The information herein describes changes to various aspects of TCP/IP for z/VM that warrant consideration when migrating from previous levels to the most current, supported level.

For information about changes that have been implemented in levels of TCP/IP for z/VM that are not listed here, check the Migration Considerations for End-of-Service Levels information.

Note that in a some cases, existing functions may have been deleted or replaced by alternate functions. High-level descriptions of these kinds of changes, as well as the level at which a change was introduced, are indicated in the text that follows.

Client Topics:

Server Topics:

Other Topics:

Notes:

• TCP/IP and related features are supported on associated releases of CP and CMS only.
• ( † )   Select the TCP/IP Stack server link to review information about changes introduced that establish changes to the following defaults:
  • RestrictLowPorts

Changes Introduced in TCP/IP Level 540

• The RPCINFO function has been updated to use the ETC HOSTS file as the local site table when host names are resolved. If the ETC HOSTS file is not present, RPCINFO continues to use the HOSTS SITEINFO file.

• Processing of the CERTNOCHECK operand for TLS connections associated with the FTP and Telnet clients (and, the SMTP server) has been changed such that this operand is equivalent to the CERTFULLCHECK operand.

• The TCPSLVL utility has been modified such that results now are directed to a file (named partname SLVLDATA) by default. To direct command output to the console, a new CONSOLE option must be used. For more information, see Appendix A of the TCP/IP for z/VM Level 540 Program Directory

Changes Introduced in TCP/IP Level 530

• The level of authorization to use the TRACERTE command has changed. OBEY authority is no longer required to use this command.

• The Telnet and FTP clients have been updated to accommodate Dynamic SSL/TLS support. Changes to provide this capability include support for additional command options, which include:
  • CERTFULLCHECK
  • CERTNOCHECK
  • NOSECURE
  • SECURE

• A new statement, SECURETELNETCLIENT, may now be specified in the TCPIP DATA file. This statement provides the default Telnet client security value to use when neither the SECURE nor NOSECURE option is specified on the Telnet command.

• Due to changes in CMS resolver code, there is a requirement that some TCP/IP modules such as FTP be at the 5.3.0 level when the CMS IPLed is 5.3.0. For this same reason, customer-built modules that include COMMTXT in the GLOBAL TXTLIB command (in order to use routines such as SayIntAd) must be re-built using the z/VM 5.3.0 level of COMMTXT. In addition, some TCP/IP modules require Language Environment (LE) to include APAR VM64055.

  Note that the following message will appear if either a TCP/IP routine or LE is back-level:

  DMSZER2571E A resolver request failed due to missing LE support or incorrect TCP/IP module levels.

  To work around this problem, upgrade TCP/IP and LE and re-build programs that use COMMTXT or IPL an earlier level of CMS.

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in TCP/IP Level 540

• Support is added for changing an FTP control connection from a secure state to a clear state through use of the Clear Control Connection (CCC) subcommand.

• Processing of the CERTNOCHECK operand for TLS connections associated with the FTP client has been changed such that this operand is equivalent to the CERTFULLCHECK operand.

Changes Introduced in TCP/IP Level 530

• The FTP client has been updated to accommodate Dynamic SSL/TLS support. Changes to provide this capability include support for additional command options, which include:
  • CERTFULLCHECK
  • CERTNOCHECK
  • NOSECURE
  • SECURE

  and new or updated FTP subcommands:

  • CLEAR
  • CPROTECT
  • PRIVATE
  • LOCSITE (updated to accept and process CERTFULLCHECK and CERTNOCHECK options)

  Support for SECUREDATA and SECURECONTROL statements within the FTP DATA file has been added as well.

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in TCP/IP Level 530

• The FTP server has been updated to accommodate Dynamic SSL/TLS support. Changes to provide this capability include support for additional server configuration statements, which include:
  • PASSIVEPORTRANGE
  • SECURECONTROL
  • SECUREDATA
  • TLSLABEL

  along with new or updated SMSG administrative command operands:

  • SECURE
  • TLSLABEL
  • QUERY (Updated to support an added SECURE keyword)

