[Simh] VAX Tape Emulation?

[Zane Healy]

What type/size of tapes does the VAX emulation support?  I was looking through 
the doc’s and it wasn’t obvious to me.  Is there a size limit?

Thanks,
Zane



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Mark Pizzolato]

On Wednesday, January 24, 2018 at 2:03 PM, Zane Healy wrote:
> What type/size of tapes does the VAX emulation support?  I was looking
> through the doc’s and it wasn’t obvious to me.  Is there a size limit?

How big is your disk?  :-)

Really, there is no actual limit on total tape size, since the data format is 
only concerned with tape records which are then processed sequentially.


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Paul Koning]

> On Jan 24, 2018, at 5:07 PM, Mark Pizzolato  wrote:
> 
> On Wednesday, January 24, 2018 at 2:03 PM, Zane Healy wrote:
>> What type/size of tapes does the VAX emulation support?  I was looking
>> through the doc’s and it wasn’t obvious to me.  Is there a size limit?
> 
> How big is your disk?  :-)
> 
> Really, there is no actual limit on total tape size, since the data format is 
> only concerned with tape records which are then processed sequentially.

Then again, SIMH supports limiting the emulated tape size.  The SIMH VAX 
document shows that it uses this feature: the tape units can be set to a 
specific size limit, or 0 for unlimited.  The same is true for various other 
emulations; I see the PDP11 has the same sort of thing, and for example its 
TMSCP controller defaults to 98 MB (TK50 size).

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

Zane,

I'm not sure I follow your question.  Tape sizes are defined by the reel,
not the recording hardware.  Since the device is a vector (starting at
block 0) are conceptually unlimited (fixed by the number of bytes/blocks
available in the length of tape).   9-track mag tapes in 12" reels were
traditionally 2400 ft long.   3M managed to make a thinner tape and got the
tapes to 3600 ft.   The 6" reels were 600 ft and the 10" reels were 1200 ft
BTW.But the recording techniques (aka the tape densities) defined how
many bytes [NRZ - aka 800 bpi, PE - aka 1600 bpi, GRZ - aka 6250].   The
other issue is/was how big a 'block' you can write.   Anything more than
64k bytes could be problematic as the IEEE tape standards did not define
reliable ways to do that and on a VAX or PDP-11 that was traditionally the
DMA size limit anyway.

Anyway, with traditionally blocking, a 2400" tape @ 6250 you could get
about 120M of storage (~180M on 3600 " tapes) --  put another way, we used
assume that an RP06 could be backed up on 2.5 tapes.

Disks on the other hand are not a vector, but rather # of heads, #of
cylinders and the # of sectors in each cylinder.  Thus they have a more
fixed size.

Clem
ᐧ

On Wed, Jan 24, 2018 at 5:02 PM, Zane Healy  wrote:

> What type/size of tapes does the VAX emulation support?  I was looking
> through the doc’s and it wasn’t obvious to me.  Is there a size limit?
>
> Thanks,
> Zane
>
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

> On Jan 24, 2018, at 2:07 PM, Mark Pizzolato  wrote:
> 
> On Wednesday, January 24, 2018 at 2:03 PM, Zane Healy wrote:
>> What type/size of tapes does the VAX emulation support?  I was looking
>> through the doc’s and it wasn’t obvious to me.  Is there a size limit?
> 
> How big is your disk?  :-)
> 
> Really, there is no actual limit on total tape size, since the data format is 
> only concerned with tape records which are then processed sequentially.

And this is why I need to pay attention to when I ask questions.  So I can give 
all the details.

Here is the story.  I have two emulated VAXen, clustered with my Alpha.  My 
only physical tape drives are getting *old*, as are my tapes.  I’d like to 
backup to a simulated tape drive on the one emulated VAX.  The largest drive on 
my Alpha is 50GB.  I’d prefer not to have to span tapes. :-)

Zane


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Tim Shoppa]

Many common tape image tools as of two decades use 32-bit integers to carry
offsets around and will be limited to 4Gigabyte tape image sizes.

I don't think this is a fundamental limit to the tape image formats used by
SIMH, just a common limitation of the tape image tools you might find from
20 years ago.

Tim.

On Wed, Jan 24, 2018 at 5:02 PM, Zane Healy  wrote:

> What type/size of tapes does the VAX emulation support?  I was looking
> through the doc’s and it wasn’t obvious to me.  Is there a size limit?
>
> Thanks,
> Zane
>
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Larry Baker]

Zane,

You didn't say what kind of Alpha you have.  I just bought a used 72GB SCSI 
drive for our Alpha DS20E.  That's plenty big enough to hold many Backup Save 
Sets from your VAXes, I assume.  VAXes can backup over DECnet from Standalone 
Backup, you know.  Using SIMH, you don't even have to do that.  You can mount 
the boot disk for one VAX on another one to back it up over any network that 
your VAX can reach.  Or, you can replicate my DECnet-to-NFS gateway on your own 
ARM SBC (I use an old Marvell SheevaPlug) and access all your NFS servers from 
DECnet.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov



> On 24 Jan 2018, at 3:53:39 PM, simh-requ...@trailing-edge.com wrote:
> 
> Message: 6
> Date: Wed, 24 Jan 2018 14:25:39 -0800
> From: Zane Healy mailto:heal...@avanthar.com>>
> To: Mark Pizzolato mailto:m...@infocomm.com>>
> Cc: simh mailto:simh@trailing-edge.com>>
> Subject: Re: [Simh] VAX Tape Emulation?
> Message-ID: <84e9bdeb-f78f-44b4-bc76-1773db558...@avanthar.com 
> <mailto:84e9bdeb-f78f-44b4-bc76-1773db558...@avanthar.com>>
> Content-Type: text/plain; charset=utf-8
> 
> 
>> On Jan 24, 2018, at 2:07 PM, Mark Pizzolato > <mailto:m...@infocomm.com>> wrote:
>> 
>> On Wednesday, January 24, 2018 at 2:03 PM, Zane Healy wrote:
>>> What type/size of tapes does the VAX emulation support?  I was looking
>>> through the doc’s and it wasn’t obvious to me.  Is there a size limit?
>> 
>> How big is your disk?  :-)
>> 
>> Really, there is no actual limit on total tape size, since the data format 
>> is 
>> only concerned with tape records which are then processed sequentially.
> 
> And this is why I need to pay attention to when I ask questions.  So I can 
> give all the details.
> 
> Here is the story.  I have two emulated VAXen, clustered with my Alpha.  My 
> only physical tape drives are getting *old*, as are my tapes.  I’d like to 
> backup to a simulated tape drive on the one emulated VAX.  The largest drive 
> on my Alpha is 50GB.  I’d prefer not to have to span tapes. :-)
> 
> Zane



smime.p7s
Description: S/MIME cryptographic signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Mark Pizzolato]

The simh (and other common formats) use 32bit values to indicate tape record 
sizes and other info about a record or file mark.  They don’t actually contain 
offset information.  As such, the limit on size is the limit on space to 
contain the tape image.

From: Tim Shoppa
Sent: Wednesday, January 24, 2018 3:54 PM


Many common tape image tools as of two decades use 32-bit integers to carry 
offsets around and will be limited to 4Gigabyte tape image sizes.

I don't think this is a fundamental limit to the tape image formats used by 
SIMH, just a common limitation of the tape image tools you might find from 20 
years ago.

Tim.

On Wed, Jan 24, 2018 at 5:02 PM, Zane Healy 
mailto:heal...@avanthar.com>> wrote:
What type/size of tapes does the VAX emulation support?  I was looking through 
the doc’s and it wasn’t obvious to me.  Is there a size limit?

Thanks,
Zane



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Dennis Boone]

 > Many common tape image tools as of two decades use 32-bit integers to
 > carry offsets around and will be limited to 4Gigabyte tape image
 > sizes.

As Mark pointed out, this is block size, not file size.  But it's also
really 31 bits, since in most variants of the format, the high bit means
that the count field indicates either some sort of error or physical end
of medium or similar.

De
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

> On Jan 24, 2018, at 2:17 PM, Paul Koning  wrote:
> 
> 
> 
>> On Jan 24, 2018, at 5:07 PM, Mark Pizzolato  wrote:
>> 
>> On Wednesday, January 24, 2018 at 2:03 PM, Zane Healy wrote:
>>> What type/size of tapes does the VAX emulation support?  I was looking
>>> through the doc’s and it wasn’t obvious to me.  Is there a size limit?
>> 
>> How big is your disk?  :-)
>> 
>> Really, there is no actual limit on total tape size, since the data format 
>> is 
>> only concerned with tape records which are then processed sequentially.
> 
> Then again, SIMH supports limiting the emulated tape size.  The SIMH VAX 
> document shows that it uses this feature: the tape units can be set to a 
> specific size limit, or 0 for unlimited.  The same is true for various other 
> emulations; I see the PDP11 has the same sort of thing, and for example its 
> TMSCP controller defaults to 98 MB (TK50 size).
> 
>   paul
> 

How do I set the tape size to 0?  I’d say that’s a stupid question, but I’ve 
had very little luck finding documentation on the options.  Though I won’t rule 
out that I might be blind. :-)

While looking for the answer to that, I may have found a better solution.  It 
looks like I can create a 50GB disk.  If I can do that, I can move my Alpha 
disks over to SIMH.  That would actually be my preference.  The two disks I’m 
the most concerned with are ODS-2.  The other two are ODS-5, and I think there 
are some filenames from OpenSource software that will have issues with ODS-2, 
but I can selectively move the data I want backed up to an ODS-2 disk.

The joke is, my 50GB disk only has about 8GB of data on it, one of the 36GB 
drives is the big one at about 26GB.

Zane


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Johnny Billquist]

Hmm. None of the tools I wrote ever had that limit. They just process records 
and don't give a damn about absolute disk or tape position.

  Johnny 


Tim Shoppa  skrev: (25 januari 2018 00:53:34 CET)
>Many common tape image tools as of two decades use 32-bit integers to
>carry
>offsets around and will be limited to 4Gigabyte tape image sizes.
>
>I don't think this is a fundamental limit to the tape image formats
>used by
>SIMH, just a common limitation of the tape image tools you might find
>from
>20 years ago.
>
>Tim.
>
>On Wed, Jan 24, 2018 at 5:02 PM, Zane Healy 
>wrote:
>
>> What type/size of tapes does the VAX emulation support?  I was
>looking
>> through the doc’s and it wasn’t obvious to me.  Is there a size
>limit?
>>
>> Thanks,
>> Zane
>>
>>
>>
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Tim Shoppa]

A couple of the tape image utilities I wrote or updated in the 1990s have that 
limit. Let me see if they are still in the SIMH utility tree. They never 
would’ve bitten me back in the 90s because the biggest reels I ever dealt with 
were 3600 feet at 6250 BPI, less than 250 Mbytes.

Tim

> On Jan 25, 2018, at 8:23 AM, Johnny Billquist  wrote:
> 
> Hmm. None of the tools I wrote ever had that limit. They just process records 
> and don't give a damn about absolute disk or tape position.
> 
> Johnny 
> 
> 
> Tim Shoppa  skrev: (25 januari 2018 00:53:34 CET)
>> 
>> Many common tape image tools as of two decades use 32-bit integers to carry 
>> offsets around and will be limited to 4Gigabyte tape image sizes.
>> 
>> I don't think this is a fundamental limit to the tape image formats used by 
>> SIMH, just a common limitation of the tape image tools you might find from 
>> 20 years ago.
>> 
>> Tim.
>> 
>>> On Wed, Jan 24, 2018 at 5:02 PM, Zane Healy  wrote:
>>> What type/size of tapes does the VAX emulation support?  I was looking 
>>> through the doc’s and it wasn’t obvious to me.  Is there a size limit?
>>> 
>>> Thanks,
>>> Zane
>>> 
>>> 
>>> 
>>> ___
>>> Simh mailing list
>>> Simh@trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>> 
> 
> -- 
> Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Paul Koning]

On Jan 24, 2018, at 8:33 PM, Zane Healy  wrote:
> 
> How do I set the tape size to 0?  I’d say that’s a stupid question, but I’ve 
> had very little luck finding documentation on the options.  Though I won’t 
> rule out that I might be blind. :-)

In the SIMH source tree there's a "doc" subdirectory with documents for SIMH 
generally, and for each of the ports.  The available configuration commands can 
be found in the specific port document, for example vax_doc.doc and 
vax780_doc.doc.

The commands are defined per controller type, but it looks like the code uses a 
consistent syntax:

set  capac=0

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

On Wed, Jan 24, 2018 at 5:25 PM, Zane Healy  wrote:

>
>   I’d like to backup to a simulated tape drive on the one emulated VAX.
> The largest drive on my Alpha is 50GB.  I’d prefer not to have to span
> tapes. :-)

​Another thought...  what are you running the emulator on?  Is it a
UNIX/Linux flavor of some type?   I ask because there might be another
solution that could work a little better in practice, although you'll need
to pull together some pieces.  The problem is the bits in my brain WRT
to VMS are 20+ years old and I've forgotten the details so you'll have to
do some homework.

At one point, I remember that some VMS folks in ZK3 (CJ Coppersmith seems
to stick in my head by I do not remember) were messing we putting a the UCB
sockets library into VMS and were somebody ported the Berkeley rcmd(3)
suite on VMS from Tru64.   I'm not sure if how much of that library or
which commands ever saw the light of day in a production version of VMS.
But the idea (then) was that a VMS system could use remote services (such
as a tape) via a socket.  The UNIX command is called rmt(8) (and of course
mt(8) and IIRC rmt(8) was originally based on the rcmd(3) calls from
rsh/rcp et al.

So assuming VMS supports same, using mt(8)/rmt(8) is trival on a UNIX side.
But more importantly for you is that on the UNIX side the remote
'device' can be a UNIX file as easily as a physical tape if the 'source'
side knows about using a socket as the output 'device.'.  I've used this
trick to back up some older systems to modern devices these days (my
Masscomp box for instance).  The "tape files" are stored on my NAS which
has redundant physical disks etc...  In fact,  I've even recompiled mt/rmt
for my Mac at one point and I have it working on *BSD with modern tapes
(just needed to grab the mtio.h file from BSD).
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

Just to be clear, I’m looking to backup a physical machine, to a virtual tape 
drive, such that I can restore the data to either SIMH or a Physical machine.  
I don’t need to extract files.  I can extract files (and I have with some of 
the most critical) via NFS to my Mac.  

Except for legacy hardware, most tapes I dealt with in the 90’s were in the 
20-40GB range.  Current tapes now are multi-Terabyte, but not something most of 
us can afford to have at home, which is why I’m looking to go this route.

Zane




> On Jan 25, 2018, at 5:39 AM, Tim Shoppa  wrote:
> 
> A couple of the tape image utilities I wrote or updated in the 1990s have 
> that limit. Let me see if they are still in the SIMH utility tree. They never 
> would’ve bitten me back in the 90s because the biggest reels I ever dealt 
> with were 3600 feet at 6250 BPI, less than 250 Mbytes.
> 
> Tim
> 
> On Jan 25, 2018, at 8:23 AM, Johnny Billquist  > wrote:
> 
>> Hmm. None of the tools I wrote ever had that limit. They just process 
>> records and don't give a damn about absolute disk or tape position.
>> 
>> Johnny 
>> 
>> 
>> Tim Shoppa mailto:tsho...@gmail.com>> skrev: (25 januari 
>> 2018 00:53:34 CET)
>> Many common tape image tools as of two decades use 32-bit integers to carry 
>> offsets around and will be limited to 4Gigabyte tape image sizes.
>> 
>> I don't think this is a fundamental limit to the tape image formats used by 
>> SIMH, just a common limitation of the tape image tools you might find from 
>> 20 years ago.
>> 
>> Tim.
>> 
>> On Wed, Jan 24, 2018 at 5:02 PM, Zane Healy > > wrote:
>> What type/size of tapes does the VAX emulation support?  I was looking 
>> through the doc’s and it wasn’t obvious to me.  Is there a size limit?
>> 
>> Thanks,
>> Zane
>> 
>> 
>> 
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com 
>> http://mailman.trailing-edge.com/mailman/listinfo/simh 
>> ___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

> On Jan 25, 2018, at 6:28 AM, Paul Koning  wrote:
> 
> On Jan 24, 2018, at 8:33 PM, Zane Healy  wrote:
>> 
>> How do I set the tape size to 0?  I’d say that’s a stupid question, but I’ve 
>> had very little luck finding documentation on the options.  Though I won’t 
>> rule out that I might be blind. :-)
> 
> In the SIMH source tree there's a "doc" subdirectory with documents for SIMH 
> generally, and for each of the ports.  The available configuration commands 
> can be found in the specific port document, for example vax_doc.doc and 
> vax780_doc.doc.
> 
> The commands are defined per controller type, but it looks like the code uses 
> a consistent syntax:
> 
>   set  capac=0
> 
>paul

Interesting.  I wonder if the documentation has gotten dropped somehow.  Either 
that or I’m still being blind.

As far as I can tell, the GITHUB repository lacks such files.
https://github.com/simh/simh/tree/master/

The v3.9-0 source at Trailing-Edge does as well.
http://simh.trailing-edge.com/

The v3.0 source on the other hand has a vax_doc.txt under the VAX subdirectory.

I’m using the SIMH build on Ubuntu in a VM.  That appears to be v3.8-1, and 
oddly enough you can do “man vax” which points you to where the doc’s are.  
Here are some of the applicable looking ones.
-rw-r--r-- 1 root root  34768 Mar  2  2007 simh_magtape.pdf
-rw-r--r-- 1 root root 188726 Feb  8  2009 simh.pdf
-rw-r--r-- 1 root root   3501 May 27  2008 vax780_bug_history.txt
-rw-r--r-- 1 root root 107942 Feb  8  2009 vax780_doc.pdf
-rw-r--r-- 1 root root 117234 Feb  8  2009 vax_doc.pdf

And there is the info I was after, in vax_doc.pdf. :-)

SET TS0 CAPAC=m

It looks like the TK50 emulation is limited to 2GB, so I don’t want to use that.

Plus it has details on the large disk sizes using SET RQn RAUSER{=n} that I’d 
found out about last night, and an RRD40 type that I was unaware of.

Next step, installing Linux on a Core i5 box I picked up for $75 recently to 
run SIMH.  If all this works, it will allow me to *significantly* cut my 
electricity bill, while keeping my VMS data online and accessible. :-) 

Zane




___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

> On Jan 25, 2018, at 6:57 AM, Clem Cole  wrote:
> 
> 
> 
> On Wed, Jan 24, 2018 at 5:25 PM, Zane Healy  > wrote:
> 
>   I’d like to backup to a simulated tape drive on the one emulated VAX.  The 
> largest drive on my Alpha is 50GB.  I’d prefer not to have to span tapes. :-)
> ​Another thought...  what are you running the emulator on?  Is it a 
> UNIX/Linux flavor of some type?   I ask because there might be another 
> solution that could work a little better in practice, although you'll need to 
> pull together some pieces.  The problem is the bits in my brain WRT to 
> VMS are 20+ years old and I've forgotten the details so you'll have to do 
> some homework.
> 
> At one point, I remember that some VMS folks in ZK3 (CJ Coppersmith seems to 
> stick in my head by I do not remember) were messing we putting a the UCB 
> sockets library into VMS and were somebody ported the Berkeley rcmd(3) suite 
> on VMS from Tru64.   I'm not sure if how much of that library or which 
> commands ever saw the light of day in a production version of VMS.   But the 
> idea (then) was that a VMS system could use remote services (such as a tape) 
> via a socket.  The UNIX command is called rmt(8) (and of course mt(8) and 
> IIRC rmt(8) was originally based on the rcmd(3) calls from rsh/rcp et al.
> 
> So assuming VMS supports same, using mt(8)/rmt(8) is trival on a UNIX side.   
>   But more importantly for you is that on the UNIX side the remote 'device' 
> can be a UNIX file as easily as a physical tape if the 'source' side knows 
> about using a socket as the output 'device.'.  I've used this trick to back 
> up some older systems to modern devices these days (my Masscomp box for 
> instance).  The "tape files" are stored on my NAS which has redundant 
> physical disks etc...  In fact,  I've even recompiled mt/rmt for my Mac at 
> one point and I have it working on *BSD with modern tapes (just needed to 
> grab the mtio.h file from BSD).  

Interesting…  I wonder if this is an option in the latest versions of OpenVMS.  
I was already researching OpenSource VTL options.  The problem being a distinct 
lack of support for OpenVMS in any OpenSource backup software that I could find.

Zane



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Paul Koning]

> On Jan 25, 2018, at 10:50 AM, Zane Healy  wrote:
> 
> 
>> ...
> 
> Interesting.  I wonder if the documentation has gotten dropped somehow.  
> Either that or I’m still being blind.
> 
> As far as I can tell, the GITHUB repository lacks such files.
> https://github.com/simh/simh/tree/master/

No, it's right there.  Remember that Github displays are case sensitive, so all 
the machine directories (being upper case, apart from "alpha") come first, then 
the lowercase ones such as "doc".  

> ...
> I’m using the SIMH build on Ubuntu in a VM.  That appears to be v3.8-1, and 
> oddly enough you can do “man vax” which points you to where the doc’s are.  
> Here are some of the applicable looking ones.
> -rw-r--r-- 1 root root  34768 Mar  2  2007 simh_magtape.pdf
> -rw-r--r-- 1 root root 188726 Feb  8  2009 simh.pdf
> -rw-r--r-- 1 root root   3501 May 27  2008 vax780_bug_history.txt
> -rw-r--r-- 1 root root 107942 Feb  8  2009 vax780_doc.pdf
> -rw-r--r-- 1 root root 117234 Feb  8  2009 vax_doc.pdf
> 
> And there is the info I was after, in vax_doc.pdf. :-)
> 
> SET TS0 CAPAC=m

Then again, 3.8.1 is quite old.

> It looks like the TK50 emulation is limited to 2GB, so I don’t want to use 
> that.

That's rather confusing.  There's a controller setting that specifies the 
device type (which doesn't make much sense since device type is a unit 
property).  But there is still a unit capacity command that seems to override 
the device setting.

> Plus it has details on the large disk sizes using SET RQn RAUSER{=n} that I’d 
> found out about last night,

Yes, RAUSER is nice to make up virtual disks of arbitrary convenient size.

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Larry Baker]

Zane,

Your idea of connecting a second disk to your SIMH VAXes will work fine.  
Create a second SIMH hard drive for your VAX(es).  Initialize it on the VAX.  
Then boot Standalone Backup and make an image Backup Save Set on your second 
disk.  Or, make an image copy.  Then you'll have a second bootable disk.  Any 
VAX can boot into Standalone Backup.  You boot SYSE instead of SYS0 with the 
boot flags.  VMS comes with a command procedure to create the bootable 
Standalone Backup SYSE directory tree.  Or, just duplicate your SIMH disk image.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov



> On 25 Jan 2018, at 6:28:14 AM, simh-requ...@trailing-edge.com wrote:
> 
> Message: 2
> Date: Wed, 24 Jan 2018 17:33:26 -0800
> From: Zane Healy mailto:heal...@avanthar.com>>
> To: Paul Koning mailto:paulkon...@comcast.net>>
> Cc: Mark Pizzolato mailto:m...@infocomm.com>>, simh 
> mailto:simh@trailing-edge.com>>
> Subject: Re: [Simh] VAX Tape Emulation?
> Message-ID: <2092bbd6-85aa-45f9-ab8b-83925b64a...@avanthar.com 
> <mailto:2092bbd6-85aa-45f9-ab8b-83925b64a...@avanthar.com>>
> Content-Type: text/plain; charset=utf-8
> 
> 
>> On Jan 24, 2018, at 2:17 PM, Paul Koning > <mailto:paulkon...@comcast.net>> wrote:
>> 
>> 
>> 
>>> On Jan 24, 2018, at 5:07 PM, Mark Pizzolato >> <mailto:m...@infocomm.com>> wrote:
>>> 
>>> On Wednesday, January 24, 2018 at 2:03 PM, Zane Healy wrote:
>>>> What type/size of tapes does the VAX emulation support?  I was looking
>>>> through the doc’s and it wasn’t obvious to me.  Is there a size limit?
>>> 
>>> How big is your disk?  :-)
>>> 
>>> Really, there is no actual limit on total tape size, since the data format 
>>> is 
>>> only concerned with tape records which are then processed sequentially.
>> 
>> Then again, SIMH supports limiting the emulated tape size.  The SIMH VAX 
>> document shows that it uses this feature: the tape units can be set to a 
>> specific size limit, or 0 for unlimited.  The same is true for various other 
>> emulations; I see the PDP11 has the same sort of thing, and for example its 
>> TMSCP controller defaults to 98 MB (TK50 size).
>> 
>>  paul
>> 
> 
> How do I set the tape size to 0?  I’d say that’s a stupid question, but I’ve 
> had very little luck finding documentation on the options.  Though I won’t 
> rule out that I might be blind. :-)
> 
> While looking for the answer to that, I may have found a better solution.  It 
> looks like I can create a 50GB disk.  If I can do that, I can move my Alpha 
> disks over to SIMH.  That would actually be my preference.  The two disks I’m 
> the most concerned with are ODS-2.  The other two are ODS-5, and I think 
> there are some filenames from OpenSource software that will have issues with 
> ODS-2, but I can selectively move the data I want backed up to an ODS-2 disk.
> 
> The joke is, my 50GB disk only has about 8GB of data on it, one of the 36GB 
> drives is the big one at about 26GB.
> 
> Zane
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Larry Baker]

