Db2 uses the assembler callable interface of z/OS UNIX System Services to perform TCP/IP services.
About this task
Any address space that needs to use z/OS UNIX System Services must have a z/OS user ID that is defined with an OMVS segment, and can also have a z/OS group name. 
The user ID associated with the ssnmDIST started task and ssnmDBM1 started task requires an OMVS segment for DDF functions and system profile functions.
The standard way to assign a z/OS user ID and a z/OS group name to a started address space is to use the z/OS Security Server (RACF®) STARTED resource class. This method enables you to dynamically assign a z/OS user ID by using commands instead of requiring an IPL to have the assignment take effect.
The alternative method to assign a z/OS user ID and a z/OSgroup name to a started address space is to change the RACF started procedures table, ICHRIN03. For more information about this approach, see Defining RACF user IDs for Db2-started tasks.
Procedure
To enable Db2 address spaces to access TCP/IP services in z/OS UNIX System Services, complete the following steps:
- Use either of the following z/OS Security Server (RACF) commands to assign an OMVS segment to a z/OS user ID, where user-ID is the z/OS user ID for the Db2 address space and nnn is any valid, unique identifier. If you set nnn to 0, the process has UNIX System Services superuser authorization.
You should either set the MAXFILEPROC parameter to at least 131072 or grant superuser authority to the user-ID. Because setting the MAXFILEPROC parameter within the active BPXPRMnnn z/OS PARMLIB member to 131072 affects the entire system, any z/OS UNIX System Services process can open 131072 files or sockets concurrently.
- During initialization, DDF calls z/OS UNIX System Services to obtain the maximum number of socket descriptors that can be opened concurrently. The value is defined by the MAXFILEPROC parameter in the active z/OS UNIX System Services (BPXPRMnnn) of the z/OS PARMLIB. If the defined value is less than 131072, DDF invokesz/OS UNIX System Services to raise it to 131072, which requires the DDF user ID to have superuser authority. DDF executes as an authorized program and is protected against unauthorized use of this privilege. If you do not want to set the system-wide MAXFILEPROC parameter to 131072 and do not want to grant superuser authority to the DDF user ID, you can explicitly authorize the DDF user ID to raise the limit to 131072 by using one of the following RACF commands, where user-ID is thez/OS user ID and nnn is any valid, unique identifier:
- If you also want to assign a z/OS group name to the address space, assign an OMVS segment to the z/OS group name by using one of the following RACF commands, where group-name is the z/OS group name and nnn is any valid, unique identifier
- If you actively administer the STARTED resource class, issue the following RACF commands to assign a z/OS user ID and a z/OS group name to the address space started procedure, where
VC1ADIST.* is the addresssapce started procedure, user-ID is the z/OS user ID, and group-name is the z/OS group name. DDF requires only a z/OS user ID. A z/OS group name is optional.
RDEFINE STARTED (VC1ADIST.*) STDATA(USER(user-ID) GROUP(group-name)) ...
RALTER STARTED (VC1ADIST.*) STDATA(USER(user-ID) GROUP(group-name)) ...
Requirement: The profile name that you specify in the RACF command must be in the generic format; that is, the profile name must end with a period followed by an asterisk (.*).
- Issue the following RACF command so that the changed profile takes effect:
SETROPTS RACLIST(STARTED) REFRESH
- When a member-specific dynamic VIPA (VIPARANGE DVIPA) is specified in the Db2 BSDS using the DSNJU003 keywords IPv4 or IPv6, DDF internally activates the DVIPA using the SIOCSVIPA/SIOCSVIPA6 IOCTL. However, you must either grant superuser authority to the DDF user ID or define a security profile for MODDVIPA under the SERVAUTH class to authorize the DDF user ID to execute the SIOCSVIPA/SIOCSVIPA6 IOCTL. You can define the security profile using RACF as follows:
RDEFINE SERVAUTH (EZB.MODDVIPA.sysname.tcpname)UACC(NONE)
PERMIT EZB.MODDVIPA.sysname.tcpname ACCESS(READ) CLASS(SERVAUTH) ID(USER1)
- sysname is the name of the MVS™ system where the ID runs the MODDVIPA utility or issues the SIOCSVIPA/SIOCSVIPA6 IOCTL.
- tcpname is the job name of the TCP/IP started task.
- USER1 is the DDF user ID that is being permitted to run the MODDVIPA utility (and thus the SIOCSVIPA/SIOCSVIPA6 IOCTL).
If this security profile is created, the user ID must be permitted to access this profile. Otherwise, the SIOCSVIPA/SIOCSVIPA6 IOCTL (and thus the MODDVIPA utility) fails with a permission denied
error, regardless of superuser authority.
Also note that when using RACF, you might need to refresh these profiles before they take effect. Use the following RACF command to refresh these profiles:
SETROPTS RACLIST(SERVAUTH) REFRESH
- Db2 for z/OS utilizes a TCP/IP DROP API through the EZBNMIFR callable service (NMI), and Db2 requires that RACF security profiles be defined to permit Db2 to successfully utilize this API. You must issue a RACF PERMIT command to enable ssnmDIST_userid CONTROL access to the MVS.VARY.TCPIP.DROP command for the OPERCMDS class, where ssnmDIST_userid is the user ID that is associated with the ssnmDIST started task.
Example (where the ssnmDIST_userid is SYS0):
RDEFINE OPERCMDS MVS.VARY.TCPIP.DROP OWNER(SYS0) UACC(NONE)
PERMIT MVS.VARY.TCPIP.DROP CLASS(OPERCMDS) ID(SYS0) ACCESS(CONTROL)
Failure to provide this permission might result in a ICH408I message similar to the following:
ICH408I USER(ssnmDIST_userid) ...
MVS.VARY.TCPIP.DROP CL(OPERCMDS) ...
For more information, see EZBNMIFR: Configuration and enablement.