#Copy Device?
15 messages in this thread
Does anyone out there in PDP11 land know right off hand if there is an
RSX-11M command that is equivalent to the RT11 "copy device" command? In
particular, I want to copy DL0: to DL1: while the system is running an
application…… of course as I think about the problem, I can't help but
wonder if there might be problems with open files on DL0: and will I have a
problem with the checkpoint file having something in it?
=> 73 <=, bill => KB7LX@K4IWW <=
Bill:
The only thing I can think of is either DSC/BRU, or writing a
little command file to look at the directories on the source drive, make
the dirs on the target drive, and then do a copy src:[*,*]*.*;*
dst:[*,*]*.*;*. This would not copy the checkpoint file, since that is in
[0,0] (which is not copied by pip in a wildcard directory specification).
Chris
Chris;
Thanks for the reply. I am afraid that I am probably just displaying my
ignorance of the RSX disk structure, but I would think that PIP would not
accomplish the task as the resulting disk must be bootable. However, the
DSC idea looks promising or maybe BRU. Unfortunately, I don't have a
system myself with RL01s or RL02s on it so I can't try it until my client
gets back to his plant. Also, this is part of a distributed processing
system (on and 11/34) so I am also concerned about the copy operation
possibly disrupting the system.
=> 73 <=, bill => KB7LX@K4IWW <=
Bill:
It would probably be easier to use DSC. Unfortunately, you would
have to take the system down for the copy operation (both disks have to be
unmounted). The problem with copying, is that RSX maintains a boot file and
STB entry for all of the files that start the OS (like MCR, DCL, MOUNT…)
If you just copy all of the files from DL0: to dl1: you still have to go to
directodl1:[1,54] (assign Dl1:=SY: and dl1:=lb:) and type VMR @sysvmr. Then
you have to boot the image (boot dl1:[1,54]rsx11m.sys) and type SAV /WB to
rewrite the boot block.
Chris Zach
Chris;
Thanks for the additional lessons. I did have a look at there command file
and DSC is indeed what they are using. If it is possible to do a backup of
DL0: to DL1: that could be restored then the purpose is accomplished.
Sitting here musing again though, I believe that the backup media must be
bootable…… or at least I don't think that you can do a restore
operation to the system device…yes?
=> 73 <=, bill => KB7LX@K4IWW <=
Bill:
If you use DSC, then the backup is bootable. The problem is you
have to a take down the system to do a backup with DSC.
Chris Zach
Chris;
Indeed, and that is the problem.
=> 73 <=, bill => KB7LX@K4IWW <=
I think there's a /IM(age) switch to PIP, or something like that, which
should do the job.
Of course your concerns about open files on DL0 are perfectly valid. There
is no guarantee that the target disk will be logically consistent if you do
it this way.
I don't think the checkpoint file should be an issue but it depends on what
you intend to do with the target disk. If you were to use it to reboot
your system from, I don't think it would matter if there's stuff in the
checkpoint file or not since the operating system probably
"logically-zeroes" the checkpoint file at boot time anyway (pretends
there's nothing there, even if there is something there). This is
speculation on my part, though.
-Bill
Bill;
I am virtually certain that you are right about the checkpoint file. The
system this is about is a distributed processing system (the 11/34 is the
host). There is extensive use made of the checkpoint file but the system
restarts following powerfail almost always without a hitch. I suspect that
there have probably been several thousand restarts with somewhere around
99% successful without operator intervention.
I am back to the books but don't see anything in PIP that would do the job
(not done searching though). Chris's suggestion to look at DSC might well
turn out the be just the ticket. As I told him, I can not test the ideas
myself as I am running the system on an 11/73 w/RD53 and TK50 (no DLs).
Thanks again for the reply. Will let you know what I find out (if
anything, since they can continue to use only 9 track B/U, if this does not
work out).
=> 73 <=, bill => KB7LX@K4IWW <=
There *is* a way to backup disk-to-disk that is known to work, but it does
not produce an image, bootable, target disk. You can use the /IMAGE:SAVE
and /SAVE:savesetname switches on the BACKUP command, and it will produce a
saveset on the target disk, rather akin to what VMS does. But if you were
to do a DIR on the target disk after doing that, all you'd see is one big
file in [0,0] called BACKUP.SYS (plus the other Files-11 "overhead" files)
— no directory structure — so this does not help you if you need
something from which you can instantaneously boot. It might be superior to
magtape, though, since you have the second disk drive. (This is the
technique used by MicroPDPs to backup to floppy, by the way.)
To try the PIP /IM switch (if it exists) or any of the approaches Chris
suggested, you don't need a system with DLs as much as a system with two
disk drives. For that matter you could test it on a system with an RX50,
just going floppy-to-floppy. If the target floppy ends up looking just
like the original (as shown by a DIR [*] for instance), then you're 99%
assured that the technique works… the only remaining question would be
its bootability, and that *should* work too.
You might also want to look in the RSX lib here to see if I didn't upload a
copy of a program called IMAGECOPY about 5 or 6 years ago (!). I wrote
this to do high-efficiency floppy-to-floppy copying on a MicroRSX system.
It's in DECUS C and could easily be altered to do DL-to-DL. But you still
have the problem of the output disk possibly being "logically inconsistent"
due to work continuing on the source disk while the backup is in
progress… and that inconsistency can be in structure (e.g. VFY will not
be happy) as well as data.
-Bill
Bill;
Do I understand you correctly to say that what you are proposing will
create a backup of DL0: on DL1:? While this is not exactly what they want
to do, I suspect that it will serve their purposes even better than what I
was hoping could be accomplished. Again, if I am following correctly, all
they need is a bootable disk and the disk containing the latest saved image
inorder to restore the system if a crash should occur.
Again, there really isn't any way for me to test this….. my system does
not have but one disk, is an 11/73 and is running RSX 4.2. Theirs' is an
11/34 running RSX 3.2 with two DLs. And before asking, no they can't
upgrade as our experiance is that the RSX upgrades are not sufficiently
compatable with the older versions to work. Now, they could buy the newer
machine with new software but then anyone holding on to an 11/34 is not
likely a prospect for a new 11……
Thanks again, and sorry about the delay in getting back to you.
=> 73 <=, bill => KB7LX@K4IWW <=
Bill,
No, what I'm describing is unlikely to work on RSX 3.2. Lord, that's a
decade old now!
I'm not sure what you mean when you say that your "experience is that the
RSX upgrades are not sufficiently compatible with the older versions to
work"… we have never had any problems in this regard, other than those
which we "expected" as a result of reading the release notes with regard to
new functionality.
When I say "unlikely", though, that's what I mean, not "impossible". I
have no access to a system that old, and no way to know if the /IM switch
to PIP exists on that version. I'm quite certain that BACKUP/IMAGE:SAVE
etc. doesn't work though because that is a capability that was only added
to RSX about the time the MicroPDP-11s were introduced, and the need to do
backups to (possibly multiple) floppies appeared… WELL after the demise
of 3.2.
Actually I think anyone running an 11/34 is an EXCELLENT prospect for a new
11; obviously they are satisfied with what it does, and the $$$ they're
spending for maintenance and power alone would pay for it in short order.
-Bill
Bill;
The software is a proprietary data acquisition system with some site
specific design features. The problem with upgrades is that the system is
tested extensively prior to installation (at great costs) and generally no
one is willing to pay the expense of retesting just to install a new O.S.
on a system that works (not to mention the possibility of an undetected
problem creeping in).
The first system ran on an 11/34, the next on an 11/44 and the latest on an
11/73. Unfortunately, the company has now released a version running on an
IBM Gearbox. Of course my opinion does not count for much but the gearbox
is pitiful. The single 11/73 version will support 93 of our monitors. The
gearbox should support 12 as it stands now and the programmers think that
they will be able to get that up to 24!
On of the things that we are facing is that DEC does not act like it will
continue to support the PDP11. Of course those of us that remember the
PDP8 also remember that for about 15 years DEC looked as though it would
not support the machine. All that aside however, DEC really does push
pretty hard to get 11 users to go to the VAX. Unfortunately, this seems to
be one of those applications where the VAX is just not suited.
I have little doubt that the PC will win, it is just that I contemplate
that occurance with a great deal of sadness.
=> 73 <=, bill => KB7LX@K4IWW <=
Yes, I understand about DEC pushing people towards VAX, and certain
applications where it isn't suited.
(Actually I believe the VAX *hardware* is suited perfectly fine… it's
just the available operating systems — VMS and ELN alike — which leave
something to be desired, but not enough to be desired to spawn a viable
third-party O/S, it seems.)
As for DEC not supporting the 11… I think that is considerably less
clear, now, since they just introduced PDP-11 C within the past year, and
just introduced the 11/93 and 11/94 last month.
-Bill
Bill;
I have not seen anything on the new machines but must admit, that the
knowledge of their introduction seemed inconsistant with with what has been
going on for the last couple of years.
=> 73 <=, bill => KB7LX@K4IWW <=