Clem,

MultiNet included rmt support.  I do not know which versions included it or 
whether MultiNet has a Hobbyist License.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov



> On 25 Jan 2018, at 7:57:30 AM, simh-requ...@trailing-edge.com wrote:
> 
> Message: 1
> Date: Thu, 25 Jan 2018 09:57:54 -0500
> From: Clem Cole mailto:cl...@ccc.com>>
> To: Zane Healy mailto:heal...@avanthar.com>>
> Cc: Mark Pizzolato mailto:m...@infocomm.com>>, simh 
> mailto:simh@trailing-edge.com>>
> Subject: Re: [Simh] VAX Tape Emulation?
> Message-ID:
><mailto:CAC20D2Ouuwmo_1bO_uUxNPofi7pV5iRRP=qvWujoN4B-sye=v...@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
> 
> On Wed, Jan 24, 2018 at 5:25 PM, Zane Healy  <mailto:heal...@avanthar.com>> wrote:
> 
>> 
>>  I’d like to backup to a simulated tape drive on the one emulated VAX.
>> The largest drive on my Alpha is 50GB.  I’d prefer not to have to span
>> tapes. :-)
> 
> ​Another thought...  what are you running the emulator on?  Is it a
> UNIX/Linux flavor of some type?   I ask because there might be another
> solution that could work a little better in practice, although you'll need
> to pull together some pieces.  The problem is the bits in my brain WRT
> to VMS are 20+ years old and I've forgotten the details so you'll have to
> do some homework.
> 
> At one point, I remember that some VMS folks in ZK3 (CJ Coppersmith seems
> to stick in my head by I do not remember) were messing we putting a the UCB
> sockets library into VMS and were somebody ported the Berkeley rcmd(3)
> suite on VMS from Tru64.   I'm not sure if how much of that library or
> which commands ever saw the light of day in a production version of VMS.
> But the idea (then) was that a VMS system could use remote services (such
> as a tape) via a socket.  The UNIX command is called rmt(8) (and of course
> mt(8) and IIRC rmt(8) was originally based on the rcmd(3) calls from
> rsh/rcp et al.
> 
> So assuming VMS supports same, using mt(8)/rmt(8) is trival on a UNIX side.
>But more importantly for you is that on the UNIX side the remote
> 'device' can be a UNIX file as easily as a physical tape if the 'source'
> side knows about using a socket as the output 'device.'.  I've used this
> trick to back up some older systems to modern devices these days (my
> Masscomp box for instance).  The "tape files" are stored on my NAS which
> has redundant physical disks etc...  In fact,  I've even recompiled mt/rmt
> for my Mac at one point and I have it working on *BSD with modern tapes
> (just needed to grab the mtio.h file from BSD).
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180125/1de6d487/attachment-0001.html
>  
> <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180125/1de6d487/attachment-0001.html>>



smime.p7s
Description: S/MIME cryptographic signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

>> 
>> As far as I can tell, the GITHUB repository lacks such files.
>> https://github.com/simh/simh/tree/master/
> 
> No, it's right there.  Remember that Github displays are case sensitive, so 
> all the machine directories (being upper case, apart from "alpha") come 
> first, then the lowercase ones such as "doc".  

I’m laughing at myself.  Not sure about 3.9, as I’m not at that computer, but 
just checked GitHub.  I saw the doc directory and mistakenly thought it was 
HP3000 specific.  I should have clicked on it and checked.

Thanks!
Zane


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Tony Nicholson]

On Fri, 26 Jan 2018 at 07:00, Larry Baker  wrote:

> Clem,
>
> MultiNet included rmt support.  I do not know which versions included it
> or whether MultiNet has a Hobbyist License.
>


Process Software’s Multinet  and PMDF for OpenVMS have had hobbyist
licenses for a long time now. All you need to do is apply and provide an
LMF checksum value from your hobbyist licence - see the link from the
OpenVMS Resources page at

http://www.process.com/psc/resources/openvms-resource-center/

Tony
-- 
Tony Nicholson 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

The question is do the standard tape utilities know how to exploit it --
i.e. the moral equiv of the UNIX sequence:  cmd -f - | rmt host

I thought CJ and Co had some way to make that work in mid 90's versions of
VMS but I've forgotten the details (many beers ago).


ᐧ

On Thu, Jan 25, 2018 at 3:11 PM, Tony Nicholson  wrote:

> On Fri, 26 Jan 2018 at 07:00, Larry Baker  wrote:
>
>> Clem,
>>
>> MultiNet included rmt support.  I do not know which versions included it
>> or whether MultiNet has a Hobbyist License.
>>
>
>
> Process Software’s Multinet  and PMDF for OpenVMS have had hobbyist
> licenses for a long time now. All you need to do is apply and provide an
> LMF checksum value from your hobbyist licence - see the link from the
> OpenVMS Resources page at
>
> http://www.process.com/psc/resources/openvms-resource-center/
>
> Tony
> --
> Tony Nicholson 
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Larry Baker]

The answer is: the rmt protocol is not sufficient to support Backup.  From the 
Multinet Installation and Administrator's Guide 
(http://www.process.com/docs/multinet5_5/install_admin.pdf):

About the RMT Client

The RMT client MULTINET RMTALLOC is used for accessing tape or CD-ROM drives on 
remote hosts over TCP (using RSHELL). If restrictions apply where RSHELL does 
not work, or if RSHELL outputs spurious login messages or greetings, RMTALLOC 
does not work. RMTALLOC depends on an RMT server to function properly. RMTALLOC 
creates a pseudo device that appears as an OpenVMS physical device to the 
OpenVMS BACKUP, COPY, and other utilities. The pseudo device is named RMTx:, x 
is the unit number. The actual tape or CD-ROM drive can be on another MultiNet 
OpenVMS system or on any host running the RMT server, such as those running the 
BSD or SunOS UNIX operating system.

For CD-ROM, RMTALLOC treats the drive as a file system, which speeds file 
access.

There are some limits to the types of tape devices you can access on other 
operating systems and the amount of control available. Because UNIX tapes and 
tape drivers cannot write variable-length blocks and do not allow skipping 
forward over records between read operations, they cannot be used with OpenVMS 
BACKUP or COPY commands. 

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov



> On 25 Jan 2018, at 12:57:46 PM, Clem Cole  wrote:
> 
> The question is do the standard tape utilities know how to exploit it -- i.e. 
> the moral equiv of the UNIX sequence:  cmd -f - | rmt host
> 
> I thought CJ and Co had some way to make that work in mid 90's versions of 
> VMS but I've forgotten the details (many beers ago).
> 
> 
> ᐧ
> 
> On Thu, Jan 25, 2018 at 3:11 PM, Tony Nicholson  
> wrote:
> On Fri, 26 Jan 2018 at 07:00, Larry Baker  wrote:
> Clem,
> 
> MultiNet included rmt support.  I do not know which versions included it or 
> whether MultiNet has a Hobbyist License.
> 
> 
> Process Software’s Multinet  and PMDF for OpenVMS have had hobbyist licenses 
> for a long time now. All you need to do is apply and provide an LMF checksum 
> value from your hobbyist licence - see the link from the OpenVMS Resources 
> page at
> 
> http://www.process.com/psc/resources/openvms-resource-center/
> 
> Tony
> -- 
> Tony Nicholson 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

On Thu, Jan 25, 2018 at 4:14 PM, Larry Baker  wrote:

> Because UNIX tapes and tape drivers cannot write variable-length blocks
> and do not allow skipping forward over records between read operations
>

​That's not a correct statement.   UNIX does it great - I've used it (and
rmt) for years.  UNIX's tape driver is the most flexible of any OS I have
ever used (and I have done tapes on probably greater than 25 different OS's
over the last 40 years).  That's why I suggest it.  I wonder what the issue
for VMS is?

Hmm.. thinking about it, TCP sockets will remove the record orientation
(TCP creates an stream of octets without any records), so if you are doing
the funky RMS like stuff, its TCP that dropping those boundaries not the
UNIX tape driver.   If you want same then it need to be set as meta-data.
But the UNIX tape drive works as expected.   The 'block' size is the size
of the write, although I think the TM11 requires a minimum of 512 bytes.
Records passed with the MTIO ioctl' which mt/rmt all support..

That said,  I agree if he can get DECnet to work, that is likely to better
integrated into the utilities.

Clem

​
ᐧ
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Larry Baker]

I agree completely.  DECnet is your friend.  On VMS, it works right out of the 
box.  I have never had a need to try rmt.  As I mentioned in an earlier email, 
I have built a DECnet FAL-to-NFS gateway using DECnet-Linux.  It works great 
for storing Backup Save Sets on an NFS file server.  Once there, they can be 
compressed with gzip to save space for long-term archive.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov



> On 25 Jan 2018, at 1:31:25 PM, Clem Cole  wrote:
> 
> That said,  I agree if he can get DECnet to work, that is likely to better 
> integrated into the utilities.
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Mark Pizzolato]

I think the documentation comment “cannot write variable-length blocks and do 
not allow skipping forward over records between read operations” was written 
when talking about the common cartridge tapes that were available on 80s and 
90s Unix workstations.  I don’t recall the name.   These things only supported 
fixed block size operations and not variable record lengths (i.e. 80 byte tape 
labels, then different sized data records, etc.).  Given that the remote tape 
drive was a drive which could do variable length record activities, I think 
MultiNet’s rmt support actually worked well.  I don’t remember testing it 
though.  Whether someone should try to do that now to backup simulated VMS 
systems is another subject I may write about a little later.

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Clem Cole
Sent: Thursday, January 25, 2018 1:31 PM
To: Larry Baker ; SIMH 
Subject: Re: [Simh] VAX Tape Emulation?



On Thu, Jan 25, 2018 at 4:14 PM, Larry Baker 
mailto:ba...@usgs.gov>> wrote:
Because UNIX tapes and tape drivers cannot write variable-length blocks and do 
not allow skipping forward over records between read operations

​That's not a correct statement.   UNIX does it great - I've used it (and rmt) 
for years.  UNIX's tape driver is the most flexible of any OS I have ever used 
(and I have done tapes on probably greater than 25 different OS's over the last 
40 years).  That's why I suggest it.  I wonder what the issue for VMS is?

Hmm.. thinking about it, TCP sockets will remove the record orientation (TCP 
creates an stream of octets without any records), so if you are doing the funky 
RMS like stuff, its TCP that dropping those boundaries not the UNIX tape 
driver.   If you want same then it need to be set as meta-data.  But the UNIX 
tape drive works as expected.   The 'block' size is the size of the write, 
although I think the TM11 requires a minimum of 512 bytes.   Records passed 
with the MTIO ioctl' which mt/rmt all support..

That said,  I agree if he can get DECnet to work, that is likely to better 
integrated into the utilities.

Clem

