Skip to content

AR291 RPG36

The AR291.rpg36.txt is an RPG (Report Program Generator) program for IBM System/36, invoked by the AR290.ocl36.txt OCL program to update salesman codes in batch order files (BBOR01 to BBOR98). Below is a detailed explanation of the process steps, business rules, tables/files used, and any external programs called.

Process Steps of the AR291 RPG Program

The AR291 RPG program updates salesman codes from an old code (ASSLSO) to a new code (ASSLSN) in the batch order file (BBORTR, dynamically representing BBOR01 to BBOR98) for records matching specific customer and company numbers. Here’s a step-by-step breakdown:

  1. Initialization (Lines 0034–0041):
  2. ONCE Routine: Executes once at program start (controlled by ONCE flag set to 1).
    • Captures the current time (TIMEX, 12 digits) and moves it to:
    • TIMEOF (6 digits, HHMMSS) for potential logging.
    • DATE (6 digits, likely MMDDYY or YYMMDD, depending on system format).

  3. Purpose: Sets up timestamp data, though it’s not used in output in this program (possibly for future logging or compatibility).

  4. Main Processing Loop (Lines 0044–0050):

  5. Loop Control: Processes each record in the ARSLST file (salesman change transaction file) where the delete flag (ASDEL) is not set (NCD condition, record type 01).
  6. Subroutines Called:
    • ARCUST: Validates the customer in the customer master file.
    • BBORTR: Updates the salesman code in the batch order file (BBORTR).

  7. Condition: The BBORTR subroutine is executed only if the customer record is found in ARCUST (N90 condition, i.e., ASKEY exists).

  8. ARCUST Subroutine (Lines 0057–0065):

  9. Process:
    • Chains (searches) the ARCUST file using ASKEY (company and customer number from ARSLST).
    • If the customer is found (N90), no updates are made to ARCUST in this program (unlike AR290).
    • If the old salesman code (ASSLSO) is zero, sets it to the current salesman code (SLMN) from ARCUST for tracking.

  10. Purpose: Validates the customer and ensures the old salesman code is populated for reference, even though ARCUST is not updated in this program.

  11. BBORTR Subroutine (Lines 0068–0092):

  12. Process:
    • Initializes a key (KEY11, 11 bytes) to blank and sets the lower limit (SETLL) on the BBORTR file to position the file pointer.
    • Enters a loop (AGNBBO tag):
    • Reads BBORTR records sequentially until no more records are found (91 indicator).
    • For each record:
      • Checks if the company (CO) matches ASCO and the customer (CUST) matches ASCUST from ARSLST.
      • If matched, updates the salesman code (SLSM) to the new code (ASSLSN) and writes the updated record (EXCPT BBO).
      • Increments the counter ASORT to track the number of updated records.
    • Loops back to read the next record (GOTO AGNBBO).

  13. Purpose: Updates the salesman code in the batch order file for matching records.

  14. Update ARSLST Counter (Lines 0099–0100):

  15. Process:
    • For each ARSLST record processed (01N90), updates the record (EXCPT) with the count of updated batch order records (ASORT).
  16. Purpose: Tracks the number of updates for reporting in the AR299 program.

Business Rules

  1. Update Criteria:
  2. Updates are applied to BBORTR records where the company number (CO) and customer number (CUST) match the ARSLST record’s ASCO and ASCUST.
  3. Prior to the MG04 change (09/26/2017), updates also required the salesman code (SLSM) to match the old salesman code (ASSLSO). This check was commented out, so updates now depend only on customer and company numbers.

  4. The new salesman code (ASSLSN) replaces the existing salesman code (SLSM) in the BBORTR file.

  5. File Scope:

  6. The program processes one batch order file at a time (BBORTR, representing BBOR01 to BBOR98), as invoked by the OCL program’s loop.

  7. The ARCUST file is used for validation only, not updated.

  8. Error Handling:

  9. If a customer record is not found in ARCUST (90 indicator), no updates are performed in BBORTR for that customer.

  10. Records in ARSLST marked for deletion (ASDEL) are skipped.

  11. Audit and Tracking:

  12. The ASORT counter tracks the number of records updated in BBORTR and is stored in ARSLST for reporting.

  13. Data Integrity:

  14. The BBORTR file is opened in update mode (UF) with shared access (from OCL DISP-SHRMM), allowing concurrent access while ensuring updates are committed.
  15. The program uses SETLL and READ for sequential processing, ensuring all matching records are updated.

Tables/Files Used

The program interacts with the following files, as defined in the File Specification (F-spec) and used in processing: 1. ARSLST (Input/Update, 256 bytes, Key: 8 bytes): - Salesman change transaction file containing company number (ASCO), customer number (ASCUST), old salesman code (ASSLSO), new salesman code (ASSLSN), and a counter for batch order updates (ASORT). 2. ARCUST (Input, 384 bytes, Key: 8 bytes): - Customer master file, used to validate customers and retrieve the current salesman code (SLMN) if ASSLSO is zero. 3. BBORTR (Update, 512 bytes, Key: 11 bytes): - Batch order file (represents BBOR01 to BBOR98), updated with the new salesman code (SLSM).

External Programs Called

  • None: The AR291 RPG program does not call any external programs. It is a standalone program invoked by the AR290.ocl36.txt OCL program and performs all processing internally through its subroutines.

Additional Notes

  • File Modifications:
  • MG04 (09/26/2017): Removed the salesman code comparison (SLSM IFEQ ASSLSO), making updates based solely on customer and company numbers, aligning with the change in AR290.
  • Performance Considerations:
  • The program processes BBORTR sequentially using SETLL and READ, typical for System/36 but potentially slow for large datasets.
  • Shared access (DISP-SHRMM in OCL) ensures concurrent access but requires careful transaction management.
  • Legacy Context:
  • This RPG III program is designed for the IBM System/36 or AS/400, using fixed-format code with cycle-based processing.
  • The use of EXCPT for output and CHAIN for random access is standard for RPG on this platform.
  • Role in OCL:
  • AR291 is called repeatedly by the OCL program for each batch file (BBOR01 to BBOR98), handling one file per invocation.

This program ensures consistent salesman code updates in batch order files, validates customers against the master file, and tracks update counts for reporting, supporting the accounts receivable system’s need for accurate salesman assignments.