The QDFTSVR Job Description

Many prestart server jobs on IBM i use the default server job description (QGPL/QDFTSVR) provided with the operating system. Several of host servers use the QSYS/QZBSJOBD job description, but that job description has the same default parameter settings as the QDFTSVR job description.  These job descriptions are defined for optimal performance for prestart jobs.  

Below are a few of the QDFTSVR parameter settings provided by IBM with a description of why these settings are selected for prestart jobs.

• End severity (ENDSEV)
  The end severity defines the severity code of an unmonitored escape message that will cause the job to end. This parameter is set to the default value 30, which is defined as a severe error. This is generally a good setting for the ENDSEV parameter.
• Message Logging (LOG)
  The setting for the message logging parameter is (4, 0, *NOLIST) which is a good setting to log all messages when the job is active, but to not generate job logs when jobs end normally. The level and severity of 4, 0 causes all messages to be logged to the job log, but *NOLIST specifies that no job log is generated if the job ends normally. If the job ends abnormally, a job log is generated. If you specify *SECLVL for the message text, then a full job log is always generated when the job ends, regardless of whether that ending was normal or not.
• Job Log Output (LOGOUTPUT)
  Creating spooled job logs takes system resources to write the spooled file, as well as storage for the spooled files. Pending job logs (*PND) still consume storage, but no system resources are used to generate spooled files.  This is generally a good thing since most of the time spooled job logs are not needed.  There is a downside to pending job logs; if you detach your spooled files, pending job logs remain associated with the job and continue to use a job structure. This prevents you from getting the full benefits of detaching spooled files.  The system’s automatic cleanup will remove pending job logs just as it does for other job logs.   The default value of the LOGOUTPUT parameter on the CRTJOBD command is *SYSVAL, but IBM uses *PND for QDFTSVR.  I previously wrote about pending job logs in the blog Job Log Pending.  IBM’s documentation on Managing Job Logs is also a good reference on this topic.
• Job message queue maximum size (JOBMSGQMX) and job message queue full action (JOBMSGQFL)
  Large job logs can consume a lot of disk space and have potential impacts at IPL if job message queues need recovery. IBM intentionally sets the job message queue size to be relatively small at 4MB. This, along with the job message queue full action of *WRAP work in conjunction to have small jobs logs that wrap when they become full. It’s not advised to make the job message queue size bigger for all your server jobs; rather, if you have a need for a larger job log, only increase the size for the jobs that need it. The default value for these parameters on the CRTJOBD command is *SYSVAL, but IBM has specified the values as described above for the QDFTSVR job description.
• Spooled File Action (SPLFACN)
  The spooled file action parameter determines whether spooled files remain associated with a job, or whether they are “detached” and become disassociated with the job. The main benefit of detaching spooled files is to reduce the number of jobs on the system. The default value is *SYSVAL. Read the blog Detach Spooled Files from a Job for more information.

You may need to change the job description associated with a prestart job entry if you find you need to generate a job log (e.g., LOGLVL of (4,0,*SECLVL), need a larger job log, or want to print the job log when the job message queue wraps by using the *PRTWRAP value for the JOBMSGQFL parameter. You should only change the job description for the jobs that need the additional information; create a duplicate of the QDFTSVR job description, modify the copy to have the desired parameters, then use the new job description by changing the prestart job entry (CHGPJE) for the desired jobs. You must restart the jobs for the change to take effect; for example, if you wanted additional logging for the database host server jobs (QZDASOINIT), use the ENDHOSTSVR *DATABASE followed by STRHOSTSVR *DATABASE commands. The article Changing job attributes for prestart jobs in the Knowledge Center discusses this topic.

The Redpaper, Best Practices for Managing IBM i Jobs and Output discusses these topics in more detail. While it’s dated 2008, the material is still relevant.  The Redpaper, Best Practices for Managing Job Logs on IBM i has a few additional tips for managing job logs.