IBM Mainframe Forum

The Programmer's Reference makes it clear that in the XCTL command the LENGTH parameter is optional with the COMMAREA parameter. The LENGERR 22 RESP2 value 28 can set when the LENGTH is specified and is larger than the length of the COMMAREA field specified. If you leave off the LENGTH parameter the pre-compiler inserts a command before the CALL to move the LENGTH OF the commarea field. If you cannot specify a value for LENGTH that is larger, which is understandable, and the LENGTH does not need to be used when the LENGTH is equal to the length of the COMMAREA field, what is the purpose of the parameter unless you specify a smaller length than the COMMAREA field? There appears to be no documentation identifying that this is an option, and there is no LENGERR condition that would set if you coded the XCTL this way. Rather than just the receiving programs DFHCOMMAREA being defined smaller than the XCTL COMMAREA field, with the intent of only referencing a subset of the COMMAREA, can't you specify a smaller LENGTH in the sending programs XCTL as well? It would certainly make it clear to other programmers that the intention is to send the subset of data and receive the subset of data, rather than seeing a mismatch of field sizes between the sender and receiver.

Any feedback is greatly appreciated. Thank you.

From the CICS 4.2 Application Programming Guide manual, page 290 on Program Control :

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.

To avoid this happening, your program should check whether the length of any communication area that has been passed to it is as expected, by accessing the EIBCALEN field in the EIB of the task. If no communication area has been passed,the value of EIBCALEN is zero; otherwise, EIBCALEN always contains the value specified in the LENGTH option of a LINK, XCTL, or RETURN command, regardless of the size of the data area in the invoked program. You should ensure that the value in EIBCALEN matches the value in the DSECT for your program, and make sure that your transaction is accessing data within that area.

Thank you for the response. However, this addresses the fact that the DFHCOMMAREA can be shorter in the receiving program, but does not clarify what IBM/CICS expects of the LENGTH parameter in the program initiating the XCTL. My question is more high-level wondering what the real purpose of the LENGTH for the COMMAREA is for. As I mentioned, the absence of the LENGTH will set the EIBCALEN based on the size of the COMMAREA (achieving the same thing as setting the LENGTH for the LENGTH OF the COMMAREA), coding a LENGTH greater than the COMMAREA is inappropriate and will set the ERRLENG response codes. So I was hoping for feedback or experience with using a LENGTH shorter than the COMMAREA.

Thanks again.

You're asking one of those questions for which no accurate answer exists -- because the reason(s) lie in IBM and its development of CICS. IBM may have planned to do something different with the LENGTH that never got developed, or it may be for consistency of options across CICS commands, or there may have been some other reason. Accept it as being the way it is and move on to a REAL problem.