rod@CHEETA.ISI.EDU (Rod Van Meter) (12/08/87)
Stephen Lui asked about processor registers during boot. My
understanding is that the registers are used the same on all Vaxes.
VMB.EXE uses them to find out where to go for its info. The only
difference is the front-end command processor. So modifying the 780's
DEFBOO.CMD to include the line
DEPOSIT R2 0F00
(or whatever the numbers may be) should work. Note, though, that the
higher numbered one must come first. The system manager's reference
contains a description of this on page 4-14, and I think there's
a more technical description of booting in the Internals and Data
Structures book.
Now it's my turn. I've got two minor problems.
1) (I'm a little fuzzy on this one, so bear with me) A user has a magtape
which wasn't written on a VAX. It's not even ANSI labelled. Just raw
data from some brain-damaged system or another. We know the block size
is 2048 and that the last one is short. This is what they tried:
$ MOUNT/FOR MUA0:/BLOCK=2048
$ COPY MUA0: FILENAME
but this seems to lose the last record. The last block contains just over
1K bytes, so it writes two 512 byte records, then loses the last few
bytes.
Trying it with /RECORD=2 seems to work OK, though I think they then
had to diddle the file a little bit to make the records happy again.
Is this the correct behavior, and how can we always be sure we're getting
everything off the tape? I haven't actually messed around with this yet
so all this is second hand...
2) This one's no big deal, but an interesting curiosity all the same.
Under MicroVMS 4.4, it seems, a SPAWN causes at least three SRPs to
be allocated from nonpaged pool. One of them doesn't get returned when
the spawned process exits, though. This means that if you're doing a
lot of spawning (always fun), eventually you run out of ready-made ones
and have to create some more, and then eventually you hit the maximum
and begin using variable-length allocation routines, which is REALLY
SLOW, particularly when you just want the packets for terminal I/O.
You can expect it to give up the ghost at some point after this, too.
This behavior doesn't show up on our big Vaxes running VMS 4.5. I
have seen no mention of this in the release notes or system
dispatches. Has anyone else seen this behavior, and is it fixed in uVMS
4.5 or 4.6? Did it exist in VMS 4.4? If I read SDA correctly, they're
BUFIO packets that are getting lost. They're still in the chain of inuse
packets, but nobody knows to let go of them.
For the curious, we found about this because of lazy programming practices.
Our local guru (nay, genius, but not particularly rigorous about his
programming) had a process which he wanted to sleep for a few minutes,
then wake up. Since he already had a SPAWN command built in, he just
spawned a DCL WAIT command rather than bother to add some hibernate code.
After a week or so he began to run out of pool...
--Rod
rod@ISI.Edu