• The CHKIPADR server exit has been updated as well, to accommodate the use of a SECUREDATA keyword that can be used to establish minimum security levels for data connections.
• The FTP server has been modified such that it will no longer create the file FTPSERVE LOG. Messages formerly written to this file now are either directed to the server console (the case for message DTCFTS4015I) or replaced with an equivalent, existing message (message DTCFTS2512I replaces message DTCFTS2513I).

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in TCP/IP Level 540

• The mechanism for defining User IDs that are to be authorized to use the IMAPADM EXEC has changed. Instead of directly creating a $SERVER$ NAMES private resource registration file, authorized User IDs are now listed via the DTCPARMS file tag :Admin_ID_List.

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in TCP/IP Level 540

• The Lightweight Directory Access Protocol (LDAP) server (LDAPSRV) has been updated to a function level equivalent to the z/OS level 1.10 Tivoli Directory Server.

• Server plug-in support has been added, to allow the functionality of the directory server to be extended.

• Support for RACF change logging and password/phrase enveloping is introduced.

Changes Introduced in TCP/IP Level 530

• A Lightweight Directory Access Protocol server (LDAPSRV) is introduced, which provides client access to data maintained in an LDAP directory. An LDAP directory provides an easy way to maintain directory information in a central location for storage, update, retrieval, and exchange.

  For more detailed information about what functions have been implemented in the initial version of the z/VM LDAP server, see TCP/IP LDAP Administration Guide (SC24-6140).

Top of Page

Changes Introduced in TCP/IP Level 540

• NETSTAT GATE command output has been updated to include two new flags — one indicates if the MTU was modified by path MTU discovery for a given route; the other indicates whether a route was created as a result of path MTU discovery.

• NETSTAT DEVLINKS command output for an OSD device has been updated to include the OSA-Express port number, the designated transport type (ETHERNET or IP, for Layer 2 or Layer 3 mode, respectively), and local MAC address (for transport type ETHERNET only).

• (IPv4 only) NETSTAT DEVLINKS command output has been updated for all non-VIPA devices to display path MTU discovery status.

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in TCP/IP Level 530

• The MPRoute server implementation of TCP/IP for z/VM has been adapted from z/OS V1.8.
• A combination of an ip_address and a subnet_mask that describes either a subnet address or a broadcast address, is no longer accepted for the OSPF_INTERFACE, RIP_INTERFACE or INTERFACE configuration statements. This change is a result of TCP/IP server enforcement of RFC rules that restrict a subnetwork broadcast or network address from being used as a host address.

  By convention, an address that has all ones in the host portion is a subnet broadcast address, whereas an address that has all zeros in the host portion is a subnet network address. Therefore, an attempt to use an ip_address and subnet_mask combination that specifies one of these special addresses will likely lead to difficulty in communicating with other hosts on the network.

• The maximum mtu value that may be specified for the OSPF_INTERFACE, RIP_INTERFACE or INTERFACE configuration statements is now the minimum of:
  • the device buffer capacity (as reported by a HiperSockets or QDIO device; for other devices, the value is based on the device architecture)
  • the buffer_size value associated with the LARGEENVELOPEPOOLSIZE statement in the TCP/IP server configuration file.

• Note:
  The RouteD server has been withdrawn from TCP/IP level 530. The server user ID, command program, configuration statements and files associated with this server have likewise been removed from the z/VM Version 5 Release 3.0 System Deliverable.

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in TCP/IP Level 540

• The logon password default for the RXAGENT1 virtual machine has been changed to AUTOONLY, to reinforce the concept that REXEC agents should be used for handling only anonymous requests.

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in TCP/IP Level 540

• Processing of the CERTNOCHECK operand for TLS connections associated with SMTP server has been changed such that this operand is equivalent to the CERTFULLCHECK operand.

