wjm 02-apr-1999: PK2KDRVR & assorted patches to system programs, V1.3 Changes over V1.2: Support non-zero SCSI host id (like Vs3100). *** This is for VMS V5.5-2 only *** PK2KDRVR is a driver for the Vs2000/uVAX2000 SCSI port (traditionally known as the "tape controller port"). >>> EXPERIMENTAL software, NO WARRANTIES at all! <<< Apart from one `feature' and one restriction mentioned next, it _ought_ to behave just like the Vs3100 SCSI driver (PKNDRIVER). SCSI host id determination: The SCSI host adapter _by_default_ used the SCSI id 0 (not 6 or 7, as customary with other SCSI adapters), meaning you can't use a device on the bus with this id. This setting can be checked from the ">>> T 50" display, which under "TPC" shows a longword for each of the SCSI ids 0..7 - the host id is indicated by a longword of FFFFFF03. Analogous to the ">>> SET SCSI[A]" commands found with other VAXen, the setting can be changed permanently (saved in NVRAM), in a somewhat non-intuitive way: For a host id of ... enter at the >>> prompt ... 7 D/U/P 200B00BC 1C 6 D/U/P 200B00BC 18 5 D/U/P 200B00BC 14 4 D/U/P 200B00BC 10 3 D/U/P 200B00BC 0C 2 D/U/P 200B00BC 08 1 D/U/P 200B00BC 04 0 D/U/P 200B00BC 00 Note: The `field sevice utility' ">>> T 73" (or better, ">>> T 20000073"), aka. "tpmker", does not correctly cope with a non-zero host id. This is a ROM bug. T 73 likely has little use to anyone these days. Known restriction: PK2KDRVR won't do data transfers of 16kB or more. This has the effect of limiting the block size that can be used with SCSI tapes, and also will break any program that _attempts_ to read 16kB or more. The only VMS program that does so (which I'm aware of) is DUMP - see below for a patch. Disclaimer: This is *EXPERIMENTAL* SOFTWARE that theoretically *could* not only crash your system, but *could* cause CORRUPTION on all media connected to the computer on which it's installed. (In fact, PK2KDRVR has plenty of code that *attempts* to crash the system if a chance for corruption gets noticed. I haven't observed any problem, let alone a crash, with PK2K on VMS V5.5-2, since the release of V1.2 in late August 1997, in spite of trying pretty hard :-) Fact is, the Vs2000/uVAX2000 hardware has never been "qualified" by anyone to work correctly with SCSI devices. >>> NO WARRANTIES at all! <<< Installation & use: *** This is for VMS V5.5-2 only *** The "binary kit" contains PK2KDRVR.EXE (not spelled PK2KDRIVER for quite "technical" reasons) plus 5 patch command files. Place PK2KDRVR.EXE in SYS$LOADABLE_IMAGES. Use $ PATCH @2KSYSGEN.COM to create 2KSYSGEN.EXE in the current directory. >>> Make sure that no MUA0 shows up, and that TVDRIVER >>> (the Vs2000/uVAX2000 magtape driver) is _not_ loaded. Use $ MCR [dir]2KSYSGEN AUTOCONFIGURE ALL to load PK2KDRVR (ought to show up as device PKA0) and autoconfigure the SCSI devices, just like on a Vs3100. If you're confident enough in the driver that you want the machine to auto-configure the SCSI at boot time, create two more programs (which _may_ only be required if the machine is a cluster member), 2KSTACONFIG.EXE via $ PATCH @2KSTACONFIG.COM plus 2KCONFIGURE.EXE via $ PATCH @2KCONFIGURE.COM and copy 2KSYSGEN.EXE to SYS$SYSTEM:SYSGEN.EXE 2KSTACONFIG.EXE to SYS$SYSTEM:STACONFIG.EXE 2KCONFIGURE.EXE to SYS$SYSTEM:CONFIGURE.EXE Each of these programs supposedly behaves just like the VMS "original", when executed on a VAX other than a Vs2000 or uVAX2000. For completeness' sake, there are two more patch command files that create PK2K-aware versions of STASYSGEN.EXE and STANDCONF.EXE . Both of these are only used by stand-alone BACKUP - in order to build a PK2K-aware kit, place the patched programs into SYS$SYSTEM under the original name, and modify SYS$UPDATE:STABACKIT-TABLE.DAT by replacing "TVDRIVER.EXE" with "PK2KDRVR.EXE". You may also wish to change STABACKIT.COM such that it accepts generic SCSI tape (devtype 28) and on that occasion make it refer to a differently named *-TABLE.DAT - I did find a non-DEC DAT drive from which a Vs2000 did boot, with the tape configured as MKA100 (">>> B MUA0" expects the tape to have a SCSI id of 1). Lastly, there's 2KDUMP.COM which will create 2KDUMP.EXE via $ PATCH @2KDUMP.COM Use the result instead of the original SYS$SYSTEM:DUMP.EXE in order to DUMP blocks from a SCSI tape drive, e.g. via $ DEFINE/USER DUMP dev:[dir]2KDUMP.EXE $ DUMP MKAu00: or similar. Contrary to standard DUMP, 2KDUMP will - independent of hardware - read at most 16k-1 bytes per tape block (no big deal :-). Wolfgang J. Möller, Göttingen, F.R.Germany