GS9294 RPGLE

The RPG program GS9294 is designed to inactivate or reactivate product load records within an IBM i (AS/400) environment. It is called from the main program GS929P to toggle the status of a product load record between active ('A') and inactive ('I') using a display file interface. The program provides a confirmation window (actwdw) for the user to approve the action. Below, I outline the process steps, business rules, database tables used, and external programs called.

Process Steps of GS9294¶

The program follows a structured flow to manage the inactivation or reactivation of product load records. The steps are organized around the mainline logic and subroutines:

1. **Initialization (*INZSR Subroutine)**¶

Purpose: Sets up initial parameters and variables.
Steps:
- Receives input parameters:
- p$cono: Company number.
- p$loc: Loading location.
- p$prod: Product code.
- p$cntr: Container code.
- p$prty: Loading priority.
- p$seq#: Sequence number.
- p$racd: Responsibility area code.
- p$mlcd: Major location code.
- p$type: Product type.
- p$fgrp: File group ('Z' or 'G').
- p$flag: Return flag (output, indicates 'A' for reactivated or 'I' for inactivated).
- Defines format fields (f$) to match input parameters and key list (klprdlod) for database access.
- Moves input parameters to format fields (f$cono, f$loc, etc.) for use in the key list.
- Initializes the window processing flag (winagn = *on) to enter the main processing loop.
- Sets up message handling fields (dspmsg, m@pgmq, m@key) and a parameter list (pld010) for potential date validation (not used in the provided code).
- Initializes the display file data structure (dspf_ds) for screen interaction.

2. Open Database Tables (opntbl Subroutine)¶

Purpose: Opens the prdlod1 file with the appropriate file override.
Steps:
- Checks if p$fgrp is 'G' or 'Z'.
- Applies the corresponding file override from the ovg (for 'G') or ovz (for 'Z') array using the QCMDEXC system API to override prdlod1 to gprdlod1 or zprdlod1.
- Opens the prdlod1 file (update/add mode, UF A, user-opened).

3. Retrieve Data (rtvdta Subroutine)¶

Purpose: Retrieves the product load record and sets up the confirmation window.
Steps:
- Chains to prdlod1 using the key list klprdlod to retrieve the record.
- If the record is found (*in99 = *off):
- Checks the delete flag (pddel):
  - If pddel = 'I' (inactive):
  - Sets the window header (f$hdr) to "Product/Load Entry ReActivate" (hdr(01)).
  - Sets the function key label (f$fkyd) to "F22=ReActivate" (fky(01)).
  - Enables indicator *in72 to highlight the reactivation option.
  - If pddel ≠ 'I' (active):
  - Sets the window header to "Product/Load Entry InActivate" (hdr(02)).
  - Sets the function key label to "F23=InActivate" (fky(02)).
  - Enables indicator *in73 to highlight the inactivation option.

4. Process Window (prcwdw Subroutine)¶

Purpose: Manages the confirmation window (actwdw) for user interaction.
Steps:
- Enters a loop (winagn) to process the window until the user exits or confirms an action:
- Displays the message subfile if needed (wrtmsg) or clears the screen (msgclr).
- Displays the confirmation window using EXFMT actwdw.
- Clears the message subfile if displayed (clrmsg).
- Resets error indicators (*in50-*in69).
- Processes user input based on the function key pressed:
  - F12: Exits the window by setting winagn to *off, leaving p$flag unchanged.
  - F22 or F23: Validates input (winedt) and updates the database (winupd) if no errors (*in50 = *off), then exits the loop.
  - Other (e.g., Enter): Validates input (winedt) and redisplays the window if errors exist.

5. Edit Window Input (winedt Subroutine)¶

Purpose: Validates user input in the confirmation window.
Steps:
- Calls chkact to perform validation (the subroutine is empty in the provided code, indicating no additional checks are implemented).
- No explicit validation logic is present, so the subroutine effectively passes control to winupd when F22 or F23 is pressed.

