On Mon, 30 Jan 2017 09:27:36 -0800, Tom Ross <[email protected]>
wrote:
> )? (Msg IGYOS4021-W)
>
>>We are beginning the transition to COBOL V5.2 from V4.2 and exploring the n=
>>ew options available for debugging.
>
>>We just discovered that the INITCHECK option is incompatible with OPTIMIZE(=
>>0). Using both options generates this warning-level message:
>
>>IGYOS4021-W The "INITCHECK" option was discarded due to option conflict r=
>>esolution. The "OPTIMIZE(0)" option took precedence.=20
>
>>There is no restriction documented for INITCHECK in the V5.2 Programmer's G=
>>uide and no mention of this incompatibility in the section on incompatible =
>>compiler options either.
>
>INITCHECK takes advantage of control flow analysis done by OPT(1|2) and so
>cannot function with OPT(0).
>
>We are trying to be aggressive about back-fitting migration assisting new
>features but we can't update all documentation everywhere. The Knowledge
>Center is updated every few months and is your best bet. If we are missing
>documentation, please open a PMR and we wil fix it!
>
But the documentation (both the Migration Guide and Programming reference for
both V6.1 and V5.2) was updated. The even refer to the relevant APARs, and are
included in "Summary of changes..." dated September 2016.
What those documentary changes don't include is the mutual-exclusivity between
OPT(0) and INITCHECK.
Are we to read anything into this?:
"|
|
|
|
|
|
| v Invalid data might get different results with COBOL V5 and V6 than in
earlier
COBOL versions. Some users have found that they get different results with the
newer compilers than with previous compilers, and/or that they get different
results with different OPT settings. These are normally due to invalid data that
is brought into the COBOL programs at run time. One way to find out whether
your programs will have this problem is to follow our new migration
recommendation:
|
| 1. Compile with SSRANGE, ZONECHECK, and INITCHECK, and then run
regression tests.
| 2. Check whether there are any problems:
|
|
| – If no problems found, recompile with NOSSRANGE, NOZONECHECK,
and NOINITCHECK, and then do a small test before moving into
production.
|
|
| – If problems are found, then either correct the programs and or data, or in
the case of bad data in zoned decimal data items, use the ZONEDATA
compiler option to tolerate the invalid data.
|
|
|
Note: The INITCHECK option is available in Enterprise COBOL V6.1 with the
PTF for APAR PI68226 installed, and available in Enterprise COBOL V5.2 with
the PTF for APAR PI69197 installed."
Gives "our new migration recommendation", yet also fails to mention that
OPT(1/2) must be used to have INITCHECK.
Also, despite the reference in the final paragraph to V5.2, the V5.2 Migration
Guide does not contain INITCHECK in the "recommendation". Is that because with
V5.2, as Peter Farley has discovered, there seems to be a "memory usage" issue
(hopefully alleviated by V6.1)? Or is it the recommendation, just not included
in the actual text.
Looking at the KnowledgeCentre, no reference to INITCHECK is made in the
migration recommendations:
Enterprise COBOL for z/OS
Enterprise COBOL for z/OS 6.1.0
Migration Guide
Migration strategies
Migration recommendations to Enterprise COBOL V5 and V6
"Compile with SSRANGE, ZONECHECK, and OPT(0) for initial code changes and unit
tests."
If the KC is the go-to place for current documentation, does this mean the
recommendation in the V6.1 Migration Guide is withdrawn, returning to the V5.1
recommendation? Or is the V6.1 OK, the KC not, and V5.2 missing the current
recommendation. Or is the V6.1 correct, the V5.2 correct, and the KC wrong?
There also seems to be an issue with a previous PMR on the subject anyway.
Apparently the claim was (paraphrase) "we could do INITCHECK at OPT(0), but
since OPT(0) is for compiler performance, INITCHECK would slow things down and
defeat that". Now you say that INITCHECK is a side-effect of the work already
done for OPT(1/2) so fat chance it could have been done at OPT(0) and just
wasn't for "compiler performance".
In the interim to disentangling the existing documentation, could you clarify
"our new migration recommendation" for V5.2 and V6.1, please? The KC casts
further knots on the subject at the moment, so turning to that is just not
giving an answer that can be used directly.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
