error activating image CMA$TIS_SHR

[Markb2117]

My operational system is still on V7.1-2  but the developement system is currently unavailable. So I made the updates on a V8.2 sytem, copied the executable across and it worked. Great.

I then tried a few more programs, some worked, others failed with

%DCL-W-ACTIMAGE, error activating image CMA$TIS_SHR
-CLI-E-IMGNAME, image file $1$DKA0:[SYS0.SYSCOMMON.][SYSLIB]CMA$TIS_SHR.EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
$ dir/dat $1$DKA0:[SYS0.SYSCOMMON.][SYSLIB]CMA$TIS_SHR.EXE

Directory $1$DKA0:[SYS0.SYSCOMMON.][SYSLIB]

CMA$TIS_SHR.EXE;1    12-AUG-1998 15:24:47.13

On V8.2 the link maps have the line

CMA$TIS_SHR     V3.15-113               0 [CDDSLIB.DDS.BUILD]CMA$TIS_SHR.EXE;1 12-AUG-1998 15:24  Linker A11-39

and the option file

[]LIBRTL.EXE/share
[]CMA$TIS_SHR.EXE/share

$ dir/dat CMA$TIS_SHR.EXE

CMA$TIS_SHR.EXE;1                                         91  12-AUG-1998 15:24:47.13

I guess the option file is a previous attempt to solve the problem.

All the code is basic 'C' with calls to LIB$ and SYS$ routines.

I could understand it if all programs failed, but not that some work. I can not spot any major difference between the link maps.

Any ideas how I can always get a working exe?

[Bob Blunt]

Mark, OpenVMS is incredibly forgiving but at some point, IMHO, your luck runs out.  Personally I've never had much luck trying to execute any image I built using a higher version of the O/S when I move it back to a previous release, and certainly not a major release older.

One thing I noticed?  CMA$TIS_SHR isn't the problem, something else it links with is the problem.  There will definitely be execlets, sharable images and other bits that get munged into the cuisinart of your build from V8.1 that aren't available on V7.1-2 so I'm surprised you had much luck running any of your images.  From what I've seen you'd have to go to extreme pains to explicitly and specifically guarantee that all the components involved in your build for V7.1-2 are in place if you build on any other version and that (again, IMHO) is no guarantee that you'll be 100% successful.  Some code is SO strapped to specific versions that you can't run it anywhere else and without the entire source library you can't rebuild for newer versions at all.

There are some other games you can use to help.  Installing older compiler versions (if possible) on newer VMS releases, bringing specific sharable images for your build, etc.  There are just some things that you can't overcome so I generally try to stay within the same major release (in your case some V7 release).  Success can also depend heavily on the nature of your application.  The more your code uses OpenVMS internals the more likely that you're going to have trouble changing versions.  Device drivers, for instance, don't cross version boundaries easily and some may require code mods and rebuilding to work correctly.

bob

[H.Becker]

From what you show, it should work. But you don't show all the images which depend on CMA$TIS_SHR. DECC$SHR and DPML$SHR are some of them. With a C source you usually get them both. But I don't see them in your linker options, so the linker may have taken them from SYS$LIBRARY of the V8.2 system.

I'm sure this was already covered somewhere in this forum. Have a look at the Linker Manual and what it says about the logical ALPHA$LIBRARY: The linker uses this logical name when creating an OpenVMS Alpha image to locate the target system's shareable images and system libraries. That is, make a copy of the V7.2-1 SYS$LIBRARY directory, place it on the V8.2 system and for your link commands, let ALPHA$LIBRARY point to that directory. That should do it.

[Hoff]

Whatever the rationale for the continued use of V7.1-2, V8.2 and similiarly old releases, well, the bill just came due.  This bill always comes due, after all.  But you know that.

You will want to look at how to back-link or back-build stuff using the OpenVMS linker (this approach is unsupported, and does variously fail), and the V8.2 to V7.1-2 target version range involved here is a particularly long window to attempt back-link across, and arange that involves attempting operations across significant updates to DECthreads and the C libraries.

You will want to relocate and reference old shareable images as part of your build environment (minimally), and there can also be missing missing system services and itemlist constants and related features.

The C language implementation on OpenVMS has additional requirements, as the compiler (also) looks at the shareable image, so you have to ensure both the compiler and the linker reference the old shareable image.

See:

http://h71000.www7.hp.com/wizard/wiz_2932.html

Also se the CMA$TIS_SHR and related discussions here:

http://h71000.www7.hp.com/commercial/c/docs/rtc_i.htm

http://h71000.www7.hp.com/wizard/wiz_3230.html

(This is a common image activation error, based on something unsupported but commonly attempted, and correspondingly commonly reported; Google will be your friend here.)

There's probably some application software stuff on the Freeware that back-links, so there are likely some build procedures you can look at.

The "best practices" or "production" approach is to upgrade the production server to a version and patch level that matches your development server, or to downgrade the development server to a matching version and patch level, or to preferably test and upgrade both servers to OpenVMS Alpha V8.3 with matching patches, or to an analogous recent version; to a "recent" version of OpenVMS Alpha.  Otherwise, you're almost certainly going to be chasing weirdnesses, and you're definitely going to be increasing your testing efforts, and you're particularly going to have to test on your "production" server.

[John Gillings · Accepted solution]

Mark,

   CMA$TIS_SHR is involved in managing thread reentrancy of the C run time library (TIS = Thread Independent Services). Its activation depends on exactly what your program calls and how. Chasing the fine details probably isn't worth while.

  One approach to back linking is to make the V7.1 images available on the later system and link against them. In simplest terms, copy the V7.1 image to V8.2 and define a logical name pointing to it:

$ DEFINE CMA$TIS_SHR yourdev:[yourdir]V71_CMA$TIS_SHR.EXE;

(the trailing semi colon is important to bypass known image activation). Similarly for any other images your program depends on. This will work as long as the linker doesn't have a dependence on the later versions of the same images (in which case you may get around it by using the V7.1 linker as well).

You may end up having to iterate copying candidate images back several times before you get everything in place.

The other way around the issue is to compile everything on V8.2 and link everything on the target system. Sure, that's using your production system for "development", but it's not much different from retrying numerous image, and you can't do any kind of meaningful testing on the V8.2 system anyway. Consider it a cost of sticking to an ancient version.

There's a command procedure called IMAGETREE.COM which was on the freeware a while ago. It can dump the image dependence tree so you know which images you need to account for. I don't have a version here which I can be sure will work that far back.

[Markb2117]

John,

I followed your sensible advice of linking on the target machine.

Thanks