On Apr 19, 20:12, Daniel A. Seagraves wrote:
> Subject: Oh, s**t. Someone tell me I'm wrong...
OK :-) You're wrong :-)
> To talk to the RL02, I had to UNLoad the DY: driveer and LOAd teh DL: driver.
> This means that RL support isn't in the montior.
Not exactly, it may just mean that the driver isn't loaded by default. None of
the drivers are "in" the monitor, they're all loaded (some with the system
image, some not).
> Since I'm switching boot
> devices to one not in the monitor, I have to re-SYSGEN RSX-11M.
> But, I don't have Sysgen or HRC, so I'm screwed, right?
Not necessarily. SYSGEN recreates the whole system from the source code. All
you need to do (assuming the original was built with suitable options) is to
get it to reset its pointers, in a manner of speaking. You won't have HRC
unless it's an RSX11M-plus system.
> That would be why BOO looped forever on both systems, the monitor was told to
> boot a device it had no support for.
> Does this sound correct?
I don't think so.
I'm not an expert on RSX, but I've done 4 or 5 sysgens -- though it was a few
years ago. The drivers were probably all built at the same time -- and
therefore with the same options -- as the rest of the system. Take a look at
the dates/times on the xxDRV.TSK and RSX11M.TSK files in [1,54] to be sure.
The RSX11M.SYS file should be much bigger, and have a later time, than the
RSX11M.TSK file. What you're probably seeing, is that the system was built
with a certain amount of space allocated for drivers, but only the ones
originally required are loaded with the system image by default, and to get
space for another, you need to unload one.
As for the BOOt problem, I'd guess you copied the files using PIP instead of
BRU. Is that right? If so, many of the files won't be in the same places on
the disk. That will confuse RSX, which has the disk addresses of some
essential things in the RSX11M.SYS file. (At least, I think it's that file,
it's been a while...) Also, PIP has possibly not copied the correct file size
-- by default, it discards unused blocks, ISTR. That will kill RSX11M.SYS,
which has extra blocks for the swap space. The other thing PIP won't do (by
default, unless you use the /CO switch) is to ensure that copies are
contiguous, though if you copied onto an empty disk, that probably won't be a
problem. You can tell if a file is contiguous (all the blocks together, in
sequence) by looking to see if there's a letter 'C' just before the date in a
long directory listing; .TSK and .SYS files have to be contiguous.
If you copy with BRU, it takes care of those things, and possibly leaves the
system in such a state that the next *software* boot will sort things out.
There are certain permutations of disk drivers that share boot blocks, which
saves you some of the effort of re-generating the boot setup, but I can't
remember if DU and DL are in that group.
[digs out notes]
If you use PIP, you'll need to recreate the RSX11M.SYS image on the new drive,
while still running the system from the old one:
ASN DL0:=SY:
ASN DL0:=LB:
SET /UIC=[1,54]
PIP RSX11M.sys/NV/CO/BL:<nnn>=RSX11M.TSK
where <nnn> is usually (memory size x 4) + 2. If you express that as a decimal
number, you have to enter it with a decimal point after the digits otherwise
PIP will think you mean octal. That's for a mapped system; change [1,54] to
[1,50] for unmapped.
Then you'll need to re-VMR the system, you can specify what drivers are to be
LOAded at boot time, what memory it has, etc. There's possibly a file called
SYSVMR.CMD or similar, which already has a string of commands in it to load
drivers; edit that to suit.
After you've run VMR _at_SYSVMR you need to software boot the new system and SAVe
it (you may need to type "G" at the prompt, and you need to SAV /WB to make it
hardware bootable).
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
Received on Mon Apr 20 1998 - 08:46:30 BST