Skip to content

AR190 RPG36

The RPG program AR190.rpg36.txt is an RPG/36 program (likely for an IBM System/36 or AS/400 environment) that handles the A/R Salesman Change Transaction Add/Update process, as referenced in the previously provided .OCL file (AR190.ocl36.txt). Below, I’ll explain the process steps, business rules, tables used, and external programs called based on the provided RPG code. The program manages the addition and updating of salesman change transactions in an Accounts Receivable (A/R) system, allowing users to assign or reassign salesmen to customers and mark transactions for deletion.

Process Steps of RPG Program AR190

The AR190 program is an interactive application that uses a workstation (display) file to manage salesman change transactions. It operates with two primary screens (S1 and S2) and performs validation, data retrieval, and file updates. Below is a detailed breakdown of the process steps, derived from the RPG code:

  1. Program Initialization and File Setup:
  2. The program defines four files:
    • SCREEN: A workstation file (display device) for user interaction, with a record length of 1000 bytes.
    • ARSLST: A disk file (update mode, UF) for salesman change transactions, with a record length of 256 bytes and an 8-byte key starting at position 2.
    • ARCONT: A disk file (input mode, IF) for A/R control data, with a 256-byte record length and a 2-byte key.
    • ARCUST: A disk file (input mode, IF) for customer master data, with a 384-byte record length and an 8-byte key.
    • GSTABL: A disk file (input mode, IF) for general table data (e.g., salesman codes), with a 256-byte record length and a 12-byte key.

  3. The program initializes variables and clears the screen fields for the first display ($SBLK subroutine, lines 0084–0105).

    • Clears arrays (CUS, CUNM, SLO, SLN, SLNM, DL) and sets the initial screen format to S1 (@SFNEX = 'S1').
    • Turns off error indicators and sets display indicators (e.g., 99, 81) to control screen behavior.

  4. Main Processing Loop ($SFNEX DOWNE 'EJ', lines 0068–0079):

  5. The program enters a loop that continues until the user presses a command key to exit (@SFNEX = 'EJ').
  6. Based on the screen format identifier (@SFID):
    • If @SFID is blank, it calls $SBLK to initialize the screen (first-time display).
    • If @SFID = 'S1', it processes the first screen ($S1 subroutine).
    • If @SFID = 'S2', it processes the second screen ($S2 subroutine).

  7. After processing the screen, it calls $XCPT to display the next screen and reads user input from the SCREEN file (READ SCREEN, with or without the Last Record indicator based on @CCNT).

  8. Screen 1 Processing ($S1, lines 0108–0115):

  9. Purpose: Collects the company number (CO) and an optional customer number (SCUS) to filter transactions.

  10. Steps:

    • Reads the S1 screen input (AR190S1 format, lines 0678–0682).
    • Checks the function key pressed (@VKEY):
    • If ENTER (@VKEY = 0), calls $S1ENT to validate and process the input.
    • If a command key is pressed (@VKEY = 2), calls $S1CK to handle command key functions (e.g., exit).
    • Validation ($S1ENT, lines 0118–0146):
    • Ensures the company number (CO) is not zero; if it is, displays error message MSG1 ("COMPANY NUMBER CANNOT BE BLANK") and sets indicator 90 (error) and 81 (highlight field).
    • Validates CO against the ARCONT file using CHAIN. If not found, displays MSG2 ("COMPANY NOT IN CONTROL FILE") and sets error indicators.
    • If valid, sets up keys (FRKEY, TOPKEY, BOTKEY) for accessing ARSLST and moves to screen S2 by setting @SFNEX = 'S2'.
    • Calls $S2RFW to populate screen S2 with transaction data.
    • Command Keys ($S1CK, lines 0149–0154):
    • If command key KG is pressed, sets @SFNEX = 'EJ' to exit the program.

  11. Screen 2 Processing ($S2, lines 0157–0166):

  12. Purpose: Displays and allows editing of up to 10 salesman change transactions, including customer number (CUS), old salesman code (SLO), new salesman code (SLN), salesman name (SLNM), and delete code (DL).

  13. Steps:

    • Reads the S2 screen input (AR190S2 format, lines 0683–0694).
    • Checks the function key pressed (@VKEY):
    • If ENTER (@VKEY = 0), calls $S2ENT to validate and update transactions.
    • If a command key is pressed (@VKEY = 2), calls $S2CK to handle command keys (e.g., exit or return to S1).
    • If ROLL UP (@VKEY = 01122), calls $S2RFW to display the next set of records.
    • If ROLL DOWN (@VKEY = 01123), calls $S2RBW to display the previous set of records.

  14. Screen 2 Validation and Update ($S2ENT, lines 0169–0334):

  15. Validation Loop (lines 0173–0288):
    • Iterates through the 10 transaction lines (X = 1 to 10).
    • For each line where DL,X ≠ 'D' (not marked for deletion):
    • Customer Validation:
      • If a salesman is keyed (SLN,X ≠ 0) but no customer is provided (CUS,X = 0), sets error indicators (70–79) and displays MSG3 ("CUSTOMER CANNOT BE ZERO") and MSG4 ("WHEN NEW SALESMAN IS KEYED").
      • If a customer is keyed (CUS,X ≠ 0), validates it against ARCUST using CHAIN. If not found, sets error indicators (70–79) and displays MSG5 ("INVALID CUSTOMER NUMBER").
      • If valid, retrieves the customer name (ARNAME to CUNM,X) and old salesman code (ARSLMN to SLO,X).
    • New Salesman Validation:
      • If a customer is keyed, validates the new salesman code (SLN,X) against GSTABL using CHAIN with key SLSMAN + SLN,X. If not found, sets error indicators (60–69) and displays MSG6 ("INVALID NEW SALESMAN CODE").
      • If valid, retrieves the salesman name (TBDESC to SLNM,X).
      • Note: A validation check for SLN,X ≠ SLO,X (new salesman different from old) was removed on 09/27/17, per the comment on line 0247.
    • Delete Code Validation:
      • If a customer is keyed, checks if the delete code (DL,X) is ' ', 'A', or 'D'. If invalid, sets error indicators (40–49) and displays MSG7 ("DELETE CODE MUST BE ' ',A, OR D").
    • If any validation errors occur, jumps to ENDS2E to redisplay the screen with error messages.

  16. Update Transactions (lines 0294–0315):

    • Iterates through the 10 transaction lines again.
    • For each line with a customer number (CUS,X ≠ 0):
    • Builds a key (FRKEY = CO + CUS,X) and checks ARSLST using CHAIN.
    • If DL,X ≠ 'D':
      • If the record exists (95 off), updates it (EXCPTUPDREC).
      • If the record doesn’t exist (95 on), adds it (EXCPTADDREC).
    • If DL,X = 'D' and the record doesn’t exist (95 off), deletes it (EXCPTDELREC).
    • Updates BOTKEY and SVKEY to track the highest key processed.
    • If the last line has a customer (CUS,10 > 0), sets S2FULL = 'Y' to indicate a full screen.
    • If no records are entered (CUS,10 = 0 and SLN,10 = 0), returns to screen S1 (@SFNEX = 'S1') and clears fields (CLRFLD).
    • Otherwise, calls $S2RFW to refresh the screen with the next set of records and sets @SFNEX = 'S2'.

  17. Roll Up (Forward) ($S2RFW, lines 0351–0484):

  18. Populates screen S2 with the next set of records from ARSLST starting at BOTKEY.
  19. Clears arrays (CUS, CUNM, SLO, SLN, SLNM, DL) and resets indicators.
  20. Reads ARSLST sequentially, filtering by company number (ASCO = CO).
  21. For each valid record (up to 10):
    • Copies data to screen arrays (ASCUST to CUS,Y, ASSLSO to SLO,Y, ASSLSN to SLN,Y, ASDEL to DL,Y).
    • Retrieves customer name from ARCUST and salesman name from GSTABL.
    • If the record is marked deleted (ASDEL = 'D'), displays MSG8 ("THIS RECORD PREVIOUSLY DELETED").
    • Sets indicators (50–59, 60–69) to protect fields for existing records.
  22. Updates TOPKEY and BOTKEY to track the range of displayed records.
  23. If the end of the file is reached, displays MSG9 ("END OF FILE HAS BEEN REACHED") and calls RESET to redisplay the last screen.

  24. If fewer than 10 records are read and S2FULL ≠ 'Y', clears remaining fields.

  25. Roll Down (Backward) ($S2RBW, lines 0539–0615):

  26. Populates screen S2 with the previous set of records from ARSLST starting at TOPKEY.
  27. Reads ARSLST in reverse (READP) until 10 records are loaded or the beginning of the file is reached.
  28. Similar to $S2RFW, copies data to screen arrays, retrieves names, and sets indicators.
  29. If the beginning of the file is reached, displays MSG10 ("BEGINNING OF FILE HAS BEEN REACHED").

  30. Updates TOPKEY and BOTKEY accordingly.

  31. Screen 2 Command Keys ($S2CK, lines 0337–0348):

  32. If command key KA is pressed, clears fields (CLRFLD) and returns to screen S1 (@SFNEX = 'S1').

  33. If command key KG is pressed, exits the program (@SFNEX = 'EJ').

  34. Display Next Screen ($XCPT, lines 0618–0637):

  35. Increments a counter (@CCNT) to track screen displays.
  36. Displays the appropriate screen based on @SFNEX:
    • If @SFNEX = 'S1', outputs the AR190S1 format.
    • If @SFNEX = 'S2', outputs the AR190S2 format.

  37. Calls CLRIND to reset error indicators and clear message fields (MSG1, MSG2).

  38. Field and Indicator Clearing:

    • CLRIND (lines 0640–0662): Resets error indicators (40–49, 60–69, 70–79, 90, 91, etc.) and clears message fields.
    • CLRFLD (lines 0665–0675): Clears screen arrays (CUS, CUNM, SLO, SLN, SLNM, DL) and S2FULL.

  39. Output Operations:

    • ADDREC (lines 0696–0701): Adds a new record to ARSLST with company number (CO), customer number (CUS,X), old salesman (SLO,X), and new salesman (SLN,X).
    • UPDREC (lines 0703–0706): Updates an existing ARSLST record with delete code (DL,X), old salesman (SLO,X), and new salesman (SLN,X).
    • DELREC (line 0708): Deletes a record from ARSLST.

