SYS$ASSIGN sends characters to terminal

[Kerry Gibbings]

We are communicating with a process control computer via the terminal driver using a TNA device. When the program executes a SYS$ASSIGN, to establish a channel, spurious characters are sent. Can I stop this behaviour, if so how?

I64 OpenVMS 8.3-1H1

TCPIP> show version
  HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.6 - ECO 2  on an HP rx3600  (1.59GHz/9.0MB) running OpenVMS V8.3-1H1

Debug session of BASIC code

─ SRC: module LLBLINKASSIGN -scroll-source──────────────────────────────────────────────────────────────────────────────────────────   118: %PAGE

   119: %SBTTL "Main"

   120:         Exit Function SysStatus If LLBELnkAssign(oLLBLink, SysStatus)

   121:         SysStatus = SYS$ASSIGN(Trm$(PropGetLLBLink(oLLBLink, "Device")) &

   122:                               ,Chan, !acmode!, !mbxnam!)

-> 123:         If SysStatus And 1% Then

   124:            Call PropLetLLBLink(oLLBLink, "Channel", WordStr(Chan))

   125:            GoSub LATConnect If PropGetLLBLink(oLLBLink, "Protocol") = "L"

   126:         Else

   127:            Subs(1) = Trm$(PropGetLLBLink(oLLBLink, "Device"))

   128:            Subs(2) = Num1$(SysStatus)─ OUT -output───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────stepped in THREAD 1

LLBLINKASSIGN\LLBLINKASSIGN\SYSSTATUS:  1

LLBLINKASSIGN\LLBLINKASSIGN\CHAN:       816

TCPTrace of packet with spurious characters created as a result of the $ASSIGN

   TCPtrace XMT packet 101 at 18-JUL-2011 15:30:51.44

                         IP Address          Port            Seq #                Ack #    

  Source              10.123.1.202   62045    481560460      2172722896

  Destination         10.123.1.71     2102

                                                           Packet Length       46

   TCP flags            PSH ACK

        window           62780  

                                                               Hex        Count   Ascii

    --------         --------        --------         --------         ----      ----------------

   CA017B0A   E1B80680   0000E269   2E000045    0000    E...i........{..

   D01E8181    8C07B41C  36085DF2 | 47017B0A   0010    .{.G.].6........

           03FB    FF01FBFF | 00005EE6  3CF51850   0020    P..<.^........

Device is set up as TNA102

show term tna102 /full

Terminal: _TNA102:    Device_Type: Unknown       Owner: No Owner
   Input:    9600     LFfill:  0      Width:  80      Parity: None

   Output:   9600     CRfill:  0      Page:   24

     
Terminal Characteristics:

   Interactive        No Echo            Type_ahead         No Escape

   Hostsync           No TTsync          Lowercase          No Tab

   Wrap               Scope              No Remote          Eightbit

   No Broadcast       No Readsync        No Form            Fulldup

   No Modem           No Local_echo      No Autobaud        Hangup

   No Brdcstmbx       No DMA             No Altypeahd       Set_speed

   No Commsync        Line Editing       Overstrike editing No Fallback

   No Dialup          No Secure server   No Disconnect      Pasthru

   No Syspassword     No SIXEL Graphics  No Soft Characters No Printer Port

   Numeric Keypad     No ANSI_CRT        No Regis           No Block_mode

   No Advanced_video  No Edit_mode       No DEC_CRT         No DEC_CRT2

   No DEC_CRT3        No DEC_CRT4        No DEC_CRT5        No Ansi_Color

   VMS Style Input    <CTRL-H> Backspace

[Hoff]

There is no mechanism to disable this, because this should not happen; sys$assign should not generate any I/O to the output.  This looks like a bug (probably) in the IP stack.  Patch TCP/IP Services to current and also patch OpenVMS to current, then (if that doesn't clear this) ring up HP support for a look.  Or if you're in the typical environment with administrative restrictions around this sort of stuff, ring up HP support first, get (officially) told to patch to current, then (if that doesn't clear this) wait for HP to provide a fix.

[Kerry Gibbings]

Thanks Hoff, I must admit I was expecting this response. It took me quite awhile to convince myself that it was sys$assign causing the output. I still don't believe it but have run out of ideas.I did wonder, since the extra characters ends in ETX whether this was some sort of valid control sequence.

We can't go to 8.4 easily but I can get the system updated to the latest VMS and TCPIP patches.

[Volker Halle]

Kerry,

how are you creating the TNA device ?

Have you written/used this program on any other version of OpenVMS before or is the a new development ? With other words: did it ever work before ?

Volker.

[Kerry Gibbings]

Hi Volker,

That was on my list of things to include, pity I didn't.

$ TELNET/CREATE 10.123.1.71 2102 102/PERM/PROTOCOL=TELNET

$ SET TERM/PERM/TYPEAHEAD/PASTHRU/NOTTSYNC/EIGHTBIT/NOBROAD/NOECHO TNA102:

$ SET SECURITY/CLASS=DEVICE/PROT=(S:RWLP,O:RWLP,G:RWLP,W:RWPL) TNA102:

We've been using this software for 20+ years but have just started to notice the problem when replacing DecServers with IOLAN port servers. We have no proof but think that the DecServers might have filtered this out. It's not causing any harm just causing a delay in the handshaking between the 2 systems, that resync on the second attempt.

[Volker Halle · Accepted solution]

Kerry,

did you try creating the TNA device with /PROTOCOL=NONE ? Just as a test...

If I understand you correctly, your process control computer now sees 'additional unexpected characters' on it's serial line, after switching from using DECservers to IOLAN port servers.

Sending this call to HP may not yield an immediate solution, as in communication problems, where 2 sides are involved, you may be up to lengthy discussions...

Volker.

[Kerry Gibbings]

Thanks Volker,

That stops the extra characters. I have a felling of deja vu now.

[Ph Vouters]

Although the code is written in C language, would it be of any help for you ? Refer to TN.C and TN.H at http://vouters.dyndns.org/tima/OpenVMS-GNV-Alternate_DCL_image_using_a_Telnet_device.html with its usage inside DCL.C

[Ph Vouters]

Your /PROTOCOL=TELNET initiates a telnet subnegociation with the remote peer. This is why the /PROTOCOL=NONE is better advised if the remote peer does not handle this subnegociation. A excellent to view the sent/received characters is to run the tcpdump utility.. I do advise using tcpdump any time a TCP/IP communication between two peers does not give expected results. For an example of tcpdump usage under OpenVMS can be viewed at http://vouters.dyndns.org/tima/All-OS-Samba-Windows-Sharing-IP_ports_usage_with_Windows_sharing.html In the tcpdump command, you shall to adjust udp ports tracing to tcp ports tracing.

[Kerry Gibbings]

Thanks to all. We have now modified the port creation to protocol=none and synchronisation occurs on the first attempt without delay. The messaging protocol between the 2 systems contains it's own error detection so there should be no problems using raw mode.