Skip to content

AR200P RPGLE

The provided document is an RPGLE program named AR200P.rpgle.txt, which is called by the OCL program AR200P.ocl36.txt (as seen in the previous query). This RPG program is designed to prompt the user for a journal date for cash receipts posting in an accounts receivable (AR) module, likely on an IBM System/36 or AS/400 system. Below, I’ll explain the process steps, business rules, tables used, and external programs called.

Process Steps of the RPG Program

The RPGLE program AR200P is responsible for displaying screens to prompt the user for a journal date, validating the input, and confirming the date before proceeding. The program uses two screen formats (AR200PS1 and AR200PS2) and includes date validation logic. Here’s a step-by-step breakdown of the process:

  1. Program Initialization:
  2. Header Specifications:
    • H DFTACTGRP(*NO): Runs in a non-default activation group, typical for ILE RPG.
    • H fixnbr(*zoned:*inputpacked): Ensures zoned and packed numeric fields are handled correctly.
    • H dftname(ar200p): Sets the default program name to AR200P.
  3. File Declarations:
    • far200pd cf e workstn Handler('PROFOUNDUI(HANDLER)') infds(@infds): Defines a workstation file (AR200PD) for interactive screen handling, using a Profound UI handler for modernized display. The infds (information data structure) captures screen status, including the virtual key pressed (@vkey).
  4. Data Definitions:
    • msg: A 35-character array with one predefined message ("INVALID DATE") for error handling.
    • uds: A user data structure containing:
    • kyjrdt (positions 100-105, numeric): Stores the journal date.
    • y2kcen (positions 509-510, numeric): Century for Year 2000 compliance.
    • y2kcmp (positions 511-512, numeric): Comparison value for century.
    • @infds: Captures screen status, including @vkey for the function key pressed.

  5. Input Specifications:

    • Defines two screen formats: AR200PS1 (S1) and AR200PS2 (S2).
    • AR200PS1: Contains jrdate (journal date, positions 3-8, MMDDYY format), broken into mm (month, positions 3-4) and dd (day, positions 5-6).
    • AR200PS2: Contains jrdate (display-only, positions 3-8) and yn (Y/N confirmation, position 3).
    • @sfid: Screen format identifier (S1, S2, or blank for initial state).

  6. Main Processing Loop (dow @sfnex <> 'EJ'):

  7. The program runs in a loop until the screen format next (@sfnex) is set to 'EJ' (end job).
  8. Processes the current screen based on @sfid (screen format identifier):
    • If @sfid is blank, calls $sblk (initial blank screen).
    • If @sfid is 'S1', calls $s1 (process date entry screen).
    • If @sfid is 'S2', calls $s2 (process confirmation screen).
  9. Checks if @sfnex = 'EJ' (set by user cancellation or program completion), and if so, sets *inlr (last record indicator) to *on and jumps to the endit tag to terminate.
  10. Calls $xcpt to display the next screen.

  11. Reads the next screen input:

    • If @sfnex = 'S1', reads AR200PS1 (date entry screen).
    • Otherwise, reads AR200PS2 (confirmation screen).
    • Sets @sfid to match the screen read (S1 or S2).

  12. Subroutine $sblk (Blank Screen, First Time Only):

  13. Initializes variables:

    • kyjrdt = *zero: Clears the journal date.
    • kyyn = *blanks: Clears the confirmation field.
    • msgout = *blanks: Clears the error message.
    • @sfnex = 'S1': Sets the next screen to AR200PS1 (date entry).

  14. Subroutine $s1 (Process Date Entry Screen):

  15. Handles input from AR200PS1 (date entry screen).

  16. Checks the virtual key (@vkey):

    • If @vkey = 0 (Enter key), calls $s1ent to validate the date.
    • If @vkey = 2 (Command key), calls $s1ck to handle function keys.

  17. Subroutine $s1ent (Edit Date Fields):

  18. Validates the journal date (jrdate):

    • Moves kyjrdt (journal date) to mmddyy for validation.
    • Calls @dtedt to validate the date format and correctness.
    • If *in79 = *on (date invalid):
    • Sets msgout = "INVALID DATE".
    • Sets *in50 = *on to display the error on the screen.
    • Jumps to ends1e to redisplay AR200PS1.
    • If valid:
    • Clears msgout.
    • Calls clrind to reset indicators.
    • Sets @sfnex = 'S2' to display the confirmation screen (AR200PS2).

  19. Subroutine $s1ck (Command Key Functions for S1):

  20. Handles function key presses (e.g., F10 or F11, mapped to *inkg).
  21. If *inkg = *on (cancel key):
    • Sets *inu1 = *on (likely sets switch bit U1 for the OCL program).
    • Sets *inlr = *on to end the program.
    • Sets @sfnex = 'EJ' to exit the loop.

  22. Resets indicators *in10 and *in11.

  23. Subroutine $s2 (Process Confirmation Screen):

  24. Handles input from AR200PS2 (confirmation screen).

  25. Checks the virtual key (@vkey):

    • If @vkey = 0 (Enter key), calls $s2ent to process the confirmation.
    • If @vkey = 2 (Command key), calls $s2ck to handle function keys.

  26. Subroutine $s2ent (Edit Confirmation Fields):

  27. Checks the confirmation field (kyyn):

    • If kyyn <> 'Y', calls clrfld to reset fields and sets @sfnex = 'S1' to return to the date entry screen.
    • If kyyn = 'Y', sets @sfnex = 'EJ' to end the program, indicating the date is confirmed.

  28. Subroutine $s2ck (Command Key Functions for S2):

  29. Handles function key presses:

    • If *inka (likely a "back" key), sets @sfnex = 'S1' to return to the date entry screen.
    • If *inkg (cancel key), sets *inu1 = *on, *inlr = *on, and @sfnex = 'EJ' to exit.

  30. Subroutine $xcpt (Display Next Screen):

    • Increments @ccnt (screen counter).
    • If @sfnex = @sfid, sets *in98 to indicate no screen change is needed.
    • Writes the appropriate screen:
    • If @sfnex = 'S1', writes AR200PS1.
    • If @sfnex = 'S2', writes AR200PS2.

  31. Subroutine clrind (Clear Indicators):

    • Resets error and display indicators (*in50, *in81–*in86, *in59) to *off.

  32. Subroutine clrfld (Clear Fields):

    • Resets fields for redisplay:
    • kyjrdt = *zero.
    • kyyn = *blank.
    • msgout = *blanks.
    • @sfnex = 'S1'.

  33. Subroutine @dtedt (Date Edit Routine):

    • Validates the date in mmddyy (MMDDYY format):
    • Extracts month ($month), day ($day), and year ($yr).
    • Checks:
      • Month must be ≤ 12.
      • For February:
      • If year is not 00, checks for leap year by dividing year by 4.
      • If leap year, day must be ≤ 29; otherwise, ≤ 28.
      • If year is 00, combines century (y2kcen) and year, checks for leap year by dividing by 400.
      • For other months:
      • Months with 30 days (April, June, September, November) must have day ≤ 30.
      • Other months must have day ≤ 31.
    • Sets *in79 = *on if any validation fails, indicating an invalid date.

  34. Program Termination:

    • When @sfnex = 'EJ', the program sets *inlr = *on and exits.
    • The U1 indicator (set via *inu1) likely corresponds to the SWITCH1-1 check in the OCL program, signaling cancellation.

