topic Re: DECserver Comms Problem in Operating System - OpenVMS

DECserver Comms Problem

Niall Godwin — Tue, 18 Jul 2006 05:58:51 GMT

We have an issue with loss of communications on a DECserver 90M+.

The DECserver is being used to collect RS-232 data from a printer port on a DEC 4000-90A.

The port outputs approximately 1 line of serial "printer" text every 4-5 Seconds.

This is buffered for about 1 day if communication to the DECserver is lost.

The DECserver port is configured as follows:
Port 1: NONE
Server: DS1501
Character Size: 8
Flow Control: XON
Parity: None
Stop Bits: Dynamic
Input Speed: 9600
Output Speed: 9600
Signal Control: nabled

Access: Dynamic
Backwards Switch: None
Break: Remote
Forwards Switch: None
Default Protocol: LAT
Autolink Timer One:10 Two:10
Local Switch: None
Name: OWP1_2
Session Limit: 4
Type: Soft
Default Menu: None
Dialer Script: None
(Current) Groups: 0
Preferred Service: None
Authorized Groups: 0
Enabled Characteristics:
Autoconnect, DTRwait, Input Flow Control, Output Flow Control

AlphaServer LAT port charateristics

Input: 9600
Output: 9600
LFfill: 0
CRfill: 0
Width: 80
Page: 24
Parity: None
Passall
No Echo
Type_ahead
No Escape
Hostsync
Wrap
No Broadcast
No Modem
No Brdcstmbx
No Commsync
No Dialup
No Syspassword
Numeric Keypad
No Advanced_video
No DEC_CRT3
VMS Style Input
TTsync
Hardcopy
No Readsync
No Local_echo
No DMA
No Line Editing
No Secure server
No SIXEL Graphics
No ANSI_CRT
No Edit_mode
No DEC_CRT4
Lowercase
No Remote
No Form
Autobaud
No Altypeahd
Overstrike editing
No Disconnect
Soft Characters
No Regis
No DEC_CRT
No DEC_CRT5
No Tab
No Eightbit
Fulldup
No Hangup
Set_speed
No Fallback
Pasthru
No Printer Port
No Block_mode
No DEC_CRT2
No Ansi_Color

This serial print data is being sent over a site LAN to an AlphaServer via LAT.

The data is being used by a logging application running on the Alpha.

The application stores the lines of text in a file for later review.

The application also resets the port of the DECserver when the application is stopped and restarted.

The DECserver connection to the Alpha is via RJ45 to a CISCO switch.

The issue is that once the DECserver is configured and initialised it passes the
RS-232 data through OK but ceases after 5-10 Mins.

The handshake from the Port on the DECserver to the printer port on the DEC 4000-90A is lost and thus that stops transmitting / Printing.

At the same time the LAN LED on the DECserver also goes out, suggesting loss of network.

However all other devices connected to the CISCO router continue working without any interruption suggesting the issue is with the DECserver.

To get it functioning again the DECserver needs to have its power cycled and the
logging application on the AlphaServer stopped and restarted.

Any ideas?

Re: DECserver Comms Problem

Karl Rohwedder — Tue, 18 Jul 2006 06:45:40 GMT

Perhaps there is really a problem with the DECserver. Have you checked the server, e.g. with a terminal, if it is functioning when the LED goes out?
We also use a lot of DS90 to access BDE terminals and I noticed a difference in port settings, as our ports are all :
- session limit 1
- type hard
- access remote
- only XON/XOFF flowcontrol

ergards Kalle

Re: DECserver Comms Problem

Wim Van den Wyngaert — Tue, 18 Jul 2006 06:54:25 GMT

Before the LED goes out : show server count
might reveal errors.

Wim

Re: DECserver Comms Problem

Mike Kier — Tue, 18 Jul 2006 07:02:35 GMT

>Access: Dynamic
>Backwards Switch: None
>Break: Remote
>Forwards Switch: None
>Default Protocol: LAT

>However all other devices connected to the CISCO router continue working without any interruption suggesting the issue is with the DECserver.

I'm surprised it worked at all... LAT is not a routable protocol. Was the Cisco set for bridging and was bridging stopped at some point?

Re: DECserver Comms Problem

Niall Godwin — Tue, 18 Jul 2006 08:15:56 GMT

Just to add that it is unlikely to be a DECserver hardware problem. We tried two DECservers (both new/refurbished) with the same result.

Re: DECserver Comms Problem

Andy Bustamante — Tue, 18 Jul 2006 11:24:52 GMT

>> Break: Remote

Just a WAG, Is it possible for your "printer" application to send a break? You can try disabling break functionality.

Andy

Re: DECserver Comms Problem

Volker Halle — Wed, 19 Jul 2006 01:57:16 GMT

Niall,

to watch the status of the port on the DECserver use:

Local> SHOW PORT 1 STATUS

You'll see things like Input/Output Xoffed etc.

Local> SHOW PORT 1 ALL
Local> SHOW SESSION ALL

should show, if the LAT session to the Alpha is still established.

MC LATCP> SHOW PORT LTAx: also should show, whether the LAT session still exists (actual node/port name should be non-blank).

Local> SHOW SERVER STATUS or COUNTER may show errors on the server.

Can you connect to the DECserver using MOP ? Does it continue to work, once the server 'has problems' ?

Volker.

Re: DECserver Comms Problem

Niall Godwin — Thu, 20 Jul 2006 03:31:46 GMT

Mike,
Re:
I'm surprised it worked at all... LAT is not a routable protocol. Was the Cisco set for bridging and was bridging stopped at some point?

Read "switch" instead of router in:
"However all other devices connected to the CISCO router continue working without any interruption suggesting the issue is with the DECserver"

Apologies for that.
Niall

Re: DECserver Comms Problem

Jon Stanley — Fri, 21 Jul 2006 07:51:40 GMT

Niall,

I think I know the problem you are seeing and it is a bug in the 90M+ DNAS code. I see you posted all the characteristics of the port and LAT service, but you did not post the DNAS version and the ROM code version.

Can you contact me via my email account and I will see if I can get you the patch.

Thanks, Jon Stanley

Re: DECserver Comms Problem

Niall Godwin — Fri, 21 Jul 2006 10:35:10 GMT

Jon,

DNAS V2.5 BL51 for DS90M+

ROM 1.4

Niall

Re: DECserver Comms Problem

Niall Godwin — Fri, 21 Jul 2006 10:41:55 GMT

Jon,
Your email address is not available in your profile.
Can you email me at niall.g.godwin@gsk.com
Thanks,
Niall

Re: DECserver Comms Problem

Niall Godwin — Tue, 22 Aug 2006 13:52:30 GMT

I upgraded the ROM and DNAS - thanks Jon -
Initially, we thought this had solved it but then communication was lost again.

We're parking the problem for the moment.

Thanks to all for your suggestions.

Niall Godwin