Changes Introduced in TCP/IP Level 530

• The SMTP server has been updated to accommodate Dynamic SSL/TLS support. Changes to provide this capability include support for additional server configuration statements, which include:
  • TLS
  • TLSLABEL

• The SMTP server has been enhanced to honor the DOMAINLOOKUP statement in the TCPIP DATA file. In addition, the SMTP server now uses the ETC HOSTS file for the local site table, if present. If the ETC HOSTS file is not present, SMTP uses the HOSTS SITEINFO file.

• An SMTP NAMES file restriction against using a nickname that is the same as a user ID in the list defined by that nickname is removed. With this level, you can specify a nickname that matches a user ID in that nickname list.

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in TCP/IP Level 540

• An SNMPTRAP command is introduced that can be used to generate SNMP version 1 enterprise-specific traps for reporting events to an SNMP manager.

Changes Introduced in TCP/IP Level 530

• An SNMP Subagent server is introduced which can be customized to supply a specific set of MIB variables (such as BRIDGE-MIB variables that are associated with a virtual switch). With this server, support for the use of various SNMP MIB exit routines, identified within a MIB_EXIT DATA file is added as well.

Top of Page

Changes Introduced in TCP/IP Level 540

• With the PTF for APAR PK65850, a CMS-based SSL server is provided with TCP/IP for z/VM that no longer requires operation within a Linux guest. The components required for running this updated server implementation are installed and serviced through the same means as other CMS-based TCP/IP servers.

  With this implementation, the SSL server and TCP/IP stack server interfaces have been modified, as have SSL server command (VMSSL) and DTCPARMS file configuration operands and requirements. Due to the nature of these changes, an SSL server implementation that is based on prior levels of TCP/IP for z/VM cannot be used with the TCP/IP level 540 TCP/IP server. The converse is also true — the TCP/IP level 540 SSL server cannot be used with prior levels of TCP/IP for z/VM.

  TCP/IP Level 540 SSL and TCP/IP server compatibility is summarized here:

  TCP/IP Level 540 SSL and TCP/IP Server Compatibility

  	TCP/IP Level 540 SSL Server	Prior-level SSL Server
  TCP/IP Level 540 Stack Server	Compatible	Not Compatible
  Prior-level TCP/IP Stack Server	Not Compatible	Compatible

Additional changes associated with the level 540 SSL server include:

• Use of z/OS V1.10 System SSL technology by the SSL server for encryption, decryption, and certificate management functions. Significant functional changes associated with the use of this technology include:
  • Implementation of Federal Information Processing Standard (FIPS) 140-2 is not available with this level of TCP/IP for z/VM.

  • Relaxed certificate checking, through use of selected application CERTNOCHECK options or operands, is not available at this level. Thus, self-signed certificates are accepted only if they are stored in both client- and-server-side certificate databases.

  • Addition of support for changing an FTP control connection from a secure state to a clear state through use of the FTP CCC subcommand.

  • Several cipher suites, including suites that provide 128-bit and 256-bit AES encryption, have been added. Two ciphers — RC4_EXP1024_56_SHA and DES_EXP1024_56_SHA have been removed. All other previously supported cipher suites have been renamed to more closely match specifications in RFCs 2246 and 4346.

  • z/OS System SSL will use hardware-assisted encryption and decryption through use of a processor-specific instruction, if it is available. Cryptographic cards are not supported.

• Use of the gskkyman (previously introduced with LDAP server support) for SSL server certificate management functions.

• The z/VM SSL server now references a certificate database that is maintained in the z/VM Byte File System (BFS).

• A GSKADMIN User ID has been added. This User ID has been defined with appropriate authorization to perform certificate management operations for the SSL server key database. The GSKADMIN User ID is also defined as an SSL server administrative User ID.

