DB2 Administration Server (DAS) Process Model on zOS

Content

The DB2® Administration Server (DAS) for z/OS® is a daemon process that runs under z/OS UNIX® System Services (USS) and provides back-end support for the IBM® DB2 Universal Database graphical tools (including the Control Center and the Replication Center). In particular, the DAS supports the following functions in the Control Center:

• Building and creating JCL jobs (used by the Create JCL and Build JCL Dialogs, which are in turn used by most Control Center z/OS functions such as running DB2 utilities or cloning a subsystem)
• Reading and writing data sets (supports PS, PDS, PDSE data sets with RECFM=FB)
• Querying operating system catalog information
• Executing shell scripts in z/OS UNIX System Services (used by Replication Center to start and stop capture and apply programs)
• Issuing MVS™ system commands through an extended console (used by the Command Editor when working against a z/OS subsystem)
• Performing batch object maintenance

Knowledge of the DAS process model can help you understand the expected behavior of the DAS and its associated components. The following sections briefly describe the major processes that comprise the DAS, and the interaction between these components.

DAS Processes

db2dasrrm - DAS request and reply manager. The main DAS process. Listens on port 523 for DAS requests. Accepts requests, performs authentication, and then routes the requests to worker processes. This process runs for as long as the DAS is started.
db2dasstml - DAS worker launcher process. A transient process, used to startup a DAS worker process. Sets up the environment and the user ID for the DAS worker process.
db2dasstm - DAS worker process. Handles work performed by the DAS (refer to the introduction for a list of the different operations that will be executed through the DAS). This process exists as long as it takes to complete the work it has been assigned. Typically one worker process exists for each request currently being handled by the DAS (It might be less as some pooling of workers takes place).
db2dasstma - Special DAS worker process, used to handle operations that require APF authorization. Behavior is identical to the db2dasstm process.
db2dassec - DAS authentication process. A transient process that is invoked to perform authentication of user ID and password provided on a DAS request.

Throughout the remainder of this document, the db2dasstm and db2dasstma processes are referred to collectively as DAS worker processes, except when the distinction between them is important.

DAS Lifecycle

The DAS is installed under the home directory of a user, referred to hereafter as the DAS owner. The DAS is started by logging into the DAS owner account, and issuing the following command:

	db2admin start 

The db2admin start command launches the db2dasrrm process as a daemon process, and then returns control to the command line. If you run the ps -ef command from the z/OS UNIX shell following the db2admin start command, you should see the following:

$ ps -ef       UID        PID       PPID  C    STIME TTY       TIME CMD   DASUSER   50331683          1  -   Jun 06 ?         0:26 /u/dasuser/das/adm/db2dasrrm   DASUSER   83886116   16777253  -   Jun 06 ?         0:00   DASUSER   50331686   83886116  -   Jun 06 ?         0:00       :       : 

Another way to display current active USS processes is to use the DISPLAY command. If you issue the D OMVS,A=ALL command from an MVS console or SDSF log following the db2admin start command, you should see the following:

D OMVS,A=ALL  BPXO040I 06.44.17 DISPLAY OMVS 814  OMVS     000D ACTIVE          OMVS=(00)  USER     JOBNAME  ASID        PID       PPID STATE   START     CT_SECS  OMVSKERN BPXOINIT 001C          1          0 MR---- 03.56.19      3.61    LATCHWAITPID=         0 CMD=BPXPINPR    SERVER=Init Process                     AF=    1 MF=00000 TYPE=FILE  OMVSKERN TCPIP    002A   16777218          1 MR---B 03.58.49    436.98    LATCHWAITPID=         0 CMD=EZBTCPIP  OMVSKERN TCPIP    002A   16777219          1 1R---B 03.58.53    436.98    LATCHWAITPID=         0 CMD=EZBTTSSL    :    :  OMVSKERN TCPIP    002A         10          1 1R---B 03.58.58    436.98    LATCHWAITPID=         0 CMD=EZBTTMST  DASUSER  DASUSER6 0034   50331683          1 HFI--- 06.58.38     26.74    LATCHWAITPID=         0 CMD=/u/dasuser/das/adm/db2dasrrm  DASUSER           0000   83886116   16777253 1L---- 06.56.54       .00  DASUSER           0000   50331686   83886116 1L---- 06.58.06       .00  SYSDSP   V81AWLM3 003B   67109133          1 1R---- 05.24.40       .18    LATCHWAITPID=         0 CMD=DSNX9WLM  SYSDSP   V81AWLM1 003F   50331918          1 1RI--- 05.24.28       .11    LATCHWAITPID=         0 CMD=DSNX9WLM  DASUSER  DASUSER3 003D   50331921   67109138 1CI--- 06.37.04       .09    LATCHWAITPID=         0 CMD=sh -L    :    : 

The display output shows all the active OMVS processes, ASIDs, process IDs, parent process IDs, and job names. In this example, the job name generated for the db2dasrrm process is DASUSER6. For more information on how job names are generated, refer to the section "Generating jobnames for OMVS address spaces" of the z/OS UNIX System Services Planning manual.

Notice that two other processes are shown running under the DASUSER user ID. These processes are shell processes and not part of the DAS itself.

