[VAXF84.FERMILAB.STARTUP]

 This submission includes a few of the procedures used in the VMS startup
 on the on the Fermilab Accelerator Controls VAXen.  Each procedure includes
 comments documenting its usage and actions.

 The files PUBDSK*.COM and MOUNTDSKS.COM were developed to solve the problem
 of locating and mounting public disks (mounted /SYSTEM) amoung a set of
 removeable media disk drives (RM03's and RA60's).  The problem was that
 disk packs could be moved around between shutdown and startup of the system.
 Our configuration includes a spare disk drive to which a pack may be moved
 from a failed drive, we wanted a automatic means of configuring the volumes
 so that no pack was explicitly tied to a drive nor were the accelerator
 operator's required to perform any special actions to reconfigure (other than
 to move the disk pack).  These same procedures can also assist V3 systems
 with dual HSC's to make the mounting of public user packs independent of
 which HSC is to used (assuming the drives are dual-ported to the two HSC's).
 At Fermilab, if an HSC fails all that is required is to reboot the system
 and the other HSC will automatically be used.  Of the files mentioned above,
 MOUNTDSKS.COM is specific to Fermilab and only included here is to illustrate
 the procedures described above.

 In a similar vein, the procedures DSKCONFIG.COM and SPAREDISK.COM are used to
 coordinate the usage of a pool of disk drives between multiple processors.
 The configuration in the Fermilab Accelerator Control System includes RM03
 and RM80 disk drives dual-ported between two 780's.  This past year, two
 HSC50's with several RA81 and RA60 disk drives were added.  The two systems
 used are the Operational system used to control the accelerator and, on
 the backup VAX, the Development system used to develope the software for
 the control system.  The Operational system uses only removeable-media
 disks for reliability - a pack can be moved from a failed drive to a standby
 and have the control system in operation after 10 minutes or less.  In
 addition, backups of the Operational disks are done pack-to-pack to provide
 an extra level of redundancy.  The Development system uses only fixed-media
 drives with backups maintained on tape.  The management problems associated
 with configuration were:

	1. Coordinating the identity of the standby RM03 and RA60 drives
	   from the Operational system (given the startup procedures described
	   in the second paragraph, above) to the Development system.

	2. Preventing access by users to the RA60 disk drives in actual use
	   by the Operational system.

 The DSKCONFIG and SPAREDISK procedures were created to automatically enforce
 this management scheme.  The Operational system sets all fixed-media drives
 to /NOAVAILABLE, the Development system does the same for all removeable-
 media drives.  DECnet is then used to communicate the identity of the standby
 RM03 and RA60 drives from the Operational system to the Development system
 so the Development system may use these drives to access offline media.

 The procedures described above will be upgraded with VMS V4 and used to
 manage a system consisting of 3 785's configured as a single processor system
 and a two-processor VAXCluster with both systems accessing logically distinct
 sets of disks connected via HSC50's.