Hidden Secrets of SBMJOB Command:

Most people use the OS/400 Submit Job (SBMJOB) command for batch processing. But SBMJOB has other powers that help to increase the capabilities of batch jobs.

SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB)
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.
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:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TEST) USER(NEWUSER)
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.
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TEST)
JOBQ(QSYS/QSYSNOMAX) USER(NEWUSER)

Server jobs can be submitted 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).

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:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) LOGCLPGM(*YES)
If you want to submit the job so that it is held on the job queue, use the Hold on job queue (HOLD) parameter:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) HOLD(*YES)
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.
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB)
SCDDATE('11/01/03') SCDTIME('10:00:00')
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:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) DSPSBMJOB(*NO)
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:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) INQMSGRPY(*DFT)

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:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) MSGQ(*USRPRF)
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:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) MSGQ(*WRKSTN)
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:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) MSGQ(*NONE)