​
[cid:~WRD161.jpg]ᐧ
[cid:~WRD161.jpg]ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Dennis Boone]

 > I think the documentation comment "cannot write variable-length
 > blocks and do not allow skipping forward over records between read
 > operations" was written when talking about the common cartridge tapes
 > that were available on 80s and 90s Unix workstations.  I don't recall
 > the name.  These things only supported fixed block size operations
 > and not variable record lengths (i.e. 80 byte tape labels, then
 > different sized data records, etc.).

Various QIC-defined formats.  Block size usually 512, though a few
computer companies apparently stuffed custom firmware into the drives to
get other block sizes.  (AS/400 did this, I think, and I've read that
some Prime machines did it, though the 50-Series tapes I've read have
been standard 512 blocks, with a controller-applied logical block
spanning scheme so the drive looked more like 9-track.)

De
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Dennis Boone]

 > At one point, I remember that some VMS folks in ZK3 (CJ Coppersmith
 > seems to stick in my head by I do not remember) were messing we
 > putting a the UCB sockets library into VMS and were somebody ported
 > the Berkeley rcmd(3) suite on VMS from Tru64.

If you're venturing into unix technology, it's possible to mount nfs
shares on the VMS machines.  Then you can use BACKUP to write save sets
onto the nfs share.  There seems to be some care needed with ADF
metadata.  Multinet seems to write this to a hidden file or
subdirectory; not sure what UCX/TCPIP do.

De
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Mark Pizzolato]

On Thursday, January 25, 2018 at 2:22 PM, Dennis Boone wrote:
>  > At one point, I remember that some VMS folks in ZK3 (CJ Coppersmith  
>  > seems to stick in my head by I do not remember) were messing we  
>  > putting a the UCB sockets library into VMS and were somebody ported  
>  > the Berkeley rcmd(3) suite on VMS from Tru64.
> 
> If you're venturing into unix technology, it's possible to mount nfs shares on
> the VMS machines.  Then you can use BACKUP to write save sets onto the nfs
> share.  There seems to be some care needed with ADF metadata.  Multinet
> seems to write this to a hidden file or subdirectory; not sure what UCX/TCPIP
> do.

I don't know where/how this discussion got steered into using rmt and/or other
IP based ideas (nfs) to access the simh tape drives, but if all of the involved 
systems
(simh VAX and the physical Alpha) are in a VMS Cluster, then the simulated VAX
Tape drives can be accessible cluster wide and they should just work as if they
were local devices.

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Johnny Billquist]

Zane - unless I remember wrong, there is a tool from DECUS to copy tapes 
to a file image, and then get that back to a tape again. The RSX version 
is called TPC, and I'm pretty sure it also exists for VMS.


Using that, pull your physical tapes into files, copy the files over to 
the simulated machines, and write them back out to simulated tapes there.


  Johnny

On 2018-01-25 16:17, Zane Healy wrote:
Just to be clear, I’m looking to backup a physical machine, to a virtual 
tape drive, such that I can restore the data to either SIMH or a 
Physical machine.  I don’t need to extract files.  I can extract files 
(and I have with some of the most critical) via NFS to my Mac.


Except for legacy hardware, most tapes I dealt with in the 90’s were in 
the 20-40GB range.  Current tapes now are multi-Terabyte, but not 
something most of us can afford to have at home, which is why I’m 
looking to go this route.


Zane




On Jan 25, 2018, at 5:39 AM, Tim Shoppa > wrote:


A couple of the tape image utilities I wrote or updated in the 1990s 
have that limit. Let me see if they are still in the SIMH utility 
tree. They never would’ve bitten me back in the 90s because the 
biggest reels I ever dealt with were 3600 feet at 6250 BPI, less than 
250 Mbytes.


Tim

On Jan 25, 2018, at 8:23 AM, Johnny Billquist > wrote:


Hmm. None of the tools I wrote ever had that limit. They just process 
records and don't give a damn about absolute disk or tape position.


Johnny


Tim Shoppa mailto:tsho...@gmail.com>> skrev: (25 
januari 2018 00:53:34 CET)


Many common tape image tools as of two decades use 32-bit
integers to carry offsets around and will be limited to 4Gigabyte
tape image sizes.

I don't think this is a fundamental limit to the tape image
formats used by SIMH, just a common limitation of the tape image
tools you might find from 20 years ago.

Tim.

On Wed, Jan 24, 2018 at 5:02 PM, Zane Healy mailto:heal...@avanthar.com>> wrote:

What type/size of tapes does the VAX emulation support?  I
was looking through the doc’s and it wasn’t obvious to me. 
Is there a size limit?


Thanks,
Zane



___
Simh mailing list
Simh@trailing-edge.com 
http://mailman.trailing-edge.com/mailman/listinfo/simh




--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Armistead, Jason]

Zane

The program that Johnny is thinking of is VMSPTC

http://www.digiater.nl/openvms/decus/vax86a/bnelson/vmstpc/vmstpc.c

Note sure if this is the latest, but it came up in the first set of Google 
search results for "VMSTPC"

Good luck
Jason


-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny Billquist
Sent: Thursday, 25 January 2018 5:48 PM
To: Zane Healy; Tim Shoppa
Cc: simh@trailing-edge.com
Subject: Re: [Simh] VAX Tape Emulation?

Zane - unless I remember wrong, there is a tool from DECUS to copy tapes to a 
file image, and then get that back to a tape again. The RSX version is called 
TPC, and I'm pretty sure it also exists for VMS.

Using that, pull your physical tapes into files, copy the files over to the 
simulated machines, and write them back out to simulated tapes there.

   Johnny

On 2018-01-25 16:17, Zane Healy wrote:
> Just to be clear, I’m looking to backup a physical machine, to a 
> virtual tape drive, such that I can restore the data to either SIMH or 
> a Physical machine.  I don’t need to extract files.  I can extract 
> files (and I have with some of the most critical) via NFS to my Mac.
> 
> Except for legacy hardware, most tapes I dealt with in the 90’s were 
> in the 20-40GB range.  Current tapes now are multi-Terabyte, but not 
> something most of us can afford to have at home, which is why I’m 
> looking to go this route.
> 
> Zane
> 
> 
> 
> 
>> On Jan 25, 2018, at 5:39 AM, Tim Shoppa > <mailto:tsho...@gmail.com>> wrote:
>>
>> A couple of the tape image utilities I wrote or updated in the 1990s 
>> have that limit. Let me see if they are still in the SIMH utility 
>> tree. They never would’ve bitten me back in the 90s because the 
>> biggest reels I ever dealt with were 3600 feet at 6250 BPI, less than
>> 250 Mbytes.
>>
>> Tim
>>
>> On Jan 25, 2018, at 8:23 AM, Johnny Billquist > <mailto:b...@softjar.se>> wrote:
>>
>>> Hmm. None of the tools I wrote ever had that limit. They just 
>>> process records and don't give a damn about absolute disk or tape position.
>>>
>>> Johnny
>>>
>>>
>>> Tim Shoppa mailto:tsho...@gmail.com>> skrev: (25 
>>> januari 2018 00:53:34 CET)
>>>
>>> Many common tape image tools as of two decades use 32-bit
>>> integers to carry offsets around and will be limited to 4Gigabyte
>>> tape image sizes.
>>>
>>> I don't think this is a fundamental limit to the tape image
>>> formats used by SIMH, just a common limitation of the tape image
>>> tools you might find from 20 years ago.
>>>
>>> Tim.
>>>
>>> On Wed, Jan 24, 2018 at 5:02 PM, Zane Healy >> <mailto:heal...@avanthar.com>> wrote:
>>>
>>> What type/size of tapes does the VAX emulation support?  I
>>> was looking through the doc’s and it wasn’t obvious to me. 
>>> Is there a size limit?
>>>
>>> Thanks,
>>> Zane
>>>
>>>
>>>
>>> ___
>>> Simh mailing list
>>> Simh@trailing-edge.com <mailto:Simh@trailing-edge.com>
>>> 
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.trailing-2Dedge.com_mailman_listinfo_simh&d=DwIGaQ&c=ilBQI1lupc9Y65XwNblLtw&r=CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4&m=Tuv134HGgnWc1vxno4wpeUgonHLScwAzyLK3tGM--Wo&s=KG58MZsCGTQPkaifTTlluf-_bo-FOhuQ7JJUEBB3Hvk&e=
>>>  
>>> 
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.trailin
>>> g-2Dedge.com_mailman_listinfo_simh&d=DwIGaQ&c=ilBQI1lupc9Y65XwNblLtw
>>> &r=CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4&m=Tuv134HGgnWc1vxno4w
>>> peUgonHLScwAzyLK3tGM--Wo&s=KG58MZsCGTQPkaifTTlluf-_bo-FOhuQ7JJUEBB3H
>>> vk&e= >


-- 
Johnny Billquist  || "I'm on a bus
   ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.trailing-2Dedge.com_mailman_listinfo_simh&d=DwIGaQ&c=ilBQI1lupc9Y65XwNblLtw&r=CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4&m=Tuv134HGgnWc1vxno4wpeUgonHLScwAzyLK3tGM--Wo&s=KG58MZsCGTQPkaifTTlluf-_bo-FOhuQ7JJUEBB3Hvk&e=
 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

On Thu, Jan 25, 2018 at 4:57 PM, Mark Pizzolato  wrote:

> I think the documentation comment “cannot write variable-length blocks
> and do not allow skipping forward over records between read operations”
> was written when talking about the common cartridge tapes that were
> available on 80s and 90s Unix workstations.  I don’t recall the name.
>
That was not UNIX, that was the QIC standard.   Yes, those were blocked at
512 bytes.   Apollo's domain systems had a b*tch of time with them because
their standard disk block was 1056 bytes​



>   These things only supported fixed block size operations and not variable
> record lengths (i.e. 80 byte tape labels, then different sized data
> records, etc.).
>
​Right the 80 byte ANSI label, then different length data records.  UNIX
handles that fine, even with RMT.​  FYI: My grad school housemate, Tom
Quarles (of SPICE3 fame) wrote the ANSI tape and bunch of
other tape support that most UNIX systems used, explicitly so he could
read/write VMS tapes for the DEC guys who were doing some of the funding of
the USB CAD lab.   Leffler (who wrote rmt) used Tom's tape stuff for the
original debug of rmt.




>   Given that the remote tape drive was a drive which could do variable
> length record activities, I think MultiNet’s rmt support actually worked
> well.  I don’t remember testing it though.  Whether someone should try to
> do that now to backup simulated VMS systems is another subject I may write
> about a little later.
>

​Understood.   I was just suggest​ing trying to keep another emulated
system out of the scheme and going directly to the remote device either
through DECnet or rmt or maybe even using a NAS as virtual tape files.   It
just seemed running a Linux with a tape and then running an emulated VAX on
top of that seemed like an extra layer of indirection if there was an
easier path.


​
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

The old netnews copytape program from the 80s did the same thing.  Somebody
has a GitHub version of it: https://github.com/halfmanhalftaco/copytape


ᐧ

On Thu, Jan 25, 2018 at 5:47 PM, Johnny Billquist  wrote:

> Zane - unless I remember wrong, there is a tool from DECUS to copy tapes
> to a file image, and then get that back to a tape again. The RSX version is
> called TPC, and I'm pretty sure it also exists for VMS.
>
> Using that, pull your physical tapes into files, copy the files over to
> the simulated machines, and write them back out to simulated tapes there.
>
>   Johnny
>
> On 2018-01-25 16:17, Zane Healy wrote:
>
>> Just to be clear, I’m looking to backup a physical machine, to a virtual
>> tape drive, such that I can restore the data to either SIMH or a Physical
>> machine.  I don’t need to extract files.  I can extract files (and I have
>> with some of the most critical) via NFS to my Mac.
>>
>> Except for legacy hardware, most tapes I dealt with in the 90’s were in
>> the 20-40GB range.  Current tapes now are multi-Terabyte, but not something
>> most of us can afford to have at home, which is why I’m looking to go this
>> route.
>>
>> Zane
>>
>>
>>
>>
>> On Jan 25, 2018, at 5:39 AM, Tim Shoppa >> tsho...@gmail.com>> wrote:
>>>
>>> A couple of the tape image utilities I wrote or updated in the 1990s
>>> have that limit. Let me see if they are still in the SIMH utility tree.
>>> They never would’ve bitten me back in the 90s because the biggest reels I
>>> ever dealt with were 3600 feet at 6250 BPI, less than 250 Mbytes.
>>>
>>> Tim
>>>
>>> On Jan 25, 2018, at 8:23 AM, Johnny Billquist >> b...@softjar.se>> wrote:
>>>
>>> Hmm. None of the tools I wrote ever had that limit. They just process
 records and don't give a damn about absolute disk or tape position.

 Johnny


 Tim Shoppa mailto:tsho...@gmail.com>> skrev: (25
 januari 2018 00:53:34 CET)

 Many common tape image tools as of two decades use 32-bit
 integers to carry offsets around and will be limited to 4Gigabyte
 tape image sizes.

 I don't think this is a fundamental limit to the tape image
 formats used by SIMH, just a common limitation of the tape image
 tools you might find from 20 years ago.

 Tim.

 On Wed, Jan 24, 2018 at 5:02 PM, Zane Healy >>> > wrote:

 What type/size of tapes does the VAX emulation support?  I
 was looking through the doc’s and it wasn’t obvious to me.
