Dba Corpppt Mainframes Le370

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

surprise!

- 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

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 64bit 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 nonPL/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 builtin 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