Operating System - OpenVMS
1748122 Members
3404 Online
108758 Solutions
New Discussion юеВ

Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

 
rbarlow
Occasional Advisor

SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

We're getting an error on one of our Alphas trying to run the Compaq Language-Sensitive Editor (LSE).

$ lse
%DCL-W-ACTIMAGE, error activating image TRACE
-CLI-E-IMGNAME, image file BCQA6$DKA0:[SYS0.SYSCOMMON.][SYSLIB]TRACE_V73.EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

I've confirmed that the TRACE image is installed and the EXE is in the correct directory.

$ install list trace

DISK$ALPHASYS:.EXE
TRACE_V73;1 Open Hdr SharAddr Lnkbl

I've read that this error can occur when when an executable is build and link with a shared image that is newer than the one that is installed, but I'm not sure how to troubleshoot this since it is not a home grown application (its part of HP DECSET).

My next course of action was to try to reinstall DECSET to see if that fixes the problem, but I figure I would check here to see if anybody has any suggestions.
10 REPLIES 10
Hein van den Heuvel
Honored Contributor

Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

Did it ever work?

Surely you are being snookered by a 'helpful' logical.

Check $ SHOW LOG TRACE

It is pointing to TRACE_73.EXE
Why?

Try undefining it or over-ruling it

$ DEFINE TRACE SYS$LIBRARY:TRACE.EXE;

I added the semicolon there to make sure there is no confusion with an installed image.

Try this way first, then try without the semicolon.

Actually first I would try

$ DEFINE TRACE SYS$LIBRARY:TRACE.XXX;
This _should_ fail reporting file not found on the XXX, ten fix to EXE
By seeing the specific failure firt you will know for sure that your logical is being followed.

Hth,
Hein
Hoff
Honored Contributor

Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

OpenVMS Alpha V7.3? Is that release below the supported minimum version of VMS supported by LSE and DECset? V7.3-2 is the landing zone, so that's the most likely target for "newish" versions of DECset.

The usual trigger for a shareable image mismatch is for an image that's too old, not too new. And V7.3 is ancient.

Which version of DECset?

What are the version requirements for that release?

And that TRACE_V73 nomenclature screams "somebody locally has been messing around with the shareable images", and implies that there's probably also a TRACE logical name defined, and that the V7.3 image is some sort of a workaround that somebody's implemented. And that can certainly trigger this stuff.

As a test, define the logical name TRACE in your process, and aim it at the SYS$SHARE:TRACE.EXE image.

DEFINE/JOB TRACE SYS$SHARE:TRACE.EXE

Then try LSEdit.

BTW: posting the product versions? Good idea. Speeds the response for you by reducing the iterations needed.
rbarlow
Occasional Advisor

Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

Thanks for the quick replies! Sorry for not including version info, its been a busy week and I'm kind of brain dead (TGIF!).

OpenVMS 7.3-2
DECset 12.8 ECO1
LSE 5.1-1

I'm not sure if it was working before, the server used to be an R&D box for somebody and then it was turned into a QA server. I believe it was recently upgraded from OpenVMS 7.3-1 to 7.3-2. This is the first time I've been involved in it.

It looks like there are multiple versions of TRACE on this server:

$ dir sys$share:*trace* /size/date

Directory SYS$COMMON:[SYSLIB]

TRACE.EXE;1 1003 27-SEP-2006 09:26:42.06
TRACE.EXE_OLD;1 880 1-OCT-2003 21:17:39.58
TRACE_V73.EXE;1 1099 14-JAN-2004 18:13:11.34
TRACE_V73.MAP;1 1170 14-JAN-2004 18:13:10.66

The current logical is:

$ show log trace
"TRACE" = "SYS$SHARE:TRACE_V73.EXE" (LNM$SYSTEM_TABLE)

I tried your suggestion of redefining the logical with an incorrect extension and got this:

$ define trace sys$share:trace.xxx;
%DCL-I-SUPERSEDE, previous value of TRACE has been superseded
$
$ lse
%DCL-W-ACTIMAGE, error activating image TRACE
-CLI-E-IMAGEFNF, image file not found BCQA6$DKA0:[SYS0.SYSCOMMON.][SYSLIB]TRACE.
XXX;

I tried changing the logical to use the TRACE.EXE instead of TRACE_V73.EXE and got the following:

$ define trace sys$share:trace.exe;
%DCL-I-SUPERSEDE, previous value of TRACE has been superseded
$
$ lse
%IMGACT-F-SYMVECMIS, shareable image's symbol vector table mismatch
-IMGACT-F-FIXUPERR, error when LSEDIT referenced LSESHR

Changing the logical back to what it was originally resulted in the same error message as before.
Robert Gezelter
Honored Contributor

Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

rbarlow,

Rather than defining the logical, I suspect the preferable option is to deassign the TRACE logical. The location for shareables defaults to the image name in SYS$LIBRARY, which is where the files actually are (the logical changes the name).

