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?
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.