TCP/IP - End-of-Service Reference Information

Migration Considerations and
Release-to-Release Changes

Note: The TCP/IP component and product levels listed below are no longer supported.

The information herein describes changes to various aspects of TCP/IP for VM that warrant consideration when migrating from the levels cited here to a more current (and most likely, supported) level of TCP/IP for z/VM.

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:

TCP/IP Usage FTP Client NETSTAT Printing Services
Remote Execution      

Server Topics:

Server Configuration DNS Server FTP Server IMAP Server
Kerberos Server LDAP Server MPRoute Server RouteD Server
Remote Execution SMTP Server SNMP Server SSL Server
† TCP/IP Stack Server Telnet    

Other Topics:

Packaging      

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 with z/VM Version 4 Release 4 that establish changes to the following defaults:
    • RestrictLowPorts

   TCP/IP Usage

Changes Introduced in TCP/IP Level 620

  • The IPFORMAT diagnostic utility has been updated to support a PCAP operand, which causes which causes TYPE GT and TYPE LAN trace data to be formatted in PCAP data format, to allow for its review and evaluation using a GUI-based trace analysis tool.

  • The CMS NOTE and SENDFILE commands (SMTP clients) have been updated to accommodate the use of IPv6.

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

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.

  • Language Environment (LE) APAR VM64055 must be applied on any system where TCP/IP level 530 is used. While this APAR is incorporated within z/VM levels higher than z/VM version 5 release 3, this requirement is cited here for consideration in the event TCP/IP for z/VM is installed on a level of CP and CMS other than z/VM version 5 release 3 (as might be the case when migration testing is performed).

  • 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 TCP/IP Level 520

  • The IPFORMAT diagnostic utility has been added. This utility can be used to analyze LAN traffic captured via the CP TRSOURCE command, as well as data captured using the TCP/IP server packet tracing facility (which makes use of existing PACKETTRACESIZE and TRACEONLY configuration statements). A related sample program, PKTTRACE, is also included. This program may be used as an aid in gathering TCP/IP server packet trace data, and preparing this information for use as input to IPFORMAT.

  • The content of the ETC SERVICES sample file (ETC SAMPSERV) has been revised such that port number assignments reflect current assignments as listed by the Internet Assigned Numbers Authority (IANA).

Changes Introduced in TCP/IP Level 510

  • With this level, host/domain name resolution is now performed for various TCP/IP functions through the use of IBM Language Environment (LE) sockets. To ensure that adequate virtual storage is available to allow for such resolution, virtual machines that use TCP/IP functions should be defined with a minimum of 16M of virtual storage.

  • The NETSTAT, TRACERTE and PING applications have been enhanced to include IPv6 support. In addition, the Pascal TRACERTE and PING functions have been replaced with C-based equivalents.

  • With this level, TCP/IP for z/VM offers two local host files for domain name resolution and reverse name resolution:

    • the introduced and preferred ETC HOSTS file, which supports both IPv4 and IPv6 address formats; this file is supplied in sample form as the file, ETCHOSTS SAMPLE
    • the older HOSTS LOCAL file, which supports only IPv4 address formats.

    A sample conversion utility (LCL2ETC SEXEC) is also provided, which can be used to create an ETC HOSTS file from an existing HOSTS LOCAL file.

    Note:
    If loopback support is required for your installation, you must explicitly code a LOOPBACK entry for address 127.0.0.1 in the ETC HOSTS file.

Changes Introduced in TCP/IP Level 440

  • The Pascal-based client and server functions supplied with TCP/IP Level 440 (for example, FTP MODULE or SMTP MODULE) are not backward compatible with prior-level TCP/IP "stack" servers, due to internal control block changes that have been implemented in this level of TCP/IP.

    Conversely, in some cases, it may be possible to use older Pascal-based functions in concert with a TCP/IP Level 440 "stack" module. However, such use may result in client "hang" situations or other unexpected results.

    To alert TCP/IP administrators of conditions in which a client-stack mismatch may be relevant, the TCP/IP stack will produce DTCREQ076I and DTCREQ077I console messages on a default basis. In the event the volume of such messages is too great, the NOLEVELWARNING operand of the ASSORTEDPARMS statement can be used to suppress these messages.

    TCP/IP Level 440 Pascal component compatibility is summarized here:

    TCP/IP 440 Pascal Module Compatibility
      TCP/IP Level 440
    Pascal Functions    		 Prior-level TCP/IP
    Pascal Functions
    TCP/IP Level 440
    Stack Server    		 Compatible Not Recommended
    Prior-level TCP/IP
    Stack Server    		 Not Compatible Compatible

  • The C-based client and server functions supplied with TCP/IP Level 440 rely upon the C/C++ Language Environment for z/VM run-time library that is provided with z/VM 4.4.0. Because this library resides on the z/VM Product Code minidisk (typically, the MAINT 19E minidisk, or Y-disk), changes to local procedures and modifications may be required to ensure this library is used in conjunction with TCP/IP services.

    For example, if the VMLINK command is currently used to acquire Language Environment support minidisks for using TCP/IP services, it may no longer be necessary to use this command for such a purpose. Similarly, the use of :vmlink. tags within a customized DTCPARMS file may no longer be required.

Changes Introduced in TCP/IP Level 430

  • The Pascal-based client and server functions supplied with TCP/IP Level 430 (for example, FTP MODULE or SMTP MODULE) are not backward compatible with prior-level TCP/IP "stack" servers, due to internal control block changes that have been implemented in this level of TCP/IP. Conversely, it should be possible to use older Pascal-based functions in concert with a TCP/IP Level 430 "stack" module in most environments.

    TCP/IP Level 430 Pascal component compatibility is summarized here:

    TCP/IP 430 Pascal Module Compatibility
      TCP/IP Level 430
    Pascal Functions    		 Prior-level TCP/IP
    Pascal Functions
    TCP/IP Level 430
    Stack Server    		 Compatible Compatible
    Prior-level TCP/IP
    Stack Server    		 Not Compatible Compatible

Changes Introduced in TCP/IP Level 420

  • TCPIP has been changed to recognize a TCP/IP loopback address of only 127.0.0.1. TCPIP no longer supports an alternate loopback address of 14.0.0.0.

    Existing TCPIP DATA files should be reviewed for NSINTERADDR statements that currently include a 14.0.0.0 loopback address. All such statements should be modified to instead make use of the conventional 127.0.0.1 address that is now supported/in use.

Top of Page

   FTP Client

Changes Introduced in TCP/IP Level 630

  • The FTP client has been updated to accommodate the use of SSL to secure IPv6 FTP connections.

Changes Introduced in TCP/IP Level 620

  • The FTP client has been updated to accommodate the use of IPv6.

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

  • The LISTFORMAT UNIX command now supports ASCII, BINARY and EBCDIC parameters, which influence the computation of the file size returned by the SIZE command and in directory listings.

  • File name pattern matching now can be used for Byte File System (BFS) files and directories

  • The LOCSTAT command now reports secure connection settings.

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 TCP/IP Level 430

  • The FTP client includes support for a WIDTH command option that allows more user control over how FTP console output is formatted.

Changes Introduced in TCP/IP Level 3A0

  • The FTP client includes support for the SIZE subcommand, which allows a client to obtain the size of a file before it is retrieved.

Changes Introduced in TCP/IP Function Level 320

  • The FTP client has been enhanced to make use of login information present in a NETRC DATA file. By default, when a connection is made to a foreign host, user ID and password information in the NETRC DATA file that is specific to that host are used as part of an automatic FTP login process. Automatic FTP login can be suppressed using the new NONETRC option, or through use of the new NETRC subcommand.

Top of Page

   Printing Services

