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

[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