Leonard writes:
> CURRENT RECORD WAS LAST RECORD WRITTEN BEFORE SYSTEM CRASHED (FSERR 151)

As Steve said, this is not a problem with the message file, but a problem
with the application that's reading the message file but does not understand
how message files work.

When the system crashes, any message files open for write access which have
records written to them will get a little note added to the file after the
machine comes back up to indicate the point at which the system failed.
This flag gets attached to the last record in the message file at the time
it is next opened, and when that record is read the read succeeds but the
FSERR 151 is returned so that the program can take appropriate action.  This
is quite a nice feature actually, and is really a requirement if you're
using message file features like reading writer ids, etc.

It probably would have made more sense for this error to only be returned if
the user has the "read writer ids" flag turned on for the message file,
since this is the most likely time that you'd care about these "errors" and
would indicate that the program knows it's reading a message file.  For
ordinary readers the error would simply be ignored for you.  This would
allow programs that don't know they're reading a message file to operate
properly in this case (plus or minus the application design).  But of course
it's too late to change things now.

In your current case, if the program reads the file "destructively" then the
problem has probably just fixed itself as in getting the above error the
program will have deleted this record from the file and if you start up the
reader process again, you'll find that it works fine.  Of course if this is
the case then you've *lost* one record of data from the message file and
you'll need to figure out what, if anything, you need to do to recover from
this data loss.

If you start up the reader program again and get this error a second time,
then your program is reading the file "non-destructively" and your choices
are to either fix the program (probably to ignore the FSERR 151 and treat it
as a *successful* read) or to use some method to read a single record from
the message file in order to eliminate the record with the system abort flag
attached (though again this record may have data you want in it) or you can
stop everything and copy the file into a new message file, but again you'll
have to use a program that is smart enough to ignore the error 151 (which
FCOPY probably isn't).

You should make sure that if you modify the program to ignore the error that
you don't simply say "if we get an error 151 then go back and try the read
again" since this will cause you to lose the records that have the 151 error
attached to get lost.  I suspect there are a few programs out there in the
world with this problem.

G.

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