Changes Introduced in TCP/IP Level 630

  • The Line Printer Daemon server (LPSERVE) and its associated resources have been removed.

Changes Introduced in TCP/IP Function Level 310

  • The LPR command can now route print files to RSCS for printing, freeing a user's virtual machine for other work. This may introduce the need for users to learn a limited set of RSCS commands in order to determine the status of their print files. Refer to the z/VM: TCP/IP Level 3A0 User's Guide for more information.

  • RSCS can be used instead of LPSERVE to provide enhanced printer daemon (LPD) capabilities. The operation and administration characteristics of RSCS are very different from LPSERVE. Refer to the chapter titled "Configuring the RSCS Print Server" in z/VM: TCP/IP Level 3A0 Planning and Customization for more information.

Top of Page

   Server Configuration

Changes Introduced in TCP/IP Level 520

  • Processing of the of the HOME and GATEWAY statements by the TCP/IP (Stack) server has been updated to allow for the specification of subnet masks using BSD-style and Classless Inter-Domain Routing (CIDR) notation. Corresponding NETSTAT command changes have been implemented to accommodate the reporting of such notation in data produced by the NETSTAT HOME and NETSTAT GATE commands.

  • The various sample EXEC files provided with TCP/IP for z/VM are now supplied with a file type of SAMPEXEC instead of the previously-used file type of SEXEC.

Changes Introduced in TCP/IP Function Level 510

  • The TCP/IP for z/VM configuration files provided as part of the z/VM Version 5 Release 1.0 System Deliverable are now supplied with only sample file names and file types, and reside on only the appropriate TCP/IP production minidisks (TCPMAINT 591 or TCPMAINT 592). The TCP2PROD command (with the TCPCONFIG section name specified as an operand) can optionally be used to copy these files — using appropriate file naming and file placement — to create an initial (or, "starter") set of configuration files that then can be customized for your installation.

  • With this level, TCP/IP for z/VM offers two local host files for domain name resolution and reverse name resolution:

    • the introduced and preferred ETC HOSTS file, which supports both IPv4 and IPv6 address formats; this file is supplied in sample form as the file, ETCHOSTS SAMPLE
    • the older HOSTS LOCAL file, which supports only IPv4 address formats.

    A sample conversion utility (LCL2ETC SEXEC) is also provided, which can be used to create an ETC HOSTS file from an existing HOSTS LOCAL file.

    Note:
    If loopback support is required for your installation, you must explicitly code a LOOPBACK entry for address 127.0.0.1 in the ETC HOSTS file.

Changes Introduced in TCP/IP Function Level 440

  • The C-based client and server functions supplied with TCP/IP Level 440 rely upon the C/C++ Language Environment for z/VM run-time library that is provided with z/VM 4.4.0. Because this library resides on the z/VM Product Code minidisk (typically, the MAINT 19E minidisk, or Y-disk), changes to local procedures and modifications may be required to ensure this library is used in conjunction with TCP/IP services.

    For example, if the VMLINK command is currently used to acquire Language Environment support minidisks for using TCP/IP services, it may no longer be necessary to use this command for such a purpose. Similarly, the use of :vmlink. tags within a customized DTCPARMS file may no longer be required.

Changes Introduced in TCP/IP Function Level 310

  • Separate server initialization execs (TCPIPXIT, FTPDEXIT, etc.) are no longer used. All server parameters and features are controlled by entries contained in a DTCPARMS file. There is support for you to supply an exit which is specific to a particular server, or an exit that is used by all servers, for customization needs that cannot be met using a customized SYSTEM DTCPARMS file.

  • Changing server names (when defining a second set of TCP/IP servers, for example) no longer requires changes to IBM-provided execs. All information related to the user ID of a particular server is kept in the TCPIP DATA file, or is part of the server configuration and is maintained in the DTCPARMS file.

  • External Security Manager (ESM) interfaces have been standardized across all servers. The RPIUCMS command is used to initialize the RACROUTE environment, and RPIVAL is used to validate user IDs and passwords supplied by clients. These commands can be changed using a customized SYSTEM DTCPARMS file.

  • The ESM environment is automatically established for a server when ":ESM_Enable.YES" is specified for that server in a customized SYSTEM DTCPARMS file.

    Refer to the chapter titled "TCP/IP Server Configuration" in z/VM: TCP/IP Level 3A0 Planning and Customization for more information.

Top of Page

   DNS Server

Changes Introduced in TCP/IP Level 3A0

  • The use of a cache file (as used with a CACHINGONLY name server configuration) has been expanded to the PRIMARY and SECONDARY configurations. A new ROOTCACHE statement allows a cache file to be specified in a manner similar to that which can be specified on the CACHINGONLY statement. A corresponding sample root cache file, NSMAIN SCACHE, supplies several configuration recommendations, a list of root name servers, and the Internet site from which the most current list can be obtained.

  • A FORWARDERS statement has been added to improve name resolution capability for z/VM hosts which are connected to other hosts that provide network firewall services. This statement can be used to identify other name server hosts which can perform name resolution outside the firewall system.

  • The algorithms used in the caching subsystem have been improved to facilitate faster access to cached information and to more quickly determine when cached information does not exist.

Top of Page

   FTP Server

Changes Introduced in TCP/IP Level 630

  • The FTP server has been updated to accommodate the use of SSL to secure IPv6 FTP connections.

Changes Introduced in TCP/IP Level 620

  • The FTP server has been updated to accommodate connections using IPv6.

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

  • The LISTFORMAT UNIX command now supports ASCII, BINARY and EBCDIC parameters, which influence the computation of the file size returned by the SIZE command and in directory listings.

  • File name pattern matching now can be used for Byte File System (BFS) files and directories

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 TCP/IP Level 440

  • The FTP server has been modified such that it can now process more than 256 concurrent connections. The maximum number of connections possible is governed by available virtual storage within the server.

Changes Introduced in TCP/IP Level 3A0

  • The FTP server now makes use of a server-specific configuration file ( SRVRFTP CONFIG by default) for its startup information, in a manner more consistent with other TCP/IP servers. Therefore, :Parms. entries within the DTCPARMS file that are associated with the FTP server need be modified to account for this change. Any SRVRFTP operands currently specified using a :Parms. entry need to be removed, with appropriate modifications made to either the FTP server configuration file or the DTCPARMS file (for example, to account for use of the ANONYMOU or RACF command operands).

    In addition, the FTP server no longer makes use of the client-oriented FTP DATA file.

  • The FTP server has been enhanced to better accommodate web browser and graphical FTP clients. Changes for this support include the ability to provide Unix-format list information in response to client DIR subcommand requests, through the use of the LISTFORMAT configuration statement. In addition, the AUTOTRANS statement can be used to configure the server to perform automatic EBCDIC-ASCII data translation for transferred files, based on file types (or, file extensions), as determined by VMFILETYPE statements which are maintained in the TCPIP DATA file.

  • Support for AUTOTRANS and LISTFORMAT operands to client-supplied SITE subcommands has been implemented as well, to provide client control over automatic EBCDIC-ASCII data translation and list information formats.

  • AUTOTRANS and LISTFORMAT characteristics can now be established when specific FTP users login, when the CHKIPADR exit exec is customized for use.

  • An ISO date format is used for all file date information that is returned by the FTP server. ISO-format dates are of the form yyyy-mm-dd, where yyyy is a 4-digit year, mm is a month, and dd is a day of that month.

  • Support for additional SMSG interface commands has been added to allow for dynamic server configuration changes, console and tracing control, and shutdown/restart capability.

