topic Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ? in Operating System - OpenVMS

LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Art Wiens — Thu, 17 Apr 2008 17:54:17 GMT

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

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Hoff — Thu, 17 Apr 2008 20:39:59 GMT

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.

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

John Gillings — Thu, 17 Apr 2008 20:58:15 GMT

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.

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Jon Pinkley — Thu, 17 Apr 2008 21:25:53 GMT

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.

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Art Wiens — Thu, 17 Apr 2008 21:55:18 GMT

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

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Hoff — Fri, 18 Apr 2008 17:41:06 GMT

{{"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

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Hein van den Heuvel — Fri, 18 Apr 2008 17:57:11 GMT

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.

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Art Wiens — Fri, 18 Apr 2008 18:15:07 GMT

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:

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Art Wiens — Fri, 18 Apr 2008 18:15:38 GMT

And here's the failing one:

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Art Wiens — Fri, 18 Apr 2008 18:43:54 GMT

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

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Hein van den Heuvel — Fri, 18 Apr 2008 18:54:31 GMT

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.

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Art Wiens — Fri, 18 Apr 2008 19:07:45 GMT

Here's /class=all - working:

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Art Wiens — Fri, 18 Apr 2008 19:08:11 GMT

and /class=all - failing:

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Art Wiens — Fri, 18 Apr 2008 19:08:45 GMT

Sorry:

and /class=all - failing:

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Hein van den Heuvel — Fri, 18 Apr 2008 19:43:34 GMT

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.

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Art Wiens — Fri, 18 Apr 2008 19:55:23 GMT

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

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Hoff — Fri, 18 Apr 2008 22:34:23 GMT

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.

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

John Gillings — Sun, 20 Apr 2008 21:12:29 GMT

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.

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

x2084 — Mon, 21 Apr 2008 09:29:43 GMT

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.

Re: LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

Art Wiens — Mon, 21 Apr 2008 14:30:25 GMT

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