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:
Server Topics:
Other Topics:
Notes:
-
TCP/IP and related features are supported on associated releases of CP
and CMS only.
-
(
)
Select the TCP/IP
Stack server link to review information about changes
introduced with z/VM Version 4 Release 4 that establish
changes to the following defaults:
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
Changes Introduced in TCP/IP Level 420
Top of Page
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
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
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
Top of Page
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
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
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
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
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
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
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 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
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
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
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:
- userid TCPIP
- nodename TCPIP
- 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:
-
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.
-
Modify the OBEY statement such that affected application
virtual machines are included in the TCP/IP obey list.
-
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
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
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
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
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
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
|
