PMS Information Systems
Welcome to PMS Information Systems - IBM i (AS/400) Forum !!!

Get Answers for all your queries on IBM i (AS/400).

SBMJOB Hidden params

View previous topic View next topic Go down

SBMJOB Hidden params

Post  maran on Fri Dec 30, 2011 12:38 pm

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 MARAN user profile, and I want to submit a job that runs under the PREETHI user profile, I would simply code my SBMJOB command like this.

SBMJOB CMD(COMMAND) USER (PREETHI)

And if I'm authorized to user profile PREETHI, 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 an unexpected way 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.


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.

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.
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.

maran
Admin

Posts : 442
Join date : 2009-07-24

View user profile http://pmsinformationsystem.forumotion.net

Back to top Go down

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum