Working Storage – Reusability
Hello, here is the question...
I want to create a sub-module (cobol DB2) that will be called at initialization time by the load driver (either TP ou Batch). That sub-module will load technical information in its working-storage after accessing DB2 tables.
That module will be called dynamically throughout processing by other modules that will want to access the technical data loaded in its working storage (all that to avoid passing a technical zone as an argument between modules - We are modifying an huge application here and we don't want to reopen all modules to pass that technical data zone).
We are in a CICS environment, what are the options I should use at compilation time in order to make sure the working storage data will be loaded once by the sub-module and will be available after for every module calling that same sub-module in order to access that data ? We are talking about a sub-module that will be called in TP CICS and BATCH environment....REUSE, RENT, DYNAM, AMODE RMODE
Thank you guys.
Rene
Software/Hardware used:
Software/Hardware used:
ASKED:
December 12, 2005 4:52 AM
UPDATED:
December 14, 2005 11:10 AM
Answer Wiki:
You seem to be presenting conflicting requirements. If you have to use the same program in CICS and in Batch, what do you mean by "called at initialization by the load driver"? Do you mean at IPL time, to be loaded into the MVS CSA? That's not the usual place for CICS programs.
If you want something to run at CICS initialization time, you can put a program into the PLTPI list. That program will run as a subroutine under the CPLT transaction, and will be running in CICS storage key (if you're using STGPROT). I would advise doing a GETMAIN SHARED USERDATAKEY to acquire an area of storage, then write out the address of that area into a TSQ MAIN. Have a different subroutine to be called by all your applications, and it will a) read that MAIN TSQ for the address, then b) SET ADDRESS of some Linkage Section entry to that address. The Linkage Section entry has to describe the storage layout of the GETMAINed area. I would use a common copybook for that data-area description.
From batch, each address space is going to have to go out and get the DB2 data itself, unless you intend to load it into the MVS CSA. The only other option I can think of would involve writing a non-reentrant Assembler program, lying to MVS about it, putting it into the LPA, and then going into privileged mode (SPK0) to modify the program's text itself to store the data. I wouldn't recommend doing that.
To see all answers submitted to the Answer Wiki: View Answer History.
I think SRovo01′s recommendation is good considering your ‘specs’ are not really clear.
If the ‘driver’ module stays resident and invokes all the other processing modules (as it seems you are saying), why don’t you just have the driver maintain the technical data storage area and pass the address to the processing modules for reference within their linkage sections? This seems a fairly easy solution if my understanding is correct.
I don’t think you can accomplish the same in batch unless, as SRovo01 said, you fool the system in some manner.
I read this as Rene wanting to, at the time that a CICS transaction or batch jobstep starts, dynamically call this module, have it get all of this weird technical data and have the data available for other modules in the task to get as needed.
Compiling the program with RENT should make it happen.
Thanks for your help guys, RENT does the job.
Rene