LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

[Art Wiens]

I am compiling/linking code that has worked on v7.x for "a long time". The service in question is written:

PROCESS::Status_l = LIB$FIND_IMAGE_SYMBOL(Image_s,Entry_s,Entry_l)

After compiling/linking on VMS v8.3 (Alpha as well), when I run the application and it comes to this function, it gives %LIB-E-ACTIMAGE, error activating image ... and it says it can't find the exe in sys$library.

Image_s is the expected name of the exe although this name is a logical comprising disk/directory/filename/extension.

Entry_s is the expected name of the module to run.

The executable has never been in sys$library but yet this application works on v7.3-2, v7.2, v7.1-1h1.

I read the system service description and it would appear that this is how it should work - ie. if you don't supply the forth parameter for image-name it will look in sys$library. We're also apparently not in compliance because the filename is not a pure filename (has device and directory included). If I copy the executable in question to sys$library, the app works.

Could this service's behaviour have changed in v8.x?

Cheers,
Art

[Hoff]

Could? Sure. Did? Donno.

Source code of a reproducer?

SHOW LOGICAL of the filename?

What does SET WATCH show for this?

SYS$SHARE:*.EXE has been the documented default for eons, given "You can specify a file specification for the image name with the optional image-name argument. If you do not specify image-name, a default file specification of SYS$SHARE:.EXE is applied to the file name. If the file is not in SYS$SHARE:.EXE, a logical name must be used to direct this routine to locate the correct file." per the manuals.

All of which implies there was probably a logical name defined, and same is presently not defined within OpenVMS Allpha V8.3. Check your startup and your application environment, and make sure it's getting executed (and DEFINEd) as expected.

[John Gillings]

Art,

I'm not sure I understand exactly - the key is the Image_s parameter. Is it just a name "MY_IMAGE" or is it a full filespec?
"disk:[dir]MYIMAGE".

If it's "MY_IMAGE" and there is a corresponding logical name, which is apparently being ignored, then the best guess is something is causing the image activator to enter "paranoia" mode. A quick check would be to define the logical name /SYSTEM/EXEC. If that "fixes" the problem, you need to work out what's changed on your new system to make it paranoid.

Wild guess, perhaps the image protection is E rather than RE wrt the process activating the image? You also need to look at other images being activated. Anything with privilege or no READ access will turn on paranoia.

[Jon Pinkley]

According to the 82final documentation set, the first parameter can specify only the filename. Perhaps they have begun to enforce a rule that wasn't enforced before.

Does the image calling LIB$FIND_IMAGE_SYMBOL have a protected subsystem ACE? If so, at some time between 7.2-2 and 7.3-2 with patches, the image activator was changed to treat these images in the same manner as images installed with privilege, i.e. only trusted (EXEC or KERNEL mode) logical names are considered with sharable images linked with the application. I would expect the same rules to apply to LIB$FIND_IMAGE_SYMBOL. Since you said it worked in 7.3-2 this may not be the same issue I saw. What patches it any were in affect on your 7.3-2 system and do you still have this system available? And there is always the possibility that they plugged one security hole in the 7.3-2 timeframe and have since plugged another.

Is the shared image installed? Do the processes have read access to it?

Jon

From http://h71000.www7.hp.com/doc/82final/5932/5932pro_018.html

Format
LIB$FIND_IMAGE_SYMBOL filename ,symbol ,symbol-value [,image-name] [,flags]


--------------------------------------------------------------------------------

RETURNS

OpenVMS usage: cond_value
type: longword (unsigned)
access: write only
mechanism: by value



--------------------------------------------------------------------------------

Arguments
filename

OpenVMS usage: char_string
type: character string
access: read only
mechanism: by descriptor

