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------------------------------
Original Message:
Sent: Wed May 12, 2021 08:09 AM
From: Jon Butler
Subject: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1
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
Original Message:
Sent: Wed May 12, 2021 01:07 AM
From: Priyadarasini Esvar
Subject: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1
Thanks a lot Mike and Joseph for your response. We would go with ARCH(12).
------------------------------
Priyadarasini Esvar Technical Manager - Mainframe
Original Message:
Sent: Tue May 11, 2021 02:51 PM
From: Mike Chase
Subject: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1
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
Original Message:
Sent: Tue May 11, 2021 01:17 PM
From: Priyadarasini Esvar
Subject: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1
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
Original Message:
Sent: Mon April 12, 2021 09:32 AM
From: Joseph Rohrbach
Subject: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1
"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
Original Message:
Sent: Wed June 17, 2020 01:51 AM
From: Yuan Jie Song
Subject: SOC1 Abend in COBOL program execution after upgrading to Enterpise COBOL V6.1
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
-----------------------------------------------------