Operating System - OpenVMS
1747992 Members
5469 Online
108756 Solutions
New Discussion

Re: Getting incorrect value for file attribute "fat_l_efblk". i.e. getting zero even thoug

 
SOLVED
Go to solution
Steven Schweda
Honored Contributor

Re: Getting incorrect value for file attribute "fat_l_efblk". i.e. getting zero even thoug

 
allin-in-one
Frequent Advisor

Re: Getting incorrect value for file attribute "fat_l_efblk". i.e. getting zero even thoug

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
Frequent Advisor

Re: Getting incorrect value for file attribute "fat_l_efblk". i.e. getting zero even thoug

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.

 

Steven Schweda
Honored Contributor

Re: Getting incorrect value for file attribute "fat_l_efblk". i.e. getting zero even thoug

 
Hein van den Heuvel
Honored Contributor
Solution

Re: Getting incorrect value for file attribute "fat_l_efblk". i.e. getting zero even thoug

 

>> 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
Trusted Contributor

Re: Getting incorrect value for file attribute "fat_l_efblk". i.e. getting zero even thoug

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