COBOL

Expand all | Collapse all

SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

  • 1.  SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

    Posted Wed June 17, 2020 01:51 AM
    Disclaimer: This post is migrated from IBM Developer Answers that is no longer in use. Its original author is Pramtcs, posted on Jan 02, 2019.

    Hi, Our site has recently upgraded from COBOL Enterprise v5.2 to v6.1. Since the upgrade, I am getting a SOC1 abend for my programs which was working fine with v5.2. Since the data movements are strict in V6.1, I have also tried with a program without any data movements just to make sure that it is not the reason for the abend.The program also failed with SOC1. Any ideas on what could be issue?

    IEA995I SYMPTOM DUMP OUTPUT
    SYSTEM COMPLETION CODE=0C1 REASON CODE=00000001
    TIME=14.03.17 SEQ=05257 CPU=0000 ASID=0034
    PSW AT TIME OF ERROR 078D0000 8DD0081A ILC 2 INTC 01
    ACTIVE LOAD MODULE ADDRESS=0DD00000 OFFSET=0000081A NAME=TTEST
    DATA AT PSW 0DD00814 - 0DD00948 00000000 0DD008D8

    -----------------------------------------------------
    Question asked by Pramtcs on Jan 02, 2019
    -----------------------------------------------------



  • 2.  RE: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

    Posted Wed June 17, 2020 01:53 AM
    Edited by Yuan Jie Song Wed June 17, 2020 01:53 AM

    What ARCH level are you compiling with, and what machine are you getting the abends on? It's likely that the ARCH level is too high for the machine you're running on (e.g. ARCH(11) or higher on a zEC12), so the compiler is generating instructions for a newer machine, as specified by ARCH, and the older machine on which you run the code doesn't know what to do with instructions it doesn't understand or support.

    If your ARCH is set correctly for the target machine or lower, please open a PMR.

    -----------------------------------------------------
    Answered by Mike Chase on Jan 02, 2019
    -----------------------------------------------------







  • 3.  RE: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

    Posted Wed June 17, 2020 01:55 AM
    Edited by Yuan Jie Song Wed June 17, 2020 01:55 AM

    Given the ILC 2 (instruction length code) and the DATA AT PSW of x'0000', it isn't an ARCH() problem but a bad branch or an overlay. Do get a system dump, and open a PMR as suggested previously. You can get the system dump via an override to the problem step of:

    //IDIOFF   DD  DUMMY   no Fault Analyzer`
    //CEEOPTS  DD *
    TER(UAIMM),TRAP(ON,NOSPIE),DYNDUMP({dsn-prefix},FORCE,TDUMP)
    /*
    

    {dsn-prefix} will be used to form the initial part of the dump dataset name, and can be up to 26 characters in length; the high level qualifier should be one the userid under which the job is running can write to.

    -----------------------------------------------
    Answered by brataj on Jan 02, 2019
    -----------------------------------------------







  • 4.  RE: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

    IBM Champion
    Posted Thu April 08, 2021 10:28 AM
    Are you able to add the LIST parameter to the compilation step of the JCL?  If so, you'll get the Assembler listing generated by the COBOL Compiler.  You can then go to the offset of X'81A' to see the encoded FOUR-BYTE instruction.  Find out which instruction it is and let me know.  The ILC is actually B'10' according to the first hex digit of the second set of four bytes of the PSW.  This is 2 and you must multiply it by 2 to get the actual abending instruction length which is 4.  I can't imagine that the Operation Exception is something that you yourself can't fix.

    ------------------------------
    Geoffrey Decker
    ------------------------------



  • 5.  RE: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

    Posted Fri April 09, 2021 02:09 PM
    Geoffrey, the ILC hasn't been in the first two bits of the second word of the PSW since System/360 (24-bit addressing only) days. These days it's stored by the processor in its PSA.
    I should clarify that in my previous response when I said DATA AT PSW of x'0000' I meant the data 2 bytes ahead of the PSW ie. the failing "instruction".

    ------------------------------
    Bernie Rataj
    Advisory Technical Support
    ------------------------------



  • 6.  RE: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

    IBM Champion
    Posted Fri April 09, 2021 02:22 PM
    Hi,

    Yes, sorry to have assumed it was the BC Mode PSW.  We see the simulated 24-bit addressing BC mode when dumps are produced by ABENDs while running in a 64-bit addressing environment.  Thank you for clarifying.

    Geoffrey D. Decker

    Instructor | ACM Faculty Sponsor

    Department of Computer Science | College of Liberal Arts and Sciences

    Psychology-Computer Science 463 | DeKalb, Illinois 60115

    815-753-0378 (dept.)

    gdecker@niu.edu

    faculty.cs.niu.edu/~decker/

     

     






  • 7.  RE: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

    Posted Mon April 12, 2021 10:32 AM
    "INSUFFICIENT DATA FOR MEANINGFUL ANSWER" (Isaac Asimov, The Last Question)

    I and another programmer successfully converted an entire application library of over 3,000 COBOL programs from versions 4.3 and earlier to version 6.1. The project was done quickly, quietly, efficiently and effectively with virtually no outage to our production environment and with very few errors and missteps along the way.

    When you say your programs that were working fine under v5.2 are now getting S0C1 abends under v6.1, a few questions come to mind:

    1) Is this problem occurring on every program that is compiled under the new version?
    2) Are your load libraries PDSEs (A.K.A. libraries)?
    3) Have you verified your compilation, link edit and execution library concatenations?
    4) Are there any warning message in the compilations?
    5) Do the abends occur before a single line of code is successfully executed?

    Debugging systemic abends is always harder than debugging programs and this certainly sounds like a systemic issue. Any additional information that you can provide about how you got where you are and what you have tried so far will go a long way toward helping someone else spot anything you may have missed.

    ------------------------------
    Joseph Rohrbach
    ------------------------------



  • 8.  RE: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

    Posted Tue May 11, 2021 01:17 PM
    Hi Joseph -

    Good to see a person who has done similar activity. We are also in process of converting 2000+ COBOL programs from 4.2 to 6.2
    Our system in Z14. ARCH option is not there in 4.2. Which ARCH is preferred in this 6.2. Our system somewhat stable till now and not worried on performance. TO avoid risk of any invalid data we are preferring ARCH(7). Will ARCH(12) fail if any invalid data presents? Please share your thoughts and advise , that we can follow during this process.

    ------------------------------
    priyadarasini Esvar
    ------------------------------



  • 9.  RE: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

    Posted Tue May 11, 2021 02:34 PM
    Priyadarasini, the ARCH compiler option relates to the machine instructions generated by the compiler. The higher the option, the newer and faster the instructions used. You choose the ARCH level based on your machine, not the compiler version. On a z14 machine such as you have, ARCH(12) is recommended. The only risk is if the compiled code is run on a lower architecture machine, in which case it may abend. In any case, the validity of the data will not be changed by ARCH(12) vs. ARCH(7). Does that help?

    ------------------------------
    Ever onward,
    Joseph Rohrbach
    ------------------------------



  • 10.  RE: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

    Posted Tue May 11, 2021 02:51 PM
    Hi Priyadarasini,

    Using ARCH(7) isn't a way to avoid invalid data issues. There can possibly be invalid data issues (differences in behaviour between COBOL 4 and COBOL 6) at any ARCH or OPT level in COBOL 6. ARCH(7) may reduce the chance of issue, at the cost of performance, but it isn't guaranteed to eliminate all invalid data issues.

    If the ONLY machines you are using, in both production and disaster recovery, are z14s, then ARCH(12) is the correct option. If you have older machines as well, then you need to set ARCH to target the oldest machine on which your program will run.

    I also highly recommend you register for an upcoming migration webinar or view a recording; you can do both from here: COBOL migration and performance webinars


    Thanks,
    Mike


    ------------------------------
    Mike Chase
    Enterprise COBOL Developer
    mike.chase@ca.ibm.com
    ------------------------------



  • 11.  RE: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

    Posted Wed May 12, 2021 01:08 AM
    Thanks a lot Mike and Joseph for your response. We would go with ARCH(12).

    ------------------------------
    Priyadarasini Esvar Technical Manager - Mainframe
    ------------------------------



  • 12.  RE: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

    Posted Wed May 12, 2021 08:10 AM
    Priya,

    While ARH(12) is correct for the z14 as Mike and Joseph have suggested , we found in a shop with some 17,000 programs, many from the 1990s, that ARCH(12) can cause a number of difficulties with non-numeric data in numeric fields, zero subscripts, or in evaluating complex IF statements where although one condition is TRUE, other conditions in the statement cause an error.  There are a number of options to ameliorate these problems, but you may want to consider ARCH(11).  We use ARCH(12) for new programs, and for those undergoing major revision, but if you are changing 2 lines in a 20,000 line module, you may end up "correcting" 100 other lines.

    Granted, all code should be fixed and there really is no excuse for bad coding, but the truth is that past IBM compilers allowed it for many years.  Tom "Captain COBOL" Ross stated that IBM did not test negative conditions, and he was surprised that there was so much bad coding.  But what happens if you don't follow the rules?  Well, you would expect the compiler or the run-time environment to catch the problem, but they  did not.  ARCH(12) with OPT(2) will increase performance, especially in batch modules, but don't expect the conversion to be quick.  

    BTW, you might consider COBOL 6.3 which has a lot of new features, plus support for the z15s.  You can use ARCH(12) with your z14s, but you will position yourself to move forward.  Of course the z16 will be out soon based on IBMs past hardware upgrade timelines, so be ready!

    ------------------------------
    Jon Butler
    ------------------------------



  • 13.  RE: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1

    Posted Wed May 12, 2021 11:01 AM
    Jon, using ARCH(11) instead of ARCH(12) to avoid invalid data issues is not a good recommendation. As I stated in my previous message, invalid data can result in different behaviour at ANY ARCH level. Using ARCH(11) will certainly avoid some problems that ARCH(12) has (because different instruction sequences chosen at different ARCH levels, or different OPT levels for that matter, will behave differently when there is invalid data), but there may also be problems that ARCH(11) has and ARCH(12) doesn't.

    There are only two reasonable strategies to deal with invalid data
    - Detect it with NUMCHECK,PARMCHECK,INITCHECK, and SSRANGE, and then correct it
    - Use INVDATA (if you update to the April 2021 PTF for 6.2 and May 2021 PTF for 6.3; use ZONEDATA if you haven't updated yet) to get some amount of compatibility with COBOL 4, noting that there is not and will not be a full COBOL 4 compatibility mode, you will still have to test thoroughly, and if you happen to find a difference in behaviour that INVDATA doesn't yet address, open a Case with us

    Changing ARCH levels to try to avoid invalid data issues is not a viable strategy, and as the Enterprise COBOL developer who has spent the most time addressing migration issues between COBOL 4 and COBOL 6 and who has been giving our public migration webinars for several years, I cannot recommend this.


    The compiler generally can't catch invalid data. The compiler is only aware of one program at a time, so it can't validate data outside the program. Prior to COBOL 5, the compiler didn't have the analysis capabilities to look at the flow of data through the entire application to find places where invalid data was used; we only added that in the last  couple years as an additional capability of our NUMCHECK option (and even then, this was done for performance reasons, so that we could remove checks that were redundant - checking a data item that hadn't changed since a previous check - or where the data was known good or known bad). As for runtime checking, we never thought to add it prior to the COBOL 5.1 GA as it would hurt performance and no client suggested invalid data was an issue we should check. Besides, between the COBOL language itself (IS NUMERIC and ON SIZE ERROR) and IBM additions (SSRANGE), there have been ways for clients to detect invalid data since well before COBOL 5.1.

    ------------------------------
    Mike Chase
    Enterprise COBOL Developer
    mike.chase@ca.ibm.com
    ------------------------------