Midrange Programmer--Admin Alert: Hidden Secrets of the SBMJOB Command

Most people take the OS/400 Submit Job (SBMJOB) command for granted. It's typically used to submit a program for batch processing. But SBMJOB has other powers that you may not be aware of, like helping you to increase the capabilities of batch jobs. This week, let's look at some of the hidden secrets of SBMJOB.

This way OS/400 submits the job for execution based on the configuration of the user running the command. The job runs under the user profile of the submitting user, it uses the job description assigned to the submitting user, it's submitted to the job queue associated with the assigned job description, and it uses the scheduling and output queue priorities assigned to its job description.

This default configuration is utilitarian but somewhat limiting. There are lots of times when you need to change the defaults and modify the operating parameters of a submitted job. For instance, you can submit your job to run under another user profile by modifying the USER parameter of a SMBJOB statement in the following manner:

For this command to work, the submitting user must be authorized to the user profile assigned to the batch job. When submitted this way, the submitted job also uses the job description associated with the new user profile. The job queue, run priority, and output priority values then take their values from the new job description.

You can also submit the job to a job queue other than that associated with the job description. On OS/400 systems where the controlling subsystem is not set to QBASE, you can submit your jobs to any active job queue. If your job is a test job, you might want to submit it to the QPGMR job queue, so that it runs in the QPGMR subsystem. However, if your job is a server job that is almost always running, you can submit it to the QSYSNOMAX job queue in library QSYS by running the command this way:

I like to submit server jobs to the QSYS/QSYSNOMAX job queue because it feeds into the QSYSWRK subsystem, which runs a lot of OS/400's server jobs, including many of its TCP/IP jobs. A second advantage to using QSYSNOMAX is that the QSYSWRK subsystem will accept and run an unlimited number of jobs originating from the QSYSNOMAX job queue (unlike the QBATCH subsystem, which typically runs only a few jobs at once). This means it's a great place to put any additional server jobs that you add to the system.

In addition to changing user profiles and job queues, you can set SBMJOB parameters to change the system library list for the job (the SYSLIBL parameter on the command), the current library for the job (the CURLIB parameter), and the job's initial library list (INLLIBL). But there are a few more fun parameters you can also change.

If you want to log all the CL commands that are executed in your batch job to the job's job log, set the Log CL program (LOGCLPGM) command parameter to *YES, like this:

If you want to submit the job so that it is held on the job queue, use the Hold on job queue (HOLD) parameter:

If you want to use SBMJOB to schedule a job to start at a certain date and time, use the Schedule date (SCDDATE) and Schedule time (SCDTIME) parameters. If I wanted to schedule a test job to run at 10:00 a.m. on November 1, I would submit the job with these parameters:

These jobs are placed on the job queue in a scheduled (Scd) status, and they will not run until the appointed time. If an unscheduled job is submitted to the same job queue, it will run ahead of the scheduled jobs.

Another neat trick is that you can hide submitted jobs from the Work with Submitted Jobs (WRKSBMJOB) command. To do this, set the Allow Display by WRKSBMJOB (DSPSBMJOB) parameter to *NO, and submit your job in the following manner:

If a user tries to view the progress of this job by using the WRKSBMJOB command, he won't be able to see it. Note, however, that users can still see the running job by finding it on the Work with Active Jobs (WRKACTJOB) command display or on the Work with Subsystem Jobs (WRKSBSJOB) command display.

If you don't want operators to answer predefined inquiry messages that appear during batch processing, you can set SBMJOB's Inquiry Message Reply (INQMSGRPY) parameter to tell the job how to answer messages. If you use the default, the job will use the inquiry message control value found in its corresponding job description. However, if you want your batch job to use default reply values for inquiry messages, you can submit the job with its INQMSGRPY value set to *DFT, like this:

And if you have default message replies for inquiry messages defined on your system, your job will attempt to use any default values it finds.

If you want your batch job to automatically reply to messages by using the values stored in OS/400's system reply list, which is maintained through the Work with System Reply List Entries (WRKRPYLE) command, you can change INQMSGRPY to use that list by entering the command this way:

And the final SBMJOB trick is to change the message queue to which SBMJOB sends its job completion messages. You have three choices. By default, job messages are sent to the message queue that is specified in the user profile that the job runs under. If you want to do it manually, you change the Message Queue (MSGQ) parameter of the SBMJOB statement, as follows:

But if you want to change that message queue so that your messages go to the message queue of the workstation the job was submitted from, you set MSGQ to *WRKSTN and your SBMJOB statement would look like this:

And if you want to suppress the completion message altogether, change MSGQ to *NONE and the job won't send out completion messages at all:

The moral of the story is that you shouldn't take familiar commands like SBMJOB for granted. There is always more to learn about an OS/400 function, if you only take the time to look.