Address/Prot translation

[Willem Grooters]

My dear collegues,

Actually, I'm looking for software running on VMS....

See attachment (Word2K document, 2 pages) for a description of the problem.

Solution is obvious: Address/Port translation, based on the address of the TRU64 machine. They can keep the ports like they need to, on the VMS side there is enough flexibility to handle this. There are several ways to do this: firewalls (already installed between the TRU64 and VMS systems), the routers in the network, or a seprate box. However, it has been estimated this would require extra investment: eventual extra hardware, extra configuration as well, extra maintenance costs...It may mean yet another party in the process (there are 4 already).

One suggestion was that this be done on the VMS side. We do NOT want this, but we might be forced to.
Since the application software simply cannot be changed to accomodate this (due to LARGE implications), this means that we need some program, passing the message to anothe rport, and in such a way that the reply will be senbt to the proper TRU64-machine - like a non-filtering firewall...
I've looked for software capable of doing this, but couldn't fine anything.
Does anyone have, or know of, VMS software that is capable of doing this translation, please let me know.

[Jan van den Ende]

Willem,

somehow I get the feeling that you cannot give more specific details. Am I correct in thinking that this would be doing something in politieland? (VMS & TRU64, RMS databases, multiple instances?). We DO have some stuff in those directions, but I got no idea how relevant they can be to your problem.

If so, you might contact me more directly at

jan.van.den.ende@amsterdam.politie.nl (en je kent de PITD restricties).

It might well be that we can get a mutual benifical cooperation out of this!

jpe

[Willem Grooters]

Jan,

You're no longer allowed to guess. I'll get in touch (and yes, I do know the rstrictions, but this will pass)

Willem

[Lawrence Czlapinski]

Willem, If your VMS system doesn't already have a network card with four ports, the simplest solution might include adding a network card with four ports on the VMS side. Is it feasible to use 3 different ports on a network card on VMS side? That way you could have 3 unique TCPIP addresses/names on the VMS side. If the data to TRU64 is sent out on a unique TCPIP address, the TRU64 would know where to send its data. You don't say what you're using to transfer the data.
Lawrence

[Bojan Nemec]

Willem,

If the VMS application permits (all instances of application can be run from the same user) you can setup the application environment based on the TRU64 machine which started the communication. For this you can use the SYS$REM_NODE logical name defined in the job logical name table.
Something like this:

$ if f$trnlnm("sys$rem_node").eqs."A::"
$ then
$ @node_A_setup
$ goto setup_done
$ endif
$ if f$trnlnm("sys$rem_node").eqs."B::"
$ then
$ @node_B_setup
$ goto setup_done
$ endif
$ if f$trnlnm("sys$rem_node").eqs."C::"
$ then
$ @node_C_setup
$ goto setup_done
$ endif
$! ups - unknown remote node
$setup_done:


Bojan

[Wim Van den Wyngaert]

Willem,

Lawrence is right. You can setup a number of synonyms on your network card.
(ifconfig we0 aliasname a.b.c.d)

But are you going to use a cluster alias ?

Wim

[Willem Grooters]

Lawrence,
If has been considered to keep different addresses for each TRU64 machine, but it would require major changes in the network configuration (routing, to be precise) - and given the structure of the organisation, this is considered undesirable (I've been told).
Another thing we thought about is a separate connection path for each remote site where the TRU64 machines reside. The environment in which the systems participate requires 24x7x365 availability, so EVERYTHING needs to be secured by redudancy. Imagine the cost of the hardware, the cost of managing the whole complex environment (up to 8 remote sites) and the possibility of error, and you'll understand why this option was dropped.

Bojan,
We thought about this, but the VMS program will continue to read until nothing is left on the socket. That means that if two TRU64 machines write to the same port during the existence of the VMS program (either alternating or one the other), the data sent by the first connection will determine in which database the data will be stored - and the data of the second will end up there as well. Which, as you will understand, is not really what we want.
Redesigning the protocol (needed to prevent this) is not an option.

Willem

[Willem Grooters]

Wim,

you just came between...
I know that multiple addresses can be put on a network connection andeach will then have up to 64K ports. Even on one NIC, you don't need multiple ones.
And yes, cluster alias is definitely be used: the whole lot is a 24x7x365 operation (or better: it'd better be) so there must at least be a VMS box available - and accessable.
This too could well lead to even more complexity - which is something to be avoided.

Willem

[Willem Grooters]

The issue has been solved, and in the way widely considered to be the only feasable one: the TRU64 application has been adjusted to faciliate multiple ports on one address. Better said: the procedures concerning the delivery and supprt of this program have been changed, since there was no technical issue why there wouldn't be multiple ports.