Find job logs from TCP/IP server prestart jobs

When the connection ends that is serviced by one of the QRWTSRVR prestart jobs associated with the distributed data management (DDM) TCP/IP server, the prestart job is recycled for use by another connection. When this happens, the job log associated with the ended connection is cleared.

However, in certain cases the job log is spooled to a printer file before it is cleared. The job log is not printed to a spooled file if the client user ID and password were not successfully validated. If validation was successful, these are the conditions under which the job log is printed to a spooled file:

If the operating system is at V5R1 or later and the server job's message logging text level is *SECLVL or *MSG.
If the server request handler routing program detects that a serious error occurred in processing the request that ended the connection.
If the prestart job was being serviced (by use of the Start Service Job (STRSRVJOB) command).
If the QRWOPTIONS data area on the client or server specified a job log output condition that was satisfied by the server job.

You might want to get job log information for several reasons. It is obviously useful for diagnosing errors. It can also be useful for analyzing performance problems. For example, if you want to get SQL optimizer data that is generated when running under debug, you can either manually start a service job and run the Start Debug (STRDBG) command, or you can set one or more applicable options in the QRWOPTIONS data area to cause the job log to be retained.

The logs of jobs in which failures occur during the connection phase will not be saved by the process described above. Jobs that are saved by that process will not be stored under the prestart job ID. To find them, run the following command:

WRKJOB userid/QPRTJOB

where userid is the user ID used on the CONNECT to the application server (AS). You can find that user ID if you do not know it with the Display Log (DSPLOG) command on the AS.

You can filter out unwanted messages by use of parameters like this:

DSPLOG PERIOD(('11:00')) MSGID(CPI3E34)

Look for the following message. Note, however, that if the QRWOPTIONS data area has been used to suppress this message (CPI3E34), it will not appear in the history log.

DDM job xxxx servicing user yyy on ddd at ttt.