dfu abort

[Ian Miller.]

I think DFU is not officially supported. I wish it was and was included on every VMS system.
You may be able to report the bug via support channels but HP don't have to fix it.

Hopefully they will.

[Jack Trachtman]

I had upgraded DFU from v2.7a to v3.1-1 this week and was reviewing its functionality. The disk VERIFY option seems to find more (minor) things wrong with directories than ANALYZE/DISK does, which I found interesting, so I put DFU in a script that would run it against all disks on a system, and copied that script to all our VMS hosts to try it. That's when I started seeing it abort on some disks (I've run across at least 4 disks now that cause it to abort).

Tom: I've tried your suggestions, but I see no change. I've also played with quota settings because the problem seems to occur on "large" disks.

Jur: Your analysis may be the clue needed.

My problem now is I don't have a contact to notify of this problem.

[Ian Miller.]

I found with DFU VERIFY that specifying the /DIR qualfier gave more consistant results.
Also using /LOCK helps if you can.

[Jur van der Burg]

Folks, I know there's a fix in DFU V3.1-3 as that's what I'm running now for some time. When Ton Dorland left HP he handed me the sources where this was fixed. We have been discussing about integrating it in VMS when I was a member of VMS engineering, and I did the work to make that possible, but higher management was against the idea.

I do have an Alpha kit for that version, and I will see that I can make it available one of the next days.

I'm not supporting DFU, but I know Ton personally and will ask him about any new work he may have done in the past since I acquired the sources. Don't ask HP for support, it's freeware after all.

Jur
lddriver at digiater dot nl

[TonDorland]

Folks,

these issues have been solved in V3.1-3. That is the last published version.
My apologies for replying this late, but I am no longer working in the VMS business, so I do not actively folow OpenVMS threads.

Regards,

Ton Dorland

[Jess Goodman]

Jur,

I reported to Tom by email two other bugs in V3.1-1. I'm hoping you can confirm that they are fixed in V3.1-3. I know Tom had found the problems and was working on fixing them for the next version.

One bug was that when you do a DFU SEARCH with /CREATE=SINCE= (or any other way of specifying a date-time limit) you may get files that were created up to 7 minutes before the given time. Probably this is due to not properly comparing the low-order 32 bits of a 64 bit binary datetime value.

The second bug I reported was with DFU UNDELETE (without /LIST) not finding all files it should. Tom eventually tracked this down any replied to me (quoted below so you can ask him about it):

"Well I found the bug. It had something to do with the command-line processing which could cause the result from parsing something like *.COM into a string which was not terminated correctly. Therefore my routine which compares a deleted file name with the *.COM would say 'no match'. Due to the coding the problem will not show up if you either use /LIST or if you use *.COM without semicolon."

[Jur van der Burg]

These bugs are fixed in the latest sources that I just got from Ton. I'm going to rebuild and repackage dfu, when it's ready I'll announce it here.

Jur.

[Dave Gudewicz]

Many thanks Jur and Ton. The OVMS community appreciates your effort and help with DFU.

Dave...

[Jur van der Burg · Accepted solution]

Ok, DFU V3.2 is ready to go.

http://www.digiater.nl/dfu

Jur.

[Steven Schweda]

> http://www.digiater.nl/dfu

The Web page (HTML) title needs some work.

Minor feature request:

DFU /VERSION (or similar).