• The SSLADMIN command has been revised such that a network connection is no longer used to perform server administrative functions. Thus, the server administrative port (previously defined at port number 9999) is no longer used and has been removed from the TCP/IP server configuration and ETC SERVICES sample files.

• OBEY authorization is no longer used to determine SSL server administrative authority. Such authorization is now controlled by the DTCPARMS file :Admin_ID_List. tag entry.

• Additional or different DTCPARMS file configuration tags and SSL server command (VMSSL) parameters now are used for configuration of the SSL server. Detailed information about such changes are provided in TCP/IP Planning and Customization (SC24-6125).

Changes Introduced in TCP/IP Level 530

• The SSL sever has been modified to accommodate "Dynamic SSL/TLS Support," which introduces a set of Application Programming Interfaces (APIs) that permit a Pascal or Assembler client or server application to control the acceptance and establishment of TCP/IP sessions encrypted using SSL/TLS.

  To provide this capability, the interface used by the SSL server to communicate with the TCP/IP stack server has been modified. Due to the nature of these changes, one of the SSL-related RPM packages supplied with TCP/IP level 530 must be used for SSL server setup and configuration. Note also that the TCP/IP level 530 SSL server cannot be used with prior levels of TCP/IP for z/VM.

  TCP/IP Level 530 SSL and TCP/IP server compatibility is summarized here:

  TCP/IP Level 530 SSL and TCP/IP Server Compatibility

  	TCP/IP Level 530 SSL Server	Prior-level SSL Server
  TCP/IP Level 530 Stack Server	Compatible	Not Compatible
  Prior-level TCP/IP Stack Server	Not Compatible	Compatible

• The SSL server command (VMSSL) has been updated to allow additional security levels to be specified for the EXEMPT operand, to more easily eliminate weak ciphers. Support for a NOHALT operand has also been added, which allows the SSL server Linux guest to remain active after a critical error is encountered during server operations.

• The SSL server administration command (SSLADMIN) has been modified as follows:
  • The SSLADMIN SELF command has been updated to support an EXPIRATION operand, which may be used to specify number of days that a self-signed certificate is to be valid.
  • The SSLADMIN LOG command has been updated to accept file ID operands that allow SSL server log information to be maintained in a file named other than SSLADMIN LOG.
  • the SSLADMIN LOGSIZE and SSLADMIN LOGCLEAR commands are introduced. These respective commands allow a maximum size to be established for the SSL server log, and for accumulated log information to be purged within the SSL server.

• The RPM packages provided with this level of TCP/IP for z/VM support running the SSL server using these Linux distributions:
  • SUSE SLES9 Service Pack 3 (31-bit)
  • SUSE SLES9 Service Pack 3 (64-bit)
  • Red Hat Enterprise Linux AS (Version 4 U4) (31-bit)
  • Red Hat Enterprise Linux AS (Version 4 U4) (64-bit)

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in TCP/IP Level 540

• The TCP/IP server has been updated such that the OVERRIDEPRECEDENCE operand of the AssortedParms configuration statement is always in effect. This change has been made in support of RFC 2873. The OVERRIDEPRECEDENCE operand continues to be accepted to maintain compatibility with prior levels of TCP/IP for z/VM, but will be reported as an obsolete parameter when encountered.

• The TCP/IP server has been updated such that the EQUALCOSTMULTIPATH and EQUALCOSTIPV6MULTIPATH operands of the AssortedParms configuration statement are always in effect. These operands continue to be accepted to maintain compatibility with prior levels of TCP/IP for z/VM, but will be reported as no longer required, when encountered.

• The OSD and the HIPERSockets DEVICE statements have been updated to make AUTORestart the default. Thus, the TCP/IP server automatically will attempt to restart the device in the event of a device failure. AUTORestart is attempted only after successful data transfer has occurred.

• The OSD DEVICE statement has been updated to include a PORTNUMBER operand for which the additional port on each channel of an OSA-Express3 device can be specified. If a port number is not specified, the default is port number 0.

