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

[Hein van den Heuvel]

Looks like you'll need SET WATCH/CLA=ALL

I grabbed a copy of CONVERT in tmp.exe
Patched it to read CONVVVV instead of CONVSHR
$define convert --> tmp.exe

With SET WATCH FILE/CLA=MAJOR

%XQP, Thread #0, Access TMP.EXE;10 (26263,3215,0) Status: 00000001
%XQP, Thread #0, Control function (26263,3215,0) Status: 00000001
%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, Deaccess (26263,3215,0) Reads: 3, Writes: 0, Status: 00000001
%DCL-W-ACTIMAGE, error activating image CONVVVV

So I do get the rigth image listed, but the actually File-Not-Found (0910) did not give details.

Now with CLASS=ALL.
$CONVERT...
:
blah blah
:
%XQP, Thread #0, Read only directory access (2577,1,0)
%XQP, Thread #0, Directory scan for: CONVVVV.EXE;0, Status: 00000000
%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, FIB contents:

And there it is clearly identified, early on before the final status.

$SET WATCH FILE/CLA=NONE

fwiw,
Hein.

[Art Wiens]

Here's /class=all - working:

[Art Wiens]

and /class=all - failing:

[Art Wiens]

Sorry:

and /class=all - failing:

[Hein van den Heuvel]

Seems that in the working case you activate ASGMENUY_V12.EXE;8 which then goes on to open LOGPARAM.DAT


In the failing case SGMENUY_V13.EXE;16 is activates which triggers activating ASGFNS_V13.EXE, which fails.

My next step would be to confirms with ANALYZE/IMAGE (Or just $dump/bloc=(star:2,coun=1)) that this 'functions?' shareable is indeed needed for V13, not for V12. And then check how ASGFNS_V13 is provided (logical, sys$share, ...)

The 7.3-2 versus 8.3 situation does not looks at all comparable to me.
You wrote "has been running for a long time"... V12 or V13?

Hein.

[Art Wiens]

The ASG software has roots back to ~1984. The ASG software is the underpinning of another couple of applications (basically all the RMS processing for them). ASG V11 has been running for 5+ years on VMS v7.2-2 (AS800's). ASG V12 (not in production) came about earlier this year in an effort to get everything running on VMS v7.3-2 on our new ES47's. A new version of BASIC was required and a few includes needed to be modified because of the introduction of BASIC$STARLET. It has been "working fine" for several months as well as the apps it supports. I've been trying to build ASG v13 since last week on VMS v8.3 (also on an ES47). I made no modifications to V12 to build V13, just created a duplicate directory structure of v12 and started with no objects, object libraries or executables. The v8.3 system disk was a backup of the v7.3-2 disk upgraded to v8.3 and patched.

Art

[Hoff]

Semi-random questions...

Is there any code built involving DECmigrate (VEST and/or AEST) anywhere here? (Yes, some references to TV stuff are normal.)

Are any of the applications built with C? If so, are there any writable sections involved?

Please post the output from SHOW LOGICAL ASG* /FULL, too.

[John Gillings]

Art,
Did you try defining your logical names /SYSTEM/EXEC? Does that make a difference.

I'm not necessarily suggesting you do that permanently, just to try it as a diagnostic.

[x2084 · Accepted solution]

From what I see in the output, ASGFNS_V13 SDA if is already mapped. At least to me it looks like the main image is linked against it. That can be checked with SDA, just before the lib$fis of ASGMENUY(_V13?).

It looks like activating ASGMENUY_V13 with lib$fis triggers an access to ASGFNS_V13 and ASGFNS_V13 can't be found. The message says,it can't be found in VMSTA1$DKC0:[SYS0.SYSCOMMON.][SYSLIB]. Aren't there logical names with 'disk/directory/filename/extension'? If there are, SYS$SHARE shouldn't show in the message.

Is it possible that ASGFNS_V13 is listed in ASGMENUY_V13 as a shareable image? From what I understand, that should not be the case, it should depend on ASGFNS and a logical should point to ASGFNS_V13. But that would explain why it isn't found, in VMSTA1$DKC0:[SYS0.SYSCOMMON.][SYSLIB], as the message says.

I would double check the dependencies in the images and the logicals. There is a tool SHIML on the last freeware CD. It may help to list all the dependecies. The tool isn't perfect and that version is old, but it may be useful, here.

[Art Wiens]

Found it! When I copied over the V12 structure to V13, I searched and replaced occurences of v12 with v13. One of these files was an .OPT for linking menuy. In there, "someone" had commented out the proper reference to shareable ASGFNSRTL (which is a valid logical which points to ASGEXE:ASGFNS_V13.EXE) and replaced it with a hardcoded reference, but just ASGFNS_V13.

10 points goes to Hartmut for making me download Freeware v8, run SHIML and then think. It pointed out:

mcr []shiml asg$v13:[asgv13.asgexe]asgmenuy_v13.exe
recursive SHareable IMage dependency List (Alpha), version 1.0
[ -> Translated Logical Name ] [ - Required Match: ID [ / Actual Match: ID ]]
ASGFNS_V13 - MATALL: 0,0

-e-slt, sublist terminated, ASGFNS_V13 not found or other error

There is no logical for that string and how should it know? ... the ASGFNSRTL logical!

I checked back in v12 and it is also a hardcoded reference to ASGFNS_V12. The above SHIML error is also noted on the v12 executable. I'm not sure why it works there?!

Edited the .OPT, relinked v13 and all is well again.

The odd thing is it doesn't need to go to ASGFNS - the symbol it's looking for with Entry_s is one which _is_ in Image_s ie. ASGMENUY_V13.

Thanks everyone!! Another great learning experience in how things work!

Cheers,
Art

[x2084]

> The odd thing is it doesn't need to go to ASGFNS - the symbol it's looking for with Entry_s is one which _is_ in Image_s ie. ASGMENUY_V13.

Too late, lib$fis asks the image activator to activate ASGMENUY[_V13] which depends on ASGFNS, so the image activator has to activate both. If back, lib$fis will read the symbols only from ASGMENUY and find the symbol. It will not read the symbols from ASGFNS, because you asked only to lib$fis ASGMENUY[_V13].

[Art Wiens]

So can we say one difference between VMS v7 and VMS v8 is "stricter" image activator code?

Art

[Hoff]

The rule of thumb I apply for cases such as this is that my code is broken until and unless I can prove that the OpenVMS code is broken. I might well go to some effort to prove that other code -- HP or layered product or third-party or such -- is broken, too, as that effort reduces the "squirm room" for the support organization, and it speeds my ability to verify the fix.

If I made changes to my application code and was rebuilding a package -- even if I made no changes to the source code itself and was strictly rebuilding the code -- I'd not (initially) be looking to point at OpenVMS. Here, you'd indicated a reference to a shareable image was missed.

Sure, OpenVMS Engineering breaks OpenVMS itself from time to time, and there have been cases where rules-checking gets tightened. But from where I sit in my comfy chair here in the 'labs, this looks like your changes that triggered this.

The OpenVMS lib$find_image_symbol (lib$fis) and the OpenVMS image activator in general are not good at reporting errors, not the least of which because there's often either no quota or no error reporting path available. Could the original design of the image activation code involved here have been better? Sure... But that's water under the bridge... And your code referenced a shareable that wasn't found during the activation, and OpenVMS did tell you that...

Without intending any offense, I'd set this case on your doormat, and not on the image activator. Not that the image activator isn't a favorite doormat of mine. :-)

