Compiler warnings with an OCCURS DEPENDING

I believe the warning is from an ANSI or ISO standard. You do not need to fix it. If you choose to fix it, you would put the  07 DYELOT-RECORDS--COUNT  PIC 9(03). item above the  07 DYELOT-RECORDS OCCURS 1 TO MAX-DYELOT-RECORDS  DEPENDING ON DYELOT-COUNT.

I ran into the same issue (also with an XBIS service program) and tried to resolve it the way Steve suggested, but it didn't work (I got even more warnings). I could only get rid of the warnings by moving the OCCURS DEPENDING table as the last item in the record (i.e. the 01-level). But with multiple method definitions under the 01-level SOAP-REQUEST-RESPONSE group, this wasn't possible

By the way, the OCCURS DEPENDING statement (a Format 2 OCCURS), including this restriction, is described in the Acu docs:

• ACUCOBOL-GT Reference Manual > Chapter 5: Data Division > 5.7 Record Description Entry > 5.7.1 Data Description Entry > 5.7.1.10 OCCURS clause

It states (in part):

8.  An item described by a Format 2 OCCURS clause can be followed, in the same record description, only by items subordinate to it.

But, you may not really need to use a variable table. Try just taking out the DEPENDING clause completely, so you just have:

07 DYELOT-RECORDS OCCURS MAX-DYELOT-RECORDS.

The compiler is going to allocate enough memory for the full, max-sized table anyway. If you're just trying to keep from sending empty array elements with your SOAP response, that can be solved with an XML Extensions statement:

XML DISABLE ALL-OCCURRENCES

This will prevent empty array elements from being exported. However, when generating the WSDL file, you'll want to reverse this with:

XML ENABLE ALL-OCCURRENCES

There's a fairly detailed explanation of these statements and their use in the XML Extensions docs. Go to:

• A Guide to Interoperating with ACUCOBOL-GT > Chapter 11: Working with Non-Vision Data > 11.2 Working with XML Data > 11.2.8 XML Extensions Statement Reference > XML DISABLE ALL-OCCURRENCES

This all makes sense, but what I ran into when taking the DEPENDING clause out was a WSDL that had the max number of elements for both the inner and outer groups in it.  When the max is 200 for both, the resulting file crashed the xbis service.  What I did to solve it was set DYELOT-COUNT to 1 before exporting the WSDL.  The XSL stylesheet seems to work with the --COUNT in order to determine how many elements to send back so that it does not send empty ones back.  

Indeed, this is described in the Xcentrisity BIS Tutorial:

Finally, also in the Browse method output-parameters, the specially named data item found-record--count is used to communicate the number of occurrences that should be exported. A --count data item may also be used on an imported data item array so that the actual number of array items imported may be known.

The --count mechanism exists because of the limitations on OCCURS...DEPENDING.  An investigation of the tutorial2 source code reveals that it does not use OCCURS DEPENDING in the SOAP-Request-Response group item.  When creating the WSDL, ALL-OCCURRENCES are turned on so that the XSLT can discover the maximum occurrence number and set that as the maximum number of elements in the schema portion of the WSDL.  At least in my RM/COBOL installation, cobol_to_wsdl.xsl does not refer to the --count data items.

If I might offer a bit of architectural advice, I would suggest that DyeLot and Rolls are two different (though obviously related) business objects, and you might be better served if you were to separate them so that they each have their own methods.  If you were designing a relational database, you could not (or at least should not) impose this type of structure on your data.  CRUD web services are probably most usable when each distinct business object has its own its own methods.  You can certainly have as many methods in a single BIS service program as you wish, so a single WSDL would contain all the related methods for the DyeLot and Roll objects.  (If I were to make an extremely educated guess, the WSDL generator is not designed to do what you are attempting, so you would need to make changes to cobol_to_wsdl, cobol_to_soap, and soap_to_cobol to meet your needs.)  Your web service consumers will be a lot happier if you make this modest architectural change.

