Skip to content

CORPT00C

Source: cbl/CORPT00C.cbl

Type: CICS transaction program

CORPT00C — Transaction Report Submission Program

Purpose

CORPT00C is a CICS online program in the CardDemo application that lets a user request a printed transaction report — Monthly, Yearly, or Custom (date-range) — from a screen (map CORPT0A). Rather than generating the report itself, it validates the user's input, builds a batch JCL job from an in-memory template, and submits that job to a background job queue for execution by a batch process (TRANREPT proc). It also handles standard 3270-style screen navigation (initial display, re-display with error messages, and return to the previous menu).

How it works

  1. MAIN-PARA is the entry point on every CICS invocation of this transaction (CR00).
  2. If there's no commarea (EIBCALEN = 0), it's a fresh start with no prior context, so it sets the "return to" program to COSGN00C (sign-on) and performs RETURN-TO-PREV-SCREEN.
  3. Otherwise it copies in the passed commarea. If the program is being entered for the first time in this conversation (NOT CDEMO-PGM-REENTER), it initializes the map and calls SEND-TRNRPT-SCREEN to display the blank report request screen.
  4. If already re-entered, it calls RECEIVE-TRNRPT-SCREEN to read the user's screen input, then branches on the AID key pressed:
    • ENTERPROCESS-ENTER-KEY (main validation/submission logic)
    • PF3 → sets target program to COMEN01C and performs RETURN-TO-PREV-SCREEN (back to main menu)
    • any other key → flags an error, sets cursor to the Monthly field, and re-sends the screen with an "invalid key" message
  5. The paragraph ends with EXEC CICS RETURN TRANSID(...) COMMAREA(...), keeping the transaction pseudo-conversational.

  6. PROCESS-ENTER-KEY determines which report type was requested by checking which map field is non-blank:

  7. Monthly: computes date range as the 1st of the current month through the last day of the current month (using FUNCTION CURRENT-DATE, INTEGER-OF-DATE/DATE-OF-INTEGER arithmetic), then performs SUBMIT-JOB-TO-INTRDR.
  8. Yearly: computes date range Jan 1–Dec 31 of the current year, then performs SUBMIT-JOB-TO-INTRDR.
  9. Custom: validates that start/end month, day, and year fields are all present and numeric/in-range (month ≤12, day ≤31), converts them with NUMVAL-C, and calls the external routine CSUTLDTC (via CALL) to validate that each date is a genuine calendar date. Any validation failure sets an error flag, positions the cursor, and re-sends the screen (each failure point calls SEND-TRNRPT-SCREEN independently). If all checks pass, it performs SUBMIT-JOB-TO-INTRDR.
  10. No selection: shows "Select a report type to print report..." and re-sends the screen.
  11. If no error occurred, it re-initializes the input fields (INITIALIZE-ALL-FIELDS), builds a " report submitted for printing..." confirmation message, and re-sends the screen.

  12. SUBMIT-JOB-TO-INTRDR requires the user to have entered a confirmation flag (CONFIRMI):

  13. If blank, it prompts for confirmation and re-sends the screen.
  14. If Y/y, it proceeds; if N/n, it aborts (re-initializes fields, flags as handled, re-sends screen); any other value is rejected as invalid.
  15. On confirmed submission, it loops through the 1000-line JOB-LINES table (a redefinition of the hard-coded JOB-DATA JCL template, with the computed start/end dates substituted into the PARM-START-DATE/PARM-END-DATE fields), writing each line via WIRTE-JOBSUB-TDQ until it hits an /*EOF marker or a blank line.

  16. WIRTE-JOBSUB-TDQ issues EXEC CICS WRITEQ TD QUEUE('JOBS') for each JCL line, writing it to the transient data queue that (outside this program) feeds CICS's internal reader to launch the batch job. Any non-normal response is displayed via DISPLAY (developer/console diagnostic), flagged as an error, and reported to the user via the screen.

  17. SEND-TRNRPT-SCREEN first calls POPULATE-HEADER-INFO (fills in title, transaction/program name, current date/time) then sends the CORPT0A map (with ERASE or without, depending on WS-SEND-ERASE-FLG), and jumps (GO TO) to RETURN-TO-CICS, which issues EXEC CICS RETURN to give control back to CICS pending the next user action.

  18. RETURN-TO-PREV-SCREEN sets up commarea fields (from-tranid, from-program, resets CDEMO-PGM-CONTEXT) and performs EXEC CICS XCTL to transfer control to another program (COSGN00C or COMEN01C), ending this program's involvement in the conversation.

Inputs & outputs

Name Type Purpose
CORPT0A (mapset CORPT00) BMS map Screen for selecting report type (Monthly/Yearly/Custom), entering custom start/end dates, and confirming submission. Both received (CORPT0AI) and sent (CORPT0AO).
TDQ JOBS Transient Data Queue (extra-partition, implied) Destination for the generated JCL lines; presumably read by CICS's internal reader to submit the batch job TRNRPT00 running proc TRANREPT.
DFHCOMMAREA Commarea (linkage section) Carries CARDDEMO-COMMAREA (via copybook COCOM01Y) across pseudo-conversational CICS calls — holds navigation context (from/to program, tran ID, reenter flag).
CSUTLDTC External subprogram call Validates whether a given date string (in YYYY-MM-DD format) is a legitimate calendar date; returns severity/message codes.
Copybooks: COCOM01Y, CORPT00, COTTL01Y, CSDAT01Y, CSMSG01Y, CVTRA05Y, DFHAID, DFHBMSCA Copybooks Common commarea layout, map layout, title/date/message/transaction-record structures, and CICS-supplied AID key/attribute constants. No SQL tables are used by this program — all persistence/reporting work is deferred to the submitted batch job.

No files or SQL tables are directly accessed in this program (per parser facts); it only interacts with the terminal, TDQ, and commarea.

Things to know

  • No direct SQL/file I/O in this program. All actual transaction reporting happens in a downstream batch job (TRANREPT proc) submitted by writing JCL text to the JOBS TDQ — this program only prepares and sends the job stream.
  • Hard-coded JCL and paths: The entire JCL skeleton (job name TRNRPT00, class A, MSGCLASS=0, JOBLIB AWS.M2.CARDDEMO.PROC, proc TRANREPT) is embedded as literal FILLER values in working storage (JOB-DATA-1), redefined as a 1000-line table (JOB-LINES). Any change to job naming, library, or proc name requires a source code change and recompile — there's no external parameterization.
  • Fixed 1000-line JCL buffer: The loop in SUBMIT-JOB-TO-INTRDR writes up to 1000 lines or until it finds /*EOF or a blank line — since the actual template is much shorter, most iterations should exit early, but this is a manually-maintained sentinel-based design, not a count-based one; a mistake in the template (missing /*EOF and no blank filler) could cause the loop to write all 1000 (mostly blank) lines to the TDQ.
  • Typo in paragraph name: WIRTE-JOBSUB-TDQ (should be "WRITE") — an intentional artifact of the original source; found in both the flow and the facts.
  • Confirmation logic double-checks membership oddly: it first checks if CONFIRMI is blank (prompts for confirmation) and then, only if no error was raised, evaluates whether it's Y/N/other — meaning the blank-check and the Y/N evaluate are somewhat redundant/overlapping in structure but functionally guard against unconfirmed submissions.
  • Date validation quirk: The custom date-range logic treats CSUTLDTC message number '2513' as an accepted case (i.e., not treated as an error) even when severity isn't '0000' — the specific meaning of code 2513 isn't documented in the source, so this exception should be treated as unclear/undocumented behavior worth confirming with the CSUTLDTC routine's own documentation.
  • Error handling pattern: Nearly every validation failure follows the same pattern — set WS-ERR-FLG to Y, set a cursor position (-1 in some length field), populate WS-MESSAGE, and call SEND-TRNRPT-SCREEN. However, multiple validation checks in PROCESS-ENTER-KEY are not mutually exclusive with END-IF/early exit — several IF blocks execute sequentially even after an earlier one has already set the error flag and sent the screen, meaning later checks can overwrite WS-MESSAGE/cursor position from an earlier failure (the last failing check's message is what's likely retained, though each SEND-TRNRPT-SCREEN call itself returns to CICS via GOTO RETURN-TO-CICS, so in practice CICS returns after the first triggered send — worth verifying against actual runtime behavior since COBOL PERFORM here doesn't stop the surrounding paragraph from continuing after the performed paragraph returns, except that SEND-TRNRPT-SCREEN itself ends in a GO TO, which only exits that paragraph, not PROCESS-ENTER-KEY).
  • GO TO usage: SEND-TRNRPT-SCREEN uses GO TO RETURN-TO-CICS rather than a structured fall-through — a legacy pattern that jumps out of the perform hierarchy back into EXEC CICS RETURN, which is a somewhat risky/non-obvious control-flow pattern for maintainers unfamiliar with COBOL.
  • Diagnostic DISPLAY statements (e.g., 'PROCESS ENTER KEY', 'RESP:' WS-RESP-CD 'REAS:' WS-REAS-CD) appear to be leftover debug output; in a CICS environment these typically go to a system log/console rather than the user, so they don't affect the screen but do indicate incomplete cleanup from development/testing.
  • Commarea reentry flag (CDEMO-PGM-REENTER, from copybook COCOM01Y) governs whether the map is fresh

CICS commands

RETURN, WRITEQ TD, SEND, RECEIVE

Copybooks

COCOM01Y, CORPT00, COTTL01Y, CSDAT01Y, CSMSG01Y, CVTRA05Y, DFHAID, DFHBMSCA

Calls

CSUTLDTC

Paragraph flow

flowchart TD
    MAIN_PARA["MAIN-PARA"]
    PROCESS_ENTER_KEY["PROCESS-ENTER-KEY"]
    SUBMIT_JOB_TO_INTRDR["SUBMIT-JOB-TO-INTRDR"]
    WIRTE_JOBSUB_TDQ["WIRTE-JOBSUB-TDQ"]
    RETURN_TO_PREV_SCREEN["RETURN-TO-PREV-SCREEN"]
    SEND_TRNRPT_SCREEN["SEND-TRNRPT-SCREEN"]
    RETURN_TO_CICS["RETURN-TO-CICS"]
    RECEIVE_TRNRPT_SCREEN["RECEIVE-TRNRPT-SCREEN"]
    POPULATE_HEADER_INFO["POPULATE-HEADER-INFO"]
    INITIALIZE_ALL_FIELDS["INITIALIZE-ALL-FIELDS"]
    MAIN_PARA --> PROCESS_ENTER_KEY
    MAIN_PARA --> RECEIVE_TRNRPT_SCREEN
    MAIN_PARA --> RETURN_TO_PREV_SCREEN
    MAIN_PARA --> SEND_TRNRPT_SCREEN
    PROCESS_ENTER_KEY --> INITIALIZE_ALL_FIELDS
    PROCESS_ENTER_KEY --> SEND_TRNRPT_SCREEN
    PROCESS_ENTER_KEY --> SUBMIT_JOB_TO_INTRDR
    SEND_TRNRPT_SCREEN --> POPULATE_HEADER_INFO
    SEND_TRNRPT_SCREEN -.-> RETURN_TO_CICS
    SUBMIT_JOB_TO_INTRDR --> INITIALIZE_ALL_FIELDS
    SUBMIT_JOB_TO_INTRDR --> SEND_TRNRPT_SCREEN
    SUBMIT_JOB_TO_INTRDR --> WIRTE_JOBSUB_TDQ
    WIRTE_JOBSUB_TDQ --> SEND_TRNRPT_SCREEN

Paragraphs

Paragraph Line Performs
MAIN-PARA 163 RETURN-TO-PREV-SCREEN, SEND-TRNRPT-SCREEN, RECEIVE-TRNRPT-SCREEN, PROCESS-ENTER-KEY, RETURN-TO-PREV-SCREEN, SEND-TRNRPT-SCREEN
PROCESS-ENTER-KEY 208 SUBMIT-JOB-TO-INTRDR, SUBMIT-JOB-TO-INTRDR, SEND-TRNRPT-SCREEN, SEND-TRNRPT-SCREEN, SEND-TRNRPT-SCREEN, SEND-TRNRPT-SCREEN
SUBMIT-JOB-TO-INTRDR 462 SEND-TRNRPT-SCREEN, INITIALIZE-ALL-FIELDS, SEND-TRNRPT-SCREEN, SEND-TRNRPT-SCREEN, WIRTE-JOBSUB-TDQ
WIRTE-JOBSUB-TDQ 515 SEND-TRNRPT-SCREEN
RETURN-TO-PREV-SCREEN 540
SEND-TRNRPT-SCREEN 556 POPULATE-HEADER-INFO
RETURN-TO-CICS 585
RECEIVE-TRNRPT-SCREEN 596
POPULATE-HEADER-INFO 609
INITIALIZE-ALL-FIELDS 633