[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

[Mark Pizzolato]

Post by 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?

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.

[Paul Koning]

Post by Mark Pizzolato

Post by 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?

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

[Zane Healy]

Post by Paul Koning

Post by Mark Pizzolato

Post by 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?

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

[Paul Koning]

Post by Zane Healy
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 <unitname> capac=0

paul

[Zane Healy]

Post by Paul Koning

Post by Zane Healy
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.
set <unitname> 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

[Paul Koning]

Post by Zane Healy

...

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

Post by Zane Healy
...
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.

Post by Zane Healy
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.

Post by Zane Healy
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

[Zane Healy]

Post by Paul Koning

Post by 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

[Hittner, David T [US] (MS)]

You are not alone. I thought that myself the first time I saw it in GitHub. ;-)
Dave

-----Original Message-----
From: Simh [mailto:simh-***@trailing-edge.com] On Behalf Of Zane Healy
Sent: Thursday, January 25, 2018 2:46 PM
To: Paul Koning <***@comcast.net>
Cc: simh <***@trailing-edge.com>; Mark Pizzolato <***@infocomm.com>
Subject: EXT :Re: [Simh] VAX Tape Emulation?

Post by Paul Koning

Post by 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
***@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Zane Healy]

Post by Mark Pizzolato

Post by 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?

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

[Clem Cole]

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

[Zane Healy]

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

[Dennis Boone]

Post by Clem Cole
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

[Mark Pizzolato]

Post by Clem Cole
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

[Zane Healy]

Post by Dennis Boone
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