@Tom - Regarding your architectural advice... I would agree that, if I were structuring this in a database, I would do it like you suggest, but I am not.  We are developing a mobile app and having all of the data returned at once will make our users a lot more happy than repeated service calls back to the server for the roll data.  Currently, we return a variable number of of dye lots that have a variable number of rolls associated with them.  An example is below.  Repeated service calls to return this data would be highly undesirable causing numerous pauses while repeatedly fetching the roll data for each tap on a dye lot. On the slow end of average, I would be looking at 200ms to fetch and return the data on the LAN. I worry about that someone on a substandard data connection in the middle of nowhere which we have a lot of where the company that I work for services.  Latency is my enemy here.  I want to provide as much responsiveness as possible for our users when they get to certain points in the app.  In this use case, it would seem that spending a tiny bit more time gathering the data and sending all of it at once is the better choice for the end user experience.  Thanks for your suggestion though!  I think that I might test removing the DEPENDING clause all together... 

The XML looks like this:

<!--SOAP 1.1 Message - Powered by Xcentrisity™-->

<env:Envelope xmlns:env="schemas.xmlsoap.org/.../">

   <env:Body env:encodingStyle="schemas.xmlsoap.org/.../" xmlns:xsi="www.w3.org/.../XMLSchema-instance" xmlns:xsd="www.w3.org/.../XMLSchema" xmlns:soapenc="schemas.xmlsoap.org/.../">

      <bdl:StockCheckResponse xmlns:bdl="tempuri.org/.../">

         <result>FoundRecords</result>

         <dyelot-count>2</dyelot-count>

         <ea-ft-uom>EA</ea-ft-uom>

         <ea-ft-qty-total>705</ea-ft-qty-total>

         <sf-sy-uom>SF</sf-sy-uom>

         <sf-sy-qty-total>0</sf-sy-qty-total>

         <dyelot-records>

            <dyelot-recordsItems>

               <dye-lot>5550</dye-lot>

               <d-ea-ft-qty-total>1</d-ea-ft-qty-total>

               <d-sf-sy-qty-total>0</d-sf-sy-qty-total>

               <roll-count>1</roll-count>

               <roll-records>

                  <roll-recordsItems>

                     <roll-number>C3095</roll-number>

                     <ea-ft-qty>1</ea-ft-qty>

                     <sf-sy-qty>0</sf-sy-qty>

                     <last-measure/>

                  </roll-recordsItems>

               </roll-records>

            </dyelot-recordsItems>

            <dyelot-recordsItems>

               <dye-lot>55501</dye-lot>

               <d-ea-ft-qty-total>704</d-ea-ft-qty-total>

               <d-sf-sy-qty-total>0</d-sf-sy-qty-total>

               <roll-count>3</roll-count>

               <roll-records>

                  <roll-recordsItems>

                     <roll-number>00614</roll-number>

                     <ea-ft-qty>140</ea-ft-qty>

                     <sf-sy-qty>0</sf-sy-qty>

                     <last-measure/>

                  </roll-recordsItems>

                  <roll-recordsItems>

                     <roll-number>80918</roll-number>

                     <ea-ft-qty>264</ea-ft-qty>

                     <sf-sy-qty>0</sf-sy-qty>

                     <last-measure/>

                  </roll-recordsItems>

                  <roll-recordsItems>

                     <roll-number>09058</roll-number>

                     <ea-ft-qty>300</ea-ft-qty>

                     <sf-sy-qty>0</sf-sy-qty>

                     <last-measure/>

                  </roll-recordsItems>

               </roll-records>

            </dyelot-recordsItems>

         </dyelot-records>

      </bdl:StockCheckResponse>

   </env:Body>

</env:Envelope>

