IBM Books

Connectivity Supplement


Setup and Use Considerations for the DB2 Universal Database for AS/400 DRDA TCP/IP Server

The main consideration in setting up the DB2 Universal Database for AS/400 DRDA TCP/IP server is to ensure that the server has been started. The CL command to start the DRDA server (also known as the DDM server) is:

   STRTCPSVR SERVER(*DDM)

The DRDA server can also be started using the Start TCP/IP Server (STRTCPSVR) command without parameters, or with *ALL specified for the SERVER parameter. The DRDA server will be started automatically when TCP/IP is started if this CL command has been issued:

   CHGDDMTCPA AUTOSTART(*YES)

One can verify that the server has been started by issuing the following CL command:

   WRKUSRJOB USER(QUSER) STATUS(*ACTIVE)

This command will show a scrollable list of jobs. If you scroll down a page or so, you should see two lines containing the following information:

   __   QRWTLSTN    QUSER       BATCH    ACTIVE
   __   QRWTSRVR    QUSER       PJ       ACTIVE

(There may be repeated occurrences of the QRWTSRVR line, depending on how many prestart server jobs are active.)

The presence of the QRWTLSTN line indicates that the job that listens for DRDA and DDM connections requests is active. This job dispatches work to the QRWTSRVR job(s) as connection requests are received.

The other way to verify that the DRDA server has been started is to issue the STRTCPSVR SERVER(*DDM) command and look for the 'DDM TCP/IP server already active' message.

The name of the prestart job used for a particular connection can be found by issuing a DSPLOG command such as:

   DSPLOG PERIOD(('15:55'))

where the time specified is earlier than when the connection was made. This will result in a scrollable list of history log entries. Look for an entry like this, which will contain the name of the server job:

   DDM job 039554/QUSER/QRWTSRVR servicing user SRR on 03/30/98 at 15:57:38.

This jobname is useful for looking at the joblog of still-active jobs. It is also useful for starting a service job on still-active jobs for problem determination or to see query optimizer messages. An example CL command to start a service job using the above information would be:

   STRSRVJOB 039554/QUSER/QRWTSRVR

To put the serviced job into debug mode, execute the STRDBG command:

   STRDBG UPDPROD(*YES)

In certain situations the DRDA server saves the joblog of the prestart job before recycling the job and clearing the joblog. This happens when a serious failure has been detected, or when the job ended while being serviced (using the STRSRVJOB command).

To find the saved joblog after the job has ended, issue the following command:

   WRKJOB userid/QPRTJOB

where userid is the name of the userid under which the connection was made (SRR in the above example).

This will display a list of jobs from which one can be selected, or an option menu for a single job. Choose option 4, 'Work with spooled files' to find the saved joblog. It will be the one with file name of QPJOBLOG in case there are multiple files spooled. Option 5 will let you view the joblog file.

An example of the type of query optimizer messages one may see in a server joblog when the job was run under debug is the following:

   CPI4329    Information   00    03/30/98   16:14:57   QQQIMPLE
               QSYS        3911     QSQOPEN      QSYS         09C4
   Message . . . . :   Arrival sequence access was used for file TBL2.
   Cause . . . . . :   Arrival sequence access was used to select
     records from member TBL2 of file TBL2 in library SR. If file TBL2
     in library SR is a logical file then member TBL2 of physical file
     TBL2 in library SR is the actual file from which records are
     being selected. A file name of *N for the file indicates it is a
     temporary file. Recovery  . . . :   The use of an access path may
     improve the performance of the query if record selection is
     specified. If an access path does not exist, you may want to
     create one whose left-most key fields match fields in the record
     selection.  Matching more key fields in the access path with
     fields in the record selection will result in improved
     performance. Generally, to force the use of an existing access
     path, specify order by fields that match the left-most key fields
     of that access path. For more information refer to the DB2 for
     AS/400 SQL Programming book.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]