[Art Wiens]

"this looks like your changes that triggered this"

I guess one get's lulled into a sense of security when things have "worked for a long time". And even after a "major upgrade" (new hardware, VMS v7.2-2 -> v7.3-2 and application code changes) it still "worked" ... only when I went to VMS v8 did it break. I don't disagree that it is the application's problem, but the view from 10,000 feet seemed to point at VMS.

"Without intending any offense, I'd set this case on your doormat, and not on the image activator"

None taken. I also didn't mean to disrespect/doubt VMS!! I did have a nagging feeling that it was how the app got linked but I was thinking it was more of which object got linked (or didn't get linked) into which executable.

Onto the main app compiling/linking!

Thanks again all!

Cheers,
Art

[John Gillings]

Art,

Regarding image activator "strictness"...

In general, the image activator requires an exact match for everything in order to believe two images are the same. So, even if two filespecs map to the same physical file, the image activator won't always consider them the same file (in particular when activating known images).

When dealing with shareable images, it's a good rule to always refer to the image by logical name in all places (including OPT files, compile, LINK, and INSTALL commands).

I don't believe this behaviour has changed for a long time (if ever), but if you strictly use logical names you won't exercise those "features" of image activation, so won't be affected.

Something I remember from a LONG LONG time ago, V4 days, which (hopefully) isn't still true...

When your runtime shareable image file name can vary, it's sometimes necessary to toggle logical names prior to the link. So, in your case the "base" image name is ASGMENUY, but actual image name may have "_Vnn" tacked on the end. It may help to have a dummy image called ASGMENUY which defines the correct transfer vector and GSMATCH, against which your images are linked. Redefine the logical name to point to ASGMENUY_V13 (or whatever) at run time.

Easy to check, use ANALYZE/IMAGE against your main image to see if the shareable image reference is to the logical name, or the actual name of the image at the time of the link. This would be relevant to your case if the image you're activating with LIB$FIS was also statically linked, and it was important that they map to the same physical image.