Analyze/disk/repair - bad file version...

[Rich Hearn]

Hi Folks,

I did an analyze/disk/repair on my system's boot disk (also does printer spooling) and there are so many "lost" files that I've reach the 32767 file version limit (example below).

I do not know of any problems if I do a delete on these files, but because there are other files that haven't yet been able to be mark as "found", I thought I should check to see if any one else knows of any complications that could/would be created by doing the deletion.

Tnx,
Rich

%ANALDISK-E-ENTERLOST, file (53834,2,0) [].;
error entering file in directory
-SYSTEM-W-BADFILEVER, bad file version number
%ANALDISK-E-ENTERLOST, file (53838,4,0) [].;
error entering file in directory
-SYSTEM-W-BADFILEVER, bad file version number
%ANALDISK-E-ENTERLOST, file (53848,1,0) [].;
error entering file in directory
-SYSTEM-W-BADFILEVER, bad file version number
CACHE1::DISK$INFSYS:[RJHEARN]_>
CACHE1::DISK$INFSYS:[RJHEARN]_>
CACHE1::DISK$INFSYS:[RJHEARN]_>dir/total Dsa1:[syslost]

Directory DSA1:[SYSLOST]

Total of 32767 files, 67393 blocks.
CACHE1::DISK$INFSYS:[RJHEARN]_>
CACHE1::DISK$INFSYS:[RJHEARN]_>show time
5-AUG-2008 13:02:09
CACHE1::DISK$INFSYS:[RJHEARN]_>
CACHE1::DISK$INFSYS:[RJHEARN]_>
CACHE1::DISK$INFSYS:[RJHEARN]_>dir Dsa1:[syslost]

Directory DSA1:[SYSLOST]

.;32767 2 2-MAR-2008 17:57:14.64 [INFSYS,MLEITH] (RWED,RWED,RWED,)
.;32766 2 2-MAR-2008 17:53:04.46 [INFSYS,MLEITH] (RWED,RWED,RWED,)

[RBrown_1]

Files with no name or filetype? If they are not "current" (as these ones are not) then I think there should be no problem deleting them. Do you know anything about [INFSYS,MLEITH] and why "he" is creating so many unnamed files?

Somebody else will probably be able to tell you that DFU can delete all of these files much more easily than you can with the DCL DELETE command. Otherwise you might do better with a bit of DCL to delete them starting at version 1 and finishing with version 32767.

Have fun!

[Rich Hearn]

Mr(Ms? Mrs?)Brown,

There is no to these files because that's how IDX's Cache application sends them - at least that's what their support folks have told me in the past. Some things "ya just hav'ta accept" :^)

I'll have to do some looking up on DFU...

Tnx,
Rich

[RBrown_1]

Mr works for me, thanks.

It is certainly valid enough to create temporay files with no names, but then the application ought to delete them when it is finished with them. Unfortunately, it appears that the application has passed this problem on to you. :-(

[Hein van den Heuvel]

It must be mightly tempting to just delete those lost files!

[SYSLOST] is not a 'sepcial' file like 000000.dir (fid=4,4). SO you can just rename is to SYSLOST_PART_01.

Or you can rename the files away to clean it.

$CREATE/DIR [SYSLOST_01]
$RENAME/NOLOG [SYSLOST]*.*;* [SYSLOST_01]

Now restart te ANAL/DISK/REPAIR?

fwiw,
Hein.

[Hoff]

There was an ECO related to a failure to correctly delete files copied to spooled devices; get current on your ECOs for whatever version and architecture of OpenVMS is in use here, if you're not already there.

It's also possible some application (other than a spooled device) is leaving temporary files around; that's not unheard of, too.

And you can always aim your spooled device at some scratch disk, and let the crud build up there. This on the off chance you can't fix this via application of upgrades and/or current ECO kits, and need to hack around this mess.

[Rich Hearn]

Mr Brown,
The App doesn't really leave the files for me to clean up; it's just that they get sent to the printers with /NoDelete (in case of errors I guess) and, obviously, some get "lost" in the process.

Hein,
Nice ideas on how to "get them out of the way" without causing any major problems

Hoff,
I believe I'm current on the patches, but it's a good suggestion - I'll follow up on it.

Thank you all for your thoughts & ideas - I do appreciate them.

Rich

[Wim Van den Wyngaert]

Did some testing too.

In our DSM application, they just write to a channel (1, 2, 3,...). This is a logical pointing to a LAT device that is spooled to a LAT or TCP print queue. You can simulate this with dcl open, write, close. The result is an entry with "/delete".

When the entry is not yet printed and you do an anal/dis/rep it will create an entry in SYSLOST but with name ".DAT" `(but that may depend on how you create the entry ???).

If you don't delete the file it still gets printed. And deleted in syslost.

If you delete the syslost file, it will end in error (if your queue has /retain=error, I ALWAYS have it active).

Wim

[Wim Van den Wyngaert · Accepted solution]

If you write to "3:.;" and 3 points to the lat port, you get the file .; as you have.

Wim

[Rich Hearn]

Wim,

Thank you for your time and effort to get that information. Our logicals are the printer names pointing to network print servers (NetQue's/JetDirects) that are connected to those printers. Basically, the TCP version you wrote of.

/retain=error is on our queues also (DSM/Cache std I assume).

I thank you for being able to explain how those file versions get created - I had asked IDX, but didn't get much for an answer.

BTW: I have deleted all the "lost" files (after renaming syslost & running analyze/disk/repair a few times with no problems) and gained back ~1 1/2 M VMS Blks on the disk

Thanks again,
Rich