DS90TL PROBLEM

[Randy Johnson_6]

I am in the process of converting one of our remote clients (in Wisconsin) over to our ASP Alpha in Illinois. They will have either a frame line or a VPN tunnel to us and will Telnet to us from a terminal emulator. The remote client is on a AlphaServer 800 5/400 running OpenVMS AXP V7.1-1H2 and MultiNet V4.1 Rev B. The ASP Alpha is an AlphaServer ES45 Model 2 running OpenVMS AXP V7.3-1 (soon to be upgraded to V8.3) and MultiNet V4.4 Rev A-X (soon to be upgraded to V5.2).

They also have a DS90TL that communicates with a Baker/Autoscript Drug Counting System. A detached process communicates with the Baker Cell via a VT terminal, which is connected to the DS90TL, by using the RS-232 printer port on the terminal.

My problem is: How can I communicate with the DS90L once the Alpha at the remote site is deinstalled?

Any and all help on this problem is appreciated..


Randy,

[John Gillings]

Randy,

>A detached process communicates with the
>Baker Cell via a VT terminal, which is
>connected to the DS90TL, by using the RS-
>232 printer port on the terminal.

What protocol does the detached process use to talk to the serial port on the DS90TL? It could be LAT or TCPIP. If it's LAT you'll need to change your code, and the DS90TL configuration to use TCPIP instead (Although there were once bridges which could be used to extend LAT across wider networks, this is not somewhere you want to go today!)

If the code is already talking TCPIP, it might not need any modifications at all, just make sure there's an IP path from the host Alpha to the DS90TL.

When doing this kind of thing, it's important to start as simple as possible, so start by putting a VT terminal on a spare port on the DS90TL, then from the host just make sure you can communicate with a person at the terminal with simple READs and WRITEs. Once you've got that down working, THEN worry about the printer port and talking to the counter gizmo.

Once it's working, make sure you have a backup of the DS90TL configuration - both binary and screen dump printouts. You'd be amazed how many times an old DS fails after a decade or two of continuous uptime, and noone has the slightest clue how it was configured (well, actually you'd be even more amazed at how FEW of these things ever fail, but when it happens, there are no backups, and the last guy who could even name the box was retrenched in 1996, and the boot node, VAX, was decommissioned in 1998).

[Randy Johnson_6]

John,

We are currently using LAT via LTA device. Will the LTA device change to a different device using TCPIP? If so, how do I set it up?

What changes would have to be made to the code other than pointing to a TCP/IP device instead of the LTA device?

Is there any documentation on how to setup the DS90TL for Telnet??

Randy,

[Hoff]

This question comes up fairly regularly in the context of switching from LAT to telnet-based network printers.

In general, telnet is a fairly good match for LAT, but there are some things that LAT can do that telnet can't. And there are some low-level differences, and a plethora of API-level differences for those applications that are using $qio-level calls directly.

The port might be mostly straight over, or you might end up working on some code.

>>>We are currently using LAT via LTA device. Will the LTA device change to a different device using TCPIP? If so, how do I set it up?<<<

It'll probably be a TN device. Telnet.

How you set it up varies, based on what the application is doing with LAT and with the I/O channel.

>>>What changes would have to be made to the code other than pointing to a TCP/IP device instead of the LTA device?<<<

It really depends on what the device and what the application are doing.

If the application is using LAT-level $qio calls, for instance, you'll have to change the code.

If the application is opening up the port and performing in-band I/O, it'll probably come across with a few changes needed.

>>>Is there any documentation on how to setup the DS90TL for Telnet??<<<

The DECserver manual covers this setup and configuration in some detail. You should be able to find DECserver manuals over at the DNPG web site. (www.dnpg.com)

here's a little related reading:
http://64.223.189.234/node/288

If you're in a hurry, there are bridges available for LAT and DECnet Phase IV and other such classic protocols; that connect these over an IP backbone.

Check your source code. See what it's doing.

[John Gillings]

Randy,

>What changes would have to be made to the
>code other than pointing to a TCP/IP
>device instead of the LTA device?

Probably a complete rewrite. Broadly, there are two ways the application may have been written.

1) The "correct" way
2) The "quick and dirty, mostly works" way

1) If it's been coded correctly with all the right $QIOs to create and connect the LAT device, then you'll need to throw it all away and replace it with the equivalent TCPIP functions. As Hoff says, there is no simple one-for-one mapping between LAT and Telnet.

