SysAdmin

Object

An object is a named area within the system that can be accessed or modified by users or applications. All items you interact with on the system—such as files, programs, commands, queues, libraries, and folders—are considered objects.
Objects offer a uniform way to manage and operate system components and are identified by their name, type, and the library they belong to. Each object can be individually secured to control access.

Library

A library is a specialized type of object designed to organize other objects into groups. Most system objects are stored in libraries, which act like containers or folders for organizational purposes. Libraries may be linked to specific user profiles or applications.
The QSYS library is unique because it can contain other libraries. Libraries function similarly to subdirectories but cannot reside within directories themselves.

Directory

Directories are special objects used to group objects into a hierarchical structure within the file system. Unlike libraries, directories can be nested inside one another, creating complex hierarchies. Each file system forms a major subtree in this directory structure.
Directories differ from libraries since their paths, not the directories themselves, have names, allowing multiple names for a single directory. Directory names can be longer and case-sensitive, whereas library names are limited to 10 characters and map to the QSYS library. Different commands and authority levels apply to directories versus libraries.

User Profile

Every system user must have a user profile, which is a special object representing their identity on the system. User profiles are necessary to sign on and use the system, and only administrators with the right authority can create or modify these profiles.

Group Profile

A group profile is a type of user profile that grants the same permissions to multiple users simultaneously. It allows you to manage access by defining authorities for the entire group instead of assigning permissions to each user individually.
Group profiles can own objects on the system and are often used for users who require access to the same applications and resources.

Special Authority

Special authority defines whether a user has permission to perform critical system tasks, such as creating user profiles or managing other users’ jobs. It controls access to higher-level system functions.

Physical Security

Physical security involves protecting the hardware components of the system, including the main unit, devices, and backup media, from accidental damage or intentional harm. These protective measures are mostly external to the system’s software.

Application Security

Application security focuses on safeguarding the applications installed on the system. It balances protecting these applications while permitting authorized users to access and use them.

Resource Security

Resource security controls who can use objects and what actions they can perform on them. This control is known as authority. Setting object authority carefully ensures users have enough permissions to perform their jobs without unnecessary access to system changes.
Authorities can be specific, such as adding or modifying records, or broader through system-defined access levels like *ALL, *CHANGE, *USE, and *EXCLUDE. System values and user profiles regulate access and prevent unauthorized logins. Resource security ensures confidentiality, integrity, and availability of information by controlling user actions on system objects after login.

Security Policy

A security policy encompasses the rules and guidelines for managing security on the IBM i system. It provides a framework for implementing and maintaining security controls.

Creating a job description

Job descriptions can be created using the character-based interface, the Work with Job Description (WRKJOBD) command, or the Create Job Description (CRTJOBD) command.

Command:

CRTJOBD

Example 1: Interactive Job

This creates a job description named PAYOUT in the current library for interactive jobs in Department HR. Users must enter a password upon sign-on, routing data QCMDI matches the subsystem’s routing table, and inquiry messages follow the system reply list for automatic responses.

CRTJOBD   JOBD(PAYOUT) USER(*RQD) RTGDTA(QCMDI) INQSGRPY(*SYSRPYL)
          TEXT ('Interactive JOBD for Department HR')

Example 2: Batch Job

This creates PRIORITY30 named JOBD in the current library, directing jobs to the NIGHTJOBQ job queue with priority 5 for both jobs and output. Routing data QCMDB aligns with the subsystem routing table, and accounting code BATCHJOB tracks statistics for these jobs.

CRTJOBD   JOBD(PRIORITY30) USER(*RQD)  JOBQ(NIGHTJOBQ) JOBPTY(5)
          OUTPTY(5) ACGCDE(BATCHJOB) RTGDTA(QCMDB)
          TEXT('Batch JOBD for priority night work')

Changing a job description

You can use the character-based interface, the Work with Job Description (WRKJOBD) command, or the Change Job Description (CHGJOBD) command to change job descriptions.

Command:

CHGJOBD

All jobs that are started after the job description is changed that use that job description are affected. If you have changed a job parameter to something different than what is specified in the job description, that parameter is not affected.

Using a Job Description

The primary method for using a job description involves specifying it in the Submit Job (SBMJOB) command via the JOBD parameter to assign it to the job.

Batch Job Options

• Use the job description as-is without changes: SBMJOB JOB(DAILYEND) JOBD(QBATCH).
• Override specific attributes, such as message logging: SBMJOB JOB(DAILYEND) JOBD(QBATCH) LOG(2 20 *SECLVL).

Supporting Commands

