VAX-11/730 %BOOT-F-Unexpected Machine Check

Thank you very much! The clue about R5 on other VAXen may prove to be critically helpful. I can study the various boot scripts for clues to see if the register use looks consistent. I did see one hint that sticking 1 instead of 0 into one particular register (I don't recall which one of the top of my head) seemed to indicate a conversational boot instead of turnkey one. Is there VMB.EXE documentation out there that I don't know how to find yet? Even if it's for VMB.EXE for a different VAX-11 machine, the one for my 730 might follow the same register conventions. Another approach came to mind that might be a lot easier than swapping a humorously large number of virtual TU58 cassettes, or might be yet another goose chase. One of my last recent eBay purchases before I quit both eBay and PayPal in a huff over terms of service changes was a TK50 drive and both UNIBUS and QBUS interface cards for it. All of the pieces are unknown quantities, and I'll need to kludge a power supply and fabricate an interface cable, but the drive can theoretically be plugged into my 730. If the 5.3 standalone backup knows about TK50 drives, then I may be able to try backing up whatever is on the hard drives to TK50 cartridges. Next, if I get a TZ30 drive, I wonder if I might be able to plug it into my Sun Ultra 60 running Solaris 8 (since that's my workingest computer with both a SCSI interface and a familiar UNIXy operating system), and then use that to slurp data off the backup cartridge(s) for further analysis. Does this approach sound plausible? Unless somebody happens to know that the TZ30 is incompatible with generic SCSI tape support on UNIX boxen, I think I'll contact the same seller I bought the TK50 from and see if they have a TZ30 sitting around. Yet another approach might be doing the same scheme with my system's existing magtape drive, and then trying to get my hands on a SCSI magtape drive to plug into my Sun. But that would involve shipping a much larger and heavier piece of equipment. -- Mark J. Blair, NF6X <nf6x at nf6x.net> http://www.nf6x.net/