Skip to main content

IBM Systems  >   System z  >   z/VM  >  

z/VM Language Environment

Black holes are where God divided by zero.
- Steven Wright, comedian (1955- )


 


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  6.3.0
z/VM  6.2.0
CMS 27
CMS 26
LE 6.2.0 C/C++, COBOL, and PL/I run-time libraries
(Roughly equivalent to z/OS 1.12 LE)
z/VM  6.1.0
z/VM  5.4.0
CMS 25
CMS 24
LE 5.4.0 C/C++, COBOL, and PL/I run-time libraries
(Roughly equivalent to z/OS 1.9 LE)
z/VM  5.3.0
z/VM  5.2.0
z/VM  5.1.0
z/VM  4.4.0
CMS 23
CMS 22
CMS 21
CMS 20
LE 4.4.0 C/C++, COBOL, and PL/I run-time libraries
(Roughly equivalent to z/OS 1.4 LE)
z/VM  4.3.0
z/VM  4.2.0
z/VM  4.1.0
z/VM  3.1.0
VM/ESA  2.4.0
VM/ESA  2.3.0
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.0 CMS 13 LE 1.6 C run-time library only
VM/ESA 2.1.0 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.

Back to the List of Questions


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/OS Language Environment the base for the z/VM port of Language Environment z/OS LE
z/VM OpenExtensions the z/VM OpenExtensions support makes heavy use of the C runtime library in LE z/VM OpenExtensions

Back to the List of Questions


What service is available for z/VM 6.2.0 LE?

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

APAR PTF Abstract
VM65315 UM33978 DMSABE141T ADDRESSING EXCEPTION OCCURRED AT 8xxxxxxx IN ROUTINE xxx

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.

APAR PTF Abstract
VM65087 UM33557 ICONV_OPEN FAILS FOR XPLINK CONVERSIONS BETWEEN UTF-8 OR UCS-2 AND IBM-1047 OR IBM-037
VM64972 UM33370 ICONV_OPEN FAILS FOR UCS-2 NOXPLINK CONVERSIONS
VM64805 UM33123 ADD GET_LOADMOD_INFO FUNCTION TO CEEO1LOD
VM64739 UM32876 ABEND X'0C5' RUNNING DB2 WITH Z/VM 5.4.0 LE
VM64737 UM32877 LDAP SERVER ABENDS IN LE WITH ADDRESSING EXCEPTION
VM64566 UM32623 COLLECTION OF FIXES FOR C++ RUN-TIME
VM64522 UM32489 CMS'S OSRUN DOES NOT RECOGNIZE LE RUNTIME OPTIONS
VM64521 UM32488 LOOP IN LE CONDITION MANAGEMENT WHEN RUNNING COBOL AND PL/I

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.

APAR PTF Abstract
VM64195 UM32009 ALLOW LDAP CLIENT UTILITIES TO ACCESS MESSAGE CATALOGS AS CMS FILES
VM64124 UM31920 CUSTLE MAY FAIL WITH MESSAGE DMSPCL389E INVALID FILEMODE: APPLY_MODE
VM64066 UM31947 RC 2012 RC2012 FROM RXMQV CONNECT
VM64148 UM31943 CUSTLE MAY FAIL WITH MESSAGE DMSPCL389E INVALID FILEMODE: APPLY_MODE (PE fix to APAR VM64124 / PTF UM31920)
VM64117 UM31924 Z/VM LANGUAGE ENVIRONMENT DAYLIGHT SAVING TIME (DST) CHANGES DST2007 ENERGY POLICY ACT OF 2005 DST 2007
VM64055 UM31923 New function in Z/VM LE to support z/VM 5.3.0
VM63972 UM31714 ABEND X'0C4' USING FPRINTF() TO PUT DATA IN A FILE.
VM63885 UM31625 VAGEN Z/VM 4.4 LE U4036-02 ACCESSING DB2 UDB ON LINUX SERVER
VM63820 UM31620 LONG RUNNING C APPLICATION ABENDS WITH OUT-OF-STORAGE CONDITION
(N.B. Also needs CMS VM63819/UM31619 and TCP/IP PK15940/UK17025)
VM63755 UM31521 NEW FUNCTION IN z/VM LE (needed to run MPROUTE in z/VM 5.2.0)
VM63795 UM31480 LE-BASED APPLICATION HANGS AFTER RECOVERABLE ABEND.
VM63778 UM31470 MPROUTE NOT RESPONDING TO COMMANDS FROM AUTHORIZED USER
VM63690 UM31365 MPROUTE HANGS AFTER IOCTL() ABEND
VM63638 UM31274 DMSABE141T ABEND0C5 IN EDCOXFR6 RUNNING C-SOCKET APPLICATION.
VM63596 UM31258 LE/440 ABEND0C4 C PROGRAM OPENING VSAM FILE FOPEN()
VM63574 UM31234 FCLOSE DOES NOT FREE ALL ALLOCATED MEMORY
VM63559 UM31228 RUNNING CUSTLE RESULTS IN MESSAGE ERROR - UNABLE TO LOCATE FILE CEEDOPT ASSEMBLE.
VM63593 UM31244 ABEND AFTER FOPEN() RETURNS BAD FILE POINTER
VM63507 UM31245 VARIOUS ABENDS WHEN NON-LE CODE USES AN LE STACK FRAME FOR PROGRAM LINKAGE
VM63485 UM31172 CMOD DOES NOT KEEP TXTLIB ORDER
VM63504 UM31152 DB2 SERVER ON Z/VM 4.4 ABENDS WITH S00C4 WITH TCPIP ACTIVATED
VM63501 UM31151 ABEND 0C4 WHEN USING FREOPEN() WITH NULL FILE NAME
VM63425 UM31054 OPENVM SHELL RESULTS IN ABEND0C5
VM63409 UM31047 CUSTLE NOT BUILDING ALL EFFECTED EXECUTABLES
VM63363 UM31002 RUN OUT OF STORAGE WITH DB2 AND Z/VM LE 4.4.0

Back to the List of Questions


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.

Show me a complete history of zSeries COBOL compilers

Show me a complete history of zSeries PL/I compilers

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

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

   /*------------------------------*/
   /*  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.

 

Back to the List of Questions


Download the DST 2007 PTF for z/VM 4.4.0 LE

  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