On 2013-07-12 21:35, Bob Armstrong wrote:
VCP will do the trick for you, but for that you need the latest version of
RSX.
If you have that, the command is just VCP COPY
Finally luck is on my side - I have VCP. Never used it before, but after
perusing the help it looks like I need to do something like
VCP CONNECT xyx/CR:RL02
VCP COPY/DEVICE DL0: VF0:
<swap packs now>
VCP COPY/DEVICE VF0: DL0:
VCP DISCONNECT VF0
My fingers crossed.....
Should work. You might possibly want to mount the devices foreign, but otherwise you should be good.
I've never had to use the /DEVICE switch. It works correctly by default.
You might like using the /STATUS switch, to see the progress.
I think I'll go crank up the 730 to copy the RL02...
:-)
Sadly the 730 doesn't boot. I was afraid it wouldn't - the RA81 is being
cranky. "Servo fine positioning error" (which probably means "the HDA is
trash"!) Those things are not particularly reliable, but there aren't many
alternatives for disk drives.
Check that the transport lock isn't engaged.
Johnny
VCP will do the trick for you, but for that you need the latest version of
RSX.
If you have that, the command is just VCP COPY
Finally luck is on my side - I have VCP. Never used it before, but after
perusing the help it looks like I need to do something like
VCP CONNECT xyx/CR:RL02
VCP COPY/DEVICE DL0: VF0:
<swap packs now>
VCP COPY/DEVICE VF0: DL0:
VCP DISCONNECT VF0
My fingers crossed.....
I think I'll go crank up the 730 to copy the RL02...
:-)
Sadly the 730 doesn't boot. I was afraid it wouldn't - the RA81 is being
cranky. "Servo fine positioning error" (which probably means "the HDA is
trash"!) Those things are not particularly reliable, but there aren't many
alternatives for disk drives.
Bob
Will do.
-brian
On Fri, Jul 12, 2013 at 06:26:36AM -0000, Cory Smelosky wrote:
Can't remember your email off-hand, Brian.
I need some modifications made, please.
Change the source int for the tunnels to Dialer0 and set the hostname you
use to dev.gimme-sympathy.org. I intend to switch to a static plan soon.
( My edge is currently a 3745 and I haven't quite figured out NAT and port
access so it may not be allowing SNMP in. ;) )
Thanks!
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2013-07-12 16:46, Bob Armstrong wrote:
Sounds like I'd better use an error free pack for the output, then.
Fortunately error free RL02s aren't that unusual, even today.
If you can get that, then you're good.
Johnny Billquist (bqt at softjar.se) wrote:
Eh... BAD is a BAD idea in this case.
I disagree - how else will you know if it's error free?
Well, BAD will do the checking, and with the right switches will tell you what bad blocks it finds, so from that point of view, sure. But do not expect the copy operation to care about what BAD found out. But if you just want a verification that the pack is error free, then sure, it will do that trick for you.
But check the /IMAGE switch to BRU...
Umm...
> HELP BRU /IMAGE
BRU>/IMAGE:SAVE source target
:RESTORE
/IMAGE specifies that you want to do a multivolume disk-to-disk
backup or restore operation.
.....
Doesn't sound like what I want. [It's odd - VMS BACKUP has a /IMAGE
option, but it does something entirely different.]
Ok. Checked BRU and /IMAGE is not useful here.
VCP will do the trick for you, but for that you need the latest version of RSX. If you have that, the command is just VCP COPY
All that said, it's about 10 lines of MACRO-11, if you want to keep it very simple.
I think I'll go crank up the 730 to copy the RL02...
:-)
Johnny
Sounds like I'd better use an error free pack for the output, then.
Fortunately error free RL02s aren't that unusual, even today.
Johnny Billquist (bqt at softjar.se) wrote:
Eh... BAD is a BAD idea in this case.
I disagree - how else will you know if it's error free?
But check the /IMAGE switch to BRU...
Umm...
> HELP BRU /IMAGE
BRU>/IMAGE:SAVE source target
:RESTORE
/IMAGE specifies that you want to do a multivolume disk-to-disk
backup or restore operation.
.....
Doesn't sound like what I want. [It's odd - VMS BACKUP has a /IMAGE
option, but it does something entirely different.]
I think I'll go crank up the 730 to copy the RL02...
Thanks,
Bob
Below
On Thu, Jul 11, 2013 at 6:51 PM, Bob Armstrong <bob at jfcl.com> wrote:
FWIW, the pack is from an ancient Unix and is not in Files11, RT11, or any other format that RSX knows about.
Given it's from an ancient UNIX system, why not let UNIX do the work? What model PDP-11 is it and I assume is has an ethernet if it's on the DECnet?
I'd just fire up a minimal *BSD for the PDP11 [which has ethernet drivers] and then do something in the scheme of:
dd if=/dev/[raw RL device] ibs=20480 obs=1b | [rs]sh some_remote_host dd ibs=1b obs=20480 of=diskimage
Once you have it in a file, you can mount diskimage in simh on get the data you want using whatever OS or system you like.
Note you might want set the ibs=1b and add conv=sync,noerror to minimize effects of bad blocks, since you are more interested in saving data then speed. You'll want to log/save away the console log so you know where the bad blocks are, since they will show up in the results as blocks of zeros.
Clem
We used the trick a couple of years ago, al biet was saving a bootable (DOS11) tape of an ancient UNIX file system. Worked like a charm. Warren Toomey now has the resulting bits on his PDP heritage site.
On 2013-07-12 13:36, John Wilson wrote:
From: Johnny Billquist <bqt at softjar.se>
But if RT-11 uses this device driver even when reading the disk without
trying to handle it as an RT-11 file system, then the RT-11 device
driver can't be used at all if you want to read foreign packs.
There's a .SPFUN to bypass RT's private bad-block replacement (yes the list
is in block 1), so you can easily write a small program to do the copy, but
I'm 99% sure COPY/DEVICE will just use .READ so, bad news.
Writing a stand-alone program to copy RLs would be straightforward, if you
wanted to be done once and for all.
Yes, you could easily do a trivial copy program standalone.
However, we still have the problem with any actual bad block mismatches between the two packs.
There is no real good solution here. Find error free packs is all I can say.
As for the original question, under RSX, there are several ways, as have already been mentioned.
Johnny
On Fri, Jul 12, 2013 at 2:26 AM, Cory Smelosky <b4 at gewt.net> wrote:
Can't remember your email off-hand, Brian.
I need some modifications made, please.
Change the source int for the tunnels to Dialer0 and set the hostname you
use to dev.gimme-sympathy.org. I intend to switch to a static plan soon.
( My edge is currently a 3745 and I haven't quite figured out NAT and port
access so it may not be allowing SNMP in. ;) )
Thanks!
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Hello!
How the <BLEEP!> did you manage to get a big IBM thing into your place
that only plays with IBM mainframes? (And then decidedly persnickety
as well.)
----
Incidentally the Yeti that were abusing the systems at Dave's are at
your place. More arrived where he is, including the twenty four on a
road trip.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
From: Johnny Billquist <bqt at softjar.se>
But if RT-11 uses this device driver even when reading the disk without
trying to handle it as an RT-11 file system, then the RT-11 device
driver can't be used at all if you want to read foreign packs.
There's a .SPFUN to bypass RT's private bad-block replacement (yes the list
is in block 1), so you can easily write a small program to do the copy, but
I'm 99% sure COPY/DEVICE will just use .READ so, bad news.
Writing a stand-alone program to copy RLs would be straightforward, if you
wanted to be done once and for all.
John Wilson
D Bit
On 2013-07-12 11:38, Cory Smelosky wrote:
On Fri, 12 Jul 2013, Johnny Billquist wrote:
BAD in turn only updates the bad block list on the pack, and do nothing
else. This is why these packs reserve the last track. That is where the
bad block list is expected to reside, along with pack serial number.
What if the last track ends up composed entirely of bad blocks? ;)
Then that pack is screwed. The bad block list is a little complex, but you need a couple of ok blocks on the last track, or it really is a broken pack.
To be more specific about the last track, the blocks are divided into manufacturer bad block lists, and user bad block lists. I seem to remember that it alternates between the two, so block 0,2,4,... are manufacturer bad block list copies, and 1,3,5,... are replicas of the user bad block list.
And the manufacturer bad block list also have some pack metadata stored, such as the pack serial number.
If the first block with the list can't be read, you are expected to try one of the alternates.
However, all that said (I'm using that phrase much right now), lots of software abuse and fail on this. Many do not at all even look at the user bad block list, and some even just ignore the manufacturer bad block list. There is no physical protection from anyone just overwriting all those blocks anyway, and I think Unix make use of all the tracks, for example.
John mentioned that the device driver in RT-11 handles the bad block remapping in the driver itself. OS/8 do that too. However, they create their own bad block list adapted for the device driver, placed somewhere else (like in block 1 for RT-11 if I understood John right). That list should hopefully be based on what is stored in the last track, but this is also something done at filesystem initialization.
But if RT-11 uses this device driver even when reading the disk without trying to handle it as an RT-11 file system, then the RT-11 device driver can't be used at all if you want to read foreign packs.
Like I said, the RSX driver do not do anything at all. If just gives you all blocks. Good or bad.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
