Hi. I'm refreshing my Cobol skills by working through 'Teach yourself Cobol in 24h'. In an example (Chapt 14a) where a ISAM-file is loaded by reading a SEQ-file the program abends with file status 21 (invalid key) at the second record. Although it's not in the book, I added with duplicates to the alternate key - just in case. But that didn't change a thing.
I checked whether the keys are in ascending order - which they are - wth this rexx script:
filename = 'dealer.txt'
counter = 1
old_key = 'A0000'
do while lines(filename)
parse value linein(filename) with 1 key 8 .
if key < old_key then do
say 'Entry' counter 'is wrong. --' key
end
counter = counter + 1
old_key = key
end
exit
I'm using cobc (GnuCOBOL) 3.3-dev.0
Write Error Dealer-Record 21 at Key
A0618
File Processed with 00001 Records Written
Never mind! I know what I screwed up. I forgot the 'LINE' sequential But then I got an error 09 Success LS Bad Data. Which I could resolve by setting COB_LS_VALIDATE to '0'. But I don't really understand why and what this means.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the reason is that dealer.txt has many NUL-Bytes before LF (linefeed) at the end of each line. GnuCOBOL can handle this with setting COB_LS_VALIDATE to 0 (off). But with this setting enabled it is more strict checking the lines of the input file.
I have replaced all NUL-Bytes in dealer.txt with spaces and with this new file dealer-clean.txt it works with or without COB_LS_VALIDATE enabled.
dealer-clean.txt works also with Rocket Cobol (Micro Focus) with the same code.
I would think checking all the programs that write dealer.txt records, and find the one(s) that write nulls, and change it there, would be the correct fix.
But good find on the compiler.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A text file by defintion is variable length.
Each record is terminated with x'0D0A' (or one of these for Linux)
A tab character is another text file space saving critter.
RALPH LINKLETTER ◙♪
SIMON◙♪
In the zOS mainframe world there is not a record format of Line Sequential.
Both the above records would be stored in a fixed length format (exclude RECFM=V)
An example would be a SYSIN dataset with a fixed length of 80 - both records 80 bytes in length.
It is odd to me that "Teach Yourself Cobol in 24 Hours" would use INDEXED on a Line Sequential dataset FD.
It seems I keep learning uses of COBOL outside of the mainframe realm.
Albeit I wonder how practical this INDEXED LINE SEQUENTIAL example is.
I think if you were to have used SPF Edit, with a fixed lenngth of 80, or Notepad++ (fixed length 80) as the program used to create the dataset the need to specify LINE SEQUENTIAL would not be required.
Live and learn :-)
Ralph
Last edit: Ralph Linkletter 2026-07-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well the indexed file wasn't declared line sequential (which isn't possible at all, is it?) It's the input file. The author used Fujitsu Cobol for a PC. But why zero's instead of blanks? I don't know.
Hi. I'm refreshing my Cobol skills by working through 'Teach yourself Cobol in 24h'. In an example (Chapt 14a) where a ISAM-file is loaded by reading a SEQ-file the program abends with file status 21 (invalid key) at the second record. Although it's not in the book, I added with duplicates to the alternate key - just in case. But that didn't change a thing.
I checked whether the keys are in ascending order - which they are - wth this rexx script:
I'm using cobc (GnuCOBOL) 3.3-dev.0
Last edit: Simon Sulser 2026-07-07
Never mind! I know what I screwed up. I forgot the 'LINE' sequential But then I got an error 09 Success LS Bad Data. Which I could resolve by setting COB_LS_VALIDATE to '0'. But I don't really understand why and what this means.
I think the reason is that dealer.txt has many NUL-Bytes before LF (linefeed) at the end of each line. GnuCOBOL can handle this with setting COB_LS_VALIDATE to 0 (off). But with this setting enabled it is more strict checking the lines of the input file.
I have replaced all NUL-Bytes in dealer.txt with spaces and with this new file dealer-clean.txt it works with or without COB_LS_VALIDATE enabled.
dealer-clean.txt works also with Rocket Cobol (Micro Focus) with the same code.
I would think checking all the programs that write dealer.txt records, and find the one(s) that write nulls, and change it there, would be the correct fix.
But good find on the compiler.
A text file by defintion is variable length.
Each record is terminated with x'0D0A' (or one of these for Linux)
A tab character is another text file space saving critter.
RALPH LINKLETTER ◙♪
SIMON◙♪
In the zOS mainframe world there is not a record format of Line Sequential.
Both the above records would be stored in a fixed length format (exclude RECFM=V)
An example would be a SYSIN dataset with a fixed length of 80 - both records 80 bytes in length.
It is odd to me that "Teach Yourself Cobol in 24 Hours" would use INDEXED on a Line Sequential dataset FD.
It seems I keep learning uses of COBOL outside of the mainframe realm.
Albeit I wonder how practical this INDEXED LINE SEQUENTIAL example is.
I think if you were to have used SPF Edit, with a fixed lenngth of 80, or Notepad++ (fixed length 80) as the program used to create the dataset the need to specify LINE SEQUENTIAL would not be required.
Live and learn :-)
Ralph
Last edit: Ralph Linkletter 2026-07-08
Well the indexed file wasn't declared line sequential (which isn't possible at all, is it?) It's the input file. The author used Fujitsu Cobol for a PC. But why zero's instead of blanks? I don't know.
The content of the CD-ROM is available here: https://archive.org/details/sams-cobol-24-hours
My guess is that you opened the file with notepad or word or a text editor.
When it was saved it became a line sequential file :-)