Jobs are used for performing out every task on a system. Within the system, every job has a unique number. All jobs run within subsystems, except for system jobs. A job may start from any work entry and enter the subsystem, including job queue, workstation, communications, AutoStart, and prestart entries.

Every active job has a minimum of one thread (the main thread) and could have more secondary threads, as well.

Threads are separate work units. The threads of a job share certain job attributes, but they also have some unique attributes of their own, like a call stack.

Information about the work’s processing is contained in the job’s attributes. When attributes are shared by threads inside the same job, the job serves as the owner. With the use of a job’s attributes, work management gives you the ability to control the work completed on your system.

Proper authority: Most changes to a job’s attributes require either your user profile to match the job user identity being changed or the control of job control special authority (*JOBCTL).

Job characteristics: Work management gives you the ability to manage the work completed on your system by using the attributes of a job. But first, you need to understand the different aspects of a job before you have control over its various aspects.

Job types: Your system processes several different types of jobs. This information describes those jobs and how they are used.

Job Types

Your system processes several different types of jobs. This information describes those jobs and how they are used.

AutoStart jobs

Batch jobs that perform repetitive tasks, one-time initialization tasks related to a specific subsystem, initialize functions for an application, or offer centralized service functions for other jobs in the same subsystem are known as AutoStart jobs. Other subsystems can be started using an AutoStart job in the controlling subsystem (as does the IBM-supplied controlling subsystem). Every time a subsystem is started, the AutoStart jobs associated with it are initiated automatically.

Batch jobs

A batch job is a set of predefined processing operations that are submitted to the system and are intended to be performed with minimal or no user-system interaction. Jobs that can be processed in batches are those that do not need user interaction to complete. A batch job has low priority and may need a specific system environment to run properly.

Communication jobs

A batch job that receives a program start request from a remote system is known as a communications job. Processing a job requires the right specifications and a communication request.

Interactive jobs

A job that begins when a user signs on to a display station and ends when the user logs off is known as an interactive job. The subsystem looks for the job description, which may be found in the user profile or the workstation entry, before allowing the job to run.

Prestart jobs

A batch job that starts running before a work request is received is known as a prestart job. In a subsystem, prestart jobs start before any other type of job. Prestart jobs are different from other jobs because they use prestart job entries (part of the subsystem description) to determine which program, class, and storage pool to use when they are started.

Reader and writer jobs

A spooled output job is a writer’s job, and a spooled input job is a reader’s job.

Server jobs

Server jobs are those that run on your system continuously in the background.

System jobs

The operating system creates system jobs to manage system resources and carry out system operations. When the server boots up or an independent disk pool is turned on, system jobs start to run. These jobs carry out several functions, such as scheduling jobs, initiating and terminating subsystems, and starting the operating system.

Job Execution

The Submit Job (SBMJOB) command can be used in IBM i to submit a job. You can specify the program or command to be run, as well as any input or output parameters, with this command. After being submitted, the job is placed in a job queue and awaits processing. In IBM i environments, SBMJOB offers scheduling flexibility and job execution automation.

Submitting a Batch Job

The command below submits the batch job with the name TESTJOB. The majority of the job’s attributes are derived from the Job description (JOBD) with the name TESTD in the library DEMOLIB; TESTD is used in the output queue (OUTQ) and TESTD is used in the message queue (MSGQ).

The job will be added to the JOBDs job queue, and TESTD is the JOBD associated with the JOBQ.

If JOBD is specified as *USRPRF and User mentioned as something other than *USER, then the attributes of the session for job run like library list, job queue, out queue, etc. are utilized that of the mentioned USER.

One can also select the Message logging level for the batch job in its outqueue spool. The below highlighted attributes of SBMJOB for Message logging allows it.

If one requires to list out all the messages and warnings from job run into the spool file irrespective of job ending normally or abnormally, the following values should be set for message logging:
Level – 4
Severity – 0
Text – *SECLVL

If it is required to list out all the messages and warnings from job run into the spool file only when job ends abnormally, the following values should be set for message logging:
Level – 4
Severity – 0
Text – *NOLIST

All the attributes of the job description are saved in an object of type *JOBD.

