VAX/UNIX Coresident on disc - I've done it!

Alasdair Rawsthorne alasdair at mupsy.UUCP
Wed Nov 6 22:21:47 AEST 1985


[Do I still need this?]
      VMS and Unix Coresident on disc - I've done it.

     There was a certain amount of discussion in  this  news
group this week on setting up a disc to be able to bootstrap
either VMS or UNIX from it - including a  contribution  from
someone  who  said  that he had seen it done. Well, I go one
better - I did it myself on a 780 (with VMS 3.4 and Berkeley
4.1) about two years ago.

     The various contributors to the discussion have identi-
fied  all  the  necessary bits and pieces needed to put this
camel together, but I  thought  it  worth  pulling  all  the
threads together in one place in case anyone needs to repeat
the exercise.  I regret that I don't have the VMS manuals to
hand  while  writing this (on the train) so I may get one or
two details corrupted at that end.  (This was the first time
I met VMS!)

     Setting up the system is dead easy  if  you're  porting
UNIX  from a nearby machine - I wasn't, so, since the system
only had one disc, an  RM80(!),  I  needed  to  STAND  ALONE
BACKUP  the  VMS  system to tape and rebuild the UNIX system
every time I wanted to run a UNIX program.

     With  hindsight,  the  problem  becomes  quite   simple
(although  I  notice  that  the names of things in the stand
alone area have changed in BSD4.2). First, use nm(1) to find
the  addresses  of  the  rm80_sizes  array in the version of
stand-alone mkfs, restor, and boot that  you  are  going  to
need and the generic kernel that you are going to bootstrap.
(For the sa stuff, its safest to rebuild them,  nm(1)  them,
and stick them on a new console floppy to guard against ver-
sion problems, I guess.)

     Then get your VMS system up and allocate some big  con-
tiguous  files  (as  I  remember it, the process consists of
creating an FDL file with a contiguous-fit parameter and the
required  size  (I  binary  chopped  sizes  down until I had
grabbed enough space, each newly allocated  contiguous  file
becoming  (eventually)  a  UNIX partition) and then creating
the file using CREATE/FDL. Use  DIR/HEADER  or  somesuch  to
find  out  where  the  file  has  gone,  and  NOTE  DOWN THE
(position, size) PAIRS of these files for later use.

     Next, build the UNIX system in the usual way with  mkfs
and  restor  loading these off the console floppy and taking
care to patch the offset table in each  program  (using  the
console Examine/Deposit commands) before allowing them to do
any work. Now bootstrap the generic kernel (again  you  have
to patch ``boot'' manually) and patch the rm80sizes table in
it when it prompts you for the root device.

     When you're up and running, you can go back  and  patch
kernel  and  stand-alone utilities using adb, and Bob's your
uncle.  VMS Console floppy  boots  VMS,  UNIX  floppy  boots
UNIX.

     The one loose end that I left concerned backing up  the
VMS system.  I believe that it's  possible to mark a file in
such a way as to prevent BACKUP  processing it - this  would
obviously be worth doing to a  system where VMS was in regu-
lar use.  In my case, the whole exercise was nothing  but  a
sop to the notional system owner - nobody actually wanted to
USE the VMS system! :-)

     I'll be glad to fill in more details (if  I  can  still
remember them!) for anyone who wants to mail me.

Alasdair Rawsthorne,
Computer Science Dept.,
Manchester University,
Oxford Road,
Manchester M13 9PL
England
PHONE: +44 61 273 7121 ext 5029
HOME: +44 45 74 65830
EMAIL: alasdair%man.cs.ux at ucl-cs.ARPA
   ...!seismo!mcvax!ukc!man.psy!alasdair



More information about the Comp.unix mailing list