IBM Z and LinuxONE Languages

Languages

Languages

Broad range of supported development languages and tools allows to transform software delivery practices.

 View Only
Expand all | Collapse all

Conditional setting of return-code behavior after z/OS upgrade

  • 1.  Conditional setting of return-code behavior after z/OS upgrade

    Posted Thu May 21, 2020 12:59 AM
    Edited by Dan Zhang Thu May 28, 2020 05:46 AM

    Disclaimer: This post is migrated from IBM Developer Answers that is no longer in use. Its original author is Sanvan, posted on Jan 31, 2018.

    Since upgrading z/OS from v1.13 to v2.1, the final return-code of a step running in production is behaving differently.

    We have a cobol program that sets the return-code conditionally. This is executed in our STEP0010. This program also contains DB2 and Report Writer. It was compiled under Cobol v3.4 and is running under Cobol v4.2.

    Example: IF A = 0 MOVE 4 TO RETURN-CODE END-IF.

    The next step is bypassed when the return-code of the previous step is not zero.

    Example: //STEP0020 EXEC PGM=IEBGENER,COND=(0,NE,STEP0010)

    Since our upgrade of z/OS from v1.13 to v2.1, we have seen our STEP0010 end with an RC 0 despite the condition having been met to set the return-code to 4. Pulling the program down to a test environment, I can see the return-code being set to 4 and displaying the return-code just before GOBACK shows it is set to 4 but the job output will show the step as ending in 0 and the next step then executes.

    Could this behavior be related to our upgrade of z/OS?

    Thank you, Sandy


    -----------------------------------------------------
    Question asked by Sanvan on Jan 31, 2018
    -----------------------------------------------------





  • 2.  RE: Conditional setting of return-code behavior after z/OS upgrade

    Posted Thu May 21, 2020 01:02 AM
    Edited by Dan Zhang Thu May 28, 2020 05:51 AM

    Hi Sandy,

    This sounds like a more involved problem that would be best handled in a PMR. The problem may be an input error. If this were a z/OS or COBOL compiler issue, it would be widespread, but this is the first report we've seen of a problem like this.

    Thanks for bringing this to our attention, and I hope this can be addressed in a PMR.


    Regards, Nicole


    -----------------------------------------------------
    Answered by Nicole Trudeau on
    -----------------------------------------------------