Skip to content

EDI404SD OCL

The provided document, EDI404SD.ocl36.txt, is an Operation Control Language (OCL) program for IBM midrange systems (e.g., AS/400 or IBM i). It is called as part of the EDI (Electronic Data Interchange) outbound Bill of Lading (BOL) tracking maintenance workflow, specifically following the EDI811 program (as seen in EDI811.ocl36.txt). The EDI404SD OCL program manages the final steps of processing and transmitting EDI 404-compliant BOL data, including checking for records, running validation and FTP processes, and archiving data. Below, I’ll explain the process steps, business rules, tables (files) used, and external programs called, integrating context from the related EDI811P and EDI811 programs.

Process Steps of the EDI404SD OCL Program

The EDI404SD OCL program checks for the presence of EDI records, calls programs to validate and transmit them, copies records to a history file, and clears the source file. Here’s a detailed breakdown of the process steps:

  1. Header and Initial Setup:
  2. The program begins with a comment: "CHECK FOR RECORDS IN EDIBOL IF EMPTY THEN THERE IS NO NEED TO RUN THE OPTION." This suggests the program verifies whether there are records to process before proceeding.

  3. // SCPROCP ,,,,,,,,?9?: Defines the procedure name (SCPROCP) with a parameter placeholder (?9?, likely a library or system prefix).

  4. Check for Records in EDIRSI:

  5. // IF ?F'A,?9?EDIRSI'?/0 PAUSE 'THERE ARE NO RECORDS TO SEND TO RSI. PRESS 0 TO CANCEL': Checks if the EDIRSI file (labeled ?9?EDIRSI) has zero records (?F'A,...'?/0). If true, it pauses the job and displays a message prompting the user to press 0 to cancel.
  6. // IF ?F'A,?9?EDIRSI'?/0 CANCEL: If EDIRSI is empty, the program cancels execution, halting further processing.

  7. Purpose: Ensures the program only proceeds if there are records to process, avoiding unnecessary execution.

  8. Call EDI404 Program:

  9. CALL EDI404: Calls the EDI404 program, likely an RPG or CL program that validates or processes the EDI 404 records in EDIOUT or EDIRSI (generated by EDI811).
  10. // IF ?L'100,6'?/CANCEL CLRPF ?9?EDI404: If the EDI404 program sets a condition at offset 100, length 6 to CANCEL, the EDI404 file (labeled ?9?EDI404) is cleared using the CLRPF (Clear Physical File) command.
  11. // IF ?L'100,6'?/CANCEL GOTO END: If the CANCEL condition is met, the program jumps to the END tag, terminating execution.

  12. Purpose: Validates or finalizes EDI 404 records before transmission, with a cancellation check to handle errors or user termination.

  13. Call EDI404FTP Program:

  14. CALL EDI404FTP: Calls the EDI404FTP program, which handles the FTP transmission of the EDIOUT file (containing EDI 404 records) to an external trading partner, such as RSI (Railway Systems Inc., inferred from the file name EDIRSI).

  15. Purpose: Transmits the EDI 404 data to the recipient, completing the outbound BOL process.

  16. Copy EDIRSI to History File:

  17. CPYF FROMFILE(QS36F/?9?EDIRSI) TOFILE(QS36F/?9?EDIRSIH) MBROPT(*ADD) FMTOPT(*NOCHK): Copies records from the EDIRSI file (in library QS36F with prefix ?9?) to a history file EDIRSIH (same library and prefix).
    • MBROPT(*ADD): Adds records to the target file without replacing existing ones.
    • FMTOPT(*NOCHK): Bypasses format checking, ensuring a direct copy regardless of minor format differences.

  18. Purpose: Archives EDIRSI records for historical or audit purposes before clearing the source file.

  19. Clear EDIRSI File:

  20. CLRPF ?9?EDIRSI: Clears the EDIRSI file (labeled ?9?EDIRSI) to remove processed records, preparing it for the next job.

  21. Purpose: Ensures no residual data remains in EDIRSI, preventing duplicate processing in future runs.

  22. Program Termination:

  23. // TAG END: Marks the END label, reached after cancellation or normal processing.
  24. // LOCAL BLANK-*ALL: Clears all local variables, ensuring a clean exit.

