17 Mar
2013
17 Mar
'13
3:53 p.m.
On 2013-03-17 14:48, Mark Benson wrote:
On 17 Mar 2013, at 12:49, Johnny Billquist wrote:
PIP LB:[1,6]SYSSCAN.TMP;1/RM
Noted for future reference :)
:-)
That happened at reboot - maybe something to do with the system accounting (not that I
have much of an idea what that is)?
By the way:
.err 334
000334 (-36): %I/O-F-IE.SQC, file ID, sequence number check
Just in case you want to know. :-)
Fascinating... I assume that translates to something like "the file system says
it's there but it's not there!" :)
More or less. It's a case of you have a directory entry, but there is no actual file.
In RSX (as in VMS) that is entirely possible to have. So, the file system says the file
don't exist, but you have a "dangling pointer". :-)
I'll assume you know how Unix systems work, and I'll make an explanation based on
that.
Directory entries in RSX are the same as hard links in Unix. Absolutely the same in all
aspects. A directory entry in RSX is just the file name, and the corresponding file id it
refers to. A file id in RSX is the same as an inode number in Unix.
The biggest difference is that RSX do not do reference counting of files. Thus, you can
have several links to a file, and yet delete the file without deleting the directory
entries. At that point, the directory entries will point to a file that don't exist.
Since file IDs are reused, RSX have a second trick to avoid an old directory entry from
accidentally refer to a new file. Every time a file id is reused, a second number is
incremented, and the full file id consists of both the id number as such, and the sequence
number.
Thus, if you have a directory entry which points to a file, but the file it referred to
have been deleted, and the file id have been reused, you'll get the file sequence
error message.
As a side note, you can also refer to, and operate on files in RSX by just using the file
ids directly. You do not need to go through the directory and get a mapping from name to
id, as you do in Unix. The basic I/O operations actually take the file id as their
argument.
System accounting is essentially the keeping track of how much CPU time each user
consumes, how many pages printed, how many I/Os done, and so on...
Oh, so it's a system audit process, similar to VMS. I got it.
More or less, yes.
And yes, the error have everything to do with accounting. The accounting subsystem keeps a
snapshot on a temporary file while running. The idea is that in case of a system crash,
you'll have a fairly accurate snapshot to pick up after reboot. But occasionally,
you'll get unlucky, and the file has been deleted, but the directory entry is still
there.
Oh. That's a quaintly analogue system. "It may be able to provide a snapshot...
if it works... and the file hasn't disappeared."
:-)
Don't complain. You could run a VFY at every reboot, if you wanted better integrity
(Unix fsck anyone?). However, the file system is robust enough that it's not normally
needed.
SYSSCAN is just a program that works in a way that can cause it to trip itself up. It
could be improved to solve this. I guess that noone thought it worth the effort.
I suspect the reason is I don't actually know how to cleanly shutdown RSX-11M+. I
vaguely remember something about a SHUTUP command?
Yes, there is a SHUTUP program. Just type RUN SHUTUP.
However, apart from the accounting system, I'm not aware of anything else that gets
particularly upset.
A VFY once a year or so to check and fix up possible disk inconsistencies are a good idea,
but that's about it.
And the SYSSCAN issue is easily solved manually if needed.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic
trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" -
B. Idol