Skip to content

AR295 RPG36

The AR295.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 invoice transaction files (BBTRXX, representing workstation-specific files). Below is a detailed explanation of the process steps, business rules, tables/files used, and any external programs called.

Process Steps of the AR295 RPG Program

The AR295 RPG program updates salesman codes from an old code (ASSLSO) to a new code (ASSLSN) in the invoice transaction file (BBTRAN) 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.
    • BBTRAN: Updates the salesman code in the invoice transaction file (BBTRAN).

  7. Condition: The BBTRAN 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. BBTRAN Subroutine (Lines 0068–0092):

  12. Process:
    • Initializes a key (KEY21, 21 bytes) to blank and sets the lower limit (SETLL) on the BBTRAN file to position the file pointer.
    • Enters a loop (AGNBBO tag):
    • Reads BBTRAN 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 ASBBT to track the number of updated records.
    • Loops back to read the next record (GOTO AGNBBO).

  13. Purpose: Updates the salesman code in the invoice transaction 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 invoice transaction records (ASBBT).
  16. Purpose: Tracks the number of updates for reporting in the AR299 program.

Business Rules

  1. Update Criteria:
  2. Updates are applied to BBTRAN records where the company number (CO) and customer number (CUST) match the ARSLST record’s ASCO and ASCUST.
  3. The salesman code comparison (SLSM IFEQ ASSLSO) is commented out, likely due to a change similar to MG04 in AR290 and AR291 (09/26/2017), meaning updates are based solely on customer and company numbers, not the old salesman code.

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

  5. File Scope:

  6. The program processes one invoice transaction file at a time (BBTRAN, representing workstation-specific files like BBTRXX), 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 BBTRAN for that customer.

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

  11. Audit and Tracking:

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

  13. Data Integrity:

  14. The BBTRAN 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 invoice transaction updates (ASBBT). 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. BBTRAN (Update, 512 bytes, Key: 21 bytes): - Invoice transaction file (represents workstation-specific files like BBTRXX), updated with the new salesman code (SLSM).

External Programs Called

  • None: The AR295 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:
  • The commented-out salesman code comparison (SLSM IFEQ ASSLSO) suggests a modification (likely aligned with MG04 from AR290 and AR291, 09/26/2017), making updates based solely on customer and company numbers.
  • Performance Considerations:
  • The program processes BBTRAN 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:
  • AR295 is called within the OCL program’s loop (LOOP tag) after AR294 retrieves the invoice transaction file name, processing one file per invocation.

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