connect two decservers

[James Ford]

I have an application that is moving locations. I have a leased line connected to a DECServer that a canned application uses LAT to send pages thru the leased line. I can not move the leased line. Is there a way to connect a DECServer in the new location that the application can talk to LAT and connect that DECSerever to the DECserver in the old location with the leased line, ie funnel/transmit the LAT from one DECServer to the other some how connecting a port on one to a port on the other.

[Robert Gezelter]

James,

Routing LAT is a problematical exercise. LAT presumes very low latency. Routing (or bridging) Ethernet frequently violates these presumptions, resulting in dropped connections and other problems.

Depending on other details, one MIGHT be able to put something together using connections looped back to reverse TELNET connections to use the TCP/IP telnet protocol for the routed network and LAT for the end. Why is LAT being used? Would TELNET (TCP/IP) work with this application? There seem to be some details missing.

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

[James Ford]

The canned application writes to a LAT port on a DECServer 200 connected to the vendor over leased line. Thed DECServer 200 is not IP capable. It may be possible to move the leased line to a DECserver 300 but I am not sure since the system has two ethernet cards and the DECServers are on different LANs

[Hoff]

If LAT is centrally required here, then you need to have a LAN; either a "real" LAN or a low-latency tunnel, bridge, or VLAN.

The LAT protocol was never opened up and was (for many years, if not still) covered by patents and licenses, so no routers or other similar gizmos were never pursued, and are not available. (IP won.)

I assume that refactoring the application has been considered and discarded. If not, the usual path is replacement either with IP and telnet, or replacement with something that "sends pages" (not sure what that means) with another available protocol.

If refactoring is an option, there are various discussions around migrating from LAT to IP telnet available (and around reverse LAT and its reverse telnet analog, if that is in use here), though I would also seriously consider and would investigate approaches beyond the expediency of mapping LAT into its current equivalent of telnet, VPN, ssh or otherwise.

Stephen Hoffman
HoffmanLabs LLC

[Robert Gezelter]

James,

More details are critical. Is the application writing directly to the LAT port, or is it using it as a printer? Is the code available? Does the program ACTUALLY use LAT-specific coding, or is LAT merely the way that things are (were) setup?

In a brute force case, it is also possible to move the DECserver 200 (or another server) and use LAT for a local leg with the rest of the journey being used in a different port via telnet.

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

[James Ford]

To try to make a long story short. A program reads a database with paging information, ie. page text, pager number , paging company, etc, then executes a program that trys to make a connecteion to the paging serviceing company thru LTA device defined to a DECserver port connected to leased line, if connection fails it tries thru another LTA port defined to a DECServer port connected to a modem and dials out to the paging serviceing company. What happens on the other end I don't know. I assume there is a program running on the other end that takes the information sent to it and acutally sends the page to a Customer Service Rep pager based on the company the pager is for and the appropriate pager number and text

[Doug Phillips]

The DECserver's ports don't "do" LAT, they do serial or TCP/IP or (?).

What I understand so far is:

1. An application connects to a DECserver via LAT over your intranet.

2. You have some leased-line tele-com equipment connected to one DECserver (serial?) port and a dial-up modem connected to another. The application will try one, and on failure will try the other.

3. You're not responsible for whatever happens outbound past the DECserver ports / comm-equipment.

4. Somethings going to change.

SO, What's staying where it is now, and what's going to move elsewhere: the comm line(s)? the application? the DECserver?

[Hoff]

DECserver 200 is circa 1990 gear.

You're probably going to have to rewrite (some of) this LAT software stuff. A partial rewrite is probably more palatable than a complete replacement, but there are commercial software tools and packages around that send out pages, and probably some open source for this purpose. And even the rewrite itself likely isn't hairy.

This because the existing software almost certainly doesn't deal with dial tone and dialing out -- and if you don't have the leased line, you're going to have to add code to do that. (There are a couple of ways to implement this, too, whether using language I/O or $qio[w] or LAT-specific calls.)

That, or figure out how to have the modem do this automatic ringdown, or to create an outboard "leased line emulator" box to deal with this, and that approach probably just as much work to deal with -- and more likely to tip over.

Or you get the leased line, such as what's sometimes known as a ringdown line; a dedicated line.

