Topic
  • 3 replies
  • Latest Post - ‏2011-12-16T17:56:03Z by DLJONES
SystemAdmin
SystemAdmin
23 Posts

Pinned topic Occurs Depending On?

‏2011-02-08T16:58:25Z |
Should we expect an application that has "occurs depending on" in the commarea to work with this SupportPac? We get it to generate, but when we try to execute it, we get a P8HF abend.

Thanks,
Steve
Updated on 2011-12-16T17:56:03Z at 2011-12-16T17:56:03Z by DLJONES
  • SystemAdmin
    SystemAdmin
    23 Posts

    Re: Occurs Depending On?

    ‏2011-02-08T20:17:01Z  
    Our developers eliminated the "occurs depending on", and were able to get the application to work. So I'm expecting to hear that ODO is not supported in this SupportPac. It would be great if you could confirm that, and let us know if that is also the case with the Feature Pack available for CICS/TS 4.1.

    Thanks,
    Steve
  • JonathanPLawrence
    JonathanPLawrence
    30 Posts

    Re: Occurs Depending On?

    ‏2011-02-10T16:08:27Z  
    Hi Steve,

    The support for COBOL records provided with the CA1S SupportPac and the CICS Dynamic Scripting Feature
    is based on the JZOS COBOL Record Generator coupled with the PHP Java™ Bridge from Project Zero.
    In fact, any mechanism for building and interpreting COBOL records in PHP or Java could be used,
    which could be completely custom written in PHP or Java, or exploit another tool for example
    Rational Developer.

    We packaged and documented the JZOS solution with the SupportPac and the Feature for convenience only.
    So, the question is really whether the JZOS record generator supports ODO, and the answer is yes
    with some limitations.
    The following explanations (with some sample code) come from around page 15/16 of the
    JZOS COBOL Record Generator User's Guide Version 2.2.1, packaged with the SupportPac:

    "The OCCURS DEPENDING ON clause is supported, but the object (size) must be set before
    any fields following the field are accessed. Once set, the object size may not be changed on a
    given record instance. An OCCURS DEPENDING ON clause may not be nested within
    another OCCURS clause."

    "When a generated class contains an OCCURS DEPENDING ON clause, a special
    constructor is generated which allows a record to be built on existing data or a new byte
    array. A zero-argument constructor is not generated, since the size of the underlying byte
    array is variable and cannot be pre-determined."

    In fact the zero-argument constructor is not overridden and hidden, so can still be used, but this
    will not work, as you have found. Instead a pre-allocated byte[] of the correct length must be passed
    to the record constructor. This can be achieved in a number of ways - one is to define a byte[] factory
    class in Java with a method such as the following:

    public static byte[] createByteArray(int size) {
    return new bytesize;
    }

    This is used in PHP via the PHP-Java Bridge to create an empty commarea as follows
    (you do need to know what length is required):

    // Call CICS program to get list of items
    $factory = new JavaClass("mypackage.Factory");
    $comm = $factory->createByteArray(1608);

    Next, the empty commarea is passed to the JZOS record constructor:

    $commAreaIn = new JPLLIBCO($comm,FALSE); // FALSE indicates ODO objects not set.

    $commAreaIn->setLibRequestType('LL');
    $commAreaIn->setLibItemCount(0); // Set ODO object

    // Pass commarea to CICS program:
    $program = new CICSProgram("JPLLIBPO");
    try {
    $program->link($commAreaIn);
    } catch (CICSException $e) {
    echo $e->getMessage();
    exit;
    }

    // Must create NEW record object to change ODO objects...
    $commAreaOut = new JPLLIBCO($comm,TRUE); // TRUE = ODO objects already set.
    // Extract and check return code:
    $rc = $commAreaOut->getLibReturnCode();
    $items = $commAreaOut->getLibItemCount(); // Set != 0 by CICS program

    Note the additional requirement to create a new JZOS record object for the output commarea.
    This is so that new values for the ODO dimensions are registered, otherwise the pre-link values will
    be used. The programming model for JZOS records based on COBOL with ODO is somewhat different from
    those without ODO as noted above. It is also possible to use any other mechanism of your choice to
    build and interpret the COBOL records.

    Documentation for the PHP Java Bridge is available here, but note that the latest syntax enhancement
    for static members is not included with the SupportPac (but is in the Feature):
    http://www.projectzero.org/sMash/1.1.x/docs/zero.devguide.doc/zero.php/ZeroAdvancedPHPJavaBridge.html

    Jonathan Lawrence
    PHP Runtime Development
    IBM United Kingdom Limited.
  • DLJONES
    DLJONES
    1 Post

    Re: Occurs Depending On?

    ‏2011-12-16T17:56:03Z  
    Hi Steve,

    The support for COBOL records provided with the CA1S SupportPac and the CICS Dynamic Scripting Feature
    is based on the JZOS COBOL Record Generator coupled with the PHP Java™ Bridge from Project Zero.
    In fact, any mechanism for building and interpreting COBOL records in PHP or Java could be used,
    which could be completely custom written in PHP or Java, or exploit another tool for example
    Rational Developer.

    We packaged and documented the JZOS solution with the SupportPac and the Feature for convenience only.
    So, the question is really whether the JZOS record generator supports ODO, and the answer is yes
    with some limitations.
    The following explanations (with some sample code) come from around page 15/16 of the
    JZOS COBOL Record Generator User's Guide Version 2.2.1, packaged with the SupportPac:

    "The OCCURS DEPENDING ON clause is supported, but the object (size) must be set before
    any fields following the field are accessed. Once set, the object size may not be changed on a
    given record instance. An OCCURS DEPENDING ON clause may not be nested within
    another OCCURS clause."

    "When a generated class contains an OCCURS DEPENDING ON clause, a special
    constructor is generated which allows a record to be built on existing data or a new byte
    array. A zero-argument constructor is not generated, since the size of the underlying byte
    array is variable and cannot be pre-determined."

    In fact the zero-argument constructor is not overridden and hidden, so can still be used, but this
    will not work, as you have found. Instead a pre-allocated byte[] of the correct length must be passed
    to the record constructor. This can be achieved in a number of ways - one is to define a byte[] factory
    class in Java with a method such as the following:

    public static byte[] createByteArray(int size) {
    return new bytesize;
    }

    This is used in PHP via the PHP-Java Bridge to create an empty commarea as follows
    (you do need to know what length is required):

    // Call CICS program to get list of items
    $factory = new JavaClass("mypackage.Factory");
    $comm = $factory->createByteArray(1608);

    Next, the empty commarea is passed to the JZOS record constructor:

    $commAreaIn = new JPLLIBCO($comm,FALSE); // FALSE indicates ODO objects not set.

    $commAreaIn->setLibRequestType('LL');
    $commAreaIn->setLibItemCount(0); // Set ODO object

    // Pass commarea to CICS program:
    $program = new CICSProgram("JPLLIBPO");
    try {
    $program->link($commAreaIn);
    } catch (CICSException $e) {
    echo $e->getMessage();
    exit;
    }

    // Must create NEW record object to change ODO objects...
    $commAreaOut = new JPLLIBCO($comm,TRUE); // TRUE = ODO objects already set.
    // Extract and check return code:
    $rc = $commAreaOut->getLibReturnCode();
    $items = $commAreaOut->getLibItemCount(); // Set != 0 by CICS program

    Note the additional requirement to create a new JZOS record object for the output commarea.
    This is so that new values for the ODO dimensions are registered, otherwise the pre-link values will
    be used. The programming model for JZOS records based on COBOL with ODO is somewhat different from
    those without ODO as noted above. It is also possible to use any other mechanism of your choice to
    build and interpret the COBOL records.

    Documentation for the PHP Java Bridge is available here, but note that the latest syntax enhancement
    for static members is not included with the SupportPac (but is in the Feature):
    http://www.projectzero.org/sMash/1.1.x/docs/zero.devguide.doc/zero.php/ZeroAdvancedPHPJavaBridge.html

    Jonathan Lawrence
    PHP Runtime Development
    IBM United Kingdom Limited.
    We've recently installed the Dynamic Scripting Feature Pack, and I have a question regarding the use of occurs depending on.

    "Instead a pre-allocated byte[] of the correct length must be passed
    to the record constructor"

    Here, you've determine the length you want is 1608:
    $comm = $factory->createByteArray(1608);

    My question is the correct lenght of WHAT must be passed to the record constructor?