• The IFCONFIG command has been updated to allow a port number to specified for a QDIO (OSA-Express) device. Additionally, IFCONFIG command output now reports the transport type (ETHERNET or IP) for links that are associated with an OSD device.

• (IPv4 only) The IFCONFIG command has been updated to accept two new operands — PATHMTU and NOPATHMTU — to enable or disable path MTU discovery for a given link.

• (IPv4 only) Various LINK statements have been updated to include two new operands — PATHMTU and NOPATHMTU — that respectively enable or disable path MTU discovery on a link-by-link basis.

• (IPv4 only) The PATHMTU operand is accepted for the ASSORTEDPARMS statement, to enable path MTU discovery by default for links for which this has not explicitly been configured.

• Support for The PATHMTUAGE statement has been added, which allows for the specification of how long (in minutes) path MTU discovery information is to be retained for a given route.

• The QDIOETHERNET LINK statement has been updated to accept an ETHERNET or IP operand, which designates the transport type for the link (Layer 2 or Layer 3 mode, respectively).

• Due to SSLADMIN command revisions that eliminate the need for a network connection to perform SSL server administrative functions, an administrative port (previously defined at port number 9999, by default) no longer needs to be reserved for the SSL server.

Changes Introduced in TCP/IP Level 530

• Several enhancements have been added to help maintain high availability in the event of an ethernet QDIO (IPv4 or IPv6) or LCS (IPv4 only) device failure. These enhancements include:
  • IPv4 ARP Takeover Support
    This support provides redundant ethernet (LCS or QDIO) adapters (two or more adapters connected to the same LAN segment) the ability to take over for each other in the event of a device failure.

    Provided all TCP/IP stack interfaces are properly configured, no TCP/IP configuration changes should be necessary for this function to be exploited. The TCP/IP stack uses the configured IP address/subnet mask pairs for each interface to make a determination about which interfaces are connected to the same LAN segment and are therefore eligible to take over for each other.

  • IPv6 Neighbor Discovery Takeover Support
    This support provides redundant QDIO ethernet adapters (two or more adapters connected to the same LAN segment) the ability to take over for each other in the event of a device failure.

    Configuration changes should not be necessary for this function to be used, since the TCP/IP stack perform "same LAN determination" for IPv6 interfaces at initialization, to identify which adapters are connected to the same LAN segment and are therefore eligible to take over for each other.

  • Enhanced OSA Address Table (OAT) Management
    With this enhancement, the IP addresses reported to an OSA adapter are restricted to:
    • those that are defined as adapters HOME addresses
    • IPv4 VIPA addresses (if the device is enabled for IPv4)
    • IPv4 Proxy ARP addresses (if the device is enabled for IPv4)
    • IPv6 VIPA addresses (if the device is enabled for IPv6)
    • any IP addresses for which the device has taken over

• IPv6 VIPA Support has been added, which gives hosts the ability to use the VIPA address as a target for IP traffic, allowing such traffic to be routed to a working adapter on the TCP/IP stack, should one of several applicable adapters fail. Configuration statement changes associated with this support include the following additions:
  • IPV6SOURCEVIPA operand (added for the ASSORTEDPARMS statement)
  • ENABLEIPV6 option (added for the LINK statement)

• TCP/IP has been updated to allow both an IPv4 and IPv6 VLAN to be associated with a QDIOETHERNET link. Changes include:
  • acceptance of an IPv6 VLAN ID (in addition to an IPv4 VLAN ID) for the QDIOETHERNET LINK statement
  • IFCONFIG command changes that allow both an IPv4 VLAN ID and an IPv6 VLAN ID to be specified as part of the VLAN interface operand

• The HOME statement now accepts a VSWITCH operand, which identifies the link that is associated with an IPv4 address as one that can be used for VSWITCH management purposes, such as retrieval of SNMP Bridge MIBs for the virtual switch. The named VSWITCH is also returned in NETSTAT HOME command results.

