setting up a LAT forward port

[Jess Goodman]

We have applications that read or write data to/from serial ports that were migrated to use LAT terminal server ports years ago. The programs that transfer the data know nothing about the LAT protocol itself, and I would prefer to keep them that way for portabilitity concerns. We have DCL scripts that uses LATCP to pre-create application ports and assign them the appropiate target service and target node. We ALLOCATE the LTAxx: device in DCL and then run a separate setup program that just does a IO$_TTY_PORT!I$M_LT_CONNECT $QIOW call and exits. Since the device is allocated the connection remains and the LTAxx: device is ready for the application program to read/write to it.

This all works well, but because we're using LAT application ports we have to specify a target node, not just a target service. This leaves us vulnerable if one particular terminal server goes down. We would like the process to be able to connet to any terminal server offering the data service.

To specify a target service without a target node I need to use a forward LAT port (outgoing LAT). There is a program example on how to create and use a forward LAT port in the I/O User's reference manual. The problem is there seems to be no easy way to create and assign the port in a setup program before running a separate application program that reads/writes to a forward port.

LATCP will not create a forward port. You have to clone one by assigning a channel to LTA0:. I can write a setup program to do this and it can even set the target service and make the connection, but when the program exits the channel is deassigned and the LTAxx: device is immediately deleted. Using SYS$ALLOC to allocate he LTAxx: device doesn't help because it's only allocated in user-mode so that goes away too when the program exits. Spawning an ALLOCATE command while the program has a channel assigned to the device just returns a "device allocated to another user" error.

I have even tried to create the forward port from DCL itself with "OPEN/READ/WRITE LATPORT LTA0:". I was hoping I could then ALLOCATE LATPORT, CLOSE LATPORT, run LATCP and/or a setup program to assign the target service and make the connection. This approach almost works except for a very strange DCL bug (I see it under VMS 6.2 and VMS 7.2). When you do the above OPEN command in DCL the LATPORT logical is created, for example:

$ show logical latport
"LATPORT" = "_NODEA$LTA120" (LNM$PROCESS_TABLE)

But that device never exists:
$ mcr latcp show port lta120:
%LAT-W-CMDERROR, error reported by command executor
-SYSTEM-W-NOSUCHDEV, no such device available

The device that is actually created by the DCL OPEN command is always one unit number higher than the device name returned in the DCL logical:
$ mcr latcp show port lta121

Local Port Name: _LTA121: Local Port Type: Forward (NonQueued)
Local Port State: Inactive
Connected Link:

Target Port Name: Actual Port Name:
Target Node Name: Actual Node Name:
Target Service Name: Actual Service Name:

I guess what I would really like is an easy way to ALLOCATE the LTAxx: device in supervisor mode from a program but there seems to be no API for this like there is for LIB$SET_LOGICAL, and I'd rather not use SYS$CMEXEC if I don't have to.

[Robert Gezelter]

Jess,

I have the distinction of actually having programmed forward ports on more than one occasion. To put it politely, the documentation on that aspect of creating and manageing outbound LAT connections is somewhat less than what it could be.

On first glance, there is a need to create the port in Supervisor mode (admittedly mixing my terminology, but in effect a "Process Permanent File", and yes, before someone jumps up and down, I did mean "in effect", not an actual Process Permanent File).

I would have to think things through a bit, because it is not quite that easy. There are other issues that need to be addressed.

What presumptions do your applications make about the ports?

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

[Jess Goodman]

The applications that read/write to the port assume they are just talking to serial devices. One particular Fortran program, which is also used interactively, just outputs some data to SYS$OUTPUT. In this case we use it to continually feed its data to a remote site by runnning it as a detached process with SYS$OUTPUT redefined to a LTAxx: device. It could be made "LAT aware" but I feel that's a very unmodular approach.

We also use WERMIT (a version of Kermit with advanced scripting capabilitities) to manage a set of dial-out modems connected to terminal servers. The WERMIT code is third party so we modifying it is pretty much out of the question.

[Robert Gezelter]

Jess,

