Skip to content

BIFX44 RPG36

The provided document, BIFX44.rpg36.txt, is an RPG (Report Program Generator) program for the IBM System/36 environment, named BIFX44. It is invoked by the OCL script BIFX44.ocl36.txt and is part of the pricing generation process initiated by PRICEGEN.clp. The program’s primary purpose is to update the "Last Update Date and Time" fields (BALUDT and BALUTM) in the BICUAG file with the "Creation Date and Time" (BACRDT and BACRTM) when the last update date is older than the creation date, typically when an old (prior) record is copied. 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 BICUAG file:

    • Access: Update mode (UP) with fixed-length records of 256 bytes.
    • Type: Disk file, likely a physical file.
    • Usage: The file is used for both input (reading records) and output (updating records), as indicated by the update mode and the O (output) specification.

  3. Input Specifications:

  4. The I specifications define the record format for the BICUAG file (record type NS 01). The fields are mapped to specific positions in the 256-byte record, identical to those in BIFX43.rpg36.txt:

    • BADEL (1): Delete code.
    • BACONO (2–3): Company.
    • BACUST (4–9): Customer number.
    • BALOC (10–12): Location.
    • BAPR01 to BAPR10 (13–52): Product codes 1 to 10.
    • BASTDT (53–59): Start date (YMD format).
    • BASTTM (60–63): Start time (HM format).
    • BAENDT (64–70): End date (YMD format).
    • BAENTM (71–74): End time (HM format).
    • BAPRCE (75–80.4): Price (4 decimal places).
    • BAOFFP (81–86.4): Off-price (4 decimal places).
    • BAMNGL (87–93): Minimum gallons/month.
    • BAMXGL (94–100): Maximum gallons/month.
    • BAPPD (101): Prepaid sale indicator (P or blank).
    • BAALSH (102): Apply to all ship-to (Y, N, or blank).
    • BAPRIM (106): Pricing at invoice or end of month (I, M, or blank).
    • BASTD8 (118–125): Start date (CYMD format).
    • BAEND8 (126–133): End date (CYMD format).
    • BADELV (134): Delivery indicator (Y, N, or blank).
    • BAFRCD (135): Freight code (C, P, A, or blank).
    • BACRDT (136–143): Creation date (CYMD format).
    • BACRTM (144–149): Creation time (HMS format).
    • BALUDT (150–157): Last update date (CYMD format).
    • BALUTM (158–163): Last update time (HMS format).
    • BACNTR (164–166): Container code.
    • BASHIP (167–169): Ship-to number.
    • BACNT# (170–180): Contract number.
    • BAUNMS (181–183): Unit of measure.

  5. Initialization (One-Time Setup):

  6. The C (calculation) specifications include a one-time initialization block controlled by the ONCE indicator:

    • Condition: ONCE IFEQ *ZEROS checks if the ONCE field (a 10-digit numeric variable) is zero, indicating the first execution.
    • Actions:
    • Increment ONCE by 1 to prevent re-execution.
    • Use the TIME operation to retrieve the current system date and time into TIMDAT (12 digits, likely YYMMDDHHMMSS).
    • Move the time portion (first 6 digits of TIMDAT) to SYSTIM (6 digits: HHMMSS).
    • Move the date portion (first 6 digits of TIMDAT) to SYSDAT (6 digits: YYMMDD).
    • This block captures the system date and time, but SYSTIM and SYSDAT are not used in the provided code, suggesting this may be a template or unused functionality.

  7. Record Processing:

  8. The program processes records from the BICUAG file (indicated by the 01 indicator for the NS 01 record type).
  9. For each record, it checks the following conditions:
    • BALUDT IFNE *ZEROS: The last update date is not blank/zero.
    • BACRDT IFNE *ZEROS: The creation date is not blank/zero.
    • BALUDT IFLT BACRDT: The last update date is earlier than the creation date.

  10. If all conditions are true (i.e., the record has a valid creation date and a last update date that is older than the creation date), the program executes an EXCPT operation to update the record.

  11. Output/Update Operation:

  12. The O (output) specifications define an exception output (E) for the BICUAG file:
    • Fields BACRDT and BACRTM are written to positions 150–157 and 158–163, respectively, which correspond to BALUDT and BALUTM in the input record.
    • The B in the output specification indicates that these fields are written only if both input and output values are non-blank/non-zero.
  13. This updates the BALUDT and BALUTM fields with the values of BACRDT and BACRTM, respectively, correcting cases where the last update date/time is older than the creation date/time.