Business Rules

The program enforces the following business rules for cash receipts journal date entry: 1. Date Entry and Validation: - The user must enter a journal date in MMDDYY format on the AR200PS1 screen. - The date is validated for: - Valid month (1–12). - Valid day based on the month (e.g., ≤ 30 for April, ≤ 28 or 29 for February depending on leap year). - Leap year calculation for February, accounting for century (Year 2000 compliance). - If the date is invalid, an "INVALID DATE" message is displayed, and the user must re-enter the date.

  1. Confirmation:
  2. After a valid date is entered, the AR200PS2 screen displays the date and prompts for a Y/N confirmation.
  3. If the user enters Y, the program accepts the date and exits (@sfnex = 'EJ').

  4. If the user enters anything other than Y, the program returns to the date entry screen (AR200PS1).

  5. Cancellation:

  6. The user can cancel at either screen using a function key (e.g., *inkg, likely F3 or F12).

  7. Cancellation sets *inu1 = *on (likely setting switch bit U1) and exits the program, signaling the OCL program to cancel further processing.

  8. Screen Flow:

  9. The program starts with a blank state, displays AR200PS1 for date entry, then AR200PS2 for confirmation.

  10. The user can navigate back from AR200PS2 to AR200PS1 using a function key (e.g., *inka).

  11. Error Handling:

  12. Invalid dates trigger an error message and keep the user on AR200PS1.
  13. Indicators are used to control screen display and error states (e.g., *in50 for error display, *in79 for date validation failure).

