Getting incorrect value for file attribute "fat_l_efblk". i.e. getting zero even though it is not.

[allin-in-one]

Hi,

I have file which lists as below.

When finding

$ EOF = F$FILE_ATTRIBUTES("AGTOFC.IDX","EOF")
$ sh sym  EOF
  EOF = 80   Hex = 00000050  Octal = 00000000120

But using the sys$qiow for finding the "fat_l_efblk" getting value as Zero.

But after coping this file to another everything is fine.

Please let me know how to get correct value of "fat_l_efblk" ?

AGTOFC.IDX;1                  File ID:  (15486,1,0)
Size:           80/80         Owner:    [1,1]
Created:    17-NOV-2004 11:18:30.74
Revised:    15-JUL-2010 09:41:12.08 (123)
Expires:    <None specified>
Backup:     24-MAR-2007 01:57:24.06
Effective:  <None specified>
Recording:  <None specified>
Accessed:   13-JUN-2013 17:02:55.30
Attributes: 15-JUL-2010 09:41:12.08
Modified:   15-JUL-2010 09:41:12.08
Linkcount:  1
File organization:  Indexed, Prolog: 3, Using 1 key
Shelved state:      Online
Caching attribute:  Writethrough
File attributes:    Allocation: 80, Extend: 0, Maximum bucket size: 2, Global buffer count: 0, No version limit, Contiguous best try
Record format:      Fixed length 32 byte records
Record attributes:  Carriage return carriage control
RMS attributes:     None
Journaling enabled: None
File protection:    System:RWED, Owner:RWED, Group:RWED, World:RWE
Access Cntrl List:  None
Client attributes:  None

Total of 1 file, 80/80 blocks.

[abrsvc]

There is not enough info here to provide any reasonable answer. Can you provide the following:

1) Version of OpenVMS and the machine type you are using (Alpha, VAX, I64?)
2) A source listing of the code segment with the QIO call. Be sure to show all appropriate variables and their values at the time of the call.

Also, it sounds like the code worked for a new copy of the file and did not for the original. If this is the case, the problem may have been with the file itself rather than the program. Please clarify this as well.

Thanks,
Dan

[allin-in-one]

The system I am using is OpenVMS IA64 v8.4.

From the command  dump /header /block = end = 0 YOUR_FILE

out put is File ID (15486,1,0)   End of file block 80 / Allocated 80.

Here my question is even though the EOF is 80 , efblk is returning Zero.

After copying file like :  $ copy/log AGTOFC.IDX;1 AGTOFC.IDX_copy

The copied file  AGTOFC.IDX_copy is retuning efblk correctly i.e. 80.

I want efblk value for calculating file size.

[allin-in-one]

Ouput of the command

dump /header /block = end = 0 AGTOFC.IDX

Dump of file  XXXXX:AGTOFC.IDX;1 on 14-JUN-2013 12:16:07.81
File ID (15486,1,0)   End of file block 80 / Allocated 80

                             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:          5, 1
    File identification:                  (15486,1,0)
    Extension file identification:        (0,0,0)
    VAX-11 RMS attributes
        Record type:                      Fixed
        File organization:                Indexed
        Record attributes:                Implied carriage control
        Record size:                      32
        Highest block:                    80
        End of file block:                0
        End of file byte:                 0
        Bucket size:                      2
        Fixed control area size:          0
        Maximum record size:              32
        Default extension size:           0
        Global buffer count:              0
        Directory version limit:          0
    File characteristics:                 Contiguous best try
    Caching attribute:                    Writethrough
    Map area words in use:                3
    Access mode:                          0
    File owner UIC:                       [1,1]
    File protection:                      S:RWED, O:RWED, G:RWED, W:RWE
    Back link file identification:        (15371,1,0)
    Journal control flags:                <none specified>
    Active recovery units:                None
    File entry linkcount:                 0
    Highest block written:                80
    Client attributes:                    None

Identification area
    File name type:                       ODS-2
    File name length:                     12
    File name:                            AGTOFC.IDX;1
    Revision number:                      123
    Creation date:                        17-NOV-2004 11:18:30.74
    Revision date:                        15-JUL-2010 09:41:12.08
    Expiration date:                      <none specified>
    Backup date:                          24-MAR-2007 01:57:24.06
    Last access date:                     13-JUN-2013 17:02:55.30
    Last attribute change date:           15-JUL-2010 09:41:12.08
    Extended RMS record attributes:       <none specified>
    File length hints
        Record count:                     <none specified>
        Data byte count:                  <none specified>

Map area
    Retrieval pointers
        Count:         80        LBN:   33113008

Dump of file XXXXXXAGTOFC.IDX;1 on 14-JUN-2013 12:16:07.81
File ID (15486,1,0)   End of file block 80 / Allocated 80

Checksum:                                 31969

Ouput of the copied file

$ dump /header /block = end = 0 AGTOFC.IDX_copy

Dump of file XXXXX:AGTOFC.IDX_COPY;1 on 14-JUN-2013 12:17:55.63
File ID (15489,2,0)   End of file block 80 / Allocated 80

                             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:          5, 1
    File identification:                  (15489,2,0)
    Extension file identification:        (0,0,0)
    VAX-11 RMS attributes
        Record type:                      Fixed
        File organization:                Indexed
        Record attributes:                Implied carriage control
        Record size:                      32
        Highest block:                    80
        End of file block:                81
        End of file byte:                 0
        Bucket size:                      2
        Fixed control area size:          0
        Maximum record size:              32
        Default extension size:           0
        Global buffer count:              0
        Directory version limit:          0
    File characteristics:                 Contiguous best try
    Caching attribute:                    Writethrough
    Map area words in use:                3
    Access mode:                          0
    File owner UIC:                       [1,1]
    File protection:                      S:RWED, O:RWED, G:RE, W:
    Back link file identification:        (15371,1,0)
    Journal control flags:                <none specified>
    Active recovery units:                None
    File entry linkcount:                 0
    Highest block written:                80
    Client attributes:                    None

