Rational Developer for System z
Enterprise PL/I for z/OS, Version 3.8, Migration Guide

Determining how applications will have access to the library

Two general methods are available for moving Language Environment into production: adding Language Environment to the LNKLST/LPALST or using a STEPLIB approach.

LNKLST/LPALST

After you add Language Environment to the LNKLST/LPALST, Language Environment is available to all of your applications. To ensure that all applications are functioning correctly under Language Environment before adding Language Environment to your LNKLST/LPALST, you can temporarily install Language Environment in LNKLST/LPALST or use STEPLIB.

Do not make more than one PL/I run-time library available to your applications at execution time. For example, there should be one and only one PL/I run-time library, such as SCEERUN for Language Environment, in LNKLST. If you have more than one, you will either get hard-to-find errors or you will have an unused load library in your concatenation. When you add Language Environment to LNKLST/LPALST, remove any other PL/I run-time libraries.

Temporary installation in LNKLST/LPALST or use STEPLIB

Suggestions for temporarily installing Language Environment in LNKLST/LPALST include:

Note:
Although many elements of z/OS and OS/390 depend on the Language Environment run-time library, both z/OS and OS/390 do not require Language Environment to be installed in LNKLST. (However, Language Environment must be installed in the same zone as z/OS and OS/390.) If you choose not to place Language Environment in LNKLST, you must STEPLIB Language Environment in the individual z/OS or OS/390 PROCs that required Language Environment. For information on which elements require Language Environment, see:

STEPLIB

You can choose to phase in Language Environment gradually by using the STEPLIB approach. When you STEPLIB to the Language Environment run time, you phase in one region (CICS or IMS), batch (group of applications), or user (TSO) at a time.

Although using STEPLIB means changing your JCL, a gradual conversion can be easier than moving all of your applications at one time. Also note that when using STEPLIB, programs will run slower than when they access the run-time library through LNKLST/LPALST and more virtual storage will be used.

Note:
If you have multiple processors linked together with channel-to-channel connections, you must treat the entire system as one processor and should convert subsystem by subsystem. In addition to revising your JCL to STEPLIB to the Language Environment run time during initial setup, you might also need to specify CEEDUMP DD if the default allocation for CEEDUMP does not meet your shop’s needs. (CEEDUMP is the ddname where Language Environment writes its dump output.)

Problems with STEPLIB and IMS programs

When you use STEPLIB on IMS/DC online to access the Language Environment run time, any Language Environment library routines that you have preloaded will not be loaded into read-only storage. If your application has an error and overwrites non-application storage, preloaded run-time routines can become corrupted and eventually cause abends when used. At refresh time, these preloaded routines marked reentrant are not refreshed unless loaded from the LPA or the LNKLST/LPALST. Thus, the abends will recur.

Note:
This is a 20-year-old problem with MVS (OS/390), IMS, and STEPLIB, and is mentioned here because of the proposed STEPLIB approach for gradually moving to Language Environment.

You can use either of the following methods to prevent this problem:

How to minimize the impact:
How to recover

If you do notice several different applications abending in the same region, stop the region and restart with these IMS commands:

  1. Determine the region number by issuing: ’/DISPLAY ACTIVE’
  2. Stop the region by issuing: ’/STOP REGION region#’
  3. Restart the region by issuing: ’/START REGION region-name’

STEPLIB example

Here is one example of how to phase in Language Environment using the STEPLIB method: for an organization that has a central development center (all compiling and linking is done in one location) and separate production sites. This is a very conservative approach, but it has been used by many customers who require absolutely no disruption in production applications.

  1. Certify Language Environment and Enterprise PL/I at the central development center.
  2. Install Language Environment on the central development center's system and test.
  3. Prepare a backout strategy
  4. Install the Language Environment run time at one production site.
  5. Install the Language Environment run time at all production sites.

Try to move the largest units of work that you can. Moving entire online regions, applications, or run units at once ensures that interactions between programs within an application or run unit can be tested.


Terms of use | Feedback

This information center is powered by Eclipse technology. (http://www.eclipse.org)