Menu
▾
▴
#1120 perform not stopping
doing a perform until eof. program reads an extra record after eof. 5 records in file but 6 records read.
running gnucobol 3.2.source as follows:
IDENTIFICATION DIVISION.
PROGRAM-ID. DGLT0004.
*AUTHOR. D.G.LANG.
*****************************************************************
* THIS IS A SIMPLE PROGRAM WHICH ONLY READS A FILE AND DISPLAYS*
* THE RECORD WHICH WAS READ. *
*****************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES.
REPOSITORY. FUNCTION ALL INTRINSIC.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT INPUT-FILE ASSIGN INPUT-NAME
ORGANIZATION LINE SEQUENTIAL.
DATA DIVISION.
FILE SECTION.
FD INPUT-FILE.
01 INPUT-RECORD.
05 INPUT-RCRD-ID PIC X(02).
05 INPUT-FID PIC X(04).
05 INPUT-TYPE PIC X(01).
05 INPUT-LENGTH PIC 9(02).
05 INPUT-INTEGERS PIC 9(02).
05 INPUT-DECIMALS PIC 9(02).
WORKING-STORAGE SECTION.
01 MISC-DATA.
05 INPUT-NAME PIC X(20) VALUE
'S:\DATA\DGLP0003.TXT'.
05 INPUT-FILE-EOF-SW PIC X(01) VALUE 'N'.
PROCEDURE DIVISION.
OPEN INPUT INPUT-FILE.
PERFORM 0000-READ-INPUT-FILE UNTIL INPUT-FILE-EOF-SW EQUAL 'Y'.
CLOSE INPUT-FILE.
GOBACK.
0000-READ-INPUT-FILE SECTION.
READ INPUT-FILE AT END
MOVE 'Y' TO INPUT-FILE-EOF-SW
GO TO 0000-EXIT.
DISPLAY 'INPUT-RECORD ' INPUT-RECORD.
0000-EXIT. EXIT.
input file:
02AS X010000
02ARB X010000
03AT X010000
03BKDFX010000
01BOFCX010000
results:
INPUT-RECORD 02AS X010000
INPUT-RECORD 02ARB X010000
INPUT-RECORD 03AT X010000
INPUT-RECORD 03BKDFX010000
INPUT-RECORD 01BOFCX010000
INPUT-RECORD 0
I've experienced a similar problem once before. An inline perform works perfectly but performing a paragraph or section id buggy.
Gen AI apps are built with MongoDB Atlas
Atlas offers built-in vector search and global availability across 125+ regions. Start building AI apps faster, all in one place.
Change line with 0000-EXIT. EXIT to
0000-Exit. EXIT SECTION.
I've added the section clause but get the same results. FWIW, the code as originally submitted was modified by the web to remove leading and duplicate spaces, I've attached a jpg of the modified code.
Last edit: Daniel G Lang 2025-06-07
On a perform until statement, the until clause should be considered before even doing the first perform. Once the EOF sw is set, the paragraph/section should not be performed. It appears that the interrogation of the EOF sw doesn't happen until after the performed paragraph/section is actually performed.
Shouldn't the PERFORM statement also be corrected to include the THRU EXIT clause?
I would think it needs to look something like:
PERFORM 0000-READ-INPUT-FILE THRU 0000-EXIT
UNTIL INPUT-FILE-EOF-SW EQUAL 'Y'.
No, it is performing a section so using thru is invalid and for that matter serves no purpose as it is only used for paraagraphs.
Paragraph 0000-READ-INPUT-FILE is a SECTION, 0000-exit is a paragraph within that SECTION. By definition, all paragraphs under a section are part of that section until another section is encountered. There is no need for a perform through.
Last edit: Daniel G Lang 2025-06-07
I've modified the code to do an "in line" perform with a "look ahead" read. Same results.
Last edit: Daniel G Lang 2025-06-07
If file is at EOF before the perform, it works perfectly.
Last edit: Daniel G Lang 2025-06-07
Add an if statement before the read ie if EOF go to exit, i.e., :
IF INPUT-FILE-EOF-SW go to 0000-exit
READ INPUT-FILE AT END etc..
I use this for all such READ statements when only setting a switch.
And for the perform change to .
PERFORM with test before 0000-READ-INPUT-FILE UNTIL INPUT-FILE-EOF-SW EQUAL 'Y'.
I always add a go to when EOF is encountered and it was there in the original coding.
I modified the code to add "with test before" and that works correctly.
My work experience was always with large IBM mainframes and the compiler standard was always with test before and therefore I never had to code it before.
Thanks much for the heads up and answer, Dan
Last edit: Daniel G Lang 2025-06-07
The following code works properly:
Last edit: Daniel G Lang 2025-06-07
The following code does not.
Last edit: Daniel G Lang 2025-06-07
On 07/06/2025 19:03, Daniel G Lang wrote:
What following code ?
Last edit: Simon Sobisch 2025-07-03
The logic was in the attachments.
in the meantime, here (in the attachments) is another sample which works correctly
Last edit: Daniel G Lang 2025-06-08
Please edit your post, attaching the source not an image of it.
The scope of some Cobol verbs can vary depending on what dialect is set via -std= option and compiler directives when compiling such as via -f options.
For safety add such a sub clause in. In this way your KNOW when it will be tested for.
Or "Don't Assume". Sorry been cobol programing since 1962 or so so I avoid assuming the compiler creates correct code, ever :)
There again I have used a very large number of compilers from m/f, mini's and micros in all that time and mileage varies and even more so with m/f's.
while with test before works perfectly with an inline perform, it fails when performing a paragraph section.
Last edit: Daniel G Lang 2025-06-07
I agree with you about NOT assuming things. Most people pronounce ASSUME as a two syllable word when it is actually a THREE syllable word pronounced as ASS U ME because when we assume things it makes as ass of ourselves and anyone we share that assumption with..
In the past, I've only attached pictures of the relevant portion of code involved wanting to focus on that and assuming that that was sufficient. In the future, I will attach all of the code and data so you can download and test yourself.
I apologize for my assumption.
I apologize for the delay, due to health problems accompanied by multiple clinic, doctor, and hospital visits I let the problem sit for awhile.
There was no problem with any of the ways I coded the program, the problem solely lay in the way I created the input file using a text editor.
I used first Note-pad, then Word-pad, and finally Edit-pad all with the same errors occurring in the programs which read the input file.
I wrote a small COBOL program to create the file from a table and then my program worked correctly.
It seems that a regular text editor inserts a line or file terminator after the last record or at the end of the last record while a file created by a COBOL program doesn't have the same file ending.
Reading a file created by a text editor in a COBOL program somehow gets an extra (bogus) input record.
Many years of using the ISPF editor on a mainframe never caused this problem.
I should have recognized this earlier since when I copied COBOL source programs which were created on a IBM mainframe over 25 years ago I didn't have the same extra record at the end.
So after all that got down to "always validate input data before processing" rule (that must have existing "on the mainframe" as well), right?
Without following all the details: why does the
PERFORM paragraphworks "as expected" while the inline perform did not?Viewing the original input file which was created/recreated using 3 different text editors did not reveal the presence of any additional "control characters" or other data after the last line. As I mentioned, creating a similar file on the mainframe using the ISPF editor never added any additional characters and I was simply unaware of a PC text editor adding any invisible characters at the end.
In so far as some of the tests being successful, I ran the input file through a simple cobol copy program which deleted the added characters after the last valid line before running the other tests so they were successful. With all that was going on at the time, I simply failed to mention that fact.
The bottom line is that it should be notated/mentioned/stressed to not use a standard text editor to create test data due to the additional characters. Hopefully, my experience with this problem might help others with similar unexplained problems.
Last edit: Daniel G Lang 2025-07-03
Diff:
closed per original author's "no bug, just unexpected input file with additional line ending"