If you have a unix system use the dd command
Van: Mark Wickens
Verzonden: woensdag 22 mei 2013 10:47 PM
Aan: HECnet Mailing List
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] VMS Backup
Guys,
I'm trying to find the 'best' way to archive the contents of the CDROMs,
and failing to find a solution.
Using COPY DKA400:[000000...]*.*;* DSA3:[MEDIA.VAX_MEDIA.path...]*.*;*
works but doesn't preseve the timestamps.
The obvious solution is to use BACKUP, but a command such as:
BACKUP/VERIFY DKA400:[000000...] DSA3:[MEDIA.VAX_MEDIA.path...]
which is what the help would have you believe does the right thing doesn't
work - you get a weird file structure where files in subdirectories are
created in the top of the destination and the directory structure is only
partially created.
Am I doing something obviously wrong here?
Cheers, Mark.
On Wed, 22 May 2013 13:14:19 +0300, Kari Uusim ki wrote:
BACKUP/IMAGE should bring everything as it is on the original medium.
Correct. But to do that, /IMAGE wants a whole device both in input and output.
And that's not the OP situation, if I'm not wrong...
G.
On Wed, 22 May 2013 10:07:36 +0100 (BST), Mark Wickens wrote:
*However* I still haven't solved the issue of timestamps. I'd like to
preserve the original file timestamps, but whether I use this version of
BACKUP or by saving to and then restoring from a SAVESET I still get
modification times of the current date.
Anyone know how to get round that issue?
I think that BACKUP updates the modification date by design and that's not
avoidable. However, after you've done your backup copy, you could always
change (almost) any date you want with SET FILE/ATTR=xxxDATE=... Just create
some DCL procedure that scans the input medium and sets the corresponding
output file date the same as the original. :)
HTH, :)
G.
On 22.5.2013 12:07, Mark Wickens wrote:
OK,
So obviously having asked the question I got further by examining the
BACKUP manual in greater detail.
It seems the command I need is:
BACKUP/VERIFY/LOG DKA400:[*...] DSA3:[MEDIA.VAX_MEDIA.VAXBINDEC95...]
The presence of the '*' in the input specifier causes the directory
structure to be preserved in the output directory.
*However* I still haven't solved the issue of timestamps. I'd like to
preserve the original file timestamps, but whether I use this version of
BACKUP or by saving to and then restoring from a SAVESET I still get
modification times of the current date.
Anyone know how to get round that issue?
Cheers, Mark.
.
BACKUP/IMAGE should bring everything as it is on the original medium.
Kari
OK,
So obviously having asked the question I got further by examining the BACKUP manual in greater detail.
It seems the command I need is:
BACKUP/VERIFY/LOG DKA400:[*...] DSA3:[MEDIA.VAX_MEDIA.VAXBINDEC95...]
The presence of the '*' in the input specifier causes the directory structure to be preserved in the output directory.
*However* I still haven't solved the issue of timestamps. I'd like to preserve the original file timestamps, but whether I use this version of BACKUP or by saving to and then restoring from a SAVESET I still get modification times of the current date.
Anyone know how to get round that issue?
Cheers, Mark.
Guys,
I'm trying to find the 'best' way to archive the contents of the CDROMs, and failing to find a solution.
Using COPY DKA400:[000000...]*.*;* DSA3:[MEDIA.VAX_MEDIA.path...]*.*;* works but doesn't preseve the timestamps.
The obvious solution is to use BACKUP, but a command such as:
BACKUP/VERIFY DKA400:[000000...] DSA3:[MEDIA.VAX_MEDIA.path...]
which is what the help would have you believe does the right thing doesn't work - you get a weird file structure where files in subdirectories are created in the top of the destination and the directory structure is only partially created.
Am I doing something obviously wrong here?
Cheers, Mark.
On 2013-05-20 23:34, Paul_Koning at Dell.com wrote:
On May 20, 2013, at 3:47 PM, G. wrote:
On Mon, 20 May 2013 21:10:18 +0200, Johnny Billquist wrote:
Using the various implementations in RSX, I can tell that it's not
RSTS/E-like, but TOPS-20.
Actually I do not really know which seems which: I based my assumptions on
something from Paul Koening I might have misread or misremembered... :P
Bit rotting is a big issue of mine :)
Thanks, but in this case the mistake is probably mine. I would have guessed that TOPS-10 used the RSTS flavor of RTERM. Johnny's experiment certainly says otherwise.
It does, but I would be careful about saying it's absolutely conclusive.
First of all, do RSTS/E have more than one remote terminal protocol implementation?
Second, the RRS application (which connects to RSTS/E systems) might be checking explicitly for RSTS/E, while it might otherwise have worked just fine against TOPS-10.
The TOPS-20 application did work just fine against TOPS-10. No denying that one. But I really do not know what the different programs do under the hood.
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 May 20, 2013, at 3:47 PM, G. wrote:
On Mon, 20 May 2013 21:10:18 +0200, Johnny Billquist wrote:
Using the various implementations in RSX, I can tell that it's not
RSTS/E-like, but TOPS-20.
Actually I do not really know which seems which: I based my assumptions on
something from Paul Koening I might have misread or misremembered... :P
Bit rotting is a big issue of mine :)
Thanks, but in this case the mistake is probably mine. I would have guessed that TOPS-10 used the RSTS flavor of RTERM. Johnny's experiment certainly says otherwise.
paul
On 2013-05-20 21:51, Johnny Billquist wrote:
On 2013-05-20 21:47, G. wrote:
On Mon, 20 May 2013 17:20:22 +0200, Johnny Billquist wrote:
Port the Linux one to VMS?
Probably not something I'd recomment... :-)
Why not? I'm not a C expert at all (I mean I know almost nothing). Do you
think it would be unfeasible or overly clumsy? I wonder if there is
something
useful in the freeware or DECUS tapes... But it may took ages to find
it. :|
Well, first of all, the API as well as some basic paradigms are rather
different in Linux than in VMS. Porting anything non-trivial from Unix
to VMS often is headaches.
Second, while I have not looked at xterm/rterm specifically, I have had
big issues with DECnet applications in Linux in the past. They seem to
work fairly ok against VMS systems, but almost all have failed miserably
when I have tried them against an RSX system.
cterm/rterm, not xterm. :-)
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
