6 Mar
2016
6 Mar
'16
1:26 p.m.
This thread is a parallel discussion to a VCF thread that I started last night:
http://www.vcfed.org/forum/showthread.php?51653-Dumping-Images-of-my-VAX-11…
With today being cold and rainy, it seems like a good excuse to turn on my VAX-11/730. I
can boot either VMS 5.2 off the RL02 or OpenVMS 7.3 off the R80, if I recall the version
numbers correctly. Several months have passed since the last time I worked on the machine.
In my last session I began trying to bring up TCP/IP networking, without success.
I want to get raw images of the system's drives off the machine and onto my modern
systems. I can think of several approaches, and still more approaches have already been
suggested in that VCF thread. I have a number of questions, and I'm also keeping my
eyes open for hardware that might help me out. I'm not presently talking to eBay, so
that limits my options.
First of all, if I manage to get TCP/IP networking up and running today, is there some way
under VMS for me to dump raw disk blocks over the network to one of my UNIX-like systems?
Alternately, if I manage to cobble together a Linux box running an older DECNET-aware
distribution and bring up DECNET on the VAX, would that give me a way to dump raw disk
blocks to a file on it across the network? I'm still quite clumsy under VMS. One of
these network-based approaches seem like the only options that I would have any chance of
achieving today, assuming that the networking hardware on my 11/730 is even in working
order.
I don't think I have the patience to dump an R80 drive across an async serial port,
but if I did have the patience, is there some way to accomplish this under a stock VMS
5.2/7.3 installation? Ditto for the RL02 and 9-track tapes.
I have a couple of broken Kennedy 9610 9-track drives in my pile. One has a SCSI
interface, so I might be able to interface it to one of my newer machines that have both
SCSI and a way to talk to my modern machines, such as my Sun Ultra 60 or my Amiga 3000.
Both drives have hub motor drive problems that need to be diagnosed and repaired, though.
This might end up being part of my best data path from the VAX to modern machines, but
it'll take some time and work.
I can think of a few possible approaches if somebody here has suitable hardware for sale
or trade:
* With an MSCP-emulating UNIBUS SCSI card, I might be able to hang a SCSI2SD off my VAX.
These seem to be expensive and hard to find, though. I see a UC17 on eBay for $949 OBO.
That's a lot more than I'm presently willing to spend, and I'm not on speaking
terms with eBay/PayPal right now anyway. I do hope to find a suitable UNIBUS SCSI adapter
at a good price, both for possible use in the VAX and for eventual use in my long-term
PDP-11/44 project.
* With an M8061 RLV12 card, I might be able to borrow the VAX's RL02 and dump packs on
my little PDP-11 half-rack. I already have a QBUS SCSI card for it that I procured a while
back. I also have four more RL02 drives out in the pile in the barn for eventual use, but
I'd initially borrow the known-working RL02 drive from the VAX, which also happens to
be in the same room as my little PDP-11. I don't think I already have an RLV12, but
I'll dig through my QBUS cards again today to see if I have one I've forgotten
about.
* With some sort of Pertec tape adapter for one of my newer computers, I might be able to
borrow the TU80 drive from my VAX (I think it has a Pertec interface; not positive yet)
and use it to read/write tapes. It could also eventually get used with one of the Kennedy
drives, but the TU80 already works. I might be able to use a PCI card in the Sun Ultra 60
if Solaris 8 can talk to it. Or an MCA card in a PS/2 65 that I recently acquired, running
OS/2 Warp Connect 4, also assuming I can get suitable software. Or a SCSI to Pertec
interface connected to the Ultra 60 or my Amiga 3000. Or even an ISA card in my crusty 386
clone running DOS 6.22. It would be ultimately nice to connect a 9-track to one of my
modern Macs, but I don't expect that to be easy.
* It was suggested that I might be able to cluster the 11/730 with a MicroVAX, and then
transfer data onto some SCSI device on the MicroVAX such as a SCSI2SD. I think I'd
need to find a fairly turnkey MicroVAX, though, to avoid a bring-up problem that's
even bigger than the data transfer problem I'm trying to solve.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
8 Mar
8 Mar
6:21 p.m.
I want to get raw images of the system's drives off the machine and onto my
modern systems. I can think of several approaches, and still more approaches
have already been suggested in that VCF thread. I have a number of questions,
and I'm also keeping my eyes open for hardware that might help me out. I'm not
presently talking to eBay, so that limits my options.
First of all, if I manage to get TCP/IP networking up and running today, is
there some way under VMS for me to dump raw disk blocks over the network to
one of my UNIX-like systems? Alternately, if I manage to cobble together a
Linux box running an older DECNET-aware distribution and bring up DECNET on
the VAX, would that give me a way to dump raw disk blocks to a file on it
across the network? I'm still quite clumsy under VMS. One of these
network-based approaches seem like the only options that I would have any
chance of achieving today, assuming that the networking hardware on my 11/730
is even in working order.
Savesets produced using VMS BACKUP are the ideal way to archive your VMS system.
They will save everything you need in a format which can be restored onto any
disk big enough to hold the data, selectively if necessary, while dealing with
any errors on the input or output media. BACKUP can be run standalone or under
VMS.
If you get TCP/IP networking like Multinet (ie not like CMUIP) running, you
should be able to use FTP, rcp or maybe even TFTP to move a VMS BACKUP saveset
to another system. The snag is you need enough scratch space to create the
saveset on the 11/730 before you transfer it.
I don't think I have the patience to dump an R80 drive across an async serial
port, but if I did have the patience, is there some way to accomplish this
under a stock VMS 5.2/7.3 installation? Ditto for the RL02 and 9-track tapes.
C-Kermit for VMS might be able to do this - I can't recall.
If you mount /foreign your non-system disk, it should be accessible at a logical
block level instead of at a file level. VMS BACKUP won't like this but COPY
should just copy logical blocks from the foreign mounted device. This probably
isn't very useful to you but rcp or FTP PUT might also similarly cope with a
foreign mounted devices and this may be another way of generating a raw dump
of the device, provided there are no errors on it. (There may be issues
detecting the size of the device and the operation may end with an error when
no more blocks can be read. If whatever software you use doesn't try to
discard it's output on encountering an error, all should be well.) However,
you can't mount your system disk /foreign.
Another way would be to write some code (VAX MACRO assembly / C / FORTRAN /
BASIC or whatever compiler you have to use VMS system services like SYS$ASSIGN
and SYS$QIO to read logical blocks from the disks and do something sensible
when errors are encountered. This might involve a steep learning curve and the
results will probably not be as well optimised to the task as VMS BACKUP. It
should be possible to find some sample code to do something like this.
* It was suggested that I might be able to cluster the 11/730 with a MicroVAX,
and then transfer data onto some SCSI device on the MicroVAX such as a
SCSI2SD. I think I'd need to find a fairly turnkey MicroVAX, though, to
avoid a bring-up problem that's even bigger than the data transfer problem
I'm trying to solve.
Clustering is pretty simple when you know how but if you don't want to get into
configuring a cluster, a DECnet connected system or emulated system would
probably be the way to go. Configuring DECnet on VMS can be done very easily
with surprisingly little understanding of what is going on and is less invasive
than configuring a cluster.
On VMS, any file, including a BACKUP saveset can be specified as being located
on a remote DECnet node, so it is possible to run BACKUP on your 11/730 and have
the output saveset situated on a different VAX / Alpha / Itanium / emulated
system running VMS or on a unix or other system capable of running DECnet well,
(ultrix?), even a PC/Macintosh running DOS/Windows/Macos and DEC Pathworks.
If your 11/730 is already configured to be a cluster member (if it says
something like "Waiting to form or join a VAXcluster" on the console at boot
time and then pauses for while before continuing) then you probably don't have
to do anything further to it to make it function as part of a cluster. The
only experimentation required would be on the additional cluster member, which
could be an emulated system using simh for example if you don't have any other
suitable hardware available. Once you are clustered, you can access disks on
a remote cluster node as if they were local. Clustering with an emulated
system would be especially suitable for producing raw block copies of the
disks on the 11/730 on the filesystem of the system hosting the emulation.
Regards,
Peter Coghlan.
9 Mar
9 Mar
2:02 a.m.
On Mar 8, 2016, at 15:21, Peter Coghlan <cctalk at
beyondthepale.ie> wrote:
If you get TCP/IP networking like Multinet (ie not like CMUIP) running, you
should be able to use FTP, rcp or maybe even TFTP to move a VMS BACKUP saveset
to another system. The snag is you need enough scratch space to create the
saveset on the 11/730 before you transfer it.
Well, there's the problem: I don't have scratch space, since all of the hard
drives are precisely what I want to image.
C-Kermit for VMS might be able to do this - I
can't recall.
Getting it onto the machine in the first place might be a challenge!
If you mount /foreign your non-system disk, it should be accessible at a logical
block level instead of at a file level. VMS BACKUP won't like this but COPY
should just copy logical blocks from the foreign mounted device. This probably
isn't very useful to you but rcp or FTP PUT might also similarly cope with a
foreign mounted devices and this may be another way of generating a raw dump
of the device, provided there are no errors on it. (There may be issues
detecting the size of the device and the operation may end with an error when
no more blocks can be read. If whatever software you use doesn't try to
discard it's output on encountering an error, all should be well.) However,
you can't mount your system disk /foreign.
I can boot either 7.3 from the R80 fixed drive, or 5.2 from an RL02 pack. So in theory, I
should be able to boot from each of them to image the other. There might be TCP/IP support
on the 7.3 installation, but I doubt there's any TCP/IP support on the 5.2. I hope
that the DECNET support is there on both installations for the ethernet card.
I set up a VM on my Mac running Ubuntu with DECNET support installed. Despite being
orphaned several years ago, it still seems to run. So I think that trying to bring up
DECNET on the VAX might give me options. I was thinking that if nothing else, if I can log
into the VAX remotely via DECNET and log the terminal output, then maybe I could just DUMP
a foreign-mounted volume and then write some throw-away program to transmogrify the hex
dump into a block-level image. It would be slow, but I hope it would at least be quite a
bit faster than dumping over an async serial port.
If I can write a file from the VAX to that Ubuntu VM via DECNET, then maybe I can just
COPY a foreign-mounted volume to a file on the VM. I don't know what capabilities the
Linux DECNET support gives me yet, but if I can do this then that should be a good option.
I wonder if I can image tapes that way, too?
Another way would be to write some code (VAX MACRO assembly / C / FORTRAN /
BASIC or whatever compiler you have to use VMS system services like SYS$ASSIGN
and SYS$QIO to read logical blocks from the disks and do something sensible
when errors are encountered. This might involve a steep learning curve and the
results will probably not be as well optimised to the task as VMS BACKUP. It
should be possible to find some sample code to do something like this.
I hope I don't have to go to that much effort, particularly since I don't know if
there are any language compilers/assemblers on the system, and I want to image the drives
before I monkey around with the system much.
Clustering is pretty simple when you know how but if
you don't want to get into
configuring a cluster, a DECnet connected system or emulated system would
probably be the way to go. Configuring DECnet on VMS can be done very easily
with surprisingly little understanding of what is going on and is less invasive
than configuring a cluster.
You had me at "surprisingly little understanding of what is going on"! This
sounds like the thing for me to try next.
On VMS, any file, including a BACKUP saveset can be
specified as being located
on a remote DECnet node, so it is possible to run BACKUP on your 11/730 and have
the output saveset situated on a different VAX / Alpha / Itanium / emulated
system running VMS or on a unix or other system capable of running DECnet well,
(ultrix?), even a PC/Macintosh running DOS/Windows/Macos and DEC Pathworks.
That sounds very promising!
If your 11/730 is already configured to be a cluster
member (if it says
something like "Waiting to form or join a VAXcluster" on the console at boot
time and then pauses for while before continuing) then you probably don't have
to do anything further to it to make it function as part of a cluster. The
only experimentation required would be on the additional cluster member, which
could be an emulated system using simh for example if you don't have any other
suitable hardware available. Once you are clustered, you can access disks on
a remote cluster node as if they were local. Clustering with an emulated
system would be especially suitable for producing raw block copies of the
disks on the 11/730 on the filesystem of the system hosting the emulation.
Hmm, I don't remember whether it output any messages like that, and I don't recall
where the console printouts are from my successful boots of the system. I'll look for
this next time I bring up the system.
Thanks for all of the suggestions! I still have a lot of learning curve to climb in the
VMS world.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
11 Mar
11 Mar
6:42 a.m.
If you get TCP/IP networking like Multinet (ie
not like CMUIP) running, you
should be able to use FTP, rcp or maybe even TFTP to move a VMS BACKUP save
set to another system. The snag is you need enough scratch space to create
the saveset on the 11/730 before you transfer it.
Well, there's the problem: I don't have scratch space, since all of the hard
drives are precisely what I want to image. C-Kermit for
VMS might be able to do this - I can't recall.
Getting it onto the machine in the first place might be a challenge!
I can boot either 7.3 from the R80 fixed drive, or 5.2 from an RL02 pack. So
in theory, I should be able to boot from each of them to image the other.
There might be TCP/IP support on the 7.3 installation, but I doubt there's
any TCP/IP support on the 5.2. I hope that the DECNET support is there on
both installations for the ethernet card.
I set up a VM on my Mac running Ubuntu with DECNET support installed.
Despite being orphaned several years ago, it still seems to run. So I think
that trying to bring up DECNET on the VAX might give me options. I was
thinking that if nothing else, if I can log into the VAX remotely via DECNET
and log the terminal output, then maybe I could just DUMP a foreign-mounted
volume and then write some throw-away program to transmogrify the hex dump
into a block-level image. It would be slow, but I hope it would at least be
quite a bit faster than dumping over an async serial port.
If I can write a file from the VAX to that Ubuntu VM via DECNET, then maybe I
can just COPY a foreign-mounted volume to a file on the VM. I don't know what
capabilities the Linux DECNET support gives me yet, but if I can do this then
that should be a good option. I wonder if I can image tapes that way, too?
COPY will give up if it encounters a bad block on the disk and it will also be
difficult to ensure the resulting image is a valid copy of the disk. BACKUP to
a saveset over DECnet will keep going despite errors and will also include
extra overhead to allow the integrity of the saveset to be verified in case it
gets damaged later. Using BACKUP will also allow restores of particular files
to be done if required rather than having to restore the whole disk even if
only a small number of files are damaged or inadvertently deleted.
Clustering is
pretty simple when you know how but if you don't want to get into
configuring a cluster, a DECnet connected system or emulated system would
probably be the way to go. Configuring DECnet on VMS can be done very easily
with surprisingly little understanding of what is going on and is less
invasive than configuring a cluster.
You had me at "surprisingly little understanding of what is going on"! This
sounds like the thing for me to try next.
On VMS, any
file, including a BACKUP saveset can be specified as being located
on a remote DECnet node, so it is possible to run BACKUP on your 11/730 and have
the output saveset situated on a different VAX / Alpha / Itanium / emulated
system running VMS or on a unix or other system capable of running DECnet well,
(ultrix?), even a PC/Macintosh running DOS/Windows/Macos and DEC Pathworks.
That sounds very promising!
Thanks for all of the suggestions! I still have a lot of learning curve to
climb in the VMS world.
Send me an email if you need more details on any of the above.
Regards,
Peter Coghlan.
14 Mar
14 Mar
3:47 a.m.
Well, I've had partial success in imaging the disks of my VAX-11/730. The RL02 packs
transferred just fine to a VM running an older Linux distribution with DECnet support, but
the R80 drive copy aborted with a parity error. Details and pictures are on my blog:
http://www.nf6x.net/2016/03/imaging-vax-11730-disks/
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
9 Mar
9 Mar
12:48 p.m.
On 08/03/16 23:21, Peter Coghlan wrote:
>
> Savesets produced using VMS BACKUP are the ideal way to archive your VMS system.
> They will save everything you need in a format which can be restored onto any
> disk big enough to hold the data, selectively if necessary, while dealing with
> any errors on the input or output media. BACKUP can be run standalone or under
> VMS.
Ideally you would use standalone backup. With most systems you would
backup to tape or to another disk.
Or you would boot into a cluster (i.e. boot off something other than
your system disk) and backup that
way.
I doubt that either of those is viable on a VAX-11/730. You can't easily
hook up a second disk and
I'm almost certain that a network boot is not possible. I don't think
that you could connect a VAX-11/730 to
a CI-cluster, and even if you could, you are not likely to have the kit
available.
If you have a tape drive, you could use standalone backup to backup to
tape and then shift that to another
system (or SIMH) and preserve the saveset that way.
I remember having the same issue as a system manager on a VAX-11/750.
There was no network boot, so the
only option was to use SABKP and a spare disk.
Antonio
3053
days inactive
3061
days old
5 comments
3 participants
participants (3)
-
a.carlini＠ntlworld.com -
cctalk＠beyondthepale.ie -
nf6x＠nf6x.net