Enhancemen request for COBOL
What:
Variable-length tables, the Enhancement of OCCURS DEPENDING ON clause
In a hybrid application architecture where the client resides on a distrubited platform (Java, .Net, iOS, Android etc) there is a need for Mainframe COBOL applications to return data from a header table, row-table, and sub-rov table in the same response without having the client to match data from this type of response.
Now, would it be possible to enhance the OCCURS DEPENDING ON clause in COBOL to make it possible to have nested OCCURS DEPENDING ON? That is, to make it possible to declare a COBOL copybook like this:
05 MfContractResponseData.
07 MfNoOfMessageObjects PIC 9(009).
07 MfMessageObject.
09 MfViewRequisition OCCURS 1 to 1252 times
Depending ON noOfMessageObjects.
11 MfBuyerdata.
13 MfPurchasingOrgId PIC X(004).
13 MfHandlerId PIC X(004).
11 MfPartData.
13 MfPartId PIC X(021).
13 MfPartDescription PIC X(025).
13 MfPartIssue PIC X(003).
13 MfDrawingNo PIC X(020).
13 MfProjectId PIC X(008).
11 MfPlantRequirement.
13 MfMaterialUserId PIC 9(009).
13 MfProductionWeek PIC 9(009).
13 MfConsignee PIC 9(009).
13 MfConsigneeCode PIC X(001).
13 MfOrderQuantity PIC 9(009).
13 MfOrderSuffixId PIC 9(004).
13 MfShiptoArriveWeek PIC 9(009).
13 MfNoOfIntlFlowLines PIC 9(004).
13 MfInternalFlow OCCURS 1 to 50 times Depending on
Depending on MfNoOfIntlFlowLines.
15 MfInternalFlowQty PIC 9(009).
15 MfInternalFlowAddress PIC X(010).
15 MfNoOfInternalFlowSubLines PIC 9(004).
17 MfInternalFlowSubLines OCCURS 1 to 500 times
Depending on MfNoOfInternalFlowSubLines.
19 MfConsigneeId PIC 9(009).
19 MfConsigneeName PIC X(035).
11 MfRequistionCreationDetails.
13 MfRequistionCreatedDate PIC X(009).
13 MfRequistionInitiatedDate PIC X(009).
13 MfIssuerName PIC X(035).
13 MfIssuerUserId PIC X(008).
13 MfIssuerSectionId PIC X(006).
13 MfOrginatorName PIC X(035).
13 MfFinancialApproverName PIC X(035).
11 MfFinanceData.
13 MfWbsId PIC X(024).
13 MfCostCenterId PIC X(010).
13 MfAccountId PIC X(021).
13 MfPriceLimit PIC X(013).
13 MfCurrencyCode PIC X(003).
13 MfUnitOfMeasureCode PIC X(003).
11 MfNoOfNoteLines PIC 9(004).
11 MfRequistionNotes OCCURS 1 to 15 times
Depending on MfNoOfNoteLines.
13 MfTextNotes PIC X(079).
As it is now, this clause only allows multiple Occurs Depending on, on the same group level. Thus, we have to hard code as below which creates a lot of “white space”:
13 MfInternalFlow OCCURS 1 to 50 times.
15 MfInternalFlowQty PIC 9(009).
15 MfInternalFlowAddress PIC X(010).
15 MfNoOfInternalFlowSubLines PIC 9(004).
17 MfInternalFlowSubLines OCCURS 1 to 500 times.
19 MfConsigneeId PIC 9(009).
19 MfConsigneeName PIC X(035).
…
11 MfRequistionNotes OCCURS 1 to 15 times.
13 MfTextNotes PIC X(079).
Frankly, I cannot believe that this clause has not yet changed due to IBM's preaching of the API era:-) Another way to solve this issue is to have this cause on the same group level and provide an ID that the client guys can use to match header, row and sub-rows, however, this is, as I se it, a bad solution. Besides, should the mainframe not have this capability for its main z/OS language?
Canceling this RFE as mentioned by the submitter.
Discussing this further with the client via email.
Hi,
Again, from the COBOL manual, to my understanding, nested Occurs Pending On arrays are not possible. Thus, it seams we have a different opinion of this capability. The reason I would like to have this COBOL feature is that I strongly feel that it should be possible for a mainframe COBOL application, especially in an API world, to return a message in a way that does not require extra coding from the consumer of this service. For example, if the Mainframe COBOL service is to return Orders and each order contain one Order header, n number of Order Rows, and n number of Order Sub-Rows it should be possible to nest them in arrays using Occurs Depending On. This way, the Header, rows and sub-rows are structurally kept together in the message. However, it is possible to nest arrays this way, but only the first/outer/header array can use Occurs Depending On, the other two arrays in this example would have to be fixed. I am sure you understand that this is not a good option since the number of rows and sub-rows may change over time and there will be lot of white space sent if a fixed array is over-sized in order to avoid frequent program changes.
Hi Oliver,
Apologies for the delay.
Just a reminder, nested ODO is supported in the compiler.
To clarify, do you need the "variables" within the next ODO table. Are you able to move the ODO variables to a fixed location?
Also, may we know if you really need to use the ODO tables in this example? ODO tables are primarily for mapping data in a file. Would it be possible to use normal occurs tables here with a variable that tracks how many 'valid' elements are in each table? In other words, do you need the 'variably located' property of items that appear after ODO tables?
From the COBOL manual, to my understanding, nested Occurs Pending On arrays are not possible. The reason I would like to have this COBOL feature is that I strongly feel that it should be possible for a mainframe COBOL application, especially in an API world, to return a message in a way that does not require extra coding from the consumer of this service. For example, if the Mainframe COBOL service is to return Orders and each order contain one Order header, n number of Order Rows, and n number of Order Sub-Rows it should be possible to nest them in arrays using Occurs Depending On. This way, the Header, rows and sub-rows are structurally kept together in the message. However, it is possible to nest arrays this way, but only the first/outer/header array can use Occurs Depending On, the other two arrays in this example would have to be fixed. I am sure you understand that this is not a good option since the number of rows and sub-rows may change over time and there will be lot of white space sent if a fixed array is over dimensioned in order to avoid frequent program changes.
Hi,
Nested OCCURS DEPENDING ON is already supported. May we know what sort of issue you are facing when trying to use this? or how are you trying to extend this?
Is it possible to change the structure of the layout? If so, is it possible to move all the ODO objects out to the top? If that doesn't solve the problem, can you show the resulting error message?
Or
Can you write your own routine/method that does this?
This would be usefull for GENERATE and PARSE statement for XML or JSON document.
Growing or shrinking inner table must move data after the table down or up in an automatic proces.
In fact each part after an OCCURS DEPENDING is a floating structure. An internal pointer on this floating structure can help in adresses computing (value of pointer must be changed when value of data item referenced by DEPENDING ON is changed).
Allowing the OCCURS DEPENDING ON data item to be located inside a table would be very bad for performance, because it would be impossible to determine the location of a data item inside such a nested table without checking the size of every previous element.
If Dynamic Capacity Tables (RFE below) were implemented, would that help your use case?
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=92391
This RFE is being investigated further.