Skip to content

AP300P OCL

Let’s break down the provided Operation Control Language (OCL) program, AP300P.ocl36.txt, which appears to be a control script used in an IBM System/36 environment to manage Accounts Payable (A/P) monthly and yearly updates for Month-to-Date (MTD) and Year-to-Date (YTD) fields in the vendor master file. OCL is a scripting language used on IBM midrange systems like the System/36 to control job execution and program flow. Below, I’ll explain the process steps, identify external programs called, and list the tables (files) used.

Process Steps of the OCL Program

The OCL script controls the execution of an Accounts Payable update process. Here’s a step-by-step explanation of the program’s logic:

  1. Load the Program (// LOAD AP300P):
  2. The script begins by loading the program AP300P. This is the main program that performs the A/P monthly or yearly update for MTD/YTD fields in the vendor master file.

  3. In the System/36 environment, // LOAD specifies the program to be executed.

  4. File Specification (// FILE NAME-APCONT,LABEL-?9?APCONT,DISP-SHR):

  5. The script defines a file named APCONT, which is associated with the disk file labeled ?9?APCONT. The ?9? is a substitution variable, likely a library or prefix defined at runtime (e.g., a specific library or environment code).
  6. DISP-SHR indicates the file is opened in shared mode, allowing multiple processes to access it concurrently without modifying its structure.

  7. This file (APCONT) is likely the vendor master file containing MTD/YTD data to be updated.

  8. Run the Program (// RUN):

  9. The // RUN statement initiates the execution of the loaded AP300P program.

  10. At this point, the program is expected to perform the core logic of updating MTD/YTD fields, but the OCL script itself does not contain the RPG logic—only the control flow.

  11. Conditional Check for Cancel (// IF ?L'129,6'?/CANCEL GOTO END):

  12. The script checks a condition using a substitution variable ?L'129,6'?, which likely references a 6-character field starting at position 129 in a system control area or parameter area (e.g., Local Data Area or program parameter).
  13. If this field equals CANCEL, the script branches to the END tag, effectively terminating the job without further processing.

  14. This acts as a safeguard to allow cancellation of the update process based on an external condition (e.g., user input or system state).

  15. Conditional Data Assignment (// IF ?L'111,3'?/CO ...):

  16. The script checks another condition using ?L'111,3'?, a 3-character field starting at position 111.
  17. If the condition is CO (likely indicating "Company"):
    • The script sets a local variable at OFFSET-1 with the value IAC (3 characters).
    • This might represent a specific company code or configuration for the update process.
  18. Else:
    • The script sets the same local variable at OFFSET-1 with the value I*C (3 characters, where * could be a wildcard or specific character depending on context).
    • This suggests an alternative configuration, possibly for a different company or processing mode.

  19. The LOCAL statement modifies the Local Data Area (LDA), a System/36 mechanism for passing parameters between programs or jobs. The assigned value (IAC or I*C) likely influences how AP300P processes the data.

  20. Conditional Job Queue Submission (// IF ?L'120,1'?/Y ...):

  21. The script checks a single-character field at position 120 (?L'120,1'?).
  22. If the value is Y:
    • The script submits a job named AP300 to a job queue (JOBQ) in the library specified by ?CLIB? (a substitution variable for the library name). The job is submitted with parameters ,,,,,,,,,?9?, where ?9? is likely the same library or environment prefix used earlier.
    • This suggests the update process is queued for batch processing, possibly to run asynchronously or in a specific job queue for resource management.
  23. Else:
    • The script executes AP300 directly (not queued) with parameters ,,,,,,,,?9?.
    • This implies immediate execution of the AP300 program in the current job stream.

  24. The difference between queuing and direct execution likely depends on system workload or user preference (e.g., Y for batch processing when the system is busy).

  25. End of Processing (// TAG END):

  26. The END tag marks the termination point of the script. If the CANCEL condition was met earlier, the script jumps here, skipping all other steps.

  27. After executing the job or program, the script reaches this point and ends.

  28. Clear Local Data Area (// LOCAL BLANK-*ALL):

  29. The script clears all data in the Local Data Area (LDA) at the start and end of the program (BLANK-*ALL).

  30. This ensures a clean state, preventing residual data from affecting this or subsequent jobs. The LDA is often used to pass parameters or flags between programs, and clearing it avoids unintended side effects.

  31. Additional Notes:

  32. The // GSY2K statement is a System/36 directive, possibly related to Y2K compliance or a system-level configuration, but it has no direct impact on the logic described here.
  33. The // SCPROCP ,,,,,,,,?9? comment at the top might be a header indicating the procedure name (SCPROCP) and parameters, with ?9? as a placeholder for a library or environment code.

External Programs Called

The OCL script references the following external programs:

  1. AP300P:
  2. Loaded and executed via // LOAD AP300P and // RUN.
  3. This is the primary program responsible for updating MTD/YTD fields in the vendor master file (APCONT).

  4. Likely an RPG or RPG II program, given the System/36 context and the .ocl36 extension.

  5. AP300:

  6. Referenced in the conditional job submission (JOBQ ?CLIB?,AP300) or direct execution (AP300 ,,,,,,,,?9?).
  7. This could be:
    • A different program from AP300P, possibly a batch version or a related utility program for the same A/P update process.
    • Alternatively, it might be a typo or alias for AP300P, but the distinct naming suggests a separate program or entry point.
  8. The parameters ,,,,,,,,?9? indicate that up to nine placeholders are passed, with ?9? being the only non-empty parameter (likely a library or environment code).

Tables (Files) Used

The script explicitly references one file:

  1. APCONT:
  2. Specified in // FILE NAME-APCONT,LABEL-?9?APCONT,DISP-SHR.
  3. This is likely the vendor master file in the Accounts Payable system, containing records with MTD/YTD fields to be updated.
  4. The ?9?APCONT label suggests the file resides in a library or is prefixed with a code provided at runtime (e.g., PRODAPCONT for production).
  5. Opened in shared mode (DISP-SHR), indicating read/write access without exclusive locking.

No other files are explicitly mentioned in the OCL script, but the AP300P or AP300 programs might access additional files (e.g., transaction files, history files) not visible in the OCL control structure.

Summary

Process Overview: The OCL script AP300P.ocl36.txt controls the execution of an Accounts Payable update process on an IBM System/36. It: - Clears the Local Data Area for a clean state. - Loads and runs the AP300P program, which updates MTD/YTD fields in the APCONT vendor master file. - Checks for a CANCEL condition to abort the process. - Sets a configuration code (IAC or I*C) based on a company-related condition. - Either submits the AP300 program to a job queue or runs it directly, depending on a flag. - Clears the LDA again to ensure no residual data affects subsequent processes.

External Programs: - AP300P: Main update program. - AP300: Possibly a batch version or related program, executed directly or via job queue.

Tables Used: - APCONT: Vendor master file containing MTD/YTD data.

This script provides a controlled, conditional execution of the A/P update process, with flexibility for batch or immediate processing and safeguards for cancellation. If you need further analysis (e.g., the RPG code for AP300P or details about the file structure), please provide additional context or files!