%TIE-W-PSIG_WRONG and %TIE-W-PSIG_ADDR errors

[Mario Antunes Marino]

Hi!
OVMS 8.3 + update 0300 on Itanium.

I converted an image from Alpha to I64. When I run it I receive then following message:

%TIE-W-PSIG_WRONG, Wrong PSIG [000000007B2D0540] for SECURESHRP_AV[12]
%TIE-W-PSIG_ADDR, PSIG invalid address : 000000007B2D0540

The image SECURESHRP_AV doesn´t exist on my system, I don´t know what is happening.

Any help?
Thanks,
Mario Antunes

[John Gillings]

Mario,

The _AV image should be a translated shareable image referenced from your program, just like the _TV images going from VAX to Alpha. I don't have an IA64 system to check on, so make sure you have SOME images with names ending in _AV in SYS$SHARE to make sure the translation environment is correctly installed.

That it's SECURESHRP is a bit suspicious. Is the program you're translating privileged in any way? If it is, you're unlikely to be able to successfully translate it.

What shareable images does the Alpha image reference?

[Volker Halle]

Mario Antunes,

welcome to the OpenVMS ITRC forum.

Did you get any warning messages, when translating the Alpha image with AEST ?

On our OpenVMS I64 V8.2 system (with TIE V1.0 installed), there is no SYS$SHARE:SECURESHRP_AV.EXE, which may lead to the conclusion, that this shareable library is not being provided by the OpenVMS TIE environment.

To search for shareable iamges linked to your Alpha program, use:

$ PIPE ANAL/IMA imagename.exe | SEARCH SYS$PIPE "global section name"

Volker.

[Mario Antunes Marino]

John, Volker.

Thank you for the replies.

My program translates without errors:

IA64_sys> aest/list/exec=PNS37002.EXE PNS37002.EXE;3
IA64_sys> dir/since/date/size=all

Directory DISCO00:[NEW.EXE]

PNS37002.EXE;7 906/912 23-JAN-2008 10:40:13.33
PNS37002_AV.LIS;2 0/0 23-JAN-2008 10:40:08.78

>>> what shareable images does the Alpha image reference?

Alpha_sys> ANAL/IMAGE PNS37002.EXE/OUT=LOG.TXT
Alpha_sys> search log.txt "global section name"
global section name: "DEC$COBRTL_001"
global section name: "LIBRTL_001"
global section name: "LIBOTS2_001"
global section name: "LIBOTS_001"
global section name: "SMGSHR_001"
global section name: "SECURESHRP_001"
global section name: "SYS$BASE_IMAGE_001"
global section name: "SYS$PUBLIC_VECTORS_001"

(From the output of $ ANAL/IMAGE):

Shareable Image List

0) "DEC$COBRTL"
1) "LIBRTL"
2) "LIBOTS2"
3) "LIBOTS"
4) "SMGSHR"
5) "SECURESHRP"
6) "SYS$BASE_IMAGE"
7) "SYS$PUBLIC_VECTORS"

As you two suspected, my program calls a shareable image (SYS$LIBRARY:SECURESHRP.EXE) that has no _AV equivalent on the IA64 system.

Although *THERE IS* a SECURESHRP.EXE image on the IA64 system, I think it would be used if my program were compiled/linked instead of translated. Since my program was translated, the TIE environment looks for SECURESHRP_AV.EXE shareable image, right?


-Mario

[Volker Halle]

Mario,

on our OpenVMS I64 V8.2 system (with TIE V1.0 installed), there are logicals for SECURESHRP_AV:

I64VMS $ sho log secure*

(LNM$PROCESS_TABLE)

"SECURESHRP_AV" = "SECURESHRP"
"SECURESHR_AV" = "SECURESHR"
"SECURESHR_TV_AV" = "SECURESHR_JACKET_AV"

...
(LNM$SYSTEM_TABLE)

"SECURESHRP_AV" = "SECURESHRP"
"SECURESHR_AV" = "SECURESHR"

SYLOGIN.COM invokes SYS$STARTUP:TIE$STARTUP to define the process logicals. The system-wide logicals are defined in VMS$INITIAL-050_VMS.COM.

Please check on your system.

Volker.

[John Gillings]

Mario,

>global section name: "SECURESHRP_001"
>global section name: "SYS$BASE_IMAGE_001"

Your image is linked against SYS$BASE_IMAGE which might preclude it from being translated.

You need to check exactly how the original image was linked, and why it's linked against the base image. Then check the AEST documentation to make sure the image is eligible for translation.

