Lesson 4 · July 2026 RPG Enhancements

RPG ON-EXCP with Generic Message IDs

Learn how RPG ON-EXCP can monitor for generic message IDs, with short practical examples for MONITOR groups.

Saurabh Arora

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

Published July 20, 20264 min read

ON-EXCP with generic message IDs lets RPG developers monitor a group of related exception messages in a MONITOR block.

RPG already has MONITOR, ON-ERROR, and ON-EXCP.

ON-EXCP is useful when you want to handle specific exception messages by message ID instead of only using status codes.

The new enhancement makes this more flexible by allowing generic message IDs.

That means an RPG program can monitor for a group of messages using a generic pattern.

What changed?

Before this enhancement, ON-EXCP was used with specific message IDs.

Conceptually:

on-excp 'CPFxxxx';

With generic message IDs, you can monitor for a group of related messages.

Conceptually:

on-excp 'CPF9800';

The idea is similar to how many IBM i developers think about generic message IDs in CL MONMSG.

Why should you care?

Generic message IDs can reduce repetitive exception handling.

Instead of writing separate handling logic for several related messages, you can group them when the recovery action is the same.

That can make the code:

• shorter
• easier to read
• easier to maintain
• closer to the way many IBM i developers already think about message handling

Simple example

This example shows the basic shape of a MONITOR group using ON-EXCP.

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

monitor;

  // Code that may send an exception message
  // Example: file access, object access, or API call

on-excp 'CPF9800';

  // Handle a group of CPF98xx object-related messages
  dsply 'Object-related exception occurred';

on-error;

  // Handle other errors
  dsply 'Unexpected error occurred';

endmon;

*inlr = *on;
return;

This keeps the object-related exception handling in one place.

Example: handling object-related messages

Many IBM i programs work with objects such as files, data areas, data queues, message queues, or user spaces.

Sometimes, the recovery action is the same for a group of object-related failures.

For example:

monitor;

  // Try to use an object that may not exist,
  // may not be authorized, or may not be available.

on-excp 'CPF9800';

  // Log the object problem and continue or return gracefully.
  // The specific message still matters for diagnostics,
  // but the business response may be the same.

on-error;

  // Other unexpected errors.

endmon;

The important part is not the exact message group.

The important part is the design idea:

If several related exception messages should be handled the same way, a generic message ID can make the RPG code clearer.

ON-EXCP must come before ON-ERROR

Inside a MONITOR group, put ON-EXCP before ON-ERROR.

monitor;

  // monitored code

on-excp 'CPF9800';

  // specific or generic message handling

on-error;

  // fallback handling

endmon;

This is important because ON-ERROR is the broader fallback.

The more specific message handling should appear first.

Specific versus generic message IDs

Use a specific message ID when one message needs special handling.

on-excp 'CPF5026';

Use a generic message ID when a group of related messages should have the same handling.

on-excp 'CPF9800';

A good rule is:

Special recovery?  Use a specific message ID.
Same recovery?     Consider a generic message ID.

When to use generic message IDs

Use generic message IDs when:

• several related messages have the same recovery action
• the code is currently repeating similar ON-EXCP blocks
• the exact message should be logged, but the handling logic is shared
• you want cleaner fallback logic inside a MONITOR group
• you are handling a known family of IBM i exception messages

When not to use generic message IDs

Do not make the generic message ID too broad.

If you monitor too wide a group, you may accidentally hide an error that should have been handled differently.

For example, avoid using a broad generic message ID just because it makes the code shorter.

Shorter code is not always better if it hides important differences.

Use generic handling only when the recovery action truly belongs together.

Practical advice

When using generic message IDs, I would usually do three things:

• Keep the MONITOR block small.
• Log enough detail for troubleshooting.
• Use ON-ERROR as the final fallback.

That keeps the logic easy to understand.

It also helps avoid the common problem of catching too much and hiding the real issue.

PTF / release note

IBM’s RPG Cafe lists generic message IDs for ON-EXCP as part of the July 2026 RPG enhancements. Check IBM’s RPG Cafe for current release and PTF information before using it in real development or production environments.

Final takeaway

Generic message IDs make ON-EXCP more flexible.

They let RPG developers handle related exception messages with one clear block of logic.

Use them when the recovery action is truly shared.

Avoid them when different messages need different handling.

The goal is not just shorter RPG code.

The goal is clearer exception handling.