Is there a size limit?

 Thanks,
 Zane



 ___
 Simh mailing list
 Simh@trailing-edge.com 
 http://mailman.trailing-edge.com/mailman/listinfo/simh
 

>>>
>
> --
> Johnny Billquist  || "I'm on a bus
>   ||  on a psychedelic trip
> email: b...@softjar.se ||  Reading murder books
> pdp is alive! ||  tryin' to stay hip" - B. Idol
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Johnny Billquist]

On 2018-01-25 22:31, Clem Cole wrote:



On Thu, Jan 25, 2018 at 4:14 PM, Larry Baker > wrote:


Because UNIX tapes and tape driverscannot write variable-length
blocks and do not allow skipping forward over records between read
operations


​That's not a correct statement.   UNIX does it great - I've used it 
(and rmt) for years.  UNIX's tape driver is the most flexible of any OS 
I have ever used (and I have done tapes on probably greater than 25 
different OS's over the last 40 years).  That's why I suggest it.  I 
wonder what the issue for VMS is?


Agreed. Unix have no problems with skips or variable length records. But 
it does require that you use the raw device (however, no sane person 
would ever use the block tape device, that is something completely 
useless in Unix).


Hmm.. thinking about it, TCP sockets will remove the record orientation 
(TCP creates an stream of octets without any records), so if you are 
doing the funky RMS like stuff, its TCP that dropping those boundaries 
not the UNIX tape driver.   If you want same then it need to be set as 
meta-data.  But the UNIX tape drive works as expected.   The 'block' 
size is the size of the write, although I think the TM11 requires a 
minimum of 512 bytes.   Records passed with the MTIO ioctl' which mt/rmt 
all support..


This is obviously a limitation of the rmt protocol, which makes the 
assumption that all records are of equal length. Works for the standard 
Unix tools, which also tend to want to use tapes with a fixed record length.


I thought that maybe rmt did preserve record length information, but 
thinking about it I can't actually remember that it did. But in case rmt 
do handle variable length records, then it should work. Whatever VMS 
does involving RMS and so on, is irrelevant. When the data hits the tape 
there is only variable length records and nothing else to it.


And no, TM11 controllers do not have a minimum length of 512 bytes.

That said,  I agree if he can get DECnet to work, that is likely to 
better integrated into the utilities.


I'd dump the tapes to local files using some tape copy program. Then I 
can transfer those files around using DECnet or TCP/IP, or whatever, and 
then write them out on simulated tape on whatever other VMS system he has.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Johnny Billquist]

On 2018-01-25 22:57, Mark Pizzolato wrote:
I think the documentation comment “cannot write variable-length blocks 
and do not allow skipping forward over records between read operations” 
was written when talking about the common cartridge tapes that were 
available on 80s and 90s Unix workstations.  I don’t recall the name.   
These things only supported fixed block size operations and not variable 
record lengths (i.e. 80 byte tape labels, then different sized data 
records, etc.).


Exabytes?
I know there was some people who thought they couldn't do variable size 
reocrds, but that is actually incorrect. They can. It might be wasting 
space on the underlying tape or something, I don't know. But I certainly 
had Exabytes connected to VAXen and PDP-11s, and used the normal DEC 
tools to play around, and Exabytes behaves just like any other tape 
drive, in all aspects.


  Johnny

  Given that the remote tape drive was a drive which
could do variable length record activities, I think MultiNet’s rmt 
support actually worked well.  I don’t remember testing it though.  
Whether someone should try to do that now to backup simulated VMS 
systems is another subject I may write about a little later.


*From:*Simh [mailto:simh-boun...@trailing-edge.com] *On Behalf Of *Clem Cole
*Sent:* Thursday, January 25, 2018 1:31 PM
*To:* Larry Baker ; SIMH 
*Subject:* Re: [Simh] VAX Tape Emulation?

On Thu, Jan 25, 2018 at 4:14 PM, Larry Baker <mailto:ba...@usgs.gov>> wrote:


Because UNIX tapes and tape driverscannot write variable-length
blocks and do not allow skipping forward over records between read
operations

​That's not a correct statement.   UNIX does it great - I've used it 
(and rmt) for years.  UNIX's tape driver is the most flexible of any OS 
I have ever used (and I have done tapes on probably greater than 25 
different OS's over the last 40 years).  That's why I suggest it.  I 
wonder what the issue for VMS is?


Hmm.. thinking about it, TCP sockets will remove the record orientation 
(TCP creates an stream of octets without any records), so if you are 
doing the funky RMS like stuff, its TCP that dropping those boundaries 
not the UNIX tape driver.   If you want same then it need to be set as 
meta-data.  But the UNIX tape drive works as expected.   The 'block' 
size is the size of the write, although I think the TM11 requires a 
minimum of 512 bytes.   Records passed with the MTIO ioctl' which mt/rmt 
all support..


That said,  I agree if he can get DECnet to work, that is likely to 
better integrated into the utilities.


Clem

​

Image removed by sender.ᐧ

Image removed by sender.ᐧ



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh




--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Phil Budne]

Johnny Billquist  wrote:
> This is obviously a limitation of the rmt protocol, which makes the 
> assumption that all records are of equal length. Works for the standard 
> Unix tools, which also tend to want to use tapes with a fixed record length.

From the FreeBSD 10.3 rmt(8) man page:

 . The protocol is comprised of the following commands,
 which are sent as indicated - no spaces are supplied between the command
 and its arguments, or between its arguments, and `\n' indicates that a
 newline should be supplied:
..

 Wcount\n
 Write data onto the open device.  The rmt utility reads count
 bytes from the connection, aborting if a premature end-of-file is
 encountered.  The response value is that returned from the
 write(2) call.

So each write to the tape can have a different record length.

All this reminds me how happy I am not to deal with tape drives any
more!  I can't remember how many times I issued "mt fsf" without an
"&" not remembering the operation made the process incorruptible, and
resistant to CTRL-Z.

I always said tape drivers and boot roms always sucked because once
you got them working, you didn't want to touch them again!


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Johnny Billquist]

On 2018-01-26 01:25, Phil Budne wrote:

Johnny Billquist  wrote:

This is obviously a limitation of the rmt protocol, which makes the
assumption that all records are of equal length. Works for the standard
Unix tools, which also tend to want to use tapes with a fixed record length.


 From the FreeBSD 10.3 rmt(8) man page:

  . The protocol is comprised of the following commands,
  which are sent as indicated - no spaces are supplied between the command
  and its arguments, or between its arguments, and `\n' indicates that a
  newline should be supplied:
..

  Wcount\n
  Write data onto the open device.  The rmt utility reads count
  bytes from the connection, aborting if a premature end-of-file is
  encountered.  The response value is that returned from the
  write(2) call.

So each write to the tape can have a different record length.


Ah! Thanks. Then my muddy memory foiled me (I blame suggestions made me 
believe it).
So, rmt should really just work also from VMS, unless there are some 
other issues.


Still, tar and dump (and dd) under Unix do tend to use the same block 
size for all reads/writes, so they don't really test such things that much.



All this reminds me how happy I am not to deal with tape drives any
more!  I can't remember how many times I issued "mt fsf" without an
"&" not remembering the operation made the process incorruptible, and
resistant to CTRL-Z.

I always said tape drivers and boot roms always sucked because once
you got them working, you didn't want to touch them again!


:-)
I don't actually find them so bad. But they are more of a headache under 
Unix than under some DEC OS, most of the time, I'd say. But 
occasionally, you can get stuck waiting for tapes for a long time.


All that said, we have one drive online at Update, connected to Magica. 
A TU81, which can do 1600 (PE) and 6250 (GCR) BPI. Just in case anyone 
ever stumbles upon a tape that needs to be read...


We might, at some point, try to get a TU77 up and running as well, so 
that we can deal with 800 (NRZI) BPI as well.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Johnny Billquist]

On 2018-01-26 00:44, Clem Cole wrote:



On Thu, Jan 25, 2018 at 4:57 PM, Mark Pizzolato > wrote:


I think the documentation comment “cannot write variable-length
blocks and do not allow skipping forward over records between read
operations” was written when talking about the common cartridge
tapes that were available on 80s and 90s Unix workstations.  I don’t
recall the name.

That was not UNIX, that was the QIC standard.   Yes, those were blocked 
at 512 bytes.   Apollo's domain systems had a b*tch of time with them 
because their standard disk block was 1056 bytes​


Hmm. Ah. THose QIC tapes. Never liked them much, and never played much 
with them.
Domain OS using 1056 bytes? On what systems? I used a lot of DN3000, 
4000 and 5000 systems, and they used bog standard disk drives with 512 
byte sectors. (Interesting systems in some ways, but their windowing 
system was pretty horrible.)



   These things only supported fixed block size operations and not
variable record lengths (i.e. 80 byte tape labels, then different
sized data records, etc.).

​Right the 80 byte ANSI label, then different length data records.  UNIX 
handles that fine, even with RMT.​  FYI: My grad school housemate, Tom 
Quarles (of SPICE3 fame) wrote the ANSI tape and bunch of 
other tape support that most UNIX systems used, explicitly so he could 
read/write VMS tapes for the DEC guys who were doing some of the funding 
of the USB CAD lab.   Leffler (who wrote rmt) used Tom's tape stuff for 
the original debug of rmt.



   Given that the remote tape drive was a drive which could do
variable length record activities, I think MultiNet’s rmt support
actually worked well.  I don’t remember testing it though.  Whether
someone should try to do that now to backup simulated VMS systems is
another subject I may write about a little later.


​Understood.   I was just suggest​ing trying to keep another emulated 
system out of the scheme and going directly to the remote device either 
through DECnet or rmt or maybe even using a NAS as virtual tape files.   
It just seemed running a Linux with a tape and then running an emulated 
VAX on top of that seemed like an extra layer of indirection if there 
was an easier path.


Yes, I think the approaches are trying to do things in too complicated 
ways as well.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

On Thu, Jan 25, 2018 at 7:46 PM, Johnny Billquist  wrote:

>
> Domain OS using 1056 bytes? On what systems? I used a lot of DN3000, 4000
> and 5000 systems, and they used bog standard disk drives with 512 byte
> sectors. (Interesting systems in some ways, but their windowing system was
> pretty horrible.)


​All of the early ones -- until the DN1 I'm pretty sure.   They used a
1024 basic block, but Mike Spourer had used the Xerox Alto trick of putting
some of the FS metadata into the controller microcode. That's what the
extra 32 bytes were.   Masscomp and Apollo used the same SMS 'OMPTI 7000'
controller for the ST506/ESDI drives, and you'll see it in the
SMS marketing literature as it says something like "Supports 512/1024/1056
block sizes".  I have controller doc somewhere in my basement - thinking
about it, SMS might have even supported blocks as large as 4K - but I
definitely remember them putting the 1056 stuff in for Apollo.   Remember
we all knew each other, the firms were one town apart and couple of people
had somebody working at each.

Anyway, with the DN1, Apollo started to use the Xylogics 4xx
controllers and Xylogics either wanted too much money for custom microcode
or the Apollo guys decided custom microcode was too expensive.   In our
Stellar days, we used to kid Mike about the 1056 bytes choice. BTW, Mike
might have done the same thing at Prime, I never looked at/knew much the
low level I/O of those systems. [@Stellar we used 4096 as the basic size
but that was a multiple of 512 so it was never an issue].