Limitation

Once a job has started you cannot change the job description.

How Job picks the Job description?

Every user profile will have a job description (*JOBD) assigned to it. You can view the job description of a user profile using the command DSPUSRPRF. Most users will have default Job description QDFTJOBD.

Batch Job

When a user submits a job, that uses the job description (*JOBD) of the user. You always have the option to change it while submitting the job using SBMJOB command.

Interactive Job

When a user signs on, the system looks at the workstation entry in the subsystem description to determine what job description to use for the interactive job. If the workstation entry specifies *USRPRF for the job description, the job description in the user profile is used.

What all attributes a Job description contains?

You can see all attributes of a job description using command DSPJOBD.

E.g: DSPJOBD JOBD(QGPL/QDFTJOBD)

Attributes:

User profile: It is the name of the user profile associated with this job description.

CL Syntax Check: you can use *NOCHK to specify not to check for syntax as CL commands. Also, you can specify value between 0-99 to specify the lowest message severity that can cause running of a job to end.

Hold on job queue: Specifies whether jobs using this job description are put on the job queue in the hold condition.

End severity: Specifies the message severity level of escape messages that can cause a batch job to end.

Job date: Specifies the date that is assigned to the job that uses this job description when the job is started.

Job switches: Specifies the initial switch settings for a group of eight job switches used for jobs that use this job description. These switches are also called external indicators from U1 through U8.

Inquiry message reply: Specifies the way that inquiry messages are answered for jobs that use this job description.

Job priority: if is a job priority, you can specify a value from 1 to 9 where 1 is highest and 9 is lowest priority.

Job queue: The name and library of the job queue into which jobs using this job description are placed.

Output priority: The output priority for spooled output files that are produced by jobs using this job description. you can specify a value from 1 to 9 where 1 is highest and 9 is lowest priority.

Printer device: The name or reference of the printer device associated with the job description.

Output queue: The name of the output queue that is used as the default output queue for jobs that use this job description.

Message logging: it is a setting for what messages to log from the jobs use this job description.

Log CL program commands: Specifies whether the commands in a control language program are logged to the job log.

Job log output: Specifies how the job log will be produced when the job is completed.

Accounting code: Specifies an accounting code for jobs that use this job description. Account code can be 15 chars in length.

Print text: Specifies the line of text to be printed at the bottom of each page.

Routing data: Specifies the routing data used with this job description to start jobs.

Request data: It is placed as the last entry in the job’s message queue for jobs that use this job description. If you need a batch job to call a specific program every time at the end of its execution, you can specify the call command to that program in Request Data parameter.

DDM conversation: Specifies whether the connections using distributed data management (DDM) protocols remain active when they are not being used. DDMF files are examples that use the DDM protocols.

Device recovery action: Specifies the action to take when an I/O error occurs for the interactive jobs. It is ignored for batch jobs. We can specify actions like to end the job or message to application program etc.

Time slice end pool: Specifies whether interactive jobs should be moved to another main storage pool when they reach time slice end for system better performance.

Job message queue maximum size: Specifies the maximum capacity of the job message queue. It can be in the range of 2 to 64 megabytes.

Job message queue full action: Specifies what action the system takes when the job message queue is full. You can specify options like to end job or print the messages etc.

Allow multiple threads: Specifies whether the job is allowed to run with multiple user threads, but not system threads.

Initial ASP group: Specifies the initial setting for the auxiliary storage pool (ASP) group name for the initial thread of jobs using this job description.

Spooled file action: Specifies whether spooled files are accessed through job interfaces after the job ends. Keeping the spool files with jobs allows job commands such as Work with Submitted Jobs (WRKSBMJOB) to work with the spooled files even after the job has ended. Removing them will clear the memory for better system performance.

Workload group: It is the name of the workload group that is used by jobs that use this job description.

Text: It is the description of the JOBD object user can specify.

Initial Library List: It is a list of libraries that are used when a job starts using this job description. If interactive job, you can edit libraries from the library list. If it is batch job you can change the library list using the CL commands inside the program. So, it is just the initial library list only.

How to work with JOB descriptions?