[Mario Antunes Marino]

John,

Yes, the image was linked agaist SYS$BASE_IMAGE.

I re-linked it without /SYSEXE:
Alpha>LINK/nosysexe PNS37002,SNS37012,SNS37016

The shareable image list changed to:

Shareable Image List

0) "DEC$COBRTL"
1) "LIBRTL"
2) "LIBOTS2"
3) "LIBOTS"
4) "SMGSHR"
5) "SECURESHRP"
6) "SYS$PUBLIC_VECTORS"

Then, re-converted it on the IA64 system:

Alpha> copy PNS37002.EXE IA64_SYS::

IA64_SYS> aest/exe=PNS37002.EXE PNS37002.EXE;4
IA64_SYS> run PNS37002.EXE


%TIE-W-PSIG_WRONG, Wrong PSIG [000000007B2D0540] for SECURESHRP_AV[12]
%TIE-W-PSIG_ADDR, PSIG invalid address : 000000007B2D0540

[John Gillings]

Mario,

Dumb question time...

> re-linked it without /SYSEXE:
>Alpha>LINK/nosysexe PNS37002,SNS37012,SNS37016

If you can relink this, does that mean you can recompile it?

If so, you should forget about converting the image, instead you should port it to IA64. Translating is really only for last-ditch-no-other-possibilities-exist situations.

However, if that's really not possible, we havn't yet worked out why your SECURESHRP_AV logical names aren't set correctly. Are you sure you've executed SYS$STARTUP:TIE$STARTUP ?

Have you successfully translated any other images?

Do you know what & why your program is accessing in SECURESHRP?

[Hoff]

An even dumber dumb question: do you have the application source code?

If you do have the source code, then AEST and TIE are usually not the best approach. The results of AEST and TIE are supportable and sustainable without substantial investments; if the translated image contains one or more latent bugs and tips over for whatever the particular trigger, all (supportability) bets are somewhere between "off" and "really expensive."

Given that the image is linked against the OpenVMS executive, AEST and TIE are not likely even going to be an option here.

[Tim E. Sneddon]

I know this reply is a little late, but I was snooping around for something and noticed this is a problem I came across too.

The problem is actually with the I64 linker. It doesn't generate TIE signatures correctly due to some bad pointer arithmetic. So, SECURESHRP has bad argument signatures. TIE uses these to pass arguments back and forward between translated code.

If you're interested in all the gory details and/or a linker that works then let me know and I can post it.

Tim.

[Robert Gezelter]

Mario,

While I am an advocate of using AEST and TIE as tools, I do agree with the comments by Hoff et al that recompiling the source is the far better alternative.

Is there a particular reason why the sources cannot be recompiled directly on the Itanium?

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

[x2084]

Yes, there is a known bug in the I64 linker related to creating TIE signatures. It's not as simple as "It doesn't generate TIE signatures correctly".

Anyway, SECURESHRP is not affected by this (from an 8.3 system):

ANAL/IMAGE/INTER SYS$COMMON:[SYSLIB]SECURESHRP.EXE
...
Link flags
Call SYS$IMGSTA
Image has main transfer
Traceback records in image file
Press RETURN to continue, or enter a period (.) for next file:

Images linked with /nonative do have a "TIE Signatures present" entry in the Link flags.

[Mario Antunes Marino]

Robert,

We had to use AEST because in some cases we didn´t have the source codes anymore.

For applications we have the source codes we recompile/relink the Cobol/SQL-Cobol programs. This is the better choice for many reasons. Performance, for example.

-Mario

[Robert Gezelter]

Mario,

I agree. AEST (and VEST) are extremely useful tools, but recompilation is the best choice.

You may find my article and presentation "Strategies for Migrating from Alpha and VAX systems to HP Integrity Servers on OpenVMS" interesting.

The OpenVMS Technical Journal article can be found via
http://www.rlgsc.com/publications/vmstechjournal/migrationstrategies.html

The presentation from the 2008 HP Technology Forum can be found at http://www.rlgsc.com/hptechnologyforum/2008/migrationstrategies.html

Translation is a useful tool, particularly since shareable libraries make it more precise than an "all or nothing" choice.

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

[Bill Pedersen]

Tim:

I know this post is a decade or so old but I have just run across this issue with a newly translated image for a client and it sounds like this is similar to the issue you mention.  It is not linked against the base image but is linked against:

        Shareable Image List

                0)  "DECC$SHR"
                1)  "LIBOTS"
                2)  "SECURESHRP"

 I am running on 8.4 update 1100...

