[Info-vax] queue errors

[Tom Adams]

On Oct 17, 9:13 am, Tom Adams <w.tom.ad... at gmail.com> wrote:
> On Oct 17, 8:58 am, Tom Adams <w.tom.ad... at gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Oct 17, 5:01 am, Jan-Erik Soderholm <jan-erik.soderh... at telia.com>
> > wrote:
>
> > > abrsvc wrote 2012-10-17 03:06:
>
> > > > On Tuesday, October 16, 2012 8:22:53 PM UTC-4, (unknown) wrote:
> > > >> IIRC (and it's been a while), Fortran defaults to file names like
> > > >> FORnnn.DAT if you don't specify a file in the OPEN command or you
> > > >> don't have a logical name FORnnn pointing to a file. I suggest that
> > > >> you check the name of the file you were trying to write to. Also, did
> > > >> you compile with /CHECK ? Memory corruptions can cause error messages
> > > >> that refer to unrelated issues (e.g. odd hardware, odd system
> > > >> functions).
>
> > > > We do this all the time at the client where I now am working.  Yes, the
> > > > default filename is FORxxx where the xxx is the Fortran unit number.
> > > > This is common for printfiles that are sent directly to a print queue.
> > > > The problem was likely a disconnec with the actual printer.  I have seen
> > > > this before.  You should be able to recover the file using
> > > > analyze/disk.
>
> > > Now, *why* would one want to "recover" the file ?
>
> > > If the file is lost from disk, just delete the queue entry.
>
> > > If the file is still on-disk, just /RESTART the entry, maybe
> > > with a /REQUEUE=xxx to another queue if the error is persistent.
>
> > > Or simply ask the end-user to reprint whatever it was.
>
> > > Jan-Erik.
>
> > > > Dan
>
> > The files are log files from a system that don't make it to the
> > logger.  Not printed by an end-user.
>
> > But we do have it all in a disk log that loses nothing.  So the losses
> > are not real important, but they have gotten on a todo list prepared
> > by QA.
>
> > I am looking into this because the QA people tend to focus on the
> > paper log. A bit hidebound and not totally rational I know.
>
> > If I had the files, I could tell exactly what is missing from the
> > paper log with little effort.
>
> > As things stand, we go to the disk log if someone notices that
> > something seems to be missing from the paper log.  That has only
> > happened once in more than a decade.
>
> Or rather a missing messsage was noticed and traced to this queue
> error only once.
>
> A paper jam can caused missed messages, but that is obvious to the
> paper log reader.

It just occurred to me that I have a way to locate the missing
messages.

The disk log messages are timed stamped and the queue error still in
the
queue are timestamped.  So, by comparing timestamps I should be able
to locate the specific message that is missing from the paper log.