What can cause CICS transaction to write out of CICS allocated memory?

Question

I'm using CICS in Cobol program and I've noticed that sometimes data are written out of the CICS memory. It cause a data corruption and my application stop. I don't know where it append, so I'm creating a parser to analyse my Cobol code to look for possible corruption in COMMAREA used by CICS. Now I checked following statements :

EXEC CICS XCTL
EXEC CICS LINK
EXEC CICS RETURN TRANSID

For each, I check if sent length (declared in LENGTH parameter) is not greater than sent COMMAREA. Then I check if DFHCOMMAREA, in the receiving program is not greater than sent COMMAREA (according to this doc http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2Fcom.ibm.cics.ts31.doc%2Fdfhp3%2Fdfhp37t.htm) :

The receiving data area need not be of the same length as the original communication area; if access is required only to the first part of the data, the new data area can be shorter. However, it must not be longer than the length of the communication area being passed. If it is, your transaction may inadvertently attempt to read data outside the area that has been passed. It may also overwrite data outside the area, which could cause CICS to abend.

Now, I'm wondering what other things should I parse in order to detect memory overwritting?

Answer 1

When a CICS program starts writing all over memory it will not only "stop working" but possibly crash the CICS region as well!

If you are sure that the LENGTH is set properly on LINKs and XCTLs and that you are receiving the COMMAREA into a linkage record of that size (EIBCALEN), then you should be fine.

Rather than trying to parse your COBOL programs I suggest that you set compiler bounds checking options on. The problem you are having is most likely related to indexing or subscripting beyond the bounds of a working storage table. Attempting to detect this class of programming error through static analysis is generally not very effective.

Setting bounds checking on should detect out of range memory references, issue a diagnostic message to the log, and then and terminate your program before it crashes the whole CICS region. The logged message should point you the the source line where the out of bounds reference occured.

Check out the SSRANGE compile time option. Make sure it is set and that your CICS region runs LE enabled programs with CHECK(ON).

This should nail out of bounds memory references pretty quickly.

Answer 2

NealB has a good idea. I suggest you also look into the STGPROT and RENTPGM CICS system initialization parameters.

Answer 3

For the passing-of-data bounds checking, always use transclusion, which in COBOL is called a COPYCODE or COPYBOOK. Pass the root data element in the copycode, and compile the same version in the caller and called program. This COPYCODE is sortof the contract for the called program, so it is a good idea to have a naming convention tying them together. To make sure they are in-sync, whenever you change the COPYCODE, recompile all programs that reference it.

Also, the use of SSRANGE is great (but someone already mentioned that).

Answer 4

As you are using Micro Focus COBOL, you could set the memory_strategy tunable (or the CBL_MEM_STRATEGY API) to help you analysis where the error is occurring by allowing the runtime to protect memory in various different ways.

Memory can also be validate via the "CBL_MEM_VALIDATE" call.

Another thing can do is use the tracing support... lookup CTF (Consolidated Tracing Facility). This will give you an idea where you code is at the time of the error.

Some References that will help you;

http://kb.microfocus.com/display/4/kb/article.aspx?aid=31645

http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.eclipse.infocenter.studee60win.sp02ws01%2FHRRTRHRTCF0O.html

http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.eclipse.infocenter.studee60ux.sp02ws01%2FGUID-762085AC-8396-4D71-9CC1-6231551D3AEE.html