IC SunsetThe developerWorks Connections Platform is now in read-only mode and content is only available for viewing. No new wiki pages, posts, or messages may be added. Please see our FAQ for more information. The developerWorks Connections platform will officially shut down on March 31, 2020 and content will no longer be available. More details available on our FAQ. (Read in Japanese.)
Topic
  • 4 replies
  • Latest Post - ‏2017-07-17T13:43:20Z by Boris L
Boris L
Boris L
8 Posts

Pinned topic z/OS Connect EE API toolkit supported with Open Beta?

‏2017-06-27T16:47:19Z |

Hi,

We are trying to get ">32k support in IMS" to work with the Open Beta. We've seen in the V3 manuals that "IMS Explorer for Development" is not supported, instead we'd have to use "z/OS Connect EE API toolkit". Can we use this with the Open Beta, too?

When we are trying to set up a sample application that uses >32k structures with "IMS Explorer for Development", we get an error: "java.lang.Exception: Unexpected TranMsg format ERROR. Second field is expected to be a 2 byte ZZ field, but field NNAME is size: 350"

Which versions of IMS Explorer for Development and IBM z/OS Connect EE API Editor are required to exploit the new ">32k feature"?

Regards,

Boris

  • cipresso
    cipresso
    24 Posts
    ACCEPTED ANSWER

    Re: z/OS Connect EE API toolkit supported with Open Beta?

    ‏2017-07-05T15:16:39Z  

    Hi Boris,

    The V3 API toolkit is not for use with the current Open Beta (which is compatible with V2 API editor).  Regarding your usability concerns, the >32K support does not have a representation in the UI/tooling yet.  When the >32K support has an explicit representation in the UI, the usability will be improved.  The general rule regarding whether you need LLZZTRANCODE is based on the maximum size of the first segment/data structure.  If the maximum size of the first segment/data structure exceeds the amount of data that can fit in the segment, then LDS assumed, and LLZZTRANCODE should not appear in the structure.  You have given an interesting bit of feedback and that is you need the tooling to help you determine whether you're working with a program that needs LDS or not.  In working with a couple clients, they considered it an inconvenience to have to include LLZZ or LLZZTRANCODE in data structures whether the scenario is LDS or not.  RFE 106155 was opened to document this and we'll need to consider the implications of the request as well.

    You can find the V3 LDS documentation here.

    Thanks, --Ted

    Updated on 2017-07-05T19:06:19Z at 2017-07-05T19:06:19Z by cipresso
  • cipresso
    cipresso
    24 Posts

    Re: z/OS Connect EE API toolkit supported with Open Beta?

    ‏2017-06-27T18:29:57Z  

    Hi Boris,

    The >32K support, originally delivered in the final V2-based Open Beta, has been corrected based on client feedback and delivered as a supported feature in V3. Since V3 has just been released, I don't believe a V3-based Open Beta is available yet.  As you noticed, the V3 API toolkit (formerly API Edtor) must be used to create IMS services on a V3 server.  Ideally you would use V3 of both the toolkit and server to leverage the 32K support.

    Looking back at >32K in the V2-based Open Beta, it was delivered without changes to the IMS Explorer for rapid validation of the programming model, so you may see errors logged regarding the LL, ZZ, or TRANCODE fields which will not be present in the data structure you use for >32K, therefore these errors can be ignored.  The IMS Service Provider on the server automatically switches to "Large Data Structure" or LDS mode when given an input or output transaction message layout where the input or output layout consists of one segment that can exceed 32K.  A client did find a defect where LDS mode was not enabling when the segment was variable length (e.g., OCCURS DEPENDING ON).  This was fixed in V3.

    If you want to continue to try with the V2-based Open Beta, it only requires the latest IMS Explorer available (3.2.1.9); the V2 API Editor is not required unless you want to create an API on top of the >32K service.

    --Ted

  • Boris L
    Boris L
    8 Posts

    Re: z/OS Connect EE API toolkit supported with Open Beta?

    ‏2017-06-29T17:26:16Z  
    • cipresso
    • ‏2017-06-27T18:29:57Z

    Hi Boris,

    The >32K support, originally delivered in the final V2-based Open Beta, has been corrected based on client feedback and delivered as a supported feature in V3. Since V3 has just been released, I don't believe a V3-based Open Beta is available yet.  As you noticed, the V3 API toolkit (formerly API Edtor) must be used to create IMS services on a V3 server.  Ideally you would use V3 of both the toolkit and server to leverage the 32K support.

    Looking back at >32K in the V2-based Open Beta, it was delivered without changes to the IMS Explorer for rapid validation of the programming model, so you may see errors logged regarding the LL, ZZ, or TRANCODE fields which will not be present in the data structure you use for >32K, therefore these errors can be ignored.  The IMS Service Provider on the server automatically switches to "Large Data Structure" or LDS mode when given an input or output transaction message layout where the input or output layout consists of one segment that can exceed 32K.  A client did find a defect where LDS mode was not enabling when the segment was variable length (e.g., OCCURS DEPENDING ON).  This was fixed in V3.

    If you want to continue to try with the V2-based Open Beta, it only requires the latest IMS Explorer available (3.2.1.9); the V2 API Editor is not required unless you want to create an API on top of the >32K service.

    --Ted

    Hi Ted,

    Thank you for your answers.

    So we can't use the new "API toolkit" along with the V2-based Open Beta, correct?

    The LDS problem you mentioned brings up an interesting point: we understand that, if we are creating an IMS service with a structure <32k in size, an LLZZTRANCODE prefix is *required*, and when a structure >32k is used, LLZZTRANCODE must be omitted (that difference in behaviour strikes us as a bit odd). When working with a variable-length structure (i.e. OCCURS DEPENDING ON or REFERS), at service creation time we can't know whether the request will be >32k or <32k, so do we need a LLZZTRANCODE prefix in the structure or not?

    Regards,

    Boris

    Updated on 2017-06-29T17:27:52Z at 2017-06-29T17:27:52Z by Boris L
  • cipresso
    cipresso
    24 Posts

    Re: z/OS Connect EE API toolkit supported with Open Beta?

    ‏2017-07-05T15:16:39Z  

    Hi Boris,

    The V3 API toolkit is not for use with the current Open Beta (which is compatible with V2 API editor).  Regarding your usability concerns, the >32K support does not have a representation in the UI/tooling yet.  When the >32K support has an explicit representation in the UI, the usability will be improved.  The general rule regarding whether you need LLZZTRANCODE is based on the maximum size of the first segment/data structure.  If the maximum size of the first segment/data structure exceeds the amount of data that can fit in the segment, then LDS assumed, and LLZZTRANCODE should not appear in the structure.  You have given an interesting bit of feedback and that is you need the tooling to help you determine whether you're working with a program that needs LDS or not.  In working with a couple clients, they considered it an inconvenience to have to include LLZZ or LLZZTRANCODE in data structures whether the scenario is LDS or not.  RFE 106155 was opened to document this and we'll need to consider the implications of the request as well.

    You can find the V3 LDS documentation here.

    Thanks, --Ted

    Updated on 2017-07-05T19:06:19Z at 2017-07-05T19:06:19Z by cipresso
  • Boris L
    Boris L
    8 Posts

    Re: z/OS Connect EE API toolkit supported with Open Beta?

    ‏2017-07-17T13:43:20Z  
    • cipresso
    • ‏2017-07-05T15:16:39Z

    Hi Boris,

    The V3 API toolkit is not for use with the current Open Beta (which is compatible with V2 API editor).  Regarding your usability concerns, the >32K support does not have a representation in the UI/tooling yet.  When the >32K support has an explicit representation in the UI, the usability will be improved.  The general rule regarding whether you need LLZZTRANCODE is based on the maximum size of the first segment/data structure.  If the maximum size of the first segment/data structure exceeds the amount of data that can fit in the segment, then LDS assumed, and LLZZTRANCODE should not appear in the structure.  You have given an interesting bit of feedback and that is you need the tooling to help you determine whether you're working with a program that needs LDS or not.  In working with a couple clients, they considered it an inconvenience to have to include LLZZ or LLZZTRANCODE in data structures whether the scenario is LDS or not.  RFE 106155 was opened to document this and we'll need to consider the implications of the request as well.

    You can find the V3 LDS documentation here.

    Thanks, --Ted

    Thank you, Ted, for the clarification on the usage of the "API Toolkit".

    The "rules" on deciding whether an LLZZTRANCODE prefix is required or not are now also clear to us, and our initial tests confirm the behavior that you described, although we do have some issues with dynamic structures (I'll open a new topic for that).

    We fully agree on RFE 106155 and I have voted for that.