Changes Introduced in TCP/IP Function Level 320

  • The FTP server has been enhanced to exploit new CP and CMS user authorization facilities provided with VM/ESA Version 2 Release 4.0. These enhancements allow an FTP user to access minidisks they own without the need for minidisk passwords to be defined or supplied during an FTP session. Thus, the link results achieved when FTP users access minidisk resources may noticeably differ from those seen using prior levels of TCP/IP for VM.

    For example, if a user establishes a read-only link to a minidisk (through the use of an explicit "ACCT read_password" command), a subsequent PUT command that initiates a write request to that minidisk may now succeed if the login user ID owns the minidisk in question. By comparison, with a prior TCP/IP level, such a request would cause an FTP user to be prompted to supply a Read/Write (or Multiple Read) password through use of the ACCT subcommand in order to first gain write access to the minidisk.

    The use of these new user authorization facilities also allows users with LOGONBY authority for a given base virtual machine to exercise that same authority during an FTP session. This is accomplished through use of the CP Diagnose X'88' command by the FTP server, which allows access to base user ID resources without requiring the password for that base user ID to be supplied. This kind of access is achieved through use of a new "/BY/byuser_id" parameter of the FTP USER subcommand. Additionally, the system directory entry for the FTP server must include an OPTION DIAG88 statement, to allow use of the Diagnose X'88' command.

  • FTP virtual reader support has been added, which allows an FTP client to use the virtual reader of a VM user ID as the current directory. For such users to issue DELETE and DIR or LS commands against a reader directory, the FTP server virtual machine must have class D privileges. To allow user to PUT files to a reader directory, the RDR parameter must be included with the FTP server startup command, SRVRFTP.

Top of Page

   IMAP Server

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 TCP/IP Level 440

  • Support for an IMAP User Authentication Exit is introduced, which removes the restriction that all IMAP users who are enrolled in the IMAP mail store must have a VM user ID and password. With this support, eight-character limits on user ID and password values are also removed, which allows registered IMAP clients to use IMAP services without knowledge (or restrictions imposed by) the VM IMAP implementation.

    The IMAP User Authentication Exit is activated by including a new AUTHENTICATEID statement in the IMAP server configuration file (IMAP CONFIG). A sample authentication exit exec is provided as IMAPAUTH SEXEC. The exit itself runs in a server virtual machine that is separate from the IMAP server; this additional server is named IMAPAUTH, by default.

    A new IMAP administrative command, IMAPADM SETTINGS, is also now supported. This command provides information about current IMAP server attributes and settings.

Top of Page

   Kerberos Server

Changes Introduced in TCP/IP Level 3A0

  • The non-DES Kerberos functions that were provided with previous levels of IBM TCP/IP for VM are no longer available. Instead, only a DES Kerberos system is supported, with the DES Kerberos functions incorporated as part of the TCP/IP Feature for z/VM.

  • Any Kerberos database that was created in a non-DES environment will not work with the DES Kerberos functions supplied as part of TCP/IP Feature for z/VM. The existing non-DES Kerberos database must be deleted and then rebuilt using the supplied DES Kerberos functions. Refer to the chapter titled "Configuring the Kerberos Server" in z/VM: TCP/IP Level 3A0 Planning and Customization for more information about building the Kerberos database.

Top of Page

   LDAP Server

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

   NETSTAT Command

Changes Introduced in TCP/IP Level 630

  • As part of the updates to provide SSL support for IPv6 secure connections, the NETSTAT IDENT SSL command has been enhanced to handle and display IPv6 secure connection data.

Changes Introduced in TCP/IP Level 620

  • With the upgrade of MPROUTE to z/OS 1.12 equivalency, the following updates are included:
    • support for a ROUTERADV option for the NETSTAT CONFIG command. This option can be used to display the router advertisement configuration parameters of a TCP/IP server.
    • the NETSTAT GATE and NETSTAT CONFIG HELP commands include new output fields.
  • Support for the OSAINFO option is introduced. This option displays basic information (such as IP and MAC addresses) from the OSA Address Table (OAT) for TCP/IP devices that are defined on supported OSA-Express cards.

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 TCP/IP Level 520

  • The NETSTAT command has been updated to accommodate the reporting of IP network masks using BSD-style and Classless Inter-Domain Routing (CIDR) notation in results produced by the NETSTAT HOME and NETSTAT GATE commands (as dictated by the notation used for the TCP/IP (Stack) server HOME and GATEWAY configuration statements).

  • A new CONFIG option has been added to allow NETSTAT to query stack configuration information.

Changes Introduced in TCP/IP Level 510

  • The MTU size associated with a given link is now reported as part of the NETSTAT DEVLINKS output. The MTU size reported is either a defined LINK MTU value, or an intelligent default that has been assigned by TCP/IP.

Changes Introduced in TCP/IP Level 440

  • The NETSTAT DEVLINKS command now reports data traffic information for the majority of devices that are supported by TCP/IP for z/VM. Traffic information is provided by newly introduced BytesIn and BytesOut fields that are included as part of the NETSTAT information produced for a given device.

  • NETSTAT has been modified to produce nonzero return codes to aid in distinguishing command processing errors when they arise. Thus, local applications that utilize NETSTAT commands may require modification to interrogate and account for return codes other than zero. Details about NETSTAT return codes and the reasons for them can be found in the z/VM: TCP/IP User's Guide.

Changes Introduced in TCP/IP Level 430

  • An OBEY operand is now supported, which can be used to make dynamic changes to the TCP/IP stack server configuration. Any data that is appropriate for use with the OBEYFILE command can be processed using a NETSTAT OBEY command (to the extent that data can be provided via the CMS command line).

Top of Page

   MPRoute / RouteD Servers

Changes Introduced in TCP/IP Level 630

  • The MPRoute server has been upgraded to z/OS 1.13 Equivalency, and includes these functional enhancements:
    • support for RFC 2328 for IPv4 OSPF
    • support for RFC 2740 for IPv6 OSPF

Changes Introduced in TCP/IP Level 620

  • The MPRoute server has been upgraded to z/OS 1.12 Equivalency, and includes these functional enhancements:
    • support for RFC 4191 and RFC 5175
    • support for MPRoute configuration file INCLUDE statements
    • updates to report and help prevent futile neighbor state loops
    • SMSG command updates to support DELETED, ACTIVATE, and SUSPEND keywords for selected commands
    • ROUTERADV statement support changes that allow router advertisements to be sent with a HIGH, MEDIUM, or LOW preference value.

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 TCP/IP Level 520

  • The MPRoute server implementation provided with this level of TCP/IP for z/VM has been revised, and is adapted from z/OS V1.7.

    With this implementation change, the format of the MPRoute server messages differs from that of other TCP/IP messages. The following message numbering convention is used for MPRoute messages:

    EZZnnnnt

    where:

    EZZ is the product identifier for MPRoute
    nnnn is a unique 4-digit numeric value assigned to the message
    t is the message type that indicates the action assigned to the message.

    Types and their meanings are:

    Type Code Meaning
    A Immediate action required
    E Eventual action required
    D Immediate decision required
    I Informational

  • Various MPRoute server configuration statements have been revised, with respect to their use and supported operands, while others have been added in support of IPv6.

  • A subnet mask value of 255.255.255.255 is no longer accepted for the OSPF_INTERFACE, RIP_INTERFACE or INTERFACE configuration statements. The most specific subnet mask that now can be specified for these statements is 255.255.255.252. 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, the subnet_mask value specified for the aforementioned statements must have a sufficient number of zero bits such that no home address in that subnet has all zeros or all ones in the host portion of the address.

    Consider a subnet that incorporates these two home addresses — 10.1.1.1 and 10.1.1.2 The subnet mask for this subnet must have zeros in at least two bit positions; for example, 255.255.255.252 (where the binary representation of 252 is 11111100). However, if a subnet includes four home addresses — 10.1.1.1, 10.1.1.2, 10.1.1.3 and 10.1.1.4 — its subnet mask must have zeros in at least three bit positions; for example 255.255.255.248 (248 in binary form is 11111000). In this instance, up to six home addresses can be included in this subnet (10.1.1.1 through 10.1.1.6).

    In general, if a subnet mask has n zero bits, then there can be up to 2n – 2 home addresses in that subnet. This limit applies even if the subject home addresses are configured on different TCP/IP stacks.

  • The name of the MPRoute server configuration file is no longer restricted to MPROUTE CONFIG. A newly introduced DTCPARMS :config. tag can be used to specify the file ID of the configuration file to be used when an MPRoute server is initialized.

  • The existing support limit of only four equal-cost paths is removed -- up to 16 equal-cost routes may now be generated for a given destination, to provide improved load-balancing support.

  • Processing of the of the HOME and GATEWAY statements by the TCP/IP (Stack) server has been updated to allow for the specification of subnet masks using BSD-style and Classless Inter-Domain Routing (CIDR) notation. Corresponding NETSTAT command changes have been implemented to accommodate the reporting of such notation in data produced by the NETSTAT HOME and NETSTAT GATE commands.

  • The TCP/IP server now automatically generates static routes for IP addresses for which a subnet mask has been specified. When a subnet mask is specified for IPv4 home addresses, the TCP/IP server automatically generates a direct static route to the subnet described by the IP address and mask. For IPv6 addresses, the TCP/IP server automatically generates a direct static route to the network described by the first 64 bits of the address. Unlike static routes added through the GATEWAY statement, these routes may be replaced by dynamic routing protocols if MPRoute is running.

  • Note:
    This is the last TCP/IP level for which a RouteD server may be deployed to provide dynamic routing support. Future levels of z/VM TCP/IP will rely solely upon the MPRoute server to provide dynamic routing services.