Sorry.

On the plus side, reading off a database and sending email to the paging network or connecting more directly into a paging network or such is straightforward programming. If you're sending numeric pages, those can usually be sent from a touch-tone dial sequence, and that's easy and it requires minimal hardware.

I won't suggest Asterisk or VoIP, but that'll do this sort of stuff, too.

[Phil.Howell]

if the application is just sending a page down a serial line, you could almost regard it as a remote printer. I know we used to have ports for modems, printers, and consoles as lat services - have a look at "reverse lat" on this page
http://linux-decnet.sourceforge.net/lat.html
Phil

[James Ford]

In case I wasn't clear. As requested, the application is moving to another location(North Royalton Ohio) and the leased line is in Alpharetta,Ga connected to a DECServer 200.

[Doug Phillips]

Right, sorry, you did say that in your first post.

What you need to make clear, though, is what your new configuration will be. How will the Ohio and Ga locations be connected? What else will move and what will stay? Is the application going to a different system with the old system remaining? Is the old system moving?

If it's a "canned" application, you probably aren't the only one using it, so what application is it? Maybe someone here is using it, too. How LAT-specific is it? Is it still supported or do you have the source code and someone who can work on it? Is there enough budget that you could replace the 200 with an IP capable server? If you're working with $.00 budget, then someone has some unrealistic expectations.

You obviously need *some* connection between the locations and knowing what that is and what else you have to work with will determine what you need to do.

Since you're going around 700 miles I doubt that you could achieve a fast enough link to bridge LAT, or at least it doesn't sound like you have that kind of budget.

Connecting two remote DECservers is not the way to achieve what you want. You need to tell us more.

[James Ford]

The new system in NOR is a duplicate of the old system in APH, nothing is moving except the Software will be running in the new location as production. The old system is staying put as a back up in case of failure (DRP). The leased line can not be provisioned in time for the production move and there is reluctance to pay for two leased lines for a period of time. The application is called DISPATCH1 from ASTEA using PROGRESS database which is now called OpenEdge. The application is only supported in a minimum mode , the vendor is not wanting to support VMS any more, the newer versions won't run on VMS. Our company has made it a policy not to bridge LAT or DECNet. TCPIP is the only protocol to be used in WAN. So, reverse LAT is not an option. Frankly, I am at a loss as to how to connect a port of one server to another server to act as a pipe to the leased line. It seems the only parctical method is somehow connecting the two ports via TCPIP so that it looks like the application is sending its data to the DECServer port in the old location with the leased line. I don't know how to configure the ports to do this or if is is even possible. This may be an exercise in futility if it is not even possible to do.

[Robert Gezelter]

James,

First, the problem is that there little known about the use of the LAT protocol by this application. Without more information (some of which can be obtained by monitoring the serial outbound line), it is difficult to say with precision what will or will not work.

The "trick" that is possible in some cases is to leave the LAT termination local (e.g., the DECserver 200), wire the outgoing port to a different server that supports TCP/IP, and use an automatic telnet connection to a reverse telnet port on the remote server over the IP network. It is a little "Rube Goldberg", but if done carefully, it works.

If you are not comfortable with this, consider bringing someone in who is familiar with the intricacies of such a configuration. It is important to check this out carefully, as it can be a challenge to troubleshoot in the event of a network problem.

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

[James Ford]

I understand what Robert is saying in the sense I know how to set up a TCPIP capable terminal server port with a listener, say at the old site(I do this for the console manager) where I could move the leased line connection to a DECServer 300, but how would you configure the port on the DECServer in the new location to connect to the listener at the old location. Usually there is a program ie, console manager, which talks to the remote port listener but the DECServer port doesn't have that much logic. I don't know enough about I/O programming at the device level to know if it is possible to modify the Progress program to talk TCPIP to the remote port on the old location, right now all it does is treat the LTA device as an output file like streaming data to a printer.
What I would like to do is smtp mail but I don't know if there is enough info on my side to know which companies the pagers use, could be several, and whether they have an email/smtp location for sending pages. The vendor certainly isn't going to give me their table/xref then we wouldn't need their service.

[Hoff · Accepted solution]

Id suggest a look at the application source code, and a decision around the business case: the leased line, or reworking the old notification gear and the old software and then rebuilding it.

