Skip to content

AP991P RPG

The provided document is an RPG (Report Program Generator) program, AP991P.rpg36.txt, designed for the IBM System/36 environment. This program is called by the OCL (Operation Control Language) script AP991P.ocl36.txt previously discussed. It appears to be part of an accounts payable (A/P) system, specifically handling override code retrieval and validation. Below, I’ll explain the process steps, business rules, tables used, and external programs called, based on the RPG source code.

Process Steps of the RPG Program

The RPG program AP991P is structured to interact with a workstation (screen) and a disk file, performing data retrieval and updates related to an override code. Here’s a step-by-step breakdown of the process steps, based on the RPG code:

  1. Program Initialization (Header and File Specifications)
  2. H-Spec (Line 0002): The header specification (H P064) identifies the program as AP991P and likely includes compilation options (e.g., P064 may indicate a specific program option or library).
  3. F-Specs (Lines 0004, 0008):
    • SCREEN: Defined as a workstation file (WORKSTN), used for interactive input/output with a display device (e.g., a terminal screen). It has a record length of 500 bytes.
    • GSCONT: Defined as an update-capable (UF), full-procedural (F), disk file with 512-byte records, indexed (2AI) with 2 keys. This file is likely a control or master file for accounts payable data.

  4. Comment (Line 0003): Indicates the program’s purpose: "PROMPTS FOR A/P OVERRIDE CODE RETRIEVAL," suggesting it retrieves or validates an override code for accounts payable processing.

  5. Input Specifications (I-Specs)

  6. SCREEN Input (Lines 0006–0009):
    • Defines input format GL951PS1 for the SCREEN file, with a field KYCODE (positions 3–8, 6 characters) read from the screen.
    • NS 01 and NS 09 indicate different record types or conditions for screen input, with CS and C1 possibly representing control or cursor fields.
  7. GSCONT Input (Lines 0042–0044):
    • Defines a field GXCODE (positions 53–58, 6 characters) in the GSCONT file, described as the "OVERRIDE CODE FOR POSTING."
  8. UDS (User Data Structure, Lines 0011–0014):
    • Defines fields in a user data structure:
    • KYJOBQ (position 120, 1 character): Likely a job queue indicator.
    • KYCOPY (positions 121–122, 2 characters): Possibly a copy or version number.
    • KYCANC (positions 129–134, 6 characters): Likely a cancellation code.
    • KYCODE (positions 135–140, 6 characters): The override code, matching the screen and file fields.

  9. These fields are likely used for job control or validation.

  10. Calculation Specifications (C-Specs)

  11. Initialize Variables (Lines 0016–0019):
    • MOVEL*BLANKS MSG 40: Clears a 40-character message field (MSG) to blanks.
    • SETOF 8190: Turns off indicators 81 and 90, which are likely used for screen or error handling.
  12. Indicator Logic (Line 0024):
    • If indicator 09 is on (from screen input), set indicator 81 on (likely for screen display control).
    • If indicator 09 is off (N09), set the Last Record (LR) indicator and jump to the END tag, terminating the program.
  13. Time and Date Processing (Lines 0151–0208):
    • TIME TIMEOF 60: Retrieves the current time into a 6-character field TIMEOF.
    • TIME TIMDAT 120: Retrieves the current date and time into a 12-character field TIMDAT.
    • MOVELTIMDAT SYSTIM 60: Moves the first 6 characters of TIMDAT to SYSTIM (system time).
    • MOVE TIMDAT SYSDAT 60: Moves TIMDAT to SYSDAT (system date).
    • SYSDAT MULT 10000.01 SYSYMD 60: Multiplies SYSDAT by 10000.01 to create a year-month-day format in SYSYMD.
    • MOVEL20 SYSDT8 80: Moves the literal 20 (likely for century, e.g., 20xx) to the first 2 characters of SYSDT8 (8-character date field).
    • MOVE SYSYMD SYSDT8: Completes the date field SYSDT8 with SYSYMD.
    • SYSDAT ADD SYSTIM FLD1 80: Adds SYSDAT and SYSTIM to create FLD1 (8 characters), combining date and time.
    • FLD1 MULT SYSYMD FLD2 110: Multiplies FLD1 by SYSYMD to create FLD2 (11 characters), possibly for a unique key or hash.
    • Z-ADDFLD2 KYCODE 60: Zero-adds FLD2 to KYCODE, creating a 6-character override code.
  14. File Access (Line 0208):
    • '00' CHAINGSCONT 99: Chains (searches) the GSCONT file using the key '00' (likely a default or control record key), setting indicator 99 if the record is not found.
    • N99 EXCPT: If the record is found (N99, indicator 99 off), execute an exception output (write/update) to GSCONT.
  15. Cancellation Logic (Lines 0021–0022):
    • If indicator KG is on (undefined in the code but likely set externally or in prior logic), turn off indicators 01 and 09 and move 'CANCEL' to KYCANC.
    • This suggests a cancellation condition, possibly linked to the OCL’s ?L'129,6'? check (positions 129–134 match KYCANC).

  16. End Processing (Line 0029):

    • The END tag marks the program’s termination point, reached via GOTO or normal flow.

  17. Output Specifications (O-Specs)

  18. SCREEN Output (Lines 0057–0061):
    • Writes to the SCREEN file using format AP991PFM.
    • Outputs KYCODE (6 characters) and MSG (40 characters, starting at position 7, ending at 46).
  19. GSCONT Output (Lines 0057–0061):
    • Updates or writes to the GSCONT file, outputting KYCODE at positions 53–58 (matching GXCODE).

