- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Getting incorrect value for file attribute "fa...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-14-2013 07:10 AM
06-14-2013 07:10 AM
Re: Getting incorrect value for file attribute "fat_l_efblk". i.e. getting zero even thoug
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-14-2013 08:19 AM
06-14-2013 08:19 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-14-2013 08:23 AM
06-14-2013 08:23 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-14-2013 08:56 AM
06-14-2013 08:56 AM
Re: Getting incorrect value for file attribute "fat_l_efblk". i.e. getting zero even thoug
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-14-2013 10:30 AM - edited 06-14-2013 10:32 AM
06-14-2013 10:30 AM - edited 06-14-2013 10:32 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-18-2013 09:33 AM
06-18-2013 09:33 AM
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
- « Previous
-
- 1
- 2
- Next »