Business Rules

  1. Purpose: The program updates the BALUDT (Last Update Date) and BALUTM (Last Update Time) fields in the BICUAG file with the BACRDT (Creation Date) and BACRTM (Creation Time) when the last update date is older than the creation date. This typically occurs when an old (prior) record is copied, resulting in an outdated last update timestamp.
  2. Condition for Update:
  3. The record must have:
    • BALUDT ≠ blank/zero (has a last update date).
    • BACRDT ≠ blank/zero (has a valid creation date).
    • BALUDT < BACRDT (last update date is earlier than creation date).
  4. This ensures updates occur only for records where the last update date is incorrectly older than the creation date, indicating a copied or re-used record.
  5. Field Mapping:
  6. BACRDT → BALUDT (copy creation date to last update date).
  7. BACRTM → BALUTM (copy creation time to last update time).
  8. Non-Destructive Update: Only the BALUDT and BALUTM fields are updated; other fields in the record remain unchanged.
  9. Context in Pricing Generation: As part of the PRICEGEN process, BIFX44 follows BIFX43 (which sets BALUDT and BALUTM to BACRDT and BACRTM for new records with blank last update fields). BIFX44 corrects records where the last update date is older than the creation date, ensuring timestamp consistency for pricing records.

Tables (Files) Used

  • BICUAG: The only file explicitly used in the program.
  • Access: Update mode (UP).
  • Purpose: Read records, check conditions, and update BALUDT and BALUTM fields when the last update date is older than the creation date.
  • Label: As defined in the OCL script (?9?BICUAG), the file name is dynamic (e.g., ABICUAG if &P$GRP = 'A' from PRICEGEN.clp).

External Programs Called

  • None: The BIFX44 RPG program does not explicitly call any external programs or subroutines within the provided code. It operates solely on the BICUAG file and performs internal logic.

Additional Notes

  • Comparison with BIFX43: The BIFX44 program is similar to BIFX43 (from the prior query) in structure and purpose, both updating BALUDT and BALUTM in the BICUAG file. However:
  • BIFX43 targets new records where BALUDT and BALUTM are blank/zero, setting them to BACRDT and BACRTM.
  • BIFX44 targets existing records where BALUDT is older than BACRDT, updating BALUDT and BALUTM to match BACRDT and BACRTM.
  • Together, they ensure consistent timestamps for both new and copied records in the pricing generation process.
  • System/36 Context: The program runs in a System/36 environment (or AS/400 in compatibility mode), as indicated by the OCL script and RPG II/III syntax. It is part of the PRICEGEN workflow, invoked after BIFX43 and before BI944B, BI942E, and PRICES.
  • Parameter Integration: The ?9? in the OCL file label (?9?BICUAG) corresponds to the &P$GRP parameter (e.g., 'A') passed via &PARM9 from PRICEGEN.clp, ensuring the correct file (e.g., ABICUAG) is processed.
  • Data Integrity: The program corrects timestamp inconsistencies, which is critical for auditing or tracking changes in pricing records, especially when records are copied from older data.
  • Limitations: The SYSDAT and SYSTIM fields (from the TIME operation) are not used, suggesting the initialization block may be a template or unused functionality. The program lacks explicit error handling for file access or invalid data, relying on the System/36 environment or PRICEGEN.clp for error management.

If you have the RPG or OCL source code for BI944B, BI942E, or PRICES, or need further analysis of how BIFX44 integrates with the pricing generation workflow, please provide those details! Let me know if you have additional questions or files to share.