OpenVMS, backup, NSF, & ZIP
rcyoung
"invisible" companion file on the NSF volume to store the OpenVMS file
characteristics, etc. Does anyone know if you "zip" the files on the
NFS mount point (using the OpenVMS version of ZIP), does it "include"
the ADF files or the info they contain, or are they "neglected"?? I
guess I am wondering if the OS handles incorporation the ADF info
automatically when the system service accesses an NSF volume, or not
Also, I have seen some "old" references to using NFS to mount a
network drive, and performing VMS backups to that external drive.
Anyone else know if this is a viable option, under 7.1 and later
through 8.x??? The old posts (7-8 yr old) thought there had been
issues "once upon a time", but it is unclear as to exactly when (if
ever) the issues disappeared, or are they still present??
Steven Schweda
> When OpenVMS places files on a remote NSF network drive, it creates an
> "invisible" companion file on the NSF volume to store the OpenVMS file
> characteristics, etc. Does anyone know if you "zip" the files on the
> NFS mount point (using the OpenVMS version of ZIP), does it "include"
> the ADF files or the info they contain, or are they "neglected"?? I
> guess I am wondering if the OS handles incorporation the ADF info
> automatically when the system service accesses an NSF volume, or not
Zip on VMS does file access the same as any other program
on VMS. If the NFS client software hides files from everyone,
then that includes Zip, too. But if the NFS client software
presents the data from these hidden files as if they were
normal file meta-data, then Zip on VMS should see those files
(or file-pairs) as normal VMS files, just as everyone else
does.
Currently, Zip on any non-VMS system would interpret those
companion files as separate files, with no connection to their
masters, and the non-VMS Zip would not imagine that these
companion files had any VMS-specific significance. And UnZip
on VMS currently can't put the pieces back together again.
But this could probably be implemented (if there were any
volunteers). I believe that it was done for AppleDouble
files.
> Also, I have seen some "old" references to using NFS to mount a
> network drive, and performing VMS backups to that external drive.
> Anyone else know if this is a viable option, under 7.1 and later
> through 8.x??? The old posts (7-8 yr old) thought there had been
> issues "once upon a time", but it is unclear as to exactly when (if
> ever) the issues disappeared, or are they still present??
As files go, I wouldn't expect a BACKUP save set to be
particularly exotic, so I wouldn't expect BACKUP to have any
particular trouble with an NFS-remote save set file. Which
"old posts", exactly?
rcyoung
> "old posts", exactly?
I'll have to go refind them later today/tomorrow. They were back about
7-8 yrs ago (around 2001-2003). I don't recall if they were on google
groups, or another VMS Usenet group.
Joseph Huber
Just to verify: on VMS 7.3-1, TCPIP 5.4 on a Unix NFS volume:
$ dir/full KASSE.DATA
Directory DISK$CRYODATA:[cryo.tmp]
KASSE.DATA;1 File ID: (774,24695,0)
Size: 20/20 Owner: [NED,CRYO]
Created: 13-DEC-2005 16:42:52.24
Revised: 19-MAR-2011 19:24:41.45 (11)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 19-MAR-2011 19:24:45.65
Attributes: 19-MAR-2011 19:24:41.45
Modified: 19-MAR-2011 19:24:31.53
Linkcount: 1
File organization: Indexed, Prolog: 3, Using 1 key
Shelved state: Online
Caching attribute: No_caching
File attributes: Allocation: 20, Extend: 0, Maximum bucket size: 2
Global buffer count: 0, No version limit
Record format: Fixed length 75 byte records
Record attributes: Fortran carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None
Total of 1 file, 20/20 blocks.
$ zip -mV tmp kasse.data
adding: KASSE.DATA (deflated 82%)
$ unzip tmp
Archive: DISK$CRYODATA:[cryo.tmp]tmp.zip;1
inflating: KASSE.DATA
$ dir/full KASSE.DATA
Directory DISK$CRYODATA:[cryo.tmp]
KASSE.DATA;1 File ID: (774,24696,0)
Size: 20/20 Owner: [NED,CRYO]
Created: 13-DEC-2005 16:42:52.24
Revised: 19-MAR-2011 19:25:40.85 (11)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 19-MAR-2011 19:25:40.57
Attributes: 19-MAR-2011 19:25:40.85
Modified: 19-MAR-2011 19:24:41.45
Linkcount: 1
File organization: Indexed, Prolog: 3, Using 1 key
Shelved state: Online
Caching attribute: No_caching
File attributes: Allocation: 20, Extend: 0, Maximum bucket size: 2
Global buffer count: 0, No version limit
Record format: Fixed length 75 byte records
Record attributes: Fortran carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None
Total of 1 file, 20/20 blocks.
$ sh dev DISK$CRYODATA:/full
Disk DNFS5:, device type Foreign disk type 7, is online, mounted, file-
oriented
device, shareable, accessed via DFS or NFS.
--
Joseph Huber - http://www.huber-joseph.de
JOUKJ
> On Mar 18, 9:38 pm, rcyoung <rcyo...@aliconsultants.com> wrote:
>
>> When OpenVMS places files on a remote NSF network drive, it creates an
>> "invisible" companion file on the NSF volume to store the OpenVMS file
>> characteristics, etc. Does anyone know if you "zip" the files on the
>> NFS mount point (using the OpenVMS version of ZIP), does it "include"
>> the ADF files or the info they contain, or are they "neglected"?? I
>> guess I am wondering if the OS handles incorporation the ADF info
>> automatically when the system service accesses an NSF volume, or not
>
> Zip on VMS does file access the same as any other program
> on VMS. If the NFS client software hides files from everyone,
> then that includes Zip, too. But if the NFS client software
leave out "if", because this is the way NFS for OpenVMS is designed.
The "hidden" files just contain the file-header info. So if you zip them
with zip "-V" on OpenVMS the correct file-attributes are stored just as
if the data were on a ODS-disk.
JF Mezei
^^
> leave out "if", because this is the way NFS for OpenVMS is designed.
> The "hidden" files just contain the file-header info. So if you zip them
> with zip "-V" on OpenVMS the correct file-attributes are stored just as
> if the data were on a ODS-disk.
But the file attributes are really stored in indexf.sys for that file
entry, right ?
is the format of those .ADF files on the NFS volume documented ? For
instance, could someone write some small unix utility that could open
them and list the file attributes described in them ?
Or is the format totally secret/proprietary and undocumented for the
masses and only Hoff and other real engineers know them ?
This sound like the callable mail for extrenal protocols. They
documented how to write a transport, but never documented how to process
a MAIL/FOREIGN message because of the extra "file attributes" block.
Bob Koehler
>
> As files go, I wouldn't expect a BACKUP save set to be
> particularly exotic, so I wouldn't expect BACKUP to have any
> particular trouble with an NFS-remote save set file. Which
> "old posts", exactly?
You would be wrong. BACKUP very much wants certain file attributes
just the way it sets them, attributes that many file systems don't
know jack about.
Over time, there have been a variety of solutions to this, and the
current version of BACKUP is supposed to have some built-in (I
haven't tried it). But without those work-arounds, you couldn't
read a BACKUP save once it had been copied to a brain-dead file
system.
Over the decades, there must have been hundreds, if not thousands,
of posts providing the work-arounds to various newbies.
Bob Koehler
>
> But the file attributes are really stored in indexf.sys for that file
> entry, right ?
No. File attributes are stored in the file header, INDEXF.SYS just
keeps track of the whereabouts of all the file headers.
Steven Schweda
> > particularly exotic, so I wouldn't expect BACKUP to have any
> > particular trouble with an NFS-remote save set file. Which
> > "old posts", exactly?
>
> You would be wrong. BACKUP very much wants certain file attributes
> just the way it sets them, attributes that many file systems don't
> know jack about.
>
> Over time, there have been a variety of solutions to this, and the
> current version of BACKUP is supposed to have some built-in (I
> haven't tried it). But without those work-arounds, you couldn't
> read a BACKUP save once it had been copied to a brain-dead file
> system.
>
> Over the decades, there must have been hundreds, if not thousands,
> of posts providing the work-arounds to various newbies.
Uh, learn to read?
No one was talking about storing a VMS BACKUP save set file
on a "brain-dead file system". We were talking about whether
a VMS NFS client could store the necessary attributes of a
BACKUP save set on an NFS-remote file system. Which it can.
If you're referring to the usual block-size problem, as
described, for example, at:
http://antinode.info/dec/sw/fixrec.html
then I think that I may know a little bit about it. But
thanks for wasting our time.
Paul Sture
I had a problem several years ago (2006?) trying to create a BACKUP
saveset on an NFS volume because the saveset exceeded 2GB - this was
using NFS 2 (either because that's all OS X supported back then or
something between VMS and NFS negotiated NFS 2).
What I did instead was to use LDDRIVER to create CD sized virtual tape
units on the NFS volume and used BACKUP to create a multi-volume tape
saveset. Then off to CD at my leisure.