Identification area
    File name type:                       ODS-2
    File name length:                     17
    File name:                            AGTOFC.IDX_COPY;1
    Revision number:                      1
    Creation date:                        13-JUN-2013 17:04:07.61
    Revision date:                        13-JUN-2013 17:04:07.61
    Expiration date:                      <none specified>
    Backup date:                          <none specified>
    Last access date:                     13-JUN-2013 17:04:07.61
    Last attribute change date:           13-JUN-2013 17:04:07.67
    Extended RMS record attributes:       <none specified>
    File length hints
        Record count:                     <none specified>
        Data byte count:                  <none specified>

Map area
    Retrieval pointers
        Count:         80        LBN:   33113248

 Dump of file XXXXX:AGTOFC.IDX_COPY;1 on 14-JUN-2013 12:17:55.63

File ID (15489,2,0)   End of file block 80 / Allocated 80

Checksum:                                 37872

[allin-in-one]

Thanks for the reply.

I need the actual file size not the allocated size.

I don't know what is wrong with this file, but for all other cases the current logic is working.

How it is possible that EOF is correct not the efblk ?

Is there any way to identify this senario ?

Thank you.

[allin-in-one]

Sorr for the confusion, wrongly used word actual file size , it is used size.

$ set file/attribute=(EBK:0)  file_name

That means we can set EOF to zero.

Then EOF will be ZERO. But in the actual file EOF is 80 and EBK is zero.

[allin-in-one]

I think there is lot of diffrence between "used size" and "allocated size".

For ex:

$ dir/size=all TEST1.LOG

Directory  XXXXX

TEST1.LOG;1                         1/16

Total of 1 file, 1/16 blocks.

Here used size is 1.

Allocated size = 16.

Please refer : http://daviddeley.com/programming/docs/rmsinternals.htm

Can you please tell me what is the difference between EOF and EBK.

As per my understanding  EBK is End of File Block which is last block used.

Please refer :http://h71000.www7.hp.com/openvms/journal/v17/openvms.html

EOF can be same as EBK or EBK+1

Thanks.

[allin-in-one]

Here My question is  how it is possible EOF is 80 and EBK is 0.

> [...] For a
> sequential-access file, the End-Of-File mark is significant.  For an
> indexed file (which is never processed sequentially), the End-Of-File
> mark is not significant, so many programs do not bother to set it.

I agree with you. But after copying file, file type changes from sequential to indexed or vise versa ?

But after coping file EOF is 81 and EBK is 80.

[Hein van den Heuvel · Accepted solution]

>> Please let me know how to get correct value of "fat_l_efblk" ?

You can not get that for an indexed file.

You may get a value which may look like an EOF but is has NO OFFICIAL MEANING.

Utilities can, and will, play fast and lose with the value and the behaviour can and has changed with OpenVMS versions.

RTFM: OpenVMS RMS Services Reference Manual Order Number: AA–PV6RE–TK

11.7 XAB$L_EBK Field ... "The XAB$L_EBK field is meaningful for sequential files only."

I suspect your dis cluster size is simply 80.

Verify with:  $ write sys$output f$getdvi(F$PARSE("AGTOFC.IDX"),"CLUSTER")

The 81 versus 80 stems from the fact that the 80 blocks were (pretended to be) entirely filled : 80*512 bytes,

( where the first block is 1, not 0)

EOF = 512*EBK + FFB.

FFB (First Free Byte) can not be 512. Just 9 bits : 0 .. 511

Therefor, instead of 80*512+512 it becomes 81*512+0

The difference between F$FILE and DUMP is probably that the file was open/in use.

F$FILE (unfortunately!) uses full RMS access in full sharing mode where RMS can read the actual EOF it will eventually flush out to the disk.

>> I don't know what is wrong with this file, but for all other cases the current logic is working.

It is NOT working, it just returns value which look pleasant enough to accept them... which is what was fixed over the years.

So what is the real problem you are trying to solve?

How do you expect to use this EOF value?

>> I want efblk value for calculating file size.

Well, you can not use it for that unless you 'feel lucky punk?'  

You'll need to use the Allocated size for non-sequential file.

I assume you realize that even 1 record in this file will require the 80 blocks due to the cluster roundup.

Even with a 1 block cluster size, it would still take 7 blocks... 3 header blocks, 1 data bucket, 1 index bucket.

And yeah... when copying an indexed file back and forwards between disks with different, non-common-denominator cluster sizes there will be a size creep, as each copy will round up to its full cluster size. This was very common with 'real' disks which often had prime-number sized cluster. Nowadays many switched to powers-of-2 cluster sizes like 32 or 256 minimizing this creep.

hth,

Hein van den Heuvel.

[GuentherF]

To find the highest block under RMS 'control' in an index-sequential file you have to look at the ARE descriptors.

$ ANALYZE/RMS/CHECK file.dat

...

AREA DESCRIPTOR #0 (VBN 3, offset %X'0000')

       ....

       Current Extent Start: 49, Blocks: 16, Used: 3, Next: 52
        Default Extend Quantity: 10
        Total Allocation: 64

AREAs are the blocks under 'control' by RMS. I say 'control' because not all blocks in an area my have data but can be filled anytime with data by RMS. Only RMS knows about used block in an index-sequential file. So utilities like BACKUP and COPY in order to be fast (using block copy) copy all the allocated blocks. All that EOF numbers have therefore no meaning here.

/Guenther