• Batch Job (BCHJOB): Starts a batch job stream, allowing attribute overrides while defaulting to job description or user profile values for unspecified parameters.
• Add Prestart Job Entry (ADDPJE): Adds an entry to a subsystem description for prestart jobs triggered by subsystem start or STRPJ command.
• Add AutoStart Job Entry (ADDAJE): Adds an entry to a subsystem description to automatically launch a specified job name and description.
• Add Workstation Entry (ADDWSE): Adds a workstation entry to a subsystem description, enabling sign-on and job execution for identified workstations.

Deleting a Job Description

Job descriptions can be removed from the system through several straightforward methods, including the character-based interface for direct navigation and manipulation, the versatile Work with Job Description (WRKJOBD) command that provides an interactive menu for managing existing descriptions, or the dedicated Delete Job Description (DLTJOBD) command designed specifically for permanent removal of these objects.

Primary Command

The core command for this operation is Delete Job Description (DLTJOBD), which targets and eliminates the specified job description from its library, ensuring it no longer exists for use in job submissions or subsystem configurations.

Creating a Job Queue in IBM i

To establish a new job queue on IBM i systems, you can utilize the character-based interface which provides a direct and interactive way to execute system commands.
The specific command used for this purpose is the Create Job Queue (CRTJOBQ) command, which allows you to define a job queue within a designated library.

Command Syntax and Usage

The essential format of the command requires specifying the name of the job queue using the library/job queue notation. This identifies both the library where the job queue will reside, and the name assigned to the job queue itself. Additionally, you may include optional parameters, such as a descriptive text to clarify the purpose or use of the job queue to other users or administrators.

Example

For example, the command below creates a job queue named MYJOBQ in the ROLLCALL library and includes a brief description labelling it as a “test job queue”:

CRTJOBQ JOBQ(ROLLCALL/MYJOBQ) TEXT(‘Morning Jobs Only’)

This command sets up the job queue to be ready for job submissions as per the configuration defined.

This creates a job queue named MYJOBQ in library ROLLCALL.

Key Parameters

• JOBQ: Required; qualified name of the job queue (e.g., LIBA/JOBQA or *CURLIB/JOBQA). Job queues must reside in permanent libraries, not QTEMP.
• TEXT: Optional; up to 50 characters for description.
• AUT: Optional; default public authority, e.g., *EXCLUDE for restricted access.

Post-Creation Steps

Once a job queue is created, it needs to be assigned to a subsystem to enable job processing. This is done using the Add Job Queue Entry (ADDJOBQE) command in the character-based interface, which links the job queue to the subsystem description.

How to Assign a Job Queue to a Subsystem Using ADDJOBQE

The ADDJOBQE command requires specifying key parameters:

• SBSD: The name of the subsystem description to which the job queue is added.
• JOBQ: The fully qualified name of the job queue (for example, LIBA/JOBQA).
• MAXACT: Defines the maximum number of active jobs allowed concurrently from the job queue. Using *NOMAX means no limit.
• SEQNBR: Sets the sequence order in which the subsystem processes jobs from this queue; lower numbers have higher precedence.
• MAXPTYn: Optional parameters to limit the number of active jobs by priority levels (ranging from 1 to 9).

Example:

For instance, this command adds the MYJOBQ job queue in the ROLLCALL library to the PRIORITY1 subsystem, allowing unlimited active jobs and setting its processing order with a sequence number of 5:

ADDJOBQE SBSD(PRIORITY1) JOBQ(ROLLCALL/ MYJOBQ) MAXACT(*NOMAX) SEQNBR(5)

The subsystem manages job queues by selecting jobs starting with the lowest sequence number. It schedules jobs based on priority and the active job limits defined. This assignment process enables the subsystem to effectively process all jobs submitted to the specific job queue.

Clearing a Job Queue

Clearing a job queue result in the permanent deletion of all jobs present on that queue, including those that are currently held or in a paused state. This operation can be performed using either IBM Navigator for i for a graphical approach or the character-based interface for command-line execution.
Importantly, any jobs that are actively running remain untouched, as they are classified as active and have already been removed from the queue itself.

Command

CLRJOBQ

Example

The following command eliminates all jobs from the IBM-supplied QBATCH job queue or a custom one like ROLLCALL/MYJOBQ, while sparing any job that is in the process of being read or executed:

CLRJOBQ JOBQ(ROLLCALL/MYJOBQ)

Holding a Job Queue

Placing a job queue on hold stops the processing of all jobs currently waiting in that queue, effectively pausing new job starts from it. This action does not impact any jobs that are already running or actively executing at the time. While the queue remains held, additional jobs can still be submitted to it, but they will remain queued and unprocessed until the hold is released.

Command

HLDJOBQ

Example

This command places the job queue QGPL/QBATCH or a custom one like ROLLCALL/ MYJOBQ on hold, suspending all non-running jobs until the queue is later released or cleared:

HLDJOBQ   JOBQ(ROLLCALL/MYJOBQ)

Release of a job queue

