Skip to content

GS800 RPG36

The provided document is an RPG (Report Program Generator) III program named GS800 for the IBM System/36 or AS/400, used for table file maintenance. It is called from the OCL program (GS800.ocl36.txt) previously provided. Below, I will explain the process steps, business rules, tables used, and external programs called, based on the RPG code and the context from the OCL program.

Process Steps of the GS800 RPG Program

The GS800 RPG program is designed to maintain various types of table records (e.g., product codes, container codes, sales manager data) through a series of interactive screens. The program uses a workstation file (SCREEN) for user interaction and processes data stored in multiple table files. Here’s a breakdown of the process steps:

  1. Initialization:
  2. Header (H-Spec): The program is defined with P064 (likely a program identifier or parameter) and named GS800 (line 0002).
  3. File Definitions (F-Specs): Defines files (tables) and a workstation file for screen interaction (lines 0015–0021):
    • SCREEN: Workstation file for interactive display (1000-byte record length).
    • GSTABL, GSTABLX, GSTABLY, GSTABLZ, GSPROD, GSCNTR: Disk files for data storage and retrieval, with specific record lengths and key structures.
  4. Data Structures and Arrays (E-Specs): Defines arrays (e.g., CD, DS, DL for codes, descriptions, delete codes) and fields for specific record types (lines 0022–0040).
  5. System Date/Time Handling: Retrieves system date and time, formats them into SYSDAT, SYSTIM, and DATTIM for use in records (lines 0197–0199, MG09 modifications).

  6. Indicator Initialization: Resets various indicators (e.g., 40–43, 81–83, 90) to control program flow and error handling (lines 0201–0205).

  7. Main Processing Loop:

  8. The program operates in a loop controlled by indicators and screen interactions (lines 0210–0254).
  9. Roll Forward/Backward (ROLLFW/ROLLBW): Handles scrolling through records (lines 0207–0208, 0258–0284):
    • ROLLFW: Moves to the next set of records in GSTABLX using SETLL and calls GETTAB to populate the screen (S2).
    • ROLLBW: Redisplays the first 15 entries of the selected type in GSTABLX, not a true backward roll but a reset to the start.

  10. Screen Processing:

    • The program uses multiple screens (S1–S8, SA, SB) to handle different record types, invoked based on user input and indicators (lines 0233–0253).
    • Each screen subroutine (e.g., S1, S2, S3, etc.) handles specific tasks like displaying, validating, or updating records.

  11. Screen Subroutines:

  12. S1 (Key Screen): Allows the user to enter a record type (e.g., TYPE, APTERM, ARTERM, PRODCD, etc.) and validates it (lines 0286–0319). If invalid (e.g., BBCAID, PRODCD, CNTRCD after specific updates), it displays an error message and prevents maintenance (JB11, JB13, JB15 modifications).
  13. S2 (List Screen): Displays a list of records for the selected type, using arrays to show codes, descriptions, and other fields (e.g., discount, net days for APTERM/ARTERM) (lines 0236–0237).
  14. S3 (Default Add/Update Screen): Used for TYPE, APTERM, ARTERM, and other types with only a description field. Validates description and other fields (lines 0239–0240).
  15. S4 (PRODCD Screen): Handles product code records, validating fields like description, product group, class, VCF code, fluid code, STCC code, inactive date, and report-as-sales flag (lines 0242–0243, JB01, JB03, JB08, VV01, MG01).
  16. S5 (INCOUN, PRODGR Screen): Manages inventory count and product group records, validating description and unit type (lines 0245–0246).
  17. S6 (PRODCL Screen): Manages product class records, validating description and sort code (lines 0248–0249).
  18. S7 (CNTRCD Screen): Manages container code records, validating container code (non-zero), description, container type, source, and IMS unit of measure (lines 0251–0252, JB04, JB14).
  19. S8 (SLSMGR Screen): Manages sales manager records, validating salesman numbers against SLSMAN records in GSTABLZ (lines 0251–0252).
  20. SA (BIUNMS Screen): Manages BIUNMS records, validating description and fluid code (JB05, lines 0251–0252).

  21. SB (CNTRPF Screen): Manages CNTRPF records, validating description and sales G/L prefix (MG06, lines 0251–0252).

  22. Validation and Error Handling:

  23. Each screen subroutine includes validation logic (e.g., checking for blank descriptions, valid codes, or specific values like Y/N for fluid code).
  24. Errors trigger specific indicators (e.g., 83, 90) and display error messages from the COM section (lines 0893–end).

  25. Examples:

    • S4: Validates product code range (0001–9999), company range (01–98), and date formats (JB03).
    • S7: Ensures container code is non-zero (JB14) and validates container source and IMS unit of measure (JB04).
    • S8: Checks salesman numbers against valid SLSMAN records.

  26. Record Add/Update:

  27. For each screen, after validation, the program chains to the appropriate file (e.g., GSPROD for PRODCD, GSCNTR for CNTRCD) to add or update records (e.g., lines 0712, 0797).

  28. Clears the screen and resets to the list screen (S2) after processing (e.g., lines 0715–0722, 0802–0809).

  29. Date Validation (@DTEDT):

  30. A dedicated subroutine validates dates (e.g., inactive date in S4) by checking month, day, and leap year rules (JB03, lines 0726–end).

  31. Handles Y2K compliance by determining the century for dates (lines JB03).

  32. Exit Processing:

  33. The program exits when the user presses a function key (e.g., F3, mapped to indicator KG) or completes an action, setting the LR (Last Record) indicator and jumping to the END tag (lines 0223–0231).