• Be aware that with z/VM 5.3.0, it is no longer necessary to uncouple/recouple to a Guest LAN or VSWITCH for VLAN or promiscuous mode authorization changes to take effect. Thus, such changes now can immediately affect the operation of a TCP/IP stack server that is connected to a VSWITCH or Guest LAN.

• Support for a -Remove command option has been added to the IFCONFIG command, which allows an interface to be dynamically removed from the TCP/IP server configuration. This support makes use of a new socket API IOCTL subcommand (SIOCDINTERFACE) introduced at this level.

• Support for the BSDROUTINGPARMS statement has been withdrawn.

• The TCP/IP sever has been modified to accommodate "Dynamic SSL/TLS Support," which introduces a set of Application Programming Interfaces (APIs) that permit a Pascal or Assembler client or server application to control the acceptance and establishment of TCP/IP sessions encrypted using SSL/TLS. New configuration statements introduced in conjunction with this capability are:
  • SSLSERVERID

  Note that to provide this capability, the interface used by the TCP/IP server to communicate with the SSL server has been modified. Due to the nature of these changes, an SSL server implementation that is based on prior levels of TCP/IP for z/VM cannot be used with the TCP/IP level 530 TCP/IP server.

• The INTERNALCLIENTPARMS statement, used for configuring the Telnet server, has been updated to accommodate Dynamic SSL/TLS support. Changes include support for SECURECONNECTION and TLSLABEL operands.

Changes to TCP/IP Server Defaults

• Port Restriction Defaults Have Changed - Action Required

  With TCP/IP Level 440, the RestrictLowPorts operand of the AssortedParms statement was changed to be active by default.

  Because of this change, various TCP/IP applications may no longer function unless you take action.

  Refer to the TCP/IP Usage Reference Information for more detail about this change.

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in TCP/IP Level 540

• The Telnet server and client have been updated to accommodate connections using IPv6. For the Telnet server, the telnet session connection and printer management exits (SCEXIT and PMEXIT, respectively) have been updated accordingly. The Telnet client includes support for a new ADDRTYPE option.

  Note that because the z/VM SSL server does not incorporate IPv6 support, IPv6 Telnet connections cannot be secured using SSL.

• Processing of the CERTNOCHECK operand for TLS connections associated with the Telnet client has been changed such that this operand is equivalent to the CERTFULLCHECK operand.

Changes Introduced in TCP/IP Level 530

• The INTERNALCLIENTPARMS statement, used for configuring the Telnet server, has been updated to accommodate Dynamic SSL/TLS support. Changes include support for SECURECONNECTION and TLSLABEL operands.

• The Telnet client has been updated to accommodate Dynamic SSL/TLS support. Changes to provide this capability include support for additional command options, which include:
  • CERTFULLCHECK
  • CERTNOCHECK
  • NOSECURE
  • SECURE

• A new statement, SECURETELNETCLIENT, may now be specified in the TCPIP DATA file. This statement provides the default Telnet client security value to use when neither the SECURE nor NOSECURE option is specified on the Telnet command.

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page

Changes Introduced in TCP/IP Level 540

General Information

• TCP/IP Level 540 is included as a pre-installed component of the z/VM product; its use is governed by your license for z/VM.

• TCP/IP Level 540 is not separately orderable from the z/VM product, although it is serviced separately from z/VM.

• TCP/IP Level 540 RSU service is provided as part of a stacked z/VM RSU, and not as a separately orderable RSU.

• TCP/IP Level 540 relies on the presence of certain functions in the z/VM 5.4.0 levels of CP and CMS. The converse is also true — using z/VM 5.4.0 CMS requires that TCP/IP level 540 be present, to accommodate those functions that use TCP/IP (DNS) resolver services.

  Abends and incorrect results are possible if you attempt to use mixed levels of TCP/IP, CP and CMS.

• TCP/IP softcopy publications are provided in the same manner as other z/VM softcopy publications, and are included with these z/VM publications.

