In a message dated 95-10-27 13:26:33 EDT, [log in to unmask] writes:
 
>I don't think it's as much a security issue (except for HP's arbitrary
>logic in only allowing the creator to rename it - VeSoft got it
>right!), as it is a matter of having to, as you say, move the file to
>the new volume set.  I suppose that the command's logic could perform a
>copy and purge, as it were, but I doubt that HP would go to the trouble
>(INTEREX - is this an enhancement request?).  This sticks our
>programmers all the time because they don't always remember our VS
>layout (we have six user volume sets).  Maybe your answer is to concoct
>a ":RENAME-intercept" UDC which runs MPEX (buy it if you don't have
>it!!) and does what you want??
>
>
 
Agree with all the above, but I bet you it also has to do with XM recovery
and synchronizing activities.  To implement the rename across volume sets
would require two-phase commit, which I don't believe is supported at this
time by the XM.
 
Anyways, for all practical puposes, a RENAME intercept  expanded to test
group locations and to do either rename or move would work OK.
 
This two phase commit thing on XM is also probably why you have to do two
commands when you create a new group on a VS, to wit  NEWGROUP;ONVS= and
NEWGROUP;HOMEVS=.
 
Kind regards,
 
Denys. . .