IDMS

Expand all | Collapse all

S0C4 batch cobol IDMS

  • 1.  S0C4 batch cobol IDMS

    Posted Aug 16, 2007 05:06 AM
    Hi Listers:



    I'll tell 'ya, I get some real beauts.



    We have a batch cobol program that runs in our dev and test environment
    fine. In production it gets a S0C4 sometimes.

    Other times it runs. When we insert the dev loadlib in front of the
    production loadlib we run it again and it works!!!



    When I migrate this program from dev to test the cobol compiler step
    always returns 00. When I migrate it to production

    the cobol compiler step always returns an 04.



    The difference in the production cobol compile is this message but it is
    only a warning:

    8022 IGYOP3091-W Code from ""procedure name 4162-STRIP-PO-PT"" to ""EXIT
    (line 8049.01)"" can never be executed and was therefore discarded.



    The only difference between production with dev and test environments is
    that I have a zap trap in rhdccsa from level2. but L2 has assured me
    this has no affect as far as the batch job goes. That makes sense being
    the S0C4 is in the batch region. This batch job is a local mode
    retrieval job.



    Does anyone have any clues or suggestions? Is a compiler option causing
    this? Is it a cobol system parameter? Anything else?

    We are 15.0 sp5.



    TIA



    J. Wayne Doneker

    BAE Systems

    York Pa.,

    717 225 8109

    John.Doneker@baesystems.com


    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: S0C4 batch cobol IDMS
    "Kirk - I never heard of SSRANGE. What or where is that?


  • 2.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 07:28 AM
    I have recently had the same problem, however it was in DB2. The
    development program ran fine all the time and when it was moved to
    production that program abended with a SOC4. It all turned out to be
    the difference in the compile options between test and production. In
    production we had Optimize turn on which removed some of the code that
    would never be executed. Like your warning message. When we finally
    got the programmer to run it in test with the same options as in
    production the error occurred there as well. We had the programmer turn
    on SSRANGE to find out what internal table was being over written. That
    exposed the error immediately, corrected the internal table and the
    problem is fixed. I would look very carefully at the compile options
    and run with the production options in test to see if you can duplicate
    it.

    Kirk Miller
    UAL


  • 3.  Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 07:28 AM
    I have recently had the same problem, however it was in DB2. The
    development program ran fine all the time and when it was moved to
    production that program abended with a SOC4. It all turned out to be
    the difference in the compile options between test and production. In
    production we had Optimize turn on which removed some of the code that
    would never be executed. Like your warning message. When we finally
    got the programmer to run it in test with the same options as in
    production the error occurred there as well. We had the programmer turn
    on SSRANGE to find out what internal table was being over written. That
    exposed the error immediately, corrected the internal table and the
    problem is fixed. I would look very carefully at the compile options
    and run with the production options in test to see if you can duplicate
    it.

    Kirk Miller
    UAL


  • 4.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 07:28 AM
    I have recently had the same problem, however it was in DB2. The
    development program ran fine all the time and when it was moved to
    production that program abended with a SOC4. It all turned out to be
    the difference in the compile options between test and production. In
    production we had Optimize turn on which removed some of the code that
    would never be executed. Like your warning message. When we finally
    got the programmer to run it in test with the same options as in
    production the error occurred there as well. We had the programmer turn
    on SSRANGE to find out what internal table was being over written. That
    exposed the error immediately, corrected the internal table and the
    problem is fixed. I would look very carefully at the compile options
    and run with the production options in test to see if you can duplicate
    it.

    Kirk Miller
    UAL


  • 5.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 07:28 AM
    I have recently had the same problem, however it was in DB2. The
    development program ran fine all the time and when it was moved to
    production that program abended with a SOC4. It all turned out to be
    the difference in the compile options between test and production. In
    production we had Optimize turn on which removed some of the code that
    would never be executed. Like your warning message. When we finally
    got the programmer to run it in test with the same options as in
    production the error occurred there as well. We had the programmer turn
    on SSRANGE to find out what internal table was being over written. That
    exposed the error immediately, corrected the internal table and the
    problem is fixed. I would look very carefully at the compile options
    and run with the production options in test to see if you can duplicate
    it.

    Kirk Miller
    UAL


  • 6.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 07:28 AM
    I have recently had the same problem, however it was in DB2. The
    development program ran fine all the time and when it was moved to
    production that program abended with a SOC4. It all turned out to be
    the difference in the compile options between test and production. In
    production we had Optimize turn on which removed some of the code that
    would never be executed. Like your warning message. When we finally
    got the programmer to run it in test with the same options as in
    production the error occurred there as well. We had the programmer turn
    on SSRANGE to find out what internal table was being over written. That
    exposed the error immediately, corrected the internal table and the
    problem is fixed. I would look very carefully at the compile options
    and run with the production options in test to see if you can duplicate
    it.

    Kirk Miller
    UAL


  • 7.  Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 08:29 AM
    SSRANGE is a compile option used to check subscript and index ranges for
    internal tables. Here is some information from a manual I found on
    Google.

    SSRANGE

    SSRANGE option syntax
    .-NOSSRANGE-.
    -----------------------------------------------------------><
    '-SSRANGE---'



    Default is: NOSSRANGE

    Abbreviations are: SSR|NOSSR

    Use SSRANGE to generate code that checks if subscripts (including ALL
    subscripts) or indexes try to reference an area outside the region of
    the table. Each subscript or index is not individually checked for
    validity; rather, the effective address is checked to ensure that it
    does not cause a reference outside the region of the table.
    Variable-length items will also be checked to ensure that the reference
    is within their maximum defined length.

    Reference modification expressions will be checked to ensure that:

    The reference modification starting position is greater than or equal to
    1.
    The reference modification starting position is not greater than the
    current length of the subject data item.
    The reference modification length value (if specified) is greater than
    or equal to 1.
    The reference modification starting position and length value (if
    specified) do not reference an area beyond the end of the subject data
    item.
    If SSRANGE is in effect at compile time, the range-checking code is
    generated. You can inhibit range checking by specifying CHECK(OFF) as a
    run-time option. This leaves range-checking code dormant in the object
    code. Optionally, the range-checking code can be used to aid in
    resolving any unexpected errors without recompilation.

    If an out-of-range condition is detected, an error message is displayed
    and the program is terminated.

    Remember: You will get range checking only if you compile your program
    with the SSRANGE option and run it with the CHECK(ON) run-time option.

    I am assuming that the program you are running has internal tables and
    that is where your problem is coming from. Since it works some times in
    production and not others it is probably related to the data.

    Kirk out.


  • 8.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 08:29 AM
    SSRANGE is a compile option used to check subscript and index ranges for
    internal tables. Here is some information from a manual I found on
    Google.

    SSRANGE

    SSRANGE option syntax
    .-NOSSRANGE-.
    -----------------------------------------------------------><
    '-SSRANGE---'



    Default is: NOSSRANGE

    Abbreviations are: SSR|NOSSR

    Use SSRANGE to generate code that checks if subscripts (including ALL
    subscripts) or indexes try to reference an area outside the region of
    the table. Each subscript or index is not individually checked for
    validity; rather, the effective address is checked to ensure that it
    does not cause a reference outside the region of the table.
    Variable-length items will also be checked to ensure that the reference
    is within their maximum defined length.

    Reference modification expressions will be checked to ensure that:

    The reference modification starting position is greater than or equal to
    1.
    The reference modification starting position is not greater than the
    current length of the subject data item.
    The reference modification length value (if specified) is greater than
    or equal to 1.
    The reference modification starting position and length value (if
    specified) do not reference an area beyond the end of the subject data
    item.
    If SSRANGE is in effect at compile time, the range-checking code is
    generated. You can inhibit range checking by specifying CHECK(OFF) as a
    run-time option. This leaves range-checking code dormant in the object
    code. Optionally, the range-checking code can be used to aid in
    resolving any unexpected errors without recompilation.

    If an out-of-range condition is detected, an error message is displayed
    and the program is terminated.

    Remember: You will get range checking only if you compile your program
    with the SSRANGE option and run it with the CHECK(ON) run-time option.

    I am assuming that the program you are running has internal tables and
    that is where your problem is coming from. Since it works some times in
    production and not others it is probably related to the data.

    Kirk out.


  • 9.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 05:19 PM
    What kind of region are you running with? Try increasing it and see what happens.

    Mark Grindstaff





  • 10.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 05:19 PM
    What kind of region are you running with? Try increasing it and see what
    happens.

    Mark Grindstaff





  • 11.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 05:19 PM
    What kind of region are you running with? Try increasing it and see what
    happens.

    Mark Grindstaff





  • 12.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 05:19 PM
    What kind of region are you running with? Try increasing it and see what
    happens.

    Mark Grindstaff





  • 13.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 05:19 PM
    What kind of region are you running with? Try increasing it and see what happens.

    Mark Grindstaff





  • 14.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 05:19 PM
    What kind of region are you running with? Try increasing it and see what
    happens.

    Mark Grindstaff





  • 15.  Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 05:19 PM
    What kind of region are you running with? Try increasing it and see what
    happens.

    Mark Grindstaff





  • 16.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 05:19 PM
    What kind of region are you running with? Try increasing it and see what
    happens.

    Mark Grindstaff





  • 17.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 16, 2007 05:19 PM
    What kind of region are you running with? Try increasing it and see what
    happens.

    Mark Grindstaff





  • 18.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 03:43 AM
    OK, let me add my 2 cents worth and possibly hang my ignorance out for everyone to have a good laugh over.

    In our shop, we do not allow the RENT or DYNAM parms to be used for Batch COBOL - thus NORENT and NODYNAM. We use RENT for DC-COBOL and I think that implies DYNAM. It has something to do with whether a program is callable by more than one run unit at a time and whether changeable storage is allocated to the program (batch) or the run unit (DC). I know these have had something to do with S0C4 abends in the past but, of course, the past is pretty fuzzy. Maybe more coffee would help at this point or maybe a COBOL compile manual.

    Gene over and out.


  • 19.  Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 03:43 AM
    OK, let me add my 2 cents worth and possibly hang my ignorance out for everyone to have a good laugh over.

    In our shop, we do not allow the RENT or DYNAM parms to be used for Batch COBOL - thus NORENT and NODYNAM. We use RENT for DC-COBOL and I think that implies DYNAM. It has something to do with whether a program is callable by more than one run unit at a time and whether changeable storage is allocated to the program (batch) or the run unit (DC). I know these have had something to do with S0C4 abends in the past but, of course, the past is pretty fuzzy. Maybe more coffee would help at this point or maybe a COBOL compile manual.

    Gene over and out.


  • 20.  Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 03:53 AM
    Thanks Peter, we have NONCICS already in the cobol system parameters.

    What I did was I compiled the program and removed the cobol compile options to make it compile like dev and test for just this one program giving us problems.

    If I still have problems I'll have to check out the SSRANGE option Kirk spoke about.

    Meanwhile, in the output, this is what I removed and then resubmitted the compile.
    // PARM.COBOL='RENT,DYNAM,OPTIMIZE(FULL),NOADV,LIB,MAP,XREF,OFFSET'

    This time I did not get the RC=04 in the cobol compile step like before.

    It ran fine last night. We'll see.

    Thanks to all for your great responses.


  • 21.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 03:53 AM
    Thanks Peter, we have NONCICS already in the cobol system parameters.

    What I did was I compiled the program and removed the cobol compile options to make it compile like dev and test for just this one program giving us problems.

    If I still have problems I'll have to check out the SSRANGE option Kirk spoke about.

    Meanwhile, in the output, this is what I removed and then resubmitted the compile.
    // PARM.COBOL='RENT,DYNAM,OPTIMIZE(FULL),NOADV,LIB,MAP,XREF,OFFSET'

    This time I did not get the RC=04 in the cobol compile step like before.

    It ran fine last night. We'll see.

    Thanks to all for your great responses.


  • 22.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 03:53 AM
    Thanks Peter, we have NONCICS already in the cobol system parameters.

    What I did was I compiled the program and removed the cobol compile options to make it compile like dev and test for just this one program giving us problems.

    If I still have problems I'll have to check out the SSRANGE option Kirk spoke about.

    Meanwhile, in the output, this is what I removed and then resubmitted the compile.
    // PARM.COBOL='RENT,DYNAM,OPTIMIZE(FULL),NOADV,LIB,MAP,XREF,OFFSET'

    This time I did not get the RC=04 in the cobol compile step like before.

    It ran fine last night. We'll see.

    Thanks to all for your great responses.


  • 23.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 03:53 AM
    Thanks Peter, we have NONCICS already in the cobol system parameters.

    What I did was I compiled the program and removed the cobol compile options to make it compile like dev and test for just this one program giving us problems.

    If I still have problems I'll have to check out the SSRANGE option Kirk spoke about.

    Meanwhile, in the output, this is what I removed and then resubmitted the compile.
    // PARM.COBOL='RENT,DYNAM,OPTIMIZE(FULL),NOADV,LIB,MAP,XREF,OFFSET'

    This time I did not get the RC=04 in the cobol compile step like before.

    It ran fine last night. We'll see.

    Thanks to all for your great responses.


  • 24.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 03:56 AM
    In the cobol compiler before the 'IBM Enterprise COBOL for z/OS '
    you have to put in the compiler option:

    NOCICS

    When you don't have this parameter your cobol batchjobs can randomly abend with a S04c abend.

    So a S04c abend can be restarted perfectly and the next time you run the job you have the S04c back again.

    gl

    Peter van de Ven Atos Origin

    * Tel: +31(0)40 2142211 +31(0)622567218
    * Fax: +31(0)402144423


    ü 51 25' 43.86"" 5 31'50.36""


  • 25.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 03:56 AM
    In the cobol compiler before the 'IBM Enterprise COBOL for z/OS '
    you have to put in the compiler option:

    NOCICS

    When you don't have this parameter your cobol batchjobs can randomly abend with a S04c abend.

    So a S04c abend can be restarted perfectly and the next time you run the job you have the S04c back again.

    gl

    Peter van de Ven Atos Origin

    * Tel: +31(0)40 2142211 +31(0)622567218
    * Fax: +31(0)402144423


    ü 51 25' 43.86"" 5 31'50.36""


  • 26.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 03:56 AM
    In the cobol compiler before the 'IBM Enterprise COBOL for z/OS '
    you have to put in the compiler option:

    NOCICS

    When you don't have this parameter your cobol batchjobs can randomly abend with a S04c abend.

    So a S04c abend can be restarted perfectly and the next time you run the job you have the S04c back again.

    gl

    Peter van de Ven Atos Origin

    * Tel: +31(0)40 2142211 +31(0)622567218
    * Fax: +31(0)402144423


    ü 51 25' 43.86"" 5 31'50.36""


  • 27.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 03:56 AM
    In the cobol compiler before the 'IBM Enterprise COBOL for z/OS '
    you have to put in the compiler option:

    NOCICS

    When you don't have this parameter your cobol batchjobs can randomly abend with a S04c abend.

    So a S04c abend can be restarted perfectly and the next time you run the job you have the S04c back again.

    gl

    Peter van de Ven Atos Origin

    * Tel: +31(0)40 2142211 +31(0)622567218
    * Fax: +31(0)402144423


    ü 51 25' 43.86"" 5 31'50.36""


  • 28.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 03:56 AM
    In the cobol compiler before the 'IBM Enterprise COBOL for z/OS '
    you have to put in the compiler option:

    NOCICS

    When you don't have this parameter your cobol batchjobs can randomly abend with a S04c abend.

    So a S04c abend can be restarted perfectly and the next time you run the job you have the S04c back again.

    gl

    Peter van de Ven Atos Origin

    * Tel: +31(0)40 2142211 +31(0)622567218
    * Fax: +31(0)402144423


    ü 51 25' 43.86"" 5 31'50.36""


  • 29.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 03:56 AM
    In the cobol compiler before the 'IBM Enterprise COBOL for z/OS '
    you have to put in the compiler option:

    NOCICS

    When you don't have this parameter your cobol batchjobs can randomly abend with a S04c abend.

    So a S04c abend can be restarted perfectly and the next time you run the job you have the S04c back again.

    gl

    Peter van de Ven Atos Origin

    * Tel: +31(0)40 2142211 +31(0)622567218
    * Fax: +31(0)402144423


    ü 51 25' 43.86"" 5 31'50.36""


  • 30.  Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 03:56 AM
    In the cobol compiler before the 'IBM Enterprise COBOL for z/OS '
    you have to put in the compiler option:

    NOCICS

    When you don't have this parameter your cobol batchjobs can randomly abend with a S04c abend.

    So a S04c abend can be restarted perfectly and the next time you run the job you have the S04c back again.

    gl

    Peter van de Ven Atos Origin

    * Tel: +31(0)40 2142211 +31(0)622567218
    * Fax: +31(0)402144423


    ü 51 25' 43.86"" 5 31'50.36""


  • 31.  Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 05:51 AM
    What also can give this problem is the OPTIMIZE(FULL) option.
    Change this to OPTIMIZE(STD) .
    btw what compiler / version are you using?

    Peter van de Ven Atos Origin

    * Tel: +31(0)40 2142211 +31(0)622567218
    * Fax: +31(0)402144423


    ü 51 25' 43.86"" 5 31'50.36""


  • 32.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 09:47 AM
    The jobcard says region=0m so that should be fine and there is no
    override of the region in the step. S0 0m should be fine.


  • 33.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 09:47 AM
    The jobcard says region=0m so that should be fine and there is no
    override of the region in the step. S0 0m should be fine.


  • 34.  Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 09:47 AM
    The jobcard says region=0m so that should be fine and there is no
    override of the region in the step. S0 0m should be fine.


  • 35.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 09:47 AM
    The jobcard says region=0m so that should be fine and there is no override of the region in the step. S0 0m should be fine.


  • 36.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 09:47 AM
    The jobcard says region=0m so that should be fine and there is no
    override of the region in the step. S0 0m should be fine.


  • 37.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 09:47 AM
    The jobcard says region=0m so that should be fine and there is no
    override of the region in the step. S0 0m should be fine.


  • 38.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 09:47 AM
    The jobcard says region=0m so that should be fine and there is no override of the region in the step. S0 0m should be fine.


  • 39.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 09:47 AM
    The jobcard says region=0m so that should be fine and there is no
    override of the region in the step. S0 0m should be fine.


  • 40.  Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 10:53 AM
    Thanks Peter, we have NONCICS already in the cobol system parameters.

    What I did was I compiled the program and removed the cobol compile options to make it compile like dev and test for just this one program giving us problems.

    If I still have problems I'll have to check out the SSRANGE option Kirk spoke about.

    Meanwhile, in the output, this is what I removed and then resubmitted the compile.
    // PARM.COBOL='RENT,DYNAM,OPTIMIZE(FULL),NOADV,LIB,MAP,XREF,OFFSET'

    This time I did not get the RC=04 in the cobol compile step like before.

    It ran fine last night. We'll see.

    Thanks to all for your great responses.


  • 41.  Re:Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 10:53 AM
    Thanks Peter, we have NONCICS already in the cobol system parameters.

    What I did was I compiled the program and removed the cobol compile options to make it compile like dev and test for just this one program giving us problems.

    If I still have problems I'll have to check out the SSRANGE option Kirk spoke about.

    Meanwhile, in the output, this is what I removed and then resubmitted the compile.
    // PARM.COBOL='RENT,DYNAM,OPTIMIZE(FULL),NOADV,LIB,MAP,XREF,OFFSET'

    This time I did not get the RC=04 in the cobol compile step like before.

    It ran fine last night. We'll see.

    Thanks to all for your great responses.


  • 42.  Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 11:43 AM
    OK, let me add my 2 cents worth and possibly hang my ignorance out for everyone to have a good laugh over.

    In our shop, we do not allow the RENT or DYNAM parms to be used for Batch COBOL - thus NORENT and NODYNAM. We use RENT for DC-COBOL and I think that implies DYNAM. It has something to do with whether a program is callable by more than one run unit at a time and whether changeable storage is allocated to the program (batch) or the run unit (DC). I know these have had something to do with S0C4 abends in the past but, of course, the past is pretty fuzzy. Maybe more coffee would help at this point or maybe a COBOL compile manual.

    Gene over and out.


  • 43.  Re: S0C4 batch cobol IDMS

    Posted Aug 17, 2007 12:27 PM
    The DYNAM parameter refers to the way in which sub-programs are linked to the calling module. Long long ago, all programs were linked into a single load module and all external references were resolved at compile/link time. This meant that whenever a change was made to a sub-program, the calling module had to be relinked to include the called module. This maintenance problem was resolved with the introduction of dynamic linkage. For a long time, the default linkage was ""static"" which was compile time linkage. Now the default is Dynamic which means that the external modules and referencing is resolved at run time. Errors in references will result in 0C4's.

    RENT refers to the wuse of storage and what the default method of variable settings are. RENT should have no effect in 0C4's. It will only affect the value of the variables at run time, thus addressing issues are not a problem.

    Vince Jensen
    Alberta Health.