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

Monitoring and optimizing system performance is essential to ensure that your infrastructure continues to meet evolving business workloads. As business demands grow and shift, the underlying system must adapt accordingly. Although performance management may initially appear to be an additional operational burden, the effort yields measurable benefits—improved system efficiency, higher throughput, and more predictable workload behaviour. These gains are achievable because system changes are proactively planned, executed, and continuously monitored.

Performance management on any platform is inherently complex, requiring deep technical insight into the system’s hardware characteristics, operating system behaviour, and application workload patterns. In this domain, IBM i provides industry leading performance management capabilities. The platform delivers advanced instrumentation, high fidelity performance metrics, continuous collection services, and integrated graphical tools that simplify analysis.

While mastering all the components that influence system performance can be challenging—and diagnosing issues often requires the combined use of several specialized tools—the IBM i performance ecosystem is designed to make these tasks more efficient and accessible. Its native tooling, always-on monitoring, and robust visualization capabilities enable administrators to quickly identify anomalies, isolate bottlenecks, and maintain consistent service levels across the environment.

Selecting a Performance Management Strategy

Developing an effective performance management strategy is essential for maintaining optimal system behaviour and ensuring that the IBM i environment can scale in alignment with evolving business workloads. The specific strategy you choose is heavily influenced by the time and resources your organization can allocate to performance oversight. Smaller organizations often have limited administrative capacity, whereas large enterprises may employ dedicated performance engineering teams to continuously tune and monitor their environments.

Because performance requirements vary significantly across business sizes, IBM recommends tailoring your performance management approach based on whether your organization fits into a small, mid sized, or large business category. Each category has different resource constraints and operational maturity, which influence tool selection and monitoring practices.

Small Business

Small businesses typically have limited staff and operational resources available for performance analysis. Therefore, leveraging automation and IBM-managed services is key to maintaining system stability with minimal administrative effort.

IBM Performance Management for Power Systems (PM for Power Systems) allows automated data collection and secure transmission to IBM, where the data is analysed, aggregated into reports, and supplemented with upgrade recommendations.

Recommended Tools for Small Businesses

• IBM Navigator for i – Performance Interface

  View, analyse, and manage performance data through a browser-based console.

• Collection Services

  Automatically collect performance metrics at configurable intervals for historical or real time analysis.

• IBM Performance Management for Power Systems (PM for Power Systems)

  Automates collection, archival, and centralized IBM driven analysis of performance data.

• IBM Performance Tools for i

  Provides detailed system performance metrics, reports, and trend analysis.

• IBM Navigator for i – Monitors

  Visualize system metrics and configure automated responses to performance thresholds or events.

Mid Sized Business

Mid sized organizations typically have more resources devoted to system administration and can invest more time in structured performance management. Automation remains beneficial, but teams may also conduct deeper analysis using IBM’s on platform toolsets.

Recommended Tools for Mid Sized Businesses

• IBM Navigator for i – Performance Interface

  For real-time and historical performance analysis.

• Collection Services

  For comprehensive sampling of CPU, memory, I/O, and workload metrics.

• IBM Performance Management for Power Systems (PM for Power Systems)

  For automated, IBM assisted performance reporting.

• IBM Performance Tools for i

  For detailed analysis and capacity planning.

• IBM Navigator for i – Monitors

  For ongoing monitoring and automated alerting.

Large Business

Large enterprises typically maintain dedicated performance engineers or operations teams who continuously monitor, tune, and optimize IBM i workloads. These environments require deeper instrumentation and diagnostic tooling to analyse job-level, disk-level, and application-level performance characteristics.

Recommended Tools for Large Businesses

• IBM Navigator for i – Performance Interface

  Centralized access to high level and granular system metrics.

• Collection Services

  Persistent, low-overhead data collection for all workloads.

• IBM Performance Management for Power Systems (PM for Power Systems)

  Enterprise-grade automated reporting and capacity planning.

• IBM Performance Tools for i

  Advanced analytics and performance reporting.

• IBM Navigator for i – Monitors

  Real-time visualization with automated responses.

• IBM i Job Watcher

  Capture detailed information about job, thread, and wait conditions.

• IBM i Disk Watcher

  Collect granular disk subsystem performance data for diagnosing I/O bottlenecks.

• Performance Explorer (PEX)

  Instrument and analyse application specific or subsystem level performance behaviour with high detail.

Tracking System Performance

Tracking system performance over extended periods is essential for effective capacity planning and for maintaining optimal operational stability. Long‑term performance data provides the historical baseline required to evaluate system growth patterns, identify emerging performance bottlenecks, and detect deviations from expected workload behaviour. It also provides the diagnostic context needed to isolate performance issues by enabling comparisons of system activity before, during, and after an incident.

Continuous performance monitoring allows administrators to observe systemic trends and workload dynamics, enabling data‑driven decisions regarding tuning, workload redistribution, or hardware and software upgrades. When a performance degradation occurs, historical data becomes critical for narrowing the root cause, validating hypotheses, and implementing the correct remediation steps.

IBM i includes a comprehensive suite of instrumentation and analysis tools designed to facilitate ongoing performance tracking and historical retention of metrics. Most of these tools rely on Collection Services, the platform’s always-on, low-overhead data collection framework. Through Collection Services, administrators can analyse long‑term trends in several key operational areas, including:

• System Resource Utilization Trends

  Provides insight into CPU, memory, disk, and I/O usage patterns, supporting accurate planning for system tuning and hardware scaling.

• Identification of Physical Component Stress

  Highlights performance hotspots or subsystems experiencing sustained load, enabling proactive maintenance or configuration adjustments.

• Workload Balancing Analysis

  Tracks utilization distribution between interactive and batch workloads, both during peak periods and under normal operating conditions, assisting in optimizing job scheduling and subsystem configuration.

• Impact Assessment of Configuration Changes

  Historical data enables precise modelling and prediction of how system changes—such as adding user communities, increasing interactive workloads, or modifying subsystems—will affect overall performance.

• Detection of Problematic Jobs or Workloads

  Identifies specific jobs or threads that create bottlenecks or negatively affect other system activities.

• Communication Line Utilization and Trending

  Monitors consumption and usage patterns of available communication resources, supporting capacity planning and network tuning.

Recommended IBM i Tools for Long‑Term Performance Tracking

• IBM Navigator for i – Performance Interface

  Provides browser-based visualization, analysis, and drill-down capabilities for real-time and historical performance data.

• Collection Services

  Serves as the core data collection engine, continuously gathering a wide spectrum of system metrics with minimal overhead.

• IBM Performance Management for Power Systems (PM for Power Systems)

  Automates collection, archival, and secure transmission of performance data to IBM, where it is analysed and compiled into capacity and performance reports.

Analysing a System Performance Issue

A wide range of diagnostic tools and analytical methods are available on IBM i to assist in identifying, isolating, and resolving system performance issues. Understanding how to apply these tools and interpret their output is essential for determining the underlying cause of performance degradation.

Most IBM i performance instrumentation relies on either sample-based data collection or trace-level data collection. Collection Services is the primary subsystem for sample data gathering and continuously records operational metrics across numerous system resources with minimal overhead. Multiple IBM i performance applications, reports, and analysis utilities consume this sample data to provide a broad, system-level perspective. This enables administrators to answer common performance questions related to CPU utilization, memory consumption, disk I/O activity, job behaviour, and overall system load. Additional sampling tools—such as IBM i Job Watcher and IBM i Disk Watcher—collect more focused datasets, enabling in-depth analysis of job execution patterns, thread wait conditions, and disk subsystem behaviour.

For scenarios where granular, low-level diagnostic information is required, IBM i provides trace-level instrumentation tools. Trace data offers highly detailed insights into job execution, system APIs, performance counters, and application behaviour. Tools such as Performance Explorer (PEX) and the Start Performance Trace (STRPFRTRC) command generate trace data suitable for advanced root cause analysis, particularly when investigating intermittent issues or workload anomalies that are not visible through high-level sampling.

Example Diagnostic Workflow

If the system experiences noticeable slowdowns, an administrator may begin by reviewing system activity using IBM Navigator for i monitors. If the monitors indicate sustained high CPU utilization, the administrator can identify specific jobs consuming disproportionate resources. Some issues may be resolved through system configuration adjustments—such as subsystem tuning, workload balancing, or job priority modifications.

However, certain performance anomalies require deeper investigation. In such cases, the administrator may initiate a Job Watcher collection targeted at the problematic job to capture detailed metrics about CPU wait states, locking behaviour, thread activity, and I/O requests. This detailed dataset provides the diagnostic context needed to evaluate how the job interacts with system resources and may reveal inefficiencies or issues within the originating application code. Based on the collected evidence, corrective actions may include application tuning, code changes, or adjustments to system configuration parameters.

Diagnosing System Performance Degradation

