HP Code Management System reports file not closed by CMS.

[allin-in-one]

We have a backup application which takes backup of the disk which contains the CMS library.

After the back CMS reports that file not closed by CMS.

Is there any specific way we need to open the file for the backup ?

-CMS-E-NOTBYCMS, data file DISK1:[CMS.LIB]FILE.TXT;6 not closed by CMS.

Please advise.

Thanks.

[Volker Halle]

Please refer to the documentation for an explanation of the -CMS-E-NOTBYCMS message:

http://h71000.www7.hp.com/doc/73final/5822/5822_013.htm

Volker.

[allin-in-one]

Thank you.

Is there any specfic attributes we need to pass for "sys$qio"  so that there will not be any error messages in CMS ?

Thanks

[Volker Halle]

So you're re-inventing OpenVMS BACKUP ?

Do a DIR/FULL on that CMS file BEFORE running your 'Backup application', then another DIR/FULL afterwards. What's changed ?

Does this CMS error happen on the SOURCE disk after the backup has run or on the backup destination disk or after restoring that backup ?

Volker.

[allin-in-one]

CMS error happen on the SOURCE disk after the backup has run

[Volker Halle]

Please look at the DIR/FULL output before/after 'backup'.

Are you by chance opening the file with using 'readonly' mode ?

Volker.

[allin-in-one]

yes, we are opening the file with using 'readonly' mode.

[Volker Halle]

Please compare the DIR/FULL output from before and after your backup.

Volker.

[allin-in-one]

Did not find any difference between  DIR/FULL output from before and after backup.

Thanks.

[Volker Halle]

If you run a BACKUP/IMAGE of the disk or just a BACKUP of the CMS library to the NULL device, do you see the same problem afterwards ?

$ BACKUP DISK1:<CMS.LIB...> NLA0:x.x/SAVE

Did you repair the -CMS-E-NOTBYCMS error using CMS VERIFY/REPAIR ? Does the error show up again after the /REPAIR ? Or does the error only show up again, after you've run your backup application ?

I've seen a couple of those errors on a CMS library, after the disk has been copied with BACKUP/IMAGE during a migration from a real Alpha to the CHARON-AXP emulator. These errors disappeared after a CMS VERIFY/REPAIR.

During the VERIFY/REPAIR phase, the messages printed are:

%CMS-I-FIXHDR, file header of element data file DISK1:<xxx..CMSLIB.CMS$000>xxx.xxx;1 repaired

This seems to indicate, that data in the 'file header' had to be repaired. If DIR/FULL does not show any differences, maybe DUMP/HEADER/BLOCK=COUNT=0 does ?

Does DIR/DATE=ACCESSED on the CMS element file report any time values ?

Volker.