They said it couldn't be done.
in [Cobol]
|
From: Arnold Trembley on 25 Jan 2010 01:50 On 1/24/2010 5:05 PM, Pete Dashwood wrote: > (snip) > My experience, garnered over many installations and cultures, has been that > when tech guys say: "You can't do that." what they really mean is: "I don't > know how to do that." > > The most memorable case of this in my experience was in Spain when IBM told > a client that 3270 screens in conversational mode cannnot be automatically > refreshed. (The client wanted a chief dealer's screen to be automatically > updated when other dealers did a deal.). They were right; it says so in the > manual... > > I provided a solution and 2 weeks later IBM were invited to a demo where > screens were automatically updated without Enter needing to be pressed, > exactly as the client required. > > The IBM guys were shocked and claimed I must have modified their software > and it could no longer be supported by them. I hadn't. The solution was > implemented, in standard IBM COBOL at the time (I think it was MVS/OS), > using the standard IBM software without modification. I showed them how I > did it and they said: "Awww...Well, of course... if you do it like THAT..." > :-) I'm not sure how to do it in Conversational CICS, but we did that in pseudo-conversational CICS. The program waits on an ATTN key (such as ENTER), in order to accept 3270 input and display 3270 output, but it can be written to wait for either an ATTN key or a message sent to itself as a started task with a time delay. You press enter to get the screen updated, or wait for the event/message to force a screen update. I have worked with long-running conversational CICS programs, but only to service VTAM or TCP/IP ports. None of those do screen dialogs with a human being. I'm very curious how it's done with fully conversational CICS. -- http://arnold.trembley.home.att.net/
From: Fred Mobach on 25 Jan 2010 07:48 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 at http://www.cygwin.com/ of the Free Software Cygwin might be your solution in case they're running a version of MS-Windows. FYI, I've never used Cygwin because of lack of such an OS here. -- Fred Mobach - fred(a)mobach.nl website : https://fred.mobach.nl .... In God we trust .... .. The rest we monitor ..
From: Fred Mobach on 25 Jan 2010 07:56 Pete Dashwood 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 is discussed enough I think>> > 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? In case you use a data definition in the linkage section with a 01 THISGROUPITEM. 03 THISITEM PIC X OCCURS 8000. and you can get the length to be processed from an existing "dictionary" and don't access the THISGROUPITEM nor any byte in THISGROUPITEM beyond the indicated length on mainframes known to me no crash will occur. -- Fred Mobach - fred(a)mobach.nl website : https://fred.mobach.nl .... In God we trust .... .. The rest we monitor ..
From: Anonymous on 25 Jan 2010 08:28 In article <7s420vFav7U1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: [snip] >The most memorable case of this in my experience was in Spain when IBM told >a client that 3270 screens in conversational mode cannnot be automatically >refreshed. (The client wanted a chief dealer's screen to be automatically >updated when other dealers did a deal.). They were right; it says so in the >manual... > >I provided a solution and 2 weeks later IBM were invited to a demo where >screens were automatically updated without Enter needing to be pressed, >exactly as the client required. > >The IBM guys were shocked and claimed I must have modified their software >and it could no longer be supported by them. [snip] We have different approaches, Mr Dashwood; after hearing 'You must have modified our software' my response would have been 'I have not done so and I find it insulting, unprofessional and unimaginative for you to blatantly misrepresent the facts demonstrated here in an effort to cover your lack of knowledge by impugning, belittling and attempting to dismiss my skills by asserting such a thing. I will be more than willing to supply sample code as soon as your check clears the bank.' DD
From: Pete Dashwood on 25 Jan 2010 08:39
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. > >> 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. > > >> >>> 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. > >>> 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. > > >>> 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) > >>>> 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." |