6. Check Activity (chkact Subroutine)¶

Purpose: Intended to check activity prior to inactivation/reactivation.
Steps:
- The subroutine is empty in the provided code, suggesting no specific checks (e.g., for dependent records or constraints) are performed before updating the record status.

7. Update Database (winupd Subroutine)¶

Purpose: Updates the prdlod1 record’s status based on the user’s action.
Steps:
- Processes based on the function key:
- F22 (ReActivate):
  - Chains to prdlod1 using klprdlod.
  - If the record exists (*in99 = *off) and is inactive (pddel = 'I'):
  - Sets pddel to 'A' (active).
  - Updates the prdlodpf record.
  - Sets p$flag to 'A' to indicate successful reactivation.
- F23 (InActivate):
  - Chains to prdlod1 using klprdlod.
  - If the record exists (*in99 = *off) and is not already inactive (pddel ≠ 'I'):
  - Sets pddel to 'I' (inactive).
  - Updates the prdlodpf record.
  - Sets p$flag to 'I' to indicate successful inactivation.
- If the record does not exist or the status condition is not met, no update is performed, and p$flag remains unchanged.

8. Message Handling (addmsg, wrtmsg, clrmsg Subroutines)¶

addmsg: Sends messages to the program message queue using QMHSNDPM (not used in the provided logic, as no errors are explicitly raised).
wrtmsg: Writes the message subfile (msgctl) for display.
clrmsg: Clears the message subfile using QMHRMVPM.

9. Program Termination¶

Closes all files (prdlod1, gs9294d) and sets *inlr to *on to end the program.

Business Rules¶

The program enforces the following business rules:

Record Existence:
The product load record, identified by the key fields (p$cono, p$loc, p$prod, p$cntr, p$prty, p$seq#, p$racd, p$mlcd, p$type), must exist in prdlod1 for any action to be performed.
Status Transition:
Reactivation (F22): Only records with a delete flag (pddel) of 'I' (inactive) can be reactivated. The flag is updated to 'A' (active), and p$flag is set to 'A'.
Inactivation (F23): Only records with a delete flag not equal to 'I' (typically 'A' for active) can be inactivated. The flag is updated to 'I', and p$flag is set to 'I'.
User Confirmation:
The user must confirm the action via the actwdw window using F22 (reactivate) or F23 (inactivate). No action is taken without explicit confirmation.
File Group Handling:
The file group (p$fgrp) determines whether the program accesses gprdlod1 ('G') or zprdlod1 ('Z'), ensuring the correct file is used.
No Additional Validation:
The empty chkact subroutine suggests no additional business rules (e.g., checking for dependent records or constraints) are enforced before changing the record status.
Error Handling:
The program does not generate error messages in the provided code (no calls to addmsg), relying on the calling program (GS929P) to handle any validation errors.

Database Tables Used¶

The program interacts with the following database file: 1. prdlod1: Product load file (update/add mode, UF A, user-opened). - Overrides to gprdlod1 or zprdlod1 based on p$fgrp ('G' or 'Z').

External Programs Called¶

The program calls the following external programs: 1. QCMDEXC: Executes the file override command for prdlod1 in the opntbl subroutine. 2. QMHSNDPM: Sends messages to the program message queue (defined in addmsg, but not used in the provided logic). 3. QMHRMVPM: Removes messages from the program message queue (clrmsg).

Summary¶

GS9294 is a focused RPG program called by GS929P to inactivate or reactivate product load records in the prdlod1 file. It presents a confirmation window (actwdw) to the user, allowing them to toggle the record’s status between active ('A') and inactive ('I') using function keys F22 and F23. The program enforces simple business rules to ensure the record exists and is in the appropriate state before updating, with no additional validation checks in the provided code. It interacts with a single database file and uses system APIs for file overrides and message handling, relying on the calling program for input validation and error messaging.