I've lost track of Mike, but Scott Baden (who is now a Prof at UCSD) was a
CPU guy on Prime 750 and I'm still pretty close too, and he might know.
I'll ask him if he remembers next time I see him.

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

s/couple of people/couple of families/
ᐧ

On Thu, Jan 25, 2018 at 8:47 PM, Clem Cole  wrote:

>
>
> On Thu, Jan 25, 2018 at 7:46 PM, Johnny Billquist  wrote:
>
>>
>> Domain OS using 1056 bytes? On what systems? I used a lot of DN3000, 4000
>> and 5000 systems, and they used bog standard disk drives with 512 byte
>> sectors. (Interesting systems in some ways, but their windowing system was
>> pretty horrible.)
>
>
> ​All of the early ones -- until the DN1 I'm pretty sure.   They used a
> 1024 basic block, but Mike Spourer had used the Xerox Alto trick of putting
> some of the FS metadata into the controller microcode. That's what the
> extra 32 bytes were.   Masscomp and Apollo used the same SMS 'OMPTI 7000'
> controller for the ST506/ESDI drives, and you'll see it in the
> SMS marketing literature as it says something like "Supports 512/1024/1056
> block sizes".  I have controller doc somewhere in my basement - thinking
> about it, SMS might have even supported blocks as large as 4K - but I
> definitely remember them putting the 1056 stuff in for Apollo.   Remember
> we all knew each other, the firms were one town apart and couple of people
> had somebody working at each.
>
> Anyway, with the DN1, Apollo started to use the Xylogics 4xx
> controllers and Xylogics either wanted too much money for custom microcode
> or the Apollo guys decided custom microcode was too expensive.   In our
> Stellar days, we used to kid Mike about the 1056 bytes choice. BTW, Mike
> might have done the same thing at Prime, I never looked at/knew much the
> low level I/O of those systems. [@Stellar we used 4096 as the basic size
> but that was a multiple of 512 so it was never an issue].
>
> I've lost track of Mike, but Scott Baden (who is now a Prof at UCSD) was a
> CPU guy on Prime 750 and I'm still pretty close too, and he might know.
> I'll ask him if he remembers next time I see him.
>
> Clem
> ᐧ
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

If it was applicable to the situation, then VMSTPC would work great.  It’s 
already installed on my Alpha, and I’m pretty sure there is a VAX binary for it 
in the VAX directory on there.  I also have it installed on my RSX-11M+.  It’s 
definitely a great tool.  Just not for this. :-)

Zane


> On Jan 25, 2018, at 2:54 PM, Armistead, Jason  
> wrote:
> 
> Zane
> 
> The program that Johnny is thinking of is VMSPTC
> 
> http://www.digiater.nl/openvms/decus/vax86a/bnelson/vmstpc/vmstpc.c
> 
> Note sure if this is the latest, but it came up in the first set of Google 
> search results for "VMSTPC"
> 
> Good luck
> Jason
> 
> 
> -Original Message-
> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny 
> Billquist
> Sent: Thursday, 25 January 2018 5:48 PM
> To: Zane Healy; Tim Shoppa
> Cc: simh@trailing-edge.com
> Subject: Re: [Simh] VAX Tape Emulation?
> 
> Zane - unless I remember wrong, there is a tool from DECUS to copy tapes to a 
> file image, and then get that back to a tape again. The RSX version is called 
> TPC, and I'm pretty sure it also exists for VMS.
> 
> Using that, pull your physical tapes into files, copy the files over to the 
> simulated machines, and write them back out to simulated tapes there.
> 
>   Johnny
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

> On Jan 25, 2018, at 2:22 PM, Dennis Boone  wrote:
> 
> If you're venturing into unix technology, it's possible to mount nfs
> shares on the VMS machines.  Then you can use BACKUP to write save sets
> onto the nfs share.  There seems to be some care needed with ADF
> metadata.  Multinet seems to write this to a hidden file or
> subdirectory; not sure what UCX/TCPIP do.

I actually looked into this option around 2008 (for the same Alpha).  If I 
remember correctly I ran into a problem on the VMS side of the file size limit 
(I have the same disk size now I had in 2008).  This can work, but you have to 
break larger disks up into chunks.  I’m hoping to avoid that, with the solution 
I’m looking at.

Zane


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

> On Jan 25, 2018, at 1:39 PM, Larry Baker  wrote:
> 
> I agree completely.  DECnet is your friend.  On VMS, it works right out of 
> the box.  I have never had a need to try rmt.  As I mentioned in an earlier 
> email, I have built a DECnet FAL-to-NFS gateway using DECnet-Linux.  It works 
> great for storing Backup Save Sets on an NFS file server.  Once there, they 
> can be compressed with gzip to save space for long-term archive.
> 
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov 
How large of a saveset can you create doing this?  This might work for another 
use case I’m aware of.

Zane


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

> On Jan 25, 2018, at 4:18 PM, Johnny Billquist  wrote:
> 
> Exabytes?
> I know there was some people who thought they couldn't do variable size 
> reocrds, but that is actually incorrect. They can. It might be wasting space 
> on the underlying tape or something, I don't know. But I certainly had 
> Exabytes connected to VAXen and PDP-11s, and used the normal DEC tools to 
> play around, and Exabytes behaves just like any other tape drive, in all 
> aspects.
> 
>  Johnny

Back when the Alpha in question was an AlphaStation 200 4/233, it had an 
Exabyte EXB-10 tape library hooked to it with at the time “massive” 5GB tapes. 
:-)  At that time my max disk size was 2GB, and I could still buy new Exabyte 
tapes.  I have a SCSI box with a Exabyte 8500 drive and a CD-ROM drive setup to 
hook to any DEC system that needs it.

The Alpha also has a TLZ06 drive installed in it, and a TZ30 and DLT7000 drive 
that can be hooked up.

So if I cared to trust old tape drives, I have options for my backups.  I 
don’t, so I’m looking to go virtual.

Zane



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Larry Baker]

As far as I am aware, there is no limit, up to the amount of disk space 
available.  Backup Save Sets are just RMS sequential files with fixed record 
lengths (on disk, usually 32768 bytes, on tape, I think the default is 4096, 
except 2048 for Interchange format).

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov



> On 25 Jan 2018, at 6:04:01 PM, Zane Healy  wrote:
> 
> 
>> On Jan 25, 2018, at 1:39 PM, Larry Baker > > wrote:
>> 
>> I agree completely.  DECnet is your friend.  On VMS, it works right out of 
>> the box.  I have never had a need to try rmt.  As I mentioned in an earlier 
>> email, I have built a DECnet FAL-to-NFS gateway using DECnet-Linux.  It 
>> works great for storing Backup Save Sets on an NFS file server.  Once there, 
>> they can be compressed with gzip to save space for long-term archive.
>> 
>> Larry Baker
>> US Geological Survey
>> 650-329-5608
>> ba...@usgs.gov 
> How large of a saveset can you create doing this?  This might work for 
> another use case I’m aware of.
> 
> Zane
> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Johnny Billquist]

Then I must have misunderstood the usecase. I thought you were looking at 
preserving a bunch of tapes from a future failure of the hardware.

Are you then looking at ways to perform backups of a physical system to virtual 
tape?

I would probably give the virtual machine a really big disk and run backup to 
that remote disk and not try to play with remote tapes.

  Johnny 


Zane Healy  skrev: (26 januari 2018 02:54:20 CET)
>If it was applicable to the situation, then VMSTPC would work great. 
>It’s already installed on my Alpha, and I’m pretty sure there is a VAX
>binary for it in the VAX directory on there.  I also have it installed
>on my RSX-11M+.  It’s definitely a great tool.  Just not for this. :-)
>
>Zane
>
>
>> On Jan 25, 2018, at 2:54 PM, Armistead, Jason
> wrote:
>> 
>> Zane
>> 
>> The program that Johnny is thinking of is VMSPTC
>> 
>> http://www.digiater.nl/openvms/decus/vax86a/bnelson/vmstpc/vmstpc.c
>> 
>> Note sure if this is the latest, but it came up in the first set of
>Google search results for "VMSTPC"
>> 
>> Good luck
>> Jason
>> 
>> 
>> -Original Message-
>> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of
>Johnny Billquist
>> Sent: Thursday, 25 January 2018 5:48 PM
>> To: Zane Healy; Tim Shoppa
>> Cc: simh@trailing-edge.com
>> Subject: Re: [Simh] VAX Tape Emulation?
>> 
>> Zane - unless I remember wrong, there is a tool from DECUS to copy
>tapes to a file image, and then get that back to a tape again. The RSX
>version is called TPC, and I'm pretty sure it also exists for VMS.
>> 
>> Using that, pull your physical tapes into files, copy the files over
>to the simulated machines, and write them back out to simulated tapes
>there.
>> 
>>   Johnny
>___
>Simh mailing list
>Simh@trailing-edge.com
>http://mailman.trailing-edge.com/mailman/listinfo/simh

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Paul Koning]

That sounds right.  Incidentally, I'm not sure how well known this is, but RSTS 
(with the "new BACKUP" introduced in V9.0) uses the VMS backup set format.  
That means you can use backup sets to interchange between the two, with some 
care because of the differences in file naming.

paul

> On Jan 25, 2018, at 9:11 PM, Larry Baker  wrote:
> 
> As far as I am aware, there is no limit, up to the amount of disk space 
> available.  Backup Save Sets are just RMS sequential files with fixed record 
> lengths (on disk, usually 32768 bytes, on tape, I think the default is 4096, 
> except 2048 for Interchange format).
> 
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

Yes, I’m trying to preserve the data on hard drive from future hardware 
failures.

I started out looking to backup to virtual tape.  I’m still looking to do that, 
but I’m now mainly looking to move the majority of the data off of the Physical 
Alpha, and to a Virtual VAX.  I hadn’t realized how big of virtual disks could 
be attached, so didn’t consider that a practical option.

Last night I installed Linux on an old Core i5 system I’d picked up recently to 
run SIMH on.  Today I’ll try to get a new VAX system added to my cluster.  
Unlike my other two virtual VAXen, this one is on a host with a 500GB drive 
(tiny by todays standards, but huge compared to the Alpha, or  where the other 
two virtual VAXen are running).

Zane




> On Jan 26, 2018, at 1:27 AM, Johnny Billquist  wrote:
> 
> Then I must have misunderstood the usecase. I thought you were looking at 
> preserving a bunch of tapes from a future failure of the hardware.
> 
> Are you then looking at ways to perform backups of a physical system to 
> virtual tape?
> 
> I would probably give the virtual machine a really big disk and run backup to 
> that remote disk and not try to play with remote tapes.
> 
> Johnny 
> 
> 
> Zane Healy  skrev: (26 januari 2018 02:54:20 CET)
> If it was applicable to the situation, then VMSTPC would work great.  It’s 
> already installed on my Alpha, and I’m pretty sure there is a VAX binary for 
> it in the VAX directory on there.  I also have it installed on my RSX-11M+.  
> It’s definitely a great tool.  Just not for this. :-)
> 
> Zane
> 
> 
>  On Jan 25, 2018, at 2:54 PM, Armistead, Jason  
> wrote:
>  
>  Zane
>  
>  The program that Johnny is thinking of is VMSPTC
>  
>  http://www.digiater.nl/openvms/decus/vax86a/bnelson/vmstpc/vmstpc.c 
> <http://www.digiater.nl/openvms/decus/vax86a/bnelson/vmstpc/vmstpc.c>
>  
>  Note sure if this is the latest, but it came up in the first set of Google 
> search results for "VMSTPC"
>  
>  Good luck
>  Jason
>  
>  
>  -Original Message-
>  From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny 
> Billquist
>  Sent: Thursday, 25 January 2018 5:48 PM
>  To: Zane Healy; Tim Shoppa
>  Cc: simh@trailing-edge.com
>  Subject: Re: [Simh] VAX Tape Emulation?
>  
>  Zane - unless I remember wrong, there is a tool from DECUS to copy tapes to 
> a file image, and then get that back to a tape again. The RSX version is 
> called TPC, and I'm pretty sure it also exists for VMS.
>  
>  Using that, pull your physical tapes into files, copy the files over to the 
> simulated machines, and write them back out to simulated tapes there.
>  
>Johnny
> 
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh 
> <http://mailman.trailing-edge.com/mailman/listinfo/simh>
> -- 
> Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Johnny Billquist]

