topic Re: Problem with DFU 3.2 and /over_allocated in Operating System - OpenVMS

Problem with DFU 3.2 and /over_allocated

Peter Barkas — Wed, 04 Feb 2009 12:33:55 GMT

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.

Re: Problem with DFU 3.2 and /over_allocated

Hoff — Wed, 04 Feb 2009 12:56:52 GMT

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

Re: Problem with DFU 3.2 and /over_allocated

Peter Barkas — Wed, 04 Feb 2009 13:00:30 GMT

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.

Re: Problem with DFU 3.2 and /over_allocated

Hein van den Heuvel — Wed, 04 Feb 2009 13:01:37 GMT

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.

Re: Problem with DFU 3.2 and /over_allocated

Peter Barkas — Wed, 04 Feb 2009 13:16:46 GMT

Thanks Hein, I'm on it.

Re: Problem with DFU 3.2 and /over_allocated

Hoff — Wed, 04 Feb 2009 13:36:03 GMT

>...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...)

Re: Problem with DFU 3.2 and /over_allocated

Jur van der Burg — Wed, 04 Feb 2009 14:12:44 GMT

>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.

Re: Problem with DFU 3.2 and /over_allocated

Jur van der Burg — Wed, 04 Feb 2009 14:40:33 GMT

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.

Re: Problem with DFU 3.2 and /over_allocated

Hoff — Wed, 04 Feb 2009 14:47:50 GMT

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.

Re: Problem with DFU 3.2 and /over_allocated

Peter Barkas — Wed, 04 Feb 2009 15:07:31 GMT

I will investigate updates and retry the operation.