Last Updated: 1 May 2025

z/VM Language Environment



 

Which "Language Environment" releases shipped with which z/VM and VM/ESA releases?

The following table lists the LE levels supplied as part of the z/VM and VM/ESA install bases:

VM Release CMS Level Language Environment Level
z/VM 7.4
z/VM 7.3 		CMS 32
CMS 31 		LE 7.3 C/C++, COBOL, and PL/I run-time libraries
(Roughly equivalent to z/OS 2.5 LE)
z/VM 7.2
z/VM 7.1
z/VM 6.4
z/VM 6.3
z/VM 6.2 		CMS 30
CMS 29
CMS 28
CMS 27
CMS 26 		LE 6.2 C/C++, COBOL, and PL/I run-time libraries
(Roughly equivalent to z/OS 1.12 LE)
z/VM 6.1
z/VM 5.4
 CMS 25
CMS 24 		LE 5.4 C/C++, COBOL, and PL/I run-time libraries
(Roughly equivalent to z/OS 1.9 LE)
z/VM 5.3
z/VM 5.2
z/VM 5.1
z/VM 4.4 		CMS 23
CMS 22
CMS 21
CMS 20 		LE 4.4 C/C++, COBOL, and PL/I run-time libraries
(Roughly equivalent to z/OS 1.4 LE)
z/VM 4.3
z/VM 4.2
z/VM 4.1
z/VM 3.1
VM/ESA 2.4
VM/ESA 2.3 		CMS 19
CMS 18
CMS 17
CMS 16
CMS 15
CMS 14 		LE 1.8 C, COBOL, PL/I run-time libraries
VM/ESA 2.2 CMS 13 LE 1.6 C run-time library only
VM/ESA 2.1 CMS 12 LE 1.5 C run-time library only

Highlighted z/VM releases in the table above are still in service. Refer to VM End of Service Effective Dates for information on when each z/VM release reaches end of service.



Is there an overview of Language Environment on z/VM?

The following presentations may help in explaining Language Environment on z/VM:

Title Description Material
Language Environment Overview, Setup and Customization on z/VM a bit old, but does provide an overview of Language Environment on z/VM. (pdf)
Diagnosing Common Application Problems Under LE on VM/ESA a bit old, but provides some application debugging hints and tips (pdf)
z/VM OpenExtensions the z/VM OpenExtensions support makes heavy use of the C runtime library in LE z/VM OpenExtensions



What compilers run on z/VM LE?

Language Environment is the prerequisite run-time environment for applications generated with the following IBM compiler products:

In many cases, you can run compiled code generated from the previous versions of the above compilers. A set of assembler macros is also provided to allow assembler programs to run within Language Environment.



What are some reasons for increased virtual storage use in various LE levels?

The amount of virtual storage consumed by LE over its lifetime has continued to grow. There are several reasons for this, some of which are listed here.

  • The LE code base has continued to grow over the years and many parts which originally had to reside below the 16M line now reside above that line. The LE code which must reside below 16M consumes approximately 40K of virtual storage. This code should be saved in the SCEE shared segment to help improve overall system performance.

    The LE code which can run above 16M consumes approximately 7M of virtual storage. It becomes a necessity to save this code in the SCEEX shared segment to both improve overall system performance and, most importantly, to avoid loading all 7M of LE code into a user's virtual storage.

  • The C sockets library code introduced in LE 1.8 with APAR PQ44028 and carried into z/VM 4.4.0 LE defines all socket descriptors as POSIX file descriptors. POSIX file descriptors are defined in CMS as part of the Byte File System (BFS) client services. When the BFS client services are initialized in a virtual machine, the BFS control blocks consume approximately 4.5M of contiguous virtual storage. If you are using any application which uses LE C sockets calls, you need to increase your virtual storage by at least 5M just to handle these control blocks. TCP/IP applications such as NFS (z/VM 3.1.0), PING (z/VM 5.1.0), and TRACERTE (z/VM 5.1.0) all use the LE C sockets interfaces and require additional virtual storage to execute. Also, in z/VM 5.1.0, the DoGetAddrInfo and DoGetNameInfo routines in CMRESOL were rewritten to call the new ported resolver routines, so things that use them also use the new resolver. The things that use these functions are almost all the z/VM TCP/IP functions and utilities.

  • Starting with z/VM 4.4.0, the LE HEAP and STACK storage areas will be obtained anywhere in virtual storage, i.e. above or below the 16M line. The initial size obtained is 32K for HEAP storage and 128K for STACK storage with increments of 32K and 128K, respectively. Also, there are 4K chunks of storage obtained at LE initialization for LIBSTACK, THREADHEAP, and THREADSTACK storage. If the LE-enabled application is long running, deeply nested in calls, or is heavily threaded, you will need to ensure there is enough virtual storage to handle the application. All the HEAP and STACK values can be customized by modifying CEEDOPT ASSEMBLE at the system level or CEEUOPT ASSEMBLE at the user/application level. The customization of CEEDOPT can be done using the CUSTLE EXEC.



