Hi. I started with COBOL and because the most books available are dealing with older compilers I am doing my first steps with RM/COBOL for DOS, which is "freely" available. From time to time I try to compile the code with GnuCobol. And here is a case I can't compile with the latter.
I wrote a program to create a data file and add entries to it. It compiles without error in RM/COBOL. But with GnuCobol there is a error status = 71:
When I do with a WORKING-STORAGE area (commented out below), then it compiles with GnuCobol. Any idea why that is?
You should be able to compile the code with GnuCOBOL - if you use a file and you get a status 71 then you have invalid data (per COBOL2023 LINE SEQUENTIAL), but for compatibility with other environments you can disable the data check, for example using an environment variable COB_LS_VALIDATE=N, also see the 3.2 NEWS file and the runtime configuration (which is nicely included in the manual).
... but just glancing on your code there should be no invalid data. Maybe the input on that console is getting strange entries in? You could easily check be enabling the external console in the program configuration. If you still get status 71 there, then please run with COB_LS_VALIDATE=N and upload the result program, allowing us to check what's actually in there.
Last edit: Simon Sobisch 2023-10-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, just tested that myself - the issue is the uninitialized FILLERs.
If you want to include them in the INITIALIZE then you have to code INITIALIZE AUSGABE-DATEI-RCD WITH FILLER, but the solution to make that work is more easy: just add a VALUE SPACE to all of your FILLER definitions and you should be good and produce a readable file in all COBOL environments.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This should be the default COB_LS_VALIDATE=N
Perhaps if I were on the COBOL standards committee - I would enable this "advanced" feature.
I am not.
I do not know anybody that is.
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually this is one of the cases where I think this is quite useful.
The OP likely did not want low-values (or other garbage) in his LINE SEQUENTIAL file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would suggest that you issue the following statement immediately after opening your output file and then again after each WRITE verb as well
MOVE SPACES TO AUSGABE-DATEI-RCD.
the reason for this is that on some compilers the location of the 01 level in the FD is actually in a buffer. The buffer can be large enough to contain multiple records, so when the WRITE verb is issued, the runtime may actually just move the pointer to the record which the operating system may or may not have initialized.
So the above practice ensures that the record area is set to spaces before any other data is moved to it. This should eliminate the issue you encountered with the status 71.
As a best practice I would recommend always using the FILE STATUS IS xxxx clause as part of the SELECT statement. Then after every I/O operation on the file, check the file status variable to ensure that the I/O was successful. You can check the programmers guide for more information on this.
Chuck Haatvedt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I kept getting the status = 71 error on a practise file downloaded from course material. I spent a long time trying to find uninitialized data but it turned out that as the input file had been downloaded from a mainframe there was an additional CRLF at the end and that was causing an extra read and that generated the error. Once deleted the program ren properly and EOF was found.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi. I started with COBOL and because the most books available are dealing with older compilers I am doing my first steps with RM/COBOL for DOS, which is "freely" available. From time to time I try to compile the code with GnuCobol. And here is a case I can't compile with the latter.
I wrote a program to create a data file and add entries to it. It compiles without error in RM/COBOL. But with GnuCobol there is a error status = 71:
When I do with a
WORKING-STORAGEarea (commented out below), then it compiles with GnuCobol. Any idea why that is?Last edit: Simon Sobisch 2023-10-17
There is a mix-up of "compile" and "run".
You should be able to compile the code with GnuCOBOL - if you use a file and you get a status 71 then you have invalid data (per COBOL2023 LINE SEQUENTIAL), but for compatibility with other environments you can disable the data check, for example using an environment variable
COB_LS_VALIDATE=N, also see the 3.2 NEWS file and the runtime configuration (which is nicely included in the manual).... but just glancing on your code there should be no invalid data. Maybe the input on that console is getting strange entries in? You could easily check be enabling the external console in the program configuration. If you still get status 71 there, then please run withCOB_LS_VALIDATE=Nand upload the result program, allowing us to check what's actually in there.Last edit: Simon Sobisch 2023-10-17
OK, just tested that myself - the issue is the uninitialized
FILLERs.If you want to include them in the
INITIALIZEthen you have to codeINITIALIZE AUSGABE-DATEI-RCD WITH FILLER, but the solution to make that work is more easy: just add aVALUE SPACEto all of yourFILLERdefinitions and you should be good and produce a readable file in all COBOL environments... or not, at least the
VALUEdoesn't help,INITIALIZE AUSGABE-DATEI-RCD WITH FILLER(or giving all filler field a name) does.This should be the default COB_LS_VALIDATE=N
Perhaps if I were on the COBOL standards committee - I would enable this "advanced" feature.
I am not.
I do not know anybody that is.
Ralph
Actually this is one of the cases where I think this is quite useful.
The OP likely did not want low-values (or other garbage) in his LINE SEQUENTIAL file.
Hello,
I would suggest that you issue the following statement immediately after opening your output file and then again after each WRITE verb as well
MOVE SPACES TO AUSGABE-DATEI-RCD.
the reason for this is that on some compilers the location of the 01 level in the FD is actually in a buffer. The buffer can be large enough to contain multiple records, so when the WRITE verb is issued, the runtime may actually just move the pointer to the record which the operating system may or may not have initialized.
So the above practice ensures that the record area is set to spaces before any other data is moved to it. This should eliminate the issue you encountered with the status 71.
As a best practice I would recommend always using the FILE STATUS IS xxxx clause as part of the SELECT statement. Then after every I/O operation on the file, check the file status variable to ensure that the I/O was successful. You can check the programmers guide for more information on this.
I kept getting the status = 71 error on a practise file downloaded from course material. I spent a long time trying to find uninitialized data but it turned out that as the input file had been downloaded from a mainframe there was an additional CRLF at the end and that was causing an extra read and that generated the error. Once deleted the program ren properly and EOF was found.