Identifying a performance problem requires a systematic and analytical approach to determine whether the system is operating within expected parameters and whether the existing configuration can sustain the current workload. The first step is to assess the adequacy of the underlying hardware resources. This includes evaluating CPU capacity, main storage availability, disk subsystem performance, and communication bandwidth. Capacity modelling or workload simulation techniques can help determine whether the system is properly sized before deeper diagnostic efforts are undertaken, ensuring time is not wasted on investigating issues caused by insufficient hardware.

After establishing a baseline understanding of the symptoms and performance objectives, the analyst formulates a hypothesis to explain the underlying cause of the degradation. IBM i provides a comprehensive set of commands and diagnostic tools—including those in IBM Performance Tools for i —to gather system metrics, job-level data, and workload characteristics. Using these tools, the analyst collects, correlates, and reviews relevant performance data.

The collected data is then analysed to refine the problem definition and validate or disprove the working hypothesis. Once likely causes have been isolated, targeted corrective actions can be proposed. Implementing one change at a time allows analysts to precisely measure its effect, ensure that it addresses the identified bottleneck, and verify that no secondary issues are introduced. IBM i performance tools can measure solution effectiveness and reveal any unintended side effects.

Achieving optimal performance requires understanding the interdependencies among key system resources—CPU, main storage, disk I/O, and communication lines. Any imbalance or saturation in one of these components can trigger system-wide performance degradation. Depending on the scenario, improvements to interactive response time, interactive throughput, batch throughput, or mixed workloads may involve:

• Adjusting subsystem configuration parameters
• Modifying memory pool sizes or activity levels
• Redistributing workload across subsystems
• Optimizing application logic or database access patterns

For example, in IBM i, activity level is a subsystem attribute that defines the maximum number of jobs allowed to compete simultaneously for CPU resources. Tuning this parameter can influence throughput and responsiveness by managing the degree of system multiprogramming.

Work management on IBM i provides the command interfaces, system structures, and internal control mechanisms required to orchestrate system operations and regulate the execution of daily workloads. It also includes the resource allocation functions necessary to ensure that applications receive the appropriate CPU, memory, and subsystem resources needed to operate efficiently.

At its core, the IBM i operating environment is designed to process work. Work is submitted to the system, dispatched for execution according to defined policies, and ultimately completed with associated output generated. Viewed from this lifecycle perspective, work management defines:

• How and where work enters the system (job submission points, subsystems, job queues)
• How work is executed and by which system resources (subsystem routing, memory pools, activity levels, dispatching priority)
• Where the results of that work are delivered (output queues, spool files, job logs, or external interfaces)

Understanding these stages—work entry, work processing, and work completion—provides a structured framework for analysing and managing workload behaviour across the IBM i environment.

Job’s Lifecycle

To understand the fundamentals of IBM i work management, it helps to follow the path of a simple batch job as it progresses through the system.

A batch job’s lifecycle begins when it is submitted. At that point, the job is placed into a job queue, where it waits for a subsystem to become available. Once the subsystem selects the job for execution, the system assigns memory from an appropriate memory pool so the job can run.

After the job completes, any printer output it produces (known as spooled files) is directed to an output queue. From there, the output waits for further actions—such as printing or other processing. While not all jobs follow this exact sequence, understanding this basic flow helps clarify how various types of work are managed on IBM i.

Lifecycle Summary:

Submit Job → Job Queue → Subsystem → Memory Allocated → Job Completes → Output Queue

Submitting a Job

When a job is submitted, it is created and introduced into the IBM i system. At this point, the system assigns all necessary attributes to the job.

These attributes come from the job description, which defines how the job will proceed through the work management cycle. Key details include the user profile under which the job will run, the request data specifying what the job should do, and the initial user portion of the library list. The job description also specifies which job queue the job should enter and includes routing data, which the subsystem later uses to locate the correct routing entry required to start the job.

The job description further identifies the output queue, which determines where any printer output (spooled files) produced by the job will be sent.

Once the job has been assigned and initialized with all its attribute values, it moves into the job queue, where it waits for the subsystem to select it for processing.

Job Enters/Waiting in the Job Queue

A job queue acts as the entry point for batch jobs into the IBM i system. It functions much like a “waiting area” where jobs remain until a subsystem is ready to process them.

Several factors determine when a job is removed from the job queue and passed to a subsystem. These include the job’s priority on the queue, the queue’s sequence number within the subsystem, and the subsystem’s maximum active job limit. When these conditions align, the subsystem selects the job for execution.

Once a job is placed on the job queue, it becomes available to any subsystem that has been configured to use that queue. A subsystem can have multiple job queues assigned to it, but a single job queue cannot feed multiple subsystems. The subsystem evaluates the sequence number of each job queue first to determine the order in which the queues are serviced. Within a job queue, the subsystem then uses job priority to decide the relative order in which jobs are eligible to enter the subsystem.