Changes Introduced in TCP/IP Level 510

  • LINK MTU values, specified as part of LINK statements within the TCP/IP server configuration file, now override any MTU values that are specified for interface statements in the MPROUTE server configuration file (MPROUTE CONIFIG).

Changes Introduced in TCP/IP Level 3A0

  • The RouteD and MPROUTE servers cannot be concurrently used with the same TCP/IP stack server.

Changes Introduced in TCP/IP Function Level 320

  • The #CP EXTERNAL command can no longer be used to terminate RouteD server. The command to stop RouteD is #CP SMSG * SHUTDOWN.

Top of Page

   Remote Execution Services

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 TCP/IP Level 440

  • The REXEC server has been updated to allow users with LOGONBY authority for a given base virtual machine to exercise that same authority when z/VM commands are remotely executed. This is accomplished through use of the CP Diagnose X'88' command within the REXEC server, which allows access to base user ID resources without requiring the password for that base user ID to be supplied.

    This kind of access is achieved by qualifying a remote login user ID with a new "/BY/byuser_id" parameter, when that user ID is specified using the -l operand of the rexec command. In addition, the system directory entry for the REXEC server must include an OPTION DIAG88 statement, to allow use of the Diagnose X'88' command.

Top of Page

   SMTP Server

Changes Introduced in TCP/IP Level 630

  • The SMTP server has been updated to accommodate the use of SSL to secure IPv6 SMTP connections.

Changes Introduced in TCP/IP Level 620

  • The SMTP server has been updated to accommodate connections using IPv6.

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

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 TCP/IP Level 510

  • Support for the SUPPRESSNOTIFICATION configuration statement has been modified such that "Received From" messages can be suppressed in addition to "Mail Delivered" messages. With this change, RECEIVED, DELIVERED and ALL operands are added for this statement. ALL is the default, meaning that both the mail received and mail delivered messages are to be suppressed.

Changes Introduced in TCP/IP Level 440

  • Support for a new VERIFYBATCHSMTPSENDER configuration statement is added. When this statement is used, SMTP will reject batch mail that contains a MAIL FROM: address that differs from available RSCS information. Specific users can be exempted from this verification through the use of additional VERIFYBATCHSMTPSENDER operands.

Changes Introduced in TCP/IP Level 420

  • Support for new FILESPERCONN and MAXCONNPERSITE statements has been added. These statements allow more control over the establishment of connections with remote SMTP servers, and may aid with adjusting mail delivery throughput.

  • An SMSG REFRESH command can now be used by authorized users to dynamically update SMTP security or nickname table information, depending on the configuration of the SMTP server.

Changes Introduced in TCP/IP Level 3A0

  • Timing values for the RETRYAGE and WARNINGAGE statements can now be specified in hours or minutes (in addition to a number of days), through the use of additional H or M statement operands. Existing defaults (specified in days, for which a D statement operand can now be specified) remain unchanged.

Changes Introduced in TCP/IP Function Level 320

  • Support for the SMTP EHLO command has been added, as has support for the Message Size Declaration and 8-bit MIME transport service extensions. With this support, SMTP now accepts and handles the SIZE and BODY parameters on MAIL FROM: commands.

Changes Introduced in TCP/IP Function Level 310

  • The DEBUG configuration file statement is no longer supported. This statement has been replaced by the TRACE statement which, when specified with the DEBUG parameter, provides identical function as the DEBUG statement, except that output goes to only the console; there is no debug file support. Refer to the chapter titled "Configuring the SMTP Server" in z/VM: TCP/IP Level 3A0 Planning and Customization for more information about the TRACE statement and additional parameters that can be specified.

  • The default for the WARNINGAGE configuration file statement has been reduced from 3 days to 1 day.

  • Due to the introduction of new and changed trace options, the TRACE SMSG command now requires additional options to be specified. In TCP/IP for VM releases prior to TCP/IP Function Level 310, the TRACE SMSG command was used to trace host name resolution via name severs. This SMSG command has been replaced with the TRACE RESOLVER SMSG command. Similar results can be achieved by specifying the TRACE RESOLVER statement in the SMTP configuration file. Refer to the chapter titled "Configuring the SMTP Server" in z/VM: TCP/IP Level 3A0 Planning and Customization for more information about configuration file changes, and to the z/VM: TCP/IP Level 3A0 User's Guide for SMTP SMSG command interface changes.

  • The SMTP DATA file is no longer needed. The ATSIGN statement previously supported using this file has been incorporated within the TCPIP DATA file.

  • The sample SMTP configuration file (SMTP SCONFIG) now specifies "NETDATA" as the default for both the LOCALFORMAT and RSCSFORMAT statements, to reflect the operational default value associated with these statements.

  • Host names for mail items can now be re-resolved (when required) by using the REPROCESS SMSG command. Refer to the chapter titled "Configuring the SMTP Server" in z/VM: TCP/IP Level 3A0 Planning and Customization for more information. The formerly documented SMTP-EXP EXEC is no longer needed for this purpose and should not be used.

  • SMTP work files (NOTE and ADDRBLOK files) have new formats and names; the file types for these files have been changed to NOTEFILE and ADDRFILE, respectively. When migrating from IBM TCP/IP for VM Version 2 Release 4, any NOTE or ADDRBLOK files present on the SMTP server A-disk are converted to the new format and renamed; such converted files cannot be processed by previous versions of TCP/IP for VM.

Top of Page

   SNMP Server

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

   SSL Server

Changes Introduced in TCP/IP Level 630

  • The z/VM SSL server has been upgraded to z/OS 1.13 Equivalency. This upgrade includes support for Transport Layer Security (TLS) protocol, version 1.2, which provides support for SHA-256 certificates. A new PROTOCOL operand on the VMSSL command allows the system administrator to enable and disable SSL and TLS protocols for cryptographic use in the operation of the SSL server. In addition, the SSL server has been updated to accommodate the use of SSL to secure IPv6 connections.

    With this change, the SSLADMIN and NETSTAT IDENT SSL commands have been enhanced to handle and display IPv6 secure connection data.

