Steps for setting up servers

Before you begin: You will need to know which programs are program-controlled. To identify those programs, use the RACF® RDEFINE command, which is discussed in Customizing the system for IBM-supplied daemons.

Perform the following steps each time you add a server.

Define all programs that are loaded into an address space that requires server authority, including the server program and any runtime library modules, to program control. For more information about defining programs to program control, see Defining modules to program control.
_______________________________________________________________
Assign a user ID to the server and define it to RACF.
Example: Assume that the user ID of the server is DATASRVR. Define user ID DATASRVR to RACF.
```
ADDUSER DATASRVR DFLTGRP(OMVSGRP) OMVS(UID(7) HOME('/') 
PROGRAM('/bin/sh')) NOPASSWORD
```
Tip: You can use the NOPASSWORD option with the ADDUSER command for DATASRVR. This indicates that it is a protected user ID that cannot be used to enter the system by means of a password or password phrase. The user ID will not be revoked due to invalid logon attempts. In this case, you are defining the DATASRVR user ID without a TSO/E segment.

_______________________________________________________________

Create a cataloged procedure. For example:

//DATASRVR PROC
//DATASRVR EXEC PGM=DATASRVR,REGION=0M,TIME=NOLIMIT,
//      PARM='POSIX(ON) ALL31(ON)/ serverparms'
//SYSPRINT    DD SYSOUT=*

_______________________________________________________________

Enable the DATASRVR cataloged procedure to obtain control with the required user identity. To do so, you must either add it to the RACF STARTED class or add an entry to the started procedures table.
Example: To add an entry to the started procedures table:
```
DC    CL8'DATASRVR' PROCEDURE NAME
DC    CL8'DATASRVR' USERID (ANY RACF-DEFINED USER ID)
DC    CL8'DATASGRP' GROUP NAME OR BLANKS FOR USER'S DEFAULT GROUP
DC    XL1'00'       NOT TRUSTED
DC    XL7'00'       RESERVED
```
_______________________________________________________________
Create the FACILITY class profile for the server.
```
RDEFINE FACILITY BPX.SERVER UACC(NONE)
SETROPTS RACLIST(FACILITY) REFRESH
```
_______________________________________________________________
Activate program control for the server, if you have not already done so for daemon support.
```
SETROPTS WHEN(PROGRAM)
```
_______________________________________________________________
Grant a level of authority to the server using thread-level security services. The BPX.SERVER FACILITY class profile controls the server's access to the pthread_security_np() service. There are two choices when setting the server's authority:
- UPDATE access allows the server to establish a thread-level (task-level) security environment for clients connecting to the server. Decisions about access control for z/OS resources (such as data sets) and to z/OS UNIX resources (such as UNIX files) that are accessed by the client's thread in the server are made using only the RACF identity of the client.
  Example: To give UPDATE access in the BPX.SERVER FACILITY class profile to user ID DATASRVR:
```
PERMIT BPX.SERVER CLASS(FACILITY) ID(DATASRVR) ACCESS(UPDATE)
SETROPTS RACLIST(FACILITY) REFRESH
```
- READ access allows the server to establish a thread-level security environment for the clients that it services. However, unless the server has specified a valid RACF password, password phrase, or PassTicket on the pthread_security_np() service invocation, the user ID of the server and the user ID of the client are used in resource access control decisions.
  Example: To give DATASRVR server authority for unauthenticated clients:
```
PERMIT BPX.SERVER CLASS(FACILITY) ID(DATASRVR) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
```
  If you are installing a product that uses thread-level security services, check the documentation that is supplied with the product to determine if the server requires READ or UPDATE access to the BPX.SERVER profile.
  
  If you grant READ access to the BPX.SERVER profile in the FACILITY class, and the server does not request a password, password phrase, or PassTicket for its clients, both the server's user ID and the client's user ID are used in decisions about resource access control. Additional security administration will have to be performed to ensure that both the server's user ID and the client's user ID were appropriately authorized to the resources that are accessed by the server.
_______________________________________________________________

When you are done, you have set up the server.

Example: To start DATASRVR, issue the following command from the MVS™ console:

S DATASRVR

If the DATASRVR daemon is deactivated, you can also issue this command to restart it.