CA IDMS

Expand all | Collapse all

Tech Tip: CA IDMS Why are API records are defined in IDD as modules?

  • 1.  Tech Tip: CA IDMS Why are API records are defined in IDD as modules?

    Posted 10-18-2016 04:48 PM

    Question:

     

    In reviewing the API records, I find that the following records are defined in IDD as modules:    WS-RESPONSE-MSG-DATA 

               WS-REQUEST-MSG-DATA 

    Is there a reason that these are defined as Modules and not records ? 

     

    Answer: 

     

    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. 

    05 WS-REQUEST-MESSAGE. 

    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. 

     

    Additional Information:

    https://docops.ca.com/ca-idms/19/en/using/using-web-services/using-the-web-services-api



  • 2.  Re: Tech Tip: CA IDMS Why are API records are defined in IDD as modules?

    Posted 10-18-2016 09:45 PM

    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