CA IDMS IUA EIUA

Expand all | Collapse all

[IDMS-L] S0C4 batch cobol IDMS

  • 1.  [IDMS-L] S0C4 batch cobol IDMS

    Posted 08-16-2007 06: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
    "What compiler and version are you using John?

    Chris Wood
    Alberta Department of Energy
    CANADA


  • 2.  Re:[IDMS-L] S0C4 batch cobol IDMS

    Posted 08-16-2007 06: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
    "SSRANGE specifies whether debug code for subscript and index range checking
    is placed in the object module. The key here is that it is for debugging
    purposes and shouldn't be put in place in production as it adds to cpu,
    reducing performance, but from a debugging perspective, it's a good tool.

    Linda Casey
    Managing Member
    Run Right, LLC.


  • 3.  Re:[IDMS-L] S0C4 batch cobol IDMS

    Posted 08-16-2007 06: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 out! That was pretty funny.

    FYI:
    Yes, the programmer said occurs clauses are internal tables.

    Production has these parms.
    // PARM.COBOL='RENT,DYNAM,OPTIMIZE(FULL),NOADV,LIB,MAP,XREF,OFFSET'

    Test does not. I will remove them from production for this one program
    and see what happens.


  • 4.  Re:[IDMS-L] S0C4 batch cobol IDMS

    Posted 08-16-2007 06: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
    Calling IDMSCOM
    "Hi all,

    In preparation for our Data Warehouse project, I'm using the Journal
    analyzer to re-assemble my records of interest into non-spanned records.
    (Thank you DBMS and CA!).

    Now for my problem - Compressed records. Compressed records show up in
    the journal as, well, compressed records. Because we're not using IDMS
    to get the record, IDMSDCOM is not being called - naturally.

    Has anyone written COBOL code to call IDMSDCOM to de-compress compressed
    records? If so, are you willing to share? Please?

    Thanks much,

    Dick

    Richard Pierce
    (617) 973-8911
    richard.pierce@state.ma.us
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Calling IDMSCOM
    "If nobody else comes up with a solution, let me know and I'll pass along
    some considerations/hints/caveats as to how to construct a solution. The
    basic problem lies in how COMP/DCOM are called (not with standard calling
    conventions).

    Hopefully somebody else has already done this and can share their solution
    with you. One or more vendors have.

    Don Casey


  • 5.  Re:[IDMS-L] S0C4 batch cobol IDMS

    Posted 08-16-2007 06: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
    "FYI
    I compiled this program without optimize like it is in test and dev.
    It made quite a difference in load module size. Without optimize it is
    pretty large but I'm guessing it'll probably run now without the S0C4?

    BPR5RRQ$ 00010170 < Prod w/optimize
    BPR5RRQ1 000639C0 < Prod wo/optimize


  • 6.  Re:[IDMS-L] S0C4 batch cobol IDMS

    Posted 08-16-2007 06: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
    "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.


  • 7.  Re:Re: [IDMS-L] S0C4 batch cobol IDMS

    Posted 08-16-2007 06:59 AM
    Kirk - I never heard of SSRANGE. What or where is that?


  • 8.  Re: [IDMS-L] S0C4 batch cobol IDMS

    Posted 08-16-2007 06:59 AM
    Kirk - I never heard of SSRANGE. What or where is that?


  • 9.  Re:Re: [IDMS-L] S0C4 batch cobol IDMS

    Posted 08-16-2007 06:59 AM
    Kirk - I never heard of SSRANGE. What or where is that?