Tables Used

In RPGLE, "tables" typically refer to database files or display files. The program uses: 1. Display File: AR200PD: - A workstation file for interactive screen handling. - Contains two formats: - AR200PS1: Date entry screen with fields jrdate (MMDDYY), mm (month), dd (day), and msgout (error message). - AR200PS2: Confirmation screen with fields jrdate (display-only), yn (Y/N), and msgout. - Uses the Profound UI handler for modernized display.

  1. No Database Files:
  2. The program does not directly reference any physical or logical files (tables) for data storage or retrieval.
  3. The journal date (kyjrdt) is stored in a data area (uds), not a database file.
  4. It’s likely that the validated date is passed to subsequent programs (e.g., AR200 in the OCL) for updating AR-related tables, but these are not accessed here.

External Programs Called

The RPG program does not explicitly call any external programs using CALL or similar operations. All processing is handled within subroutines: - Subroutines (internal): $sblk, $s1, $s1ent, $s1ck, $s2, $s2ent, $s2ck, $xcpt, clrind, clrfld, @dtedt. - No External Program Calls: Unlike the OCL program, which calls GSGENIEC, SCPROCP, GSY2K, and AR200, this RPG program is self-contained.

Integration with OCL Program

  • The OCL program (AR200P.ocl36.txt) loads and runs AR200P after setting up the environment and checking conditions.
  • The U1 indicator (*inu1) in AR200P likely sets the first switch bit checked by the OCL’s IF SWITCH1-1 CANCEL, allowing cancellation to propagate back to the OCL.
  • The kyjrdt value (journal date) is likely stored in the data area (uds) and used by the subsequent AR200 program called in the OCL for actual cash receipts posting.
  • The ?9? parameter in the OCL’s AR200 ,,,,,,,,?9? may relate to kyjrdt or another value set by AR200P.

Notes

  • Modernization: The use of Handler('PROFOUNDUI(HANDLER)') indicates the program has been modernized for a web or graphical interface using Profound UI, despite being rooted in System/36 or AS/400 conventions.
  • Year 2000 Compliance: The y2kcen and y2kcmp fields and leap year logic reflect Y2K compliance, critical for legacy systems handling dates.
  • Limitations: The program only handles date input and validation, not the actual posting of cash receipts, which is likely handled by AR200 or other programs in the OCL flow.
  • Source Conversion: The T4 prefixes (e.g., T4A, T4M) indicate the program was converted using a tool (TARGET/400), with 33 lines added, 8 modified, and 279 processed, suggesting migration from RPG II or III to RPGLE.

If you have additional context (e.g., the AR200 program, the AR200PD display file definition, or database file structures), I can provide a deeper analysis of the end-to-end process or data flow. Let me know if you need further clarification or specific details!