Business Rules

The program enforces the following business rules for managing salesman change transactions:

  1. Company Number Validation:
  2. The company number (CO) must not be blank/zero (MSG1: "COMPANY NUMBER CANNOT BE BLANK").

  3. The company number must exist in the ARCONT file (MSG2: "COMPANY NOT IN CONTROL FILE").

  4. Customer Number Validation:

  5. If a new salesman code (SLN,X) is entered, a customer number (CUS,X) must be provided (MSG3: "CUSTOMER CANNOT BE ZERO" and MSG4: "WHEN NEW SALESMAN IS KEYED").

  6. The customer number must exist in the ARCUST file (MSG5: "INVALID CUSTOMER NUMBER").

  7. Salesman Code Validation:

  8. The new salesman code (SLN,X) must exist in the GSTABL file under the SLSMAN table (MSG6: "INVALID NEW SALESMAN CODE").

  9. A previous rule requiring the new salesman to differ from the old salesman (SLN,X ≠ SLO,X) was removed on 09/27/17 (lines 0247–0264).

  10. Delete Code Validation:

  11. The delete code (DL,X) must be ' ' (blank), 'A', or 'D' (MSG7: "DELETE CODE MUST BE ' ',A, OR D").

  12. If DL,X = 'D', the record is marked for deletion, and if it doesn’t exist in ARSLST, it is deleted via EXCPTDELREC.

  13. Transaction Processing:

  14. If a customer number is entered:
    • If the record exists in ARSLST and DL,X ≠ 'D', it is updated (UPDREC).
    • If the record does not exist and DL,X ≠ 'D', it is added (ADDREC).
    • If the record does not exist and DL,X = 'D', it is deleted (DELREC).

  15. Deleted records in ARSLST (ASDEL = 'D') are flagged with MSG8 ("THIS RECORD PREVIOUSLY DELETED").

  16. Screen Navigation:

  17. Screen S1 collects the company number and optional customer number.
  18. Screen S2 displays up to 10 transactions and supports roll-up/roll-down for navigation.
  19. If no records are entered or the end of the file is reached, the program returns to screen S1.
  20. The end of the file (ARSLST) triggers MSG9 ("END OF FILE HAS BEEN REACHED").

  21. The beginning of the file triggers MSG10 ("BEGINNING OF FILE HAS BEEN REACHED").

  22. Field Protection:

  23. Customer numbers for existing records are protected (indicators 50–59) to prevent modification.

  24. Error indicators (40–49, 60–69, 70–79) highlight invalid fields on screen S2.

  25. Data Retrieval:

  26. Customer names are retrieved from ARCUST (ARNAME).
  27. Salesman names are retrieved from GSTABL (TBDESC) for the SLSMAN table.
  28. The old salesman code is retrieved from ARCUST (ARSLMN) or ARSLST (ASSLSO).