Heh. As a reference. I'm running an RSX system on simh with four 8G disks. No 
point in being cheap here.

  Johnny 


Zane Healy  skrev: (26 januari 2018 16:53:11 CET)
>Yes, I’m trying to preserve the data on hard drive from future hardware
>failures.
>
>I started out looking to backup to virtual tape.  I’m still looking to
>do that, but I’m now mainly looking to move the majority of the data
>off of the Physical Alpha, and to a Virtual VAX.  I hadn’t realized how
>big of virtual disks could be attached, so didn’t consider that a
>practical option.
>
>Last night I installed Linux on an old Core i5 system I’d picked up
>recently to run SIMH on.  Today I’ll try to get a new VAX system added
>to my cluster.  Unlike my other two virtual VAXen, this one is on a
>host with a 500GB drive (tiny by todays standards, but huge compared to
>the Alpha, or  where the other two virtual VAXen are running).
>
>Zane
>
>
>
>
>> On Jan 26, 2018, at 1:27 AM, Johnny Billquist  wrote:
>> 
>> Then I must have misunderstood the usecase. I thought you were
>looking at preserving a bunch of tapes from a future failure of the
>hardware.
>> 
>> Are you then looking at ways to perform backups of a physical system
>to virtual tape?
>> 
>> I would probably give the virtual machine a really big disk and run
>backup to that remote disk and not try to play with remote tapes.
>> 
>> Johnny 
>> 
>> 
>> Zane Healy  skrev: (26 januari 2018 02:54:20
>CET)
>> If it was applicable to the situation, then VMSTPC would work great. 
>It’s already installed on my Alpha, and I’m pretty sure there is a VAX
>binary for it in the VAX directory on there.  I also have it installed
>on my RSX-11M+.  It’s definitely a great tool.  Just not for this. :-)
>> 
>> Zane
>> 
>> 
>>  On Jan 25, 2018, at 2:54 PM, Armistead, Jason
> wrote:
>>  
>>  Zane
>>  
>>  The program that Johnny is thinking of is VMSPTC
>>  
>>  http://www.digiater.nl/openvms/decus/vax86a/bnelson/vmstpc/vmstpc.c
><http://www.digiater.nl/openvms/decus/vax86a/bnelson/vmstpc/vmstpc.c>
>>  
>>  Note sure if this is the latest, but it came up in the first set of
>Google search results for "VMSTPC"
>>  
>>  Good luck
>>  Jason
>>  
>>  
>>  -Original Message-
>>  From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of
>Johnny Billquist
>>  Sent: Thursday, 25 January 2018 5:48 PM
>>  To: Zane Healy; Tim Shoppa
>>  Cc: simh@trailing-edge.com
>>  Subject: Re: [Simh] VAX Tape Emulation?
>>  
>>  Zane - unless I remember wrong, there is a tool from DECUS to copy
>tapes to a file image, and then get that back to a tape again. The RSX
>version is called TPC, and I'm pretty sure it also exists for VMS.
>>  
>>  Using that, pull your physical tapes into files, copy the files over
>to the simulated machines, and write them back out to simulated tapes
>there.
>>  
>>Johnny
>> 
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
><http://mailman.trailing-edge.com/mailman/listinfo/simh>
>> -- 
>> Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

I’d posted about this nearly a month ago, and have made some real progress this 
weekend.

Configuration:
MONK
OpenVMS 8.3/Alpha
Compaq XP1000/667

RENNY
OpenVMS 7.3/VAX
SIMH MicroVAX3900

I’m backing MONK up over the Cluster to a “tape drive” on RENNY.

First, Ubuntu includes a package for SIMH V3.8-1.  If you’re just using disk 
and network, it seems to be just fine.  If you want to write tapes, it seems 
fine.  If you want to read tapes, upgrade, as it appears to crash OpenVMS V7.3, 
at least when messing with “tapes" the size I’m creating.  Hopefully the 
crashing isn’t a clustering issue, I still need to test that.  I downloaded the 
latest SIMH sources, and built them today, and I appear to be able to read 
tapes without crashing.  At least it doesn’t crash when reading from the SIMH 
VAX, I still need to try reading one over the cluster on my Alpha.

My largest backup, from the Alpha, to a virtual “tape”, has been 23.5GB, which 
resulted in a 27.5GB image file.

Speeds are painful to say the least, but at least I seem to be getting readable 
backups (I will be doing more testing on that once the current backup 
completes).

One stupid question, I assume that SIMH emulates the network interface at 
10Mbit.  Is there any way to speed that up?  Granted, all my real VAXen are 
limited to 10Mbit, but a faster link in SIMH would be nice.

Zane



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Mark Pizzolato]

On Monday, February 19, 2018 at 9:55 PM, Zane Healy wrote:
> I’d posted about this nearly a month ago, and have made some real progress
> this weekend.
> 
> Configuration:
> MONK
> OpenVMS 8.3/Alpha
> Compaq XP1000/667
> 
> RENNY
> OpenVMS 7.3/VAX
> SIMH MicroVAX3900
> 
> I’m backing MONK up over the Cluster to a “tape drive” on RENNY.
> 
> First, Ubuntu includes a package for SIMH V3.8-1.  If you’re just using disk 
> and
> network, it seems to be just fine.  If you want to write tapes, it seems 
> fine.  If
> you want to read tapes, upgrade, as it appears to crash OpenVMS V7.3, at least
> when messing with “tapes" the size I’m creating.  Hopefully the crashing 
> isn’t a
> clustering issue, I still need to test that.  I downloaded the latest SIMH 
> sources,
> and built them today, and I appear to be able to read tapes without crashing.
> At least it doesn’t crash when reading from the SIMH VAX, I still need to try
> reading one over the cluster on my Alpha.
[...]
> One stupid question, I assume that SIMH emulates the network interface at
> 10Mbit.  Is there any way to speed that up?  Granted, all my real VAXen are
> limited to 10Mbit, but a faster link in SIMH would be nice.

The network interface is not artificially limited to 10Mbit.  Years ago, I 
measured some 25Mbit on my desktop system.  I suggest that you run 
with the latest code from https://github.com/simh/simh.  Simh v3.8-1
was from a long time ago, and significant changes have been made since 
then.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Larry Baker]

Zane

> On Feb 20, 2018, at 9:00 AM, simh-requ...@trailing-edge.com wrote:
> 
> Date: Mon, 19 Feb 2018 21:55:00 -0800
> From: Zane Healy mailto:heal...@avanthar.com>>
> To: Zane Healy mailto:heal...@avanthar.com>>
> Cc: simh mailto:simh@trailing-edge.com>>
> Subject: Re: [Simh] VAX Tape Emulation?
> Message-ID: <1665a095-d246-4272-91ac-ef2bbc45a...@avanthar.com 
> <mailto:1665a095-d246-4272-91ac-ef2bbc45a...@avanthar.com>>
> Content-Type: text/plain; charset=utf-8
> 
> I’m backing MONK up over the Cluster to a “tape drive” on RENNY.


I'm really puzzled why you prefer to backup to a SIMH virtual tape image.  You 
can create empty SIMH VAX virtual disk drives for your clustered virtual VAX 
and backup directly to a save set on disk.  You can even make a backup disk 
image—bootable on a SIMH Alpha, when that arrives.  You can read files 
individually on a backup disk image any time you want to.  There is no need to 
go through the entire save set to find one file.

As far as your backup speed, you might be rate limited by the XOR blocks being 
added and by the (less likely) SIMH virtual tape formatting.  You should be 
able to test that by doing a backup on the SIMH VAX to the virtual tape drive 
to take the network out of the picture.  You can control how often XOR blocks 
are written, or eliminate them altogether.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

> On Feb 19, 2018, at 10:42 PM, Mark Pizzolato  wrote:
> 
> On Monday, February 19, 2018 at 9:55 PM, Zane Healy wrote:
>> I’d posted about this nearly a month ago, and have made some real progress
>> this weekend.
>> 
>> Configuration:
>> MONK
>> OpenVMS 8.3/Alpha
>> Compaq XP1000/667
>> 
>> RENNY
>> OpenVMS 7.3/VAX
>> SIMH MicroVAX3900
>> 
>> I’m backing MONK up over the Cluster to a “tape drive” on RENNY.
>> 
>> First, Ubuntu includes a package for SIMH V3.8-1.  If you’re just using disk 
>> and
>> network, it seems to be just fine.  If you want to write tapes, it seems 
>> fine.  If
>> you want to read tapes, upgrade, as it appears to crash OpenVMS V7.3, at 
>> least
>> when messing with “tapes" the size I’m creating.  Hopefully the crashing 
>> isn’t a
>> clustering issue, I still need to test that.  I downloaded the latest SIMH 
>> sources,
>> and built them today, and I appear to be able to read tapes without crashing.
>> At least it doesn’t crash when reading from the SIMH VAX, I still need to try
>> reading one over the cluster on my Alpha.
> [...]
>> One stupid question, I assume that SIMH emulates the network interface at
>> 10Mbit.  Is there any way to speed that up?  Granted, all my real VAXen are
>> limited to 10Mbit, but a faster link in SIMH would be nice.
> 
> The network interface is not artificially limited to 10Mbit.  Years ago, I 
> measured some 25Mbit on my desktop system.  I suggest that you run 
> with the latest code from https://github.com/simh/simh.  Simh v3.8-1
> was from a long time ago, and significant changes have been made since 
> then.

I grabbed the latest copy of the source from GitHub yesterday.  I ran another 
backup last night using the current SIMH, and it was the first to die before 
finishing, but there could have been other issues.  I’m trying again, as that 
was also my first attempt and running it with the /LIST option.

As noted, the latest SIMH was needed to successfully read the tape (I simply 
did a listing).

It’s hard to judge the speed accurately, due to tape Metadata, but I’m seeing 
the ‘virtual tape’ be created at about 510KB/sec.  That is faster than what I 
was previously seeing.  I wouldn’t be surprised if part of the bottleneck is 
the virtual tape drive.

Zane

 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Mark Pizzolato]

On Tuesday, February 20, 2018 at 12:25 PM, Zane Healy wrote:
> > On Feb 19, 2018, at 10:42 PM, Mark Pizzolato 
> wrote:
> >
> > On Monday, February 19, 2018 at 9:55 PM, Zane Healy wrote:
> >> I’d posted about this nearly a month ago, and have made some real
> >> progress this weekend.
> >>
> >> Configuration:
> >> MONK
> >> OpenVMS 8.3/Alpha
> >> Compaq XP1000/667
> >>
> >> RENNY
> >> OpenVMS 7.3/VAX
> >> SIMH MicroVAX3900
> >>
> >> I’m backing MONK up over the Cluster to a “tape drive” on RENNY.
> >>
> >> First, Ubuntu includes a package for SIMH V3.8-1.  If you’re just
> >> using disk and network, it seems to be just fine.  If you want to
> >> write tapes, it seems fine.  If you want to read tapes, upgrade, as
> >> it appears to crash OpenVMS V7.3, at least when messing with “tapes"
> >> the size I’m creating.  Hopefully the crashing isn’t a clustering
> >> issue, I still need to test that.  I downloaded the latest SIMH sources, 
> >> and
> built them today, and I appear to be able to read tapes without crashing.
> >> At least it doesn’t crash when reading from the SIMH VAX, I still
> >> need to try reading one over the cluster on my Alpha.
> > [...]
> >> One stupid question, I assume that SIMH emulates the network
> >> interface at 10Mbit.  Is there any way to speed that up?  Granted,
> >> all my real VAXen are limited to 10Mbit, but a faster link in SIMH would be
> nice.
> >
> > The network interface is not artificially limited to 10Mbit.  Years
> > ago, I measured some 25Mbit on my desktop system.  I suggest that you
> > run with the latest code from https://github.com/simh/simh.  Simh
> > v3.8-1 was from a long time ago, and significant changes have been
> > made since then.
> 
> I grabbed the latest copy of the source from GitHub yesterday.  I ran another
> backup last night using the current SIMH, and it was the first to die before
> finishing, but there could have been other issues.  I’m trying again, as that 
> was
> also my first attempt and running it with the /LIST option.
> 
> As noted, the latest SIMH was needed to successfully read the tape (I simply
> did a listing).
> 
> It’s hard to judge the speed accurately, due to tape Metadata, but I’m seeing
> the ‘virtual tape’ be created at about 510KB/sec.  That is faster than what I 
> was
> previously seeing.  I wouldn’t be surprised if part of the bottleneck is the
> virtual tape drive.

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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

