Top Banner

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

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)..

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 inconcatenation 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), ChangeCBLQDA 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 ProductionPossible 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 migrationOnline: - 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 TipsHave 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

DBA Corpppt Mainframes Le370

Apr 11, 2015

ReportDownload

Documents

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

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)..

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 inconcatenation 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), ChangeCBLQDA 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 ProductionPossible 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 migrationOnline: - 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 TipsHave 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