Packaging-specific Changes

• The default minimum virtual storage size defined for the TCPIP (stack) server virtual machines has been increased to 128M, to better accommodate a wide variety of workloads without the need to redefine storage allocated for this server.

• The directory entries for the MPROUTE and the SSLSERV virtual machines now include a SHARE RELATIVE 3000 statement, to allow these servers to better handle activity that is closely associated with TCP/IP server processing.

• With the PTF for APAR PK65850, a CMS-based SSL server is provided with TCP/IP for z/VM that no longer requires operation within a Linux guest. The components required for running this updated server implementation are installed and serviced through the same means as other CMS-based TCP/IP servers — installation of an updated RPM file within a Linux guest is no longer necessary. For this reason, the minidisks that follow have been deleted with this level of TCP/IP for z/VM:
  • 5VMTCP40 493
  • SSLSERV 201
  • SSLSERV 203

  Note
  Coincident with the change in implementation of the z/VM 540 SSL server, the (Linux-only) vmsock module and its program source are no longer provided with z/VM.

• The GSKADMIN User ID has been added. This User ID has been defined with appropriate authorization to perform certificate management operations for the SSL server key database, now maintained within the z/VM Byte File System (BFS). The GSKADMIN User ID is also defined as an SSL server administrative User ID.

  For detailed information about how specific TCP/IP User IDs have been defined, consult the 5VMTCP40 PLANINFO file. This file is located on the 5VMTCP40 191 minidisk.

Changes Introduced in TCP/IP Level 530

General Information

• TCP/IP Level 530 is included as a pre-installed component of the z/VM product; its use is governed by your license for z/VM.

• TCP/IP Level 530 is not separately orderable from the z/VM product, although it is serviced separately from z/VM.

• TCP/IP Level 530 RSU service is provided as part of a stacked z/VM RSU, and not as a separately orderable RSU.

• TCP/IP Level 530 relies on the presence of certain functions in the z/VM 5.3.0 levels of CP and CMS. The converse is also true — using z/VM 5.3.0 CMS requires that TCP/IP level 530 be present, to accommodate those functions that use TCP/IP (DNS) resolver services.

  Abends and incorrect results are possible if you attempt to use mixed levels of TCP/IP, CP and CMS.

• TCP/IP softcopy publications are provided in the same manner as other z/VM softcopy publications, and are included with these z/VM publications.

Packaging-specific Changes

• TCP/IP service procedures now require the TCP/IP for z/VM installation and service user ID (5VMTCP30, by default) to have file pool administration authority for the VMSYS file pool. Such authorization is necessary to accommodate service update processing for LDAP server components that reside in the z/VM Byte File System (BFS).

  For the z/VM Version 5 Release 3.0 System Deliverable, the 5VMTCP30 user ID has already been enrolled as a file pool administrator for the VMSYS file pool. If you choose to use a different user ID to service TCP/IP for z/VM, or elect to use a file pool other than VMSYS for maintaining the Byte File System, you then will need to enroll the appropriate user ID as an administrator for the applicable file pool.

• Support for the BOOTPD and RouteD servers has been withdrawn. The server user IDs, command programs, configuration statements and files associated with these servers have likewise been removed from the z/VM Version 5 Release 3.0 System Deliverable.

  If appropriate, the DHCPD and MPRoute servers should be configured to provide any support and functionality for your installation that was previously provided by the respective BOOTPD and RouteD servers.

• The default minimum virtual storage size defined for most TCP/IP server virtual machines is now 32M (however, the default minimum for certain virtual machines, such as the IMAP, LDAP and SSL servers, is defined higher than this value).

  For detailed information about how specific TCP/IP user IDs have been defined, consult the 5VMTCP30 PLANINFO file. This file is located on the 5VMTCP30 191 minidisk.

Changes Introduced in Prior Levels

• Check the TCP/IP Usage Reference Information for applicable information.

Top of Page