Business Rules

The GS800 program enforces several business rules, primarily through validation logic in the screen subroutines. These rules ensure data integrity and compliance with system requirements. Key rules include:

  1. General Rules:
  2. Description Mandatory: For most record types, the description field (DESC) cannot be blank (e.g., lines 0729, 0761, 0784, JB05, MG06). Violation triggers error message COM,3 ("Description May Not Be Blank").
  3. Type Validation: The TYPE field must match predefined values (e.g., TYPE, APTERM, ARTERM, PRODCD, PRODGR, PRODCL, CNTRCD, INCOUN, SLSMGR, BIUNMS, CNTRPF). Invalid types trigger COM,1 ("Invalid Type Entered").

  4. Restricted Types: Certain types (BBCAID, PRODCD, CNTRCD) are no longer maintained in GS800 and are handled by other programs (e.g., BB905, GS916 series) (JB11, JB13, JB15). Attempts to maintain these types trigger errors (COM,31, COM,32, COM,34).

  5. Screen-Specific Rules:

  6. S1 (Key Screen):
    • Validates the entered type against allowed values (lines 0295–0303).
    • For TYPE, checks code length (1–6) and data type (A=Alpha, N=Numeric) (lines 0307–0319).
  7. S2 (List Screen):
    • Displays up to 12 records with codes, descriptions, and type-specific fields (e.g., discount, net days for APTERM/ARTERM) (lines 0900–0914).
  8. S3 (Default Add/Update):
    • Used for types with only a description or minimal fields (e.g., TYPE, APTERM, ARTERM).
    • Validates terms percentages for ARTERM (must total 100%, COM,17).
  9. S4 (PRODCD Screen):
    • Product code must be in range 0001–9999 (COM,7).
    • Company code must be 01–98 (COM,8).
    • VCF code must exist in INVCF type (COM,20, JB01).
    • Fluid code must be Y, N, or blank (COM,21, VV01).
    • Report-as-sales (RPSL) must be Y, N, or blank (COM,26, JB08).
    • Inactive date must be valid (checked via @DTEDT, COM,22, JB03).
    • Product class and inventory group cannot be blank (COM,27, COM,28, MG10).
  10. S5 (INCOUN, PRODGR):
    • Unit type (UNTY) must be B or blank (COM,18).
  11. S7 (CNTRCD):
    • Container code (CTRCOD) cannot be zero (COM,33, JB14).
    • Container type (CNTY) must be B (Bulk) or P (Packaged) (COM,16).
    • Container source (CTRS) must be valid or blank (COM,23, JB04).
    • IMS unit of measure (IUM) is required for packaged containers and must exist in BIUNMS (COM,24, JB04).
  12. S8 (SLSMGR):
    • Salesman numbers (SLS#) must exist in SLSMAN records in GSTABLZ (COM,19).
  13. SA (BIUNMS):
    • Fluid code (FLCD) must be Y or N (COM,21).

  14. SB (CNTRPF):

    • Sales G/L prefix (SGL#4) cannot be zero (COM,25, MG06).

  15. Date Validation:

  16. The @DTEDT subroutine validates dates by checking:

    • Month (1–12, COM,22 if invalid).
    • Day (1–31, or 1–28/29 for February, accounting for leap years).
    • Leap year calculation for February (divisible by 4 for non-century years, or 400 for century years) (JB03).

  17. Data Integrity:

  18. Records are checked for existence before update/add using CHAIN operations (e.g., lines 0712, 0797).
  19. Deleted records are flagged with TBDEL, TPDEL, or TCDEL (lines 0106, 0164, etc.).

  20. Y2K compliance is handled by determining the century for dates (JB03).

  21. Error Handling:

  22. Errors set indicators (e.g., 83, 90) and display messages from the COM section (lines 0893–end).
  23. After an error, the program typically clears the screen and returns to the list screen (S2) (e.g., lines 0715–0722).

Tables Used

The RPG program uses the following files (tables), as defined in the F-Specs (lines 0015–0021) and referenced in the OCL program: 1. GSTABL: Primary table file (256 bytes, indexed, 12-byte key, alternate index). 2. GSTABLX: Index file for GSTABL (256 bytes, 12-byte key, alternate index). 3. GSTABLY: Additional index file (256 bytes, 12-byte key, alternate index). 4. GSTABLZ: Additional table file (256 bytes, 12-byte key, alternate index). 5. GSPROD: Product file (512 bytes, 6-byte key, alternate index), used for PRODCD records. 6. GSCNTR: Container file (512 bytes, 3-byte key, alternate index), used for CNTRCD records.

External Programs Called

The GS800 RPG program does not explicitly call external programs. There are no CALL operations or references to other RPG or CL programs in the provided code. The program operates self-contained, relying on its subroutines (e.g., S1, S2, GETTAB, @DTEDT) and file operations to perform its tasks.

However, the comments indicate that certain record types (BBCAID, PRODCD, CNTRCD) are now maintained by other programs: - BBCAID: Maintained in the BB905 series (JB11). - PRODCD: Maintained in the GS916 series (JB13). - CNTRCD: Maintained elsewhere (unspecified program, JB15).

These are not called directly by GS800 but are referenced as part of the business rules to prevent maintenance of these types within GS800.

Summary

  • Process Steps:
  • Initialize system date/time, files, and indicators.
  • Enter a main loop to handle user interactions via screens (S1–S8, SA, SB).
  • Validate user input based on record type and specific fields.
  • Add or update records in the appropriate files (GSTABL, GSPROD, GSCNTR).
  • Handle scrolling (ROLLFW/ROLLBW) and redisplay the list screen (S2) after actions.

  • Exit on user command (e.g., F3) or error.

  • Business Rules:

  • Mandatory fields (e.g., description, specific codes).
  • Restricted types (BBCAID, PRODCD, CNTRCD not allowed in GS800).
  • Specific validations for each record type (e.g., product code range, container type, salesman validation).
  • Date validation for inactive dates, including leap year checks.

  • Error messages for invalid inputs, with screen reset after errors.

  • Tables Used:

  • GSTABL, GSTABLX, GSTABLY, GSTABLZ, GSPROD, GSCNTR.

  • External Programs Called:

  • None directly called. References to BB905 and GS916 series for specific types, but no direct invocation.

If you need a deeper analysis of specific subroutines, field mappings, or additional context (e.g., the GETTAB subroutine or screen layouts), please provide the relevant details or clarify the scope!