Name of the file for which LIB$FIND_IMAGE_SYMBOL is searching. The filename argument is the address of a descriptor pointing to this file name string. This argument may contain only the file name. File type cannot be indicated. If any file specification punctuation characters (:, [, <, ;, .) are present, the error SS$_IVLOGNAM is returned.

You can specify a file specification for the image name with the optional image-name argument. If you do not specify image-name, a default file specification of SYS$SHARE:.EXE is applied to the file name. If the file is not in SYS$SHARE:.EXE, a logical name must be used to direct this routine to locate the correct file. Only logical names defined in the system logical name table with the /EXEC attribute will be considered while the image activator is processing a request from an image that was installed with privileges. If the calling image was installed with privileges, the image being activated and any shareable images or message sections it references must be installed as a known image with the INSTALL utility. Running an image to which you have only Execute (not Read) access results in the same restrictions on logical names and shareable images as does running a privileged image.

[Art Wiens]

The description of what the "filename" can/ should be is contradictory, but I guess I have to assume that a logical name is a valid parameter or else the last 15 years have been a sham!

Let me put together some "hard evidence" and I'll post it ... While doing this I realize that I have misrepresented my problem a bit. The trouble is it's a "reasonably large" application with many objects being linked together from different sources to produce the resulting exe's and called functions are most likely in a different place.

It's not the actual file specified by Image_s that it reports it can't find, it's another executable where a collection of functions are kept. If I spawn out just before the statement executes and show dev/files, I'm already accessing the exe it subsequently says it can't find.

Let me show you ... in a while.

Cheers,
Art

[Hoff]

{{"It's not the actual file specified by Image_s that it reports it can't find, it's another executable where a collection of functions are kept. If I spawn out just before the statement executes and show dev/files, I'm already accessing the exe it subsequently says it can't find."}}

If I understand this statement correctly, then it appears that the merged image activation itself is bombing out, and not specifically the lib$fis call itself.

File protections on the image and its constituent shareable images can be a factor, as can the run-time context of the image activation itself. Logical names such as SYS$ERROR are not defined in certain process contexts, and it is very easy to miss a logical name to a constituent shareable image.

This could well be a problem in lib$fis, but this could also be an error in the application code.

Try a "smaller" activations of known and specific images, and see if you can isolate this to all images in this environment, or just to your specific image.

Here are some sources of example code that might help you build a reproducer:

http://h71000.www7.hp.com/wizard/wiz_2486.html
http://www.eight-cubed.com/examples/framework.php?file=lib_find_image_symbol.c

[Hein van den Heuvel]

Ah yes,

Hoff's entry reminded me of an earlier note this year. See: http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1204873

Most importantly:

A couple more remarks from a friend in OpenVMS engineering:

"The image activator is not good at reporting problems when it is done with mapping all the images. Fixups are usually done after mapping all the images.
Then the name of the last mapped image is used to print error messages.
So the name SCRSHR may or may not be correct."

There SCRSHR was reported, but the problem was with Hypersort.

Still, In your case, a file-not-found would suggest an error during mapping, not before.

Maybe the real complaint was about a shareable one level down?

Say "MAIN" is linked with "SHR1" which is linked with "SHR2" which can not bye found. Did it report SHR1 where SHR2 was the culprit?

Does the SET WATCH FILE/CLA=MAJOR which Hoff suggested earlier provide any insight?

Hein.

[Art Wiens]

Coming up with the evidence is harder than I thought ... I will attach two files displaying the results when using SET WATCH/CLASS=MAJOR FILE, one running v7.3-2 (where it works) and v8.3 (where it fails).

Here's the working one:

[Art Wiens]

And here's the failing one:

[Art Wiens]

I really don't think it's file permissions per se, the exe's and the directories they are in have identical security settings between the previous and new versions.

The other "interesting" thing is if I setup my environment on the v8.3 session to access the previous version of the application, it fails the same way. Setting up the v7.3-2 session to access the new version of app fails with:

%DCL -W- ACTIMAGE, error activating image SORTSHR
-CLI -E- IMGNAME, image file $1$DGA300:[SYS0.SYSCOMMON.] [SYSLIB] SORTSHR.EXE
-SYSTEM -F- SHRIDMISMAT, ident mismatch with shareable image

so unfortunately that can't tell us anything.

I have compared logicals between the two sessions and the application related ones are also "identical" (other than one set referencing v12 of the app and the other v13).

Art