IMGACT-F-SYMVECNFD, symbol vector entry not a valid procedure

[Cindy Railey_1]

Hi..

I attempted to run accounting on one of our Integrity servers (OpenVMS v8.3) and got the following error

>>acco/br/sin
%DCL-W-ACTIMAGE, error activating image SCRSHR
-CLI-E-IMGNAME, image file $1$DGA12:[SYS0.SYSCOMMON.][SYSLIB]SCRSHR.EXE
-IMGACT-F-SYMVECNFD, symbol vector entry not a valid procedure

I have 6 other IA64 servers running VMS v8.3 and at same patch level. SYS$LIBRARY:SCRSHR.EXE is same date/time/size on all servers. But I only have the problem on 1 server.

Also ANAL/IMAGE says "0 Errors". I moved the accountng.dat file to a different server and ran accounting with no problems.

I couldn't find SYMVECNFD in the help message file. Has anyone ever seen this before?

[Hein van den Heuvel]

This error is happening while the account command image (sys$system:ACC.EXE) is started, before it is activates, and certainly well before it opens the target file (sys$manager:ACCOUNTNG.DAT)

So you should check out (ANALYZE/IMAGE) sys$library:SCRSHR.EXE
It has helper routines to do the SCReen management.
It should be about 123 blocks and INSTALLED (INSTAL LIST ...)
Compare it with your other systems.

Good luck!
Hein.

[Hein van den Heuvel]

I meant to say ANALYZE/IMAGE/GST and ANAL/IMA/SECTION=SYMBOL_VECTOR SYS$LIBRARY:SCRSHR.EXE

Compare the output betweena working system and the broken one


On re-read I see you already checked the sizes and dates.

Maybe delete and re-install?
(I know, it would not be very satisfying if that fixed it, but let's worry about that if it happens again :-)

Hein.

[Robert Gezelter]

Cindy,

Please also verify that there are not any logical names matching the SCRSHR name.

If the shareable image file matches the files on the other machines, a logical name could be pointing at another file.

- Bob Gezelter, http://www.rlgsc.com

[John Gillings]

Cindy,

Reinstall is a good bet, but if you're not privileged, or don't want to mess with the installed image, try:

$ DEFINE SCRSHR SYS$SHARE:SCRSHR.EXE;
(repeat failing command)

(note the critical trailing semicolon to bypass known file activation). If this "fixes" the problem, then you've confirmed a problem with the installed global section and a reinstall should resolve the issue. Similarly, make a copy of SCRSHR from a known good system in your SYS$LOGIN directory, and try:

$ DEFINE SCRSHR SYS$LOGIN:SCRSHR.EXE;
(repeat failing command)

If this works, but the previous one doesn't you must have a corrupt image. Try DIFF between the images.

ANALYZE/IMAGE doesn't necessarily pick up all possible corruptions, and it certainly won't pick up any in-memory corruptions of the installed sections.

[Hein van den Heuvel · Accepted solution]

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

So that would mean checking out LIBRTL, LIBITS and SORTSHR as well.
But those are so commonly used that it would be odd for this problem to be reported with ACCOUNTING only. The message itself indicates a discrepancy between what was looked for, and what was found.
Maybe it was looking for the wrong thing!
I would check (grab copy from other system) the ACC.EXE as well.

"ANALYZE is a nice tool. But ... On I64 /GST (as any other Alpha specific
qualifier) is accepted but silently ignored. /SECTION=SYMBOL_VECTOR is
the right thing, but it only checks the consistency of the symbol vector
itself... By default, ANALYZE prints only a summary. To have analyze read and interpret all Elf structures, one should ask for /section=all /segment=all (and redirect the output to a file, hope that there is
enough disk space and go for a coffee)."

hth,
Hein.

[Cindy Railey_1]

Thank you all for the good suggestions and information.

I've worked my way thru each suggestion -
No logical for SCRSHR defined, tried defining it myself and continue to get the same error.

I've diffed the SCRSHR.EXE with a good image from another system. also diffed the output of ANAL/IMAGE/SECTION=ALL/SEGMENT=ALL from both systems.

I removed and reinstalled the image, and even tried reinstalling the image from the other system. Tried using a 'good' ACC.EXE

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

I cannot say for certain that I have ever run accounting on this server since it was installed 4 mos ago. The server was rebooted Sat. night - (HP had to replace one of the Dimms)

Yesterday I noticed that when I did install list/fu - the 'entry access count' was "9". This count does not increment when I attempt to run accounting (it does increment on systems where accounting works). Of course, since I have reinstalled the image - the entry access count is "0" and is not incrementing.

Do you agree that this tells me that the image has been accessed correctly at some time since the system was booted? Does anyone know what else may use SCRSHR?

I'm going to try moving the 'offending' SCRSHR.EXE to a test system and see what happens. This may take some time because I've got to address some other issues first - but I will keep you posted.

Cindy

[Cindy Railey_1]

I moved the SCRSHR.EXE and ACC.EXE to a test system and used these images without a problem.

this seems to lead back to what Hein said -"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."


So If I understand correctly - this would mean that although SCRSHR is reporting the error - but it's a different image that Accounting is using that has the problem?

[Wim Van den Wyngaert]

Check the files sys$share:librtl.exe and libots.exe. These are used by decshr which in term is used by acc.exe.

Wim

[Cindy Railey_1]

I finally found it. In my LOGIN.COM I have SORTSHR defined as SYS$LIBRARY:HYPERSORT.

This didn't show up as a problem on the other servers - I only define the logical if the architecture is "ALPHA" (leftover from Vax to Alpha migration I suppose)

We have 1 remaining lonely alpha - I checked it out and Accounting runs fine with SORTSHR defined as HYPERSORT.

So this mystery is solved.. appreciate everyone's help - I learned more stuff that I'm sure will come in handy someday.

Now I'll go try to determine if there's a patch or some limitation using Hypersort on Itanium.