I see no (obvious) free lunch here.

Application code that calls into LAT can be anywhere from trivially simple to rewrite-it scale really-hairy. And the application itself is almost certainly old source code, given it's using DECserver 200 boxes.

Reworking and adding dial-up might be cheap, or it might be cheaper to use the leased line and not touch the existing code. You need to decide how much you want to spend, and on what, but you will be spending.

I've posted up some C code that sends out email under an MIT-style copyright, and that code can likely be adapted and used for these sorts of cases -- when the paging network supports email-based pages.

http://64.223.189.234/node/744

[Kelly Stewart_1]

James,

So, if I understand this, the application is considered critical enough that your company leases a dedicated line (and backs it up with a modem), but, for a transitional period, is willing to send the pages to that leased line through third-party Internet services. Why not switch to a modem-only system in Ohio, until the leased line is moved?

Programming for a LAT port is similar to programming for a local terminal port, with some code added for dealing with data-set hangups and broken LAT connections. The application can probably talk to a regular terminal port. If so, you could write a program that uses the pseudo-terminal device to replace the LAT port. It then transmits the port data over IP to a sister program in Georgia that sends it on to the LAT port. See the OpenVMS I/O User's Reference Manual chapter on pseudo-terminals.

If the vendor won't tell you the contents of the database (and it wouldn't hurt to ask!), you might be able to dump it. How do you maintain this database? If there's any kind of add/modify/delete capability, there should also be a way to list the entries.

You mentioned that your company isn't bridging DECnet. It is possible to transport DECnet over IP by using either DECnet-Plus or DECnet-IV with Multinet (and possibly other IP stacks). But I don't see how a DECnet connection really helps unless you can divide the application up across your two locations -- the main stuff in Ohio with the actual page transmitter software in Georgia.

Also note that some DECServer 200s, the "MC" models, have full RS232 modem-control signals, but (I believe) the DECServer 300s do not.

Good luck,
Kelly

[James Ford]

Thanks for the ideas, I need to do some more research into the replies and the application code.

[Jan van den Ende]

James,

>>>
possible to modify the Progress program
<<<

Is this as in 'programming around the Progess Database by Progress Software?

In that case some extra warnings are warranted:
"Progress: dropped support for "Progress on VMS" as per 1/1/01 (and devellopment some years before that).
Nowadays the company has NOONE anymore that knows about VMS.
That certainly means there is NO way you will ever be able to move this to I64 (and even Alpha V8 is and will remain unqualified).

(I have been in that same corner)

Proost.

Have one on me.

jpe

[Doug Phillips]

I don't think the database is relevant to your problem. It's the Dispatch-1 software that handles the link setup and does the communication, no? Isn't there a script or options file/record that tells it what device/port to use? I'd be surprised if it were LAT specific. Do you have a Dispatch-1 manual? Is there no one at Astea willing to help you?

You still haven't said if the two sites are connected in some way other than via Internet or POTS. Since you're talking DR, it seems likely you have something else, too.

Forgive me, but you seem to still be thinking about this from the LAT point of view. The DECserver ports are serial. DECservers are Ethernet devices. To connect two DECservers via their ports, you must extend a serial connection between them. To connect two DECservers on your network, you must extend Ethernet between them.

So far, Kelly Stewart has suggested the easiest way: Switch to a modem-only system in Ohio until you set up a leased line there (or until you come up with a better solution).

Since you're going for a DR setup, this would be a good time to look at how you can talk to your paging service provider some way other than with a non-redundant and not-easily switched leased line.

I really don't understand what you mean by "which companies the pagers use." Some pagers have telephone numbers. The phone company allocates numbers to the paging service provider who in turn assigns those numbers to the pagers. Others use a central PBX number and treat each pager like an extension. From a telephone, can you call a pager directly or do you call a central number and then enter a pager number?

Software like Dispatch-1 just provides an automated way to do the dialing and such.

[Walter Miller_1]

How does the LTA device get created? Are you supplying a terminal server name and port to the application which creates the LTA device or are you creating the LTA device and passing the LTAxxx name to the application?

If you are creating the device, it may be possible to move the leased line to a TCPIP enabled terminal server and create a TNAxxx device (telnet) to pass to the application.