topic INSTALL REMOVE problem in Operating System - OpenVMS

INSTALL REMOVE problem

Willem Grooters — Wed, 09 Jun 2004 04:56:18 GMT

I encountered the following problem:

INSTALL LIST revealed I have an image installed twice, from different locatins:

DISK$NOD_RAIDB:.EXE
LFMEM;1 Open Shar Lnkbl Wrt

DISK$NOD_RAIDB:.EXE
LFMEM;1 Open Shar Lnkbl Wrt

I can remove one of them (done by a procedure, but this just tells to remove LFMEM:
...
$ install delete lfmem
...

but just that one is removed:

DISK$NOD_RAIDB:.EXE
LFMEM;1 Open Shar Lnkbl Wrt

The other one is kept in memory, and cannot be removed since it doens't exist any more (location has been moved):

LIS_MGR> install remove DISK$KENA09_RAIDB:lfmem.exe
%INSTALL-E-OPENIN, error opening DISK$NOD_RAIDB:LFMEM.EXE; as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file
%INSTALL-W-FAIL, failed to REMOVE entry for DISK$NOD_RAIDB:LFMEM.EXE;
-RMS-E-DNF, directory not found

So what I did was re-create directory and copied the file (from it's new location) to this directory - but alas, it didn't work:

LIS_MGR> install remove DISK$NODE_RAIDB:lfmem.exe
%INSTALL-W-FAIL, failed to REMOVE entry for DISK$KENA09_RAIDB:LFMEM.EXE
-INSTALL-E-NOKFEFND, Known File Entry not found

Same with INSTALL REMOVE LFMEM

* am I right that VMS just keeps the file-id - and not the name? That would explain why I'm not able to get the entry off the list...
* Is there a way to remove the entry without rebooting the system? (Could think of keeping a copy of the executable (to be isntalled), rename the right version to the 'wrong' directory)

Willem

Re: INSTALL REMOVE problem

Willem Grooters — Wed, 09 Jun 2004 05:24:45 GMT

Some addition - scrolling down the session log, I found something I remembered happening when removing the file-entry

LIS_MGR> install remove lfmem

KENA09_LIS_MGR_09> install remove lfmem

%INSTALL-E-OPENIN, error opening DISK$NOD_RAIDB:LFMEM.EXE; as input
-RMS-E-FLK, file currently locked by another user
%INSTALL-W-FAIL, failed to REMOVE entry for DISK$NOD_RAIDB:LFMEM.EXE;
-INSTALL-E-NOKFEFND, Known File Entry not found

But show dev/files does not reveal who has it locked:

00000000 [LIS.XFE.LIST_COMM.EXE]LFMEM.EXE;1

note: this file is not installed at this point.

Willem

Re: INSTALL REMOVE problem

Uwe Zessin — Wed, 09 Jun 2004 05:45:36 GMT

Willem,
can't you move it temporarily back to the old location? Even when the file has been 'deleted', the header is still locked and you should be able to retrieve it with:
$ ANALYZE /DISK_STRUCTURE /REPAIR

Re: INSTALL REMOVE problem

Jan van den Ende — Wed, 09 Jun 2004 07:27:29 GMT

Ha Willem,

Nice application, isn't it?
Just try and make it run on multiple nodes of the cluster!.
First: show dev/fil DOES show who has it locked: 00000000, which means it is installed!.
And now, why can't you de-instal? Currently lockeced?
Then INSTAL SHOW file /FULL should show that is still is accessed.
(Current /max accessed non-zero for current).
This can happen, if the image was still accessed during your de-install. Then your de-install will be pending until the last access finishes.
LFMEM by the way is a sharable writeable image section, so maybe one of your referencing programs (various LFxxx processes) which was loaded ( = LFMGR STARTed) when LFMEM grouplogical still referenced THIS file, is still around.

If this LIST is not currently the production instance, carefully check ALL LFxxx processes, and kill the ones that have this group-UIC (killing LFMAN will get rid of its subprocesses, killing the subprocesses will have them immediately restarted by LFMAN).
IF the last referencing process is gone, then either the INSTAL REMOVE will finsish, or, if it acually refused to begin deinstall, then you will now be able to de-instal. (that is, if my experience with similar situations on other images is also valid for this sharable writeable section; I can't remember this issue with exactly this image...)

hth,

jpe

Re: INSTALL REMOVE problem

Willem Grooters — Wed, 09 Jun 2004 15:02:12 GMT

Jan,

I could have guessed that you know the application (for the outer world: some middleware for data exchange)
It was stopped completely, no LF* processes left, ans the 'valid' LFMEM out of memory. Just this one was left.

Uwe, I don't know whether this is still possible. The system (over which I have no control) can have been rebooted this morning early so the problem has then be 'solved', but I can try this on our own system.

Willem

Re: INSTALL REMOVE problem

David B Sneddon — Thu, 10 Jun 2004 02:52:31 GMT

Willem,

What I have managed to do in the past when
installed images are deleted before removing
them is to copy the image back to where it
is supposed to be, "install replace" which
will install the version you have just copied
then "install remove" to get rid of it.

Dave

Re: INSTALL REMOVE problem

John Gillings — Thu, 10 Jun 2004 20:39:57 GMT

Willem,

INSTALLed images are a huge potential security hole in OpenVMS, so the INSTALL utility is highly paranoid about files and file names. You really need to use *precisely* the same file name to manipulate installed images. Having the same image name for two or more images can also be a problem.

Best practice is to always define a /SYSTEM/EXEC logical name for any image to be installed and ONLY use that logical name with INSTALL

$ DEFINE/SYSTEM/EXEC LFMEM fullfilespec
$ INSTALL ADD LFMEM/qualifiers
$ INSTALL REMOVE LFMEM

This can cause trouble if you want two images with the same name installed. Best way around that is "don't" ;-) RENAME any duplicates and use group or process logical names to resolve them for processes that need to see the alternates.

Dave Sneddon's suggestion is probably the best way to clean up the situation you're in now, but it may still leave you with a delete pending section.

Re: INSTALL REMOVE problem

Jan van den Ende — Fri, 11 Jun 2004 02:34:12 GMT

John,

I think you have the right arguments to do things right, but...

In this case we inherited some 'fine' gimmics of those who could do something on VMS but did not REALLY understand things.
The applic uses a lot of Progress-supplied stuff, and THAT ended support 1 jan 2001, so absolutely NO way to change that. (And before that time I tried very hard, but the original authors had long left, current staff did not fully understand the complexities, and management didn't care, because all this stuff was to be replaced before end of 2000 anyway. Moving the logic to *IX, with M$ frontend, has proved to lead to some delay, however).
This specific LFMEM sharable writable image section HAS to be installed, the logical name HAS to be /GROUP, and it usually has multiple occurrences in a number of different groups! (and this DIFFERENT group-UIC requirement is CLUSTERwide!).
And to be able to use the associated communication any user MUST have the corresponding group-UIC, which MUST be different on different clusternodes, and for different instances.

NOW do you understand why I called it a "nice application"?

BTW.: the applic is VITAL for the organisation. Running 7 * 24, any interruption leads to escalation and requires explanations.

But what fun in life without some challenges, eh?

Jan

Re: INSTALL REMOVE problem

Ian Miller. — Fri, 11 Jun 2004 04:43:34 GMT

These references may also be of interest
http://h71000.www7.hp.com/wizard/wiz_3768.html
http://h18000.www1.hp.com/support/asktima/operating_systems/CHAMP_SRC940317006594.html