Ultimately, the combination of job priority and the subsystem’s maximum active job setting determines when a job leaves the job queue and begins execution within the subsystem.

Job in Subsystem

A subsystem is an operating environment that manages the resources required by jobs and controls the jobs that run within it. Once a job enters a subsystem, it becomes active, and the subsystem can perform actions such as holding, releasing, or ending the job based on user requests.

Like jobs, subsystems are defined by subsystem descriptions that contain critical information necessary for processing work. One key component is the routing entry. The routing entry points to a class object, which defines attributes that control the job’s run-time environment. However, before a job can use a routing entry, its routing data must match the compare value specified in that entry. If this match fails, the job cannot be started.

After a successful match, the system determines the class object the job will use. The class object governs run-time attributes such as run priority, time slice, maximum wait time, maximum processing time, maximum temporary storage, and the maximum number of threads available.

The subsystem description also defines the memory pools allocated to the subsystem, as well as the maximum number of active jobs it can support simultaneously. A job cannot begin running until it receives an activity level and is assigned a memory pool.

Overall, the subsystem description—like a job description—provides essential details such as the designated memory pool, routing entry, maximum active jobs, and the number of jobs currently active in the subsystem.

Subsystem Resource Utilization for Job Execution

A subsystem consumes memory allocated from its assigned memory pool to execute a job’s processing workload. The overall execution efficiency is directly influenced by the pool’s configured storage size and the level of memory contention from concurrently active jobs.

Memory pools provide the addressable working storage in which job threads execute. Job performance within a pool is governed by factors such as pool size, activity level (the maximum number of simultaneously dispatchable threads), and the rate of system paging and page-fault occurrences. Each job contains at least one active thread, but may spawn multiple threads to support parallel execution paths—for example, computation in one thread while another awaits I/O.

Paging refers to the synchronous or asynchronous movement of memory pages between main storage and disk. Pages may be written back to auxiliary storage or discarded if unmodified. A page fault is triggered when a referenced memory page is not resident in main storage; this forces the task to suspend until the page is retrieved, introducing latency into program execution.

Subsystems may be configured with multiple memory pools to isolate workloads and optimize performance characteristics across different job types.

Job Completion

When a job finishes, any generated printer output—referred to as spooled files—is placed into an output queue. Like a job queue, the output queue regulates how spooled files are released to a printer or other output device, allowing prioritization and controlled processing.

Output queues serve as holding areas where spooled files wait for further handling. Printer output may be produced automatically by the system or via a user defined print file. A print file acts as a template that defines default attributes for the spooled output and represents the starting point of the printer output lifecycle.

Print files specify the OUTQ (output queue) and DEV (printer device) parameters, which determine where the spooled file is routed. These values commonly default to *JOB, meaning that the job’s own output queue and device attributes are used. These job-level attributes are derived at job creation from the user profile, job description, workstation device description, and the QPRTDEV (Default Printer) system value.

When the system is ready to generate the spooled file, it evaluates the print file attributes first, followed by the job attributes, to determine the correct output queue and device. If the specified output queue does not exist, the output is redirected to the default queue: QGPL/QPRINT.

Once the spooled file is ready, a writer job—the process responsible for transferring data from the output queue to the output device—retrieves the spooled file and delivers it to the designated printer or target device.

System values serve as global configuration parameters that define and control the IBM i operating environment. Unlike traditional system objects, system values are non-object entities that store critical control data governing core system operations.

These parameters allow administrators to configure fundamental aspects of the runtime environment—such as system date/time, default library list behaviour, international settings, and various security controls. By adjusting system values, you effectively modify the system’s operational characteristics.

Modifying a system value requires USE authority to the CHGSYSVAL (Change System Value) command. Certain system values additionally require elevated privileges, which are documented within their respective descriptions. Most security-related system values can be updated only by users possessing both *Security Administrator (SECADM) and *All Object (ALLOBJ) special authorities.

To further safeguard critical security settings, IBM i provides mechanisms within System Service Tools (SST) and Dedicated Service Tools (DST) to lock sensitive security system values, preventing modification even by highly privileged users during normal system operation.

System value categories

These system value categories are different from the categories used in the character-based interface.

Summary

System Values are essential because they control the core operational, security, performance, and startup characteristics of the entire IBM i system. They act as the foundation for system stability, security posture, and predictable behaviour across all jobs, user profiles, and workloads.