Skip to content

AR299 RPG36

The AR299.rpg36.txt is an RPG (Report Program Generator) program for IBM System/36, invoked by the AR290.ocl36.txt OCL program to generate a report summarizing the salesman code changes made by the preceding programs (AR290, AR291, AR294, AR295). Below is a detailed explanation of the process steps, business rules, tables/files used, and any external programs called.

Process Steps of the AR299 RPG Program

The AR299 RPG program reads the salesman change transaction file (ARSLST), retrieves customer and salesman details, and produces a formatted report detailing the updates made across various files. Here’s a step-by-step breakdown:

  1. Initialization (Lines 0032–0039):
  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 the report header.
    • DATE (6 digits, likely MMDDYY or YYMMDD) for the report header.

  3. Purpose: Sets up timestamp data for the report header.

  4. Main Processing Loop (Lines 0042–0057):

  5. Loop Control: Processes each record in the ARSLST file where the delete flag (ASDEL) is not set (NCD condition, record type 01).
  6. Steps:
    • Customer Lookup:
    • Constructs a key (ARKEY, 8 bytes) using the company number (ASCO) and customer number (ASCUST) from ARSLST.
    • Chains (searches) the ARCUST file using ARKEY to retrieve the customer name (ARNAME).
    • If the customer is not found (10 indicator), sets ARNAME to 'INVALID'; otherwise, uses the retrieved name.
    • Salesman Description Lookup:
    • Constructs a key (SLKEY, 12 bytes) by combining the literal 'SLSMAN' and the new salesman code (ASSLSN) from ARSLST.
    • Chains the GSTABL file (general table file) using SLKEY to retrieve the salesman description (TBDESC).
    • If the salesman code is not found (10 indicator), sets TBDESC to 'INVALID'; otherwise, uses the retrieved description.

  7. Purpose: Gathers customer and salesman details to include in the report, ensuring meaningful output even for invalid records.

  8. Report Generation (Lines 0060–0124):

  9. Output Structure:
    • Header Lines (Level L1, triggered by company number change or overflow):
    • Prints page number (PAGE), date (DATE), and time (TIMEOF).
    • Prints a title (* SALESMAN CHANGE POST *).
    • Prints decorative lines (* * * * * * * * * * * *) for formatting.
    • Prints column headers: CO, CUSTOMER #, NAME, SALESMAN OLD NEW, BBORDR, BBBOL, BBORXX, BBTRWS, SA5FIL, SA5DBB, SA5BCM, SA5SHP, FRBINH.
    • Detail Lines (Condition 01):
    • For each ARSLST record:
      • Prints company number (ASCO), customer number (ASCUST), customer name (ARNAME), old salesman code (ASSLSO), new salesman code (ASSLSN), and salesman description (TBDESC).
      • Prints update counts for each file: ASBBO (order headers), ASBBB (bill of lading), ASORT (batch orders), ASBBT (invoice transactions), ASS5F (sales analysis fixed), ASS5D (sales analysis database), ASS5B (sales analysis billing control), ASS5S (shipping units, added in LT01), ASSFR (freight bills, added in LT01).
  10. Purpose: Produces a detailed report summarizing the salesman code changes and the number of records updated in each file.

Business Rules

  1. Report Content:
  2. The report includes all non-deleted ARSLST records, detailing the company, customer, old and new salesman codes, and the number of records updated in each file.
  3. Customer names are retrieved from ARCUST; if not found, 'INVALID' is displayed.

  4. Salesman descriptions are retrieved from GSTABL for the new salesman code; if not found, 'INVALID' is displayed.

  5. Grouping and Formatting:

  6. The report groups records by company number (ASCO, level L1), with headers printed on company change or page overflow (OF).
  7. Headers include page number, date, time, and column labels for clarity.

  8. Decorative lines (* * * * *) enhance readability and separate sections.

  9. Error Handling:

  10. If a customer record is not found in ARCUST, the report indicates 'INVALID' for the customer name but still includes the record.

  11. If a salesman code is not found in GSTABL, the report indicates 'INVALID' for the salesman description.

  12. Audit and Verification:

  13. The report serves as an audit trail, showing the extent of updates across multiple files (BBORDR, BBBOL, BBORXX, BBTRWS, SA5FIL, SA5DBB, SA5BCM, SA5SHP, FRBINH).

  14. Update counts (ASBBO, ASBBB, etc.) reflect the work done by AR290, AR291, and AR295, providing a summary of changes.

  15. Data Integrity:

  16. Files are opened in input mode (IP, IF) for ARSLST, ARCUST, and GSTABL, and output mode (O) for ARPRINT, ensuring read-only access to data files and write-only to the printer file.
  17. The program processes records sequentially, ensuring all non-deleted records are reported.

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, 256 bytes, Key: 8 bytes): - Salesman change transaction file containing: - Company number (ASCO), customer number (ASCUST), old salesman code (ASSLSO), new salesman code (ASSLSN). - Update counts: ASBBO (order headers), ASBBB (bill of lading), ASORT (batch orders), ASBBT (invoice transactions), ASS5F (sales analysis fixed), ASS5D (sales analysis database), ASS5B (sales analysis billing control), ASS5S (shipping units, added in LT01), ASSFR (freight bills, added in LT01). 2. ARCUST (Input, 384 bytes, Key: 8 bytes): - Customer master file, used to retrieve the customer name (ARNAME). 3. GSTABL (Input, 256 bytes, Key: 12 bytes): - General table file, used to retrieve the salesman description (TBDESC) for the new salesman code. 4. ARPRINT (Output, 164 bytes, Printer): - Printer file for the report output, containing headers and detail lines.

External Programs Called

  • None: The AR299 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.

Additional Notes

  • File Modifications:
  • LT01 (10/14/2011): Added fields ASS5S (shipping units) and ASSFR (freight bills) to ARSLST and included them in the report output.
  • Performance Considerations:
  • The program processes ARSLST sequentially, which is efficient for small to medium datasets typical of System/36 applications.
  • The use of CHAIN for random access to ARCUST and GSTABL may introduce minor overhead for large files but is necessary for retrieving names and descriptions.
  • 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 report output uses a printer file (ARPRINT), with formatting controlled by Output Specifications (O-specs), typical for System/36 reports.
  • Role in OCL:
  • AR299 is called at the end of the OCL program to generate the final report, summarizing the results of all salesman code updates performed by AR290, AR291, and AR295.
  • The OCL overrides the printer file to direct output to QUSRSYS/SLSMCHANGE (production) or QUSRSYS/TESTOUTQ (testing).

This program provides a comprehensive audit trail of salesman code changes, ensuring transparency and verification of updates across the accounts receivable system’s files.