Business Rules

Based on the program’s logic and context, the following business rules can be inferred:

  1. Override Code Generation:
  2. The program generates an override code (KYCODE) by combining system date (SYSDAT) and time (SYSTIM), performing arithmetic operations to create a unique code (FLD2), and storing it in KYCODE.

  3. This code is likely used to authorize or validate accounts payable transactions, such as posting to a general ledger.

  4. Screen Interaction:

  5. The program prompts the user via the SCREEN file (format GL951PS1) to input or validate an override code (KYCODE).

  6. The message field (MSG) displays feedback or errors to the user.

  7. File Validation:

  8. The program checks the GSCONT file using a key of '00' to retrieve or validate a control record.
  9. If the record is found, it updates GSCONT with the generated KYCODE (as GXCODE).

  10. If the record is not found (indicator 99 on), no update occurs, potentially triggering an error or alternative flow.

  11. Cancellation Handling:

  12. If a cancellation condition is detected (indicator KG or the OCL’s ?L'129,6'? matching KYCANC), the program sets KYCANC to 'CANCEL' and may terminate early.

  13. This aligns with the OCL’s conditional check, suggesting the program supports job cancellation for invalid or unauthorized conditions.

  14. Date and Time Compliance:

  15. The program ensures proper date handling (e.g., century prefix 20 for 20xx dates) to comply with Year 2000 standards, as reinforced by the OCL’s GSY2K command.

Tables Used

  • GSCONT:
  • A disk file used for update and retrieval, containing at least the GXCODE field (positions 53–58) for storing the override code.
  • Likely a control or master file for accounts payable data, indexed with 2 keys.
  • SCREEN:
  • A workstation file used for interactive input/output, with format GL951PS1 for reading KYCODE and format AP991PFM for outputting KYCODE and MSG.
  • Not a traditional "table" but a logical file for user interaction.

External Programs Called

  • None:
  • The RPG program does not explicitly call other programs. It operates standalone, performing its logic using the SCREEN and GSCONT files.
  • The program is called by the OCL script (AP991P.ocl36.txt), but it does not invoke additional external programs within its code.

Additional Notes

  • Indicator Usage: Indicators like 09, 81, 90, 99, and KG control program flow and screen/file operations. Their exact triggers (e.g., KG) are not fully defined in the code and may depend on external inputs or prior logic.
  • OCL Integration: The OCL script’s ?L'129,6'? likely checks the KYCANC field (positions 129–134) for 'CANCEL', linking the RPG program’s cancellation logic to the OCL’s job termination.
  • Parameter ?9?: The OCL’s ?9? placeholder (e.g., in LABEL-?9?GSCONT) may correspond to a library or prefix for GSCONT, but it’s not referenced in the RPG code directly.
  • Legacy Context: The program’s structure (RPG II/III, System/36) indicates a legacy environment, typical for accounts payable systems in the 1980s–1990s. The override code logic suggests a security or control mechanism for financial transactions.

Summary

  • Process Steps: Initialize variables, generate an override code using date and time, interact with the user via SCREEN, validate/update the GSCONT file, handle cancellation, and output results.
  • Business Rules: Generate and validate override codes, support user interaction, update control files, handle cancellations, and ensure Y2K-compliant date processing.
  • Tables Used: GSCONT (disk file), SCREEN (workstation file).
  • External Programs Called: None.

If you have additional details (e.g., the GL951PS1 or AP991PFM screen formats, GSCONT file structure, or external conditions setting KG), I can refine the analysis further.