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.
In 2001, another LE for VSE was needed for the 2001 to 2002 development cycle to be shipped with the next release of VSE/ESA. Several improvements had been requested by both level 2 support personal and customers. The development team reviewed these for possible inclusion; they also reviewed current LE z/OS development items that may be applicable to the VSE product. From all these sources, several development items were agreed upon and developed for LE for VSE/ESA 1.4.2. Of notable interest was the LE z/OS development item of directing LE CEE5DMP output to another destination other than CESE that was quickly and easily accessible and wasn’t susceptible to other CICS transactions (or CICS itself), intermixing output information with CEE5DMP output or the dump lines being wrapped around to the next output line.
The LE z/OS solution was to include the CEE dump output in with the CICS transaction dump so both were available from the same file and could be reported on together. A slightly different implementation had to be designed if LE for VSE was to gain this improvement. The lead developer for LE for VSE designed an interface into the VSE/ POWER spool system for LE to use under CICS. This meant LE for VSE could now write its CEE5DMP output directly to individual VSE/POWER output spool queue members, allowing quick access to the CEE5DMP output by application or systems programmers and removing the intermixing problems associated with using the CICS transient data queue, CESE. A benefit of this was that no reporting program was required to access the LE/CICS produced dump output. The LST queue member could even be sent directly to a server via File Transfer Protocol (FTP) for analysis by level 2 and change team support teams. A few other improvements were also included in LE for VSE 1.4.2: CEEPIPI pre-initialization service support improvements, TCP/IP socket Application Program Interface (API) additions, and some further CICS storage usage optimizations.
LE for VSE/ESA 1.4.2 was shipped as planned with VSE/ESA 2.6 in December 2001. Again, customers were pleased with the improvements, especially with the new VSE/POWER LST queue support for dumps produced under CICS. A few minor improvements were requested to this feature and were delivered as PTFs (APARs PQ58992, PQ67005, and PQ72056).
With the announcement of VSE/ESA 2.7 and continued z/OS affinity, another LE for VSE level was required. Again, several customer and level 2 support team requests were identified and the LE z/OS development item database searched for any appropriate or required items. The LE for VSE development team discussed all the requested enhancements and decided upon several that could be included into the new LE for VSE/ESA 1.4.3.
The COBOL/VSE compiler development team was busy working on including the SYSDEBUG side file support from COBOL z/OS into the COBOL/VSE compiler. This compiler development would also mean a large change to the LE/COBOL run-time, so it was decided to include this requirement in the enhancements for LE for VSE/ESA 1.4.3. This support meant that COBOL customers could now compile their programs using TEST(NONE,SYM,SEP) and the compiler would store the debugging information and symbol table in a separate librarian member with the file type of SYSDEBUG. This would remove all this information from the COBOL application PHASE, allowing these compiler options to be used in a production environment without impacting the amount of storage a COBOL application PHASE would require when loaded. Then, if a failure occurred, the appropriate SYSDEBUG member would be read by the LE/ COBOL run-time to extract the required debugging information that could then be included in the LE CEE5DMP output.
The previously developed VSE/ POWER LST queue support was enhanced to allow easier tailoring of the output spooling options by providing a macro (CEELOPT) that was included as part of the LE run-time options PHASE. Mainframe Dead? Hardly! CLER CICS transaction is another enhancement from LE z/OS that was selected. The development team reviewed the LE z/OS CLER features and decided that LE for VSE would provide a much improved version of this feature. The CLER CICS transaction lets a user or CICS systems programmer dynamically alter a selected number of LE for VSE run-time options by altering the displayed values on a CICS panel. These changes are then made active and any subsequent CICS transactions started that use LE programs will use the new settings.
Another LE z/OS enhancement provided was the HEAPCHK run-time option change to support the storage leak report. This enhancement lets programmers detect any storage leaks their applications may have by reviewing the report produced when this run-time option is enabled. Programming interface enhancements ported from LE z/ OS also included the CEEFETCH/ CEERELES assembler macros combined with the appropriate run-time support and further improvements to the CEEPIPI pre-initialization service.
LE for VSE/ESA 1.4.3 was delivered as part of VSE/ESA 2.7 in March 2003.
With major support being shown for VSE in the announcement of z/VSE 3.1, we again needed to look at supplying a more efficient LE product that had improved user interfaces like none before it. There were again several customer and level 2 support team requests for improvements; these were discussed along with recent LE z/OS enhancements and directions. One of the more important items being implemented was to add the updated euro currency support from LE z/OS to LE for VSE to provide improved customer application data transmission and interface support between euro and non-euro countries. Due to the strong affinity between the two LEs, it was necessary that the VSE code be ported from z/ OS. This was difficult, since the z/OS code was still being developed and changed. Fortunately, the enhancement was completed with affinity to the z/ OS implementation.
Another LE z/OS enhancement that was appealing was the console command interface to allow display and modification of LE batch environment run-time options. This looked really good for implementing on VSE but the development team had some reservations about the modification ability. So, it decided that initially, the display support would be provided with some further improvements over what was available with the LE z/OS feature. The VSE/AF development team made the required modifications to the attention routine interface and the LE development team designed and developed an attention command support component that could provide the required information.
A routine was also developed to gather some installation details for the attention routine commands. This meant a total of three attention routine commands were implemented solely for LE use and to provide information on the installation status, user exit status, and the currently active batch environment default run-time option settings. All are available to the operator or systems programmer via a set of simple CEE-specific attention routine commands. Some previous features have also been enhanced. The VSE/POWER LST queue support for CEE5DMP output under CICS has been improved to support the batch environment. This means that CEE5DMP output created during a batch application run can be written directly to a VSE/POWER LST queue member and not included in the applications spooled output simply by setting the appropriate run-time options.
Storage usage monitoring was also noted as an area for improvement, so the LE for VSE storage manager was modified to use subpool identification names that could be displayed whenever an operator or systems programmer used the VSE GETVIS command on a partition that was executing an LE application program. The previously ported CEEFETCH and CEERELES macros from LE z/OS were enhanced to support COBOL/VSE (RENT only) target modules where previously only C/ VSE and PL/1 VSE load modules were supported.
LE for VSE 1.4.4 was released in March 2005 and is now supplied as part of the VSE/AF Central Functions with z/VSE 3.1.
