Working storage in Called module

a_khedekar · New User Joined: 21 Dec 2003 Posts: 7

I have module A (driver) which calls so many module e.g. B, C, D etc.
One of the module D gets called on specific condition from module A.

Program D has a table defined in working storage.
First time it goes inside Program D, there is logic to populate the table from Database.

When it goes inside Program D for subsequent time, I see that the table is still populated with same data.

I researched and found out that unless that Run Unit is terminated or explicit CANCEL is issued, Program D will keep all its working storage in memory intact.

My question is, can we trust the data? If we can then why do we need linkage ?

Thanks
Atul

Bill O'Boyle · Posted: Fri Jun 05, 2009 10:36 pm

The following post might shed some light on your question -

www.ibmmainframes.com/viewtopic.php?p=192011&highlight=#192011

Furor · New User Joined: 04 Jun 2009 Posts: 30 Location: Bangalore

Please go through the below link:
Usage of INITIAL keyword.

Robert Sample · Posted: Fri Jun 05, 2009 10:45 pm

Linkage is used to pass data between calling and called program -- this data could be something that changes every call, or it could be a status code returned from the called program to the calling routine telling the success or failure of the subprogram processing.

Bill O'Boyle · Posted: Fri Jun 05, 2009 10:55 pm

If you're not trusting of the data, then move the table in "D" to LINKAGE, acquiring the necessary storage via "CEEGTST", save the storage-address in an EXTERNAL WS POINTER (known by all programs within the run-unit) and use this POINTER to establish addressability every time "D" is subsequently accessed. For that matter, because the POINTER is EXTERNAL, the data is available to any program within the run-unit, providing a given program has the table definition defined to their respective LINKAGE SECTION.

You should first set the EXTERNAL WS POINTER to NULL in the Main Driver program. When "D" obtains control, check whether the POINTER is NULL and if it is, then build the table. Otherwise, it's already been built.

Storage obtained via "CEEGTST" is available until the step is terminated, where the operating system will free it back. Alternatively, you could issue a CALL to "CEEFRST" (Free Storage), but that's not normally done, unless the amount of data previously acquired via "CEEGTST" was huge and your program will not be terminating shortly.

Regards,

a_khedekar · New User Joined: 21 Dec 2003 Posts: 7

Sorry guys if 2nd question for linkage has confused you. Forget about my 2nd question. My actual question is first question.

Bill, my program is completely batch program. No CICS.

Also, it is not that I dont trust the data. I am making use of the data in the table without going into database again.
But some senior resource in my company is telling me that even IBM will not take guarantee that the data will be uncorrupted when I come back to Program D on subsequent calls.
So what is the guarantee that the data is uncorrupted and good to use next time.

I could not find enough material on internet using which I can prove that we can trust the data.

Thanks for all the help.

- Atul

Bill O'Boyle · Posted: Fri Jun 05, 2009 11:36 pm

The concept of EXTERNAL WS being available to all programs within a run-unit, is not restricted to CICS.

The dynamic building of the table and subsequent saving of the dynamic-storage address in an EXTERNAL WS POINTER, will ensure that the table-data will be intact and untouched.

Regards,

Robert Sample · Posted: Fri Jun 05, 2009 11:48 pm

From the COBOL Programming Guide section 4.1.2:

dbzTHEdinosauer · Posted: Sat Jun 06, 2009 12:10 am

Whether statically or dynamically linked, without the INITIAL clause or a CANCEL the Working-Storage will be as it was since the last invocation.

a_khedekar · New User Joined: 21 Dec 2003 Posts: 7

Thanks All.

Anuj Dhawan · Posted: Sat Jun 06, 2009 12:56 am

Bill O'Boyle · Posted: Sat Jun 06, 2009 1:06 am

Dick/Robert,

In using the dynamic-storage pitch, I was attempting to give the OP an alternative.

I understand (through many years of Vulcan Mind Melds) that once the table has been built in program "D", it remains intact and undisturbed for subsequent addressing by other callers in the run-unit, providing that a CANCEL or the "INITIAL" keyword of the PROGRAM-ID was NOT used.

And I agree 100%. The "Senior" resource is way off base with his assessment.

Regards,

a_khedekar · New User Joined: 21 Dec 2003 Posts: 7

Final solution as Bill said, data in the table will be trusted. Table will not be loaded again in subsequent calls.

But one more question, if the job abends, Run Unit will be terminated and data will be lost right ?

- Atul

Robert Sample · Posted: Sat Jun 06, 2009 3:02 am

Atul, yeah once the job finishes (normally or not) the data is gone. This also means the next time that program A is started up, the call will load the table again since all programs will start with their initial values in WORKING-STORAGE.

dick scherrer · Posted: Sat Jun 06, 2009 3:25 am

Hello,

dbzTHEdinosauer · Posted: Sat Jun 06, 2009 5:25 am

Bill,

I went a little overboard, but my main complaint was with the 'senior resource',
and probably turned a few people off. For that I am sorry.

any alternative method is ok by me.
More and more, I think we will see the need for 'dynamic extra storage'
and the methodology will slowly become accepted by more pgmrs.
Even I (the dinosaur that i am) am becoming a believer/user of such techniques.
You have a good grasp of LE facilites, they are the future in IBM,
we have to adjust and start using them.

Thx for your posts, without which I would never have explored their use
and would have stayed with my the old ways.

Bill O'Boyle · Posted: Sat Jun 06, 2009 5:48 am

Dick,

Apologies unnecessary, I wasn't bothered one bit.

Hopefully, the OP will go back to this Senior Resource and let him know that his assessment is incorrect and he should consult the manual (such as Robert's excerpt posting).

In other words, brain needs to be engaged before opening mouth

Regards,

Tom Bowman · Posted: Tue Jun 16, 2009 8:20 pm

The issue I see here is going to be if you are using a static link (which prevents 'thread independence' by forcing a seperate load of the called routine by calling program(s), thus preserving memory state) or would want to use a (more memory efficient, reentrant) dynamic link (marked RENT). Renterable code MAY keep the same memory state (if not unloaded and not called by another program between your programs calls) - I would only use initial values for local WS or to initialize re-entrant memory. This concept is most useful for CICS however.

When there is an abend, all bets are off. A lot depends on the type of abend, S0C1, S806, and other memory space related abends normally are cleaned up by JES or OS. Sometimes a DB2 thread may insist on trying to run to 'completion' (which may or may not be possible), requiring one to -TERM the thread... I'd either pass the data each time I called or reload the subprogram (not very efficient, makes the loader suffer from a lot of overhead). Eventually the data will be lost, and depending on abend type is likely not relaible after an abend anyway.

dick scherrer · Posted: Wed Jun 17, 2009 8:04 am

Hello Tom and welcome to the forum,