Releasing a job queue from its held state allows all the jobs that were previously paused specifically because the queue itself was placed on hold to resume processing and continue execution as normal. However, this release action does not affect any individual jobs that were manually placed on hold prior to the queue being held, as those remain paused independently until explicitly released through separate commands. This distinction ensures precise control over job management without unintended activations.

Command

RLSJOBQ

Example

The following command lifts the hold on the job queue QGPL/QBATCH or a custom one such as ROLLCALL/MYJOBQ, thereby freeing up all queue-held jobs for processing:

RLSJOBQ   JOBQ(ROLLCALL/MYJOBQ)

Moving a job to a different job queue

There are numerous practical reasons for transferring a job from one job queue to another on IBM i systems, allowing for more efficient workload management and resource allocation. For instance, a queue might experience significant backlogs due to a single long-running job that occupies processing time for an extended period, causing delays for other waiting tasks. Additionally, scheduling conflicts can arise when a newly submitted job with higher priority needs immediate attention, displacing lower-priority jobs that were queued earlier.
In such scenarios, relocating the affected waiting jobs to an alternative job queue that has lighter traffic, and available capacity provides an effective solution to balance the system load and prevent bottlenecks.

Command

CHGJOB

Example

This command relocates the specific job named PAYOUT to the MYJOBQ job queue located in the ROLLCALL library, enabling it to process in a potentially less congested environment:

CHGJOB JOB(PAYOUT) JOBQ(ROLLCALL/MYJOBQ)

Deletion of job queue

Job queues can be permanently removed using the character-based interface on IBM i systems, providing a reliable method for system cleanup and resource management once certain prerequisites are met.

Restrictions

• The target job queue must be completely empty, meaning all jobs have either finished processing, been explicitly deleted, or transferred to another queue.
• No active subsystems can be associated with or actively using the job queue during the deletion process.

Recommended Method

The preferred approach is the Work with Job Queue (WRKJOBQ) command, which displays essential details like the current job count and overall status for informed decision-making.
If the job count shows 0, select option 4=Delete directly from the interactive display to remove the job queue from its library safely.

Alternative Method

For automated scripting or bulk cleanup tasks, use the Delete Job Queue (DLTJOBQ) command, but exercise caution as it defaults to searching the library list and deleting the first matching job queue name encountered.
To avoid accidentally removing the wrong queue when duplicates exist across libraries, always specify the exact qualified library name.

Example

DLTJOBQ JOBQ(ROLLCALL/TEST1)

Creating an output queue

The Create Output Queue (CRTOUTQ) command is used to set up a new output queue specifically for spooled files. Each spooled file receives an entry on this queue. The sequence in which spooled files are sent to the output device is determined by their output priority and the SEQ parameter setting, which indicates the order files are processed on the queue. You can create an output queue using the character-based interface

For example, the command below creates an output queue named NIGHTJOB in the current library. With AUT(*EXCLUDE) set and OPRCTL(*YES) assumed, only the creator and users with job or spool control authority can use or manage this queue. SEQ(*FIFO) ensures that spooled files are processed in the order they are added (first-in, first-out). If users in a particular department need access, they must be granted authority using the GRTOBJAUT command. Only owners or authorized users can display data from files on this queue. By default, no job separator page is printed at the start of each job’s output.

