Skip to content

BI944A RPG36

The provided document, BI944A.rpg36.txt, is an RPG (Report Program Generator) program for the IBM System/36 environment, named BI944A. It is invoked by the OCL script BI944B.ocl36.txt as part of the pricing generation process for blended lubes, initiated by PRICEGEN.clp. The program appears to process contract data from the BICONT file, setting up a key date (KYDAT8) based on the system date and handling century logic for year 2000 (Y2K) compliance. Below, I will explain the process steps, business rules, tables used, and external programs called .

Process Steps of the RPG Program

  1. File Definition:

  2. The F specification defines the BICONT file:

    • Access: Input mode (IF) with fixed-length records of 256 bytes.
    • Type: Disk file, likely a physical file.
    • Indexing: 2AI indicates an indexed file with 2 keys for access.
    • Usage: The file is used for reading contract data, as indicated by the input mode and READ operation.

  3. Input Specifications:

  4. The I specifications define the record format for the BICONT file (record type NS):
    • BCDEL (1): Delete code (likely 'D' for deleted records).
    • BCCO (2–3): Company number.
    • BCNAME (4–33): Company name.
  5. User Data Structure (UDS):
    • KYDAT8 (333–340): An 8-digit field to store a key date (likely in CYMD format, e.g., CCYYMMDD).
    • Y2KCEN (509–510): A 2-digit field for the century (e.g., '19' for 1900s).
    • Y2KCMP (511–512): A 2-digit field for comparison year (e.g., '80' for Y2K pivot year).

  6. These fields are used to manage date processing and Y2K logic.

  7. Initialization:

  8. Z-ADD00 BILIM 20: Initializes BILIM (a 2-digit field) to zero. This field is used as a record limit or counter for the SETLL operation.
  9. BILIM SETLLBICONT: Positions the file pointer at the start of the BICONT file (likely using the index) to prepare for reading records.

  10. READ BICONT 20: Reads the first record from BICONT, setting indicator 20 if the end of file is reached or an error occurs.

  11. Date Processing and Y2K Logic:

  12. Z-ADD*ZERO KYDAT8: Initializes KYDAT8 to zero.
  13. UDATE MULT 10000.01 KYDAT6 60: Converts the system date (UDATE, typically in YYMMDD format) to a 6-digit field (KYDAT6) by multiplying by 10000.01. This operation is unusual and may be a workaround to format the date, though it could result in a value like YYMMDD.00.
  14. Z-ADDKYDAT6 KYDAT8: Moves KYDAT6 to KYDAT8 (8 digits), likely to store the date in CYMD format.
  15. Y2K century logic:
    • UYEAR IFGE Y2KCMP B2: Checks if the system year (UYEAR, 2 digits) is greater than or equal to Y2KCMP (e.g., '80').
    • If true: Z-ADDY2KCEN UCN 20 sets UCN (2 digits) to Y2KCEN (e.g., '19' for 1900s).
    • If false: 1 ADD Y2KCEN UCN increments Y2KCEN by 1 (e.g., '19' becomes '20' for 2000s).
    • MOVELUCN KYDAT8 80: Moves the century (UCN) into the first two digits of KYDAT8, forming a full CYMD date (e.g., 19YYMMDD or 20YYMMDD).

  16. This logic ensures the date in KYDAT8 is Y2K-compliant by adding the correct century.

  17. Program Termination:

  18. SETON LR: Sets the Last Record indicator (LR), signaling the end of the program. This ensures the program terminates after processing the date logic, likely because it only needs to set up KYDAT8 for use by subsequent programs or processes.

Business Rules

  1. Purpose: The program processes the BICONT file to initialize a key date (KYDAT8) for use in the pricing generation process, ensuring Y2K-compliant date handling by determining the correct century (1900s or 2000s) for the system date.
  2. Date Processing:
  3. The system date (UDATE, YYMMDD) is converted to a Y2K-compliant 8-digit date (KYDAT8, CCYYMMDD).
  4. The century is determined by comparing the system year (UYEAR) to a pivot year (Y2KCMP, e.g., '80'):
    • If UYEAR ≥ Y2KCMP, use Y2KCEN (e.g., '19' for 1900s).
    • If UYEAR < Y2KCMP, use Y2KCEN + 1 (e.g., '20' for 2000s).
  5. File Access: The program reads the BICONT file but does not modify it, suggesting it may validate the file’s existence or prepare for subsequent processing by other programs.
  6. Context in Pricing Generation: As part of the BI944B process (within PRICEGEN.clp), BI944A likely sets up date parameters for contract-related pricing data, which are used by later programs (BI9443, BI9444, BI944) to populate ?9?BICUAGP with blended lubes pricing.
  7. Minimal Record Processing: The program reads only one record from BICONT (or positions the file pointer), indicating it may primarily serve to initialize KYDAT8 rather than process all contract records.

Tables (Files) Used

  • BICONT: The only file explicitly used in the program.
  • Access: Input mode (IF), shared read mode with record locking (DISP-SHRRM from the OCL script).
  • Purpose: Read contract data (company number, name, delete code) to position the file or validate its existence.
  • Label: ?9?BICONT (e.g., ABICONT if &P$GRP = 'A' from PRICEGEN.clp).

External Programs Called

  • None: The BI944A RPG program does not explicitly call any external programs or subroutines within the provided code. It performs internal logic to set up KYDAT8 and terminates.

Additional Notes

  • Context with BI944B.ocl36: The BI944A program is invoked by BI944B.ocl36 as the first program after clearing ?9?BICUAGP. It likely prepares date parameters for subsequent steps in the blended lubes pricing process, using ?9?BICONT (e.g., ABICONT).
  • Y2K Compliance: The program’s focus on century logic reflects its design to handle dates around the year 2000 transition, ensuring correct century prefixes (e.g., 19 or 20) for dates in KYDAT8.
  • Limited Functionality: The program’s minimal logic (reading one record, setting a date, and terminating) suggests it is a preparatory step, possibly validating the BICONT file or setting a global date parameter in the user data structure (UDS) for use by later programs.
  • System/36 Environment: The use of RPG II/III and OCL indicates a legacy System/36 environment, possibly running on an AS/400 in compatibility mode.
  • Potential Issues: The UDATE MULT 10000.01 KYDAT6 operation is unusual and may not produce the expected result (e.g., converting YYMMDD to a usable format). It could be a typo or a System/36-specific convention, but typically, UDATE is already in YYMMDD format, and the multiplication may be unnecessary or incorrect.
  • Error Handling: The program lacks explicit error handling for file access or invalid data, relying on the System/36 environment or the calling OCL (BI944B.ocl36) to manage errors.

If you have the RPG source code for BI9443, BI9444, BI944, or the remaining procedures (BI942E, PRICES), or need further analysis of how BI944A integrates with the pricing generation workflow, please provide those details! Let me know if you have additional questions or files to share.