Changes Introduced in TCP/IP Level 620

    Inclusion of the SSL Server Performance and Scalability Enhancements (introduced in TCP/IP for z/VM level 540 and level 610 via the PTFs for APARs PK97437, PK97438 and PK75662). These enhancements improve upon the ability of an SSL server to provide concurrent secure connectivity by increasing its overall performance and decreasing the amount of required system resources.

    Changes included as part of these enhancements include:

    • support for a new VMSSL command operand, CACHECLEANUP, and changes associated with support of the CACHELIFE operand
    • updates to the SSLADMIN command, with changes that affect the SSLADMIN QUERY, SSLADMIN REFRESH, and SSLADMIN TRACE/NOTRACE commands
    • support for new SSL server administration (SSLADMIN) commands — SSLADMIN CLEAR, SSLADMIN SET and SSLADMIN START
    • introduction of a new TCP/IP server configuration statement, SSLLIMITS, and changes that affect processing of the SSLSERVERID statement.

    With this change, the SSLSERV user ID no longer is included as part of the z/VM version 6 release 2 System Deliverable. In its place, an SSL server "pool" of five servers now is defined as part of the system. While continued use of a single-instance, minidisk-based server (such as SSLSERV) still is possible and remains supported, the preferred configuration for running a single SSL server is to alter the SSL pool definition such that only one pool sever is defined. This can readily be accomplished by a CP directory change to the SSL server POOL definition.

  • Inclusion of SSL Server Federal Information Processing Standard (FIPS) 140-2 Support (introduced in TCP/IP for z/VM level 610 via the PTF for APAR PM10616).

Changes Introduced in TCP/IP Level 610

  • SSL Server Federal Information Processing Standard (FIPS) 140-2 Support is introduced with the PTF for APAR PM10616).

  • With the PTFs for APARs PK97437, PK97438 and PK75662, SSL Server Performance and Scalability Enhancements are introduced. These enhancements improve upon the ability of an SSL server to provide concurrent secure connectivity by increasing its overall performance and decreasing the amount of required system resources. With these enhancements, support for multiple SSL servers, defined as a server "pool" is introduced as well.

  • With TCP/IP level 610, the PTF for APAR PK65850 (SSL Server Enablement) is not required — the CMS-based SSL server supplied with the z/VM version 6 release 2 System Deliverable is fully enabled.

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 TCP/IP Level 520

  • A FIPS operand is introduced that signifies the SSL server is to operate in FIPS (Federal Information Processing Standard, FIPS 140-2) mode, which restricts connections to those that employ FIPS-approved cipher suites.

  • Server operation has been modified such that a server restart is not required to activate or remove a certificate.

  • The RPM packages provided with this level of TCP/IP for z/VM support running the SSL server using these Linux distributions:

    • SUSE SLES8 Service Pack 3 (31-bit)
    • SUSE SLES9 Service Pack 2 (31-bit)
    • SUSE SLES9 Service Pack 2 (64-bit)
    • Red Hat Enterprise Linux AS V3 (31-bit)
    • Red Hat Enterprise Linux AS V3 (64-bit)

Changes Introduced in TCP/IP Level 440

  • Linux-based components of the SSL server implementation are now provided using RPM-format files, which are maintained on a newly introduced TCP/IP service build disk. When the SSL server is configured for use, the appropriate RPM package file must be retrieved from this disk and then installed on the intended Linux guest by using the Red Hat Package Manager (RPM).

    The DASD requirements for the SSL Server have also been modified, to allow for more flexibility in how the required Linux guest services are provided. As a result of these changes, SSL-specific binary system files are no longer required (or provided) with TCP/IP for z/VM.

  • The syntax for the SSLADMIN SELF command has been modified to be more consistent with that of the SSLADMIN STORE command.

Top of Page

   TCP/IP (Stack) Server

Changes Introduced in TCP/IP Level 630

  • Support for Common Link Access to Workstation (CLAW) and HYPERchannel A220 devices has been removed.

Changes Introduced in TCP/IP Level 620

  • Inclusion of the TCP/IP server-specific changes associated with the SSL Server Performance and Scalability Enhancements (introduced in TCP/IP for z/VM level 540 and level 610 via the PTFs for APARs PK97437, PK97438 and PK75662). Stack specific updates introduced with the PTF for APAR PK75662 include:
    • support for the SSLLIMITS statement is added, which is used to specify the total number of secure connections that are to be supported by the TCP/IP server, as well as the connection limit for each SSL server.
    • support for the SSLSERVERID statement is modified to accept an asterisk (*) as a user_id value. In addition, a different TIMEOUT operand default (of 30 seconds, formerly 60 seconds) now is employed, with boundary values imposed.

Changes Introduced in TCP/IP Level 610

  • z/VM version 6 release 1 implements a new Architecture Level Set (ALS) and is available on only the IBM System z10 Enterprise Class server and System z10 Business Class server (and, future generations of System z® servers). Because of this ALS, TCP/IP for z/VM no longer supports these network devices, communication methods and related configuration statements:
    • Devices
      • Open System Adapter 2 (OSA-2)
      • OSA-Express (first generation only)
      • IBM 3172 Interconnect Controller
    • Communication Methods
      • Asynchronous Transfer Mode (ATM)
      • Fiber Distributed Data Interface (FDDI)
      • IBM Token-Ring (IBMTR)
    • Configuration Statements
      • DEVICE and LINK statements for ATM device types
      • DEVICE and LINK statements for LCS device types other than an OSA-Express configured for LAN emulation mode
      • LINK statements for IBMTR networks
      • LINK statements for FDDI networks
      • LCS device 3172-specific NETMAN operand
      • ATMARPSERVER
      • ATMLIS
      • ATMPVC

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 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 RestrictLowPorts Information for more detail about this change.

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 Introduced in TCP/IP Level 520

  • Processing of the of the HOME and GATEWAY statements by the TCP/IP (Stack) server has been updated to allow for the specification of subnet masks using BSD-style and Classless Inter-Domain Routing (CIDR) notation. Corresponding NETSTAT command changes have been implemented to accommodate the reporting of such notation in data produced by the NETSTAT HOME and NETSTAT GATE commands.

  • The TCP/IP server now automatically generates static routes for IP addresses for which a subnet mask has been specified. When a subnet mask is specified for IPv4 home addresses, the TCP/IP server automatically generates a direct static route to the subnet described by the IP address and mask. For IPv6 addresses, the TCP/IP server automatically generates a direct static route to the network described by the first 64 bits of the address. Unlike static routes added through the GATEWAY statement, these routes may be replaced by dynamic routing protocols if MPRoute is running.

