Clarification (?)for those of us not expert in the symbolic link area,

LISTF SFD.DATA2, where DATA2 is a group linkname to group DATA, works, but
LISTF @.DATA2 does not. LISTF @.@ works but lists the contents twice as
Gavin described.

LISTFILE ../DATA2/@ works as one would intuitively expect - lists all files
in group DATA one time only, but reports them under /DATA2/.  Some listf
modes will additionally report the true path:

listfile ../DATA2/@,2

ASTRO/DARNELL/DATA(1):listfile ../DATA2/@,2
 PATH= /DARNELL/DATA/../DATA2/

 CODE  ------------LOGICAL RECORD-----------  ----SPACE----  FILENAME
         SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX

           6B  VAM          0       1302  42       64  2  *  ALLOCAT1
          80B  VAM          0       1029   3      256  1  *  ALLOCATR
         298B  FA           9       1014   1       48  1 32  AP000300
         298B  FA           3       1014   1       48  1 32  AP000500

I do not yet know how this will tie in with intrinsics such as FOPEN,
HPFOPEN, and the AIF calls, but I am hoping it can provide the same
functionality as if file equates could equate at the group level.

One capability of file equations is that they can redirect away from
existing files that we do not want to access under the names called out by
the program.

:FILE mydb.mygroup=mydb.testdata will keep us from accessing the real
mydb.mygroup, if the open intrinsic is optioned appropriately.

I don't believe we can do that with symbolic links - the "real" filename
already owns the linkname pointing to itself, so we cannot add another
linkname pointing to a different physical file.  Yes, you can swizzle it
such that it is the same as renaming the file, but,... why.


And, of course, symbolic links are persistent across sessions whereas file
equations are not.

-d


> -----Original Message-----
> From: Gavin Scott [mailto:[log in to unmask]]
> Sent: Monday, December 18, 2000 12:05 PM
> To: [log in to unmask]
> Subject: Re: not rescinded: NEWLINK for a group
>
>
> Dave writes:
> > This worked perfectly, thanks.
>
> Note that symbolic links at the GROUP level to other GROUPs
> work rather
> strangely in some cases.  For example, a LISTF @.@ will
> traverse the target
> group twice, reporting that all of the files exist in each
> "group".  This
> could cause problems for some tools/applications/humans.
>
> The symlink looks enough like a real group that certain MPE
> commands will go
> ahead and try to operate on it as though it were a real
> group, though some
> operations work, some fail halfway, and some don't work or
> just don't see
> the group at all.
>
> Beware.
>
> G.
>