Why did the ALL31 and STACK options change in z/VM 4.4.0 and how do I change them back?

The global LE defaults were changed in z/VM 4.4.0 from ALL31(OFF) to ALL31(ON) and from STACK(,,BELOW) to STACK(,,ANYWHERE). This was done primarily because there had been significant changes made to the z/OS LE code which was ported to z/VM 4.4.0. Undoing those changes would have been nearly impossible, so z/VM was left with keeping the defaults changes in place. With that as an explanation of why the changes were made, let's discuss how you can alter the defaults.

There are several ways to change the default settings for ALL31 and STACK.

  1. To change the defaults at the system level, from MAINT, run the command

    CUSTLE ZVM LE

    Select option 

    "1.  Run Time Options"
    . You will then be placed in an XEDIT session of CEEDOPT ASSEMBLE. Look for the ALL31 and STACK options and make certain they read as follows:
    ALL31=((OFF),OVR),
    
      STACK=((128K,128K,BELOW,KEEP,512K,128K),OVR),

    After making the changes in CEEDOPT ASSEMBLE, issue FILE on the XEDIT command line. Several LE MODULEs will be rebuilt. WARNING: Changing CEEDOPT will change the defaults for EVERY application built after the change goes into effect.

  2. There is a user version of CEEDOPT ASSEMBLE named CEEUOPT ASSEMBLE. A copy of which should be on the Y-disk (MAINT'S 19E disk). XEDIT CEEUOPT ASSEMBLE, make the same changes as described in #1, FILE the updated copy if CEEUOPT ASSEMBLE on your A-disk, issue the command "GLOBAL MACLIB SCEEMAC", and then issue "HLASM CEEUOPT". There will now be a CEEUOPT TEXT on the user's A-disk. When you rebuild the application you need to add CEEUOPT TEXT to the list of TEXT files included in the MODULE build. Keeping the altered copy of CEEUOPT TEXT around will ensure that the application will always be built as ALL31(OFF) and STACK(,,BELOW).

  3. You can also specify these runtime options when the application is run. If the application name is TEST123, from the CMS command line or from an EXEC, issue the command as

        TEST123 ALL31(OFF) STACK(,,BELOW)/inputparameters

    The "/" separates the LE runtime options from the application input parameters.

    The above only works for non-COBOL programs that use the default LE run-time options (CBLOPTS(ON) is in effect). If TEST123 is a COBOL program, then you need to use the format of:

        TEST123 inputparameters/ALL31(OFF) STACK(,,BELOW)

    Notice that the input parameters are first when COBOL is the "main" LE program with CBLOPTS(ON) in effect. If the LE run-time option CBLOPTS(OFF) is in effect, then the order is reversed:

        TEST123 ALL31(OFF) STACK(,,BELOW)/inputparameters

  4. If the application is written in C or PL/I, the runtime options can be specified in the source code. At the beginning of a C program, specify the following:

        #pragma runopts (ALL31(OFF), STACK(,,BELOW))

    At the beginning of a PL/I program, you should specify the following

        DCL PLIXOPT CHAR(25) VAR INIT('ALL31(OFF),STACK(,,BELOW)') STATIC EXTERNAL;

    If the application is written in COBOL, there is no way to specify runtime options in the COBOL source code.

The topic of changing runtime options can be found in the "z/OS V1R4.0 Language Environment Programming Guide" under the heading "Specifying Run-time Options". Yes, that is the z/OS LE book. Since the z/VM LE code was ported from the z/OS LE code, we also "piggy-backed" off the z/OS books. There is a "z/VM V4R4.0 Language Environment User's Guide" which covers the differences between the z/VM and z/OS LE code.



How can I run multiple copies of LE from DCSS (shared segments) on my system?

There are three parts to each LE runtime library:

  1. The code on minidisk (the 19E)
  2. The SCEE shared segment - contains code which must run below 16M
  3. The SCEEX shared segment - contains code which can run anywhere

The LE DCSS (shared segments) are optionally installed, but if there are many users running C/C++, COBOL, or PL/I applications, having the shared segments defined and saved will help overall system performance. If the shared segments are installed, then all three of these pieces must be at the same version and release level for LE to work properly and not ABEND.

Internally, LE uses the CMS SEGMENT LOAD function to load the shared code from the two shared segments. The contents of the SCEE and SCEEX shared segments consist of the LE MODULEs and both shared segments are created using the CMS SEGGEN command. When a shared segment is saved with SEGGEN, an entry for the physical segment, e.g. SCEEX, is placed in the CMS SYSTEM SEGID file on the S-disk. Additionally, logical segment entries are created in the SYSTEM SEGID for each LE MODULE contained in the shared segment. When LE determines it should load the C/C++ runtime library code, a SEGMENT LOAD CEEEV003 function is issued and the CEEEV003 member of the SCEEX shared segment is loaded for use.

The drawback to the above scenario is that SEGMENT LOAD will look for the first occurrence of the "logical segment", i.e. the MODULE, in the SYSTEM SEGID file. In our example, the first occurrence of CEEEV003 in SYSTEM SEGID appears under the SCEEX shared segment and that copy will be loaded.

Let's say we have created and saved a second set of LE shared segments, SCEE54 and SCEEX54. Since we already have SCEE and SCEEX entries in the SYSTEM SEGID file, the new SCEE54 and SCEEX54 entries will come second in the file. Since SEGMENT LOAD looks for the first occurrence of the MODULE, it will always find it in the SCEEX shared segment, even if we really want the copy in the SCEEX54 shared segment.

You can run multiple levels of LE on a single system and have multiple SCEE and SCEEX shared segments installed. It simply requires a little manipulation of pointers to the shared segments. Keeping with our examples above, the current SCEE and SCEEX shared segments contain the code for LE 4.4.0. We want the SCEE54 and SCEEX54 shared segments to contain the code for z/VM 5.4.0 LE. The Saved Segments Planning and Administration book explains the process of defining and saving a shared segment. Also, the VMSES/E VMFSGMAP command can be used to create the shared segments.

We first create new SCEE54 and SCEEX54 shared segments, running SEGGEN to save the contents. In addition to saving the shared segments, SEGGEN updates the SYSTEM SEGID file to show the presence of SCEE/SCEEX and SCEE54/SCEEX54 shared segments. The logical segment definitions under each of these will list similar names. We now want to make certain we always use the new SCEE54 and SCEEX54 shared segments when we run. We accomplish this using a series of SEGMENT ASSIGN commands. SEGMENT ASSIGN tells CMS which physical segment contains the logical segment specified on a SEGMENT LOAD command. Thus, to tell CMS to load CEEEV003 from SCEEX54, we could issue from the CMS command line the following:

  1. SEGMENT ASSIGN CEEEV003 SCEEX54
  2. SEGMENT LOAD CEEEV003

As mentioned previously, the SEGMENT LOAD commands all happen internally in LE. Therefore, to ensure we always use the same levels of LE code, we need to ensure we tell CMS to always use the SCEE54 and SCEEX54 segments. The LE540 EXEC shown below should be run shortly after CMS initialization completes or from the CMS SYSPROF EXEC to ensure the z/VM 5.4.0 LE code is always invoked. 

   /*------------------------------*/
   /*  LE540 EXEC                  */
   /*                              */
   /*  Get the z/VM 5.4.0 LE disk  */
   /*  N.B. If the LE code is on   */
   /*  19E Y-disk, we can skip the */
   /*  LINK and ACCESS commands.   */
   /*------------------------------*/
 
   'CP LINK MAINT 49E 49E RR'
   'ACCESS 49E R'
   'GLOBAL LOADLIB SCEERUN'
 
   /*------------------------------*/
   /*  Reassign the SCEE members   */
   /*------------------------------*/
   'SEGMENT ASSIGN  CEEBINIT  SCEE54'
   'SEGMENT ASSIGN  CEEBLIIA  SCEE54'
   'SEGMENT ASSIGN  CEEPIPI   SCEE54'
   'SEGMENT ASSIGN  CEEBPICI  SCEE54'
   'SEGMENT ASSIGN  IBMRLIB1  SCEE54'
   'SEGMENT ASSIGN  IBMRCOMP  SCEE54'
 
   /*------------------------------*/
   /*  Load up the SCEE members    */
   /*------------------------------*/
   'SEGMENT LOAD  CEEBINIT'
   'SEGMENT LOAD  CEEBLIIA'
   'SEGMENT LOAD  CEEPIPI '
   'SEGMENT LOAD  CEEBPICI'
   'SEGMENT LOAD  IBMRLIB1'
   'SEGMENT LOAD  IBMRCOMP'
 
   /*------------------------------*/
   /*  Reassign the SCEEX members  */
   /*------------------------------*/
   'SEGMENT ASSIGN  CEECOPP   SCEEX54'
   'SEGMENT ASSIGN  CEEPLPKA  SCEEX54'
   'SEGMENT ASSIGN  CEEMUEN0  SCEEX54'
   'SEGMENT ASSIGN  CEEMUEN2  SCEEX54'
   'SEGMENT ASSIGN  CEEMUEN3  SCEEX54'
   'SEGMENT ASSIGN  CEEMUEN4  SCEEX54'
   'SEGMENT ASSIGN  CEEMUEN5  SCEEX54'
   'SEGMENT ASSIGN  CEEPLPKA  SCEEX54'
   'SEGMENT ASSIGN  CEEMENU0  SCEEX54'
   'SEGMENT ASSIGN  CEEMENU2  SCEEX54'
   'SEGMENT ASSIGN  CEEMENU3  SCEEX54'
   'SEGMENT ASSIGN  CEEMENU4  SCEEX54'
   'SEGMENT ASSIGN  CEEMENU5  SCEEX54'
   'SEGMENT ASSIGN  CEEMJPN0  SCEEX54'
   'SEGMENT ASSIGN  CEEMJPN2  SCEEX54'
   'SEGMENT ASSIGN  CEEMJPN3  SCEEX54'
   'SEGMENT ASSIGN  CEEMJPN4  SCEEX54'
   'SEGMENT ASSIGN  CEEMJPN5  SCEEX54'
   'SEGMENT ASSIGN  CEEEV003  SCEEX54'
   'SEGMENT ASSIGN  EDCNINSP  SCEEX54'
   'SEGMENT ASSIGN  EDCZ24    SCEEX54'
   'SEGMENT ASSIGN  EDCZEMSG  SCEEX54'
   'SEGMENT ASSIGN  EDCZJMSG  SCEEX54'
   'SEGMENT ASSIGN  EDCZUMSG  SCEEX54'
   'SEGMENT ASSIGN  CEEEV005  SCEEX54'
   'SEGMENT ASSIGN  IGZINSH   SCEEX54'
   'SEGMENT ASSIGN  IIGZMSGT  SCEEX54'
   'SEGMENT ASSIGN  IGZCMGEN  SCEEX54'
   'SEGMENT ASSIGN  IGZCMGJA  SCEEX54'
   'SEGMENT ASSIGN  IGZCPAC   SCEEX54'
   'SEGMENT ASSIGN  IGZCPCO   SCEEX54'
   'SEGMENT ASSIGN  CEEEV010  SCEEX54'

In the sample exec above, we assign all the SCEE logical segments to the SCEE54 shared segment and we assign all the SCEEX logical segments to the SCEEX54 shared segment. Additionally, we force the load of the SCEE54 logical segments just for good measure. Since these logical segments (MODULEs) are loaded below the 16M line and space down there is a rare commodity, we want to ensure we always have the shared segment copies loaded. After the sample exec is run, everything LE needs to run will come from the matched minidisk and shared segments.