Changes Introduced in TCP/IP Level 510

  • Internet Protocol Version 6 (IPv6) support has been updated to allow the z/VM TCP/IP stack to be configured for IPv6 networks connected through OSA-Express devices which operate in QDIO mode, as well as those associated with a z/VM QDIO Guest LAN. New configuration statements introduced in conjunction with this capability are:

    • EQUALCOSTIPV6MULTIPATH (for ASSORTEDPARMS)
    • IGNOREIPV6REDIRECT (for ASSORTEDPARMS)
    • ICMPERRORLIMIT
    • NCBPOOLSIZE
    • ROUTERADV
    • ROUTERADVPREFIX

    Various, existing statements have also been modified to accommodate their use for an IPv6 configuration. Refer to z/VM: TCP/IP Level 510 Planning and Customization for detailed information about the statements affected by these changes.

  • Support for a LINK statement MTU operand has been added. When a value of zero (0) is specified for this operand, TCP/IP uses an intelligent MTU value based on the pertinent LINK definition. See the section titled "Intelligent default MTU Values Based on the Device and Link Type" Refer to z/VM: TCP/IP Level 510 Planning and Customization for detailed information about the MTU operand and its use.

    Note that with this change:

    • the MTU size reported by the NETSTAT command for a given link is either a defined LINK MTU value, or an intelligent default that has been assigned by TCP/IP
    • LINK MTU values override any MTU values that are specified for interface statements in the MPROUTE server configuration file (MPROUTE CONIFIG).

  • Server initialization logic has been updated to additionally support the use of an initial configuration file that is named to match the user ID of a given TCP/IP server virtual machine. With this change, TCP/IP searches for an initial configuration file in the following order:

    1. userid TCPIP
    2. nodename TCPIP
    3. PROFILE TCPIP

  • AUTORESTART processing for HiperSockets and OSD devices has been modified. Upon an OSD device failure for which a restart is appropriate, TCP/IP will attempt to restart that device once, and then every 30 seconds thereafter, until the device becomes "ready" or it is stopped (as by OBEY STOP processing). When restart processing is in effect, a new status is reported for this device by the NETSTAT DEVLINKS command: 

      AUTORESTART retry

  • The VSWITCH CONTROLLER statement has been updated to specify whether failover capability is enabled or disabled for a designated TCP/IP stack controller. When failover is enabled, CP checks timestamps to confirm that the z/VM TCP/IP stack controller is responding to requests to service an OSA Express device associated with an active Virtual Switch.

  • A :vnic. tag can now be specified in a customized SYSTEM DTCPARMS file, to automatically define a virtual Network Interface Card (NIC) and couple this adapter to a designated guest LAN or virtual switch, as part of TCP/IP initialization.

Changes Introduced in TCP/IP Level 440

  • Action Required — Port Restriction Defaults Have Changed
    Multiple TCP/IP Applications May Be Affected

    Various TCP/IP applications may no longer function unless you take action.

    The security of the z/VM TCP/IP stack has been improved by making the RestrictLowPorts operand of the AssortedParms statement active by default. Thus, all TCP/IP applications that listen on "well-known" ports ( ports 1 through 1023) must be given permission to do so. Such permission can be granted by customizing the TCP/IP server configuration file (PROFILE TCPIP, or its equivalent) in one of three ways:

    1. Use the PORT statement to reserve the specific port (or ports) required by each application (virtual machine) used on your system. This is the preferred method. Note that with z/VM Version 4 Release 4, ports can be reserved within a specific range, in addition to being reserved on an individual basis.

    2. Modify the OBEY statement such that affected application virtual machines are included in the TCP/IP obey list.

    3. Include the FreeLowPorts operand as part of an AssortedParms statement. This method removes the default protection for all well-known ports.

    Note:
    When the RestrictLowPorts default is in effect and appropriate port authorizations have not been provided, applications that rely upon "well-known" ports (for example, VM-based web servers or remote printing functions such as lpr) are likely to report "Unable to open port(s)" or "Permission denied" conditions.

  • Variable-length subnet masks may be used without specification of the VARSUBNETTING operand of the ASSORTEDPARMS statement. VARSUBNETTING is now the default behavior of the TCP/IP stack and cannot be disabled.

  • For DEVICE statements that correspond to real interface devices, a CPU operand can now be specified to designate a particular virtual processor for running the device drivers associated with such devices. Note that to exploit this capability, the stack must be configured as a virtual multiprocessor (Virtual MP).

  • The send_limit and receive_limit defaults for the DATABUFFERLIMITS statement have been increased from 5 to 8.

  • Support for a new SOMAXCONN statement is introduced. This statement provides control over the maximum number of pending connection requests that are queued for a listening socket. The default maximum is 10. Note that using a different SOMAXCONN value may require corresponding changes to the SOCKET.H file, to allow for effective use of the specified maximum by C socket programs.

  • Support for a new LINK statement operand, NOFORWARD (and its synonym, NOFWD) is introduced. This operand specifies that packets received on the designated link are not to be forwarded to another host, and that packets transmitted on this link must originate from the local host. In other words, when the NOFORWARD operand is specified for a link, traffic carried on that link will not be intermingled with traffic on other links.

  • By default, the TCP/IP stack will produce DTCREQ076I and DTCREQ077I console messages to alert TCP/IP administrators of conditions in which a (Pascal-based) client-stack mismatch is detected. In the event the volume of such messages is too great, the NOLEVELWARNING operand of the ASSORTEDPARMS statement can be used to suppress these messages.

  • The PORTNAME operand for OSD and HiperSockets DEVICE statements is now optional. However, for some OSA Express adapter levels (whether real or virtual), a PORTNAME operand and value must still be specified. When such an adapter is in use and the PORTNAME operand is omitted, error message DTCOSD310E will be displayed during device initialization.

  • Virtual Local Area Network (VLAN) identifiers can now be specified on QDIOETHERNET and QDIOIP LINK statements, as well as with the IFCONFIG command.

  • The TCP/IP stack can now act as a controller for a z/VM Virtual Switch. The VSWITCH CONTROLLER statement, along with the IUCV *VSWITCH system directory statement, determines whether a given stack can act as such a controller.

  • The NETSTAT DEVLINKS command now reports data traffic information for the majority of devices that are supported by TCP/IP for z/VM. Traffic information is provided by newly introduced BytesIn and BytesOut fields that are included as part of the NETSTAT information produced for a given device.

Changes Introduced in TCP/IP Level 430

  • The NETSTAT command now supports an OBEY operand, which can be used to make dynamic changes to the TCP/IP stack server configuration. Any data that is appropriate for use with the OBEYFILE command can be processed using a NETSTAT OBEY command (to the extent that data can be provided via the CMS command line).

  • The IFCONFIG command introduced with this level of TCP/IP can be used to make dynamic configuration changes to network interfaces for the z/VM TCP/IP stack, or to display the current configuration. Note that network changes made using IFCONFIG are not permanent. However, IFCONFIG can produce data that is compatible with the TCP/IP server configuration file, which then can be used for permanent modifications.

Changes Introduced in TCP/IP Level 420

  • TCPIP has been changed to recognize a TCP/IP loopback address of only 127.0.0.1. TCPIP no longer supports an alternate loopback address of 14.0.0.0.

    Existing TCPIP DATA files should be reviewed for NSINTERADDR statements that currently include a 14.0.0.0 loopback address. All such statements should be modified to instead make use of the conventional 127.0.0.1 address that is now supported/in use.

  • The number of DEVICE statements that can be specified within the TCP/IP server configuration file is no longer limited to 100 such statements. The number of DEVICE statements that can be supported is now determined by the virtual storage size of the TCPIP virtual machine.

  • Proxy ARP support (activated through use of the PROXYARP operand of the ASSORTEDPARMS statement) can now be used with OSA Direct (OSD) devices, as well as for more traditional point-to-point connections.

  • The default for the SCANINTERVAL operand of the INTERNALCLIENTPARMS statement (used for Telnet server configuration) has been changed from 120 to 60 seconds.

  • OSA Direct (OSD) Device Token Ring support is now provided.

Changes Introduced in TCP/IP Function Level 320

  • The TIMESTAMP statement default has been changed from TIMESTAMP 0 to TIMESTAMP PREFIX, which specifies that a time stamp is to preface every trace and console message. This change helps in diagnosing problems and isolating error conditions. Therefore, it is recommended that any existing TCP/IP server configuration files be changed to specify TIMESTAMP PREFIX to aid in problem determination.

  • The Telnet session connection exit interface has been changed to pass the LU name supplied by a client (if any) as an additional parameter. Existing exits may need to be changed to accommodate this behavior.

  • The Telnet printer management exit is called for any printer session, regardless of whether the client LU name and IP address are defined by a TN3270E statement in the TCP/IP configuration file. Existing exits may need to be changed to accommodate this behavior.