The db2dasrrm executable always runs under the user ID of the DAS owner. It binds to TCP port 523 (the well-known reserved DAS port) and listens for incoming requests from the Control Center. The DAS is threaded and other threads are active in this process (most of which perform cleanup operations on intervals around two or more hours). As long as no requests are being driven to the DAS from the Control Center, the db2dasrrm process should consume almost no CPU resources and minimal memory resources.

The following flowchart shows the processing that takes place when the DAS receives a request from the Control Center. This chart provides an overview of where and when the different processes are created, and the work carried out by each process.

Note: Right-click on the image and use your browser to view a larger version of the image.









1) The request is accepted and a thread is created in the db2dasrrm to handle the request.
2) The request message is read from the TCP socket by the new thread.
3) The authentication information provided in the request (user ID and password) is decrypted. A db2dassec process is started and passed the user ID and password information. The db2dassec process checks whether or not the credentials are valid. Authentication is delegated to this separate process because root authority is required to validate the user ID and password. It is not desirable to have the DAS listener (db2dasrrm), which is a long running process, executing as root during its lifetime. So the db2dassec process (which is only invoked to perform authentication and then goes away) is used to handle authentication.
4) If the user ID and password provided in the request are valid, a db2dasstml (worker launcher) process is created. The worker launcher process sets up the environment for the worker process (e.g. PATH, LIBPATH, etc) and switches the user ID to the user iD provided in the request. Then the db2dasstml process launches the worker process (db2dasstm or db2dasstma), which handles the processing that is associated with the request. In most cases, the worker process that is started is a db2dasstm process. However, some operations supported through the DAS (such as EMCS console commands) require APF authorization. When these operations are executed through the DAS, the worker process that is started is the db2dasstma process.

The DAS uses an impersonation security model for handling requests. That is, when worker (db2dasstm or db2dasstma) processes are started, they run under the authority (user ID) provided in the DAS request. This process ensures that the worker is not capable of taking any action that the user issuing the request is not authorized to perform. This also implies that when looking at DAS processes using the D OMVS,A=ALL DISPLAY command, the worker process will be running under the userid that initiated the DAS request, not the DAS owner userid.

For example, if you start the Control Center, select a table space object and select the Create JCL action from the DB2 for z/OS subsystem using the user ID ADMF001, and then run the D OMVS,A=ALL DISPLAY command, you should see the following output:

D OMVS,A=ALL  BPXO040I 07.30.30 DISPLAY OMVS 125  OMVS     000D ACTIVE          OMVS=(00)  USER     JOBNAME  ASID        PID       PPID STATE   START     CT_SECS  OMVSKERN BPXOINIT 001C          1          0 MR---- 07.09.51      5.62    LATCHWAITPID=         0 CMD=BPXPINPR    SERVER=Init Process                     AF=    1 MF=00000 TYPE=FILE  OMVSKERN TCPIP    002A   16777218          1 MR---B 07.13.03    635.57    LATCHWAITPID=         0 CMD=EZBTCPIP    :    :  DASUSER  DASUSER6 0032   33554467          1 HF---- 07.35.31     25.32    LATCHWAITPID=         0 CMD=/u/dasuser/das/adm/db2dasrrm  SYSDSP   V71BDIST 0039   16777252          1 MF---B 07.21.24      9.25    LATCHWAITPID=         0 CMD=DSNVEUS3  OMVSKERN INETD    003C   33554469          1 1FI--- 07.30.42       .06    LATCHWAITPID=         0 CMD=/usr/sbin/inetd -d  DASUSER           0000   67108902   16777255 1L---- 07.35.30       .00  DASUSER           0000   16777255   67108898 1L---- 07.34.57       .00  SYSDSP   V81AWLM1 003B   16777334          1 1RI--- 07.13.18       .09    LATCHWAITPID=         0 CMD=DSNX9WLM  SYSDSP   V81AWLM3 0022        119          1 1R---- 07.13.24       .08    LATCHWAITPID=         0 CMD=DSNX9WLM  ADMF001  DASUSER9 0020   83886202          1 1K---- 07.30.27       .12    LATCHWAITPID=         0 CMD=/u/dasuser/das/bin/db2dasstm 182 

The worker (db2dasstm or db2dasstma) process created handles the work associated with the Create JCL function.

The worker (db2dasstm or db2dasstma) processes are threaded and are capable of handling more than one request at a time. So if the same user issues multiple DAS requests, these requests typically get routed to the same worker process running on the server. Worker process are pooled on the user ID though. Thus, a request from one user is never routed to a worker process handling a request from another user (in this case, a different worker process would be created to handle the request, and the new process would run under the new user ID). After a period of inactivity (no new requests) of approximately 40 seconds, a worker process shuts itself down, to limit the amount of resources the DAS consumes on the system.

The DAS is stopped by logging in as the DAS owner and issuing the following command:

	db2admin stop 

This commands stops the DAS listener process (db2dasrrm) and any active worker (db2dasstm or db2dasstma) processes. After running the db2admin stop command, if you issue the DISPLAY command D OMVS,A=ALL you should no longer see any db2dasrrm or DAS worker processes running on the system.