We shall discuss this, Minakshi-chan. First, though, note that you ought to enclose any information where alignment is significant (and it is
very significant in both the input data and the report) in Code tags, so as to preserve that alignment. Note the differences in the appearance of my report and your mock-up.
Now, to discussion. Leaving aside for moment the variable declarations and overhead, the logic begins with:
on endfile (tulin) eof_tulin = true;
read file (tulin) into (input_record);
The second statement is of course a mere I/O statement; the file
tulin is being read into the variable
input_record. In COBOL, the file definition (FD) must include some sort of record definition. However, this definition represents the actual I/O buffer; as the data in the buffer are volatile, you should always read into and write from working storage, so as to be sure the data are available when needed.
In PL/I I simply write
dcl tulin file record input,
whereas in COBOL you need a more complex definition. As I said
supra, it has been many years since I programmed in COBOL, but IIRC the definition would be:
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT INPUT-FILE ASSIGN TO TULIN.
[...]
DATA DIVISION.
FILE SECTION.
FD INPUT-FILE
DATA RECORD IS INPUT-BUFFER.
01 INPUT-BUFFER PIC X(329).
In the FILE-CONTROL paragraph, you use the SELECT statement to associate a COBOL internal file, that I have named INPUT-FILE, with a external file, TULIN; in MVS this will be the name of the DD statement defining the actual data set in the JCL. In the FILE section, you then create a FD for the internal file.
Note that I have defined a
on endfile statement for
tulin. When a PL/I program is compiled, object code is generated so that when the end of the data set associated with
tulin is reached, control is transferred to the
on statement and then, when it executes, returns to the point of origin. In COBOL, this must be done explicitly, so that
read file (tulin) into (input_record);
Becomes
READ INPUT-FILE INTO INPUT-RECORD
AT END MOVE 'Y' TO EOF-INPUT-FILE.
where, of course, EOF-INPUT-FILE is a PIC X variable in working storage, initialized to something
other than 'Y' ('N' would be conventional and easy to interpret, but not absolutely necessary).
That’s enough for one morning. Digest that, and we shall then continue.
"You have sat too long for any good you have been doing lately ... Depart, I say; and let us have done with you. In the name of God, go!" -- what I say to a junior programmer at least once a day