- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Error activating image ...
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
тАО05-26-2010 04:08 AM
тАО05-26-2010 04:08 AM
$ DISPO_RETOUR :== $KLS$SYSTEM:SIN$DISPO_RETOUR
$ DISPO_RETOUR SO_AUS_NN
%DCL-W-ACTIMAGE, error activating image TPSHR
-CLI-E-IMGNAME, image file DSA0:[TPLIB]TPSHR.EXE;5
-LOADER-E-BADIMGOFF, image offset not within any image section
This is mystery to us, because the image DISPO_RETOUR runs with different input parameters without any error messages. And the shared library TPSHR is ativated by nearly every image from the batch procedure - also without any error message.
There are also the following messages:
-LOADER-E-BAD_DYNTBL, image format error - illformed dynamic table
or
-LOADER-E-BADIMGRELA, unexpected rela type for image
The errors occurs very rarely. However only in our midnight job - which terminates abnormally.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-26-2010 05:25 AM
тАО05-26-2010 05:25 AM
Re: Error activating image ...
I'd also check constituent shareable images, just for completeness.
Check process quotas. When the process quotas are insufficient, the image activation process can be unable to generate decent error messages.
Check that you're current on patches. (There were some bugs in older I64 linkers.) If you're not on V8.3-1H1 with fairly recent UPDATE patches, get there. If you're on anything prior to V8.3, upgrade.
Make sure you're invoking the same image that you've installed, if you have the image installed. (Adding a version number onto an invocation will bypass the installed image processing, and you might be activating a different version of the image depending on how you've specified the invocation.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-26-2010 05:36 AM
тАО05-26-2010 05:36 AM
SolutionEssentially, at the time the image activator needs to relocate or fixup TPSHR, it finds an offset which is not in any image segment (or section if you prefer pre-I64 terminology) of the shareable images activated so far. This offset was read from the "dynamic table". Later, when reading the "dynamic table" the image activator encounters an illegal relocation type. So the image activator reports that something is wrong with or in the "dynamic table".
The dynamic table is part of the image file. It is usually read at activation time and brought into memory. If this "occurs very rarely", something else is going on. So this is very likely no problem in the image activator.
Running with different input parameters may obly be realated, if the image is activated via lib$fis. But that's not the case as you see the %DCL-W-ACTIMAGE.
Although these questions were already asked (and maybe answered in the mean time):
Is the image installed with /header? If it is, how?
As a workaround, I would try to install it /shared=addr. This may not be possible and/or may require more images to be installed that way.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-26-2010 05:37 AM
тАО05-26-2010 05:37 AM
Re: Error activating image ...
>> This is mystery to us, because the image DISPO_RETOUR runs with
>> different input parameters without any error messages
You mean to say that only when you pass a parameter of "SO_AUS_NN", you
are getting the "DCL-W-ACTIMAGE" messages. But with other input parameter
the program works fine.
What does the program do differently when provided with "SO_AUS_NN" as
the input parameter.
Regards,
Murali
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-26-2010 05:46 AM
тАО05-26-2010 05:46 AM
Re: Error activating image ...
That would be user writable memory right?
Klaus>> DISPO_RETOUR runs with different input parameters without any error messages.
My guess is that this input values cause some table/pointer to overflow and that a subsequent semi random happens to stomp on this table, setting that up for failure when it is (re)used.
This could be a tedious debug process, and yo may need process dumps.
Hmmm, of you could figure out how to find that table when you may be able to see a before and after image and spot what might have caused it.
It may be more productive to check that 'special value' to try to figure out what makes it special. Does it correspond with more 'objects'/'things'? fewer? zero? does it invoke object that have errors? along those lines...
fwiw,
Hein
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-26-2010 06:02 AM
тАО05-26-2010 06:02 AM
Re: Error activating image ...
Not really: there is no "user code" running at that time. This is at activation time, no command line input was processed, yet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-26-2010 06:07 AM
тАО05-26-2010 06:07 AM
Re: Error activating image ...
Hartmutt> Not really: there is no "user code" running at that time. This is at activation time, no command line input was processed, yet.
Right, but I had thought that the table would be used later on as well, but if it is only used for/during the fixups? Maybe LIB$FIS goes back to it? Dunno right now.
Klaus, is TPSHR linked with the images, or are the functions in TPSHR activated through LIB$FIND_IMAGE_SYMBOL?
fwiw,
Hein
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-26-2010 07:02 AM
тАО05-26-2010 07:02 AM
Re: Error activating image ...
Nope. The dynamic table or dynamic segment is only for the image activator. This segemnt is generated at link time. There is nothing in any object pointing to it. Nobody else knows where it is. (In case the image is not installed /header, the image activator deletes this process section after it is done with it.)
In my point of view, the DCL message excludes lib$fis, here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-26-2010 10:11 AM
тАО05-26-2010 10:11 AM
Re: Error activating image ...
H.Becker>The errors are very rarely - but in the night. So we got an emergency call.
What is lib$fis?
The image and the shared library is not installed.
What do you mean with "install it /share=addr"? Install the image "DISPO_RETOUR" or install the shared library TPSHR?
P Muralidhar Kini>No. The problem is not the parameter.
Hein>TPSHR is linked and not activated through LIB$FIND_IMAGE_SYMBOL.
@All>The problem is not only with the shared library TPSHR. There are two other shared libraries
We had no problem on Alpha. We just "compile and link" ported our system. Is there any hint in building shared libraries on IA64?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-26-2010 10:30 AM
тАО05-26-2010 10:30 AM
Re: Error activating image ...
H.Becker>The errors are very rarely - but in the night. So we got an emergency call.
>What is lib$fis?
shorthand for lib$find_image_symbol. Also often used to refer to the dynld stuff (dlopen, etc) in the C RTL, which is based on the same mechanisms.
>The image and the shared library is not installed.
>What do you mean with "install it /share=addr"? Install the image "DISPO_RETOUR" or install the shared library TPSHR?
If it's not installed, then you can ignore the INSTALL command options here including /SHARE=ADDR
It can be inferred from the file names that different languages might be in play. Is the code using different VMS language settings or locales or different C settings in the different environments?
I'd suggest ringing up HP support. They'll probably want the most recent UPDATE kits and such loaded, of course.
And definitely check for marginal quotas, and other differences in the run-time environments; logical names and quotas can cause weird errors, and the C run-time environment is a forest of subtlety. And batch processes and interactive environments can also have quota differences.
The BADIMGOFF stuff was classically exec images; I don't know if that stuff has changed. (Hartmut would.) Are these images execlets or privileged? (The help here points to the potential use of the LOAD_SYS_IMAGES system parameter for cases of BADIMGOFF code involving Alpha. Might be stale help text, too; this is OpenVMS Alpha V8.3 text I'm looking at.)