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