In reviewing the API records, I find that the following records are defined in IDD as modules: WS-RESPONSE-MSG-DATA
Is there a reason that these are defined as Modules and not records ?
The reason given for these records being in a module definition instead of a record definition is that this type of construct (compatible with COBOL) is not allowed for a record definition within CA IDMS.
Trying to do this as a record fails:
ADD REC WS-RESPONSE-MSG-DATA LANGUAGE IS COBOL.
10 WS-REQUEST-MSG-BYTE PIC X(1)
OCCURS 0 TO 1 TIMES
DEPENDING ON WS-REQ-MSG-BUFF-LEN.
* E DC601123 DEPENDING ON NAME NOT FOUND FOR RECORD ELEMENT
* - DC601123 WS-REQUEST-MSG-BYTE
If the length of the buffer is fixed (WS-RSP-MSG-BUFF-LEN and / or WS-REQ-MSG-BUFF-LEN is fixed ) then it is be okay to define the module as a record without the occurs clause because in both cases they depend on the values in these two elements.
I think there may be more to it than that ... as WS-RSP-MSG-BUFF-LEN and / or WS-REQ-MSG-BUFF-LEN could be defined as elements in the REC definition - but it is a requirement of the ADS " LINK ... using parm-1 parm-2 etc " that the parameters are defined as records. ADS does not allow ELEments within a RECord to be passed as a parameter, and these length values are passed as unique parameters in the API.
So in the Cobol API WS-RSP-MSG-BUFF-LEN is passed as a parameter and may be either at a Record (01) or subordinate level - it must be a RECord for ADS. So because it must be stored in IDD as a separate Record and included in the dialog - you cannot (for ADS purposes if it is going to be passed as a parameter) have it as a subordinate element in a RECord so that you can refer to it in an ODO clause - because it must also be included as a RECord in the dialog definition. Very frustrating at times.
Note: You could have 05 WS-RSP-MSG-BUFF-LEN in the above record, and WS-RSP-MSG-BUFF-LEN-PARM as a RECORD in IDD to be included in the dialog and passed as a parameter in the LINK ... USING - then MOVE WS-RSP-MSG-BUFF-LEN-PARM to WS-RSP-MSG-BUFF-LEN after calling the API.
HTH - cheers - Gary