COBOL:当两者都返回代码10时,如何区分文件结尾和垃圾值?

Sus*_*wat 1 cobol

我正在研究富士通COBOL,有一种情况我必须阅读文件,如果有垃圾值,那么我想要找到工作.

当有一个垃圾值时,返回码为10,但是当有EOF(文件结束)时,即使那时返回码为10.

请帮助我如何根据返回代码区分这两个事件?

Ric*_*ith 5

在早期的PC(MS-DOS 1.0)上,使用Ctrl + Z(X"1A")作为文本文件的结尾.您的编译器可能会检测到该字符并将其视为end-if-file,而不是允许处理该文件的其余部分.

在OEM/DOS字符集中,X"1A"显示为向右箭头.(你在评论中提到了一个箭头.)我创建了一个包含四个记录的短文件进行测试.

原始文件:

Record1
Record2
Record3
Record4
Run Code Online (Sandbox Code Playgroud)

我用X"1A"替换了"3".在十六进制编辑器中,它显示为,

十六进制编辑修改记录的图像

请注意,x"1A"字符显示为向右箭头.

A写了一个程序(未示出)来读取显示修改文件输出的文件.

Record1
Record2
Record
0003 lines read
Run Code Online (Sandbox Code Playgroud)

文件结束发生在X"1A".

以下程序可用于检查X"1A"和"识别损坏的记录发生...以便[您]可以更正文件".

   program-id. ctrl-z.
   environment division.
   input-output section.
   file-control.
       select in-file assign "ctrl-z.txt"
           organization sequential
       .
   data division.
   file section.
   fd in-file.
   1 in-char pic x.
   working-storage section.
   1 line-count binary pic 9(4) value 0.
   1 msg-txt pic x(25) value "lines read".
     88 error-msg value "lines read before cntrl-z".
   1 eof-in-file-flag pic 9 value 0.
     88 eof-in-file value 1.
   procedure division.
   begin.
       open input in-file
       read in-file
           at end set eof-in-file to true
       end-read
       perform until eof-in-file
           evaluate in-char
           when x"0A"
               add 1 to line-count
           when x"1A"
               set error-msg to true
               set eof-in-file to true
               exit perform
           when other
               continue
           end-evaluate
           read in-file
               at end set eof-in-file to true
           end-read
       end-perform
       close in-file
       display line-count space msg-txt
       stop run
       .
   end program ctrl-z.
Run Code Online (Sandbox Code Playgroud)

结果是:

0002 lines read before cntrl-z
Run Code Online (Sandbox Code Playgroud)

  • 这不是"垃圾价值"!运行时系统认为X"1A"是文件的结尾,因此将"FILE STATUS"设置为10.忽略该字符后面的所有数据.早期的系统用于以固定的128字节块写入文本文件,因此,即使文本的最后部分没有占据整个块,X"1A"也会告诉程序停止读取.这很快就更改为使用文件名存储文件长度,但旧文件仍然存在.有些是从CP/M移植到MS-DOS之前的几年. (3认同)