Value coming out of a terminal server port

[Art Wiens]

This isn't necessarily VMS related but ...

We have a VAX (v6.2) system which, via LAT, sends a "message" to a terminal server (DECserver 90M) port. This serial port is connected to COM1: connector of a pc (Red Hat Linux). An application on the RH box listens for messages on COM1:, reformats them to TAP protocol (for paging) and sends it out it's COM2: port to the paging provider.

We are having issues where some pages are not being delivered to the field. There is a particular related communication sequence (listed below) which I have the paging provider looking into, but in addition, there seem to be regular occurences of the RH box logging eg:

2008-01-30-11:23:11 From COM1: BFFFF4B0

Does anyone have a clue what this value coming from a t/s port might mean? I've looked in some old logfiles and this didn't use to happen. Not sure if it has anything to do with the issue at all, but when it "fails" there are numerous.

Cheers,
Art

The failure from the RH app log:

2008-01-30-11:18:33 From COM1: BFFFF4B0
2008-01-30-11:18:33 Send COM1:
2008-01-30-11:18:57 From COM1: BFFFF4B0
2008-01-30-11:18:57 Send COM1:
2008-01-30-11:19: 1 From COM1: BFFFF4B0
2008-01-30-11:19: 1 Send COM1:
2008-01-30-11:19: 5 From COM1: BFFFF4B0
2008-01-30-11:19: 5 Send COM1:
2008-01-30-11:19: 9 From COM1: BFFFF4B0
2008-01-30-11:19: 9 Send COM1:
2008-01-30-11:19:13 From COM1: BFFFF4B0
2008-01-30-11:19:13 Send COM1:
2008-01-30-11:19:17 From COM1: BFFFF4B0
2008-01-30-11:19:17 Send COM1:
2008-01-30-11:19:21 From COM1: BFFFF4B0
2008-01-30-11:19:21 Send COM1:
2008-01-30-11:19:25 From COM1: BFFFF4B0
2008-01-30-11:19:25 Send COM1:
2 minutes of silence ... then
2008-01-30-11:21:21 From COM1:
2008-01-30-11:21:21 Send COM1:
2008-01-30-11:21:25 From COM1: BFFFF4B0
2008-01-30-11:21:25 Send COM1:
2008-01-30-11:21:39 From COM1: ... and it starts working again.

[Art Wiens]

The terminal server counters ... please see attached.

Art

[John Gillings]

Art,

The trouble with LAT is it will often "work" even though the programs aren't really complying with the protocol.

A typical example is where LATCP is used to create a LTA device, and a program just opens a channel to it and starts reading and writing. Strictly speaking, the program should use the LAT driver to establish the connection, but most of the time, provided the program WRITEs to the port first, it will work.

However, if there are other entities in the network also writing to the same LAT port you may get some odd things happening.

One way you might be able to "easily" fix any suspect use of LAT protocol is to redefine the port to be a serial printer adn simple PRINT your messages. Let LATSYM do all the protocol stuff for you. This may not even need changes in a program that writes to an LTA device, just SPOOL the device (what it WON'T work for is a program that expects to be able to READ from the LTA device).

If none of this makes sense, please post more detail... for example, how the message is sent, any commands used to configure the LTA device, LATCP SHOW PORT, and the port configuration from the terminal server.

It might also be interesting to know how long this application has been running, and if this peoblem is a new phenomenon. I know some network equipment suppliers detest LAT with a passion ("what idiot invented a non-routable protocol!?") If your network path traverses any intermediate routers, make sure they're correctly configured to deal with LAT.

[Hoff]

Um -- and only half in jest -- I'm supposed to trust the output from an application program that can't manage to format a time value correctly? :-)

But seriously, spend some time and figure out what's going on with the traffic, both out from the application and in-bound into the RedHat application.

This could be pretty much anything, from one end of the path to the other.

Do also look and see if anything interesting happens over on the DECserver console port. I've seen some serious weirdness with serial communications, when the speeds are off, when the frames slip and when the devices involved see a restart sequence.

If it were not feasible to sort this out (and if tapping into the communications isn't feasible), I'd probably look to migrate to something shorter and less-involved than what's in use here.

[Volker Halle]

Art,

does the OpenVMS VAX application have any kind of log, debug or trace functionality, which could also be enabled ?

Volker.

[Kelly Stewart_1]

Art,

Just a thought: if your VAX has a TCP/IP stack and an internet connection, you may consider simply e-mailing the message to your paging provider - assuming this is a typical commercial provider. Most have an e-mail interface these days, usually with the pager number as the username and the paging company as the domain. It would be a much simpler configuration. There also is, or was, commercial software to call a paging service from VMS (so you would plug the terminal server port into a modem instead of the PC), but it was a bit pricey.