They said it couldn't be done.
in [Cobol]
|
From: Fred Mobach on 26 Jan 2010 05:48 Pete Dashwood wrote: > 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) ? Yes, after checking if the derived-length is not out of range. Or the old way with PERFORM ... VARYING ... FROM 1 BY 1 UNTIL ... > LENGTHFIELD. > Fujitsu provides a slightly more elegant way to do it which I'll post > later. The Fujitsu compiler is unknown to me, the Siemens (later Fujitsu Siemens) COBOL compilers on the other hand ... But then again, I'm still eager to learn. :-) -- Fred Mobach - fred(a)mobach.nl website : https://fred.mobach.nl .... In God we trust .... .. The rest we monitor ..
From: Fred Mobach on 26 Jan 2010 06:00 Pete Dashwood wrote: > I did consider trying to detect the end of the buffer by checking > characters and trapping a storage violation, but it is pretty awful > isn't it? (As the buffer could be 8000 characters this approach was > ruled out fairly early on in the piece.) Trapping storage violations is a time consuming process that you really don't want to see as a solution. You are right on that one. -- Fred Mobach - fred(a)mobach.nl website : https://fred.mobach.nl .... In God we trust .... .. The rest we monitor ..
From: Pete Dashwood on 26 Jan 2010 06:58 Fred Mobach wrote: > Pete Dashwood wrote: > >> Fred Mobach wrote: >>> Pete Dashwood wrote: >>> >>>> Richard wrote: >>>> >>>>> 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.) > > Perhaps a recommendation to read > http://en.wikipedia.org/wiki/Comparison_of_revision_control_software > before actually spending time and money on a new software environment > ? Certainly couldn't do any harm :-) Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 26 Jan 2010 06:56 Richard wrote: > On Jan 26, 10:51 am, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> 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: <snipped> >>> _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. >> > > So, why did you claim that I "forgot" it ? Because you stated: "For Fujitsu it is DLOAD. Recompile and relink as a set of libraries and main program(s). " "Libraries" in this environment requires an Entry file. Individual, separately called modules do not. Pete.
From: Anonymous on 26 Jan 2010 09:24
In article <7s6kgdF5etU1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: >docdwarf(a)panix.com wrote: >> In article <7s5m5eFc1bU1(a)mid.individual.net>, >> Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: >>> 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. >>> :-) >> >> As I said, Mr Dashwood, we see it differently. As I see it you had a >> set of skills and experiences which could be combined in a manner >> which generated a solution which someone else - in this case IBM, an >> organisation which has a rather large profit-motive - could use to >> make money. >> >> No problem there... you want to make money from my abilities, *I* >> want to make money from my abilities. Works both ways, I'd say. >> >> (Note that this is for another party involved. IBM, I believe, was >> not collecting your timesheets nor paying for your invoices. > >Nobody collected timesheets from me as I worked on a daily basis, and was >contracted direct to the client. However, the client did pay my invoices and >I did my very best to justify the not insignificant amounts on those >invoices, by ensuring that he got what he wanted rather than what IBM said >was possible. I went there on a 6 month contract to design a database and >ended up staying 2 years. My wife instigated it as she spoke a little >Spanish and she was tired of living in Germany. We could have stayed in >Madrid indefinitely but after 2 years she was ready to return to the U.K. I >never wanted to go there but I have to say they treated us very well and it >was a good place to live and work. > >> If your >> Boss wants to give away trade secrets then that's his concern; [snip] >Why would >you make money for people who have no idea what's going on? That was my point exactly, Mr Dashwood... IBM not only had no idea what was going on (insofar as your manipulation of their technology was concerned) and stated that your techniques must have required modification of their software to the point of unsupportability. To learn that this conclusion is Just Plain Wrong is, I would say, a valuable thing and not to be given away without due recompense. DD |