The QDFTSVR Job Description
By Dawn May / October 25, 2018
QDFTSVR parameter settings provided by IBM with a description of why these settings are selected 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.
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.
Tagged as:
IBM i / Article / Community / Systems management / i Can blog
About the author
Dawn May is an IBM i consultant. She owns Dawn May Consulting, LLC in the Greater Boston area. Dawn is a former IBM senior technical staff member.
See more by Dawn May