GETMAIN or CEEGTST

Larret Miyuki · New User Joined: 07 Apr 2010 Posts: 7 Location: Poland

Here is scenario: I want to allocate memory for ODO table in linkage section of program C. Program A which is CICS transaction calls program C. Program B which is batch executed by JCL will also call program C.
In such case, can I use CEEGTST in program C for both environments (CICST, TSO), or should I build GETMAIN version of program C for CICS usage?

Bill O'Boyle · Posted: Wed Jul 14, 2010 3:21 pm

You can use CEEGTST for both Batch and CICS. However, it would be good practice to call CEEFRST when you are finished with this storage.

Note that when calling CEEFRST, the program performing the CALL doesn't have to be the program which called CEEGTST. All you need is the storage POINTER and a 12-Byte Feedback-Area.

Bill

Bill O'Boyle · Posted: Wed Jul 14, 2010 3:41 pm

Click below for a sub-program, which will inform the caller of the run environment (Batch or CICS). You may find it to be applicable to what you want to do.

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

But, there's a change necessary. Instead of using R12, use R3 instead.

R12 contains the address of the CEECAA (from the LE compliant High-Level caller) and it would be best to preserve it, in case your shop decides that the sub-program should be made LE compliant.

Bill

Larret Miyuki · New User Joined: 07 Apr 2010 Posts: 7 Location: Poland

Larret Miyuki · New User Joined: 07 Apr 2010 Posts: 7 Location: Poland

I belive that storage would be freed when I finish program that called program C (C uses CEEGTST) and in this case there is no need to call CEEFRST from caller program - can you confirm this Bill?

dbzTHEdinosauer · Posted: Wed Jul 14, 2010 6:09 pm

I believe that it is freed at termination of the run-unit,
and not due to an EXIT from a module to an upper module.

also, I believe the storage will remain - acquired - even if a CANCEL is issued.
Unless you have saved the pointer for the upper module,
the storage remain acquired but unaddressable.

Bill O'Boyle · Posted: Wed Jul 14, 2010 6:14 pm

For a CICS GETMAIN (except SHARED) an implicit FREEMAIN is issued at task termination. But, I've used CEEGTST before in Batch and the storage acquired via CEEGTST is implicitly freed either at the end of the STEP or the end of the JOB. Because CICS is a JOB or STC, this is why I suggested to explicitly free the storage using CEEFRST.

By calling CEEFRST, then there's no question that the storage has been freed, regardless of the environment.

Bill

Larret Miyuki · New User Joined: 07 Apr 2010 Posts: 7 Location: Poland

That's interesting. I've just debugged such scenario: CICS program A is CALLing program B. Program B has copybook on LINKAGE section (included in CALL instruction in program A) - this copybook gets dynamic storage. After EXIT instruction from pgm B, pgm A doesn't see storage allocated by B. However if I use those programs but I won't allocate storage with CEEGTST in pgm B, program A can access data of this copybook.

dbzTHEdinosauer · Posted: Wed Jul 14, 2010 9:32 pm

not completely clear on sequence of events.

PROG-A COBOL CALL Pgm-b using????? copybook?

PROG-B Procedure Division using ???? copybook?

copybook gets dynamic storage - from where? what?

if prog-a passes the copybook to prog-b (CALL pgm-b using copybook)
the copybook is either using PROG-A's storage or from somebody above prog-a.

If you acquire storage via CEEGTST in Prog-B,
not execute CEEFRST,
and return to Prog-a with a Pointer to the acquired storage,
Prog-A can address the acquired storage via the pointer set by prog-b with the CEEGTST CALL.
IF you don't pass a pointer back to Prog-A then Prog-A can not address the acquired storage - even though it still exists if no CEEFRST CALL is made.

Bill O'Boyle · Posted: Thu Jul 15, 2010 3:14 am

If you can determine the run environment as CICS and establish addressability to the EIB, write a small callable (not linked-to) COBOL/CICS program, which issues a CICS GETMAIN and returns the storage address in a parameter.

Then, you won't have to worry about freeing the storage as CICS will issue an implicit FREEMAIN at task termination.

You can also eliminate calling CEEFRST for a Batch environment.

FWIW, LE introduced a callable service routine in release 1.8, named CEE3INF, which can also inform you of the run environment.

The trick is to "disguise" the CICS environment to the "Calling" program, by performing CICS API's via "Called" sub-programs.

As long as you have proper control-block addressability, the "Called" sub-programs will do exactly what you tell them.

Bill

dbzTHEdinosauer · Posted: Thu Jul 15, 2010 4:28 am

Larret Miyuki · New User Joined: 07 Apr 2010 Posts: 7 Location: Poland

dbzTHEdinosauer: IF you don't pass a pointer back to Prog-A then Prog-A can not address the acquired storage - even though it still exists if no CEEFRST CALL is made.

Scenerio 1:
Program A CALL program B using COPYBOOK1 (copybook is in Working Storage area of program A, and in Linkage of program B).
Program B allocates storage for ODO in COPYBOOK1 with CEEGTST. COPYBOOK1 also includes POINTER variable, which holds address of newly acquired storage.
Program A : won't compile in such scenario - error IGYPS2161-S (which is ok)

Scenerio 2: Just like scenerio 1 but COPYBOOK1 is in Linkage section of program A and Linkage section in program B. Program A will crash as it try to move some input data to COPYBOOK1 (which storage is in Linkage section, so at this time it doesn't has addressability).

Any ideas?

Larret Miyuki · New User Joined: 07 Apr 2010 Posts: 7 Location: Poland

OK. I simply used two CPYs. One is in WorkingStorage section (input data), second is in Linkage (output used by CEEGTST).

Problem solved. Thx.

dbzTHEdinosauer · Posted: Thu Jul 15, 2010 1:15 pm

glad to here that you solved the problem.