Dexterity Business Analysts

LE-370
 LE – 370 Migration Agenda

 Overview - What is LE ?

 Runtime Options

 Migrating to LE

 User Experiences

 Debugging LE

 Summary
 LE Overview
 What is Language Environment (LE) ?

 Single run-time environment for High Level

Languages
• Basic support routines
(init/term, storage, messages, conditions)
• Callable services (Date, Time, etc.)
• Language-specific routines
(C/C++, COBOL, PL/I, Fortran)

 Why use LE ?

 Base element of OS/390

 Prerequisite for applications built with newer
compilers
 Replaces obsolete run-time library products
 LE Runtime Options

ABTERMENC(ABEND)
(ABEND) is new default for V2R9 and up
DEPTHCONDLMT(0)
(10) is default but (0) is recommended
ERRCOUNT(0)
(0) is default for V2R6 and above
TERMTHDACT(TRACE)
(UADUMP) and DD needed to get system dump
TRAP(ON,SPIE)
(ON,SPIE) is default & recommended
 LE Runtime Options for better
performance

 ALL31(ON)
 (OFF) - default, required if using AMODE 24

 ANYHEAP, BELOWHEAP, HEAP

 Use RPTSTG suggested values to minimize GETMAINs

 LIBSTACK, STACK
 Use RPTSTG suggested values to minimize GETMAINs

 RPTOPTS(OFF), RTPSTG(OFF)
 Avoid generating reports during production !!!

 STORAGE(NONE,NONE,NONE)
 Using initial values will impact performance
 Setting LE Runtime Options

 LE Migration Guide lists current recommendations

 Language-specific
 Mixed language applications
 CICS and non-CICS (batch, IMS, etc)

 Setting LE Run-Time options

 CEEDOPT - installation-wide LE default options
 CEEROPT - region-wide LE options (if IMS with LRR)
 CEEUOPT - application specific LE options, must be
linked
 Load Module
• PL/I main - PLIXOPT
• C main - #pragma runopts()
 Migrating to LE Using
multiple
OS/390 LE releases
 LE is Upward compatible!
 Applications built on one level of OS/390 LE will
continue to run on later releases of OS/390
without the need to re-link edit or recompile

 New in R10 - LE is downward compatible too!

 You may develop applications on higher releases
of OS/390 LE for use on platforms running lower
releases of OS/390 LE
 Migrating to LE Using multiple OS/390
LE releases (contd)..

 LE Programming Guide lists guidelines/restrictions

• NOT a roll-back of new function to prior releases
• System used to build applications must be at least OS/390
V2R10

 Toleration PTFs for lower OS/390 releases are in PSP bucket

• Upgrade OS390R10 subset LANGENV
 Planning for Migration
 Develop a cost/benefit analysis
- Include E-business, client-server, OO in your
benefit
- See "Technical Advantages of LE" in handout

 Take inventory of your COBOL and PL/I

development tools

 Assess requirements of new software

- Prerequisite product levels
- Compatibility with vendor products
- Compatibility with IBM products

 Take inventory of existing applications

 Assess migration effort for each application

 Schedule training for programmers

Planning for Migration (contd)..

What could go wrong without

planning?
 Improper setup
- Not increasing the ERDSASZE CICS storage
option
value SOS condition can result
• We are working on reducing storage
requirements of LE

- One customer noticed a big performance hit

when using TRUNC (BIN);

- Problem was solved by using TRUNC (OPT)

- TRUNC(BIN) should never be the default option

Planning for Migration (contd)..

What could go wrong without planning ?

(contd)..
 "Surprise" migrations!

- Tricky IBM product packaging.

Example: Customer moves from SMP install to
rebuilt
- IBM offers SERVERPAC
- LE in LNKLST by default
- Surprise migration!
- Installer doesn't RTFM
- Ignores SMP warnings
- Surprise migration!
- If any problem applications, then not a NICE
surprise!
 Preparation for Migration

 For each application, determine

(by hand, or with EDGE Portfolio Analyzer):
- Level of source used
* CICS Macro Language
* COBOL 68, 74, 85
- Level of compiler used
- Compiler and run-time options used
- Presence of Inter-Language Communication
(ILC)
* PL/I-COBOL and C-COBOL migration aids
exist
(see respective migration guides)
- Presence of assembler
- Level of PL/I transient library used
- Level of PL/I resident library used
 Preparation for Migration
(contd)..
 EDGE Portfolio Analyzer works with load modules
- EDGE Portfolio Analyzer tool
* No longer available from IBM
* Go to www.edge-information.com
- Scans load module libraries (any language)
- Tells you what (if any) needs to be relinked
- Build Linkage Editor Control statements to aid
relinking
-Determines which compiler and what options were
used

 Install latest maintenance on existing run-time

