Uploaded by Jason Haines

COBOL 6 Migration Webinar - May 11, 2021

advertisement
Migrating To
IBM Enterprise COBOL 6
Mike Chase
mike.chase@ca.ibm.com
Compiler Optimization Developer
Contents
• The what and why of COBOL migration
• Speeding Migration by Using COBOL 6
and ABO together
• A brief history of COBOL compilers on z/OS
• What is different about COBOL 6 migration
• Migration Pitfalls
• Best practices for COBOL 6 migration
• How to prepare for COBOL 6 before you
begin migration
• Resources
© 2019 IBM Corporation
2
The what and why
of COBOL migration
© 2019 IBM Corporation
3
What is migration?
Migration: Updating your build compiler to a later version, including required source, option,
testing and environment changes.
▪
Migration does not mean recompilation
▪
Not all programs have to be, or will ever be, recompiled using the newer build compiler
▪
Migration is usually considered complete when all source programs changed at the source level
will use the newer build compiler and select programs have been recompiled
▪
After migration, many/most compiled programs will still have been built using older compilers.
▪
In this presentation, migration specifically refers to updating your build compiler from Enterprise
COBOL 4 or earlier to Enterprise COBOL 6
▪
Note: unless specified, anything said about COBOL 6 also applies to COBOL 5
© 2019 IBM Corporation
4
Why Migrate Your Build Compiler to IBM Enterprise COBOL 6?
▪
Performance: Enterprise COBOL 6 has advanced optimization and deep hardware exploitation of
the latest IBM mainframes to improve performance
▪
Reduce CPU time and service units to reduce MIPS and shorten batch windows
▪
Modernization: Leverage new COBOL language and productivity features
▪ JSON: Parse and Generate to work with JSON objects and RESTful APIs
▪ Conditional compilation
▪ New intrinsic functions
▪ 64-bit COBOL applications (COBOL 6.3)
▪ And a lot more…
▪
Support: End of support announced for Enterprise COBOL 4 and 5
▪ COBOL 4 has EOS date of April 2022
▪ COBOL 5 is EOS (since April 2020)
▪ Note that only the compilers are reaching EOS. The already-compiled modules use LE (part of
z/OS), not the compiler, and will continue to be supported in production as long as you’re using a
supported z/OS level
▪ There is no need to recompile everything
© 2019 IBM Corporation
5
What to recompile?
Not all your COBOL programs need to be recompiled
▪
Focus your migration effort on applications/programs under active development
▪ Don’t attempt to recompile everything without considering the necessity of migration and
the large amount of work required
▪ Instead, first analyze the development activity on your applications to determine the key
candidates for recompilation
▪ Applications/programs that are not regularly updated do not need to be
immediately recompiled
▪ To improve performance of these legacy applications use IBM Automatic Binary
Optimizer (ABO)
▪ ABO optimizes directly from the already compiled code and produces faster but
functionally equivalent optimized code → no source migration needed and
all the pitfalls of migration are avoided.
© 2019 IBM Corporation
6
IBM Automatic Binary Optimizer (ABO) for z/OS Quick High-Level Overview
ABO available since 2015 (ABO 1.1). Latest release is ABO 2.1
▪
ABO improves performance of already-compiled COBOL program modules
▪ Optimize directly from the compiled program
▪ Optimizes program modules compiled by VS COBOL II 1.3 through to Enterprise
COBOL 4.2 to target the latest IBM Z mainframes (up to z15)
▪ New technology is under development with the intent to extend ABO eligibility to
1
COBOL 6 compiled modules
▪ No source level migration or recompilation or options changes required
▪ None of the build compiler migration pitfalls or challenges are an issue when
using ABO
ABO
Optimized Program Binaries
(Latest z Systems)
Original Program Binaries
(Base ESA390)
https://www.ibm.com/us-en/marketplace/improved-cobol-performance
1
Any statements regarding IBM's future direction, intent or product plans
are subject to change or withdrawal without notice.
7
Speeding Migration
by using COBOL 6
and ABO together
© 2019 IBM Corporation
8
Using COBOL and Automatic Binary Optimizer now and in the future;
Maximizing Performance, ROI, and reducing migration effort
ABO
COBOL 6
No recompile plan
Recompile due to source
change or when
upgrading to COBOL 6
to improve performance
• Improve performance of
programs that have not been
recompiled in a long time
• Less testing effort
• Reduce scope of COBOL 6
migration
• Generate ROI to invest in
business-critical applications
and adoption of DevOps
80%
20%
•
•
•
•
•
Defect fixes
Refactoring
Modernization
New Programming features
Recompile for performance
80%
20%
Code without
business as usual recompile plan
Code that is actively under
development or maintenance
IBM Systems / Enterprise COBOL for z/OS client presentation/ January 2020/ © 2020 IBM Corporation
9
Using COBOL 6 and Automatic Binary Optimizer Together
Usage
ABO
Risk due to compiler migration
Improve performance, reduce CPU
usage – Source available
Yes, optimize modules directly
Yes: migration, recompilation and option
tuning required
Improve performance, reduce CPU
usage – Source not available
Yes, optimize modules directly
Not supported
Not supported
Change source and recompile and test
Not supported
Change source and recompile and test
Yes, optimized
modules interoperate
Not supported
Significantly less: no source risk,
optimize binaries directly
Detecting problems (e.g. invalid data)
requires a 2-step compile/test approach.
Fixes require source changes
Fix defects or implement new features
Modernize existing application with
latest language features to support
digital transformation
Improve performance of programs that
interoperate with OS/VS COBOL or
VS COBOL II NORES
Testing
© 2019 IBM Corporation
10
Client Story: Using ABO and COBOL 6
build compiler migration together
UnopolSai Assicurazioni
Solution: Systems
Software Industry: Insurance
Italian insurance company UnipolSai modernized its
application environment in two stages:
• Build compiler migration to Enterprise COBOL 6.2
for all applications under active development
Modernizing core business
applications for the digital age
• Deployed ABO to optimize the performance (10%)
of the remaining legacy CICS applications
Determined to deliver on growing demand for digital
services, Italian insurer UnipolSai Assicurazioni
wanted to bring its legacy applications into the
21st century.
“ IBM Automatic Binary Optimizer for z/OS enables us
to get the maximum value out of our IBM Z platform. It
means that even our oldest legacy applications can
harness the latest hardware facilities.”
Working with IBM, UnipolSai Assicurazioni
upgraded its COBOL code, improving performance,
increasing efficiency and making it easier for
developers to add exciting new features.
—Carlo Romanella, Chief Technical Officer, UnipolSai Assicurazioni
Read the full story here
11
A brief history of
COBOL compilers
on z/OS
© 2019 IBM Corporation
12
COBOL Compiler Migration: Historical Overview
Compiler
Front end*
Back End*
ABO Eligibility
OS/VS COBOL
74 Std
1st generation
No
VS COBOL II
85 Std (new)
2nd generation
(new)
Yes – ABO eligible
COBOL/370
85 Std (same)
2nd generation
(same)
Yes – ABO eligible
COBOL for OS/390 2
85 Std (same)
2nd generation
(same)
Yes – ABO eligible
COBOL for z/OS 3
85 Std (same)
2nd generation
(same)
Yes – ABO eligible
COBOL for z/OS 4
85 Std (same)
2nd generation
(same)
Yes – ABO eligible
COBOL for z/OS 5
85 Std (same)
Select 2002 Std
3rd generation
(new)
No
COBOL for z/OS 6
85 Std (same)
Select 2002 Std
3rd generation
(same)
No 1
*Compiler Terms:
• Front End handles parsing and language rules
• Back End handles optimization and code generation
1
13
New technology under development with
the intent to extend ABO eligibility to COBOL 6
compiled modules
Migration is needed across the red lines
because of infrastructure changes
▪ OS/VS COBOL to any later compiler is the
most difficult due to language change
▪ Migration from 2nd generation (COBOL 4)
to 3rd generation (COBOL 5/6) is less
difficult
▪ No Migration is required within a generation
(e.g. VS COBOL II to COBOL 4; COBOL 5
to 6)
COBOL 5/6 compiled programs do not
interoperate with OS/VS COBOL and VS COBOL
II NORES programs (ABO optimized modules do
interoperate with these programs)
COBOL Migration History
OS/VS COBOL → all newer versions
▪
Most difficult migration
▪
Source incompatibilities between 1974 COBOL Standard and 1985 COBOL Standard
▪
▪
Convert source with CCCA (COBOL and CICS/VS Command Level Conversion Aid;
Included with IBM Debug Tool)
New code generator with more accurate numeric results
VS COBOL II thru COBOL V2 with CMPR2 compiler option → newer version
up to COBOL 4
▪
Some source incompatibilities between 1974 COBOL Standard and 1985 COBOL Standard
▪
Easier than OS/VS COBOL migration, but still need to convert source using CCCA
© 2019 IBM Corporation
14
COBOL Migration History
VS COBOL II or later → Enterprise COBOL 4 or earlier
▪
Very easy migration
▪
Source is compatible
▪
Generated code is the same between versions
▪
© 2019 IBM Corporation
Even programs using invalid data will behave the same
15
What is different about
COBOL 6 migration?
© 2019 IBM Corporation
16
What is Different About Migration to COBOL 6?
Compile time differences
▪
COBOL 6 is built on new advanced optimization technology that requires significantly more time
and memory to compile programs (especially at higher optimization levels)
▪
About 20x more memory required at compile time
▪
More time required to compile a program
▪
5x to 12x, depending on optimization level, size and complexity of the source program and
the load/capacity of your build system
▪
More compiler work datasets (SYSUTx) required → use new IBM-supplied compile PROCs
▪
Compiler always uses some above the 2GB bar storage, so MEMLIMIT must be set to
non-zero value (we recommend the zOS default of 2 GB)
© 2019 IBM Corporation
17
What is Different About Migration to COBOL 6?
Run time differences – Possible behavioural changes
▪
Programs that have invalid code or data may behave differently when compiled by COBOL 6. These
programs may also behave differently when changing OPT and/or ARCH settings.
▪
Some existing compiler options such as NUMPROC(PFD) or TRUNC(OPT) may behave differently when
used with nonconforming data
▪
Assembly or other programs that depend on certain internal workings or data/code layout of the older
compilers or runtimes may no longer behave the same.
Run time differences – Environment and interoperability changes
▪
Executables must be in PDSE datasets.
▪
COBOL 6 programs cannot be mixed in an application with OS/VS COBOL programs or with VS COBOL
II NORES programs
▪
▪
These programs must be first migrated separately to a later version of COBOL, or use VS COBOL II
RES option, to be used with 6 programs
Other versions can be mixed. When mixing COBOL 4/earlier and COBOL 5/6, dynamic calls have the
best performance; with only COBOL 5/6 or only COBOL 4/earlier, static calls have the best performance
© 2019 IBM Corporation
18
What is Different About Migration to COBOL 6?
Bind time differences
▪
▪
Old IGZEBSTs (bootstrap/initialization routines) can cause problems for VS COBOL II programs mixed
with COBOL 6
▪
Link edit/bind time correction
▪
Will need effort to update VS COBOL II load libraries called dynamically if the programs in them
aren't being recompiled
AMODE 24: COBOL 6 support for AMODE 24 is mostly the same as COBOL 4, with some bind-time
differences:
▪
When a program object contains any of the following programs, the binder option RMODE(24) must
be specified:
▪
An Enterprise COBOL program that is compiled with the RMODE(24) or NORENT compiler
options.
▪
A VS COBOL II program that is compiled with the NORENT option.
▪
An assembler program that contains a CSECT with RMODE 24.
▪
Programs compiled with COBOL 4/earlier that run with AMODE 24 and statically call a COBOL
5+ program.
© 2019 IBM Corporation
19
Migration Pitfalls
What they are
How to Identify
How to tolerate/fix
© 2019 IBM Corporation
Migration Pitfalls: Invalid Code and Data Handling in COBOL 6
▪ Many customers migrating to COBOL 6 encounter migration problems as a result of COBOL
programs processing invalid code or data at run time
▪ This is the MAJOR migration challenge encountered and the one most costly and slow to
identify and fix
My program worked before! What changed in COBOL 6?
▪
Different generated instructions can process invalid code/data differently from programs
produced by previous compilers
▪
Over time invalid code/data combined with the specific generated instructions by the older
compiler resulted in specific behavior that eventually became the expected behavior.
▪
COBOL 6 generates new instructions that can result in different behavior when code/data is
invalid
Why doesn’t the compiler give error diagnostics for invalid data?
▪
Since the problem is caused by data values at run time or inter-program dependencies these are
not able to be found by a compiler
© 2019 IBM Corporation
21
Migration Pitfalls: Invalid Code and Data Handling in COBOL 6
How did we get here?
Why didn’t IBM enforce rules against invalid code & data for the past 30 years?
▪
IBM did not test for invalid code and data in general
▪ We had no idea of the level of ‘misuse’ of COBOL by customers
▪ Previous code generator hid many problems
▪
The COBOL Standard provided solutions for invalid numeric data
▪ i.e. IF NUMERIC, ON SIZE ERROR
▪
IBM provided solutions for invalid table processing
▪ i.e. SSRANGE
© 2019 IBM Corporation
22
Migration Pitfalls: Invalid Data Handling in COBOL 6
How did we get here?
The COBOL 6 migration issues caused by invalid data or parameter passing are:
▪ Invalid data in numeric USAGE DISPLAY data items
▪ Uses of TRUNC(OPT) or TRUNC(STD) with overpopulated binary data items (values
with more digits than are defined in the data definitions)
▪ Parameter/argument size mismatch
▪ Data items that are used before they're assigned a value
▪
All other known issues with invalid data causing differences in behavior between
compilers have been resolved in PTFs
Note: Make sure that all PTFs are applied to your compiler when you first install it,and
consider frequent updates via PTF for performance and new features! Only installing
z/OS RSU service is also a good way to go.
© 2019 IBM Corporation
23
Migration Pitfall #1
Invalid Data in Numeric
USAGE DISPLAY
Data Items
© 2019 IBM Corporation
24
Migration Pitfall #1: Invalid Data in Numeric USAGE DISPLAY data items
77 A1 PIC X(4) VALUE ’00 0’. *>
*>
*>
77 A2 REDEFINES A1 PIC 9(4). *>
PROCEDURE DIVISION.
IF A2 = ZERO
DISPLAY ’ZERO‘
ELSE
DISPLAY ’NOT ZERO‘
END-IF
x’F0F040F0’, third byte
has x’4’ for zone bits.
OK in PIC X, not valid in
PIC 9 USAGE DISPLAY
*> Compiler could do character
*> or numeric compare
Whether the program displays ‘ZERO’ or ‘NOT ZERO’ depends on the compiler options you use in COBOL
4 and earlier and in COBOL 6 and the specific code generated by COBOL 6 compared to COBOL 4
▪
▪
If A2 had valid data, numeric and character compares would be equivalent
▪
With the invalid data, a character compare would be not equal, numeric compare would remove zone
bits and compare equal
© 2019 IBM Corporation
25
Migration Pitfall #1: Invalid Data in Numeric USAGE DISPLAY data items
What is bad data?
Zoned decimal
Packed decimal
Not all arrangements of bits are
valid decimal values. Consider
the number -123. There are
multiple ways to represent it.
The programmer selects the
representation of a data item
using the PICTURE clause.
Ex: PIC S9(3)
Ex: PIC S9(3) COMP-3
F1 F2 D3
12 3D
This number has three
digits. They must be
between 0 and 9.
This number also has three
digits and a sign code.
However, it does not have
any zone bits.
Each of these representations
has constraints on what the
data can look like.
It also has a sign code. It
must be between A and F. In
this case, D means the
number is negative.
It also has zone bits. These
must always be F.
© 2018 IBM Corporation
26
Migration Pitfall #1: Invalid Data in Numeric USAGE DISPLAY data items
How to detect invalid data:
▪
Add IF NUMERIC checks to your code. Likely lots of code changes and very slow performance.
▪
Or compile and test with the NUMCHECK(ZON) compiler option to get a message or abend when a
USAGE DISPLAY data item is invalid
▪
NUMCHECK can also checked PACKED-DECIMAL or BINARY data
▪
▪
PAC or BIN suboptions
NUMCHECK is slower than NONUMCHECK
© 2019 IBM Corporation
27
Migration Pitfall #1: Invalid Data in Numeric USAGE DISPLAY data items
How to correct invalid data:
▪ Use NUMCHECK(ZON) to find the source of invalid data, and correct at the source
▪ Invalid value explicitly set through code (e.g. REDEFINES) → correct it
▪ Incorrect record description for file → use the correct one
▪ Group MOVEs → correct mismatch or use MOVE CORRESPONDING
▪ Value coming from another source →correct at the source or add IF NUMERIC test to
validate before use
How to tolerate bad data if you can’t fix it:
▪
Use INVDATA to cause the compiler to generate COBOL 4-compatible code
▪ New in April 2021 6.2 PTF and May 2021 6.3 PTF; replaces ZONEDATA
▪ May negatively affect performance
▪ Only for known cases; NOT a full COBOL 4 compatibility mode
© 2019 IBM Corporation
28
Migration Pitfall #1: Invalid Data in Numeric USAGE DISPLAY data items
What INVDATA and NUMPROC options should I use?
IBM recommends that all users ensure that they are using valid data and that they use NOINVDATA.
However, if you find that you are using invalid data at run time, and you do not have the resources to fix
your programs or systems so that you are using valid data at runtime…
In COBOL 4, I Used…
In COBOL 6, I Should Use…
ALL data VALID?
COBOL 4 NUMPROC
COBOL 6 NUMPROC
COBOL 6 INVDATA
Yes
NUMPROC(MIG)
NUMPROC(NOPFD)
NOINVDATA
Yes
NUMPROC(NOPFD)
NUMPROC(NOPFD)
NOINVDATA
Yes
NUMPROC(PFD)
NUMPROC(PFD)
NOINVDATA
No
NUMPROC(MIG)
NUMPROC(NOPFD)
INVDATA(FORCENUMCMP,NOCLEANSIGN)
No
NUMPROC(NOPFD)
NUMPROC(NOPFD)
INVDATA
No
NUMPROC(PFD)
NUMPROC(PFD)
INVDATA
* INVDATA with no suboptions defaults to NOFORCENUMCMP,CLEANSIGN
© 2019 IBM Corporation
29
Migration Pitfall #1: Invalid Data in Numeric USAGE DISPLAY data items
What does INVDATA do?
▪
NOINVDATA: I have no invalid data; the compiler can generate the fastest code
▪
INVDATA(FORCENUMCMP): Always use a numeric compare
▪
INVDATA(NOFORCENUMCMP): Compare is sometimes numeric; matches COBOL 4 with
NUMPROC(NOPFD|PFD)
▪
INVDATA(CLEANSIGN): Clean sign codes of senders of arithmetic and compares
▪
INVDATA(NOCLEANSIGN): Don’t clean sign codes for senders of arithmetic and compares
▪
COBOL 4 did this for NUMPROC(MIG), but COBOL 6 didn’t do this with ZONEDATA
ZONEDATA
INVDATA Equivalent
ZONEDATA(MIG)
INVDATA(FORCENUMCMP,[NO]CLEANSIGN)
ZONEDATA(NOPFD)
INVDATA(NOFORCENUMCMP,CLEANSIGN)
ZONEDATA(PFD)
NOINVDATA
© 2019 IBM Corporation
30
Migration Pitfall #1: Invalid Data in Numeric USAGE DISPLAY data items
What does INVDATA(CLEANSIGN) do?
01 B1 PIC X(3) VALUE x’000000’.
*> Sign in B2
01 B2 REDEFINES B1 PIC 9(5) PACKED-DECIMAL. *> is x’0’
PROCEDURE DIVISION.
IF B2 > ZERO
DISPLAY ’ZERO
END-IF
▪
COBOL 4 corrects sign to x’F’ under NUMPROC(NOPFD)
▪
COBOL 4 has 0C7 abend under NUMPROC(MIG): CP abends because sign code is x’0’ and the sign isn’t
corrected
▪
INVDATA(CLEANSIGN) in COBOL 6 corrects sign to x’F’: no abend
▪
Same behaviour as ZONEDATA(NOPFD), which matches NUMPROC(NOPFD) with COBOL 4
INVDATA(NOCLEANSIGN) doesn’t correct the sign code to x’F’
▪
▪
New behaviour to be compatible with NUMPROC(MIG) in COBOL 4
▪
To get the old ZONEDATA(MIG) behaviour, use INVDATA(CLEANSIGN,FORCENUMCMP)
© 2019 IBM Corporation
31
Migration Pitfall #1: Invalid Data in Numeric USAGE DISPLAY data items
•
Earlier example compiled with NUMCHECK(ZON,MSG)
77 A1 PIC X(4) VALUE ’00 0’. *>
*>
*>
77 A2 REDEFINES A1 PIC 9(4). *>
PROCEDURE DIVISION.
IF A2 = ZERO
DISPLAY ’ZERO‘
ELSE
DISPLAY ’NOT ZERO‘
END-IF
•
x’F0F040F0’, third byte
has x’4’ for zone bits.
OK in PIC X, not valid in
PIC 9 USAGE DISPLAY
*> Compiler could do character
*> or numeric compare
When run, will issue the message below:
IGZ0279W The value X'F0F040F0' of data item A2 at the time of reference by
statement number 1 on line 8 in program ZONE failed the NUMERIC class test
generated by the NUMCHECK compiler option.
© 2019 IBM Corporation
32
Migration Pitfall #2
Overpopulated binary data items
© 2019 IBM Corporation
33
Migration Pitfall #2: Overpopulated binary data items
Values that have more digits than are defined in the data definitions
01
01
01
01
A1 PIC X(2).
A2 REDEFINES A1 PIC 9(3) BINARY.
B PIC 9(2) VALUE 2.
C PIC 9(3).
MOVE HIGH-VALUES TO A1
COMPUTE C = A2 * B
DISPLAY C
▪
*> 3 digits
*> A2 = 65535: 5 digits!
This is valid for programs compiled with TRUNC(BIN) and invalid for programs compiled with
TRUNC(STD) and TRUNC(OPT)
▪
Displays 070 with COBOL 6 “TRUNC(any)”, COBOL 4 “TRUNC(BIN)”
▪
Displays 002 with COBOL 4 “TRUNC(STD) or TRUNC(OPT)”
▪
In general the specific results in over-populated cases cannot be predicted as it depends on the
exact instruction sequence generated by the compiler.
▪
The use of TRUNC(OPT) in general is another pitfall as data must conform to the declared number
of digits or unpredictable results (and different results between compilers) may occur
© 2019 IBM Corporation
34
Migration Pitfall #2: Overpopulated binary data items
How to identify:
▪ Add ON SIZE ERROR tests
▪ Compile and test with the NUMCHECK(BIN) compiler option
▪ Will cause a message (MSG) or abend (ABD) when a BINARY data item has a value
that exceeds its picture clause
How to correct:
▪ Depends on the context
▪ Incorrect data item description → increase number of digits or use USAGE COMP-5
▪ Invalid value explicitly set through code (e.g. REDEFINES) → correct the code
▪ Incorrect record description for file → use the correct one
▪ Value coming from another source → correct at the source or add code to force a
truncation
© 2019 IBM Corporation
35
Migration Pitfall #2: Overpopulated binary data items
▪
Earlier example compiled with NUMCHECK(BIN,MSG)
IDENTIFICATION DIVISION.
PROGRAM-ID. BIN.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A1 PIC X(2).
01 A2 REDEFINES A1 PIC 9(3) BINARY.
01 B PIC 9(2) VALUE 2.
01 C PIC 9(3).
PROCEDURE DIVISION.
MOVE HIGH-VALUES TO A1
COMPUTE C = A2 * B
DISPLAY C
▪
When run, will issue the message below:
IGZ0316W The value X'FFFF' of data item A2 at the time of reference by statement number 1 on
line 11 in program BIN was invalid. The value exceeded the number of digits in the data
definition, and failed the SIZE ERROR test generated by the NUMCHECK(BIN) compiler option.
© 2019 IBM Corporation
36
Migration Pitfall #3
Parameter/Argument Size Mismatch
© 2019 IBM Corporation
37
Migration Pitfall #3: Parameter/Argument Size Mismatch
77
GRP1 PIC X(100).
Procedure Division.
. . .
Call ‘SUBP’ Using GRP1.
Program-Id. SUBP.
Linkage Section.
01 GRP2 PIC X(500).
Procedure Division Using GRP2.
MOVE ‘stuff’ To GRP2(300:20) *> Invalid!
Note: Caller is passing fewer bytes than the called program uses
Results:
• For COBOL 4 and earlier: illegal program didn’t fail
• For COBOL 6: file-status in CALLER changed; flow changed, failed
• NOTE: To catch this error, PARMCHECK(*,400) or greater is needed
© 2019 IBM Corporation
38
Migration Pitfall #3: Parameter/Argument Size Mismatch
How to identify:
•
Compile with new PARMCHECK compiler option and run regression tests
•
•
PARMCHECK introduced in COBOL 6.1 in April 2017 PTF and COBOL 6.2 GA
New feature of IBM Developer for z Systems (initially in RDz 9.5)
•
Scanning COBOL programs for compatibility
•
Use the Scanning COBOL Programs for Compatibility feature to scan a set of
COBOL programs to determine whether the parameters passed between the
calling and called programs are compatible
•
This works for CALL ‘literal’ statements and also for most CALL data-name
statements
How to correct:
•
Change the source code so the calling program is passing parameters at least as large as
the called program expects
© 2019 IBM Corporation
39
Migration Pitfall #3: Parameter/Argument Size Mismatch
•
Earlier example compiled with PARMCHECK(MSG,500)
77
GRP1 PIC X(100).
Procedure Division.
. . .
Call ‘SUBP’ Using GRP1.
Program-Id. SUBP.
Linkage Section.
01 GRP2 PIC X(500).
Procedure Division Using GRP2.
MOVE ‘stuff’ To GRP2(300:20) *> Illegal!
•
Note : PARMCHECK
results in slower code
than NOPARMCHECK
When run, will issue the message below:
IGZ0318W The CALL statement on line 135 in program TESTRUN caused corruption of
data beyond the end of the WORKING-STORAGE SECTION.
© 2019 IBM Corporation
40
Migration Pitfall #4
Data items that are used before
being given a value
© 2019 IBM Corporation
41
Migration Pitfall #4: Data items that are used before being given a value
01 X PIC X(100).
01 Y PIC 9(5).
01 Z PIC 9(3) BINARY.
01 W PIC 9(3) BINARY.
DISPLAY "X: " X
IF Y > 100
COMPUTE W = Z + 1
END-IF
DISPLAY W
What values do X, Y, Z, and W have at runtime?
▪ Depends on runtime options, how the compiler has laid out memory, where
the program was loaded
▪ Uninitialized memory isn't guaranteed to have any specific value
▪ COBOL 6 cannot guarantee uninitialized memory has the same value as it
did in COBOL 4
© 2019 IBM Corporation
42
Migration Pitfall #4: Data items that are used before being given a value
How to identify:
▪ Compile with INITCHECK compiler option
▪ Warnings are given at compile time
▪ Increases compile time, but has no runtime cost
How to correct:
▪
Assign a value to the data item (MOVE, INITIALIZE, or use a VALUE clause) before using it
as a sender
© 2019 IBM Corporation
43
Migration Pitfall #4: Data items that are used before being given a value
•
Earlier example compiled with INITCHECK
01 X PIC X(100).
01 Y PIC 9(5).
01 Z PIC 9(3) BINARY.
01 W PIC 9(3) BINARY.
DISPLAY "X: " X
IF Y > 100
COMPUTE W = Z + 1
END-IF
DISPLAY W
•
When compiling, the compile-time messages below are issued:
10
11
12
14
IGYCB7311-W
IGYCB7311-W
IGYCB7311-W
IGYCB7311-W
The
The
The
The
data
data
data
data
item
item
item
item
'X'
'Y'
'Z'
‘W'
may
may
may
may
be
be
be
be
used
used
used
used
at
at
at
at
this
this
this
this
statement
statement
statement
statement
before
before
before
before
it
it
it
it
is
is
is
is
set.
set.
set.
set.
© 2019 IBM Corporation
44
Migration Pitfall #4: Data items that are used before being given a value
01 X PIC X(100).
01 Y PIC 9(5).
01 Z PIC 9(3) BINARY.
01 W PIC 9(3) BINARY.
DISPLAY "X: " X
IF Y > 100
COMPUTE W = Z + 1
END-IF
DISPLAY W
•
W is initialized on one path (Y > 100) but not the other (Y <= 100)
•
Do you want a warning about W in the DISPLAY statement?
•
No: only warn about data items if they’re not initialized on ANY path to a statement:
use INITCHECK(LAX)
•
Yes: warn about data items unless they’re initialized on ALL paths to a statement:
use INITCHECK(STRICT)
© 2019 IBM Corporation
45
Best practices for
COBOL 6 migration
© 2019 IBM Corporation
46
Steps to Migrate to COBOL 6
In parallel with migration effort, identify applications not under regular development. These applications can
be optimized and deployed using ABO to realize immediate MIPS reductions and shorter batch windows.
47
Best Practices for COBOL 6 Migration
To identify bad data IBM recommends a two stage approach, applied on a program by program basis:
1) Compile each program to be migrated using SSRANGE, NUMCHECK, PARMCHECK, INITCHECK and OPT(0)
for initial code changes and unit test
▪ To find table misuse, invalid data use and invalid parameter usage
▪ OPT(0) programs are easiest to debug, quicker compiles
▪ Inspect listings for INITCHECK messages
▪ Look at runtime logs for NUMCHECK, PARMCHECK and other error messages
The performance of this OPT(0) generated code especially combined with these strict bad data checking options
means a second compile and re-testing is needed before production deployment…
2) Recompile with NOSSRANGE, NONUMCHECK, NOPARMCHECK and OPT(2) and highest ARCH level possible
for testing and production
▪ NOSSRANGE, NONUMCHECK and NOPARMCHECK are required for good performance
▪ OPT(2) is preferred for good performance in production
▪ Set ARCH to the highest level you can (but no higher than the lowest level of mainframe where code will
have to ever run).
deployment:
Note: This approach requires two compile development and test process if you are not using one already
© 2019 IBM Corporation
48
Best Practices for COBOL 6 Migration
How much MSU reduction do you get with Enterprise COBOL 6?
Depends on many factors, the only way to know is to measure performance before and after migration
IBM recommends this process for performance comparison:
Back up COBOL 4 (or earlier) executables before you migrate
After migrating, set up a test environment with a real, representative workload, and measure performance against
that workload with the old COBOL 4 executables and again with the new COBOL 6 executables
Measuring in production won't be as accurate
Different workloads at different times
Not best practice to measure COBOL 4 before migrating and COBOL 6 after
Hardware, workloads, code, may all be changed during migration
© 2019 IBM Corporation
49
Best Practices for COBOL 6 Migration
To help reduce cases of invalid data IBM has these recommendations for COBOL development
We recommend using the RULES compiler option to provide information about your programs, issues like:
– NOENDPERIOD (flags conditional statements terminated with period)
– NOEVENPACK (flags even number of packed decimal digits)
– NOLAXPERF (flags opportunities for performance improvements)
– NOSLACKBYTES (flags bytes added by compiler for SYNCHRONIZED data items)
We recommend always using DIAGTRUNC
– To find any cases of ‘hidden’ loss of data when statements truncate numeric data items
Use the Scanning COBOL Programs for Compatibility feature of
IDz (introduced in RDz 9.5) to check parameters
– To find parameter mismatches in CALL statements
© 2019 IBM Corporation
50
Best Practices for COBOL 6 Migration
A few things to consider about compiler options
▪
▪
Use the same compiler options with COBOL 6 as in earlier compilers when migrating, except:
▪
Options that have been removed, e.g. NUMPROC(MIG)
▪
Optimization level has new sub-options (0,1,2 instead of NOOPT,STD,FULL)
▪
New ARCH level option to target particular IBM mainframe levels
Do not change from NUMPROC(NOPFD) to NUMPROC(PFD) or from TRUNC(BIN) to TRUNC(OPT)
without doing research and testing
© 2019 IBM Corporation
51
Best Practices for COBOL 6 Migration
A few things to consider about compiler options
▪
▪
Be aware of ARCH setting and your hardware. You need to know the lowest level of hardware where
your programs will ever be run (Disaster recovery machine? Subsidiary companies?)
▪
For example: ARCH(13) programs require a z15 and may abend with an 0C1 on z14 (or earlier)
▪
If you update your hardware in the future you will want to update ARCH in your COBOL compile
steps as well
NUMPROC(MIG) is removed, which requires special consideration and extra testing.
▪
Usually use NUMPROC(NOPFD). Most conservative setting of option, also the default.
▪
Also look at INVDATA(FORCENUMCMP,NOCLEANSIGN)
▪
Using NUMCHECK(ZON,PAC) with NUMPROC(PFD) can indicate that your data and signs are
always preferred, allowing you to migrate to NUMPROC(PFD) and NOINVDATA for better
performance
© 2019 IBM Corporation
52
How to prepare for
COBOL 6 before you
begin migration
© 2019 IBM Corporation
53
How to Prepare for COBOL 6 Before You Begin Migration
Install latest maintenance required for COBOL 6
(on LE, Db2, CICS, Binder, and other products)
Use the COBOL FIXCAT feature documented here:
http://www-01.ibm.com/support/docview.wss?uid=swg21648871
Run the SMP/E MISSINGFIX command to find required PTFs (LE,DB2,CICS,Binder, etc) for the new compilers:
SET BDY(GLOBAL)
REPORT MISSINGFIX ZONES(ZOS13T,ZOS13P)
FIXCAT(IBM.TargetSystem-RequiredService.Enterprise-COBOL.*)
▪ This command will look for all PTFs needed for COBOL 6
Install indicated PTFs on all systems before using the new compiler
© 2019 IBM Corporation
54
How to Prepare for COBOL 6 Before You Begin Migration
▪
Install latest maintenance for vendor tools
▪ Older versions may not support programs compiled with COBOL 6
▪
If you use third-party code in your application, check with the vendors for updates
▪ Some vendors have updated their applications; others may need to
▪
Convert PDS COBOL load libraries to PDSE datasets
▪
Change build processes in the BIND/LINK step to avoid using the old VS COBOL II
bootstrap routines
▪ REPLACE –IMMED,IGZEBST
▪ This will not fix all, but is a no-risk change that could have a good reward
© 2019 IBM Corporation
55
How to Prepare for COBOL 6 Before You Begin Migration
▪
Take inventory of your COBOL load libraries
▪
▪
▪
Use a tool like Load Module Analyzer of Debug Tool
▪
IBM File Manager (Load Module Utility Functions)
▪
COBANAL Tape #321 at cbttape.org
▪
Library Utility of File-AID/MVS
▪
What compilers were used for each program
▪
What compiler options were used (esp CMPR2, NUMPROC, TRUNC)
If you have OS/VS COBOL or VS COBOL II NORES programs
▪
See if they are being used (OMEGAMON or Tivoli Application Manager)
▪
If so, either target them for early migration to COBOL 6 or migrate them to COBOL 4
▪
Get rid of the “OS/VS COBOL problem” early
Use CCCA of Debug Tool to convert source
▪
OS/VS COBOL programs
▪
Pre-V3 programs compiled with CMPR2
© 2019 IBM Corporation
56
Resources
© 2019 IBM Corporation
57
COBOL Migration Portal (here) - Your one-stop COBOL migration content hub
Read case studies to see how other
companies have benefited from the
migration.
Check FAQs to quickly find answers
and solutions when running into
problems.
Watch the COBOL experts interview
videos.
Discover IBM Automatic Binary
Optimizer for z/OS (ABO), which
can accelerate the COBOL migration
and improve the performance of
COBOL modules without a
recompilation plan.
Try the cloud-based COBOL
Migration Assistant that helps you
navigate through the whole migration
process.
Register to the no-charge COBOL
Migration and Performance Tuning
Webinars.
Find the complete COBOL
Migration Guides and
Performance Tuning Guides.
Leverage IBM DevOps tools to
support your migration esp.
regression testing.
Check out other resources such as
fix packs/PTFs to keep your COBOL
compilers up-to-date, as well as the
COBOL support portal and COBOL
community to seek for help along
your migration and performance
tuning journey.
the interactive and cloud-based COBOL Migration Assistant augments the COBOL Migration Guide and helps you navigate through the migration process
smoothly.
IBM Enterprise COBOL for z/OS Migration Assistant (link)
Ease your migration to
the latest IBM Enterprise
COBOL for z/OS compiler
The cloud-based and step-by-step
COBOL Migration Assistant helps you
navigate through the COBOL
migration process from Enterprise
COBOL 4 or earlier to COBOL 6 or
later.
IBM Doc Buddy
IBM Doc Buddy
With the IBM Doc Buddy mobile app, you can search
messages and codes issued from IBM Z products online and
offline. IBM Doc Buddy also aggregates mainframe content
including blogs, videos, IBM Knowledge Center topics, and
Thought Leader opinions.
iOS
Android
https://ibmdocbuddy.mybluemix.net/
sptast@cn.ibm.com
60
COBOL Resources
Enterprise COBOL
Product Page:
https://ibm.biz/BdqVZ3
Documentation:
https://ibm.biz/BdqVZT
Trial:
https://ibm.biz/BdqVZw
RFE community: Request For Enhancement:
https://ibm.biz/BdqVZk
COBOL Blogs:
https://ibm.biz/BdqVZt
COBOL Discussion Forum:
https://ibm.biz/BdqVZ6
COBOL Performance
Whitepaper:
https://ibm.biz/BdqVZU
Identify Top Consuming COBOL Programs:
https://ibm.biz/BdqLnx
Performance Tuning Guide:
https://ibm.biz/BdqLnH
61
ABO Resources
IBM Marketplace Page:
https://ibm.biz/BdqeWm
Documentation:
https://ibm.biz/BdqeWa
Trial Cloud Service:
https://ibm.biz/BdqeWG
ABO Demo:
https://ibm.biz/BdqeWn
RFE community:
Automatic Binary Optimizer
62
IBM Automatic Binary Optimizer
for z/OS Trial Cloud Service
Overview
A sleek, new, no-charge 90-day trial web application to
optimize COBOL modules
Easy-to-follow instructions and videos to guide you from
beginning to end
What can you do?
Optimize multiple COBOL modules per data set upload
View a list of all modules within a data set
Search and multi-select COBOL modules to optimize
Get up-to-date optimization status via notifications and
from the optimizer dashboard
https://optimizer.ibm.com
Q&A
© 2019 IBM Corporation
64
Thank you
Mike Chase
Compiler Optimization Developer
IBM
—
mike.chase@ca.ibm.com
© Copyright IBM Corporation 2019. All rights reserved. The information contained in these materials is provided for informati onal purposes only, and is provided AS IS without warranty of
any kind, express or implied. Any statement of direction represents IBM’s current intent, is subject to change or withdrawal, and represent only goals and objectives. IBM, the IBM logo, and
ibm.com are trademarks of IBM Corp., registered in many jurisdictions worldwide. Other product and service names might be tra demarks of IBM or other companies. A current list of IBM
trademarks is available at Copyright and trademark information.
© 2019 IBM Corporation
65
Backup
© 2019 IBM Corporation
66
Changes Since Release
These were problems in previous COBOL 5/6 releases that were fixed in subsequent
releases or PTFs
– With the latest service on COBOL 6.2, they won’t be a problem now
Compiler required an OMVS segment be defined for the userid doing the compilation. This
requirement is removed with APAR PI94326.
Compiler messages are not in the same part of the listing as before
▪ FE messages are in the middle, before pseudo-assembler
▪ BE messages are at the end like in COBOL 4 and earlier
▪ Previous behavior restored in COBOL 6.2!
AMODE 24: There used to be problems, but IBM fixed them in March 2014 (5.1.1).
© 2019 IBM Corporation
67
Modifying data outside the bounds of a table
01 MY-TABLE.
05 TABLE-ROW OCCURS 100 TIMES INDEXED BY MY-INDEX.
10 MY-ITEM PIC X(1).
SET MY-INDEX TO 1
PERFORM UNTIL DONE
MOVE ‘Z’ To MY-ITEM(MY-INDEX)
SET MY-INDEX UP BY 1
END-PERFORM
You may see different results with statements that modify data beyond the end of a table in COBOL 5
compared to previous compilers.
▪
In COBOL 6, index-names were stored immediately after the table group, rather than being stored
elsewhere in memory (TGT in COBOL 4)
▪
Changed in July 2016 PTF for COBOL 5.2 and September 2016 PTF for COBOL 6.1
▪
▪
Index-names are now at the beginning of their section
These types of invalid programs can be detected with the SSRANGE compiler option.
© 2019 IBM Corporation
68
Using tables when the ODO object value is not in legal range
01 OBJ PIC 9(5) BINARY.
01 MY-TABLE.
02 T OCCURS 0 TO 1 TIMES DEPENDING ON OBJ.
05 MY-FIELD PIC X(1).
01 OFLOW PIC X(500).
MOVE 300 TO OBJ. *> Legal if table is not referenced
MOVE ALL ‘M' TO MY-TABLE. *> Illegal, OBJ not in range 0 TO 1
DISPLAY MY-TABLE
DISPLAY OFLOW
Different results in different versions of COBOL
▪
COBOL 4 and earlier: Moved 300 bytes of ‘M’
▪
COBOL 5: Moved 1 byte of ’M’ and 299 bytes of ‘other’
▪
Moves 300 bytes of ‘M’ after applying March 2016 COBOL 5.2 PTF, April 2016 COBOL 5.1 PTF, or
June 2016 COBOL 6.1 PTF
▪
You can use SSRANGE to detect this problem
© 2019 IBM Corporation
69
ABO: Before you begin using
▪
Check if LE and Binder PTFs have to be installed on systems where ABO and the
optimized modules will be used : ABO 1.3 Pre-Req PTFs
▪
z/OS 2.1 and z/OS 2.2 may require LE and binder PTFs
▪
z/OS 2.3 requires a single binder PTF on system where ABO itself will be used (and
nothing on system where optimized modules will be used)
▪
ABO install is a simple and standard SMP/E install
▪
No updates needed to other sub-systems (except for CICS CSD update on z/OS 2.1
and 2.2)
▪
No post install configuration or customization required
▪
ABO ships with an installation verification program (IVP) to check that LE PTFs have
been installed correctly
© 2019 IBM Corporation
70
© 2019 IBM Corporation
71
Download