COBOL Terminal Input and Output: ACCEPT and DISPLAY Examples

ACCEPT reads input. DISPLAY writes output.

A small test job asks for an account number, the operator types one line, and the program prints the value to the spool. In COBOL, that simple exchange is usually built with two verbs: ACCEPT for input and DISPLAY for output.

This page explains terminal input and output in COBOL in plain English. It focuses on what a beginner sees in a batch job, TSO test, or training program: where the input comes from, where the message goes, and why these verbs should be used carefully in production code.

What Terminal Input and Output Means in COBOL

Terminal input and output means the program communicates with a person or a simple run-time device instead of reading a normal business file. In a mainframe batch job, input can come from SYSIN. Output often goes to SYSOUT, the job log, or a console-related destination depending on the compile and run-time setup.

That is different from file processing. A file program normally uses OPEN, READ, WRITE, and CLOSE with an FD entry. Terminal I/O is simpler, but it is not a replacement for structured file design. Use it for prompts, diagnostics, small utilities, classroom examples, and controlled test jobs.

ACCEPT Verb in COBOL

The ACCEPT statement moves incoming data into a COBOL data item. IBM documents that ACCEPT does not validate or edit the incoming value for you, so the program must check the field after reading it. If the user enters letters into a numeric account field, your program needs to decide what to do.

Simple ACCEPT Syntax

WORKING-STORAGE SECTION.
01  WS-ACCOUNT-NO        PIC X(10).
01  WS-REPLY             PIC X.

PROCEDURE DIVISION.
    DISPLAY "ENTER ACCOUNT NUMBER: ".
    ACCEPT WS-ACCOUNT-NO.

    DISPLAY "ACCOUNT ENTERED: " WS-ACCOUNT-NO.
    STOP RUN.

In a simple batch test, the value accepted by the program can be supplied through SYSIN. That lets a developer repeat the same test without typing at a screen every time.

Batch Test with SYSIN