[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
ᐧ

Post by 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
http://mailman.trailing-edge.com/mailman/listinfo/simh

ᐧ

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

Post by 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
http://mailman.trailing-edge.com/mailman/listinfo/simh

[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 <***@avanthar.com<mailto:***@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
***@trailing-edge.com<mailto:***@trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Dennis Boone]

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

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

[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

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

Post by Zane Healy
What type/size of tapes does the VAX emulation support? I was

looking

Post by Zane Healy
through the doc’s and it wasn’t obvious to me. Is there a size

limit?

Post by Zane Healy
Thanks,
Zane
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

[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

Post by 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

Post by Mark Pizzolato
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.

Post by Mark Pizzolato
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
http://mailman.trailing-edge.com/mailman/listinfo/simh

--
Skickat från min Android-enhet med K-9 Mail. UrsÀkta min fåordighet.

[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

Post by 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

Post by 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
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.
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
http://mailman.trailing-edge.com/mailman/listinfo/simh <http://mailman.trailing-edge.com/mailman/listinfo/simh>

[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

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

Post by 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

Post by 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
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.
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
http://mailman.trailing-edge.com/mailman/listinfo/simh
<http://mailman.trailing-edge.com/mailman/listinfo/simh>

[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


ᐧ

Post by 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

Post by 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

Post by 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
Hmm. None of the tools I wrote ever had that limit. They just process

Post by Johnny Billquist
records and don't give a damn about absolute disk or tape position.
Johnny
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.
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
http://mailman.trailing-edge.com/mailman/listinfo/simh
<http://mailman.trailing-edge.com/mailman/listinfo/simh>

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

[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

Message: 6
Date: Wed, 24 Jan 2018 14:25:39 -0800
Subject: Re: [Simh] VAX Tape Emulation?
Content-Type: text/plain; charset=utf-8

Post by Mark Pizzolato

Post by 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?

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

[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

Message: 2
Date: Wed, 24 Jan 2018 17:33:26 -0800
Subject: Re: [Simh] VAX Tape Emulation?
Content-Type: text/plain; charset=utf-8

Post by Paul Koning

Post by Mark Pizzolato

Post by 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?

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

[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

Message: 1
Date: Thu, 25 Jan 2018 09:57:54 -0500
Subject: Re: [Simh] VAX Tape Emulation?
Content-Type: text/plain; charset="utf-8"

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

[Tony Nicholson]

Post by Larry Baker
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

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


ᐧ

Post by Tony Nicholson

Post by Larry Baker
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
--

[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

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

[Clem Cole]

Post by Larry Baker
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

​
ᐧ
ᐧ

[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

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

[Zane Healy]

Post by 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

How large of a saveset can you create doing this? This might work for another use case I’m aware of.

Zane

[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

Post by Zane Healy

Post by 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

How large of a saveset can you create doing this? This might work for another use case I’m aware of.
Zane

[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

Post by 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

[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-***@trailing-edge.com] On Behalf Of Clem Cole
Sent: Thursday, January 25, 2018 1:31 PM
To: Larry Baker <***@usgs.gov>; SIMH <***@trailing-edge.com>
Subject: Re: [Simh] VAX Tape Emulation?



On Thu, Jan 25, 2018 at 4:14 PM, Larry Baker <***@usgs.gov<mailto:***@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]ᐧ

[Clem Cole]

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

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​

Post by Mark Pizzolato
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.

Post by Mark Pizzolato
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.


​
ᐧ

[Johnny Billquist]

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

[Clem Cole]

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 DN10000 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 DN10000, 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
ᐧ

[Clem Cole]

s/couple of people/couple of families/
ᐧ

Post by Clem Cole

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 DN10000 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 DN10000, 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
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
ᐧ

[Johnny Billquist]

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.
*Sent:* Thursday, January 25, 2018 1:31 PM
*Subject:* Re: [Simh] VAX Tape Emulation?
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
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Zane Healy]

Post by Johnny Billquist
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

[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

[Johnny Billquist]

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

[Phil Budne]

Post by Johnny Billquist
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!

[Johnny Billquist]

Post by Phil Budne

Post by Johnny Billquist
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.

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

Post by Phil Budne
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

[Larry Baker]

Zane,

Now you lost me. You initially said you wanted to backup SIMH VAXes. If you want to do the backup to a virtual tape drive from a real VAX, you'll need something like MultiNet, and something on the other end that speaks the rmt protocol. If you want to do a backup to something over the network, DECnet is your friend. You can (and, I do) run SIMH VAXes on your Mac with huge virtual disk drives attached. Your physical VAXes can boot into Standalone Backup and you can send the Backup Save Sets over DECnet to the SIMH VAX on your Mac. If your physical VMS machine is an Alpha, as I recall, Alpha VMS did not support the same bootable Standalone Backup method as VAX VMS. That is, you could not create a bootable SYSE directory tree on your boot disk. However, the bootable Alpha VMS install disks let you drop into a console session where you could do that. That means you have to have one of those bootable install disks and a CD-ROM reader on your physical Alpha.

Unless you are looking for the experience of dealing with tape drives, I think the DECnet remote file access method is easier and more useful.

Larry Baker
US Geological Survey
650-329-5608

Message: 2
Date: Thu, 25 Jan 2018 07:17:38 -0800
Subject: Re: [Simh] VAX Tape Emulation?
Content-Type: text/plain; charset="utf-8"
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

[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-***@trailing-edge.com] On Behalf Of Johnny Billquist
Sent: Thursday, 25 January 2018 5:48 PM
To: Zane Healy; Tim Shoppa
Cc: ***@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

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

Post by 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

Post by 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
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.
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
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: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
***@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=

[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

Post by 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-----
Sent: Thursday, 25 January 2018 5:48 PM
To: Zane Healy; Tim Shoppa
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

[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

Post by 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
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-----

Johnny Billquist

Sent: Thursday, 25 January 2018 5:48 PM
To: Zane Healy; Tim Shoppa
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
http://mailman.trailing-edge.com/mailman/listinfo/simh

[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

Post by 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
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
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-----
Sent: Thursday, 25 January 2018 5:48 PM
To: Zane Healy; Tim Shoppa
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
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.

[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

Post by 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

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

Post by Johnny Billquist
Are you then looking at ways to perform backups of a physical system

to virtual tape?

Post by Johnny Billquist
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.

Post by Johnny Billquist
Johnny

CET)

Post by Johnny Billquist
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. :-)

Post by Johnny Billquist
Zane
On Jan 25, 2018, at 2:54 PM, Armistead, Jason
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>

Post by Johnny Billquist
Note sure if this is the latest, but it came up in the first set of

Google search results for "VMSTPC"

Post by Johnny Billquist
Good luck
Jason
-----Original Message-----

Johnny Billquist

Post by Johnny Billquist
Sent: Thursday, 25 January 2018 5:48 PM
To: Zane Healy; Tim Shoppa
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.

Post by Johnny Billquist
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.

Post by Johnny Billquist
Johnny
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

<http://mailman.trailing-edge.com/mailman/listinfo/simh>

Post by Johnny Billquist
--
Skickat från min Android-enhet med K-9 Mail. UrsÀkta min fåordighet.

[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

[Mark Pizzolato]

Post by Zane Healy
I’d posted about this nearly a month ago, and have made some real progress this weekend.
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.

[...]

Post by Zane Healy
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.

[Zane Healy]

Post by Mark Pizzolato

Post by Zane Healy
I’d posted about this nearly a month ago, and have made some real progress
this weekend.
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.

[...]

Post by Zane Healy
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

[Mark Pizzolato]

Post by Zane Healy

Post by Mark Pizzolato

Post by Zane Healy
I’d posted about this nearly a month ago, and have made some real
progress this weekend.
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.

Post by Mark Pizzolato

Post by Zane Healy
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.

[...]

Post by Zane Healy
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.

Post by Mark Pizzolato
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

[Zane Healy]

Post by Mark Pizzolato
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:[000000...]*.*;* tape:A0005


Running this from the Alpha, crashes VAX, once it goes to Verify. This happened on both V3.8-1 and on Current.
backup/verify $1$DKC300:[000000...]*.*;* tape:A0005
%MOUNT-I-MOUNTED, A0004 mounted on _$5$MSA0: (RENNY)
%BACKUP-I-STARTVERIFY, starting verification pass at 21-FEB-2018 00:11:02.08
%BACKUP-F-POSITERR, error positioning _$5$MSA0:[]A0005.;
-SYSTEM-F-VOLINV, volume is not software enabled


Partial output from the Console of the VAX. If you look further down, you’ll see the full output from trying to read a tape.

SYSGETSYI.EXE 8344EA00 83450A00
SYSDEVICE.EXE 83450E00 83453800
MESSAGE_ROUTINES.EXE 83453E00 8345A000
EXCEPTION.EXE 8346A600 83474E00
LOGICAL_NAMES.EXE 83475600 83498E00
SECURITY.EXE 83499800 834A3200
LOCKING.EXE 834A3A00 834AA800
PAGE_MANAGEMENT.EXE 834AB200 834B5200
WORKING_SET_MANAGEMENT.EXE 834CA000 834CFE00
IMAGE_MANAGEMENT.EXE 834D0800 834D3E00
EVENT_FLAGS_AND_ASTS.EXE 834D4400 834D6600
IO_ROUTINES.EXE 834D7000 834E7600
PROCESS_MANAGEMENT.EXE 834E9000 834F6A00
ERRORLOG.EXE 83560200 83560E00
PRIMITIVE_IO.EXE 83561400 83562600
SYSTEM_SYNCHRONIZATION_UNI.EXE 83562A00 83566E00
SYSTEM_PRIMITIVES_MIN.EXE 83567400 8356B200

**** Starting memory dump, writing dump to unit number 0
. . . . . . .
**** Memory dump complete, dump written to unit number 0

HALT instruction, PC: 83C4D909 (MOVB 400(R1),R0)
sim> q




Okay, here is the crash from when I tried to read a tape from the Alpha. I’m not sure if this is a cluster issue, or a SIMH issue. I could test this with real hardware, but it would take quite a bit of time to dig out all the bits, assuming they still work.


**** Fatal BUG CHECK, version = V7.3 CLUEXIT, Node voluntarily exiting VAXcluster

Crash CPU: 00 Primary CPU: 00

Active/available CPU masks: 00000001/00000001

Current process = NULL

Register dump

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

Kernel/interrupt/boot stack

8459557C 0000204C
84595580 0000800A
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 00000034
845955C0 00003778
845955C4 7FFB9E80
845955C8 7FFB9F3E
845955CC 7FFB9F0A
845955D0 7FF6D558
845955D4 83567ED2
845955D8 0000003E
845955DC 00000000
845955E0 00000009
845955E4 84594000
845955E8 83B7A200
845955EC 848CC400
845955F0 0000C6E8
845955F4 00000000
845955F8 834E9F8D
845955FC 04C30000


Loaded images

[SYSMSG]SYSMSG.EXE 83331200 83377C00
[SYS$LDR]SYSLDR_DYN.EXE 8356EA00 83570A00
[SYS$LDR]DDIF$RMS_EXTENSION.EXE 83570E00 83572000
[SYS$LDR]RECOVERY_UNIT_SERVICES.EXE 83572200 83572A00
[SYS$LDR]RMS.EXE 83377E00 833A4800
SYS$NTA.EXE 833ED400 833ED600
VAXCLUSTER_CACHE.EXE 833EDA00 833F2600
SYS$NETWORK_SERVICES.EXE 833F2C00 833F2E00
SYS$UTC_SERVICES.EXE 833F3400 833F4200
SYS$TRANSACTION_SERVICES.EXE 833F4800 83402600
SYS$IPC_SERVICES.EXE 83402A00 83420A00
CPULOA.EXE 83420C00 83426000
LMF$GROUP_TABLE.EXE 83428400 83429E00
SYSLICENSE.EXE 8342A200 8342D400
F11BXQP.EXE 8342D800 8344D000
SNAPSHOT_SERVICES.EXE 8344D800 8344E400
SYSGETSYI.EXE 8344EA00 83450A00
SYSDEVICE.EXE 83450E00 83453800
MESSAGE_ROUTINES.EXE 83453E00 8345A000
EXCEPTION.EXE 8346A600 83474E00
LOGICAL_NAMES.EXE 83475600 83498E00
SECURITY.EXE 83499800 834A3200
LOCKING.EXE 834A3A00 834AA800
PAGE_MANAGEMENT.EXE 834AB200 834B5200
WORKING_SET_MANAGEMENT.EXE 834CA000 834CFE00
IMAGE_MANAGEMENT.EXE 834D0800 834D3E00
EVENT_FLAGS_AND_ASTS.EXE 834D4400 834D6600
IO_ROUTINES.EXE 834D7000 834E7600
PROCESS_MANAGEMENT.EXE 834E9000 834F6A00
ERRORLOG.EXE 83560200 83560E00
PRIMITIVE_IO.EXE 83561400 83562600
SYSTEM_SYNCHRONIZATION_UNI.EXE 83562A00 83566E00
SYSTEM_PRIMITIVES_MIN.EXE 83567400 8356B200

**** Starting memory dump, writing dump to unit number 0
. . . . . . .
**** Memory dump complete, dump written to unit number 0

HALT instruction, PC: 83C4D909 (MOVB 400(R1),R0)
sim>


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

Zane

[Mark Pizzolato]

Post by Mark Pizzolato

Post by Mark Pizzolato
I would actually attribute the 'improved' behavior to the fact that tape I/O to

TQ

Post by Mark Pizzolato
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.

Post by Mark Pizzolato
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.

Post by Mark Pizzolato
- 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?

Post by Mark Pizzolato
Realistically, once I get these “tapes” created, I’ll be migrating part of the data
from physical disks on the Alpha, to disks on SIMH/VAX. I’ve already done
some experimentation with that. Unfortunately I have ODS-5 data, and some
software requires an Alpha.
Okay… Some more info on the crashes I’m seeing. The first is specific to the
current source in GitHub. It seems pretty obvious at this point that I can write
a tape from the Alpha, to a virtual SIMH VAX tape drive, but trying to read the
data crashes the SIMH VAX.
This command started, got about half way through, and then the terminal
session on my Alpha that I was running this on was reset. The backup did not
complete.
backup/verify/list $1$DKC300:[000000...]*.*;* tape:A0005
Running this from the Alpha, crashes VAX, once it goes to Verify. This
happened on both V3.8-1 and on Current.
backup/verify $1$DKC300:[000000...]*.*;* tape:A0005
%MOUNT-I-MOUNTED, A0004 mounted on _$5$MSA0: (RENNY)
%BACKUP-I-STARTVERIFY, starting verification pass at 21-FEB-2018 00:11:02.08
%BACKUP-F-POSITERR, error positioning _$5$MSA0:[]A0005.;
-SYSTEM-F-VOLINV, volume is not software enabled
Partial output from the Console of the VAX. If you look further down, you’ll
see the full output from trying to read a tape.
SYSGETSYI.EXE 8344EA00 83450A00
SYSDEVICE.EXE 83450E00 83453800
MESSAGE_ROUTINES.EXE 83453E00 8345A000
EXCEPTION.EXE 8346A600 83474E00
LOGICAL_NAMES.EXE 83475600 83498E00
SECURITY.EXE 83499800 834A3200
LOCKING.EXE 834A3A00 834AA800
PAGE_MANAGEMENT.EXE 834AB200 834B5200
WORKING_SET_MANAGEMENT.EXE 834CA000 834CFE00
IMAGE_MANAGEMENT.EXE 834D0800 834D3E00
EVENT_FLAGS_AND_ASTS.EXE 834D4400 834D6600
IO_ROUTINES.EXE 834D7000 834E7600
PROCESS_MANAGEMENT.EXE 834E9000 834F6A00
ERRORLOG.EXE 83560200 83560E00
PRIMITIVE_IO.EXE 83561400 83562600
SYSTEM_SYNCHRONIZATION_UNI.EXE 83562A00 83566E00
SYSTEM_PRIMITIVES_MIN.EXE 83567400 8356B200
**** Starting memory dump, writing dump to unit number 0
. . . . . . .
**** Memory dump complete, dump written to unit number 0
HALT instruction, PC: 83C4D909 (MOVB 400(R1),R0)
sim> q

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

Post by Mark Pizzolato
Okay, here is the crash from when I tried to read a tape from the Alpha. I’m
not sure if this is a cluster issue, or a SIMH issue. I could test this with real
hardware, but it would take quite a bit of time to dig out all the bits, assuming
they still work.
**** Fatal BUG CHECK, version = V7.3 CLUEXIT, Node voluntarily exiting VAXcluster
Crash CPU: 00 Primary CPU: 00
Active/available CPU masks: 00000001/00000001
[...]

The simh tape will have very different timing characteristics when
reading as compared to a real physical tape. I would still recommend
the TQ device since that I/O is asynch and isn't delaying instruction
execution (and cluster timing activities) during data transfers. The
cluster exit may merely be due to timing on SCS messages.

Post by Mark Pizzolato
End Result, I think I’m going to have to resort to the disk solution.

The disk solution has effectively similar limits (something just under
2TB) is the maximum RQ disk size.

Meanwhile, you needn't worry about ODS-5 vs ODS-2. You're
driving the backup from the AXP side, and the VAX is merely serving
access to disk blocks (not files). The VAX can address the full capacity
of the disk. Doing a BACKUP/IMAGE your target disk will be mounted
/FOREIGN on the AXP side. No problem there. When you want to
access the contents of one of these target disks, once again you
merely let the VAX serve up access to disk blocks and on the AXP
side, you DON'T do a MOUNT/CLUSTER, but instead merely do a
MOUNT and you'll be able to see the file system naturally on the
AXP side.

- Mark

[Zane Healy]

Post by Mark Pizzolato
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.”

Post by Mark Pizzolato
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.

Post by Mark Pizzolato
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.

Post by Mark Pizzolato

Post by Zane Healy
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".

Post by Mark Pizzolato
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

[Mark Pizzolato]

Post by Zane Healy

Post by Mark Pizzolato
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
"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 2000000000 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 ">>>"

Post by Zane Healy

Post by Mark Pizzolato
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.

Post by Mark Pizzolato
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.

Post by Mark Pizzolato

Post by Zane Healy
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".

Post by Mark Pizzolato
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

[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

Post by Zane Healy

Post by Mark Pizzolato
TQ limited to 2000GB means a limit of 2TB. Do you have disks on the AXP system
that big?

"User-specified capacity must be between 50 and 2000 MB. The TQK50 does not support the BOOT
command.”

Post by Mark Pizzolato
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.

Post by Mark Pizzolato
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.

Post by Mark Pizzolato

Post by Zane Healy
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".

Post by Mark Pizzolato
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
http://mailman.trailing-edge.com/mailman/listinfo/simh

[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

Post by 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

Post by Zane Healy

Post by Mark Pizzolato
TQ limited to 2000GB means a limit of 2TB. Do you have disks on the AXP system
that big?

"User-specified capacity must be between 50 and 2000 MB. The TQK50 does not support the BOOT
command.”

Post by Mark Pizzolato
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.

Post by Mark Pizzolato
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.

Post by Mark Pizzolato

Post by Zane Healy
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".

Post by Mark Pizzolato
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
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Larry Baker]

Zane

Date: Mon, 19 Feb 2018 21:55:00 -0800
Subject: Re: [Simh] VAX Tape Emulation?
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
***@usgs.gov

[Larry Baker]

Zane,

Date: Tue, 20 Feb 2018 19:58:31 -0800
Subject: Re: [Simh] VAX Tape Emulation?
Content-Type: text/plain; charset=utf-8

Post by Mark Pizzolato
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
***@usgs.gov

[Zane Healy]

Post by Larry Baker
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

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

[dave porter]

Does anyone know any documentation provides some information about MOP
header in SYS files?

As a one-time implementor of MOP under DECnet/OSI on VMS, there's no such
thing as far as I am aware.

The MOP server reads normal image files (i.e., as output by the linker or
whatever).
The choice of what image files to support is left to the system implementer
based
on what target systems he expects to load - e.g., if you want to load
systems that
are generally built on Ultrix, you'd better learn how to read Ultrix image
files, even
if you're VMS.

Wire formats are defined in the DNA spec for MOP, of course.

Any more background about what you're looking at?