Business Rules

The EDI404SD OCL program enforces the following business rules: 1. Record Existence Check: - The program only proceeds if the EDIRSI file contains records. If empty, it prompts the user to cancel and terminates execution, preventing unnecessary processing. 2. Validation Before Transmission: - The EDI404 program is called to validate or finalize EDI 404 records before FTP transmission. If it signals cancellation (via a data area at offset 100, length 6), the EDI404 file is cleared, and the program ends. 3. Data Transmission: - The EDI404FTP program transmits EDI 404 records (likely in EDIOUT) to an external trading partner, ensuring timely delivery of BOL data. 4. Data Archiving: - Records in EDIRSI are copied to EDIRSIH for historical retention before clearing the source file, maintaining an audit trail. 5. File Management: - The EDIRSI file is cleared after archiving to prevent duplicate processing in subsequent runs. - The EDI404 file is cleared if the EDI404 program cancels, ensuring no invalid data persists. 6. Environment Cleanup: - Local variables are cleared at the end to prevent data leakage or conflicts in future jobs.

Tables (Files) Used

The OCL program references the following files: 1. EDIRSI: - Label: ?9?EDIRSI (in library QS36F). - Purpose: Input file containing routing or shipment information (generated by EDI811), checked for records and cleared after archiving. 2. EDIRSIH: - Label: ?9?EDIRSIH (in library QS36F). - Purpose: Output file for archiving EDIRSI records, used for historical or audit purposes. 3. EDI404: - Label: ?9?EDI404 (in library QS36F). - Purpose: Likely the same as EDIOUT (from EDI811), containing EDI 404-compliant BOL records. Cleared if the EDI404 program cancels.

Note: The comment references EDIBOL, but it’s not used directly in this OCL program. It likely refers to the workflow context where EDIBOL is an input to EDI811.

External Programs Called

The OCL program explicitly calls the following external programs: 1. EDI404: - Called via CALL EDI404. - Purpose: Validates or finalizes EDI 404 records in EDIOUT or EDIRSI before transmission. It may set a cancellation condition checked at offset 100, length 6. 2. EDI404FTP: - Called via CALL EDI404FTP. - Purpose: Handles FTP transmission of the EDIOUT file (EDI 404 records) to an external trading partner, such as RSI.

Integration with EDI811P and EDI811 Programs

  • EDI811P (OCL and RPG):
  • The EDI811P.rpg36 program validates company numbers (KYCO) and BOL numbers, writing them to EDIBOL.
  • EDI811P.ocl36 sets up the initial files (BICONT, EDIBOL, EDIBOLTX) and calls EDI811.
  • EDI811 (OCL and RPG):
  • The EDI811.rpg36 program reads EDIBOL and EDIBOLTX, generating EDI 404 records in EDIOUT and routing/shipment data in EDIRSI.
  • The EDI811.ocl36 program defines these files and calls EDI404SD after EDI811 completes.
  • EDI404SD:
  • Checks EDIRSI for records, calls EDI404 for validation, transmits data via EDI404FTP, archives EDIRSI to EDIRSIH, and clears EDIRSI.
  • The EDI404 file (likely EDIOUT) is cleared if validation fails, ensuring data integrity.
  • Workflow Continuity:
  • EDI811P prepares validated BOL data (EDIBOL).
  • EDI811 formats it into EDI 404 records (EDIOUT, EDIRSI).
  • EDI404SD validates, transmits, and archives the data, completing the outbound BOL process.

Summary

  • Process Overview: The EDI404SD OCL program checks if EDIRSI contains records, cancels if empty, calls EDI404 to validate EDI 404 data, calls EDI404FTP to transmit the data, copies EDIRSI to EDIRSIH for archiving, and clears EDIRSI. It ensures a clean exit by clearing local variables.
  • Business Rules: Requires non-empty EDIRSI, validates data before transmission, archives records, clears files to prevent duplicates, and handles cancellation scenarios.
  • Tables/Files: EDIRSI (input), EDIRSIH (output/history), EDI404 (output, likely EDIOUT).
  • External Programs: EDI404 (validation), EDI404FTP (FTP transmission).

If you need further details (e.g., the RPG/CL code for EDI404 or EDI404FTP), please provide additional files or context.