On Tuesday, February 20, 2018 at 7:59 PM, Zane Healy wrote: > > On Feb 20, 2018, at 1:58 PM, Mark Pizzolato <m...@infocomm.com> wrote: > > > > I would actually attribute the 'improved' behavior to the fact that tape > > I/O to > TQ > > and XQ devices is asynchronous in the latest code. > > > > I would seriously consider Mr Baker's suggestion of backing up to simh > > disks. > Not to save sets, but to merely using VMS backup to perform BACKUP/Image > to RQ units attached to disk container files. Thus allowing any recovery you > might need to have random access to the original file system without having to > dig through a save set sequentially. > > > > An industrious fellow might also want to manage the RQ media setup and > change activities automatically from the AXP system with a program that does > a TCP connect to a simh Remote Console. > > > > - Mark > > Based on the documentation, the TQ device appears to be limited to 2000GB. > As a result I’ve been using the TS device.
TQ limited to 2000GB means a limit of 2TB. Do you have disks on the AXP system that big? > Realistically, once I get these “tapes” created, I’ll be migrating part of > the data > from physical disks on the Alpha, to disks on SIMH/VAX. I’ve already done > some experimentation with that. Unfortunately I have ODS-5 data, and some > software requires an Alpha. > > Okay… Some more info on the crashes I’m seeing. The first is specific to the > current source in GitHub. It seems pretty obvious at this point that I can > write > a tape from the Alpha, to a virtual SIMH VAX tape drive, but trying to read > the > data crashes the SIMH VAX. > > This command started, got about half way through, and then the terminal > session on my Alpha that I was running this on was reset. The backup did not > complete. > backup/verify/list $1$DKC300:[000000...]*.*;* tape:A0005 > > > Running this from the Alpha, crashes VAX, once it goes to Verify. This > happened on both V3.8-1 and on Current. > backup/verify $1$DKC300:[000000...]*.*;* tape:A0005 > %MOUNT-I-MOUNTED, A0004 mounted on _$5$MSA0: (RENNY) > %BACKUP-I-STARTVERIFY, starting verification pass at 21-FEB-2018 00:11:02.08 > %BACKUP-F-POSITERR, error positioning _$5$MSA0:[]A0005.; > -SYSTEM-F-VOLINV, volume is not software enabled > > > Partial output from the Console of the VAX. If you look further down, you’ll > see the full output from trying to read a tape. > > SYSGETSYI.EXE 8344EA00 83450A00 > SYSDEVICE.EXE 83450E00 83453800 > MESSAGE_ROUTINES.EXE 83453E00 8345A000 > EXCEPTION.EXE 8346A600 83474E00 > LOGICAL_NAMES.EXE 83475600 83498E00 > SECURITY.EXE 83499800 834A3200 > LOCKING.EXE 834A3A00 834AA800 > PAGE_MANAGEMENT.EXE 834AB200 834B5200 > WORKING_SET_MANAGEMENT.EXE 834CA000 834CFE00 > IMAGE_MANAGEMENT.EXE 834D0800 834D3E00 > EVENT_FLAGS_AND_ASTS.EXE 834D4400 834D6600 > IO_ROUTINES.EXE 834D7000 834E7600 > PROCESS_MANAGEMENT.EXE 834E9000 834F6A00 > ERRORLOG.EXE 83560200 83560E00 > PRIMITIVE_IO.EXE 83561400 83562600 > SYSTEM_SYNCHRONIZATION_UNI.EXE 83562A00 83566E00 > SYSTEM_PRIMITIVES_MIN.EXE 83567400 8356B200 > > **** Starting memory dump, writing dump to unit number 0 > . . . . . . . > **** Memory dump complete, dump written to unit number 0 > > HALT instruction, PC: 83C4D909 (MOVB 400(R1),R0) > sim> q What happens if you merely backup a few hundred MB to the tape with /VERIFY? > Okay, here is the crash from when I tried to read a tape from the Alpha. I’m > not sure if this is a cluster issue, or a SIMH issue. I could test this with > real > hardware, but it would take quite a bit of time to dig out all the bits, > assuming > they still work. > > > **** Fatal BUG CHECK, version = V7.3 CLUEXIT, Node voluntarily exiting > VAXcluster > > Crash CPU: 00 Primary CPU: 00 > > Active/available CPU masks: 00000001/00000001 > [...] The simh tape will have very different timing characteristics when reading as compared to a real physical tape. I would still recommend the TQ device since that I/O is asynch and isn't delaying instruction execution (and cluster timing activities) during data transfers. The cluster exit may merely be due to timing on SCS messages. > End Result, I think I’m going to have to resort to the disk solution. The disk solution has effectively similar limits (something just under 2TB) is the maximum RQ disk size. Meanwhile, you needn't worry about ODS-5 vs ODS-2. You're driving the backup from the AXP side, and the VAX is merely serving access to disk blocks (not files). The VAX can address the full capacity of the disk. Doing a BACKUP/IMAGE your target disk will be mounted /FOREIGN on the AXP side. No problem there. When you want to access the contents of one of these target disks, once again you merely let the VAX serve up access to disk blocks and on the AXP side, you DON'T do a MOUNT/CLUSTER, but instead merely do a MOUNT and you'll be able to see the file system naturally on the AXP side. - Mark _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh