Joined: 10 Jan 2008 Posts: 29 Location: Chennai, India
Hi,
1) To retain values in next pass the values should be moved to DFHCOMMAREA. Is that possible to retain the values in map(Symbolic copybook) defined under linkage section and requesting the memory space thru GETMAIN?
01 LINKAGE SECTION.
01 DFHCOMMAREA.
COPY emprec. ==> Normal Copybook
COPY empmap ==> Symbolic Map
I would request storage for the copybook empmap using GETMAIN in my program.
2) Why we should keep the map in DFHCOMMAREA instead of working storage section?
3) What are all the other ways to retain values other than using DFHCOMMAREA and TS Queue?
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Unless you're using GETMAIN "SHARED" (not recommended) or you're attempting to save the data in the TWA, upon task termination, the storage address is no longer valid (implicit FREEMAIN has occurred) and/or the TWA has been refreshed.
Using the CWA is not a good idea, especially if the data is defined to a common area in the CWA, used by multiple programs. It would be a challenge (if not an impossibility) to synchronize this common data area with the last invocation of your transaction as other transactions would want to save their data there as well. You can scratch this idea.
The maximum length for DFHCOMMAREA and EIBCALEN value, is 32763. This is a signed-binary halfword, but COBOL treats binary-data differently. If you're not using the version of DFHEIBLK, which defines EIBCALEN (and others) as COMP-5 (instead of COMP) and your value exceeds 9999, then you need to specify TRUNC(BIN) during compilation.
Another method (other than storing the map-data in the commarea) is to keep the data in the map itself, setting map-fields, which have been entered, to attribute FSET. The drawback is that the next invocation of your transaction will cause you to re-edit data that perhaps, you've already validated. You can find the attribute bytes in IBM copybook DFHBMSCA.
TSQ's are a definite possibility, but care must be taken to ensure the TSQ's are deleted when you're done using them. Enough left-over TSQ's can cause issues with Main Storage and/or Auxiliary Storage (DFHTEMP), depending on where the TSQ's were created.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Suceender Kumar stated -
Quote:
I read in CICS document like "It is good programming practise to keep the map under Linkage Section". Hence i raised this Query.
I have another doubt. Do we need to issue GETMAIN command for each pass or only in the first pass?
In order to keep the map in LINKAGE, it is necessary to issue a GETMAIN for the map, prior to the initial SEND. Subsequent RECEIVES use a SET (instead of an INTO) and subsequent SENDS use FROM (always).
Years ago, using OS/VS COBOL (non-reentrant), it was normal to use the approach of having the map in LINKAGE. But, since the introduction of re-entrant WS (VS/COBOL II - mid/late 1980's), it isn't necessary to define the map to LINKAGE anymore and defining the map to WS is now preferred.
Remember, the greater the number of GETMAIN's, the more cycles are used for the region to go through storage-compression, during implicit and explicit FREEMAIN's. In addition, when CICS/MVS 1.7 was released in the late 1980's, the RESP/NOHANDLE facility was introduced. This was significant because when you define HANDLE CONDITIONS, CICS issues internal GETMAIN's. Using RESP/NOHANDLE removes the need for these internal GETMAIN's and so, reduces the potential for additional storage-compression.
You should generate a TRACE (or this will be in a transaction dump) and look at the number of things behind the scenes CICS is doing.
WS for your program is obtained via an internal GETMAIN, so if you can acquire all the storage you need in one fell swoop, then it would be additional overhead to issue additional GETMAIN's, unless of course, it was a necessity by design.
Although this might be slightly off-topic, it does touch on Dynamically Allocated Storage. If you use CICS Dynamic CALL's (not CICS LINK API's), the WS allocated in the Dynamically Called sub-program should be kept to a manageable amount because this WS is not implicitly FREEMAINed until task termination. Program's which are accessed via a LINK-API, have their WS allocated (GETMAINed) upon entry and deallocated (FREEMAINed) upon exit (CICS RETURN) back to the Linker. For LE compliancy, this is known as an entry and exit Enclave.