Actually, I am (in my spare time) working on modifying C-KERMIT to be able to make outbound connections using LAT. There is a good chance that your WERMIT is actually a direct version of C-Kermit (from Columbia University's Kermit Project).

The sequential streams approach could be done two ways:
1) I suspect something could be set up to establish the connections in Supervisor Mode (it would require some modest programming, but not too bad); or
2) it could be done with less efficiency, and with probably more work (just not elevated modes) with mailboxes or network channels (I prefer DECnet logical links, they have important useful semantics when tasks exit)

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

[Anton van Ruitenbeek]

Maybe its to easy, or I don't understand the problem directly, but cant you create a LAT port in LATCP before starting up the process and create the logical to it?
This port will be permanent.

One of my costumers is a plant for making cartons for eg milk. The whole plant is filled with PLC's. This are triggers who only can communicate serial. All these whe connect to ports whe create with LATCP, and in the processes (Oracle C+) who need to trap these PLC's we connect to the previous created LTA devices. Now we can modify the .COM procedures who create the LTA ports if a terminalserver failed or a PLC has to be moved from one to another terminalserver.

AvR

[Albert Öttl]

Hi Jess,
because a LAT service with the same name can be defined on more than one service node, it does not make sense to define an outbound LAT connection with only a service name. In either case (service or port) you have to specify the target node. To specify a service name instead of a port name makes sense if you want to change the port on the same server without the need of reconfiguration of the LTAnnn: device.

If you want to change the server, you have to redefine the LTAnnn: device for the outbound connection.

Regards,
Albert

[Robert Gezelter]

Albert,

While the outbound LAT code on OpenVMS MAY NOT allow the specification of a SERVICE name without a SERVER, it is a limitation (a polite term for that rare OpenVMS "feature", a "bug").

It is true that when you connect to a LAT service by service name, you do not know which of potentially multiple servers you have connected to. But, that is exactly the definition of a LAT service (e.g., members of the same OpenVMS Cluster often define, in addition to the LAT services for specific nodes, an overall cluster LAT service, which is load balanced using an "advertising" scheme).

In summary, it does make sense, although it may be an implementation limitation.

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

[Jess Goodman]

Anton, I can (and DO) create /APPLICATION ports with LATCP. As you said they are permanent and if the terminal server they connect to goes down then command files must be modified. What I want is an *automatic* failover to another terminal server when one of them goes down.

Albert, yes it does makes good sense to define a service that is offered on more then one node and to allow connections to the service without specifying the node.

One simple example of this is an interactive service offered by all nodes in a cluster. A terminal server user would connect to a VMS node (does not care which) with CONNECT servicename. You may think that the syntax is CONNECT nodename, but here "nodename" is actually the name of the default LAT service offered by a VMS node.

If you have outgoing LAT connections enabled on your VMS node then at DCL you can use "SET HOST/LAT service" to make a connection just as if you were using a terminal server port.

Anton, what I am trying to do is use a FORWARD port instead of an APPLICATIOn port. FORWARD ports are outgoing LAT connections under the control of a VMS application. But unlike APPLICATION ports, with FORWARD ports you do not have to specify a target node name.

In one case my target service connects to dial-out modems located on multiple terminal servers. As long as one modem is free I should be able to connect to it no matter what terminal server the free modem is on.

The application that talks to the modems is third party and does not know anything about LAT. You can use LATCP to pre-create APPLICATION, DEDICATED, or LIMITED ports but LATCP will not create FORWARD ports. I can write a separate setup program to create a FORWARD port and to set its target service, but when the setup program exits the FORWARD port is immediately deleted.

[Jess Goodman]

To emphasize one more point - it *IS* possible to use LAT FORWARD ports in a VMS application to connect to a service offered by more than one terminal server without specifying a target node name. There is even an example of how to do this in the terminal driver chapter of the I/O User's Reference Manual.

My problem is I want to create, assign, and connect the FORWARD port using LATCP and/or a setup program, and then have a different program use the pre-existing FORWARD port.

[Robert Gezelter]

Jess,

I can confirm that you do not need to specify a port/server, only a Service name.

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