Skip to content

BB110E RPG36

Process Steps of the RPG Program BB110E

This RPG III program (indicated by the .rpg36 extension and syntax) appears to manage a simple interactive display screen, likely a "busy" or waiting screen used during order entry processes for picking tickets and confirmations. It handles user input, particularly for cancellation, and controls program flow via indicators. The program is designed for an IBM midrange system (e.g., AS/400 or iSeries) and interacts with a workstation display file. Below is a step-by-step breakdown of the program's execution:

  1. Program Initialization and File Definition:
  2. The program starts with header (H) specifications, identifying it as BB110E with a parameter P016 (possibly a program identifier or option).

  3. Defines a display file named SCREEN as a combined file (CP) with a record length of 500, used for workstation (WORKSTN) interaction. This file handles screen input/output.

  4. Input Specifications and Data Area Setup:

  5. Defines input for the SCREEN file under format 01 (likely a screen format).
  6. Sets up a user-defined data structure (UDS) with positions 300-305 reserved for a field named CANCEL (likely a 6-character field to store cancellation status).

  7. No database reads or complex inputs; this is primarily for screen handling.

  8. Calculation and Logic Execution:

  9. Under indicator 01 and when not in key group 10 (10NKG), turns off indicator 10 (SETOF 10). This might reset a status or error flag.
  10. If a specific key group (KG, possibly the cancel key like F12 or AID byte for cancel) is pressed:
    • Moves 'CANCEL' into the CANCEL field.
    • Turns off indicators 01 and 10 (SETOF 0110).
    • Sets on the last record indicator (LR), which signals the program to end.

  11. If indicator 09 is off (N09), sets on indicators 10 and 09 (SETON 1009). This could enable/disable screen elements or control visibility (e.g., error messages or busy status).

  12. Output and Screen Display:

  13. Outputs to the SCREEN file under detail (D) line for indicators 01 and 10.
  14. Writes a record with key 8 (K8) referencing format 'BB110EFM' (likely a display format name for the busy screen layout).

  15. The screen is displayed to the user, waiting for input (e.g., cancel key).

  16. Program Termination:

  17. If cancel is triggered, the program ends via LR indicator.
  18. Otherwise, it may loop or redisplay based on calling context (as it's called from OCL, control returns to the caller).

The program runs in a loop implicitly through workstation interaction: display screen → wait for input → process keys → potentially redisplay or exit. It's a modal screen, blocking until user interaction or cancellation.

Business Rules

  • Cancellation Handling: The primary rule is to detect a cancel key press (KG) and set a 'CANCEL' flag in a shared data area (UDS positions 300-305). This allows the calling OCL or program to check for cancellation and abort processes like order entry, picking ticket generation, or confirmations. It prevents indefinite waiting during busy operations.
  • Indicator-Based Control: Uses RPG indicators (01, 09, 10) to manage screen states:
  • Indicator 01: Likely controls the main screen display.
  • Indicator 10: Toggled for status (e.g., busy vs. ready) or error handling.
  • Indicator 09: Conditionally set, possibly for validation or visibility of screen elements.
  • No data validation or business logic beyond key handling; it's a utility for user interruption during long-running tasks.
  • Integration Context: As called from the main OCL (e.g., during validation loops for proforma invoices), it enforces a "busy" state rule: Show a waiting screen to the user while background processing occurs, with an option to cancel to avoid locks or timeouts.
  • Error/Status Management: Resets indicators on entry/exit to ensure clean state transitions. No explicit error handling, but indicator 09/10 might flag issues like invalid input.

Tables/Files Used

  • SCREEN: A workstation display file (WORKSTN) used for interactive screen I/O. It defines the user interface (e.g., busy message, cancel prompt). No database tables (physical or logical files) are used; this program is screen-focused.

External Programs Called

  • None: The program does not call any external programs (no CALL opcodes or references). It is self-contained and returns control to the caller (e.g., the OCL script) upon completion or cancellation.