LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

[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