They said it couldn't be done.
in [Cobol]
|
From: Richard on 25 Jan 2010 12:44 On Jan 26, 1:48 am, Fred Mobach <f...(a)mobach.nl> wrote: > Pete Dashwood wrote: > > Richard wrote: > >> 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. > > <<snip>> > > >> 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. > > Minor change to the grep command : > grep -E -i "call *\"name\"" *.cbl > so more than 1 space between call and literal will fit. > > > As the site in question doesn't HAVE grep or an equivalent facility, > > for them, it is a nightmare. > > Then a download athttp://www.cygwin.com/of the Free Software Cygwin > might be your solution in case they're running a version of MS-Windows. grep has available for decades on almost all systems including Windows and IBM mainframes. For example http://www.dignus.com/freebies/ > > FYI, I've never used Cygwin because of lack of such an OS here. I would regard that as a bonus. > -- > Fred Mobach - f...(a)mobach.nl > website :https://fred.mobach.nl > .... In God we trust .... > .. The rest we monitor ..
From: Howard Brazee on 25 Jan 2010 12:53 On Mon, 25 Jan 2010 17:24:57 +0000 (UTC), docdwarf(a)panix.com () wrote: >I, for one, do not recall ever looking at the clock and saying 'Whoops, >10:02am... time to set everything aside, grab a cup of coffee and catch up >on the sports page'... and yet I've worked in shops where a goodly number >of folks did just that. That's silly, the sports page is in the other window on one's computer (what's a newspaper?). If one can't get caught up with sports and celebrity gossip at one's desk, what will one talk about on one's break? -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison
From: Richard on 25 Jan 2010 13:06 On Jan 26, 2:39 am, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > Richard wrote: > > On Jan 25, 11:28 am, "Pete Dashwood" > > <dashw...(a)removethis.enternet.co.nz> wrote: > >> Richard wrote: > >>> 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). > > >> Yes, that is good. But you forgot to mention the ENTRY file that > >> equates the entry point to a .DLL at run time. > > > I didn't 'forget' it, it is not needed. The CALLs are literals so if > > each called routine is named as, say, libX1.so then CALL "X1" will > > find it without an ENTRY file. > > But then you wouldn't be using a library for your solution and yiour > statement: "Recompile and relink as a set of _libraries _ " is not correct. > A libNAME.so _is_ a dynamic link library on Unix/Linux (so = shared object) on Windows it would be named libNAME.DLL It may be that my set of libraries has one module per library but that was not excluded as a solution, it is just that you were unaware of that option. > >> DLOAD implements "dynamic program linkage" (as opposed to "dynamic > >> linkage") and is a Fujitsu facility that allows the static calls to > >> be processed dynamically at run time, via an ENTRY file which > >> equates the entry points ot the respective libraries. > > > It only needs the ENTRY file if you have bundled the routines into one > > library file that needs to be identified. > > Or several library files, which ios what you siuggested. > You had specified there were about 20 called routines, I suggested about 20 dynamic load libraries with naming that reflected the routine's call name so no ENTRY file needed. How hard is that ? > > >>> 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. > > >> As the site in question doesn't HAVE grep or an equivalent facility, > >> for them, it is a nightmare. > > > If it doen't have grep or equivalent then _everything_ is a nightmare. > > Perhaps...:-) > > You'd be amazed the number of sites that actually function without tools a > "good" site would take for granted. > > > If they have Rexx or PERL or even AWK then they do have an equivalent > > to grep. Writing a simple COBOL program to search source code for > > CALLs should not be beyond them. > > It was suggested. > > > Your "doesn't HAVE grep or an equivalent" sounds exactly like like "it > > couldn't be done". > > No, I didn't say that. What you implied was that 'an equivalent couldn't be done'. > >>> With dynamic linking there may be a problem because the CALL can be > >>> a variable and the name may come from anywhere: > > >> That's why the ENTRY file is important. > > > The problem as given was that currently the CALLs were static. This > > means that it was CALL literal, thus no problem. But even with CALL > > variable the system finds libNAME.so without any ENTRY file being > > required. > > Only if each subroutine is it's own module. Each subroutine is in its own dynamic library, yes. Your point being ? > >>> 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. > > >> The Fujitsu ENTRY file is a text file that can be managed externally > >> in a similar way. The PRIMA Toolset analyses any .DLL you specify > >> and generates this file for you. > > > Not needed. > > Funny, the solution doesn't run wthout it. (All of the claaed stubs arein a > single .DLL) _YOUR_ solution may not run without it. _MY_ solution does not need it. The problem as stated was to get "_a_ dynamic environment", and did not require it to be identical to yours. > > >>>> 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. > > >> No. The existing (non-COBOL program) has facilities that COBOL > >> doesn't have, so you CAN'T do that. > > >> No more clues... :-) > > > Fujitsu has ANY LENGTH > > That's a good point and I hadn't thought of it. > > As I mentioned in a different post, there is usually more than one > solution... > > Pete. > -- > "I used to write COBOL...now I can do anything."
From: Anonymous on 25 Jan 2010 13:35 In article <mgmrl518t0lr67ufbnrf65qh9c1ak2bqkn(a)4ax.com>, Howard Brazee <howard(a)brazee.net> wrote: >On Mon, 25 Jan 2010 17:24:57 +0000 (UTC), docdwarf(a)panix.com () wrote: > >>I, for one, do not recall ever looking at the clock and saying 'Whoops, >>10:02am... time to set everything aside, grab a cup of coffee and catch up >>on the sports page'... and yet I've worked in shops where a goodly number >>of folks did just that. > >That's silly, the sports page is in the other window on one's computer >(what's a newspaper?). The thing you use to try and block some of the radiation pouring out of the 3270 terminal, of course. >If one can't get caught up with sports and >celebrity gossip at one's desk, what will one talk about on one's >break? Where one is spending one's vacations... this was back when folks still worked in places long enough to get vacations, instead of getting Engulfed, Devoured and right-sized. DD
From: Pete Dashwood on 25 Jan 2010 16:51
Richard wrote: > On Jan 26, 2:39 am, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> Richard wrote: >>> On Jan 25, 11:28 am, "Pete Dashwood" >>> <dashw...(a)removethis.enternet.co.nz> wrote: >>>> Richard wrote: >>>>> 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). >> >>>> Yes, that is good. But you forgot to mention the ENTRY file that >>>> equates the entry point to a .DLL at run time. >> >>> I didn't 'forget' it, it is not needed. The CALLs are literals so if >>> each called routine is named as, say, libX1.so then CALL "X1" will >>> find it without an ENTRY file. >> >> But then you wouldn't be using a library for your solution and yiour >> statement: "Recompile and relink as a set of _libraries _ " is not >> correct. >> > > A libNAME.so _is_ a dynamic link library on Unix/Linux (so = shared > object) on Windows it would be named libNAME.DLL > > It may be that my set of libraries has one module per library but that > was not excluded as a solution, it is just that you were unaware of > that option. > What makes you think I was unaware of it? I was totally aware of it. We opted for a single .DLL because it is a better solution. > >>>> DLOAD implements "dynamic program linkage" (as opposed to "dynamic >>>> linkage") and is a Fujitsu facility that allows the static calls to >>>> be processed dynamically at run time, via an ENTRY file which >>>> equates the entry points ot the respective libraries. >> >>> It only needs the ENTRY file if you have bundled the routines into >>> one library file that needs to be identified. >> >> Or several library files, which ios what you siuggested. >> > > You had specified there were about 20 called routines, I suggested > about 20 dynamic load libraries with naming that reflected the > routine's call name so no ENTRY file needed. > > How hard is that ? Not hard, just a poorer solution. It means 20 different objects to be looked after when they can be in a single .DLL. (Library) Just to avoid the use of an Entry file which is generated by a tool anyway? > >> >>>>> 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. >> >>>> As the site in question doesn't HAVE grep or an equivalent >>>> facility, for them, it is a nightmare. >> >>> If it doen't have grep or equivalent then _everything_ is a >>> nightmare. >> >> Perhaps...:-) >> >> You'd be amazed the number of sites that actually function without >> tools a "good" site would take for granted. >> >>> If they have Rexx or PERL or even AWK then they do have an >>> equivalent to grep. Writing a simple COBOL program to search source >>> code for CALLs should not be beyond them. >> >> It was suggested. >> >>> Your "doesn't HAVE grep or an equivalent" sounds exactly like like >>> "it couldn't be done". >> >> No, I didn't say that. > > What you implied was that 'an equivalent couldn't be done'. > Whatever inference you took is entirely a matter for you. There was no implication. > > >>>>> With dynamic linking there may be a problem because the CALL can >>>>> be a variable and the name may come from anywhere: >> >>>> That's why the ENTRY file is important. >> >>> The problem as given was that currently the CALLs were static. This >>> means that it was CALL literal, thus no problem. But even with CALL >>> variable the system finds libNAME.so without any ENTRY file being >>> required. >> >> Only if each subroutine is it's own module. > > Each subroutine is in its own dynamic library, yes. Your point being ? > > >>>>> 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. >> >>>> The Fujitsu ENTRY file is a text file that can be managed >>>> externally in a similar way. The PRIMA Toolset analyses any .DLL >>>> you specify and generates this file for you. >> >>> Not needed. >> >> Funny, the solution doesn't run wthout it. (All of the claaed stubs >> arein a single .DLL) > > _YOUR_ solution may not run without it. _MY_ solution does not need > it. The problem as stated was to get "_a_ dynamic environment", and > did not require it to be identical to yours. > No, of course not and there are a number of possible solutions. If you like yours, that's fine. I don't care. But be aware that I chose the solution I did in full awareness of the facts surrounding Fujitsu's Dynamic Program Linkage model both with and without the use of an Entry file. > >> >>>>>> 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. >> >>>> No. The existing (non-COBOL program) has facilities that COBOL >>>> doesn't have, so you CAN'T do that. >> >>>> No more clues... :-) >> >>> Fujitsu has ANY LENGTH >> >> That's a good point and I hadn't thought of it. >> >> As I mentioned in a different post, there is usually more than one >> solution... >> Pete. -- "I used to write COBOL...now I can do anything." |