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
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? ;)
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2013-07-12 00:51, Bob Armstrong wrote:
I have an RL02 pack and a RSX system and I want to 1) copy a sector
by sector image of the RL02 to a 20480 block file and then b) mount a
new pack, BAD it, and then copy the same image back to the new pack. On
VMS I d just use COPY /DEVICE or maybe BACKUP /PHYSICAL, but I m having
a tough time figuring out the RSX equivalent.
I thought PIP would do it, ( PIP FOO.IMG=DL0: ) but that fails if the
disk isn t mounted or if it s mounted as /FOREIGN. I don t think BRU
or DSC understand non-ODS volumes, and I don t know any other utilities
that copy files.
FWIW, the pack is from an ancient Unix and is not in Files11, RT11,
or any other format that RSX knows about.
Otherwise my only choice will be to fire up the 730 so I can get an
RL02 attached to a real operating system J
Eh... BAD is a BAD idea in this case. The problem with RL packs is that bad blocks are not hidden, but very visible. And the list of bad blocks are actually written on a disk block. The device driver does not do anything will the bad block information. Instead it is the file system initialization code which reads in the bad block list from the pack, and they allocate all the bad blocks on the pack to the [0,0]BADBLK.SYS file, so that they are not used by any other file.
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.
So if copy pack A to pack B, and you have bad blocks on pack A, they will also be marked as bad blocks on pack B, while if you have bad blocks on pack B, they will be forgotten.
All that said, if you are running the latest version of RSX, the easiest way of copying is to use VCP.
All that said, I think that BRU can also do the work, although I have not played with that.
But check the /IMAGE switch to BRU...
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
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
From: "Bob Armstrong" <bob at jfcl.com>
I thought the DL driver did the bad block revectoring.
Only on RT. So reading an alien DL: or DM: pack (with random stuff at the
end of block 1) on RT is a great way to scramble it.
John Wilson
D Bit
Perhaps simplest would be to boot a RSTS system on that machine, and write the 4 line Basic-PLUS program that will do the moral equivalent of "dd" to do the image copy.
(That won't cope with bad blocks, though. In fact, if you have bad blocks in different spots on source vs. destination, you need a file structured copy.)
paul
On Jul 11, 2013, at 6:51 PM, Bob Armstrong wrote:
I have an RL02 pack and a RSX system and I want to 1) copy a sector by sector image of the RL02 to a 20480 block file and then b) mount a new pack, BAD it, and then copy the same image back to the new pack. On VMS I d just use COPY /DEVICE or maybe BACKUP /PHYSICAL, but I m having a tough time figuring out the RSX equivalent.
I thought PIP would do it, ( PIP FOO.IMG=DL0: ) but that fails if the disk isn t mounted or if it s mounted as /FOREIGN. I don t think BRU or DSC understand non-ODS volumes, and I don t know any other utilities that copy files.
FWIW, the pack is from an ancient Unix and is not in Files11, RT11, or any other format that RSX knows about.
Otherwise my only choice will be to fire up the 730 so I can get an RL02 attached to a real operating system :)
Thanks,
Bob
I have an RL02 pack and a RSX system and I want to 1) copy a sector by sector image of the RL02 to a 20480 block file and then b) mount a new pack, BAD it, and then copy the same image back to the new pack. On VMS I d just use COPY /DEVICE or maybe BACKUP /PHYSICAL, but I m having a tough time figuring out the RSX equivalent.
I thought PIP would do it, ( PIP FOO.IMG=DL0: ) but that fails if the disk isn t mounted or if it s mounted as /FOREIGN. I don t think BRU or DSC understand non-ODS volumes, and I don t know any other utilities that copy files.
FWIW, the pack is from an ancient Unix and is not in Files11, RT11, or any other format that RSX knows about.
Otherwise my only choice will be to fire up the 730 so I can get an RL02 attached to a real operating system J
Thanks,
Bob