Skip to content

BB1014 RPGLE

The BB1014.rpgle.txt is an RPG program (likely RPG III or RPG/36, given the System/36 context) called from the BB502.ocl36.txt OCL program. It is designed to retrieve location information from the INLOC file, supporting programs like BB101, BB495, and BB500. Below, I’ll explain the process steps, business rules, tables used, and external programs called based on the provided RPG source code.

Process Steps of the RPG Program

The BB1014 program is a simple utility that retrieves location-specific data (e.g., location name, phone number, inventory type) based on input parameters (company number and location code). It formats the output and returns it to the calling program. Here’s a step-by-step breakdown of the process:

  1. Program Initialization:
  2. The program defines the INLOC file as an input file (512 bytes, indexed, read-only) with a key length of 2 bytes (KEYLOC(2)).
  3. Two data structures are defined:
    • PARMS4: An output parameter structure containing:
    • @4CONO (2 digits, company number).
    • @4LOC (3 characters, location code).
    • @4LINT (1 character, inventory type).
    • @4LOCN (20 characters, location name).
    • @4LOCP (14 characters, location phone number).
    • PHONE: A substructure to format the phone number, consisting of:
    • PARL (1 character, left parenthesis).
    • ILAREA (3 digits, area code).
    • PARR (2 characters, ") ").
    • ILTEL3 (3 digits, phone number prefix).
    • DASH (1 character, hyphen).
    • ILTEL4 (4 digits, phone number suffix).

  4. Input specifications (I) map fields from the INLOC file to program variables:

    • ILDEL (delete flag, position 1).
    • ILCONO (company number, positions 2–3).
    • ILLOC (location code, positions 4–6).
    • ILNAME (location name, positions 7–26).
    • ILTELE, ILAREA, ILTEL3, ILTEL4 (telephone number components, positions 363–372).
    • ILINTY (inventory type, position 458).

  5. Parameter Input:

  6. The program accepts input parameters via the *ENTRY PLIST using the PARMS4 data structure, which contains the company number (@4CONO) and location code (@4LOC) provided by the calling program.

  7. Phone Number Formatting:

  8. The program initializes the phone number formatting characters:

    • PARL is set to '('.
    • PARR is set to ') '.
    • DASH is set to '-'.

  9. Retrieve Location Record:

  10. The program constructs a 5-character key (LOCKEY) by combining:
    • @4CONO (company number, moved to the first 2 positions).
    • @4LOC (location code, moved to the last 3 positions).
  11. It uses LOCKEY to perform a CHAIN operation on the INLOC file to retrieve the corresponding record.
  12. If the record is not found (indicator 91 is on):
    • @4LOCN (location name) is set to blanks.
    • @4LOCP (phone number) is set to blanks.
    • @4LINT (inventory type) is set to blanks.

  13. If the record is found (indicator 91 is off):

    • ILNAME is moved to @4LOCN (location name).
    • If ILTELE (telephone number) is zero, @4LOCP is set to blanks; otherwise, the formatted phone number (PHONE) is moved to @4LOCP.
    • ILINTY is moved to @4LINT (inventory type).

  14. Program Termination:

  15. The program sets the LR (Last Record) indicator to terminate and return the PARMS4 data structure to the calling program with the retrieved or blank values.

Business Rules

The BB1014 program enforces the following business rules, inferred from the code and comments:

  1. Valid Location Lookup:
  2. The program requires a valid company number (@4CONO) and location code (@4LOC) to retrieve a record from the INLOC file.

  3. If no matching record is found (based on the composite key LOCKEY), the program returns blank values for location name, phone number, and inventory type, indicating an invalid or non-existent location.

  4. Phone Number Formatting:

  5. The phone number is formatted as (XXX) XXX-XXXX using the PHONE data structure, combining ILAREA, ILTEL3, and ILTEL4 with parentheses and a hyphen.

  6. If the telephone number (ILTELE) is zero, the phone number field (@4LOCP) is returned as blank, indicating no valid phone number exists for the location.

  7. Inventory Type Handling:

  8. The inventory type (ILINTY) is retrieved and returned as-is (valid values are blank, 'D', or 'P', as per the comment in the I specification).

  9. This field is critical for programs like BB502 to determine how inventory is managed at the specified location.

  10. Consistency Across Programs:

  11. The comment at the top (TLN-GSS-12/06/99) emphasizes that changes to BB1014 must be coordinated with BB101, BB495, and BB500 to ensure consistency, as these programs share similar logic for accessing INLOC data.

  12. Error Handling:

  13. The program handles missing records gracefully by returning blank values rather than raising an error, allowing the calling program to decide how to proceed.
  14. No explicit validation errors are raised within BB1014, as it is a utility program focused on data retrieval.

Tables (Files) Used

The program uses only one file, as defined in the F (File) specification:

  1. INLOC: Location master file (512 bytes, indexed, read-only, key length of 2 bytes). Contains fields like:
  2. ILDEL (delete flag).
  3. ILCONO (company number).
  4. ILLOC (location code).
  5. ILNAME (location name).
  6. ILTELE, ILAREA, ILTEL3, ILTEL4 (telephone number components).
  7. ILINTY (inventory type).

External Programs Called

The BB1014 program does not call any external programs. It is a standalone utility that performs a single CHAIN operation on the INLOC file and returns data to the calling program via the PARMS4 data structure.

Summary

The BB1014 RPG program is a utility called from the BB502 OCL program (and potentially BB101, BB495, and BB500) to retrieve location information from the INLOC file. It accepts a company number and location code, retrieves the corresponding location name, phone number, and inventory type, and formats the phone number for output. If no record is found, it returns blank values. The program enforces simple business rules around valid lookups and phone number formatting, using a single file (INLOC) and no external program calls. Its design ensures consistency with related programs, as noted in the change history.

If you need further analysis (e.g., cross-referencing with BB502 logic, specific validations, or related content from X or web searches), let me know!