//STEP01   EXEC PGM=ACCTIO
//STEPLIB  DD DISP=SHR,DSN=PROD.COBOL.LOAD
//SYSOUT   DD SYSOUT=*
//SYSIN    DD *
ACCT000123
/*

When the program executes ACCEPT WS-ACCOUNT-NO, the run-time environment can read the next available input line from the assigned input source. Site standards vary, so always check how your shop maps COBOL terminal input in batch, TSO, and z/OS UNIX runs.

DISPLAY Verb in COBOL

The DISPLAY statement writes literals and data items to an output device. With no special destination phrase, the output normally goes to the system logical output device. In a batch job, that usually means the message appears in spool output associated with SYSOUT.

Simple DISPLAY Syntax

01  WS-ACCOUNT-NO        PIC X(10) VALUE "ACCT000123".
01  WS-STATUS            PIC X(08) VALUE "ACTIVE".

PROCEDURE DIVISION.
    DISPLAY "ACCOUNT=" WS-ACCOUNT-NO
            " STATUS=" WS-STATUS.
    STOP RUN.

This is useful for small trace messages while testing. For example, a developer may display the key before a READ, then display the file status after the READ. For long-running production jobs, permanent logging rules should come from your team standard rather than scattered DISPLAY statements.

ACCEPT and DISPLAY Together

The pair is easy to understand when shown together. The program below reads an employee number and prints a clean response. It also checks that the field is not blank before continuing.

IDENTIFICATION DIVISION.
PROGRAM-ID. TERMIO.

DATA DIVISION.
WORKING-STORAGE SECTION.
01  WS-EMP-NO            PIC X(08).

PROCEDURE DIVISION.
    DISPLAY "ENTER EMPLOYEE NUMBER: ".
    ACCEPT WS-EMP-NO.

    IF WS-EMP-NO = SPACES
        DISPLAY "EMPLOYEE NUMBER IS REQUIRED"
    ELSE
        DISPLAY "EMPLOYEE NUMBER ENTERED: " WS-EMP-NO
    END-IF.

    STOP RUN.

The validation is deliberately simple. In a real payroll or claims program, you might also check length, allowed characters, and whether the key exists in a VSAM file or Db2 table.

Common Uses in Mainframe Work

Use case	Typical verb	Example
Read one test value	ACCEPT	Read an account number from SYSIN.
Print a diagnostic message	DISPLAY	Show WS-FILE-STATUS after a failed read.
Confirm selected options	DISPLAY	Print the run date, region, or control-card value.
Build a quick training program	Both	Prompt for a value, accept it, and display the result.

Validation Rules Beginners Often Miss

ACCEPT is not the same as business validation. It reads the data, but it does not prove the data is right. For a numeric field, accept into an alphanumeric work field first when bad input is possible, check it, and only then move it to a numeric field.

01  WS-AMOUNT-TEXT       PIC X(07).
01  WS-AMOUNT            PIC 9(07).

PROCEDURE DIVISION.
    DISPLAY "ENTER AMOUNT: ".
    ACCEPT WS-AMOUNT-TEXT.

    IF WS-AMOUNT-TEXT IS NUMERIC
        MOVE WS-AMOUNT-TEXT TO WS-AMOUNT
        DISPLAY "AMOUNT ACCEPTED: " WS-AMOUNT
    ELSE
        DISPLAY "AMOUNT MUST BE NUMERIC"
    END-IF.

This avoids a common beginner mistake: reading untrusted input directly into a numeric field and then wondering why the program fails later or prints confusing output.

DISPLAY Output Limits and Formatting

Keep displayed lines short. IBM documents device-related limits for displayed records, and console output is especially limited compared with ordinary spool output. A safe training habit is to display concise messages and split long diagnostic text across several lines.

DISPLAY "INPUT ACCOUNT: " WS-ACCOUNT-NO.
DISPLAY "FILE STATUS  : " WS-FILE-STATUS.
DISPLAY "ACTION       : CHECK CUSTOMER MASTER".

Avoid one huge DISPLAY line containing every field in working storage. It is hard to read in spool output, and it can be split by the output device. Short messages are easier to scan during an abend review.

ACCEPT vs READ in COBOL

Use ACCEPT when the program needs a small value from a simple input source. Use READ when the program processes records from a defined file. A batch payment program should not use ACCEPT to process thousands of payment records; it should define the input file in the Environment Division and read it record by record.

For file processing topics, continue with the Mainframe Forum guides on COBOL READ statement, COBOL file status, and COBOL OPEN statement.

How This Fits with Other COBOL Verbs

ACCEPT and DISPLAY are often the first COBOL I/O verbs a learner sees. After that, the next step is usually file input and output, then table processing, string handling, and conditional logic. Related Mainframe Forum notes include COBOL ACCEPT statement, COBOL DISPLAY statement, COBOL PERFORM statement, and COBOL data types.

Common Mistakes

Accepting Bad Data Without a Check

If a field must be numeric, test it before moving it to a numeric target. If the field must be a valid code, compare it with known values or a control table.

Using DISPLAY as a Permanent Audit Trail

DISPLAY is fine for training and controlled diagnostics. For production audit evidence, use the logging method approved for the application so operations teams can search and retain it properly.

Mixing Terminal I/O with File I/O

Do not use ACCEPT for normal transaction files just because it looks shorter than READ. File I/O gives you record definitions, file status checks, and clearer restart behavior.

FAQ

What is the COBOL terminal input verb?

The common terminal input verb is ACCEPT. It reads data from an input source and places it into the named COBOL data item.

What is the COBOL terminal output verb?

The common terminal output verb is DISPLAY. It writes literals or data-item values to the output destination used by the run-time environment.

Can ACCEPT validate input automatically?

No. ACCEPT reads the input value, but the program must validate it. Use checks such as IS NUMERIC, blank checks, valid-code checks, or file/table lookups.

Should production batch programs use ACCEPT for large input files?

No. Large business input should usually be handled with normal file processing: OPEN, READ, file status checks, and CLOSE.

References

For exact syntax and current compiler behavior, use IBM documentation for Enterprise COBOL ACCEPT statement, Enterprise COBOL DISPLAY statement, and assigning input from a screen or file.

Use ACCEPT for small controlled input, use DISPLAY for readable messages, and validate every value that can come from outside the program.

COBOL PERFORM UNTIL: TEST BEFORE, TEST AFTER, and Loop Examples

A file-reading loop usually stops when the end-of-file flag becomes true. In COBOL, that pattern is often written with PERFORM UNTIL: run the statements again and again until the condition is satisfied.

PERFORM UNTIL stops when the condition is true.

This guide explains the UNTIL phrase of the COBOL PERFORM statement with simple examples. It keeps the focus on loop control: the condition, TEST BEFORE, TEST AFTER, inline loops, paragraph loops, and the mistakes that cause endless loops.

What PERFORM UNTIL Means

PERFORM UNTIL repeats a block of code or a named paragraph until a condition is true. IBM documents that when the condition is true, control passes to the next executable statement after the PERFORM.

PERFORM UNTIL END-OF-FILE
    READ CUSTOMER-FILE
        AT END
            SET END-OF-FILE TO TRUE
        NOT AT END
            PERFORM 200-PROCESS-CUSTOMER
    END-READ
END-PERFORM.

The loop continues while END-OF-FILE is false. It stops after the READ reaches end of file and the program sets the condition-name to true.

PERFORM UNTIL Syntax

The inline form keeps the looped statements directly under the PERFORM. It ends with END-PERFORM, which makes the loop boundary easy to see.

PERFORM [WITH TEST BEFORE | WITH TEST AFTER]
    UNTIL condition
        statement-1
        statement-2
END-PERFORM.

The out-of-line form runs a paragraph or a range of paragraphs until the condition becomes true.

PERFORM 300-CALCULATE-TOTAL
    UNTIL WS-DONE = "Y".

TEST BEFORE Is the Default

If you do not code WITH TEST BEFORE or WITH TEST AFTER, COBOL assumes TEST BEFORE. The condition is checked before the first execution. If the condition is already true, the loop body does not run at all.

MOVE 6 TO WS-COUNT.

PERFORM WITH TEST BEFORE
    UNTIL WS-COUNT > 5
        DISPLAY "COUNT=" WS-COUNT
        ADD 1 TO WS-COUNT
END-PERFORM.

This loop displays nothing because WS-COUNT > 5 is already true before the loop starts. That behavior is correct, but it surprises many beginners.

TEST AFTER Runs at Least Once

WITH TEST AFTER checks the condition after the statements run. That means the body runs at least once, even when the condition is already true at entry.

MOVE 6 TO WS-COUNT.

PERFORM WITH TEST AFTER
    UNTIL WS-COUNT > 5
        DISPLAY "COUNT=" WS-COUNT
        ADD 1 TO WS-COUNT
END-PERFORM.

This loop displays one line for COUNT=6, then stops. Use TEST AFTER only when one execution is required, such as prompting once before checking whether the user wants to continue.

File Reading Example

The most common mainframe use is a file loop. The file status and end-of-file flag should be initialized before the loop, then changed inside the loop.

01  WS-CUSTOMER-STATUS    PIC X(02).
01  WS-END-OF-FILE        PIC X VALUE "N".
    88 END-OF-FILE        VALUE "Y".
    88 MORE-RECORDS       VALUE "N".
PROCEDURE DIVISION.
    SET MORE-RECORDS TO TRUE.
    PERFORM UNTIL END-OF-FILE
        READ CUSTOMER-FILE
            AT END
                SET END-OF-FILE TO TRUE
            NOT AT END
                PERFORM 200-PROCESS-CUSTOMER
        END-READ
    END-PERFORM.

This pattern is readable because the condition says what stops the loop. The loop does not depend on a hidden counter or an unclear flag name.

Counter Loop Example

PERFORM UNTIL can also control a counter. Initialize the counter before the loop and change it inside the loop. Without the change, the loop can run forever.

MOVE 1 TO WS-SUB.

PERFORM UNTIL WS-SUB > 10
    DISPLAY "TABLE ENTRY " WS-SUB
    ADD 1 TO WS-SUB
END-PERFORM.

For a pure counter loop, PERFORM VARYING may be clearer. Use the plain UNTIL form when the stop condition is tied to a flag, file status, response code, or business rule.

Inline PERFORM vs Paragraph PERFORM

Form	Use it when	Watch for
Inline PERFORM UNTIL	The loop body is short and belongs in one place.	Use END-PERFORM and keep nested statements readable.
Paragraph PERFORM UNTIL	The loop body is reused or has a clear paragraph name.	Avoid wide THRU ranges that make control flow hard to follow.

IBM notes that Enterprise COBOL supports both inline and out-of-line PERFORM. For modern code, a short inline loop is often easier to read, while a named paragraph can still be useful for a business step such as 200-PROCESS-CUSTOMER.

PERFORM UNTIL EXIT

UNTIL EXIT creates a loop that does not end from a normal condition. IBM warns that the program must reach a real escape path. In an inline loop, that usually means EXIT PERFORM.

PERFORM UNTIL EXIT
    ACCEPT WS-REPLY
    IF WS-REPLY = "Q"
        EXIT PERFORM
    END-IF
    PERFORM 100-HANDLE-REPLY
END-PERFORM.

Use this form sparingly. A named condition such as UNTIL END-OF-FILE or UNTIL WS-REPLY = "Q" is usually easier for the next developer to inspect.

Common Mistakes

Forgetting to Change the Loop Condition

If the condition never becomes true, the loop never ends. Update the counter, set the end-of-file flag, or change the response field inside the loop.

Using TEST AFTER by Accident

TEST AFTER guarantees one execution. That is useful only when one pass is required. For file reads and most validation loops, TEST BEFORE is usually safer.

Hiding Logic in a Wide THRU Range

PERFORM A-PARA THRU Z-PARA can execute every paragraph between those names. Keep paragraph ranges tight, or use inline PERFORM when the loop belongs in one place.

Related COBOL Lessons

For the broader loop family, read COBOL PERFORM statement, COBOL basic PERFORM, COBOL PERFORM TIMES phrase, and PERFORM VARYING in COBOL. For condition logic, continue with COBOL IF statement and COBOL EVALUATE statement.

FAQ

What is PERFORM UNTIL in COBOL?

PERFORM UNTIL repeats a block of statements or a paragraph until the specified condition becomes true.

Is TEST BEFORE or TEST AFTER the default?

TEST BEFORE is the default. COBOL checks the condition before the first execution unless WITH TEST AFTER is coded.

When should I use TEST AFTER?

Use TEST AFTER when the loop body must run at least once, such as asking for input once before checking whether the user wants to quit.

How do I prevent an endless PERFORM UNTIL loop?

Initialize the condition before the loop and make sure the loop body can make the condition true. For file loops, set an end-of-file flag in the AT END path.

References

For exact syntax and current compiler behavior, use IBM documentation for PERFORM with UNTIL phrase, using PERFORM, and IBM's coding a loop examples.

Write the condition so it says exactly when the loop must stop, then make sure the code inside the loop can make that condition true.