topic DS90TL PROBLEM in Operating System - OpenVMS

DS90TL PROBLEM

Randy Johnson_6 — Wed, 17 Oct 2007 17:23:17 GMT

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,

Re: DS90TL PROBLEM

John Gillings — Wed, 17 Oct 2007 17:49:43 GMT

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

Re: DS90TL PROBLEM

Randy Johnson_6 — Thu, 18 Oct 2007 10:48:07 GMT

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,

Re: DS90TL PROBLEM

Hoff — Thu, 18 Oct 2007 11:09:54 GMT

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.

Re: DS90TL PROBLEM

John Gillings — Thu, 18 Oct 2007 18:15:12 GMT

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

Re: DS90TL PROBLEM

Andreas Vollmer — Fri, 19 Oct 2007 16:54:09 GMT

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

Re: DS90TL PROBLEM

Randy Johnson_6 — Wed, 24 Oct 2007 16:47:48 GMT

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,

Re: DS90TL PROBLEM

Randy Johnson_6 — Mon, 23 Jun 2008 16:59:09 GMT

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,

Re: DS90TL PROBLEM

Rob Leadbeater — Mon, 23 Jun 2008 17:23:50 GMT

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

Re: DS90TL PROBLEM

Steven Schweda — Mon, 23 Jun 2008 17:26:43 GMT

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

Re: DS90TL PROBLEM

Randy Johnson_6 — Mon, 23 Jun 2008 17:30:08 GMT

I have downloaded the manual.

Andreas provided some sample scripts with terminal server cmds of how to setup TCP/IP and telnet on DECserver. I am assuming it is in his attachment...

Re: DS90TL PROBLEM

Randy Johnson_6 — Mon, 23 Jun 2008 18:29:26 GMT

I doubled click on the attachment, saved the file to my desk top, FTP'ed the file to my Alpha in both text and binary mode. I am using UNZIP 5.42 by Info-ZIP..

In text mode I get:
UNZIP52 -l DS90TL_TCPIP_CMDS_TEXT.ZIP

Error: zipfile is in variable-length record format. Please
run "bilf l DGA3:[SXC_CIGNA_PROD]DS90TL_TCPIP_CMDS_TEXT.ZIP;1" to convert t
he zipfile to stream-LF
record format. (BILF is available at various VMS archives.)
NOTE: I am trying to find BILF

In binary mode I get:
UNZIP52 -l DS90TL_TCPIP_CMDS_BINARY.ZIP
Archive: DGA3:[SXC_CIGNA_PROD]DS90TL_TCPIP_CMDS_BINARY.ZIP;1
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in ds90tl_tcpip_cmds_binary.zip,
and cannot find DGA3:[SXC_CIGNA_PROD]DS90TL_TCPIP_CMDS_BINARY.ZIP;1.zip,
period.

Steven - Could you EMail me the *.TXT files??

Randy,

Re: DS90TL PROBLEM

Hoff — Mon, 23 Jun 2008 20:11:23 GMT

This with unzip 5.42? Really? (I thought only HP was using zip and unzip that ancient and that buggy.)

Try it again with unzip 5.52 (current released version), and see if you get any further. The more recent versions have cleaned up a whole lot of "fun" with the tools...

The pre-built image versions of zip and unzip found on the OpenVMS Freeware V8.0 distro (see http://mvb.saic.com/) were deliberately built against very old OpenVMS releases, so they should work on most anything folks might have)

As for ftp, it's binary transfers all the way.

Re: DS90TL PROBLEM

Hoff — Mon, 23 Jun 2008 20:16:48 GMT

If you're downloading with a web browser, some of the web browsers can make odd ftp transfer choices. In particular, there are some differences in the defaults for unrecognized file extensions; browser-based zip file downloads need to be binary. Put another way, if this is Windows and IE, try Firefox. If this is Windows and Firefox, try IE.

I just downloaded the zipped attachment on a Mac OS X box running Safari, and it unpacked just fine.

If you're doing direct manual binary ftp downloads from ITRC, then ignore this.

Re: DS90TL PROBLEM

Randy Johnson_6 — Mon, 23 Jun 2008 20:42:27 GMT

How do I do a "direct manual binary ftp downloads from ITRC" ????

Randy,

Re: DS90TL PROBLEM

Randy Johnson_6 — Mon, 23 Jun 2008 20:58:46 GMT

I tried unzip 5.52 and got the same error messages..

Randy,

Re: DS90TL PROBLEM

Steven Schweda — Mon, 23 Jun 2008 21:19:33 GMT

> I doubled click on the attachment,

So, you're running some version of some Web
browser on some system of some type?

> saved the file to my desk top,

Ah. _Now_ I understand. A system of some
type which has some relationship with your
desk. Thanks for clearing that up.

> How do I do a "direct manual binary ftp
> downloads from ITRC" ????

You might just run a Web browser on your VMS
system. It worked for me. Or try something
like:

wget http://antinode.info/ftp/misc/294722.zip

Or do whatever you need to do to keep your
(unspecified) Web browser from corrupting the
file as it's downloaded from the ITRC.

Re: DS90TL PROBLEM

Rob Leadbeater — Mon, 23 Jun 2008 21:20:39 GMT

Hi Randy,

I think it's an IE7 problem... I get "The Compressed (zipped) Folder is invalid or corrupted" using XP's built in zip handling, after downloading the attachment via IE7.

Downloading the same file with Firefox, or Perl's lwp-download and it unzips fine with XP.

Cheers,

Rob

Re: DS90TL PROBLEM

Randy Johnson_6 — Tue, 24 Jun 2008 15:50:52 GMT

Rob, you hit it on the head.. Since my company will not allow me to install Firefox on my office computer, I installed it om my home PC and downloaded the zip attachment. I copied it to a stick and downloaded it to my Alpha and Unzipped it with no problem..

Now the fun begins setting up the DecServer for TCP/IP and accessing the ports..

Randy,

Re: DS90TL PROBLEM

Verne Britton — Thu, 26 Jun 2008 21:34:16 GMT

if you have a Multinet support contract with Process, they may have some ideas too :-)

Verne
(happy Multinet user)