My next suggestion would be to de-nest the rolls from the dyelots, and add enough information into each roll occurrence so that the consuming application can properly associate the roll occurrences that belong to each dyelot occurrence.  Since you are designing with latency in mind, sending a bit of redundant data may not cause any additional perceived delay.

              05 OUTPUT-PARAMETERS.
                 07 RESULT                 PIC X(80).
                 07 DYELOT-COUNT           PIC 9(03).
                 07 EA-FT-UOM              PIC X(03).
                 07 EA-FT-QTY-TOTAL        PIC X(15).
                 07 SF-SY-UOM              PIC X(03).
                 07 SF-SY-QTY-TOTAL        PIC X(15).
                 07 DYELOT-RECORDS OCCURS MAX-DYELOT-RECORDS.
                    09 DYE-LOT             PIC X(12).
                    09 D-EA-FT-QTY-TOTAL   PIC X(15).
                    09 D-SF-SY-QTY-TOTAL   PIC X(15).
                    09 ROLL-COUNT          PIC 9(03).
                 07 DYELOT-RECORDS--COUNT  PIC 9(03).
                 07 ROLL-RECORDS OCCURS MAX-ROLL-RECORDS.
                    09 ROLL-NUMBER         PIC X(06).
                    09 ROLL-DYELOT         PIC X(12).
                    09 EA-FT-QTY           PIC X(10).
                    09 SF-SY-QTY           PIC X(10).
                    09 LAST-MEASURE        PIC X(10).
                 07 ROLL-RECORDS--COUNT    PIC 9(03).

This places a bit more burden on the web service consumer.

Have you tested how much of your latency is associated with setting up the connection, versus actual request latency after the connection exists?  If your mobile client does not drop the connection between web service calls, several roundtrips might be avoided and your performance may be acceptable.

In testing whether your nested scheme works as you wish, we would need to see the WSDL (to make sure the schema contained in the WSDL is correct) as well as the output result.  If the WSDL is wrong, then the (presumed) code generator that is using the WSDL to generate client side code will be misled.