library
- PN74000 for VS COBOL II R4 bootstrap IGZEBST
* Mixing VS COBOL II and newer COBOL
- PN69803 & PN69804 for OS PL/I V2
* For mixed PL/I and COBOL (ILC)
 Preparation for Migration (contd)..

Use only one run-time library for each application

- Ex: COBOL NORES modules contain their own run-time
routines
-they must be REPLACED with link edit

Do not have more than one COBOL library in concatenation

- Ex: OS/VS COBOL 1st, VS COBOL II 2nd in LNKLST
- OS/VS COBOL main program has SORT
Brings up OS/VS COBOL environment
- SORT exits written in VS COBOL II
Brings up VS COBOL II environment
- Abend when return to OS/VS COBOL

First step might be to remove OS/VS COBOL from LNKLST

- Run all programs under VS COBOL II, then LE
- For OS PL/I V1, could go to OS PL/I V2 then to LE
 Preparation for Migration (contd)..
 Do not have more than one COBOL library in
concatenation
 If more than one COBOL library in LNKLST
- If LE is first in LNKLST, then other COBOL is dead code
- If VS COBOL II is first, then OS/VS COBOL is dead
 Common error we are hearing:
- VS COBOL II first, then LE in LNKLST
- This will cause problems! It is NOT supported!
- VS COBOL II first means the LE migration still has to be
done
 If LE not first, what could go wrong?
- Mixing COBOL for OS/390 & VM programs and VS
COBOL II
programs will definitely fail, but in unpredictable
ways
 One COBOL library in concatenation only
- Either COBLIB, COB2LIB, or SCEERUN
- COBLIB not supported, COB2LIB support ended 3/2001
 Setting Up LE

 In LE for OS/390 2.6 (9/1998), Change

- CBLQDA to OFF,
- DEBUG to OFF,
- ERRCOUNT to 0, and
- FLOW to NOFLOW

 In LE for OS/390 2.9 (3/2000), Change

- ABTERMENC to ABEND.
- APAR PQ34302

 Less customization at install time!

 Moving LE into Production

 Install target depends on migration strategy used

- LNKLST/LPA only when everything runs under LE
 There are 2 main strategies being used, both OK:
- Change each application one at a time to use new
compiler and
run-time library (STEPLIB)
- Run current modules under LE, then use new compiler
later at
maintenance or enhancement time (LNKLST)
 This presentation is focused on run-time first, then compiler
migration
 STEPLIB for old applications that will not run under LE
- Complete the migration later
 STEPLIB maximum control with performance cost
- Customer feedback says STEPLIB noticeably slower
 One IMS region at a time
 One CICS region at a time
 Moving LE into Production

Possible scenarios for controlled migration

Batch 1:
- Newly migrated applications STEPLIB to LE
- Deferred applications STEPLIB to old runtime
- At a given point change from old runtime to new
in
LPA/LNKLST
- Start deleting STEPLIB for migrated applications

Batch 2:
- Change all applications to STEPLIB to current
runtime
- Install LE in LPA/LNKLST
- Delete STEPLIB to migrate each application
 Moving LE into Production

 Scenario for controlled migration

Online:
- Create new region that uses LE
- Move transaction by transaction from old region to new
Online (TSO):
- Use TSOLIB command to set up dynamic steplib
concatenation (must be TSO/E 2.5 or later)
- Under ISPF add LE to the ISPLLIB concatenation
- If you can control the logon proc, put a STEPLIB there
Note: Under ISPF, the search order is:
ISPLLIB, LNKLST/LPALST, then STEPLIB
 Moving LE into Production

 Some customers have used a bold migration method:

- Test cross-section of applications

- No or few problems were found
- IPL production systems with LE in LNKLST on Sunday
- Have all application support personnel on call for next
week
- STEPLIB applications that have problems
- Fix the problems as time permits, remove STEPLIB
- Method is not recommended as best method, but has
worked for some
LE is Different!
Some run-time options are the same, many new
ones
ABEND codes are different
- Most abends end up with code 4038
- If TERMTHDACT (UADUMP) then 4039 also
- Can get U1035-type codes with CEEWUCHA or
CEEBX05A
-Run-time messages are in different places under
CICS
- CESE Transient Date queue, VS COBOL II used
Temporary Storage Queue
Other languages can be sub programs with LE
- Example: COBOL calling C, C was MAIN before LE
ABEND-AID installed differently than pre-LE
Debug abends using error messages, NOT abend
codes.
- Abend codes will not help in many cases!
 64-bit is not Different!
 PL/I and COBOL applications will run unchanged in 64-
bit z/OS
V1R1 and V1R2, 31-bit or 64-bit regions, it doesn't
matter

 Although PL/I and COBOL do not support 64-bit

addresses
explicitly, customers may get some of the benefits of
64-bit
z/OS just by moving to it.

With a 64-bit addressable real memory backing virtual

