DSXchange

Yes, I've seen it personally and it has been reported here as well by several others, I do believe. All it takes is the loss of the hidden .Type30 file inside the directory to cause this issue as the hashed file is no longer a dynamic one. It can then fall back on this funky (type 1? 19?) "hashed file" where every record is written out as a separate file.

As you noted, the correct solution is to nuke it and let it rebuild from scratch.

Edit: found another post on the subject.

Thanks for the info chulett. I had suspected that the hashed files were being created as something other than Type 30, but I've never used anything else in five years, and figuring it out took a back seat to recovering.

When you create the hashed file/s you are better off deleting and recreating them (if possible) for this (amongst other) reason.
IHTH... (I hope This Helps)

Backing up a Type30 causes the ".Type30" to go missing. One solution is to add a .Type19 hidden file to the directory and at the ">" prompt,

create a VOC ENTRY that looks like this:

F
PATHNAME
D_VOC


Then do a COPYI FROM PATHNAME TO REPAIREDHASH ALL


--------

Cheers,

Ray D

daignault wrote:Backing up a Type30 causes the ".Type30" to go missing.

That would depend entirely on how one backs it up, yes?

roy wrote:When you create the hashed file/s you are better off deleting and recreating them (if possible) for this (amongst other) reason.

Whereas in my experience, deleting and recreating them each time has been at the root of this issue. I tended to stick with "Clear" unless I had a good reason to nuke them each time and that would generally involve dynamic setting of the Minimum Modulus based on wildly variable volumes. Different strokes.

Craig,
I beg to differ!
In my humble opinion (from experience) any hashed file that is used for a long period using the clear option never being deleted and created a new, is bound to eventually get corrupted.

And in my experience I've found them to be quite resilient and really only saw "corruption" for issues like (lack of) disk space, going over the dreaded 2GB barrier with 32bit addressing or by writing funky data to them. Otherwise, solid. Like I said, different strokes.