Operating System - OpenVMS
1748069 Members
5637 Online
108758 Solutions
New Discussion юеВ

Analyze/Disk shows DELHEADER warning

 
Viviana
Occasional Visitor

Analyze/Disk shows DELHEADER warning

Want to know if it's safe to ignore ANALDISK-W-DELHEADER warning messages when I verified that the file didn't exist.
Moreover that, the Analyze/Disk/Repair didn't eliminate the warning message.
This happens on VMS 8.3-1H1 and the file is the DCLTABLE.EXE.
7 REPLIES 7
Steven Schweda
Honored Contributor

Re: Analyze/Disk shows DELHEADER warning

Probably. Around here, it's usually a
"lock.VMS" or "LOCK.VMS" in a [.NETSCAPE]
directory, created by an old Web browser.

> Moreover [...]

If the file is still open, then it's already
about as deleted as it can get. When the
process which is using the file exits, then
/REPAIR should work better.
Viviana
Occasional Visitor

Re: Analyze/Disk shows DELHEADER warning

We ran ana/disk/repair many times and the error still appears.
The file addressed is the DCLTABLES.EXE;153. The current version of this file is 154 and 153 didn't exist (suppose it was deleted or purged previously).
I read that this file usually is marked for delete after an upgrade or install of a layered product fails is performed.
As I'm planning an OS upgrade I want to be sure if I can ignore that message.
Hoff
Honored Contributor

Re: Analyze/Disk shows DELHEADER warning

Somebody's probably updated DCL command tables here and has likely reinstalled the tables and the previous/current/old processes (and users) of the older version of the command tables haven't been fully cleared out yet.

This'll be fine for now, and can be cleaned up after the old tables are released or (more commonly) can be cleaned up after the next reboot.

(Not rebooting means that any existing and logged-in users and processes will have to log out and back in again to pick up the command table changes, too. Or after the next reboot, of course.)
John Gillings
Honored Contributor

Re: Analyze/Disk shows DELHEADER warning

Viviana,

>I read that this file usually is marked
>for delete after an upgrade or install of
>a layered product fails is performed.

It's not failed upgrades, it's successful ones. There's a question that VMSINSTAL asks:

"Do you want to purge files replaced by this installation [YES]?"

The default is YES. I believe it should be NO. Disk space is cheap. Purging files recovers an infinitessimal value in disk space, but loses the much more significant benefit of being able to roll back to previous versions. Purging also causes the error that you're seeing right now.

I recommend always alswering NO to this question.

>As I'm planning an OS upgrade I want to be
>sure if I can ignore that message.

Yes and no. Here's what's happened. Someone at some time did an installation that updated or inserted a new verb into DCLTABLES, creating a new version of DCLTABLES.EXE and said YES to the purge question. At the successful completion of the installation, the old version of DCLTABLES was purged (DELETEd). Since any running DCL process has DCLTABLES open, the DELETE succeded, but didn't actually delete the file. It's just maked the file as deleted in the header and removed the directory entry. This is normal behaviour. Over time, as processes stop and restart, they drop the old version and pick up the new one.

In theory, when the file is formally closed by the last process to have it open, RMS will see the delete bit in the header and complete the deletion process. All mess is cleared up and everyone is happy.

HOWEVER, in practice, any process that has kept DCLTABLES open for an extended period will probably keep it open "forever". Instead of a nice clean RMS CLOSE, it will most likely be $DELPRCed when the system is shutdown. The RMS cleanup won't happen and the file will remain on disk. When you run another ANALYZE/DISK/REPAIR after the next reboot the file will be cleaned up.

So, you can ignore it for now. All its telling you is a file deletion has not completed. Worst case you're wasting a few hundred blocks of disk space that needs an ANALYZE/DISK/REPAIR to cleanup sometime in the future.

To avoid seeing this error in future, always answer NO to purging files replaced by an installation.
A crucible of informative mistakes
Viviana
Occasional Visitor

Re: Analyze/Disk shows DELHEADER warning

Thanks for all your answers, all are very explanatory.
Although that, I really don't understand why the subsequents ana/disk/repair and reboots didn't remove the warning.
But for me it's ok with your answers.

Best Regards,
Viviana
Steven Schweda
Honored Contributor

Re: Analyze/Disk shows DELHEADER warning

> If the file is still open, then it's already
> about as deleted as it can get. When the
> process which is using the file exits, then
> /REPAIR should work better.

Running ANAL /DISK /REPAIR does not stop the
process which is keeping a file around.
Stopping that process is needed to release
the file, and allow it to be deleted. (Or,
perhaps a little more precisely, to allow its
deletion to be completed.)

Rebooting generally stops every process, so
that's a one-step solution. Logging out the
interactive processes which are using the old
file may help, too, but not every process is
so easy to stop and restart.
Hoff
Honored Contributor

Re: Analyze/Disk shows DELHEADER warning

This is not complex.

Reboot. That clears all current processes, and frees all resources, and releases all connections to the DCLTABLES section.

Subsequent to the reboot, issue ANALYZE /DISK /REPAIR to perform the repair, now that all resources are released. This may still show some (other) diagnostics, as you're on a running system.

If you're still showing the DCLTABLES errors, then you probably have something implemented in the local startups that is changing the file (and then reloading it) at run-time.

If you're showing other errors, shut down and boot from a distribution disk or another system disk, and issue the ANALYZE /DISK /REPAIR from there. That means the target disk is quiescent.

Far, far, far, far more important here than what are these basically "noise" diagnostics from ANALYZE is having a full disk backup. More than a few folks that get confused by this sort of low-level stuff can also get confused by tools such as BACKUP /IGNORE=INTERLOCK qualifier and the errant belief that that command provides an online backup, and they end up with incomplete or corrupt backups.

Follow the steps in the OpenVMS installation and upgrade manual around using a different system disk or the distribution disk to get a (good, complete, reliable, consistent) backup.