CRTOUTQ OUTQ(NIGHTJOB) AUT(*EXCLUDE) SEQ(*FIFO) TEXT(‘Printer for Night Jobs')

Another example creates an output queue named NEWTON in the QGPL library with descriptive text:

CRTOUTQ OUTQ(QGPL/NEWTON) TEXT ('Output queue for Newton’)

This command establishes the queue with the specified ownership and control features to appropriately manage spooled file output and user access.

Assigning the output queue to a job or job description

You can modify a job description to specify a different output queue so that all jobs using that description will send their spooled files to the new queue. This change is done through the character-based interface. For example, the Change Job Description (CHGJOBD) command can be used to update the job description DAYEND to direct output to the QPRINT queue:

CHGJOBD JOBD(DAYEND/DAYEND) OUTQ(*LIBL/NIGHTJOB)

This command reassigns the output queue for all jobs that use the DAYEND job description, ensuring consistent output handling.

Accessing printer output

Command: Work with Output Queue (WRKOUTQ <output queue name>)

Command: Work with Spooled Files (WRKSPLF JOB (<qualified job name>))

Clearing output queues

When a job produces printer output, it is sent to an output queue for printing. Typically, you won’t print every piece of output produced. Clearing an output queue removes all spooled files waiting to be printed or held in that queue. The Clear Output Queue (CLROUTQ) command deletes these entries from the specified output queue, such as NEWTON. However, it does not affect the file currently printing or files still being generated by active programs.

Example command:

CLROUTQ OUTQ(NEWTON)

This command clears all pending spooled files from the QPRINT output queue but leaves ongoing print jobs and files still receiving data intact

Deleting an output queue

You can use the character-based interface to delete an output queue, but several conditions must be met before the queue can be removed. First, the output queue must be empty; any spooled files in the queue must be printed, deleted, or transferred to another queue. Additionally, the subsystem controlling the queue must not be active, and the queue cannot be in use by a spooling writer. Finally, queues that were automatically created by the system for specific printers cannot be deleted.

For example, this command deletes the output queue named NEWTON:

DLTOUTQ OUTQ(NEWTON)

This ensures that the specified output queue is removed from the system only when it is safe to do so without disrupting active printing or system operations.

Creating a subsystem description

You can create a subsystem description in two ways: by copying an existing one and modifying it, or by building a new one from scratch. Here are the two methods:

• To copy an existing subsystem description using the character-based interface:
  • Use the Create Duplicate Object (CRTDUPOBJ) command to duplicate an existing subsystem description. Alternatively, you can use the Work with Objects (WRKOBJ) or Work with Objects using Programming Development Manager (WRKOBJPDM) commands.
  • Modify the copied description to meet your needs. For example, remove the original job queue entry since it points to the old job queue, and then add a new job queue entry with parameters for the new subsystem.
  • Review entries such as AutoStart jobs, workstation entries, prestart jobs, and communication entries to avoid conflicts between the original and new subsystems. For instance, ensure that workstation entries don’t make both subsystems allocate the same display devices.
• To create a completely new subsystem description using the character-based interface:
  • Use Create Subsystem Description (CRTSBSD).
  • Create a job description (CRTJOBD).
  • Create a class (CRTCLS) for use, in add prestart job entries (ADDPJE) and routing entries (ADDRTGE).
  • Add necessary work entries to the subsystem description such as:
    • Workstation Entry (ADDWSE)
    • Job Queue Entry (ADDJOBQE)
    • Communications Entry (ADDCMNE)
    • AutoStart Job Entry (ADDAJE)
    • Prestart Job Entry (ADDPJE)
    • Routing Entries (ADDRTGE)

This approach ensures your subsystem is properly configured with all required components and no conflicts with existing subsystems.

Changing a subsystem description

The Change Subsystem Description (CHGSBSD) command modifies the operational settings of a specified subsystem description. You can make changes to the subsystem description even while the subsystem is running. This is done through the character-based interface.

For example, the following command adjusts storage pool 2 used by the PRIORITY1 subsystem to have a storage size of 1500K and an activity level of 3. It also changes the sign-on display file to COMPNAME in the QGPL library. If the subsystem is currently active, the new display file won’t take effect until the subsystem is restarted.

CHGSBSD SBSD(QSYS/PRIORITY1) POOLS((2 1500 3)) SGNDSPF(QGPL/ COMPNAME)

This command allows you to update various parameters of the subsystem description without needing to stop the subsystem.

Viewing subsystem attributes

Subsystems feature various attributes that provide information about their current condition or details specified in the subsystem description. When using IBM Navigator for i, you can view these attributes for an active subsystem:

• Subsystem: Displays the subsystem’s name along with the library housing its description.
• Description: Shows the description assigned to the subsystem.
• Status: Indicates the subsystem’s current state, with help documentation explaining possible statuses.
• Active jobs: Counts the jobs currently active in the subsystem, whether running or waiting, excluding the subsystem job itself.
• Maximum active jobs: Specifies the highest number of jobs allowed to be active in the subsystem, both running and waiting.
• Subsystem job: Lists the subsystem job name, including the user and job number.

To access the character-based interface, enter the following command:

Command: Display Subsystem Description (DSPSBSD)

Example: This command brings up the subsystem description menu for the subsystem named PRIORITY1:

DSPSBSD QSYS/PRIORITY1

Stopping a Subsystem

Two types of stops exist for subsystems.

Controlled (Recommended)

This method terminates the subsystem in a controlled way, allowing jobs to end orderly so running programs can complete cleanup tasks, such as end-of-job processing. If a job handles the SIGTERM signal, it receives this signal and has time set by the DELAY parameter to finish before termination.

Command: End Subsystem (ENDSBS)

ENDSBS SBS(PRIORITY1) OPTION(*CNTRLD) DELAY(180)

Ends all active jobs in PRIORITY1 and the subsystem itself, giving jobs 180 seconds for cleanup.

Immediate

This option shuts down the subsystem right away, ending jobs instantly with no cleanup allowed except SIGTERM signal handling within the QENDJOBLMT system value time limit.

Command: End Subsystem (ENDSBS)

ENDSBS SBS(PRIORITY1) OPTION(*IMMED)

Terminates all active jobs in PRIORITY1 and the subsystem immediately.