2) Some applications relied on LATCP to create a LAT device, and then ran a program which used the LTA device as if it were a serial port or file. Strictly speaking, this was unsupported, and not guaranteed to work because there was no certainty about how the connection was established, or how it might behave in the presence of other LAT devices mapped to the same physical port. In most cases it would "work" if the initial operation on the LTA device was a WRITE. It would NEVER work if the initial operation was a READ - think about it.

Although TELNET/CREATE can create a TN device, which you might *think* is similar to an LTA device created with LATCP, you cannot use the TN device in the same manner as an LTA device, so again you probably need to rip out all the code, and replace it with TCPIP stuff.

If you have a 2) type program, there is a 3rd option... using the pseudo terminal driver, you can setup a pair of pseudo terminals "back to back" with a process in between shovelling data across. Your program can read and write one side, and the other side can be logged in and telnet to the remote end. It's a rather ugly hack, since you end up with three processes doing the work of one, BUT it has the advantage that you don't need to change your original application. Somewhere around I have a program called "WIRE.C" which effectively implements the software "cable" between the two pseudo terminals. I wrote it to replace a physical cable between two serial ports used to fix a similar situation to yours - an application expecting a serial port, which I wanted to run across a telnet session. At the time I thought it one of the most pointless programs imaginable, but it's been used several times in circumstances similar to yours. Definitely not recommended...

[Andreas Vollmer · Accepted solution]

Hi Randy,

I would like suggest following...

1) How to deal with load request of the Terminal Server?
- I could provide you with some old DEC terminal server SW for Windowsin order to provide a load host => DEC Netrider.
But no guaranty it will work with Windows 2000 or higher or with your terminal server.
In case this will not work try an Lantronix Box. This will work without any load host and is affordable.
http://www.lantronix.com/device-networking/external-device-servers/uds-10.html

2) Why not use and unused terminal server port and configure it for TCP/IP.
Then do some tests and try.
If the code change is possible or what ever, maybe you can use logicals which are pointing to a telnet printer queue?

I will provide some sample scripts with terminal server cmds of how to setup TCP/IP and telnet on DECserver.
I am looking forward for your feedback.
Regards
Andreas

[Randy Johnson_6]

Thanks for the replies, which are very useful.

Andreas, thanks for the attachments on how to set up the DS90TL to use Telnet..

I am going to leave this open for awhile. Hopefully, I can rearrange my priorities so that I can do some testing on this in the near furture..

Randy,

[Randy Johnson_6]

I am now going to try this..
Andreas - I downloaded the ZIP file from your message on 10/19/07 but I am not able to UNZIP it. Can you attach it in a different format or EMail it to me??

Randy,

[Rob Leadbeater]

Hi Randy,

Not entirely sure if this is what you need, but you'll find the owners manual for the 90TL here:

http://vt100.net/mirror/mds-199909/cd2/network/dsrveom1.pdf

Cheers,

Rob

[Steven Schweda]

> I downloaded the ZIP file from your message
> on 10/19/07 but I am not able to UNZIP it.

Downloaded how? Which UnZip ("unzip -v")?
I did it using SWB ("Mozilla/5.0 (X11; U;
OpenVMS COMPAQ_Professional_Workstation;
en-US; rv:1.7.13) Gecko/20060506") with no
trouble:

alp $ unzip -l 294722.ZIP
Archive: ALP$DKA0:[SMS.ITRC]294722.ZIP;1
Length Date Time Name
-------- ---- ---- ----
1545 10-04-96 08:36 DS_tcp_echo.TXT
11194 10-19-07 23:30 PF_DS90m_Setup Idea.txt
69 03-05-03 14:20 DS_TS_Support.txt
3411 11-03-04 22:22 DS_telnet_printer.TXT
4490 10-04-96 07:54 DS_telnet_Port.TXT
2228 10-04-96 08:34 DS_telnet_break.TXT
5677 10-04-96 08:33 DS_TCP_setup.TXT
4134 10-04-96 08:35 DS_tcp_remote_cons.TXT
4965 10-04-96 08:31 DS_tcp_port.TXT
19719 10-19-07 23:35 README DEC ASM-SW.TXT
-------- -------
57432 10 files

That's "UnZip 5.52 of 28 February 2005, by
Info-ZIP. [...]", "Compiled with DEC C
V6.5-001 for OpenVMS (V7.3-1 Alpha) on May 18
2005.".

As usual, "I am not able" is not a useful
problem description.