They said it couldn't be done.
in [Cobol]
|
From: Pete Dashwood on 24 Jan 2010 06:19 Here's a couple of intellectual exercises if anyone is bored or wants to think about something else for a break... Two problems relating to COBOL... (Assume Fujitsu NetCOBOL for both solutions, or whatever version of COBOL you use if you can solve them with your current compiler.) 1. Imagine you have a couple of thousand COBOL programs, all written in ANSI 74 procedural COBOL. Almost every one of these programs makes static calls to a number of subroutines (say there are around 20 of these subroutines). sample call : CALL "X1" using p1, p2, p3, p4. Obviously, because of the static linkage, there is HUGE duplication of these subroutines throughout the environment. (Every other program has the same subroutines statically linked into it, and some of these "subroutines" are "large"...) Changing any of the called routines means a nightmare of identifying and recompiling every program that uses it. For reasons connected with a new environment, you need these routines to be dynamically called, but you cannot change all the calling programs. (In fact, the client has insisted that the calling program code must remain EXACTLY as it is.) Can you get to a dynamic environment WITHOUT recoding or amending the calling programs? 2. You are replacing a service routine (a called program, not in COBOL) with a new routine, in COBOL. The new routine has the same signature as the old one and receives several parameters from the calling programs. Here is its signature: procedure division using p1, p2, p3, p4. p1, p3, and p4 are always the same type and length. But, p2 can vary in length (it is a record buffer). It could be defined in the working storage of each calling program as anything from 20 to 8000 bytes. (Not with OCCURS... DEPENDING, just different fixed length records.) Your called routine has to update this buffer; if you set a wrong length in the Linkage section you will immediately crash on a storage violation as soon as you try to write the record back. You might think it is pretty easy to pass a record length or some other clue) as another parameter. Nope. The same rules as above; you cannot modify the existing code, and it doesn't have a "p2-length" in its parameter list. Clue: You MIGHT be able to derive the p2 length from an existing "dictionary", accessible by your new program. Any thoughts on how the called program could be coded to accommodate these requirements? FINALLY, as inspiration, some poetry... "They said it couldn't be done But he, with a smile, denied it He said:'How do you know that it cannot be done?' Until you, at least, have tried it. So he rolled up his sleeves And he gritted his teeth And where there was doubt He hid it. And he tackled that job that 'Couldn't be done'.... And, Whaddya know?!! He couldn't bloody do it..." Pete. -- "I used to write COBOL...now I can do anything."
From: Richard on 24 Jan 2010 13:37 On Jan 25, 12:19 am, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > Here's a couple of intellectual exercises if anyone is bored or wants to > think about something else for a break... > > Two problems relating to COBOL... (Assume Fujitsu NetCOBOL for both > solutions, or whatever version of COBOL you use if you can solve them with > your current compiler.) > > 1. Imagine you have a couple of thousand COBOL programs, all written in ANSI > 74 procedural COBOL. Almost every one of these programs makes static calls > to a number of subroutines (say there are around 20 of these subroutines).. > > sample call : CALL "X1" using p1, p2, p3, p4. > > Obviously, because of the static linkage, there is HUGE duplication of these > subroutines throughout the environment. (Every other program has the same > subroutines statically linked into it, and some of these "subroutines" are > "large"...) Changing any of the called routines means a nightmare of > identifying and recompiling every program that uses it. > > For reasons connected with a new environment, you need these routines to be > dynamically called, but you cannot change all the calling programs. (In > fact, the client has insisted that the calling program code must remain > EXACTLY as it is.) > > Can you get to a dynamic environment WITHOUT recoding or amending the > calling programs? That is not a COBOL problem but is an implementation issue. Given that all CALLs would have to be using a literal to get static linkage then it is a matter of specifying the compiler and linking options applicable to the particular system being used. For Fujitsu it is DLOAD. Recompile and relink as a set of libraries and main program(s). Anyway, identifying the calling programs is not a 'nightmare', a simple 'grep -i "call \"name\"" *.cbl' will pick them up because with static linking the CALL must be of a literal. With dynamic linking there may be a problem because the CALL can be a variable and the name may come from anywhere: in the case of most of my systems they can come from a system file that holds the menus and options, or can even be typed in directly. > 2. You are replacing a service routine (a called program, not in COBOL) with > a new routine, in COBOL. The new routine has the same signature as the old > one and receives several parameters from the calling programs. Here is its > signature: > > procedure division using > p1, p2, p3, p4.. > > p1, p3, and p4 are always the same type and length. > > But, p2 can vary in length (it is a record buffer). It could be defined in > the working storage of each calling program as anything from 20 to 8000 > bytes. (Not with OCCURS... DEPENDING, just different fixed length records..) > > Your called routine has to update this buffer; if you set a wrong length in > the Linkage section you will immediately crash on a storage violation as > soon as you try to write the record back. > > You might think it is pretty easy to pass a record length or some other > clue) as another parameter. Nope. The same rules as above; you cannot > modify the existing code, and it doesn't have a "p2-length" in its parameter > list. > > Clue: You MIGHT be able to derive the p2 length from an existing > "dictionary", accessible by your new program. > > Any thoughts on how the called program could be coded to accommodate these > requirements? You do it exactly the same way as the original (non-COBOL) program does currently.
From: Charles Hottel on 24 Jan 2010 13:42 "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message news:7s2om7Fmu2U1(a)mid.individual.net... > Here's a couple of intellectual exercises if anyone is bored or wants to > think about something else for a break... > > Two problems relating to COBOL... (Assume Fujitsu NetCOBOL for both > solutions, or whatever version of COBOL you use if you can solve them with > your current compiler.) > > 1. Imagine you have a couple of thousand COBOL programs, all written in > ANSI 74 procedural COBOL. Almost every one of these programs makes static > calls to a number of subroutines (say there are around 20 of these > subroutines). > > sample call : CALL "X1" using p1, p2, p3, p4. > > Obviously, because of the static linkage, there is HUGE duplication of > these subroutines throughout the environment. (Every other program has the > same subroutines statically linked into it, and some of these > "subroutines" are "large"...) Changing any of the called routines means a > nightmare of identifying and recompiling every program that uses it. > > For reasons connected with a new environment, you need these routines to > be dynamically called, but you cannot change all the calling programs. (In > fact, the client has insisted that the calling program code must remain > EXACTLY as it is.) > > Can you get to a dynamic environment WITHOUT recoding or amending the > calling programs? > > 2. You are replacing a service routine (a called program, not in COBOL) > with a new routine, in COBOL. The new routine has the same signature as > the old one and receives several parameters from the calling programs. > Here is its signature: > > procedure division using > p1, p2, p3, p4. > > p1, p3, and p4 are always the same type and length. > > But, p2 can vary in length (it is a record buffer). It could be defined in > the working storage of each calling program as anything from 20 to 8000 > bytes. (Not with OCCURS... DEPENDING, just different fixed length > records.) > > Your called routine has to update this buffer; if you set a wrong length > in the Linkage section you will immediately crash on a storage violation > as soon as you try to write the record back. > > You might think it is pretty easy to pass a record length or some other > clue) as another parameter. Nope. The same rules as above; you cannot > modify the existing code, and it doesn't have a "p2-length" in its > parameter list. > > Clue: You MIGHT be able to derive the p2 length from an existing > "dictionary", accessible by your new program. > > Any thoughts on how the called program could be coded to accommodate these > requirements? > > FINALLY, as inspiration, some poetry... > > "They said it couldn't be done > But he, with a smile, denied it > He said:'How do you know that it cannot be done?' > Until you, at least, have tried it. > > So he rolled up his sleeves > And he gritted his teeth > And where there was doubt > He hid it. > > And he tackled that job that > 'Couldn't be done'.... > And, Whaddya know?!! > He couldn't bloody do it..." > I remember two times when I was able to do something that "couldn't" be done. Afterwards the people who had said that (they were users) were very unhappy because they had previously be receiving large amounts of overtime for doing this manually.
From: Alistair on 24 Jan 2010 14:26 On Jan 24, 11:19 am, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > Here's a couple of intellectual exercises if anyone is bored or wants to > think about something else for a break... > > Two problems relating to COBOL... (Assume Fujitsu NetCOBOL for both > solutions, or whatever version of COBOL you use if you can solve them with > your current compiler.) > > 1. Imagine you have a couple of thousand COBOL programs, all written in ANSI > 74 procedural COBOL. Almost every one of these programs makes static calls > to a number of subroutines (say there are around 20 of these subroutines).. > > sample call : CALL "X1" using p1, p2, p3, p4. > > Obviously, because of the static linkage, there is HUGE duplication of these > subroutines throughout the environment. (Every other program has the same > subroutines statically linked into it, and some of these "subroutines" are > "large"...) Changing any of the called routines means a nightmare of > identifying and recompiling every program that uses it. > > For reasons connected with a new environment, you need these routines to be > dynamically called, but you cannot change all the calling programs. (In > fact, the client has insisted that the calling program code must remain > EXACTLY as it is.) > > Can you get to a dynamic environment WITHOUT recoding or amending the > calling programs? > How about renaming the called programs and replacing the original called program with a stub program to dynamically call the renamed program. I don't know if that would work under MVS as I don't know if a static recompile can call a program which executes a dynamic call. But don't tease, give us solutions not problems (as a really shite manager of mine used to say).
From: Arnold Trembley on 24 Jan 2010 15:52
On 1/24/2010 1:26 PM, Alistair wrote: > On Jan 24, 11:19 am, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> Here's a couple of intellectual exercises if anyone is bored or wants to >> think about something else for a break... >> (snip) > How about renaming the called programs and replacing the original > called program with a stub program to dynamically call the renamed > program. I don't know if that would work under MVS as I don't know if > a static recompile can call a program which executes a dynamic call. > > > But don't tease, give us solutions not problems (as a really shite > manager of mine used to say). It should be possible to do this under MVS (now z/OS). The Binder/Linkage editor has a feature that allows you to relink an existing program, removing a statically bound subprogram and replacing it with a new statically bound subprogram. If that program is COBOL it can turn around and call any subprogram dynamically. You don't need to recompile the main calling program. But you would need to write two programs to replace each static subprogram, the first would be a stub with the same name, to call the second dynamically with whatever name you choose. It would help quite a bit if the main COBOL program uses COBOL or Language Environment runtime libraries. -- http://arnold.trembley.home.att.net/ |