Top of Page

   Telnet Server / Client

Changes Introduced in TCP/IP Level 630

  • The Telnet server and client have been updated to accommodate the use of SSL to secure IPv6 connections.

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 TCP/IP Level 420

  • The default for the SCANINTERVAL operand of the INTERNALCLIENTPARMS statement (used for Telnet server configuration) has been changed from 120 to 60 seconds.

Changes Introduced in TCP/IP Function Level 320

  • The Telnet session connection exit interface has been changed to pass the LU name supplied by a client (if any) as an additional parameter. Existing exits may need to be changed to accommodate this behavior.

  • The Telnet printer management exit is called for any printer session, regardless of whether the client LU name and IP address are defined by a TN3270E statement in the TCP/IP configuration file. Existing exits may need to be changed to accommodate this behavior.

Top of Page

   Packaging

Changes Introduced in TCP/IP Level 630

  • Resources associated with the following services have been removed:
    • Dynamic Host Configuration Protocol server (DHCPD)
    • Line Printer Daemon server (LPSERVE)

    These changes are part of an ongoing effort to provide only those TCP/IP services that are required by customers to support their enterprise.

  • The MAINTvrm user ID for performing TCP/IP for z/VM service activity is MAINT630, whereas the 6VMTCP30 user ID is the designated owner of TCP/IP minidisks and SFS resources.

Changes Introduced in TCP/IP Level 620

  • Significant packaging changes, which affect all of z/VM and its components, have been implemented with z/VM version 6 release 2 to provide support for a z/VM single system image (SSI) environment. With these changes, the role of the 6VMTCP20 user ID has changed. This user ID no longer is intended for use to service and maintain TCP/IP for z/VM. Instead, the 6VMTCP20 user ID serves only as the designated owner of the various minidisks and SFS resources required for product maintenance purposes.

    Thus, all TCP/IP for z/VM service activity now must be performed using the MAINTvrm user ID — MAINT620.

  • The TCP2PROD command no longer is used for placing TCP/IP files into production; instead, the VMSES/E PUT2PROD command now directly performs this function. With this change, the TCP2PROD command no longer is supplied with z/VM. The PRODUTL command, included as part of the VMSES/E component of z/VM, provides equivalent function and capabilities, and can be used (if needed) in place of TCP2PROD.

  • The TCP/IP CATALOG file (6VMTCP20 CATALOG) no longer is used for control purposes when TCP/IP product files are placed into production. For the most part, this file now is used for select processing that pertains to TCP/IP for z/VM sample files..

  • Resources associated with the following services (for which support was withdrawn from TCP/IP for z/VM, effective as of level 540) have been removed:
    • Network Database (NDB),
    • SNALINK
    • Trivial File Transfer Protocol (TFTP)
    • X.25 support

    Included with these changes is removal of these user IDs and any associated minidisks:

    • ADMSERV
    • GCSXA
    • NAMESRV
    • NDBPMGR
    • NDBSRV01
    • SNALNKA
    • TFTPD
    • VMKERB
    • VSMSERVE
    • X25IPI
  • The SSLSERV user ID no longer is included as part of the z/VM version 6 release 2 System Deliverable. In its place, an SSL server "pool" of five servers now is defined as part of the system. While continued use of a single-instance, minidisk-based server (such as SSLSERV) still is possible and remains supported, the preferred configuration for running a single SSL server is to alter the SSL pool definition such that only one pool sever is defined. This can readily be accomplished by a CP directory change to the SSL server POOL definition.

  • The SSLPOOL utility, supplied as a sample exec with the PTFs for the SSL Server Performance and Scalability Enhancements, has been incorporated as a formally supported command. The SSLPOOL SAMPEXEC file no longer is supplied.

  • Consult the 6VMTCP20 PLANINFO file for detailed information about how specific TCP/IP user IDs have been defined. This file is located on the 6VMTCP20 191 minidisk.

Changes Introduced in TCP/IP Level 610

  • No significant changes have been introduced with TCP/IP level 610.

    note
    With TCP/IP level 610, the PTF for APAR PK65850 (SSL Server Enablement) is not required — the CMS-based SSL server supplied with the z/VM version 6 release-2 System Deliverable is fully enabled.

Changes Introduced in TCP/IP Level 540

  • 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 TCP/IP Level 520

Packaging-specific Changes

  • Definitions and sample configuration files have been added to provide a pair Switch (VSWITCH) controller virtual machines, DTCVSW1 and DTCVSW2. Refer to z/VM Connectivity (SC24-6080) for more information about Virtual Switches, and their z/VM environment.

  • The various sample EXEC files provided with TCP/IP for z/VM are now supplied SAMPEXEC instead of the previously-used file type of SEXEC.

Changes Introduced in TCP/IP Level 510

General Information

  • TCP/IP Level 510 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 510 is not separately orderable from the z/VM product, although it is serviced separately from z/VM.

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

  • TCP/IP Level 510 relies on the presence of certain functions in the Z/VM 5.1.0 levels of CP and CMS. Abends and incorrect results are possible if you attempt to use it with a different level of CP or 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 TCP/IP for z/VM configuration files provided as part of the z/VM Version 5 Release 1.0 System Deliverable are now supplied with only sample file names and file types, and reside on only the appropriate TCP/IP production minidisks (TCPMAINT 591 or TCPMAINT 592). The TCP2PROD command (with the TCPCONFIG section name specified as an operand) can optionally be used to copy these files — using appropriate file naming and file placement — to create an initial (or, "starter") set of configuration files that then can be customized for your installation.

  • The TCP2PROD command has been updated to employ improved selectivity and (sample) file change notification when serviced TCP/IP for z/VM files are placed into production. This capability is facilitated in part by the addition of TCPSAMPLE and file exclusion definition entries within the supplied TCP/IP CATALOG file.

Changes Introduced in TCP/IP Level 440

General Information

  • TCP/IP Level 440 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 440 is not separately orderable from the z/VM product, although it is serviced separately from z/VM.

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

  • TCP/IP Level 440 relies on the presence of certain functions in the Z/VM 4.4.0 levels of CP and CMS. Abends and incorrect results are possible if you attempt to use it with a different level of CP or 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.

  • The Pascal-based client and server functions supplied with TCP/IP Level 440 are not backward compatible with prior-level TCP/IP "stack" servers, due to internal control block changes that have been implemented in this level of TCP/IP.

    TCP/IP Level 440 Pascal component compatibility is discussed further in the TCP/IP Usage section.

  • The C-based client and server functions supplied with TCP/IP Level 440 rely upon the C/C++ Language Environment for z/VM run-time library that is provided with z/VM 4.4.0. Because this library resides on the z/VM Product Code minidisk (typically, the MAINT 19E minidisk, or Y-disk), changes to local procedures and modifications may be required to ensure this library is used in conjunction with TCP/IP services.

    For example, if the VMLINK command is currently used to acquire Language Environment support minidisks for using TCP/IP services, it may no longer be necessary to use this command for such a purpose. Similarly, the use of :vmlink. tags within a customized DTCPARMS file may no longer be required.

