• Which "Language Environment" releases shipped with which z/VM and VM/ESA releases ?
• Is there an overview of Language Environment on z/VM ?
• What service is available for z/VM LE 5.4.0 ?
• What service is available for z/VM LE 4.4.0 ?
• What are some reasons for increased virtual storage use in various LE levels?
• Why did the ALL31 and STACK options change in z/VM 4.4.0 and how do I change them back?
• How can I run multiple copies of LE from shared segments on my system ?

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:

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.

Back to the List of Questions

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

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

Back to the List of Questions

What service is available for z/VM 5.4.0 LE?

The table below lists all z/VM 5.4.0 LE APARs and PTFs, chronologically, from most recent to oldest.

Back to the List of Questions

What service is available for z/VM 4.4.0 LE?

The table below lists all z/VM 4.4.0 LE APARs and PTFs, chronologically, from most recent to oldest.

Back to the List of Questions

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.

• 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.

Back to the List of Questions

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.

Back to the List of Questions

How can I run multiple copies of LE from 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 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 the 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, SCEE4 and SCEEX4. Since we already have SCEE and SCEEX entries in the SYSTEM SEGID file, the new SCEE4 and SCEEX4 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 SCEEX4 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 1.8. We want the SCEE4 and SCEEX4 shared segments to contain the code for z/VM 4.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 SCEE4 and SCEEX4 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 SCEE4/SCEEX4 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 SCEE4 and SCEEX4 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 SCEEX4, we could issue from the CMS command line the following:

1. SEGMENT ASSIGN CEEEV003 SCEEX4
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 SCEE4 and SCEEX4 segments. The LE440 EXEC shown below should be run shortly after CMS initialization completes or from the CMS SYSPROF EXEC to ensure the z/VM 4.4.0 LE code is always invoked.

   /*------------------------------*/
   /*  LE440 EXEC                  */
   /*                              */
   /*  Get the z/VM 4.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  SCEE4'
   'SEGMENT ASSIGN  CEEBLIIA  SCEE4'
   'SEGMENT ASSIGN  CEEPIPI   SCEE4'
   'SEGMENT ASSIGN  CEEBPICI  SCEE4'
   'SEGMENT ASSIGN  IBMRLIB1  SCEE4'
   'SEGMENT ASSIGN  IBMRCOMP  SCEE4'
 
   /*------------------------------*/
   /*  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   SCEEX4'
   'SEGMENT ASSIGN  CEEPLPKA  SCEEX4'
   'SEGMENT ASSIGN  CEEMUEN0  SCEEX4'
   'SEGMENT ASSIGN  CEEMUEN2  SCEEX4'
   'SEGMENT ASSIGN  CEEMUEN3  SCEEX4'
   'SEGMENT ASSIGN  CEEMUEN4  SCEEX4'
   'SEGMENT ASSIGN  CEEMUEN5  SCEEX4'
   'SEGMENT ASSIGN  CEEPLPKA  SCEEX4'
   'SEGMENT ASSIGN  CEEMENU0  SCEEX4'
   'SEGMENT ASSIGN  CEEMENU2  SCEEX4'
   'SEGMENT ASSIGN  CEEMENU3  SCEEX4'
   'SEGMENT ASSIGN  CEEMENU4  SCEEX4'
   'SEGMENT ASSIGN  CEEMENU5  SCEEX4'
   'SEGMENT ASSIGN  CEEMJPN0  SCEEX4'
   'SEGMENT ASSIGN  CEEMJPN2  SCEEX4'
   'SEGMENT ASSIGN  CEEMJPN3  SCEEX4'
   'SEGMENT ASSIGN  CEEMJPN4  SCEEX4'
   'SEGMENT ASSIGN  CEEMJPN5  SCEEX4'
   'SEGMENT ASSIGN  CEEEV003  SCEEX4'
   'SEGMENT ASSIGN  EDCNINSP  SCEEX4'
   'SEGMENT ASSIGN  EDCZ24    SCEEX4'
   'SEGMENT ASSIGN  EDCZEMSG  SCEEX4'
   'SEGMENT ASSIGN  EDCZJMSG  SCEEX4'
   'SEGMENT ASSIGN  EDCZUMSG  SCEEX4'
   'SEGMENT ASSIGN  CEEEV005  SCEEX4'
   'SEGMENT ASSIGN  IGZINSH   SCEEX4'
   'SEGMENT ASSIGN  IIGZMSGT  SCEEX4'
   'SEGMENT ASSIGN  IGZCMGEN  SCEEX4'
   'SEGMENT ASSIGN  IGZCMGJA  SCEEX4'
   'SEGMENT ASSIGN  IGZCPAC   SCEEX4'
   'SEGMENT ASSIGN  IGZCPCO   SCEEX4'
   'SEGMENT ASSIGN  CEEEV010  SCEEX4'

In the sample exec above, we assign all the SCEE logical segments to the SCEE4 shared segment and we assign all the SCEEX logical segments to the SCEEX4 shared segment. Additionally, we force the load of the SCEE4 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.

Back to the List of Questions

Download the DST 2007 PTF

1. Download UM31924 VMARC to your work station.

2. Upload the VMARC file from your work station to your z/VM system. You must transfer the VMARC file in binary format.

3. Unpack the VMARC file

   You must have a copy of the VMARC MODULE to unpack the UM31924 VMARC file. To get a copy of the VMARC MODULE, see the VM download information page.

   1. Access the minidisk or SFS directory, where the VMARC file is stored, as file mode A.

   2. Convert the UM31924 VMARC file to the CMS VMARC format:

      pipe < um31924 vmarc a
           | fblock 80 00
           | > um31924 vmarc a f 80
      

   3. Unpack and expand the UM31924 VMARC file:

      vmarc unpk um31924 vmarc a
      

      This VMARC UNPK will place one file on filemode A. This is the PTF envelope, UM31924 SERVLINK.

4. You can now follow the normal VMSES/E PTF installation process to apply this PTF to your system.

Back to the list of available service