connect two decservers

[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.