> so what can the application do with this error?  I've always
> had to get everyone out of the file and then
> do an fcopy on the message file, which gets rid of a bad (?)
> record, and then everything is fine.

There is no "bad" record. Unless you get a "bad variable block structure" or
something else, the file is fine. As Gavin explained to us in detail in '95:

"Now this is actually a *feature* of message files, which the file system
goes to a lot of trouble to implement for you. Unfortunately it's only
marginally well documented (it would be nice if there was a note in the
FREAD doc), and a lot of people have never heard of it. If you have a
message file open with write access, and the system fails, then you *will*
get this error when you later read data from the file. It does not indicate
that there is any problem with the file, but simply that the record you just
read was the last one that got written to the file before the system
crashed.

Unfortunately, most generic file reading programs don't know about FSERR
151, and many programs that are specifically using message files don't
either. The problems arise because the file system has this bit of
information it wants to pass to you, but it has no good way of getting it to
you. So when your program reads a record from the message file that 'was the
last one written before a system failure', the FREAD returns CCL and FSERR
151 to indicate it. Even though the FREAD returned CCL, the record *was*
returned to you, and
also deleted from the message file (unless you had done a non-destructive
read).

When a program gets an FSERR 151, it is supposed to ignore it unless the
application has some use for the information that FSERR 151 is giving it.
What usually happens though is that the program aborts when it gets the
unexpected 'error' reading the file. Since the record has actually been read
(and deleted) the user can just restart the program and it will continue
without errors (of course one record from the file has now been lost).

So this logic:

LOOP
  FREAD MessageFile
  IF condition-code not CCE THEN
    quit with fatal error
  ELSE
    do something with the data
ENDLOOP

will result in the above symptoms. The program will crash sometime after a
system abort, losing a record in the process. Restarting the program will
'fix' the problem, probably leaving the user thinking evil things about
message files.

This logic 'fixes' the problem too but is actually worse:

LOOP
  READANOTHER:
  FREAD Message File
  IF condition code not CCE then BEGIN
    FCHECK to get FSERR
    IF FSERR is 151 then GOTO READANOTHER
    ELSE
      quit with fatal error
  END
  do something useful with the record
ENDLOOP

The problem is that the programmer who wrote the above has learned that
FSERR 151s should be ignored, but in his attempt to 'ignore' the error, he
is also throwing away a valid record from the file. A correct way of dealing
with the FSERR 151 is to treat the CCL/FSERR 151 the same as though a CCE
had been returned, for example:

LOOP
  FREAD Message File
  IF condition-code is not CCE then BEGIN
    FCHECK to get FSERR
    IF FSERR <> 151 THEN
      quit with fatal error
  END
  process the record normally
ENDLOOP

(of course a real program would be cheking for EOF, etc too).

G."

In summary:
 1) Treat FSERR 151 as "not an error".
 2) In particular, when you get CCL/151, *don't* throw away what was read.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *