- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shar...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-04-2010 09:32 AM
тАО06-04-2010 09:32 AM
SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
$ 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:
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-04-2010 09:45 AM
тАО06-04-2010 09:45 AM
Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-04-2010 09:46 AM
тАО06-04-2010 09:46 AM
Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-04-2010 10:19 AM
тАО06-04-2010 10:19 AM
Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-04-2010 10:36 AM
тАО06-04-2010 10:36 AM
Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-04-2010 10:46 AM
тАО06-04-2010 10:46 AM
Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-04-2010 10:50 AM
тАО06-04-2010 10:50 AM
Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
Thanks for all the help!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-04-2010 11:20 AM
тАО06-04-2010 11:20 AM
Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-04-2010 06:56 PM
тАО06-04-2010 06:56 PM
Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
>> $ 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-05-2010 12:14 AM
тАО06-05-2010 12:14 AM
Re: SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
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.