Conference vaxaxp::vmsnotes

310.0. "Q: file id on volume set" by OSOSPS::HIRAIWA (Yoshitaka Hiraiwa/SPS) Wed Mar 12 1997 04:20

Hi, how are you?
I have a question about file id of the file in volume set.

My customer has the bind volume set on VMS/VAX V6.1 as follows:

$ show dev dsa414
Device                  Device           Error    Volume         Free  Trans Mnt
 Name                   Status           Count     Label        Blocks Count Cnt
DSA414:                 Mounted              0  RART_BLK1       854936     2   1
DSA515:                 Mounted              0  RART_BLK2       854944     2   1
$1$DIA4:      (HSD000)  ShadowSetMember      0  (member of DSA414:)
$1$DIA5:      (HSD000)  ShadowSetMember      0  (member of DSA515:)
$1$DIA14:     (HSD001)  ShadowSetMember      0  (member of DSA414:)
$1$DIA15:     (HSD001)  ShadowSetMember      0  (member of DSA515:)
$

Members of this volume set are DSA414: (rvn 1), DSA515: (rvn 2).
I found the file that has file id that I was interested in.

$ dir/file DSA414:[HKDART.CALENDER]

Directory DSA414:[HKDART.CALENDER]

CALENDAR.TXT;16      (25285,2,258)
			      ^^^^	
CALENDAR.TXT;15      (31433,1,257)
			      ^^^^	
CALENDAR.TXT;14      (41282,51,2)
DATETABLE.TXT;1      (79,1,2)
ROUTINEDATA.TXT;416  (38695,17,1)
ROUTINEDATA.TXT;415  (14552,43,257)
			       ^^^^
ROUTINEDATA.TXT;414  (7935,21,2)

Total of 7 files.

I know the third number is relative volume number.
In my knowledge, this number is less than 255.

Anyway, the contents of these files are fine for me now. 
And  file id are different from one in file header and one in directory file.
In this case, (90821,2,0) is in file header, (25285,2,258) is in directory 
file.

Please tell me about it!

Best regards,
Yoshitaka Hiraiwa/SPS/MCS/Japan

$ dump/head DSA414:[HKDART.CALENDER]CALENDAR.TXT;16

Dump of file DSA414:[HKDART.CALENDER]CALENDAR.TXT;16 on 12-MAR-1997 13:02:27.59
File ID (90821,2,2)   End of file block 39 / Allocated 40

                             File Header

Header area
    Identification area offset:           40
    Map area offset:                      100
    Access control area offset:           255
    Reserved area offset:                 255
    Extension segment number:             0
    Structure level and version:          2, 1
    File identification:                  (90821,2,0)
    Extension file identification:        (0,0,0)
    VAX-11 RMS attributes
        Record type:                      Fixed
        File organization:                Sequential
        Record attributes:                Implied carriage control
        Record size:                      19764
        Highest block:                    40
        End of file block:                39
        End of file byte:                 308
        Bucket size:                      0
        Fixed control area size:          0
        Maximum record size:              19764
        Default extension size:           0
        Global buffer count:              0
        Directory version limit:          0
    File characteristics:                 <none specified>
    Map area words in use:                2
    Access mode:                          0
    File owner UIC:                       [HKDART,HKDARTMGR]
    File protection:                      S:RWED, O:RWED, G:RWED, W:
    Back link file identification:        (24,1,1)
    Journal control flags:                <none specified>
    Active recovery units:                None
    Highest block written:                40

Identification area
    File name:                            CALENDAR.TXT;16
    Revision number:                      1
    Creation date:                        28-FEB-1997 22:01:44.49
    Revision date:                        28-FEB-1997 22:01:45.31
    Expiration date:                      <none specified>
    Backup date:                          <none specified>

Map area
    Retrieval pointers
        Count:         40        LBN:     695020

Checksum:                                 1211

    re: .0
    
    Something is rather interesting here...  Note the following pattern
    whem viewed in Hex:
    
    $ a=90821
    $ sho sym a
      A = 90821   Hex = 000162C5  Octal = 00000261305
    $ b=25285
    $ sho sym b
      B = 25285   Hex = 000062C5  Octal = 00000061305
    $ c=258
    $ sho sym c
      C = 258   Hex = 00000102  Octal = 00000000402
    			   ^
    			   |
    			Did this come from b???
    
    
    Dan

    The format of the File ID is
    
    ___________________________________
    |      seq       |      num       | 0
    |________________|________________|
                     |  nmx   |  rvn  | 4
                     |________|_______|
    
    Where 'num' and 'nmx' are really one number.  'nmx' is the most
    significent bits of the file number.  Where the file number is
    actually 24 bits long.
    
    The DIRECTORY command is only formatting the value as three 16 bit
    values instead of a 24 bit value, a 16 bit value and an 8 bit value.
    
    So when there are more than 65535 files on the disk, 'nmx' starts to
    get non-zero values.
    
    					Bob Harris
    
    PS.  This actually has nothing to do with Volume Sets.  The same
         problem will occur on a single disk if the total number of files
         exceeds 65535.  You just noticed it because you were looking at RVN
         values.
    
    PPS.  Just wait until you have to figure out RVN values of 0 on a
          volume set!  What fun.

Hi thank you very much for replies!

.1>    Something is rather interesting here...  Note the following pattern
.1>    whem viewed in Hex:

Good idea! The way you did is important, when you are beginning to find out
something that you don't not know much.

.2> PPS.  Just wait until you have to figure out RVN values of 0 on a
.2>       volume set!  What fun.

I found a following description about RVN.

FID$B_RVN : Relative volume number. It indicates the volume of a volume
	    set on which a file is located. If this volume is not part of
	    a volume set,then this word contains a value of 0. If the 
	    volume is part of a volume set, then the relative number(RVN)
	    can range from 1 to 255.

	    When a file must be referenced in context of the volume on
	    which a file is located, a relative volume number of 0 is used,
				     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	    regardless of the RVN that may be assigned to that volume.

0 means that the file is located the same disk as indexf.sys is located.
Is it right?

Therefore, this volume is good I suppose.
Thank you very much!

Yoshitaka

P.S. The real problem is ACCVIO during backup operation as follow;

     VMS/VAX V6.1 + VAXBACK04_061

     $ backup/image/vol=1 dsa414: $1$dia14:
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000024,
PC=00013A9A, PSL=03C00004

     First, I suspect that the volume is wrong and write the topic in this
     notes file. In results of this topic and analyze/disk says the volume 
     is good. So I will request it to IPMT.

    Actually I think (but I will not claim it for fact), that an RVN of
    zero indicates that the file has the same RVN as the parent directory,
    but don't hold me to that statement.  It has been too long since I had
    to play with RVN information.
    
    					Bob Harris