UHAC010@vaxa.rhbnc.ac.UK (07/03/88)
You _can_ run an LAVC off an RD53 boot disk. I have just brought up a VS2000 on a Q3 microvax with twin RD53's. However, to do this I had to use a dump of the system disk from my other (already running) LAVC which does have an RD54, since as you rightly say the installation procedure for VMS V4.6 refuses to continue in the prescence of an RD53 system disk. My understanding of this restriction is as follows. VMS 4.6 is a monolithic group of files. MicroVMS is essentially the same set of files (minus some important header files, examples and other things that _real_ VMS programmers value) but in five lumps, namely the BASE system and four `options' called PROG, SYSP, USER and UTIL. DEC rather grandly told us all how a microVMS system was `configurable' ie you could have a system with no programmer commands, no system programmer support, no users (heaven really does exist) and no utilities. Dunno quite what you use such a beast for, presumably embedded applications, but then I thought VAX-FLAN was the solution to all those problems. In addition to these options, DECnet (which is part of the monolithic big VMS) is just another layered product on MicroVMS. The reason for all this partitioning is that with the advent of the microVAX DEC found itself selling systems with disks that were too small for real VMS. The problem was exacerbated by the way that VMS installs itself. Loosely speaking, a version of VMS is loaded from the tape and then it builds the new system. At critical points in the installation process two versions of VMS are effectively resident on the disk at the same time, so you need LOADSA-blocks. Micro-VMS takes the central chunk of VMS that actually needs to participate in this process and calls it the base system. Only after the rebuilding is completed do you actually load the rest of the OS, so all the blocks that would have been filled up by things like the security utilities, queuing processes etc. are avaliable for the build, and hence it can be done on a microVAX. Now DEC never bothered to build a microVMS system that could support clusters for reasons that are unknown to me but probably have something to do with the fact that space on an RD53 really is a bit tight even if you can get it all to work. I have not yet finished purging back the new system but I only had about 10K blocks left and that was with page and swap file sizes set too small for comfort. The good news is that at V5 microVMS dissapears because big VMS has adopted the BASE+OPTIONS strategy and can therefore be tailored for small disks. However RD52 disks are no longer supported atall because they are just too small. RD53s are fine. I've never used a microVAX I with an RD52 but from what I know of the performance of the machine and its disk I should imagine anybody out there with such a combination will be glad of a reason to junk it. The way to get your RD53 LAVC going is to find someone with a live LAVC and then do a BACKUP/IMAGE/VERIFY/IGNORE=INTERLOCK of the system disk. Boot standalone backup on your boot node and restore from the tape using BACKUP/IMAGE/VERIFY mua0:*/save dua0:/INIT. This takes about an hour and a quarter. Then reboot the machine off dua0. You had better do this with your Ethernet cables disconnected since the machine will think it is the same DECnet node as the one you got the tape from, and that might cause some confusion... Immediately run NETCONFIG.COM to put you network to rights and then run ncp to enable service on your Ethernet adapter (as per p10 of the VMS LAVC manual, AA-JP20C-TE). Run BOOT_CONFIG.COM and then reconnect the Ethernet. You can then run SATELLITE_CONFIG.COM to add in your shiny new VS2000 (or whatever). When I did this I took the precaution of using SATELLITE_CONFIG.COM to remove all the satellites from the system disk of running system before I took the backup. I think you could easily run into space problems on your RD53 if you omit this step. Words of warning. 1) Your satellites should have local disks for page and swap because there probably isn't enough space on the RD53 for them. 2) You'd better have another disk to put you user files on because there won't be much space on the RD53. The satellite local disk would be fine. 3) When your boot node is on the net with no satellites awake you will get regular messages from DECnet complaining about aborted service requests. This is normal, don't worry. As soon as the cluster reaches quorum they will go away. 4) DEC do NOT approve of this procedure. I am an edu user with a known penchant for hacking my systems around and so they decided not to notice what I am doing but don't be surprised if they are unhelpful when you complain to them that this doesn't work If you want more details please contact me directly. Noone in the states ever seems to be able to contact me. Anyone on the UK side know what my mail address looks like to US readers? ------------------------------------------------------------------------------ Adrian Johnstone, Mail: Royal Holloway & Bedford New College, Egham, Surrey, TW20 0EX, England Phone: 0784 39025 Fax: 0784 37520 Telex: 935504 RHC Email: Janet: A.JOHNSTONE@uk.ac.rhbnc.vaxa Arpa: A.JOHNSTONE%vaxa.rhbnc.ac.uk@cs.ucl.ac.uk (I think) Bitnet/NetNorth/Earn: A.JOHNSTONE@vaxa.rhbnc.ac.uk (I think) ------------------------------------------------------------------------------