- Bob Gezelter, http://www.rlgsc.com
Hoff
Honored Contributor

Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

Nuke and pave, dude. Nuke and pave.

This stuff is not worth chasing.

Wipe the disk. Load fresh software bits.

If anything, that's also a central benefit specific to a Q&A box, as a selection of prepared disk images (what you get between installing VMS and the LPs and before you load your own software) makes for a far more repeatable and flexible environment. Save off a selection of copies of these images (as BACKUP savesets on a disk or InfoServer service) or (gag) tape, and you can immediately launch a test environment.

Spending more time than I should doing grunt work for your problem, your version of DECset LSEDIT 5.1 is from 2005, and is supported on V7.3-2 minimally.

VMS error messages are something you're going to want and need to know how to read in some detail, particularly if you're going to be programming on VMS. Stuff like the common ACCVIO diagnostics provides a wealth of information, too. And those same diagnostics (and the condition- and signal-handling) are key to creating robust application code. You've got a good start here with resolving the File Not Found error from the (bogus) logical name.

The User's Guide is the launching point for learning VMS, followed (if you're using LSEDIT for programming) the Programming Concepts manual and the language-specific manual(s) for whatever language(s) you're working with. The documentation shelves for most products including VMS itself are here:

http://www.hp.com/go/openvms/doc

And have a look around for a patch kit for OpenVMS Alpha V7.3-2, as there's almost certainly an UPDATE kit for it. If there's an endemic problem with TRACE, then the patch kit for a release this old will contain the fix.

Patches are here:

ftp://ftp.itrc.hp.com

$ DIRECTORY/FTP/ANONYMOUS ftp.itrc.hp.com::

$ DIRECTORY/FTP/ANONYMOUS ftp.itrc.hp.com::"quote remote directory stuff here"

Eventually:

$ COPY /FTP /BINARY /ANON ...

You're looking for the most recent UPDATE kit, as a start.

I don't have the release dates handy to confirm that the TRACE image you're referencing is the one that shipped with V7.3-2, but this box is already highly suspect, and who knows what's going on here. Nuke and pave, dude.
rbarlow
Occasional Advisor

Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

Ahh I was hoping to avoid the clean sweep but it is probably the best option in the long run in order to get the system the same as the other ones.

Thanks for all the help!
Hoff
Honored Contributor

Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

Here's the effort that can be involved with changing node names on VMS...

http://labs.hoffmanlabs.com/node/589

This based on an obvious potential course of action here involving rolling in a different disk image; of replicating an existing system disk, rather than a fresh install.

And if you're running an active Q&A effort and decide to go for the archives of various versions, the V8.3 InfoServer stuff is massively handy. It's also useful for a fast replication or recovery of a production server, but that tends to be less often than your average Q&A effort wants to reset its version.
P Muralidhar Kini
Honored Contributor

Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

Hi rbarlow,

>> $ dir sys$share:*trace* /size/date
>>
>> Directory SYS$COMMON:[SYSLIB]
>>
>> TRACE.EXE;1 1003 27-SEP-2006 09:26:42.06
>> TRACE.EXE_OLD;1 880 1-OCT-2003 21:17:39.58
>> TRACE_V73.EXE;1 1099 14-JAN-2004 18:13:11.34
>> TRACE_V73.MAP;1 1170 14-JAN-2004 18:13:10.66

What is the file "TRACE.EXE_OLD;1" ?
Was it by any chance the working version of the file ?
May be, as it was a R&D box before, somebody renamed and keep the acutal
TRACE.EXE file file aside and then copied new version of the file,
for whatever reason.

You can try changing the logical to point to the TRACE.EXE_OLD;1.
Try this,
$ copy trace.exe_old;1 trace.exe;10 (any version number, i just chose 10)
$ define trace sys$share:trace.exe;10
$ lse
Does it work ?

Remember, if this does does not work, then later delete the trace.exe;10 file.

Let us know whether that works or not.

Regards,
Murali
Let There Be Rock - AC/DC
Volker Halle
Honored Contributor

Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

rbarlow,

TRACE.EXE 27-SEP-2006 09:26:42 is the version shipped in VMS732_DEBUG-V0100 and VMS732_TRACE-V0300. Later superseeded in VMS732_DEBUG-V0200 (link date 15-AUG-2008 10:03:51). This IS the right version to be used on OpenVMS Alpha V7.3-2 !

TRACE.EXE_OLD 1-OCT-2003 21:17 is most likely the OpenVMS V7.3-2 SSB version, renamed by installing the DEBUG or TRACE ECO kit (or the UPDATE kit).

TRACE_V73.EXE does NOT seem to be from any 'official' VMS ECO kit, so this is most suspect ! It may be from some OpenVMS engineering patch, why would it have a TRACE_V73.MAP file delivered with it otherwise ?

You should try the following:

- de-assign the TRACE logical
- install the correct image TRACE.EXE
- invoke LSE and troubleshoot any further problems, which would show up...

Volker.