You mention a linker that solved the problem.  Did the fixes never get into the standard linker?

Thanks,

Bill.

[H.Becker]

> Did the fixes never get into the standard linker?

To answer the question: yes, as far as I know this fix is not in the standard linker.

As mentioned before, SECURESHRP very likely doesn't have a problem caused by this linker bug. On recent VMS versions (V8.4-2L1) I can't see the footprint of that bug in SECURESHRP. Can you show an output of analyze/image from your SECURESHRP, especially the PROGRAM SEGMENT SUMMARY?

What is the full error message, is SECURESHRP mentioned?

And yes, if you have a linker with the fix for the mentioned bug, and if SECURESHRP is affected by the bug, you need to re-link SECURESHRP.

[Bill Pedersen]

Tim,

Thanks for getting back to me.  This is, as I mentioned, on 8.4U1100...  Not likely to get to VSI version for a while.

Full error message is:

%TIE-W-PSIG_WRONG, Wrong PSIG [000000007B2CC540] for SECURESHRP_AV[12]
%TIE-W-PSIG_ADDR, PSIG invalid address : 000000007B2CC540

Analyze/Image of SECURESHRP.EXE...

Analyze Image                                27-FEB-2018 19:05:56.44                                                   Page 1

SYS$COMMON:[SYSLIB]SECURESHRP.EXE;1

ANALYZ I01-55

This is an OpenVMS IA64 (Elf format) shareable image file

Image Identification Information, in section 8.

    Image name:                                 "SECURESHRP"

    Global Symbol Table name:                   "SECURESHRP"

    Image file identification:                  "X-9"

    Image build identification:                 "0100000081"

    Link identification:                        "Linker I02-37"

    Link Date/Time:                             27-JUL-2012 12:31:08.05

Image Transfer Information, in segment 8.

    Main Transfer

        Entry Address:                          000000000004FF80 (segment 2.)

        GP Value:                               00000000002F0000

Image Activation Information, in segment 9.

    Match Control

        Algorithm:                              LESS/EQUAL

        Major ID:                               1.

        Minor ID:                               4.

    Global Pointer:                             00000000002F0000

    Whole program FP-mode:                      VAX FLOAT

    Symbol Vector in segment 8.

    Link flags

        Call SYS$IMGSTA

        Image has main transfer

        Traceback records in image file

        TIE Signatures present

    Shareable Image List

        SYS$BASE_IMAGE

        SYS$PUBLIC_VECTORS

    Component List, Image / Current System Version

        SYS$K_VERSION_BASE_IMAGE                (3.0 / 3.0)

        SYS$K_VERSION_MEMORY_MANAGEMENT         (3.0 / 3.0)

        SYS$K_VERSION_PROCESS_SCHED             (2.0 / 2.0)

        SYS$K_VERSION_SYSGEN                    (1.64 / 1.64)

        SYS$K_VERSION_LOGICAL_NAMES             (1.0 / 1.0)

        SYS$K_VERSION_SECURITY                  (2.32 / 2.32)

        SYS$K_VERSION_IMAGE_ACTIVATOR           (1.64 / 1.64)

        SYS$K_VERSION_STABLE                    (1.64 / 1.64)

        SYS$K_VERSION_MISC                      (1.64 / 1.64)

        SYS$K_VERSION_VOLATILE                  (1.64 / 1.64)

        SYS$K_VERSION_SHELL                     (1.64 / 1.64)

        SYS$K_VERSION_MULTI_PROCESSING          (2.16 / 2.16)

Analyze Image                                27-FEB-2018 19:05:56.44                                                   Page 2

SYS$COMMON:[SYSLIB]SECURESHRP.EXE;1

ANALYZ I01-55

Elf Header Information, at file address 0.

    Class:                                      ELF-64

    Data:                                       Little-endian byte order

    Elf Header Version:                         1.

    OS ABI:                                     OpenVMS

    OS ABI Version:                             2.

    Type:                                       Shareable

    Machine Architecture:                       IA_64

    Elf File Version:                           1.

    VMS Completion Code:                        SUCCESS

Analyze Image                                27-FEB-2018 19:05:56.44                                                   Page 3

SYS$COMMON:[SYSLIB]SECURESHRP.EXE;1

ANALYZ I01-55

PROGRAM SEGMENT SUMMARY      Table at file address 00000048, 10. segments, 56. bytes each, 560. total bytes

Number  Type                 Virtual Address  Memory Size      File Address     File Size         Flags

