Geoff asks:
>      Would anyone happen to know the reasoning behind RENAME (frename) not
> being able to work across volume sets?  I understand the "why" - that RENAME
 
Well, if    RENAME T.DEVEL.FOO , T.PROD.FOO fails because of the two groups
being on different volume sets, you can try:
 
   :mv.hpbin.sys "/FOO/DEVEL/T /FOO/PROD/T"
 
It worked for the one simple case I tried (moving a file that
looks like:
 
   FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
                     SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX
 
   T                  88B  FA           9          9  32       16  1  1
 
BTW, I'm a little unclear on precisely what you are asking:
 
   1) why can't RENAME revert to doing a COPY/PURGE (i.e., a Unix "mv")
      if the destination is on a different volume set;
 
      Probably because there wasn't that much call for the ability in
      the old days (MPE V).  (It seemed like the majority of users
      shied away from Private Volumes.)
 
or
 
   2) why can't RENAME simply rename the file (without moving the data)
      even though it is on the wrong volume set?
 
      Because, like Unix, a single directory cannot have files in it that
      are on different volume sets.
 
      MPE does not keep ldevs in the directory or in the Label Table.
      Instead, the information about each extent of disk associated with a
      file is recorded in the type "t_extent_descriptor", which looks like:
 
         T_EXTENT_DESCRIPTOR =
            PACKED RECORD
            EXTENT_SECTOR_ADDR : BIT32 ($0.0 @ 4.0);
            SECTORS_IN_EXTENT  : BIT24 ($4.0 @ 3.0);
            VOL_SET_INDEX      : T_VOL_SET_INDEX ($7.0 @ 1.0);
            FILE_SECTOR_OFFSET : BIT32 ($8.0 @ 4.0);
            END ($0.0 @ c.0)
 
       The crucial part is the VOL_SET_INDEX ... that's a relative number
       where 1 means the master volume of the set, 2 means the second volume
       of the set ... nary an ldev in sight!
       Thus, an entry in the Label Table is completely unable to describe
       a chunk of disk on a volume in another volume set.
 
       BTW, notice that the VOL_SET_INDEX is only 1 byte in size?  That
       implies that a volume set cannot have more than 255 volumes in it.
       (it could have been 256, but 0 is currently never used).
 
       Similarly, the maximum extent size imposed by this data structure
       is 16,777,215 sectors (2^24 - 1).
 
       The FILE_SECTOR_OFFSET field imposes a size limitation of
       4 billion sectors.  However, other things conspire to limit the
       size of a single file to 4GB at present.
 
       Finally, the EXTENT_SECTOR_ADDR field imposes a size limitation
       of 4 billion sectors per disk drive (that would be a 1 terabyte disk!).
 
--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html