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