Tables (Files) Used

The following files are used by the AR190 program: 1. SCREEN: Workstation file for user interaction (display/input). 2. ARSLST: Salesman change transaction file (update mode, UF), stores transaction records with fields: - ASDEL (1 byte, delete code: ' ', 'A', or 'D'). - ASCO (company number, positions 2–3). - ASCUST (customer number, positions 4–9). - ASSLSO (old salesman code, positions 10–11). - ASSLSN (new salesman code, positions 12–13). 3. ARCONT: A/R control file (input mode, IF), contains company data with fields: - ACNAME (company name, positions 4–33). 4. ARCUST: Customer master file (input mode, IF), contains customer data with fields: - ARNAME (customer name, positions 10–39). - ARSLMN (salesman code, positions 263–264). 5. GSTABL: General table file (input mode, IF), contains reference data (e.g., salesman codes) with fields: - TBDESC (table description, e.g., salesman name, positions 14–43).

External Programs Called

The AR190 program does not explicitly call any external programs (e.g., via CALL operations). It operates as a standalone program, handling all logic internally through subroutines.

Summary

  • Process Steps:
  • Initializes files and screen fields.
  • Uses a main loop to process two screens: S1 (company/customer input) and S2 (transaction display/edit).
  • Validates input on S1 (company number) and S2 (customer, salesman, delete code).
  • Updates ARSLST with add (ADDREC), update (UPDREC), or delete (DELREC) operations.
  • Supports roll-up/roll-down for browsing transactions.

  • Displays error messages and protects fields as needed.

  • Business Rules:

  • Validates company number, customer number, salesman code, and delete code.
  • Ensures data consistency with ARCONT, ARCUST, and GSTABL.
  • Handles add, update, and delete operations for salesman change transactions.

  • Manages screen navigation and error handling.

  • Tables Used: SCREEN, ARSLST, ARCONT, ARCUST, GSTABL.

  • External Programs: None.

If you have additional details (e.g., the AR191.rpg36 code for editing transactions or specific screen layouts), I can provide further analysis or comparisons. Let me know if you’d like me to search for related information or analyze any other uploaded files!