They said it couldn't be done.
in [Cobol]
|
From: Pete Dashwood on 25 Jan 2010 08:44 Fred Mobach 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 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. Thanks Fred. I think the lack of source management (or even versioning) in this place is a source of problems for them (it certainly would be for me:-)), but it is not something they are concerned about, especially as they will be replacing COBOL anyway. I believe they will move to full source management as part of the new environment. (It is likely they will standardise on Visual Studio for teams.) Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 25 Jan 2010 08:48 Arnold Trembley wrote: > 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. This was IMS/DC, running in full conversational mode with serial reusability. Pete. -- "I used to write COBOL...now I can do anything."
From: Anonymous on 25 Jan 2010 08:49 In article <7s5l9hF6q8U1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: >Richard wrote: >> On Jan 25, 11:28 am, "Pete Dashwood" >> <dashw...(a)removethis.enternet.co.nz> wrote: [snip] >>> 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. As recently as 1996 I had a contract in an IBM mainframe shop where ABEND-Aid was not available and core-dumps had to be read. DD
From: Pete Dashwood on 25 Jan 2010 08:54 docdwarf(a)panix.com wrote: > 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.' Well, I DID tease them a little bit before revealing the solution. :-) My Boss was grinning ear to ear at their amazed gasps as terminals around the room started pinging, without anybody touching them. I didn't want to alienate them too mch because I would be moving on and the customer would need their support after I was gone. In terms of credibility it was amazing. After that I walked on water and got anything I wanted for the tech team :-) And it wasn't really a lack of knowledge (they completely understood the solution once it was revealed); rather, a lack of imagination... Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 25 Jan 2010 09:00
Fred Mobach wrote: > 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. I agree that would work. I assume you would refmod the group level when updating the buffer? move changed-stuff to THISGROUPITEM (1: derived-length) ? Fujitsu provides a slightly more elegant way to do it which I'll post later. Pete. -- "I used to write COBOL...now I can do anything." |