Operating System - OpenVMS
1748200 Members
3846 Online
108759 Solutions
New Discussion юеВ

Re: Problem with DFU 3.2 and /over_allocated

 
SOLVED
Go to solution
Peter Barkas
Regular Advisor

Problem with DFU 3.2 and /over_allocated

Not sure if this is a known problem, but for certain files, DFU shows the used space as 0 when directory/size does not.

Disk exhibiting the problem is 48GB with cluster 137 and is the 32nd shadow set on san HSV200.

Other files, other DFU options and other disks after 32nd seem OK.
9 REPLIES 9
Hoff
Honored Contributor

Re: Problem with DFU 3.2 and /over_allocated

The maintenance of and maintainer of DFU is not affiliated with HP. Please contact Jur directly; he may or may not see this bug report here. http://www.digiater.nl/dfu
Peter Barkas
Regular Advisor

Re: Problem with DFU 3.2 and /over_allocated

Thanks Hoff, I knew that, but I have seen other DFU issues logged here before and thought that the problem may be relevant for other users.
Hein van den Heuvel
Honored Contributor

Re: Problem with DFU 3.2 and /over_allocated

To try and understand what might be happening you'll need to provide a lot more detail here, or to Jur.
(http://www.digiater.nl/dfu)

Please collect the following information and ATTACH as a plain TXT file to a future reply:

- verbatim DFU command and output reduced to header, and example file or two and trailer.

- DIR/FULL for an example file

- SHOW DEV/FULL for the device holding the example

- DUMP/HEAD/BLOC=COUN=0 for an example file.

and maybe
- DUMP/HEAD/BLOCK=COUNT=1 for [000000]INDEXF.SYS

While the OS details are likley irrelevant, please indicate the exact OpenVMS version, platform and patch level. (CD, update X00, ...)

Hope this will help a little bit,
Hein.

Peter Barkas
Regular Advisor

Re: Problem with DFU 3.2 and /over_allocated

Thanks Hein, I'm on it.
Hoff
Honored Contributor

Re: Problem with DFU 3.2 and /over_allocated

>...but I have seen other DFU issues logged here before and thought that the problem may be relevant for other users...

In all seriousness (and with all respect intended), we also see HP-UX and Windows questions here, too.

Jur may well need access to the boxes here and/or to enable any latent diagnostics on the boxes. Not everybody has a configuration sufficient to replicate this.

I don't know that he has a bug tracking system here. (There really isn't one of those typically used for most Freeware, though. I don't have one of those up for the Freeware I've released. But I digress...)
Jur van der Burg
Respected Contributor

Re: Problem with DFU 3.2 and /over_allocated

>I don't know that he has a bug tracking system here.

Well, I DO have a bug-tracking system and that's called email :-). As long as the volume is low it works just fine.

I'll look into this problem soon.

Jur.

Jur van der Burg
Respected Contributor
Solution

Re: Problem with DFU 3.2 and /over_allocated

Peter has sent me some more info. The key is this directory output:

SEPTEMBER_2008.OLME;1 File ID: (1025,3,0)
Size: 156865/156865 Owner: [COMPUTER,WADE]
...
File organization: Indexed, Prolog: 3, Using 1 key

and the dump of the file header:

Header area
...
VAX-11 RMS attributes
Record type: Variable
File organization: Indexed
Record attributes: Implied carriage control
Record size: 0
Highest block: 156865
End of file block: 0
End of file byte: 0
Bucket size: 2


Well, I would say that DIRECTORY is lying. The end of file pointer is really 0 and that's what DFU displays. But this file is an indexed file, and for indexed files the end of file pointer is meaningless. RMS will set it to a value such that the display looks okay, but for some reason that has not been done on this file.

DIRECTORY takes the file organisation into account and show the highest allocated block as the filesize.

So in my opinion neither DIRECTORY nor DFU has a bug. The unusual thing is that an application has created an indexed file where the end of file pointer is zero.

Jur.
Hoff
Honored Contributor

Re: Problem with DFU 3.2 and /over_allocated

There have been a couple of cases where EOF has been set oddly; it's meaningless for various file formats, and there were some cases where EOF and EBK were set strangely IIRC. If I were guessing, I'd say the OpenVMS system might be missing an ECO.
Peter Barkas
Regular Advisor

Re: Problem with DFU 3.2 and /over_allocated

I will investigate updates and retry the operation.