If the request input parameters are simple enough (we haven't seen your input parameters), then you might want to consider a web service that is not SOAP based, but rather returns JSON.  The third tutorial teaches this possibility, using query parameters for the input parameters.  JSON has some desirable attributes, in that it is a bit more self describing, obviating the need for a WSDL.  It also tends to be a bit more terse.  You can also have as much complexity as you desire in the returned structure, with the tradeoff being a bit more work on the XSLT that is returning the structure (mostly to avoid sending 'empty' objects = Roll records in this situation).  Finally, there a lot of client-side widget sets out there that understand JSON.

The WSDL appears to generate decently.  We have not had any major issues with parsing the response.  We did have an issue where single dye lots or single rolls did not generate an array of a single element but returned as an object with properties mirroring the output parameters items.  I am not sure if this was from the WSDL or the PHP json_enocode().  However, this was easy enough to test for and was coded around.  You can see the difference here:

0: Object

       d-ea-ft-qty-total: "1"

       d-sf-sy-qty-total: "0"

       dye-lot: "5550"

       roll-count: "1"

       roll-records: Object

              roll-recordsItems: Object

                     ea-ft-qty: "1"

                     last-measure: ""

                     roll-number: "C3095"

                     sf-sy-qty: "0"

1: Object

       d-ea-ft-qty-total: "704"

       d-sf-sy-qty-total: "0"

       dye-lot: "55501"

       roll-count: "3"

       roll-records: Object

              roll-recordsItems: Array[3]

                     0: Object

                           ea-ft-qty: "140"

                           last-measure: ""

                           roll-number: "00614"

                           sf-sy-qty: "0"

                     1: Object

                           ea-ft-qty: "264"

                           last-measure: ""

                           roll-number: "80918"

                           sf-sy-qty: "0"

                     2: Object

                           ea-ft-qty: "300"

                           last-measure: ""

                           roll-number: "09058"

                           sf-sy-qty: "0"

We are using Ionic and Angular to build this app. Technically. we are using JSON for this already since the result is gotten from a request to a PHP script that uses json_encode() on a result from a PHP Soap call. The WSDL, as it appears in SoapUI, is pasted below.  There are some other things happening in the PHP in addition to doing the SOAP call. So, I would be pretty reluctant to remove that layer.  Input is very simple in this case.  Two fields are required of the service.  That section of my working storage is below as well.

We are really just entering into the more rigorous testing phase shortly.  External network testing is to also begin shortly.  I am not sure how the connections will be handled as of yet.  

I did test with a set up similar to your suggested one.  I was told that coding things on the client side got a little kludgy especially since it is in Javascript. I think that if we had been doing this in straight Java/Objective-C, things would have been a lot nicer in the handling of an object as would be returned by your suggested layout.  As it is now, I can consider that kind of layout and pre-process the response in the PHP script if that would help something somehow.

I really do appreciate the feedback that you are providing.  Thanks again for your assistance and ideas!

The WSDL appears to generate decently.  We have not had any major issues with parsing the response.  We did have an issue where single dye lots or single rolls did not generate an array of a single element but returned as an object with properties mirroring the output parameters items.  I am not sure if this was from the WSDL or the PHP json_enocode().  However, this was easy enough to test for and was coded around.  You can see the difference here:

0: Object

       d-ea-ft-qty-total: "1"

       d-sf-sy-qty-total: "0"

       dye-lot: "5550"

       roll-count: "1"

       roll-records: Object

              roll-recordsItems: Object

                     ea-ft-qty: "1"

                     last-measure: ""

                     roll-number: "C3095"

                     sf-sy-qty: "0"

1: Object

       d-ea-ft-qty-total: "704"

       d-sf-sy-qty-total: "0"

       dye-lot: "55501"

       roll-count: "3"

       roll-records: Object

              roll-recordsItems: Array[3]

                     0: Object

                           ea-ft-qty: "140"

                           last-measure: ""

                           roll-number: "00614"

                           sf-sy-qty: "0"

                     1: Object

                           ea-ft-qty: "264"

                           last-measure: ""

                           roll-number: "80918"

                           sf-sy-qty: "0"

                     2: Object

                           ea-ft-qty: "300"

                           last-measure: ""

                           roll-number: "09058"

                           sf-sy-qty: "0"

We are using Ionic and Angular to build this app. Technically. we are using JSON for this already since the result is gotten from a request to a PHP script that uses json_encode() on a result from a PHP Soap call. The WSDL, as it appears in SoapUI, is pasted below.  There are some other things happening in the PHP in addition to doing the SOAP call. So, I would be pretty reluctant to remove that layer.  Input is very simple in this case.  Two fields are required of the service.  That section of my working storage is below as well.

We are really just entering into the more rigorous testing phase shortly.  External network testing is to also begin shortly.  I am not sure how the connections will be handled as of yet.  

I did test with a set up similar to your suggested one.  I was told that coding things on the client side got a little kludgy especially since it is in Javascript. I think that if we had been doing this in straight Java/Objective-C, things would have been a lot nicer in the handling of an object as would be returned by your suggested layout.  As it is now, I can consider that kind of layout and pre-process the response in the PHP script if that would help something somehow.

I really do appreciate the feedback that you are providing.  Thanks again for your assistance and ideas!

Assuming the cobol_to_soap.xsl is constructing the response as it is described in the WSDL, then I think an array of one item will come out as just that.  Easy enough to see in the resulting response's XML.

Going back to the concept of having the BIS web service create JSON...  I am not any kind of expert on PHP, but I can see in the docs that there is a JSON_decode() function.  Given that the PHP script is going to deliver JSON anyway, it may seem a bit more maintainable in the future to be dealing with JSON both for input and output.  For some the choice between SOAP and JSON is a matter of religious conviction.  I would rather use what works well.  My assumption is that JSON_encode() will probably do a faithful encode of a structure that has been built by JSON_decode().  The only drawback to a JSON-based web service is that the input parameters are pretty much constrained to what you can do with URL-encoding (I. e. emulation of a HTML form being POSTed).  The company_json.xsl form the BIS tutorial is a reasonable starting point for an XSL that returns a specific JSON structure.  I have some fondness for jTable (an extension of jQueryUI), which has a specific JSON design pattern that it uses repeatedly, so I designed a more general purpose XSL for jTable.  I would be happy to help should SOAP become intractable.