[Simh] VAX Tape Emulation?

[Mark Pizzolato]

On Tuesday, February 20, 2018 at 7:59 PM, Zane Healy wrote:
> > On Feb 20, 2018, at 1:58 PM, Mark Pizzolato <Mark at 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