Two IPC_Shr Images

[Almond Desailly]

Hi,

I was working with TCPIP services the other day and was confronted two images in system:
TCPIP$IPC_SHR.EXE and UCX$IPC_SHR.exe.
Why are there two IPC_shr exes in an openVMS system?
As far as I remember(correct me if I am mistaken), UCX was previously used to provide various services on OpenVMS, which are now provided by TCPIP.
It is more of a curiosity than an issue faced by me.

Would appreciate if anyone can throw some light on this.

Cheers,
Almond

[Joseph Huber_1]

Doing analyze/image and difference, it looks they are identical images and both contain the UCX$ and TCPIP$ entry names.
I think one could get rid of ucx$ipc_shr, and either make an alias directory entry or define a logical name to use older programs linked to ucx$ipc_shr.
The makers of the TCPIP product kit probably are just lazy or don't know it better ...

[Jeffrey Goodwin]

The two images were used to maintain compatibility when the product prefix was changed to TCPIP$ from UCX$.

Perhaps there might have been a better way to maintain compatibility, but that's the way the UCX/TCPIP group did it.

-Jeff

[John Gillings]

re: Joseph

>I think one could get rid of ucx$ipc_shr,
>and either make an alias directory entry or
>define a logical name to use older programs
>linked to ucx$ipc_shr.

True, but logical names are a finite resource, and increasing the number of definitions in a logical name table will increase the cost of logical name lookups (even if only infinitessimal). They also need to be defined somewhere before they can be used.

To impose a cost, however small, on ALL TCPIP users for all time for the sake of the dwindling minority of those who still have UCX legacy code sounds like a bad trade-off to me. Remember that logical name lookup is a very high frequency event, so even small costs add up over time.

Also true, the same effect could be achieved with an alias entry, but, unlike Unix, file aliases tend to be very rare in OpenVMS. Indeed the ONLY alias used in most OpenVMS installations I can think of is that of VMS$COMMON on the system disk (and think of all the trouble that's caused over the years!). I can definitely see why TCPIP engineering would avoid introducing aliases.

>The makers of the TCPIP product kit
>probably are just lazy or don't know it
>better ...

I think that's an unfair assessment.
For the sake of a few hundred disk blocks and an automatic COPY operation in the build, I'd say they've picked the simplest and most robust mechanism for maintaining compatibility. They've also given themselves a simple way to leave UCX frozen in time and change the equivalent TCPIP image in the future, should it become necessary.

[Robert Gezelter]

Almond,

If the images are identical (with the exception of the filename), then I will, with all due respect, disagree with John with respect to using logical names to map TCPIP$IPC_SHR.EXE and UCX$IPC_SHR.EXE into a single file.

If expansion of the interface is needed, then it is a simple matter to add entry points to the end of the transfer vector, with no ill effects on any existing binary images, so long as the API to the pre-existing entry points is maintained.

With regards to the overhead of extra logical names, with the exception of privileged images, there is no reason why such a logical name need be in a global table, it can be in the process, job, or group tables, as well as any other logical name table that is included in the appropriate search path used by the image activator (I do not have my IDSM within reach at this instant).

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