LES@vaxi.UWO.CDN (10/22/87)
We have a problem with:
$ SET HOST/LOG=FOO.LOG/DTE TXK3:
That is, we are trying to capture, in FOO.LOG, the output of an interactive
session being conducted over TXK3. The session generates all kinds of
escape sequences for cursor addressing, bolding, etc. THE OUTPUT DISPLAYS
FINE during the interactive session, HOWEVER, some of the output being logged
to FOO.LOG is MISSING. Therefore, I have ruled out a communications problem
since the display on my terminal is okay. It seems as if SET HOST (RTPAD) is
receiving everything okay but is dropping a few characters when writing to
the log file. The characters being dropped appear random but often seem to
be ESCAPEs. We are currently running VMS 4.2. Anyone got any ideas?
Another question... Does anyone have an effective Virtual Terminal program
that they can send me? (i.e. Something that does effectively was SET HOST/DTE
does - but something we can have the source code to so that enhancements can
be added). Any versions over the net would be appreciated.
Les Flodrowski
Social Science Computing Laboratory
University of Western Ontario LES@UWOVAX.BITNET
or LES@VAXI.UWO.CDNeal@tut.fi (Lehtim{ki Erkki) (10/27/87)
We use SET HOST/DTE on our outgoing modem line and almost every
time our MicroVAX-II crashes with RTPAD as active task.
We have VMS V4.4.
Is that a known bug and is it patched in VMS V4.6?
--
Erkki A. Lehtim{ki eal@tut.uucppete@tsc.dec.com (Pete Schmitt) (10/29/87)
In article <472@tutor.tut.fi>, eal@tut.fi (Lehtim{ki Erkki) writes: > > We use SET HOST/DTE on our outgoing modem line and almost every > time our MicroVAX-II crashes with RTPAD as active task. > We have VMS V4.4. > Is that a known bug and is it patched in VMS V4.6? > > -- > Erkki A. Lehtim{ki eal@tut.uucp If you go to 4.6 it may fix your problem, but we would need more info on your configuration. -- \\\!/// From: Pete Schmitt _ _ UUCP: allegra!decwrl!tsc.dec.com!pete ( Q Q ) DECnet: tsc::pete ---,,,,-------U-------,,,,--- It's okay to say the U... word.
tencati@VLSI.JPL.NASA.GOV (Ron Tencati) (11/04/87)
At my site, we have noticed a bug in RTPAD that has existed since V4.4:
A user on some remote node does a SET HOST and logs onto my node, then once
logged in issues a SET HOST/DTE command to one of the out-going modem or asynch
LAN ports. RTPAD connects to the specified port, but there is some kind of I/O
error reported (exact text escapes me at the moment...). The user has a normal
session with the out-bound port, then types ^\ and logs off my machine.
According to my machine, the user is still logged in, NCP shows an active
link from the remote node, and the user process on my machine is running RTPAD
in some sort of loop that is consuming a LOT of CPU time.
I have had jobs consume inordinate amounts of CPU time when this bug is
activated. This behavior is about 75% reproducable.
I brought this issue up at the DECUS in SF last year, and I was told that "DEC
had recently discovered this problem, and they would look into it". That is
the last I heard from them.
This may be related to the problem you are having with RTPAD. I can't offer
you any solution, only provide you with my experience.
I don't know if this "feature" is fixed under V4.6, DEC???
Ron Tencati
System Mgr.
JPL-VLSI.ARPA
Jet Propulsion LaboratoryGraw@UNCAMULT.BITNET (Pete Graw) (05/17/88)
I am trying to hook an X.25 PAD up to an outgoing port on a VAX 11/785. I've got the two basically talking using set host/dte, but flow control doesn't seem to be working. What modes do I need to have set for the term port in order that CTS/RTS handshaking will work correctly? So far I've determined that I need the modem bit set so that the connection is correctly terminated when either end disconnects (using DTR/DSR). I would really love to get CTS/RTS going instead of XON/XOFF, so that the connections can be as invisible as possible. Also, instead of flow control, is there anything I can do to ensure that characters don't get lost, such as a higher process priority, larger buffers (in sysgen, and what parameter?), etc? Oh ya, all at 9600 baud. (In desperation, I figured I'd try XON/XOFF to see if atleast that worked, and of course, it didn't seem to. I must be off in left field on this...)
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (05/21/88)
I am trying to hook an X.25 PAD up to an outgoing port on a VAX 11/785. I've got the two basically talking using set host/dte, but flow control doesn't seem to be working. What modes do I need to have set for the term port in order that CTS/RTS handshaking will work correctly? There is no such setting; the VMS terminal driver does not support CTS/RTS handshaking. So far I've determined that I need the modem bit set so that the connection is correctly terminated when either end disconnects (using DTR/DSR). I would really love to get CTS/RTS going instead of XON/XOFF, so that the connections can be as invisible as possible. The only DEC equipment I know of that supports CTS/RTS handshaking is some recent terminal servers. You'd have to check the specs to determine which ones. Also, instead of flow control, is there anything I can do to ensure that characters don't get lost, such as a higher process priority, larger buffers (in sysgen, and what parameter?), etc? Oh ya, all at 9600 baud. Nothing except flow control will ENSURE that this will work - any buffers, any increase in priority, will be overrun by SOME bursts of characters. The best you can do is minimize it. Unless your system is very heavily loaded, increased priority probably won't make much difference; but a larger terminal buffer may help. The SYSGEN parameter TTY_TYPAHDSZ controls the size of the typeahead buffer. I would not, however, recommend increasing this: EVERY terminal will use that many bytes of physical - not virtual - memory for typeahead. On a large system, this can add up. Rather, set the SYSGEN parameter TTY_ALTYPAHD, the "alternate" typeahead buffer size; then set the terminal you will be using with SET HOST/DTE to /ALTYPEAHD/PERMANENT. This will cause that terminal line to use ALTYPAHD, rather than TYPAHDSZ, for the size of it's typeahead buffer. Note that once set, /ALTYPAHD cannot be cleared short or rebooting the system. (In desperation, I figured I'd try XON/XOFF to see if at least that worked, and of course, it didn't seem to. I must be off in left field on this...) How did you "try XON/XOFF"? Note that there are TWO setting of significance here: /TTSYNC is the parameter you usually think of; setting it says that an XOFF received by VMS causes it to suspend output, and an XON causes it to resume output. The converse is /HOSTSYNC, which says that VMS is to set XOFF when the typeahead buffer is (almost) full, XON when it empties out. Almost certainly, you are seeing problems when characters arrive from the PAD too quickly; so it is /HOSTSYNC you need. Further. THE PAD MUST RESPOND TO THE XOFF! This isn't a VMS issue - it's a question of whether your PAD responds to XON/XOFF from the async line it is connected to. It may not support this at all; or you may have to turn it on. It may also respond, but too slowly - at 9600 baud, a character arrives about every millisecond. If the PAD takes 100 ms to respond to XOFF, it may overrun VMS's buffer. (Things get even worse if there is a long "pipe" down which the characters must travel.) If it is slow response from the PAD that is the problem, an appropriate setting of TTY_ALTAHD, plus TTY_ALTALARM (which controls the point at which the terminal driver will generate an XOFF), should allow you to fix the problem. -- Jerry