Hi Mark,
According to
http://man.he.net/man1/unzip
the "--D" option can be used under VMS to restore directory timestamps.
Would this zip/unzip route do what you want?
The unzip on my system is too old, otherwise I would have tried it...
Erik
On Wed, May 22, 2013 at 01:54:08PM +0100, Mark Wickens wrote:
Yes, I thought about LD as a solution, but presumably I'd then have the issue of tens of devices mounted, how would I present that in a hierarchical structure suitable for browsing via either decline or wasd web server?
Thanks for the suggestions.
Mark
http://www.wickensonline.co.ukhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
On 22 May 2013, at 13:31, G. <gerry77 at mail.com> wrote:
On Wed, 22 May 2013 12:12:36, h vlems wrote:
LD is your friend..
Yeah! I really didn't think about it. Maybe that's the best solution. It all
depends on what the OP means by "archiving". If he wants files readily
accessible anywhere by anyone (e.g. via browser), the LD solution would be
very nice, otherwise /IMAGE would be the best, I think. Mine was a trick...
G. :)
Mount/bind?
Van: Mark Wickens
Verzonden: woensdag 22 mei 2013 14:54 PM
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] OpenVMS Backup
Yes, I thought about LD as a solution, but presumably I'd then have the issue of tens of devices mounted, how would I present that in a hierarchical structure suitable for browsing via either decline or wasd web server?
Thanks for the suggestions.
Mark
http://www.wickensonline.co.ukhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
On 22 May 2013, at 13:31, G. <gerry77 at mail.com> wrote:
> On Wed, 22 May 2013 12:12:36, h vlems wrote:
>
>> LD is your friend..
>
> Yeah! I really didn't think about it. Maybe that's the best solution. It all
> depends on what the OP means by "archiving". If he wants files readily
> accessible anywhere by anyone (e.g. via browser), the LD solution would be
> very nice, otherwise /IMAGE would be the best, I think. Mine was a trick...
>
> G. :)
An ld device is a nice target for an image backup. I prefer a dd on Tru64 and move the output file to a vms system where it can be mounted as an lda device. no bytes wasted...
Van: G.
Verzonden: woensdag 22 mei 2013 14:31 PM
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] OpenVMS Backup
On Wed, 22 May 2013 12:12:36, h vlems wrote:
> LD is your friend..
Yeah! I really didn't think about it. Maybe that's the best solution. It all
depends on what the OP means by "archiving". If he wants files readily
accessible anywhere by anyone (e.g. via browser), the LD solution would be
very nice, otherwise /IMAGE would be the best, I think. Mine was a trick...
G. :)
Yes, I thought about LD as a solution, but presumably I'd then have the issue of tens of devices mounted, how would I present that in a hierarchical structure suitable for browsing via either decline or wasd web server?
Thanks for the suggestions.
Mark
http://www.wickensonline.co.ukhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
On 22 May 2013, at 13:31, G. <gerry77 at mail.com> wrote:
On Wed, 22 May 2013 12:12:36, h vlems wrote:
LD is your friend..
Yeah! I really didn't think about it. Maybe that's the best solution. It all
depends on what the OP means by "archiving". If he wants files readily
accessible anywhere by anyone (e.g. via browser), the LD solution would be
very nice, otherwise /IMAGE would be the best, I think. Mine was a trick...
G. :)
On Wed, 22 May 2013 12:12:36, h vlems wrote:
LD is your friend..
Yeah! I really didn't think about it. Maybe that's the best solution. It all
depends on what the OP means by "archiving". If he wants files readily
accessible anywhere by anyone (e.g. via browser), the LD solution would be
very nice, otherwise /IMAGE would be the best, I think. Mine was a trick...
G. :)
LD is your friend..
Van: G.
Verzonden: woensdag 22 mei 2013 13:28 PM
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] OpenVMS Backup
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.
Or stay with VMS, create a logical disk of 600 MB and backup/ image
Van: Mark Wickens
Verzonden: woensdag 22 mei 2013 11:07 PM
Aan: hecnet at update.uu.se
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] OpenVMS Backup
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.
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.
