Changes for z/OS V1R4 include support for Internet Protocol Version 6 (IPv6), improved UNIX security management, greater application flexibility with zFS and REXX enhancements, and new system management features.
||z/OS UNIX IPv6 support
UNIX System Services offers CINET support for Internet Protocol Version 6 (IPv6). IPv6 increases the size of IP addresses from 32 bits to 128 bits, making possible 340 billion billion billion billion unique IP addresses. IPv6 can be added to, and is interoperable with, IPv4 systems. Local INET (BPXTLINT) is no longer supported.
You activate IPv6 on a system by adding a second NETWORK statement to the definition of the INET or CINET configuration, using AF_INET6 as the domain value. You can also add the second NETWORK statement dynamically with SETOMVS RESET=(), although the TCP/IP stacks have to be recycled in order for IPv6 to be activated.
Other changes to support IPv6:
- The CINET operand on the DISPLAY OMVS operator command displays 16-byte IP addresses, where appropriate, if IPv6 is in use.
- The inetd and rlogind daemons are enhanced to support IPv6 connections.
- The socket callable service (BPX1SOC) supports the use of AF_INET6 as the domain value to create IPv6 sockets.
- Three new callable services provide for protocol-independent name resolution services:
- BPX1GAI (Get the IP address and information of a service name or location)
- BPX1FAI (Free Addr_Info structures)
- BPX1GNI (Get the host name and service name from a socket address)
For more information about IPv6, see the home page for Playground.Sun.Com, a server operated by the Internet Engineering group of Solaris Software, a division of Sun Microsystems, Inc.
||UNIX security management enhancements
- UID/GID Enhancements
Enhancements to the way UIDs and GIDs can be assigned by RACF make managing UNIX identities for users and groups easier and less error prone. Administrators can:
- Use the new RACF facility class profile, BPX.NEXT.USER FACILITY, to have UIDs and GIDs automatically assigned to new users. The AUTOUID and AUTOGID keywords of ADDUSER/ALTUSER allow RACF to automatically assign an unused UID or GID to a user or group.
- Assign shared (non-unique) UIDs and GIDs to z/OS UNIX groups, or prevent them from being shared, using the SHARED keyword of ADDUSER/ALTUSER/ADDGROUP/ALTGROUP. The SHARED.IDS profile must be defined in the UNIXPRIV class.
- Determine the user, or set of users, currently assigned a given UID, using the UID keyword of the SEARCH command.
- Determine the group, or groups, currently assigned a given GID value, using the GID keyword of the SEARCH command. This provides an alternative to using the UNIXMAP class.
- Use the FILE.GROUPOWNER.SETGID class profile in the UNIXPRIV class to specify that the group owner of a new HFS file is to come from the effective GID of the creating process. Previously, only the group owner of the parent directory could be the group owner of a new HFS file.
- Enhanced program security
RACF provides enhanced program control checking for privileged z/OS UNIX programs that require a program-controlled environment. The BPX.MAINCHECK security profile allows files to be defined to RACF as trusted, or "MAIN". HFS programs must be moved to an MVS library before they can be defined to MAIN.
- Sanction lists
Sanction lists provide additional security for APF or program-controlled programs. You can compile a single list to contain the lists of pathnames and program names that are sanctioned by the installation for use by APF-authorized or program-controlled calling programs.
- A new BPXPRMxx statement, AUTHPGMLIST, specifies that a sanction list is to be used and points to the sanction list HFS file. The value in AUTHPGMLIST is the pathname of the HFS file that contains the sanction list.
- SETOMVS has a new keyword, AUTHPGMLIST, which specifies that a sanction list is to be used.
- The output of DISPLAY OMVS contains the AUTHPGMLIST value.
- Transport Layer Security (TLS) Certificate Support
The BPX1SEC callable service has a new function code, SECURITY_CERTAUTH#, that allows users to supply a digital certificate for authentication of a specified user ID. Once the authentication is provided, a setuid() can be used to change the MVS/UNIX identify to that of the specified user ID.
- zFS enhancements
With z/OS Distributed File Service zSeries File System (zFS), you can put multiple mountable file systems into a single data set, called an aggregate. You can display the names of aggregate file systems with:
- The w_getmountent (BPX1GMN) file system interface
- The DISPLAY OMVS,FILESYSTEM operator command
- The MODIFY BPXOINIT,FILESYS=DISPLAY operator command
- The df shell command
- ISHELL File System Attributes
You can use the ISHELL to create HFS-compatible zFS file systems.
- REXX enhancements
Level-1 support for REXX functions that extend the REXX language in the z/OS UNIX environment. Some of these were previously available on the UNIX System Services Tools & Toys Web page.
Functions for standard REXX I/O:
Functions for accessing common file services and environment variables:
- BPXWDYN, which makes dynamic allocation and dynamic output services easily accessible to programs running outside of a TSO environment. (It also functions in a TSO environment.) It supports data set allocation, unallocation, concatenation, and the addition and deletion of output descriptors.
BPXWDYN is designed to be called from REXX, but it may be called from several other programming languages, including Assembler, C, and PL/I.
- A TSO host command environment that permits a REXX program to run TSO/E commands.
- Support for "immediate commands," TSO/E REXX commands that change characteristics that control the execution of an exec or program.
See z/OS V1R4.0 Using REXX and z/OS UNIX System Services.
- /dev enhancements
The /dev/fd/ n file is supported, and can be created dynamically.
||System management features
- Enhanced pthread_quiesce
Two new thread-scope signals, SIGTHSTOP and SIGTHCONT, allow individual threads to be stopped and resumed. These signals can only be used with the pthread_kill command.
- z/OS UNIX process start/end exits
Applications can use four installation exit points to monitor the creation and termination of processes:
- Pre-process initiation exit (BPX_PREPROC_INIT), which receives control immediately before the creation of a new z/OS UNIX process
- Post-process initiation exit (BPX_POSPROC_INIT), which receives control immediately after the creation of a new z/OS UNIX process
- Process image initiation exit (BPX_IMAGE_INIT), which receives control immediately before the initiation of a new z/OS UNIX process image
- Pre-process termination exit (BPX_PREPROC_TERM), which receives control immediately before the termination of a z/OS UNIX process
- Automove system list
You can compile an automove system list to indicate where specified file systems should and should not be moved when a system is taken out of a sysplex. Until now, file systems defined with AUTOMOVE=YES have been moved randomly.
- The MOUNT statement of BPXPRMxx has a new keyword, AUTOMOVE, which indicates where the specified file systems should be moved when systems leave the sysplex.
- The SETOMVS operator command has a new keyword, AUTOMOVE, which indicates where the specified file systems should be moved when systems leave the sysplex.
- The DISPLAY OMVS,F operator command displays the list of file systems that will be moved.
- A new variable for mount requests, MNTE_SYSLIST, is added to the getmntent and mount syscall commands.
- Distributed byte range lock manager (BRLM)
This release allows for distributed, rather than centralized, BRLM. With distributed BRLM, each system in a sysplex is started with BRLM, and each BRLM maintains locks for files in files systems that are locally owned. When a remote sysplex member dies, many applications that lock locally mounted files are unaffected.
Conversion to distributed BRLM is enabled with a new parameter (DISTRBRLM) on the CDS format utility IXCL1DSU. In a future release, distributed BRLM will be the default.
- Signal during socket suspends
Signal termination processing is enhanced to terminate threads in a TCP/IP socket suspend.
(Currently, fastpath processing for TCP/IP socket calls causes TCP/IP to wait for the task during a kernel syscall. This places the task in a state in which signal delivery cannot be executed, and defers indefinitely any signal sent to the suspended thread. The only way to terminate the process when the thread is hung in this wait is with the operator's CANCEL command.)