Use WRKJOBD to work with job descriptions.

E.g.: WRKJOBD JOBD(QGPL/*ALL)

By using the options on this screen, we can create, change, copy, delete and display the job descriptions. Alternatively, we can use the commands below.

CRTJOBD – To create a job description.

CHGJOBD – To change a job description.

DLTJOBD – To delete a job description.

DSPJOBD – To display a job description.

How to assign job description to Jobs?

Interactive Job: For an interactive job, a user has to login. So, we can assign the Job description to a user profile. So, whenever the user logs into the system, that interactive session will use the assigned job description.

We can assign a job description to user profile while creating the user profile using CRTUSRPRF command or changing the user profile use CHGUSRPRF command.

Batch Job:

The SBMJOB command has option to assign the job description.

• The commands in the job
• The commands in CL program, if CL program was created with the LOG(*YES) option or with the LOG(*JOB) option and a change job (CHGJOB) is run with the LOGCLPGM(*YES) option.
• All messages and message help sent to the requester and not removed from the program message queues.

At the end of the job, the job log can be written to the output file QPJOBLOG so that it can be printed. After the job log is written to the output file, the job log is deleted.

Controlling information written in a job log

To control what information the system writes in the job log, specify the LOG parameter on the Create Job Description (CRTJOBD) command. You can change the levels by using the Change Job (CHGJOB) command or the Change Job Description (CHGJOBD) command.

Three values make up the LOG parameter: message level, message severity, and message text level.

The first value, message level, has the following levels:

The second value, message severity, specifies the severity level in conjunction with the log level that causes error messages to be logged in the job log. Values 0 through 99 are allowed.

The third value in the LOG parameter, message text level, specifies the level of message text that is written in the job log. The values are:

*SAME

The current value for the message text level does not change.

*MSG

Only message text is written to the job log (message help is not included).

*SECLVL

The message and the message help (cause and recovery) are written to the job log.

Displaying a job log

The way to display a job log depends on the status of the job.

• The Work with Job Logs (WRKJOBLOG) command can be used to display pending job logs for completed jobs, all job log spooled files, or both. For example, to display the list of pending job logs for all jobs that have ended, enter: WRKJOBLOG JOBLOGSTT(*PENDING)
• If the job is active or in a job queue, or if the job log is pending, use the Display Job Log (DSPJOBLOG) command. For example, to display the job log of the interactive job for user JSMITH at display station WS1, enter: DSPJOBLOG JOB(nnnnnn/JSMITH/WS1), where nnnnnn is the job number.
• If the job has ended and the job log is written to an output file but is not yet printed, use the Display Spooled File (DSPSPLF) command, as follows: DSPSPLF FILE(QPJOBLOG) JOB(001293/FRED/WS3). to display the job logs for job number 001293 associated with user FRED at display station WS3.
• To display the job log of your own interactive job, do one of the following:
  • Enter the command: DSPJOBLOG OR
  • Enter the WRKJOB command and select option 10 (Display job log) from the Work with Job display.
  • Press F10=Include detailed messages from the Command Entry display (this key displays the messages that are shown in the job log).
  • Use the cursor movement keys to get to the end of the job log. To get to the end of the job log quickly, press F18 (Bottom). After pressing F18, you might need to roll down to see the command that is running.
  • Use the cursor movement keys to get to the top of the job log. To get to the top of the job log quickly, press F17 (Top).

  
  
  

• To display the job log in command WRKACTJOB:
  • Use the WRKACTJOB command.
  • Take option 5 against the job.
  • Type option 10 to see the job log.
  • Press F10=Include detailed messages from the Command Entry display (this key displays the messages that are shown in the job log).
  • Use the cursor movement keys to get to the end of the job log. To get to the end of the job log quickly, press F18 (Bottom). After pressing F18, you might need to roll down to see the command that is running.
  • Use the cursor movement keys to get to the top of the job log. To get to the top of the job log quickly, press F17 (Top).

  
  
  
  
  

Preventing the production of job logs

• To prevent a job log from being produced at the completion of a batch job, you can specify *NOLIST for the message text-level value of the LOG parameter on the Batch Job (BCHJOB), Submit Job (SBMJOB), Change Job (CHGJOB), Create Job Description (CRTJOBD), or Change Job Description (CHGJOBD) command.
• If you specify *NOLIST for the message level value of the LOG parameter, the job log is not produced at the end of a job unless the job end code is 20 or greater. If the job end is 20 or greater, the job log is produced.
• For an interactive job, the value specified for the LOG parameter on the SIGNOFF command takes precedence over the LOG parameter value specified for the job.
• To prevent a job log from being produced when the job is completed, but remain in the system in a pending state, specify *PND for the LOGOUTPUT parameter on the Submit Job (SBMJOB), Change Job (CHGJOB), Create Job Description (CRTJOBD), or Change Job Description (CHGJOBD) command. If you specify *NOLIST for the LOG parameter, no job log will be produced, and there will be no pending job log either. Pending job logs will only be available when a job log would normally be written to an output file or database file when the job ends and the job log output job attribute is *PND. You can use the Work with Job Logs (WRKJOBLOG) command to find both pending and written job logs.

Job log from programming perspective

• Write to job log, we can send messages from inside a running RPG program. We can do it by using one of IBM’s APIs – Qp0zLprintf

  The procedure prototype is as below.

  

  Example

  

• Using SQL to get information from Job Logs.

  We can get job log information with SQL Select query from table JOBLOG_INFO. It returns one row for each job log message.

  SELECT *
  FROM TABLE(QSYS2.JOBLOG_INFO('*')) A;
  

  The parameter ‘*’ says to retrieve the information from the current job. If we wanted to look at a different job we would change the parameter to the fully qualified jobname such as:

  SELECT *
  FROM TABLE(QSYS2.JOBLOG_INFO('878597/QUSER/QZDASOINIT')) A;
  

  If we wanted to see the job log in reverse order, we can do this with:

  SELECT *
  FROM TABLE(QSYS2.JOBLOG_INFO('*')) A
  ORDER by ordinal_position desc;
  

  to retrieve only the last message in the joblog.

  SELECT message_id, message_text, message_second_level_text
  FROM TABLE(QSYS2.JOBLOG_INFO('*')) A
  ORDER by ordinal_position desc
  fetch first row only;
  
  

IBM i has two types of logs for messages. They are:

1. Job log – Log generated for any job on the system, whether it could be interactive or submitted batch job, is called a job log.
2. History log/System log – Whenever a system activity is successful or abended with some error, a message will be generated by the system. All such messages can be viewed at History log (System Log). Message can be associated with a job/system/device status or a system operator message.

How to view the System log?

• DSPLOG command can be used to see the system log.

Note: Since the result is read only, it is safe to run this command in ALL environments.

Command:

Result:

To see the additional information, take F1 on corresponding message.

Parameters:

On typing the command and taking prompt (F4), corresponding parameters can be seen.

Log: The only option available for this parameter is QHST, which means system history log.

Time Period:  This parameter can be used to view the system log for a certain period. Beginning Time/Date and Ending Time/Date can be input for corresponding time frame.

Time should be specified in 24-hour format and date should be specified in the date format the current job uses.

For example, the input below gives the system log between 1 PM and 3 PM for the current date.

Output: This parameter has four options.

*                       –    Result will be shown on the display.

*PRINT            –    Spool file will be generated for the output. Only the first 105 characters of first

                               level message text will be printed for each message.

*PRTWRAP     –    Spool file will be generated for the output. Up to 2000 characters of first

                               level message text will be printed for each message.

*PRTSECLVL    –    Spool file will be generated for the output. Up to 2000 characters of first

level message text and 6000 characters of second level message text will be                    printed for each message.

Additional Parameters: After taking prompt(F4) on the command, press F10 for additional parameters and move the page down to input the additional parameters.

Job: This parameter can be used to see the system log associated to specific job or specific user.

For example, the below input gives the system log associated to the user SUPERUSER.

Message Identifier: This parameter can be used in two ways.

*ALL – All messages irrespective of message identifiers, will be included in the output.

 Specific/Generic – If looking for specific message then corresponding message identifier can be input. If looking for certain message types, then generic format can be input.

For example, to see the job started messages CPF1124 can be input.

Message Identifier Selection: This parameter is associated with Message Identifier and can be used in two ways.

*INCLUDE – All the messages as per the Message Identifier input, will be included in the output.

*OMIT – All the messages as per the Message Identifier input, will be excluded in the output.

For example, to exclude the job started messages input CPF1124 in Message Identifier and *OMIT in the selection.

Benefits of System log:

• To know the start/end time of a job from the past.

Let us assume that a job is scheduled in production to run on daily basis; and start/end time is needed to present in the daily dashboard. In some cases, timelines are needed from the past. So, DSPLOG command can be used with Job name, date, message identifiers as CPF1124/CPF1164 and selection as *INCLUDE to know the timelines.

• To analyze the production issue.

Let us assume that an issue is reported in production, which could be a run-time exception. If you know the exact job which caused the issue, then you can check the job log and find the root cause. If no job details are available, then DSPLOG command can be executed with the suspected time frame and check for exception message. Take F1 on message and then F9 to know the exact job/program & analyze the issue.

Hence, System Log provides useful information and can be used in many scenarios whenever needed.

Scheduling a job using schedule entry related commands

A job can be scheduled and viewed/modified on job schedule using the below commands:

(a) ADDJOBSCDE (Add Job Schedule Entry)

This command is used to schedule a batch job by adding an entry to the job schedule.
Below are the important parameters that need to be considered while adding a job to the schedule:

1. JOB: It is the name of the job which appears on the schedule list once added and it will also be the name of the job which will be submitted.
2. CMD: It is the command that will run when the job is submitted on the specified schedule, generally it’s the call command for a program.
3. FRQ: It is the frequency of the job submission. Below are the possible values for this parameter and when to use these values:
   • *ONCE: If a job needs to be submitted only one time.
   • *WEEKLY: If a job needs to be submitted daily OR on a few selected days of the week.
   • *MONTHLY: If a job needs to be submitted on a few selected dates of the month (like the first date of every month).
   • *YEARLY: If a job needs to be submitted only once a year.
4. SCDDAY/SCDDATE: These are the parameters for scheduled days & scheduled dates for the job.For jobs that are supposed to be executed daily or on specific days of every week, the SCDDATE parameter is supplied as *NONE, and the SCDDAY parameter is supplied with the name of the days.For jobs that are supposed to be submitted once, monthly, OR yearly; the SCDDAY parameter is supplied as *NONE, and the SCDDATE parameter is updated as a specific date, *MONTHSTR or *MONTHEND.
5. SCDTIME: It is the time of the day at which the job is supposed to be executed.
6. JOBD:The job description parameter specifies the JOBD using which the job will be executed. The JOBD contains the list of libraries which will be used by the job to perform the required actions given in program.
7. JOBQ: This is the JOBQ in which the job will be submitted, generally for batch jobs it is kept as QBATCH.
8. USER: It specifies the name of the user using whose authorities the scheduled job will be executed. Possible values are:
   • *CURRENT – The job is submitted under the user profile of the user who is adding the job schedule entry.
   • *JOBD – The job will be submitted using the user profile of the JOBD.
   • A specific name of the user profile can also be provided.

Below are some examples of adding a new job schedule entry for different scenarios:

• Scheduling a one-time job
  

  

  The above command translates to “The job TODAYRPT will be submitted on 25th March 2024 at 10:30 PM on JOBQ ‘QBATCH’ using profile AZARU to call the program GENDAILYRP from library PGMLIB”.

• Scheduling a job to execute a program on daily basis:
  

  

  The above command translates to “The job DAILYRPT will be submitted on ALL days of every week (i.e. daily) at 10:30 AM in the morning on JOBQ ‘QBATCH’ using profile AZARU to call the program GENDAILYRP from library PGMLIB”.

(b) WRKJOBSCDE (Work with Job Schedule Entries)

This command allows the user to work with the existing scheduled entries of the jobs to change, remove, display, hold, release, check the last submission details of the job OR submit the job immediately if needed.Below are some sample executions of this command:

• Change the scheduled job.
  

  

  Provide the name of the job (if want to work only with specific job) and press enter.

  

  Option 2 can be taken to change the job (i.e. change any parameter which was used to add the scheduled entry of the job). Let’s assume that we want to change the scheduled time of “DAILYRPT” job from 10:30 am to 11:00 am. On taking option 2 below screen appears:

  

  We can change the time as below and press enter to update the scheduled entry of the job.

  
  

  
  *It can be observed that when option 2 is taken on the scheduled entry, the command CHGJOBSCDE is executed. This command can directly be used to change the parameter of scheduled entry from command line.
  

• Hold/Release the scheduled job.In case it is needed to hold the job from getting submitted for the next execution (or release the scheduled entry of the job if it was held before), option 3 can be taken (option 6 can be taken to release the scheduled entry).
  

  

  As we can see above the job is currently in SCD (Scheduled) status and it will be submitted at 11:00 AM, to stop it from getting submitted at 11:00 AM, option 3 can be taken as below:

  
  

  Job status gets changed to “HLD” (Held) as shown above.

  To release this job (or bringing it back to SCD status) option 6 can be taken as below:

  
  

  First the job status is changed from “HLD” to “RLS” (released), on pressing F5 status gets updated correctly to SCD

  

  *Scheduled entries can be held/released by commands HLDJOBSCDE/RLSJOBSCDE as well

• Work with last submission.To work with the most recent submission of the job by scheduled entry, option 8 can be taken.
  

  
  

• Submit immediately.If we want to submit the scheduled entry immediately, we can take option 10.
  

  
  

  *We can observe, by submitting the job immediately didn’t change any this on “next submit date” column. So, submitting the job using option 10 does not impact the scheduled entry of the job. It can also be achieved using SBMJOB command.

• Remove job schedule job.If we want to remove the scheduled entry, we can take option 4 to do the same:
  

  
  

  System asks for the confirmation, press enter again.

  

  Scheduled entry gets removed.

  *A scheduled entry can also be removed using command RMVJOBSCDE.

(c) How to know the scheduled job entry number of all scheduled entries

There are commands like CHGJOBSCDE, HLDJOBSCDE, RLSJOBSCDE, RMVJOBSCDE which require you to supply job entry number along with the scheduled job name (in case there are multiple scheduled entries available with the same name).The job entry number is automatically assigned by system when we add a new scheduled entry in system using ADDJOBSCDE (or by pressing F6 from WRKJOBSCDE command).

To see all the scheduled job details in system (along with scheduled job entry number), we can either print all scheduled entries details using WRKJOBSCDE command OR alternatively we can also use the view “SCHEDULED_JOB_INFO” (Short name SCHED_JOB) which is available in QSYS2 library.

It can be accessed using SQL session and data filtering criteria can also be applied.

Scheduling a job using submit job command.

In case it is required to run a job not immediately but at a particular date/day and time (once only), it can also be achieved using SMBJOB command.

We can supply the parameters “SCDDATE” and “SCDTIME” for this purpose.

SCDDATE can either be a specific date OR a name of day (*MON/*TUE etc.) or month start/month end (*MONTHSTR/*MONTHEND) as well. If needed to submit the job on the same day but at some other time, we can consider not to provide SCDDATE parameter (keep it as *CURRENT) and provide only SCDTIME parameter.

SCDTIME parameter is used to provide the time at which the job will be submitted.

Below is a sample to schedule a job using SMBJOB command:

• Sample one time execution scheduling using SBMJOB command.
  

  

  The above command will schedule the job to run at 11:00 AM on 26th Apr 2024.

  

  The scheduled entries will reside in JOBQ with status SCD till the time to submit is reached. We can see these entries using WRKJOBQ command.

  On entering command WRKJOBQ JOBQ(QBATCH), below entry appears:

  

  *If needed we can change, hold, end, or release the job from the JOBQ. The corresponding commands are CHGJOB, HLDJOB, ENDJOB, RLSJOB to do the same activities.

Scheduling a job using the Advance job scheduler

IBM has also provided an advanced job scheduler package which comes with more flexibilities and options for user which scheduling the jobs (like having holiday calendar, group jobs to run one after other, multiple submissions of a job at different times on same day etc.).

The scheduler can be accessed using the menu command “GO JS” and different options can be used to add/update/remove a job in advance job scheduler. Moreover, different calendars can also be maintained.

IBM has provided a red book for its manual which can be accessed below, you can go through this red book to understand different options of advance job scheduler.

The group of eight logical values that can be used to pass information to a submitted job or to exchange information between programs running in the same job are known as Job Switches in IBMi. Logical values indicate only 0’s (false) and 1’s (true) to be specified in the 8-digit character string, but not other character values.

These switches can be set or tested in a CL program and used to control the flow of the program.

How we can pass information to a submitted job via Job Switches?

The Job Switches can be used as an appropriate way to pass information to a submitted job. When a job enters the system, the initial job switches value can be set via the following ways:

1. Using the Job Switches Parameter (SWS) of a Submit Job Command
2. Job Switch attribute of the JOBD object used to start the job.

Specifying the initial value of the Job Switches of a submitted job via SWS Parameter in a SBMJOB CMD as below:

SBMJOB CMD (CL-Command-To-Run)

       SWS (01010010) /* This 8-Byte Character Value ‘01010010’ is the example */

                    /* for the Job Switches value to pass to the submitted job */

Specifying the initial value of the Job Switches by setting up the JOBD parameter to JOBD object as below:

/* By assuming each job switch indicates whether a specific task among */

/* all the eight tasks need to be done by the submitted job */

CRTJOBD JOBD (DONOTHING)

        SWS (00000000)  

CRTJOBD JOBD (EVERYTHING)

        SWS (11111111)  

SBMJOB CMD (CL-Command-To-Run)

       JOBD (DONOTHING) /* The Submitted Job here need not do anything */

SBMJOB CMD (CL-Command-To-Run)

       JOBD (EVERYTHING) /* The Submitted Job here needs to do everything */

Accessing the Job Switches

By using CL Commands and Built-in-Function, we can access the Job Switches.

With the help of below DSPJOB command, we can check the Job Switch settings of the current interactive job.

DSPJOB OPTION(*DFNA)

The CL Switch Built-in Function (%SWITCH) tests one or more of the eight switches of the current job under an 8-character mask and returns a logical value of ‘0’ or ‘1’. 

Syntax of %SWITCH BIF:

%SWITCH(8-Character-Mask)

Only 0, 1 or X can be specified as the valid characters in every position of the mask.

Following are the list of indications of the above valid characters for %SWITCH BIF.

• ‘0’ – The corresponding job switch is to be tested for a 0 (off).
• ‘1’ – The corresponding job switch is to be tested for a 1 (on).
• ‘X’ – The corresponding job switch is not to be tested (X). The value in the switch does not affect the result of %SWITCH.

Simple Job Switch Example in CL

IF COND(%SWITCH(0XX1XXXX) THEN (GOTO HOME)

From the above example, we can understand that if the Job Switch# 1 contains ‘0’, and Job Switch# 4 contains ‘1’, then the program will branch to label HOME. The remaining Job Switches 2, 3, 5, 6, 7, and 8 will not be tested.

Other CL Commands used to get or set the Job Switches 

With the help of RTVJOBA and CHGJOB command, we can get or set one or more Job Switches of the current job or another job, respectively.

CHGJOB SWS(XXX1XXXX)

The above CL command changes the value of the fourth Job Switch value of the current job to ‘1’.

Accessing the Job Switches via RPG PGM

OPM RPG & ILE RPG supports Job Switches via external indicators (U1 through U8). At the beginning of the RPG Program cycle, the current Job Switches settings are copied to indicators U1-U8 and at the end of the program cycle, the indicator values of U1-U8 are copied back to the Job Switches.

Also, noting that the returning from an RPG Program with the LR indicator set off will not get the Job Switches settings of the updated current job.

RPG PGM Example on how Job Switches settings are updated via external indicators:

D SET_OFF         S               N   INZ(*OFF)  

D SET_ON          S               N   INZ(*ON)

 /Free

       *INU1 = SET_OFF;

       *INU2 = SET_ON;

       *INLR = *ON;

 /End-Free

Note:

Although, the RPG compiler will stop assigning constant values other than ‘0’ or ‘1’ (*ON or *OFF) to an indicator variable, it is still possible to change the contents of external indicators with non-logical values. Since, assigning a character variable to an indicator variable is allowed in RPG.

Hence, to modify a Job Switch value in an ILE RPG PGM via a stand-alone variable, use an Indicator Type (N) character variable instead of a type A character variable to avoid the non-logical values assigning issue.

A job which does not require user interaction to run is known as a Batch job. In simple terms, batch job is a scheduled program which runs without or minimum user interaction, once batch job is submitted it waits for its turn in job queue, on its turn job starts automatically in the background even if user signs-off.
IBM i system provides facility to schedule batch jobs.

• Schedule daily, weekly, monthly, start or end of the month and so on.
  Example-A batch job is scheduled to run 10.00 PM daily to take back up of important application files.

Submitting a batch job:

• In this example, a job named DELETESPL is submitted in QBATCH job queue. The job runs the command DLTSPLF.
  

  SBMJOB CMD(DLTSPLF FILE(*SELECT)) JOB(DELETESPL) JOBQ(QBATCH)

• In this example, Job named DAILYBKUP is submitted in QBATCH job queue.
  The job runs the program named BKUPFILES.

  SBMJOB CMD(CALL PGM(*LIBL/BKUPFILES)) JOB(DAILYBKUP) JOBQ(QBATCH)

Debugging a batch job:

• HOLD the Job: – Debug command should be executed before job starts. Hence, the job we want to debug should be on hold or yet to start. To achieve this-
  • Use the submit job (SBMJOB) command with parameter HOLD(*YES) to prevent job from executing immediately.
    

    SBMJOB CMD(CALL PGM(*LIBL/BKUPFILES)) JOB(DAILYBKUP) JOBQ(QBATCH) HOLD(*YES)

    
    The job will be submitted with status "HELD".
    

    

  • In real time applications, usually the jobs are submitted from programs with HOLD(*NO). In such cases, when SBMJOB is coded within a program, we can hold the job queue to which the job is being submitted using Hold Job Queue (HLDJOBQ) command. Once job is submitted, we can then hold the specific job with HLDJOB command or option 3 = Hold on WRKUSRJOB screen and release the job queue with Release Job Queue (RLSJOBQ) command.
    NOTE: Job queue must be released ASAP, since holding it for long time will impact execution of other jobs submitted to same job queue.
  • Schedule date/time can be specified in SBMJOB command using parameters SCDDATE and SCDTIME.
• Find the job attributes: Note down the attributes of the submitted job. This can be done using following method-
  • Run command WRKUSRJOB STATUS(*JOBQ) and Enter option 5.
    

    

    
    Note down the values Job, User, Number displayed at the top of the next screen "Work with Job".
    

    

• Start service job: The service job will allow to interactively debug the batch job.
  Enter command STRSRVJOB with the job attributes noted in last step.
  

  STRSRVJOB JOB(667098/HIMANSHUGA/DAILYBKUP)

  
  

  

• Start debug:
  • Enter STRDBG command and enter the program name(s) you want to debug.
    

    STRDBG PGM(BKUPFILES) UPDPROD(*YES)

    
    

    

    
    Module source is displayed on debug screen.
    

    

  • At this point, debug commands cannot be used. Since job is not active, press F12 to return to command line and release the held job using RLSJOB command or using option 6 = Release on WRKUSRJOB screen.
    

    

    
    Below screen is displayed then..
    

    

  • Press F10=Command entry on above screen takes to "Command Entry" screen and type Display Module Source (DSPMODSRC) command and press ENTER; Module source is displayed again on debug screen. Break points can be added at this point.
    

    

    
    ADD break points.
    

    

  • Now press F3 or F12 to return to the "Command Entry" screen and press F12 again to return to the "Start Serviced Job" screen.
    

    

    
    Press ENTER to start the job and continue with debugging.
    

    

• End debug and End service job:
  Once debug completes enter the ENDDBG command to end the debug and ENDSRVJOB command to end the service operations of the job that was being serviced.