memory,
there will be less paging and swapping and, therefore,
the
possibility of better system performance
 64-bit is not Different! (contd)..

Actual results obtained in specific operating

systems environments will vary depending on
individual configurations and workload conditions

 In addition, DB2 can exploit 64-bit addressing for

SQL statements in PL/I and COBOL programs without
any changes to the PL/I or COBOL programs.
 Hints and Tips

Have at least one "COBOL or PL/I DBA" who knows

about
compilers, run-times, and preferred default settings

Keep your language products up-to-date on service

as much as possible
- Down-level language migrations are harder
Example:PN74000 for VS COBOL II Release 4 would
revent problems with IGZEBST when adding COBOL for
MVS & VM programs to VS COBOL II applications

Keep control of your language products usage

- Do not allow programmers to choose the release and
maintenance level or you will end up with a nightmare for
application management
 PL/I for MVS & VM

Benefits of Migration
- FETCH for CICS and VM
- Automatic storage optionally allocated above 16M
line
- More powerful condition handling
- OPTIONS(FETCHABLE), no need for Linkage-editor
ENTRY
- CEESTART entry point (even CICS)
- OPTIONAL attribute for OPTIONS(ASSEMBLER)
- PLIRETC and PLIRETV extended to a fullword value
- EXTERNAL ('env-name') for OPTIONS(ASSEMBLER)
- NOT and OR compiler options
 PL/I for MVS & VM (contd)..

- Enhanced FETCH
- Allow use of above-the-line storage
- ERROR on-units can now get control for non-PL/I
conditions and system ABENDs
- Lifted restriction on dynamic link -- may specify
the proc
that gets control within a FETCHed load module
- Simplified link-edit
- Helps build more flexible procedures
- Expanded return code (works w/ JCL
enhancement)
- More powerful entry DCL for Assembler
- Help with code page issues when moving source
between platforms
 Look and Feel

 PL/I for MVS & VM object module

- CEESTART is the only entry point for OPTIONS(MAIN)

- CEESTART is the entry point for OPTIONS(FETCHABLE)

- Require Language Environment SCEERUN during

compilation
 PL/I Source Conversion

 Recompile OS PL/I Version 1 with CMPAT(V1)

- CHARSET(48) and CHARSET(BCD) are not
supported
- DBCS is a little different from old EGCS
- Cannot coexist with modules produced by
Checker

 Recompile OS PL/I Version 1 with CMPAT(V2)

- Support for fullword subscripts
- Support for AREA and Aggregates size > 16MB
- HBOUND, LBOUND, DIM, and ALLOCATION
return FIXED BIN(31,0)
 PL/I Source Conversion (contd)..

 Do not mix CMPAT options if:

- All procedures in an application share one of the
following
- An array
- A structure that contains an array
- Allocated aggregate or AREA

 Use PL/I-supplied CHARSET(48) migration tool

- Translate CHARSET(48) to CHARSET(60)
- Available with OS PL/I V2 as a sample program
PL/I Source Conversion (contd)..

 Array bounds and areas were limited in V1

-- descriptor used half-word

 Don't use CMPAT(V2) unless you are ready to recompile

everything and use the same CMPAT option

 Watch for direct use of descriptor internals from non-

PL/I
CMPAT(V1) is the default run-time option
 EDGE tool can spot mismatches
 PL/I Source Conversion (contd)..

 The CHECK option functionality has been replaced by

Debug Tool:
 Display current value of any variable
 Does not require source update and recompile to
activate
 Obtain similar trace output:
- Compile program with TEST(PATH)
- Specify TEST runtime option
- Set PATH breakpoint:
- AT PATH * DO; LIST
('At statement: ', %STATEMENT); GO; END;
- This will display a message at every PATH point
(block entry, block exit, label constant, before
CALL, after CALL, . . .)
- Type GO; to start program execution
 Year 2000 items

 PL/I for MVS & VM

 Millennium Language Extensions:

- Two-digit year date comparisons automatically

windowed
- Comparisons and assignments between variables
with different date attributes are supported
- REPATTERN, Y4DATE, Y4JULIAN, and Y4YEAR built-
in functions make some common transformations
easier
- New DATE attribute
- Activated by RESPECT(DATE) compiler option
 User Experiences - Topics

Determining LE vs. non-LE

Programming Issues
System Issues
Error Handling
Testing
De-Bugging
IMS Issues
 Determining LE vs. non-LE

 Determining LE vs. non-LE

 Externally
 Internal Application Program
 Programming Issues

 All Variables should be Initialized

 Uninitialized variables (under non-LE) had a value
usually
X’0’ which do not give raise to problems.
 Under LE, garbage in many uninitialized variables

 PL/I source code

 PL/I FREE requires IN for AREA allocated variables
• FREE P->X IN(A);

 Standard output files - PLInnnn mapped to CEExxxx

• Example: PLIDUMP to CEEDUMP

 Message File - Sysprint, Sysout, or MSGFILE

 System Issues

 Pre-initialized environments
 LE PICI mechanism
• Mostly compatible with PRE-LE
techniques
 LE PIPI mechanism
• "Wave of the future“
 Error Environment
 SPIE & STAE mapped to TRAP
• TRAP(ON) if either SPIE or STAE
 TRAP(OFF)
• Really TRAP “almost” OFF
• Shunt mechanism
 Error Handling

 Conversion of SPIE and STAE

 visit PLIXOPT and #pragma
 Pre-LE to LE options translation

 Watch for error based systems

 Locally brewed error handlers
 May need modification for retry

 Shunting
 ESPIE and ESTAE handling
 LE CEE3ERP interface
 Error Handling (contd)..

 Error codes
 Uses C Paradigm
 PL/I 2xxx may be mapped to 3xxx

 Error processing
 Post error processing
• may need modification (e.g. GOTO out of
error)

 Special situation
 Shunting
 Testing

 Standard scripts
 Multi-environment
 Assembler, PL/I and/or C mix

 Error scenarios
 Recursive error conditions
 Condition Handling
• Hardware of Software program check

 Output to standard files

 SYSPRINT, stdout, etc.

 Extensive testing is required

 Debugging with IMS and LE

 IMS & LE do coordinate condition handling!

 ABEND codes are different

 Most LE abends are U4038/U4039
 Debug using error messages, NOT abend codes!
• Example: Abend0C4 becomes message
CEE3204S

 Return & Reason code changes

 MSGFILE(SYSOUT)
 Messages and Reports default to SYSOUT
 Debugging with IMS and LE - Dump
files

 CEEDUMP
 Formatted dump of LE storage/data
 Content depends on TERMTHDACT() suboption

 SYSUDUMP
 If TRMTHDACT(UADUMP) with SYSUDUMP DD
 Formatted dump but no formatting of LE
information

 SYSMDUMP
 If TRMTHDACT(UADUMP) with SYSMDUMP DD
 IPCS verbexit LEDATA/CEEERRIP
 When reporting problems to IBM L2
 Debugging with IMS and LE - control blocks

 Common Anchor Area (CAA)

 pointed to by Register 12

 Stack Frame/Dynamic Save Area (DSA)

 pointed to by Register 13
 DSAs are backchained at DSA+X'4‘

 Condition Information Block (CIB)

 CEECAA +x'2D8' points to current CIB

 Machine State Information Block (ZMCH)

 pointed to by CIB + x'24'
 Migrating IMS Regions to
LE

 Make sure you & your applications are ready

 Read the language-specific LE Migration Guides
 PLAN, PLAN, PLAN
 Perform Regression Tests

 Make sure your Vendor tools are LE-enabled

 List in LE Migration Guide Appendix A or call the
Vendor

 Don't let OS/390 force LE into the LNKLST too early

 OS/390 Program Directory under 'LNKLSTxx
Considerations‘
 APAR ii10425: How to install OS/390 without LE in
the LNKLIST
 Migrating IMS Regions to LE (contd)..

 LPA, LNKLST or STEPLIB for LE modules?

 LNKLST for most LE modules
• SCEERUN (PDS) and SCEERUN2 (new PDSE at
V2R10 & up)

 LPA for heavily used LE modules

• SCEELPA contains LPA eligible LE modules
• Also check language-specific recommendations
in Migration Guides

 STEPLIB if you have not completed LE migration

 LRR (Library Routine Retention)

 What is LRR (Library Routine Retention)?

 Keeps LE resources in memory for better performance
 LE does not keep user programs in storage

 LRR setup
 In the DFSINTxx member of IMS.PROCLIB specify name
CEELRRIN
 Specify xx as a suffix on the PREINIT keyword in your
IMS 'bring up' JCL or procedure
 LRR - Storage tuning user exit

 Collect LE storage tuning information without having

to run with the RPTSTG option

 Set the LE runtime options STACK, LIBSTACK,

HEAP,ANYHEAP, and BELOWHEAP for each LE enclave

 use CEEBSTX (for non-CICS with LRR)

 sample exit in SCEESAMP as CEEWBSTX

 must be assembler, reentrant

 See LE Customization manual

 LE V2R9 & up
 LRR - Load Notification User
Exit

 improve performance by preventing the use count

for frequently used modules from dropping below
one

 CEEBLNUE (requires LRR)

 must be written in assembler

 See LE Customization manual

 Summary

 LE is part of OS/390 and z/OS

 Plan for migration by reading the Migration

manuals

 Review runtime options before migration

 Consider LRR for performance

 Check for uninitialized variables

 Do extensive testing, including error scenarios

 Be aware of Debugging differences

END OF THE SESSION