[Edge Home] [Edge Portfolio Analyzer] [What's New]
[Language Environment] [Portfolio Management] [Consulting & Training]
[About Edge] [Edge Partners] [Edge Downloads]


The Language Environment
Challenge



IBM's Language Environment (LE) for OS/390 and z/OS operating systems is a different environment from language environments in the past. While generally achieving its objectives of upward compatibility (and even some limited downward compatibility), coexistence of multiple levels of compiled code, and ease of migration, LE has also introduced new levels of complexity and areas where changes should be made in application development processes and areas of potential problems in program development and system operation.

Before LE

Before the introduction of LE, languages and their operation and management were less complex and easier to maintain. Each language your facility chose to use came with a single product — its own compiler and a unique run-time library of common routines. Compilers and run-time libraries were self-contained with no hooks or connections to the operating system. Fixes were infrequent and updates seldom. Introductions of new language versions merely added a new compiler and run-time library that ran in conjunction with the previous versions — for example, moving to VS COBOL II just meant adding its compiler and run-time library to the existing OS/VS COBOL compiler and its run-time library. Consequently, language environments were relatively stable and provided little opportunity for trouble. In fact, in many facilities, language management was delegated to the most junior systems programers.

The New Environment

LE, on the other hand, is much more complex. LE consists of compiler-only products with a single common run-time library, a compatibility library, of routines for all LE participating languages. Consequently, all participating languages are connected to LE and its compatibility library as well as to their own LE compilers and their own existing compilers and run-time libraries.

One of the LE requirements is to only use the LE library, instead of the distribution libraries provided with the compilers. However, some programs continue to use a combination of libraries under LE such as the VS COBOL II run-time library, and the OS/VS COBOL run-time library. This arrangement is NOT supported and, if not identified, will ultimately result in hard to diagnose errors. This adds a distinct level of complexity to your language environment and operations. Further, while to assure upward compatibility, LE routines in the compatibility library are functionally equivalent to, and have duplicate names of routines in existing run-time libraries, they use different code, which also presents a definite potential for difficulties.

In addition, LE is an integral part of the operating system, is used by operating system components, and is enhanced and upgraded with the frequency that the operating system is enhanced and upgraded — a new release every six months with maintenance in between. Sometimes, functional changes in a release require coordination with application programs. For example, the change from OS/390 v2.8 to v2.9 caused COBOL programs with certain options [DATA(31) and RENT] to fail if there was an AMODE(24) component in the application. One of the Edge Portfolio Analyzer's External Analyzers identifies modules where this situation is present.

Also, compilers are no longer static programs under LE — upgrades are more frequent, as are new versions. Migrating to a new compiler is more complicated than before and usually requires LE coordination.

The constantly changing LE environment virtually assures that production program components will become incompatible with each other, with run-time routines, or with other elements of the operating environment. And the resulting inevitable blowup definitely assures reduced production and increased debugging time. Assuring component compatibility requires adherence to two rules — the fundamental rules to successful LE management:

Fundamental Rule #1

The run-time package must be at a product and maintenance level equal to, or later than, any compiled code which is executed under the run-time package.


Fundamental Rule #2

All dynamic run-time package components must be at a product and maintenance level equal to, or later than, any linked-in run-time component which is executed under the run-time package.

LE's introduction of an additional run-time library and the frequent updates to LE, its compilers, and its compatibility library make managing the LE environment much more complex and critical. While, starting with OS/390 v2.10, there is limited downward compatibility, it is still necessary to know what you have as well as the rules governing compatibility.

Managing the language environment under LE has moved beyond the level of junior systems programmers. Successfully managing LE requires a dedicated, systematic, and continuing approach at all levels of systems operations and applications development.

Managing LE

Managing the LE environment encompasses four areas: LE migration, ongoing operating system and LE maintenance, compiler upgrades, and subsystem migration. Successfully managing the LE environment requires close and continuous attention to each of these.

LE Migration

At the highest level, moving a facility's run-time usage to the OS/390 or z/OS Language Environment consists simply of eliminating references to old libraries and then removing any STEPLIBs required during transition. (Of course, you may want to retain the old libraries for recovery, just in case.) After LE run-time is proven, you can begin using the new LE-based compilers, starting with subroutines and working toward mainlines. However, achieving a successful LE migration requires diligent management of two key issues: maintaining run-time compatibility and eliminating incompatible functions among run-time modules.

Maintaining run-time compatibility may, and usually does, require ReLink or ReCompile of load modules, especially where you have modules with mixed library levels, or COBOL programs with mixed RES and NORES instructions, or Assembler that is not AMODE/RMODE ready. Incompatible functions that may need to be eliminated include "Assembler Helpers" that perform LINKs or other incompatible SVCs, homegrown error handlers, and new, and usually unexpected, program behavior resulting from changes to run-time options. InterLanguage Communications (ILC) is a particular area in which incompatible function problems may, and invariably do, occur.

Because ILC applications are built from two or more high-level languages (HLLs), and frequently, assembler also, they run outside of the realm of a single language's environment. This creates special conditions, such as how the languages' data maps across load module boundaries, how conditions are handled, or how data can be called and received by each language. To achieve LE's objective to provide cooperative support for running mixed-language applications without the overhead of multiple libraries and library initialization, under Language Environment ILC applications run in just one environment--LE.

Consequently, under LE, your ILC applications must follow the LE program model and handle conditions cooperatively. The intent is to make program execution and exception and condition handling consistent and predictable. To realize this consistency and predictability, you must make sure all your ILC applications are LE-conforming, i.e., they must adhere to LE's common interface. To successfully mix HLL and LE operations, application code needs to follow the rules in the LE programming guide as well as the rules in each compiler programming guide. Failure to do so is a guarantee of run-time problems. For example, a common LE ILC problem is assembler interacting with an HLL against the rules LE requires.

While migrating to LE can be as easy as just installing and running it -- there are facilities that have done this successfully -- the reality when moving to LE is that the potential for run-time difficulties is great and the probability that problems will arise is high. Prudence dictates that the migration be carefully managed.

The easiest migrations are preceded by the proper preparations. One of the more difficult tasks in any migration is understanding all the components that must be migrated, their relationships to each other, and their potential dependencies on system functions. Determining your migration options requires a detailed analysis of your system.

The first step in preparing for LE migration is to inventory your applications to identify what you already have running in production. For each application, you need to determine:

The second step is to fix what won't run as is. You need to:

Obviously, analyzing all your applications to this level of detail is a daunting task. Even assuming that your facility has complete and up-to-date documentation of all source, compile, and link-edit code, a dubious circumstance at most facilities, searching through all your application and production code by hand is an intimidating, arduous, and resource-consuming task at best. And, as the number of programs you must analyze rises from hundreds to thousands to tens of thousands, the probability of achieving a successful migration quickly approaches the impossible.

One way to assure a successful migration is to use software tools to automate your analysis to determine what you have and what meets the most common "won't work" scenarios under LE. You can buy them, or build your own, but tools can reduce months of work into weeks, or even days.

One such product, the Edge Portfolio Analyzer (EPA), analyzes production load libraries and extracts information about what is running in your system, even if you have few or no written records. The EPA lets you look at your application load modules and flags problem modules prior to migration. Additional analyzers, included with the EPA, can be easily tailored to further focus the scope of your analysis. The Edge Portfolio Analyzer:

Through the use of automation you can do in hours what many facilities have not been able to do in years.

Migrating to LE requires significant management commitment and effort.

Four Migration Insights:

  1. To know where you're going, you must know where you've been.
  2. You must know what you have to migrate.
  3. Plan, plan, plan ...
  4. Migration is an ongoing process.

The Migration Continues -- Ongoing Operating System and LE Maintenance

Updates to LE are now a regular part of OS/390 and z/OS maintenance, so each new release or maintenance upgrade can present new challenges. One area of particular concern, for example, is that some PTFs make changes to run-time modules that are incompatible with other run-time modules from earlier releases. Unless load modules containing these incompatible modules are relinked, the program may experience a variety of problems during execution. However, identifying the load modules containing incompatibilities is easier said than done.

Again, the Edge Portfolio Analyzer's automation tools make managing your LE environment easier. For example, the Analyzer can identify load modules containing incompatible run-time modules. In addition, some External Analyzers can generate linkage editor control statements to re-link the affected modules.

Compiler Upgrades

Under the new environment, compilers are no longer static, but are regularly updated, with new products being introduced frequently. These compiler upgrades require coordination with LE. And if you have mixed-language applications, upgrading one compiler may require coordination with other language compilers as well.

Compiler updates often produce run-time situations similar to those encountered in LE maintenance, and new compiler products frequently require the full-blown endeavors of LE migration. Once more, as in both LE migration and LE maintenance, automation tools such as the Edge Portfolio Analyzer can ease and speed your management efforts.

Subsystem Migration

Under LE, subsystems such as CICS, IMS, and DB2, work more closely with languages than they did in the past and incorporate LE requirements.

New versions of these subsystem have restrictions on language levels they support and may not work with older compilers. For example, the forthcoming version of CICS will no longer run programs compiled by the OS/VS COBOL compiler.

Here again, the automation provided by the Edge Portfolio Analyzer can expedite many of these subsystem migration tasks by identifying load modules that no longer conform to the subsystem's new requirements.

[Edge Home] [Edge Portfolio Analyzer] [What's New]
[Language Environment] [Portfolio Management] [Consulting & Training]
[About Edge] [Edge Partners] [Edge Downloads]


Copyright ©, 2007, Edge Information Group, Inc.
Revision: 3.2 (15 June 2007)
Send comments to: Webmaster