> On Feb 20, 2018, at 1:58 PM, Mark Pizzolato  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.

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:[00...]*.*;* 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:[00...]*.*;* 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.EXE834A3A00 834AA800
PAGE_MANAGEMENT.EXE834AB200 834B5200
WORKING_SET_MANAGEMENT.EXE 834CA000 834CFE00
IMAGE_MANAGEMENT.EXE   834D0800 834D3E00
EVENT_FLAGS_AND_ASTS.EXE   834D4400 834D6600
IO_ROUTINES.EXE834D7000 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




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: 00Primary CPU: 00

Active/available CPU masks: 0001/0001

Current process = NULL

Register dump

R0 = 204C
R1 = 800A
R2 = 
R3 = 83AA28C0
R4 = 83A6B780
R5 = 83AA2A40
R6 = 
R7 = 00DE
R8 = 83A6E080
R9 = 83A9C080
R10= 83A6F000
R11= 7FFB9F0A
AP = 7FF6D558
FP = 7FF6D534
SP = 84595574
PC = 83C395E6
PSL= 04080004

Kernel/interrupt/boot stack

8459557C  204C
84595580  800A
84595584  83C391F1
84595588  83A5F4A3
8459558C  83A6B780
84595590  83A5FF0E
84595594  83A6B780
84595598  83A60B95
8459559C  83B61CC0
845955A0  83B7D140
845955A4  83A6F1F0
845955A8  83A9C2C0
845955AC  83A615C7
845955B0  83A60C25
845955B4  83A6E098
845955B8  84594210
845955BC  0034
845955C0  3778
845955C4  7FFB9E80
845955C8  7FFB9F3E
845955CC  7FFB9F0A
845955D0  7FF6D558
845955D4  83567ED2
845955D8  003E
845955DC  
845955E0  0009
845955E4  84594000
845955E8  83B7A

Re: [Simh] VAX Tape Emulation?

[Larry Baker]

Zane,

> On Feb 20, 2018, at 7:58 PM, simh-requ...@trailing-edge.com wrote:
> 
> Date: Tue, 20 Feb 2018 19:58:31 -0800
> From: Zane Healy mailto:heal...@avanthar.com>>
> To: Mark Pizzolato mailto:m...@infocomm.com>>
> Cc: simh mailto:simh@trailing-edge.com>>
> Subject: Re: [Simh] VAX Tape Emulation?
> Message-ID: <121aee2a-10da-4ffe-8028-59b65b6ed...@avanthar.com 
> <mailto:121aee2a-10da-4ffe-8028-59b65b6ed...@avanthar.com>>
> Content-Type: text/plain; charset=utf-8
> 
> 
>> On Feb 20, 2018, at 1:58 PM, Mark Pizzolato > <mailto: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.
> 
> 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.

> ...

> End Result, I think I’m going to have to resort to the disk solution.
> 
> Zane


You should be able to write an ODS-5 backup save set to an ODS-2 disk image on 
your SIMH VAX.  It may help you decide whether the cluster I/O or the virtual 
tape drive is the culprit crashing your VAX.  Make the VAX disk large enough.  
Cluster mount it.  Do the backup entirely from the Alpha using MSCP I/O.

One thing I've never tried is to restore ODS-5 files to an ODS-2 disk.  Does 
BACKUP give you some options to at least deal with renaming non-ODS-2 file 
names?

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

> On Feb 20, 2018, at 8:17 PM, Larry Baker  wrote:
> 
> You should be able to write an ODS-5 backup save set to an ODS-2 disk image 
> on your SIMH VAX.  It may help you decide whether the cluster I/O or the 
> virtual tape drive is the culprit crashing your VAX.  Make the VAX disk large 
> enough.  Cluster mount it.  Do the backup entirely from the Alpha using MSCP 
> I/O.
> 
> One thing I've never tried is to restore ODS-5 files to an ODS-2 disk.  Does 
> BACKUP give you some options to at least deal with renaming non-ODS-2 file 
> names?
> 
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov 
I’m not sure what will happen if you try restore ODS-5 files to a ODS-2 disk.  
That’s something I’ve not tried.

Interesting, it wasn’t just the VAX that I crashed.  I just realized I also 
crashed the Alpha. 

Zane



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [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  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:[00...]*.*;* 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:[00...]*.*;* 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.EXE834A3A00 834AA800
> PAGE_MANAGEMENT.EXE834AB200 834B5200
> WORKING_SET_MANAGEMENT.EXE 834CA000 834CFE00
> IMAGE_MANAGEMENT.EXE   834D0800 834D3E00
> EVENT_FLAGS_AND_ASTS.EXE   834D4400 834D6600
> IO_ROUTINES.EXE834D7000 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: 00Primary CPU: 00
> 
> Active/available CPU masks: 0001/0001
> [...]

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 probl

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

> On Feb 20, 2018, at 8:56 PM, Mark Pizzolato  wrote:
> 
> TQ limited to 2000GB means a limit of 2TB.  Do you have disks on the AXP 
> system 
> that big?

Unfortunately the 2000GB is a typo on my part.  A 2GB “tape" is too small for 
me, and has been for a long time.  From the documentation:
"User-specified capacity must be between 50 and 2000 MB. The TQK50 does not 
support the BOOT
command.”

> What happens if you merely backup a few hundred MB to the tape
> with /VERIFY?

I’m not sure, I’d thought about giving that a try.  Right now I’m going to 
focus on getting the data moved.

> 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.

I’ll see about testing that later.  While it’s not that practical to backup to 
2GB tapes, it would be interesting to see if the problem exists in the TQ 
emulation.

>> 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.

In this case, that’s not a problem.  I’m creating 36GB “disks".

> 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.

This I’m going to have to try.  I wouldn’t have thought of trying it, and it 
would definitely fulfill one of my goals with this project.

Zane





___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Mark Pizzolato]

On Tuesday, February 20, 2018 at 9:29 PM, Zane Healy wrote:
> > On Feb 20, 2018, at 8:56 PM, Mark Pizzolato  wrote:
> >
> > TQ limited to 2000GB means a limit of 2TB.  Do you have disks on the
> > AXP system that big?
> 
> Unfortunately the 2000GB is a typo on my part.  A 2GB “tape" is too small for
> me, and has been for a long time.  From the documentation:
> "User-specified capacity must be between 50 and 2000 MB. The TQK50 does
> not support the BOOT command.”

What documentation are you talking about?  Ahh... the vax_doc.doc TQK50 section.

The:

  SET TQ TKUSER{=n} 

command.  This section of the document was copied from the PDP11 simulator and 
on that simulator the TQK50 is indeed not bootable.  Additionally, the 2000MB 
limit is only true if your host environment doesn't have the ability to 
read/write files larger than 2GB.  All reasonable host systems today can handle 
files larger than 2GB, so then the limit for n in the TKUSER{=n} command is 
20 MB instead of 2000 MB.

Meanwhile if you read a couple of lines further in the document it says:

Regardless of the controller type, individual units can be set to a specific 
reel capacity in MB, or to unlimited capacity:

 SET TQn CAPAC=m  set unit n capacity to m 
MB (0 = unlimited)
 SHOW TQn CAPAC   show unit n capacity in MB

On the VAX (MicroVAX 3900) simulator, the TQ device is indeed bootable.  

You can use:

  $ @sys$update:stabackit MUA0: 

to put standalone backup on a tape.  From the VAX console ROM ">>>" 
you can BOOT MUA0:

> > What happens if you merely backup a few hundred MB to the tape with
> > /VERIFY?
> 
> I’m not sure, I’d thought about giving that a try.  Right now I’m going to 
> focus
> on getting the data moved.
> 
> > 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.
> 
> I’ll see about testing that later.  While it’s not that practical to backup 
> to 2GB
> tapes, it would be interesting to see if the problem exists in the TQ 
> emulation.
> 
> >> 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.
> 
> In this case, that’s not a problem.  I’m creating 36GB “disks".
> 
> > 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.
> 
> This I’m going to have to try.  I wouldn’t have thought of trying it, and it 
> would
> definitely fulfill one of my goals with this project.

Without regard to tape capacity, I believe that the backup to disk will be the 
far 
superior (and faster) approach.

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Tim Shoppa]

Is this possibly a host compiler switch or host OS or host file system issue? 
The way Zane is hitting some limit at 2Gbytes for both emulated disks and tapes 
sounds like the limits of 32 bit operating systems or file systems using signed 
ints.

Tim

> On Feb 21, 2018, at 12:29 AM, Zane Healy  wrote:
> 
> 
>> On Feb 20, 2018, at 8:56 PM, Mark Pizzolato  wrote:
>> 
>> TQ limited to 2000GB means a limit of 2TB.  Do you have disks on the AXP 
>> system 
>> that big?
> 
> Unfortunately the 2000GB is a typo on my part.  A 2GB “tape" is too small for 
> me, and has been for a long time.  From the documentation:
> "User-specified capacity must be between 50 and 2000 MB. The TQK50 does not 
> support the BOOT
> command.”
> 
>> What happens if you merely backup a few hundred MB to the tape
>> with /VERIFY?
> 
> I’m not sure, I’d thought about giving that a try.  Right now I’m going to 
> focus on getting the data moved.
> 
>> 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.
> 
> I’ll see about testing that later.  While it’s not that practical to backup 
> to 2GB tapes, it would be interesting to see if the problem exists in the TQ 
> emulation.
> 
>>> 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.
> 
> In this case, that’s not a problem.  I’m creating 36GB “disks".
> 
>> 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.
> 
> This I’m going to have to try.  I wouldn’t have thought of trying it, and it 
> would definitely fulfill one of my goals with this project.
> 
> Zane
> 
> 
> 
> 
> 
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

Tim,
Somewhere you misunderstood me.   The only 2GB limit I’ve found is that the 
documentation says the TQ emulation only supports tapes up to 2GB.

I have a 50GB drive, and I’ve created 27GB tapes.

My problem is with reading the SIMH tapes, over the cluster, from the Alpha.  I 
can read them just fine with SIMH.

Zane



> On Feb 21, 2018, at 4:03 AM, Tim Shoppa  wrote:
> 
> Is this possibly a host compiler switch or host OS or host file system issue? 
> The way Zane is hitting some limit at 2Gbytes for both emulated disks and 
> tapes sounds like the limits of 32 bit operating systems or file systems 
> using signed ints.
> 
> Tim
> 
>> On Feb 21, 2018, at 12:29 AM, Zane Healy  wrote:
>> 
>> 
>>> On Feb 20, 2018, at 8:56 PM, Mark Pizzolato  wrote:
>>> 
>>> TQ limited to 2000GB means a limit of 2TB.  Do you have disks on the AXP 
>>> system 
>>> that big?
>> 
>> Unfortunately the 2000GB is a typo on my part.  A 2GB “tape" is too small 
>> for me, and has been for a long time.  From the documentation:
>> "User-specified capacity must be between 50 and 2000 MB. The TQK50 does not 
>> support the BOOT
>> command.”
>> 
>>> What happens if you merely backup a few hundred MB to the tape
>>> with /VERIFY?
>> 
>> I’m not sure, I’d thought about giving that a try.  Right now I’m going to 
>> focus on getting the data moved.
>> 
>>> 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.
>> 
>> I’ll see about testing that later.  While it’s not that practical to backup 
>> to 2GB tapes, it would be interesting to see if the problem exists in the TQ 
>> emulation.
>> 
 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.
>> 
>> In this case, that’s not a problem.  I’m creating 36GB “disks".
>> 
>>> 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.
>> 
>> This I’m going to have to try.  I wouldn’t have thought of trying it, and it 
>> would definitely fulfill one of my goals with this project.
>> 
>> Zane
>> 
>> 
>> 
>> 
>> 
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh