Dexterity Business Analysts LE-370
Dexterity Business Analysts
LE-370
Overview - What is LE ?
Runtime Options
Migrating to LE
User Experiences
Debugging LE
Summary
LE – 370 Migration Agenda
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 Overview
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
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)..
"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!
What could go wrong without planning ? (contd)..
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 migrationBatch 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 hasworked 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 QueueOther languages can be sub programs with LE - Example: COBOL calling C, C was MAIN before LEABEND-AID installed differently than pre-LEDebug 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 harderExample: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
- 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
PL/I for MVS & VM (contd)..
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
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
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
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)..
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 TestingDe-BuggingIMS 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