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.

[John Reagan]

I haven't seen any I64-specific problems with Hypersort. Should be the same as Alpha.

[Volker Halle]

Cindy,

did you ever enable XQP diagnostics before invoking the Accounting utility ?

$ SET WATCH FILE/CLASS=MAJOR
$ ACC...

$ SET WATCH FILE/CLASS=NOMAJOR ! to turn off

This should list all images and files, which are being accessed...

Volker.

[Cindy Railey_1]

Found some notes about Hypersort Utility in the v8.3 Release Notes Section 5.20. I guess the key statement here is -

"As always, continue to use SORT32 as a workaround for any unresolved problems with Hypersort or any functionality not implemented in Hypersort"

There's addtional info about quotas etc. I will review further as time allows.

[Cindy Railey_1]

Thank you for reminding me about SET WATCH - I have notes about it but have never used it for troubleshooting a problem.

Had I used it - I would have seen HYPERSORT.EXE being accessed and would not have spent 2 or 3 hrs spinning on this. However - I will remember better next time after seeing the benefits of a tool.

Thanks to all who assisted.

[John Reagan]

To give an update:

HYPERSORT only implements a subset of the callable API that SORTSHR implements. ACCOUNTING contains a call to SOR$INIT_SORT. That routine isn't in HYPERSORT. Since SORTSHR and HYPERSORT's symbol-vectors are kept in sync, HYPERSORT just has a 0 in the slot.

When the image activator is trying to perform various fixups, it was looking for the official function descriptor for SOR$INIT_SORT but couldn't find it. Hence the error message.

On Alpha, you only notice the missing API if you ask for ACC/SORT=keyword. You'll get an ACCVIO when ACCOUNTING tries to call SOR$INIT_SORT.

We're looking at both changing the image-activator to not raise the error at activation time and let you get some error only when trying to call the missing routine.

We're also looking at changing HYPERSORT to provide some "not implemented" routine instead of just filling the slot with 0. The routine would signal some error like:

"Attempted to call an unavailable HYPERSORT API; use SORTSHR instead"

[The Brit]

I didn't fully follow John's previous post, however I was a bit disturbed by the references to SORTSHR and HyperSort.

I have Hypersort enabled in several important DCL scripts that I run (currently on Alpha). Are they going to blow-up when I move to Itanium (in ~2-3 months)??

Dave.

[x2084]

You have a main image M, it contains references to functions F and G. Both are
implemented in the shareable S. If you run M without any argument (or qualifier)
only function F is called. If you run M with argument X, G is called.

Now you replace S with T, which only implements F.

On Alpha you can run M without any argument and everything is fine. If you run
it with argument X you get an ACCVIO.

On I64 you can not run M without any argument: you get an "-IMGACT-F-SYMVECNFD,
symbol vector entry not a valid procedure". Trying it with argument X isn't
even possible.

So there is an incompatibility in the behavior of the image activator between
Alpha and I64. This will be looked at.

Adding a stub G function to T is another option or improvement: running M with
X will terminate with a nicer message than ACCVIO.

>I have Hypersort enabled in several >important DCL scripts that I run
>(currently on Alpha). Are they going to >blow-up when I move to Itanium (in ~2-3
>months)??

It depends on your(?) Ms if they reference the Gs.

[Jon Pinkley]

Count this as my vote for a stub routine that returns a useful status to the user in every unimplemented function.

If T (HYPERSORT) is supposed to be a drop in replacement for S (SORTSHR), then I would expect that unimplemented functions have stub routines. At least that fits with the "VMS principle of least surprise". I don't expect access violations or "-IMGACT-F-SYMVECNFD, symbol vector entry not a valid procedure" to occur when using a documented and supported mechanism.

I can't think of any downsides (from the end user's perspective) of having stub routines. And that would make the ALPHA and IA64 behavior consistent, e.g. ACCOUNTING without sort would work on both platforms even when the process had SORTSHR defined as HYPERSORT.

John, I would suggest a rewording of the message text to explicitly mention the SORTSHR logical name, as "use SORTSHR instead" may not be enough of a clue. At least the help/message output should have some examples of how to define it for the process in case someone had a system definition of SORTSHR to use HYPERSORT.

Specifically, the error message that was returned

%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

was not very helpful in finding the actual cause of the problem, although from the image activator's point of view, it was an accurate description.

The advantage to hp of fixing this would be fewer support calls and happier customers. And it should be an easy fix that could be put in a patch kit.

Jon

[Volker Halle]

Cindy,

looks like this problem has been fixed in the recent patches for SORT32:

VMS83A_SORT32-V0100
VMS831H1I_SORT32-V0100
VMS83I_SORT32-V0100

Volker.

[Volker Halle]

for reference:

Fixed in VMS831H1I_SYS-V0200

5.2.5 Image Activation Problem

5.2.5.1 Problem Description:

Activation of certain images does not work properly when Hypersort is set as the preferred sort image.

Images Affected:

- [SYS$LDR]IMAGE_MANAGEMENT.EXE

- [SYS$LDR]IMAGE_MANAGEMENT.STB