Operating Systems

Language Environment for VSE: From the Past to the Present

2 Pages

Back in the “good ol’ days” of DOS/VS COBOL, DOS/PL1, and later C/370, there were multiple run-time components to support the different compilers and run-time functions. This meant that incorporating different languages into a single application was a bit of an educated guess. Poor execution times were possible if the application wasn’t designed correctly. This could result in run-times being initialized and terminated multiple times for each call. There were different standards for interfacing and each language had its own particular assembler interface processes. Some had good problem-handling and debugging abilities while others had little or none.

In an effort to improve this situation, MVS had developed the Common Execution Environment (CEE). VSE could accrue the same benefits MVS customers enjoyed if this product were available for VSE. So, it was decided to port Language Environment (LE)/370 for MVS 1.2 to VSE and package it as LE for VSE/ESA 1.1. Considerable development work went into providing an LE that would be compatible with old DOS/VS COBOL applications but still provide run-time support for the VS/COBOL II compiler and the newly released COBOL for VSE/ESA 1.1.0 (COBOL/VSE) compiler. The first release provided a common execution environment for COBOL/VSE, VS/ COBOL II, and PL/1 VSE users and compatibility for code produced by the older DOS/VS COBOL compiler. Assembler interfaces were standardized, support for previous COBOL pre-initialization processes retained, and new pre-initialization services introduced to improve performance when using assembler programs as drivers. This showed what CEE could do for legacy applications that were combined with code written for the newer compilers. Common storage management, message management, standard problem handling, enhanced date/time services, and a multitude of callable services were among the benefits LE provided compared to the older run-times (see Figure 1).

With the introduction of COBOL/ VSE (ANSI-85) and PL/1 VSE compilers based on LE technology, a range of debugging facilities were now available that could provide much-needed enhanced debugging capabilities for VSE users. Looking again at what had been developed on MVS, a port of the Debug Tool to VSE was performed. The Debug Tool provided a much improved interactive debugging environment for VSE application developers. This tool required a LE for C run-time. To meet that requirement, another port of LE for VSE was done. The second port used LE/370 for MVS 1.5 code and was made available as LE for VSE/ESA 1.4.0. It was initially shipped with VSE/ESA 2.2 as an optional product. Later, it was included in the base install of VSE/ESA 2.3. A port of the C/370 AD/Cycle 1.2 compiler from MVS provided a new C for VSE compiler. Included in this update of LE, another development team provided a C run-time TCP/IP interface that would allow VSE application program developers to use the new TCP/IP for VSE/ESA product.

Several small but beneficial enhancements were included in LE 1.4.0 as APARs. Improved CICS performance for application programs that used the EXEC CICS LINK or XCTL function calls, system programmer C, Year 2000 date support, locales, improved condition handling services, and the movement of many modules to above the 16MB line also helped with virtual storage constraint relief. Options such as RETZERO were introduced to provide migration assistance for those users moving from the older DOS/VS COBOL environment and mixing in COBOL/ VSE with LE. Several requested improvements were provided, one of which was the ability to control when an LE dump was to be suppressed. This was particularly beneficial in the CICS environment, where several abends, such as AKCS, for example, don’t require LE dump information.

At this point, LE entered a development cycle for the 2000 to 2001 period, which meant enhancements by APAR were limited to urgent requirements. This new development level of LE for VSE was to be included with VSE/ESA 2.5. The first development request was to ensure LE packaging and PTF installation was less dependent on user environments and to bring it in line with current VSE PTF packaging standards. This meant eliminating the need for PTFs to be link-edited on user systems and the removal of user-replaceable modules from core LE load modules.

The restructuring of the product was only half the problem. LE required two installation libraries just for COBOL. This created user confusion and problems as to when each library was to be used and under what circumstances. To correct this, LE 1.4.1 removed the “CICS-only” installation library by adding environment sensing logic to the relevant COBOL run-time routines. Now the COBOL run-time would determine at execution time which run-time support module was required dynamically. To help with determining which language run-times were supported in any CICS system that was started with LE active, messages were added to the CICS initialization process to indicate which run-times were available. CICS transactions to report on the current installation default Runtime Option Settings (ROPC) and to “new-copy,” on-the-fly CICS run-time options (NEWC) were introduced to reduce required system downtime for LE options tailoring. These changes also assist IBM support personal in retrieving vital LE options setting information when problems were reported.

The LE for VSE CICS abnormal termination exit was modified to eliminate duplicate dumps and to allow standard CICS abend codes to be reported. Multiple levels of condition handling were introduced to perform the equivalent functionality available on LE for OS/390 by adding the MIN and MAX suboptions to the TRAP run-time option. MSGFILE now supported the specification, under CICS, of any user-defined transient data queue that could then be used as the destination for LE output. Further minor enhancements were provided, including new C run-time console functions, additional TCP/IP interface support, default LE run-time options tuning, optimized LE for C run-time, and reduced SVC usage by the COBOL/ VSE date service routines.

 

This first development level of LE for VSE/ESA 1.4.1 was released in September 2000 with VSE/ESA 2.5 and was well-received. Several customers made special mention of the improvements available by the removal of the two COBOL run-time installation libraries and the improved condition-handling and supplied CICS transaction functions. Figure 2 shows a summary of the enhancements available in the first development release of LE.

2 Pages