Admin Alert: Hidden Parameters of the Submit Job Command

Power i operating system commands are like old friends. You think you know everything about them, then one day they surprise you by displaying a different side of themselves. This week, let’s look at a few hidden parameters available with the i OS Submit Job (SBMJOB) command. These parameters can help you perform some new tricks you may not have thought of.

Non-Obvious Candidates

Everyone knows the standard SBMJOB parameters such as Job Name (JOB), Job Description (JOBD), and Job Queue (JOBQ). But if you search the Additional Parameters section of the Submit Job command (available by pressing F10 from the SBMJOB screen), you can find other parameters that allow you to do unexpected things, add new capabilities, or just make life easier. To that end, here’s a short list of four valuable but overlooked SBMJOB parameters every System i and Power i admin should be familiar with.

Parameter #1: USER – Submit as one user, run as another

SBMJOB’s User (USER) parameter allows you to submit a job from one user profile job and run it under another user profile. To use this feature, simply set SBMJOB’s USER parameter to the value of a user profile that you have authorization rights to. When the program is submitted, it will run under the user profile name listed in the USER parameter, complete with all the rights associated with that user profile.

For example, if I’m running an interactive session under my JOEH user profile, and I want to submit a job that runs under the JIMB user profile, I would simply code my SBMJOB command like this.

SBMJOB CMD(COMMAND)  USER (JIMB)

And if I’m authorized to user profile JIMB, my job will run under that user profile.

The USER parameter is particularly valuable for setting up automated jobs to run under different user profiles inside a job scheduling program, such as Help/Systems‘ Robot/SCHEDULE package or the i OS Job Schedule. The USER parameter is also available when you add entries to IBM‘s Job Scheduling function through the Add Job Schedule Entry (ADDJOBSCDE) command or change existing entries through the Change Job Schedule Entry (CHGJOBSCDE) command.

Parameter #2: PRTTXT – Print a footer in your spooled files

There is also a SBMJOB parameter called Print text (PRTTXT) that allows you to print up to 32 characters at the bottom of each page of spooled file output you produce in a submitted job. Using PRTTXT allows you to add customizable footer text to your job’s spooled files.

To set up a spooled file footer, just enter any acceptable 32-character literal in the PRTTXT parameter of your SBMJOB command, like this.

SBMJOB CMD(COMMAND) PRTTXT('1-32 characters can be entered')

Parameter #3: AGCCDE – Unexpected users for a job’s accounting code

According to IBM, a job’s accounting code is “. . . used by the submitted job when logging the usage of system resources in the system accounting journal QACGJRN.” But I recently discovered that the accounting code (AGCCDE) parameter can be used in two unexpected ways to help with job processing.

First, understand that the AGCCDE parameter can also be used to send a literal of 15 characters or less to a CL program. This literal can contain parameters, message text, or a program variable. You can do this in two steps.

1. Change your SBMJOB statement to submit and receive a 15-character or less literal via the ACGCODE parameter, like this:

SBMJOB CMD(COMMAND) ACGCDE('15-character literal')

2. Inside your CL program, add the following commands:

DCL   VAR(&ACGCDE)  TYPE(*CHAR)  LEN(15)

RTVJOBA   ACGCDE(&ACGCDE)

The Declare CL Variable (DCL) command creates a CL variable &ACGCDE. &ACGCDE will be used to hold the Accounting Code (ACGCDE) parameter that was submitted with the job.

The Retrieve Job Attributes (RTVJOBA) command will retrieve the accounting code parameter associated with the job, and store that value in the &ACGCDE parameter. This variable can be used to control processing anywhere in your program.

Running your jobs this way, you can retrieve the value in your job’s accounting code parameter and use it to pass in short-form information (15-characters or less) for job usage. This technique allows you to pass information in to your program, similar to the way you use other i OS constructs (such as program parameters, data areas, local data areas, job switches, etc.) to do the same thing.

In the right situation, this can come in handy.

The second unexpected way you can use a job’s accounting code is as a parameter in third-party packages. Many third-party package either allow you to enter accounting code information for submitted jobs (such as Help/Systems’ Robot/SCHEDULE), or to retrieve a job’s accounting code information when performing a certain function with that job.

In my shop’s case, our programming director determined that he could set up Robot/SCHEDULE submitted jobs to put in a pre-defined accounting code in each job. Then in the shop’s Bytware MessengerConsole program, which monitors Power i jobs for errors, messages, and other situations, he filters the jobs he wants to monitor by only having MessengerConsole look at jobs with one of the pre-defined accounting codes. By doing this, he has the two packages working together to retrieve information and perform processing based on a submitted job’s accounting code. The lesson here is that you can use a job’s accounting code in a similar fashion for any third-party program that can set or retrieve accounting codes.

Parameter #4: SCDDATE and SCDTIME – Using SBMJOB to schedule when a job will run

The Submit Job command also has two scheduling parameters that allow you to submit a job and then specify the date and time the job will start. It can do this through by using these SBMJOB parameters.

• Scheduled Date (SCDDATE)–Tells the operating system on what date the job is eligible to be run.
• Scheduled Time (SCDTIME)–Tells the operating system what time on the submitted date the job will start running.

The job can be scheduled to run at a certain date by setting SCDDATE to any one of the following parameters:

• The current date (*CURRENT). This is the default value.
• A specific date in the future (type in your own date).
• The first day of the month (*MONTHSTR) or the last day of the month (*MONTHEND).
• A specific day of the week (*MON, *TUE, *WED, *THU, *FRI, *SAT, *SUN).

The job can be scheduled to run at a certain time on the date specified in SCDDATE by setting SCDTIME to one of the following values:

• The current time (*CURRENT)–Using *CURRENT will cause the job to run immediately, provided SCDDATE is equal to the current date. This is the default value.
• A specific time–You can enter a target run time in the hh:mm:ss format.

So if I wanted to submit a job to run at 9:45 a.m. next Tuesday, I could run the following SBMJOB command.

SBMJOB CMD(COMMAND)   SCDDATE(*TUE) SCDTIME(09:45:00)

There are a few caveats to scheduling a run date and time with SBMJOB.

1. The job may not necessarily start exactly at the specified time. Depending on how your job queues are configured, a scheduled job may have to wait for other jobs to finish running before it can start. This may cause it to start running later than its appointed time. The job may also be delayed if, for any reason, the subsystem attached to your target job queue is not running.
2. Scheduled jobs are also subject to system IPLs and restarts. If your system needs to IPL, scheduled jobs may not be available for running after the system restarts.

More SBMJOB parameters

These aren’t the only unusual command parameters you can use with SBMJOB. Submit Job offers many more parameters that can be helpful in running jobs. Take a few minutes and see what else is available with SBMJOB. You may be surprised.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot