CICS ISSUE ENDFILE

ISSUE ENDFILE is a CICS command that signals the end of file (end of data) to a destination. When your program has been sending data to a destination—for example a printer or a terminal used for print—you issue ISSUE ENDFILE to tell that destination that no more data will follow. The destination can then complete the print job, close the logical file, or perform any cleanup. This quick reference covers the syntax, parameters, typical use with printing, and how it differs from ISSUE EOI.

Explain Like I'm Five: What Is ENDFILE?

Imagine you are handing pages to someone who is stacking them. When you have given them the last page, you say "that's all" so they know they can staple the stack and finish. ISSUE ENDFILE is like saying "that's all" to the printer or destination: you have sent all the data, and now you are telling it there is no more coming so it can finish the job.

When to Use ISSUE ENDFILE

Use ISSUE ENDFILE when your transaction sends a stream of data to a destination (e.g. a CICS printer or a terminal used for print) and you need to signal that the stream is complete. Without ENDFILE, the destination might wait for more data or might not finalize the job correctly. You typically send data using SEND with the PRINT option, or by writing to a destination via other CICS facilities; after the last send or write, you issue ISSUE ENDFILE with the same destination so it knows to close the file or complete the print. Do not use ENDFILE before you have sent any data; use it only after all data has been sent.

Command Syntax

1
2
3
4
5
EXEC CICS ISSUE ENDFILE
    DESTID(dest-id)
    [RESP(response-code)]
    [RESP2(reason-code)]
END-EXEC

DESTID specifies the destination that receives the end-of-file signal. It is the same destination (e.g. terminal ID or destination name) you used when sending the data. RESP and RESP2 are optional; you should specify them so you can check for success or handle errors.

Parameters

Typical Flow: Sending Output Then ENDFILE

A typical pattern is: (1) establish or use a destination (e.g. a printer terminal); (2) send data to that destination one or more times (e.g. SEND with PRINT, or equivalent); (3) when all data has been sent, issue ISSUE ENDFILE DESTID(same-destination); (4) check the response. The destination receives the data and then the ENDFILE signal, and can complete the job. If you use START to create a print task that reads data via RETRIEVE and then sends to a printer, the started task would send the data and then issue ENDFILE to the printer destination when done.

1
2
3
4
5
6
7
8
9
10
* After sending all report lines to printer PRT1...
EXEC CICS ISSUE ENDFILE
    DESTID('PRT1')
    RESP(WS-RESP)
END-EXEC.
IF WS-RESP = DFHRESP(NORMAL)
    * Print job completed
ELSE
    * Handle error (INVREQ, NOTAUTH, etc.)
END-IF.

Response Codes

Always check the response after ISSUE ENDFILE. If the destination is not open, not valid for ENDFILE, or the task is not authorized, CICS returns an error. Use RESP2 for additional reason codes when troubleshooting.

ISSUE ENDFILE vs ISSUE EOI

ISSUE EOI (end of input) signals that input from a source is complete—for example, you have finished reading from a device or stream. ISSUE ENDFILE signals that output to a destination is complete—you have finished sending data to a destination. So EOI is for the input side, ENDFILE for the output side. Use ENDFILE when you are the sender and want to tell the destination "no more data"; use EOI when you are the reader and want to signal "no more input."

Step-by-Step: Using ISSUE ENDFILE After Printing

1. Identify the destination (e.g. printer terminal ID or destination name) you will use for output.
2. Send all report or output data to that destination using the appropriate CICS commands (e.g. SEND with PRINT, or writing to the destination).
3. When there is no more data to send, issue EXEC CICS ISSUE ENDFILE DESTID(dest-id) RESP(response-code).
4. Check the response code. If NORMAL, the destination received the end-of-file signal. If not, handle INVREQ, NOTAUTH, or other errors and optionally retry or report.

Best Practices

• Issue ENDFILE only after all data has been sent to the destination; do not issue it before or in the middle of sending.
• Use the same DESTID for ENDFILE that you used when sending the data.
• Always specify RESP (and RESP2 if needed) and check the response; handle errors so the task does not assume success.
• If the destination is a printer, ensure the printer definition and your task's authority allow ISSUE ENDFILE for that destination.

Test Your Knowledge