Packaging-specific Changes

  • TCP/IP CMS Help files are now maintained separately from other TCP/IP for z/VM client files. With this change, these help files are now placed into production on the z/VM Product HELP disk (MAINT 19D, or its equivalent).

  • Linux-based components of the SSL server implementation are now provided using RPM-format files, which are maintained on a newly introduced TCP/IP service build disk. When the SSL server is configured for use, the appropriate RPM package file must be retrieved from this disk and then installed on the intended Linux guest by using the Red Hat Package Manager (RPM).

    The DASD requirements for the SSL Server have also been modified, to allow for more flexibility in how the required Linux guest services are provided. As a result of these changes, SSL-specific binary system files are no longer required (or provided) with TCP/IP for z/VM.

  • The z/VM Version 4 Release 4.0 system directory entries for each TCP/IP for z/VM service virtual machine now include LINK statements for the 4TCPIP40 491 and492 minidisks. These minidisk links have been added to better facilitate the testing of newly applied service.

  • An IMAPAUTH user ID and a corresponding 191 minidisk have been added to the default installation, for supporting the (optional) IMAP User Authentication Exit introduced with this level of TCP/IP for z/VM.

Changes Introduced in TCP/IP Level 430

General Information

  • TCP/IP Level 430 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 430 is not separately orderable from the z/VM product, although it is serviced separately from z/VM. However, note that TCP/IP RSU service is no longer provided in a stand-alone fashion; TCP/IP RSU service is provided as part of a stacked z/VM RSU.

  • TCP/IP Level 430 relies on the presence of certain functions in the Z/VM 4.3.0 levels of CP and CMS. Abends and incorrect results are possible if you attempt to use it with a different level of CP or CMS.

  • TCP/IP softcopy publications are provided in the same manner as other z/VM softcopy publications.

  • The Pascal-based client and server functions supplied with TCP/IP Level 430 are not backward compatible with prior-level TCP/IP "stack" servers, due to internal control block changes that have been implemented in this level of TCP/IP.

    TCP/IP Level 430 Pascal component compatibility is discussed further in the TCP/IP Usage section.

Changes Introduced in TCP/IP Level 420

General Information

  • TCP/IP Level 420 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 420 is not separately orderable from the z/VM product, although it is serviced separately from z/VM. However, note that TCP/IP RSU service is no longer provided in a stand-alone fashion; TCP/IP RSU service is provided as part of a stacked z/VM RSU.

  • TCP/IP Level 420 relies on the presence of certain functions in the Z/VM 4.2.0 levels of CP and CMS. Abends and incorrect results are possible if you attempt to use it with a different level of CP or CMS.

  • TCP/IP softcopy publications are provided in the same manner as other z/VM softcopy publications.

Changes Introduced in TCP/IP Level 410

General Information

  • TCP/IP Level 410 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 410 is not separately orderable from the z/VM product, although it is serviced separately from z/VM.

  • TCP/IP Level 410 relies on the presence of certain functions in the Z/VM 4.1.0 levels of CP and CMS. Abends and incorrect results are possible if you attempt to use it with a different level of CP or CMS.

  • TCP/IP softcopy publications are provided in the same manner as other z/VM softcopy publications.

Packaging-specific Changes

  • TCP/IP for z/VM is no longer a priced feature of z/VM Version 4 Release 1.0. No action is required to activate (enable) this component of z/VM.

  • The TCP/IP NFS Server Feature for z/VM is no longer a priced feature of TCP/IP for z/VM. No action is required to activate (enable) the TCP/IP NFS server.

  • The TCP/IP Source Feature is no longer a priced feature of TCP/IP for z/VM. TCP/IP for z/VM source files are now supplied and installed as part of the z/VM Version 4 Release 1.0 System DDR.

Changes Introduced in TCP/IP Level 3A0

General Information

  • TCP/IP Level 3A0 is included as a priced feature of the z/VM product, requiring that you have a license from IBM for its use. The TCP/IP feature must be enabled using the correct feature code before it can be used.

  • The Network File System (NFS) server is a separately licensed and priced feature of z/VM. Like the base TCP/IP feature, it is included with the z/VM product, but it must be enabled before it can be used. Information about enabling the TCP/IP and TCP/IP NFS Server features is provided in the TCP/IP Feature for Z/VM, Level 3A0 Program Directory.

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

  • TCP/IP Level 3A0 relies on the presence of certain functions in the Z/VM 3.1.0 levels of CP and CMS. Abends and incorrect results are possible if you attempt to use it with a different level of CP or CMS.

  • TCP/IP softcopy publications are included with the other z/VM softcopy publications.

Packaging-specific Changes

  • DES Kerberos functions are now incorporated in the base TCP/IP Feature for z/VM (non-DES Kerberos functions are no longer available). Therefore, customers who have a Kerberos database that was created in a non-DES environment must delete and then rebuild that database using the supplied DES Kerberos functions. Refer to the chapter titled "Configuring the Kerberos Server" in z/VM: TCP/IP Planning and Customization for more information about building the Kerberos database.

  • The various servers and code that provide support for the Network Computing System (NCS) are no longer provided.

  • The installation user ID-owned "Sample" (2C2) minidisk and its corresponding sample files are no longer provided.

Changes Introduced in TCP/IP Function Level 320

General Information

  • TCP/IP Function Level 320 (TCP/IP FL320) is included as a priced feature of the VM/ESA 2.4.0 product, requiring that you have a license from IBM for its use. The TCP/IP FL320 feature must be enabled using the correct feature code before it can be used.

  • The TCP/IP FL320 Network File System (NFS) server is a separately licensed and priced feature of VM/ESA 2.4.0. Like the base TCP/IP FL320 feature, it is included with the VM/ESA 2.4.0 product, but it must be enabled before it can be used. Information about enabling the TCP/IP FL320 and TCP/IP FL320 NFS Server features is provided in the TCP/IP Feature for VM/ESA Function Level 320 Program Directory.

  • TCP/IP FL320 is not separately orderable from the VM/ESA 2.4.0 product, although it is serviced separately from VM/ESA 2.4.0.

  • TCP/IP FL320 relies on the presence of certain functions in the VM/ESA 2.4.0 levels of CP and CMS. Abends and incorrect results are possible if you attempt to use it with a different level of CP or CMS.

  • TCP/IP FL320 softcopy publications are included with the other VM/ESA 2.4.0 softcopy publications.

Function-specific Changes

  • No function-specific packaging changes have been made as part of TCP/IP FL320.

Changes Introduced in TCP/IP Function Level 310

General Information

  • TCP/IP Function Level 310 (TCP/IP FL310) is included as a priced feature of the VM/ESA 2.3.0 product, requiring that you have a license from IBM for its use. The TCP/IP FL310 feature must be enabled using the correct feature code before it can be used.

  • The TCP/IP FL310 Network File System (NFS) server is a separately licensed and priced feature of VM/ESA 2.3.0. Like the base TCP/IP FL310 feature, it is included with the VM/ESA 2.3.0 product, but it must be enabled before it can be used. Information about enabling the TCP/IP FL310 and TCP/IP FL310 NFS Server features is provided in the TCP/IP Feature for VM/ESA Function Level 310 Program Directory.

  • TCP/IP FL310 is not separately orderable from the VM/ESA 2.3.0 product, although it is serviced separately from VM/ESA 2.3.0.

  • TCP/IP FL310 relies on the presence of certain functions in the VM/ESA 2.3.0 levels of CP and CMS. Abends and incorrect results are possible if you attempt to use it with a different level of CP or CMS.

  • TCP/IP FL310 softcopy publications are included with the other VM/ESA 2.3.0 softcopy publications.

Function-specific Changes

  • TCP/IP-based user e-mail functions are included in CMS. TCP/IP-specific versions of NOTE and SENDFILE are NOT provided with the TCP/IP Feature.

  • A subset of RSCS Version 3 Release 2 function is available with the z/VM product to provide enhanced TCP/IP client and server print capabilities. RSCS functions not related to TCP/IP printing enhancements require a separate RSCS license for use. Refer to the RSCS Version 3 Release 2 Program Directory for additional information.

  • Non-DES Kerberos functions are included in the base TCP/IP Feature. DES Kerberos functions are available as a separate feature that must be separately installed.

Top of Page