HP3000-L Archives

August 1997, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Roy Brown <[log in to unmask]>
Reply To:
Roy Brown <[log in to unmask]>
Date:
Fri, 22 Aug 1997 13:09:27 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (86 lines)
In article <[log in to unmask]>, Richard Corn
<[log in to unmask]> writes
>At one time, message files were susceptible to corruption if
>the accesing program was aborted or the system aborted. If
>you were using a message file to queue records for processing
>and a failure occurred, message file corruption would cause
>loss of such queue records.
>
>Is this still the case today or has this issue been dealt with
>as MPE has moved forward?  Can message files be relied upon to
>retain records if the system or writting program fails? What
>is the current reliability of message files as a persistent
>queueing mechanisim?
>

Excerpts from the LaserRom (Nov 1996):

(Intrinsics Manual, FCONTROL, 6)

    *   If used for message files, it verifies the state of the file
        by writing the file label and buffer area to disk; ensures the
        message file can survive system crashes.  No EOF is written.

(Interprocess Communication:Programmer's Guide)

Forcing Records To Disc

Message files reside primarily in buffers, and they can lose data in the
event of a system crash.  For applications that must use message files
and must be "crash-proof," MPE XL provides a way to force the data to
disc.

This is done by using FCONTROL with a controlcode of 6.  Either readers
or writers can call this intrinsic.  It forces all buffers to be written
to disc and the disc file label to be updated.  This causes several disc
I/Os and, therefore, takes a relatively long time.  It must be done
after each FWRITE to be most effective, and even then there is a
"window" between the FWRITE and the FCONTROL during which a crash would
cause the record to be lost.

Remember that IPC is designed to be a fast, efficient means of passing
messages between processes.  If the task the application is performing
is really event logging, and it must be highly crash-resistant, you
should consider using "circular files" or other files with FSETMODE.
(FSETMODE is ignored for message files.)  For more information about
FSETMODE, refer to Accessing Files (32650-90017) and the MPE XL
Intrinsics Reference Manual (32650-90028).

(end of excerpts)

So there you have it. Are you writing your own code, or considering
other peoples' code? If the latter, do you have any influence over how
it is written?

We have added FCONTROL 6s to all our 'persistent' message files, with a
welcome reduction in the incidence of corrupted ones as a result. Only
message files will do the job we want. so we can't use any other sort.

Accessing Files, as far as I can tell with the manky antiquated
inefficient junkheap that passes for LaserRom software, doesn't even
mention FSETMODE, and I cannot remotely see the relevance of it, from
the point of view of crash recovery, from the entry in the Intrinsics
manual.

<Rant mode on>

(That right, HP? I can't just search one manual alone without making a
custom bookshelf, adding just that manual to it, and THEN searching it?
And when I *do* find the reference, I've no idea how that ties up with a
page of the dead tree edition? Which I want to use, because reading it
off the LaserRom is about as cumbersome as the legendary gynaecologist
painting his front hall?)

<Click, double-click, select Close, click, highlight so it's not greyed
out, click, maximise, click, minimise, click, click. Rant mode off - >

Anyway HTH


Roy Brown
--
Roy Brown               Phone : (01684) 291710     Fax : (01684) 291712
Affirm Ltd              Email : [log in to unmask]
The Great Barn, Mill St 'Have nothing on your systems that you do not
TEWKESBURY GL20 5SB (UK) know to be useful, or believe to be beautiful.'

ATOM RSS1 RSS2