They said it couldn't be done.
in [Cobol]
|
From: Richard on 26 Jan 2010 18:09 On Jan 25, 12:20 pm, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > Arnold Trembley wrote: > > 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. > > Interesting post, Arnold. That is along the lines of what we actually did in > the end. We wrote a single .DLL that contained the stubs, and these called > the new subroutines dynamically. > > The Fujitsu "Dynamic Program Linkage" model (implemented via the DLOAD > compiler option and with a suitable ENTRY file containing all the stub names > and equating them to the stub .DLL) , means there were no changes required > to the existing source, but it had to be batch recompiled with the DLOAD > option. > > Only difference I can see from your solution is that we collected all the > stubs under one "umbrella" .DLL, rather than as separate called modules. > I am not sure that you are using the term 'stubs' as I understand it. A stub is code that satisfies a CALL, for example during development, in place of the actual called program. It seems that you have written stubs for each called program and this, in turn, simply does a dynamic call of actual subroutine program. Why did you need to write 'stubs' that you collected "under one "umbrella" .DLL" when "these [stubs] called the new subroutines dynamically". PROGRAM CALL "X1" --> STUB.DLL X1: CALL "X1ROUTINE" --> X1ROUTINE ??
From: Pete Dashwood on 26 Jan 2010 23:14 Clark F Morris wrote: > On Mon, 25 Jan 2010 12:20:41 +1300, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> wrote: > >> Arnold Trembley wrote: >>> 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. >> >> Interesting post, Arnold. That is along the lines of what we >> actually did in the end. We wrote a single .DLL that contained the >> stubs, and these called the new subroutines dynamically. That was misleading. The .dll actually contains the routines. They are called dynamiclly through the DLOAD. >> >> The Fujitsu "Dynamic Program Linkage" model (implemented via the >> DLOAD compiler option and with a suitable ENTRY file containing all >> the stub names and equating them to the stub .DLL) , means there >> were no changes required to the existing source, but it had to be >> batch recompiled with the DLOAD option. That's pretty much what we did. >> >> Only difference I can see from your solution is that we collected >> all the stubs under one "umbrella" .DLL, rather than as separate >> called modules. > > Unless none of the components change, I don't see the advantage of the > single DLL but then I'm used to the IBM MVS environment. As it happens they mostly don't change, but the whole .dll is managed as a single project. That makes it easy to manipulate. > For that > environment, assuming that the subroutines were all separately > compiled, the change would be re-compile the calling programs changing > the compile option from NODYNAM to DYNAM. I seem to remember NORENT has to become RENT, but that may not be true any more. >This would not work for > CICS programs. Yes. I DO remember that... :-) >The second part means that the length of parameter 2 > must have been determinable based on data passed in the other > parameters and action could then be taken based on that data. No, I specifically stated that that was not the case. Nothing in the passed parameters indicates the length of P2. However, it can be derived separately from an available dictionary. If the > field had a prefix, there are cute tricks to allow getting at that > prefix. I seem to recall using negative subscripting, but I'd be surprised if that still works. Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 26 Jan 2010 23:18 Richard wrote: > On Jan 25, 12:20 pm, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> Arnold Trembley wrote: >>> 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. >> >> Interesting post, Arnold. That is along the lines of what we >> actually did in the end. We wrote a single .DLL that contained the >> stubs, and these called the new subroutines dynamically. >> >> The Fujitsu "Dynamic Program Linkage" model (implemented via the >> DLOAD compiler option and with a suitable ENTRY file containing all >> the stub names and equating them to the stub .DLL) , means there >> were no changes required to the existing source, but it had to be >> batch recompiled with the DLOAD option. >> >> Only difference I can see from your solution is that we collected >> all the stubs under one "umbrella" .DLL, rather than as separate >> called modules. >> > > I am not sure that you are using the term 'stubs' as I understand it. > A stub is code that satisfies a CALL, for example during development, > in place of the actual called program. It seems that you have written > stubs for each called program and this, in turn, simply does a dynamic > call of actual subroutine program. Yes, what I wrote does look like that. It isn't what we did. > > Why did you need to write 'stubs' that you collected "under one > "umbrella" .DLL" when "these [stubs] called the new subroutines > dynamically". > > PROGRAM > CALL "X1" --> STUB.DLL > X1: CALL "X1ROUTINE" --> X1ROUTINE ?? please see response to Arnold. Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 26 Jan 2010 23:22 docdwarf(a)panix.com wrote: > 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 I understand your point, Doc, but there was more at stake here than "teaching IBM a lesson..." I walked away happy (all the way to the bank), IBM were let off the hook, so they were happy, and My Boss was happy because all he wanted was certain screens refreshed when certain events happened... :-) (In a non-mainframe world, that would really be standard procedure...) Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 26 Jan 2010 23:25
Michael Wojcik wrote: > Pete Dashwood wrote: >> Michael Wojcik wrote: >>> Pete Dashwood wrote: >>> >>>> 2. You are replacing a service routine (a called program, not in >>>> COBOL) with a new routine, in COBOL. ... >>>> >>>> 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.... >>>> >>> There isn't enough information in the problem. >>> >>> Either the length of the buffer is available out-of-band, or it >>> isn't. The problem says it "MIGHT" be available from a dictionary. >>> That's not a useful statement. It might be available from magic >>> computer elves, too; but either we don't have to accommodate the >>> case where it is not available from that source, in which case the >>> problem is solved, or we do, in which case we are no closer to a >>> general solution. >> >> Yes, that is fair comment. I used MIGHT because there was some doubt >> about whether the "dictionary" would actualy be built and accessible. > > OK, but we still don't know whether we can use it in our solution... > >> Also, this >> is meant to be a fun exercise and not to be taken too literally (I >> should have known that posting it here would preclude any element of >> fun... :-( ) > > I didn't say I wasn't having fun with it! Just that there wasn't > enough information to solve the problem. (Clearly, there was enough to > speculate at some length... :-) > >> Take it, for the sake of the exercise that a it IS possible to >> derive the length of the buffer in the calling program, from a >> dictionary. > > OK. In that case I'd probably use reference modification to operate on > the buffer using the correct length, assuming standard procedural > COBOL. > > In our comms code, it's pretty common to have linkage like: > > 01 incoming-record. > 03 rec-length pic x(4) comp-x. > 03 rec-data pic x. > > Then "rec-data" is actually processed with refmod, for example: > > move rec-data(1:rec-length) ... > > Obviously that's a highly simplified version - with no length > validation, you'd have a nifty stack-smashing opportunity here - but > you get the idea. > > (In .NET managed code, I could declare a working-storage "binary-char > unsigned occurs any" item, then set its length and contents from the > linkage item. Then I'd have an Array object with the correct length > and all the other Array methods available, which would make the > subsequent code safer and cleaner.) Excellent! Fujitsu has some special facilities that make this easy. We used those. Pete. -- "I used to write COBOL...now I can do anything." |