Lesson 5 · July 2026 RPG Enhancements

RPG PSDS Job Type and Subtype

Learn how RPG can use the PSDS job type and subtype fields to understand how a program is running, with short practical examples.

Saurabh Arora

IBM i Solution Architect | Technical Lead | Modernization & Integration Specialist

Published July 21, 20264 min read

The PSDS can now include job type and subtype information, giving RPG programs an easier way to understand how they are running.

The Program Status Data Structure, usually called the PSDS, is one of those RPG features that many developers know exists, but do not always use often.

It can provide useful runtime information about the current program and job.

With the July 2026 RPG enhancements, IBM lists job type and subtype in the PSDS as one of the new additions.

That gives RPG programs another simple way to understand their execution context.

What changed?

IBM added job type and job subtype information to the RPG Program Status Data Structure.

The exact field names and layout should be confirmed from the current IBM documentation and PTF level before using the feature in production code.

Conceptually, your program can use the PSDS to answer questions like:

What kind of job am I running in?
Is this an interactive job?
Is this a batch job?
Is this a special job subtype?

Simple way to remember

The PSDS tells your RPG program about its runtime context. Job type and subtype add more context about the job itself.

Why should you care?

Many RPG programs behave differently depending on where and how they run.

For example:

Interactive programs may show messages to a workstation user.
Batch programs may write more detail to a job log.
Service programs or API-style jobs may need different error handling.
Scheduled jobs may need different logging or notification behavior.
Utility programs may need to detect whether they are running in the expected job context.

Before this enhancement, developers often used other approaches to find job information.

For example, they might call APIs, use SQL services, inspect job names, or depend on job descriptions and environment conventions.

Those approaches can still be valid.

But having job type and subtype available in the PSDS can make some RPG code simpler and more direct.

Simple PSDS shape

A PSDS is defined with psds.

**free
ctl-opt dftactgrp(*no);

dcl-ds PgmStatus psds qualified;
  programName char(10) pos(1);
  statusCode  char(5)  pos(11);
  jobName     char(10) pos(244);
  userName    char(10) pos(254);
  jobNumber   char(6)  pos(264);

  // Confirm the current IBM documentation for the
  // job type and subtype positions/names before using.
  jobType     char(1);
  jobSubtype  char(1);
end-ds;

*inlr = *on;
return;

This example shows the idea, but you should confirm the exact PSDS layout from IBM documentation for your release and PTF level.

Example: choose different logging behavior

One common use case is logging.

A program may want to log differently when running in batch versus interactive mode.

if PgmStatus.jobType = 'B';

  // Batch job:
  // write detailed diagnostic information to a log table or job log.

elseif PgmStatus.jobType = 'I';

  // Interactive job:
  // keep the message short and useful for the user.

else;

  // Other job type:
  // use a safe default logging approach.

endif;

The exact job type values should be confirmed from the IBM documentation for the enhancement.

The main idea is simple:

Let the program use its job context to make better runtime decisions.

Example: guard a utility program

Some utilities should only run in batch.

For example, a cleanup process, archive process, or mass update program may not be intended for interactive use.

if PgmStatus.jobType <> 'B';

  // Send an error message, log the issue, or return safely.
  // This program is expected to run only in batch.

  return;

endif;

This kind of check can prevent a program from being used in the wrong context.

It is not a replacement for authority, job control, or good operational design.

But it can be a useful safety check.

Example: different behavior for scheduled processing

Imagine a program used both manually and by a scheduler.

The job type and subtype can help the program decide how much output to create, where to log messages, or whether to send notifications.

select;

when PgmStatus.jobType = 'B';

  // Batch/scheduled style processing.
  // Write detailed operational logs.

when PgmStatus.jobType = 'I';

  // Interactive usage.
  // Keep output user-friendly.

other;

  // Fallback behavior.
  // Avoid assuming too much.

endsl;

Again, confirm the specific values from IBM documentation before relying on them.

When to use PSDS job type and subtype

Use these PSDS fields when the program needs to understand how it is running.

Good use cases include:

changing logging behavior
detecting batch versus interactive execution
guarding programs that should only run in certain job types
improving diagnostic messages
supporting operational utilities
making error handling more context-aware

When not to use it

Do not overuse job type checks.

If a program’s business logic should be the same regardless of job type, keep it the same.

Avoid scattering job-type logic all over the application.

It is usually better to centralize this kind of check in:

utility procedures
logging procedures
message handling logic
program entry checks

Also avoid using job type as a substitute for security.

Authority, adopted authority, object ownership, and operational controls still matter.

Practical advice

Use the PSDS job type and subtype where it makes the code more intentional.

For example, this is reasonable:

if isBatchJob();
  writeDetailedLog();
else;
  sendUserMessage();
endif;

This is better than repeating low-level PSDS checks everywhere.

The PSDS can provide the information.

Your application design should decide how to use it cleanly.

PTF / release note

PTF / release note

Before using the new PSDS job type and subtype fields, verify the required IBM i release level, RPG compiler PTF, SQL RPG compile support, and runtime PTFs on the systems where the program will be compiled and run.

IBM’s RPG Cafe lists job type and subtype in the PSDS as part of the July 2026 RPG enhancements. Check IBM’s RPG Cafe and IBM documentation for current release, PTF, and field layout details before using it in real development or production environments.

Final takeaway

The PSDS already helps RPG programs understand their runtime context.

Adding job type and subtype makes that context more useful.

Use it when the program needs to make clear runtime decisions based on how the job is running.

Keep it simple.

Keep it centralized.

And always verify the current IBM documentation before relying on the exact field layout or values.

References

Documentation and references used for this lesson.

Comments

Share your thoughts, questions, or real-world IBM i experiences related to this article.