1. LOAD                 0000000000010000 00000000000019B0 0000000000000400  = Memory Size    -WR------------Pro------------
2. LOAD                 0000000000020000 0000000000000070 0000000000000000 0000000000000000  -WR------------Pro------------
3. LOAD                 0000000000030000 000000000005B1D0 0000000000001E00  = Memory Size    X-R------------Pro------Shr---
4. LOAD                 00000000000B0000 0000000000002CD0 000000000005D000  = Memory Size    --RNwr---------Pro------------
5. LOAD                 00000000000C0000 0000000000000510 000000000005FE00  = Memory Size    --RNwr---------Pro------Shr---
6. LOAD                 00000000000D0000 000000000000002C 0000000000060400  = Memory Size    --RNwr------VecPro------------
7. LOAD                 00000000000E0000 0000000000003748 0000000000060600  = Memory Size    --R------------Pro------------
8. LOAD                 00000000000F0000 0000000000000054 0000000000063E00  = Memory Size    -WR------------Pro---Sho------
9. LOAD                 0000000000100000 00000000000022F8 0000000000064000  = Memory Size    --RNwr---------ProNwfSho------
10. DYNAMIC              0000000080000000 000000000000A170 0000000000066400  = Memory Size    --R---------------------------

Key for Flags: X (Execute), W (Write), R (Read), Nwr (No write but relocations), Ini (Initialization code), Res (Resident),

               Vec (Vector), Pro (Protected), Nwf (No write but fixups), Sho (Short data), Shr (Shared), Nrc (No recovery code)

SECTION SUMMARY              Table at file address 0007CE00, 13. sections, 64. bytes each, 832. total bytes

Number  Type                 Name                              File Address     File Size         Flags

1. NULL                                                   0000000000000000 0000000000000000  ------------------------------
2. STRTAB               .shstrtab                         000000000007CC00 0000000000000095  ------------------------------
3. STRTAB               .strtab                           000000000007CA00 0000000000000115  ------------------------------
4. VMS_TRACE            .debug_line                       0000000000070600 0000000000009C34  ------------------------------
5. VMS_TRACE            .trace_abbrev                     000000000007A400 0000000000000357  ------------------------------
6. VMS_TRACE            .trace_info                       000000000007A800 00000000000014C9  ------------------------------
7. VMS_TRACE            .trace_aranges                    000000000007BE00 0000000000000560  ------------------------------
8. PROGBITS             .comment                          000000000007C400 000000000000004A  ------------------------------
9. NOTE                 .note                             000000000007C600 0000000000000190  ------------------------------
10. NULL                 $LINKER RELOCATABLE_SYMBOL        0000000000000000 0000000000000000  ------------------------------
11. STRTAB               .dynstr                           0000000000066670 0000000000000023  -A----------------------------
12. SYMTAB               .symtab                           000000000007C800 00000000000001B0  ------------------------------
13. VMS_SYMBOL_VECTOR    .vms_symbol_vector                0000000000064000 0000000000000098  -A----------------------------

Key for Flags: W (Write), A (Alloc), E (Execute), S (Strings), I (Info link), L (Link order), O (OS-specific processing),

               G (Group), Sho (Short), Nrc (No recovery code), Gbl (Global), Ovr (Overlaid), Shr (Shared), Vec (Vector),

               64b (Allocate 64bit address), Pro (Protected)

Analyze Image                                27-FEB-2018 19:05:56.45                                                   Page 4

SYS$COMMON:[SYSLIB]SECURESHRP.EXE;1

ANALYZ I01-55

The analysis uncovered NO errors.

**bleep**/IMAGE sys$library:secureshrp.exe

===================================

Thanks,

Bill.

[Bill Pedersen]

It should be noted, that the program RUNS and does give the expected output, just that it gives these warnings.  Not having the source, as least as far as we can determine so far, lead us to use AEST to translate it.

I have implemented a filter to get rid of the warning messages for the client so they are happy, but...

Best,
Bill.

[H.Becker]

The PROGRAM SEGMENT SUMMARY does not show a signature segment. The linker bug only shows if there is a signature segment and if one more condition is met.

(The signature segment comes after the Sho[rt] segments, here numbers 8 and 9, and before the DYNAMIC segment, here number 10.)

I don't know much about the TIE messages. But they contain a P1 address. You can check with SDA whether it is an address of an image installed with shared address data, which SECURESHRP is. For a process with SECURESHRP mapped, just do a "SDA> map 7B2CC540". From what I see, I would expect the address to be in "Short data (read only)".