SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (10/23/87)
Info-Kermit Digest Fri, 23 Oct 1987 Volume 6 : Number 24
Departments:
ANNOUNCEMENTS -
RE: Info-Kermit Digest V6 #23 Multiple Copies
Kermit HEX file for the Amstrad PCW
MS-DOS iRMX Kermit Documentation
MS-DOS KERMIT -
Use of Kermit by the Disabled
Space Key on MS-Kermit 2.29c
MS Kermit 2.29C Report or Query
Problem with Input Translation and 'SET DISPLAY 7'
Kermit 2.29C VT-102 Emulation
Kermit-MS v2.29c
MS-Kermit 2.29c Comments
Kermit with Zenith COM3
Printing through a PC (2 messages)
MACINTOSH KERMIT -
MacKermit, Key Redefinition
MacKermit 0.8(35) bug?
Mac Kermit CKMKEY & XKMKEY
MacKermit 0.8(35) Can't Save Settings File
Mac .HQX files
MISCELLANY -
Thanks on CONNECT.PASVT100
Kermit Versions and Packet Size
VMS: No Default Terminal Line for Transfers
----------------------------------------------------------------------
Date: Wed 14 Oct 87 15:19:29-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: RE: Info-Kermit Digest V6 #23 Multiple Copies
Keywords: Info-Kermit Digest
You may have gotten 2 different versions of Info-Kermit Digest V6 #23.
The first digest was sent out and was lost somewhere in the network.
Meanwhile, thinking that digest was not sent out, I added some other
messages and sent out yet another version of the digest. Sure enough,
both copies got sent. Keep the latest copy (with the German documentation
message in it). I apologize for any inconvenience this may have caused.
------------------------------
Date: 15-OCT-1987 13:34:27 GMT +01:00
From: SYSKERMIT%vax1.central.lancaster.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: Kermit HEX file for the Amstrad PCW
Keywords: Amstrad PCW
The system-dependant HEX file for the Amstrad PCW was sent to us by
Phil Wade of Hull University computer centre.
Regards,
Steve Jenkins.
[Ed. - Thanks Steve and Phil. This HEX file is in KER:CP4PCW.HEX available
from Arpanet by FTPing to CU20B, user ANONYMOUS (any password) and GETting
the file or thru BITNET using KERMSRV.]
------------------------------
Date: Tue, 22 Sep 1987 09:00 PDT
From: JAFW801%CALSTATE.BITNET@wiscvm.wisc.edu (Jack Bryans)
Subject: MS-DOS iRMX Kermit Documentation
Keywords: iRMX Kermit, MS-DOS Kermit
MSKERMIT, the richest and most widely used implementation of KERMIT for the
small computer, has been ported to iRMX86 and iRMX286. The .DOC file
discusses differences between KERMIT and MSKERMIT, where KERMIT refers to
the RMX version and MSKERMIT refers to the DOS program. Users unfamiliar
with MSKERMIT may prefer to read this in conjunction with MSKERM.DOC.
[Ed. - Thanks Jack! The file is in KER:MSTRMX.DOC.]
------------------------------
Date: Tue 20 Oct 87 09:51:19-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Use of Kermit by the Disabled
Keywords: MS-DOS Kermit 2.30, Disabled
In preparing version 2.30 of MS-DOS Kermit for release, we are trying to
make the program as useful as possible for people with disabilities like
motor impairment, blindness, or deafness. This program provides terminal
emulation and file transfer for PCs in the IBM PC family, for IBM
compatibles, the DEC Rainbow, and many other MS-DOS systems, and it is
available free of charge by copying from someone who has it, downloadable
over networks and BBS's, or by mail order for a modest distribution fee
from Columbia University or various diskette services. There are
several factors that could inhibit Kermit's use by the disabled:
. The escape sequence to get back to Kermit after connecting to a remote
system is Control-Rightbracket followed by C. People who can only press one
key at a time should not be required to enter control sequences. Similarly,
people with only one hand should not be expected to type control characters
beyond their reach. The new release will allow the Kermit escape-back or
other CONNECT-level escape commands to be assigned to single keys, like F1.
So far so good.
. The screen display during file transfer has fields for the filename,
the number of packets transferred so far, the number of bytes, etc. These
fields are updated randomly, so that Kermit's output during file transfer
would make little sense when redirected to a Braille or voice device. SET
DISPLAY SERIAL remedies this.
. During terminal emulation, Kermit bypasses DOS and the BIOS and writes
directly to screen memory. This would also bypass any special drivers
installed by people with voice or Braille output devices. The command SET
TERMINAL NONE turns off terminal emulation and uses DOS for all screen
writes, allowing DOS or BIOS-level drivers to be used.
. In order to allow the widest possible range of key redefinitions, Kermit
uses the BIOS to obtain key scan codes, thus bypassing any DOS-level console
drivers, like ANSI.SYS (but not BIOS-level drivers like SuperKey and
ProKey). Kermit can be directed to use DOS to obtain key codes, but then
the distinction is lost between various keys (like the digit "2" above the
"Q" and "W", and the digit "2" on the numeric keypad). However, when DOS is
used, there is an apparent problem in DOS itself when multiple characters
are assigned to a single key (involving nonblocking character reads). Thus
BIOS-level keyboard handling could potentially bypass DOS-level drivers
distributed with special keyboards, but DOS-level drivers could have
annoying restrictions.
Please help us to make the program as useful as possible by answering the
following questions (or offering any other comments):
1. If you are directing screen output to a voice, Braille, or other device,
please let us know what the device is, how the redirection is done, and (if
you know it) whether the redirection is at the DOS, BIOS, or hardware level.
Also, are there screen drivers for the deaf that translate sounds (like the
terminal beep) into special visual effects? Again, at what level do they
operate?
2. If you have a special keyboard, keyboard replacement, or keyboard driver,
please let us know about it. Does the driver operate at the DOS, BIOS, or
hardware level? Does the device look like a real keyboard to the system's
BIOS?
3. What about TDD modems? Clearly, Kermit or other ASCII-based
communication programs are not compatible with Baudot-only TDD systems.
Translating between ASCII and Baudot is not a practical solution, because
the ASCII alphabet is more than twice the size of Baudot. Packet-mode
file transfer would be impossible because the Kermit packets could not be
uniquely reconstructed on the receiving end. Presumably there is movement
in the TDD world away from Baudot to ASCII code?
4. Any other considerations we may have overlooked?
Thanks for your help!
Frank da Cruz
Columbia University
Center for Computing Activities
612 West 115th Street
New York, NY 10025 USA
Network addresses:
SY.FDC@CU20B.COLUMBIA.EDU (Internet)
FDCCU@CUVMA (BITNET)
...uunet!columbia!cu20b!sy.fdc (Usenet)
------------------------------
Date: Tue, 22 Sep 1987 09:36 CDT
From: William Bruce Curtis <NU024414@NDSUVM1>
Subject: Space Key on MS-Kermit 2.29c
Keywords: MS-DOS Kermit
There seems to be an error in the show key command for mskermit 2.29c.
Space, ctrl-space, alt-space and shift space all show up as the same scan
code. This is also true for the scan program that was mentioned in the
lastest digest (msuchk.boo). We have an application where we want to define
alt-space to somethng else.
Thanks,
Bruce
[From jrd - ALT/Control/Shift Space all yield the same scan code. True. The
IBM Bios says the space bar is unaffected by these modifier keys and Kermit
uses largely what the Bios reports. There are plenty of modified Function keys
around (some nearly out of reach above normal keys).]
[From jrd - While on this subject, there have been several requests to allow
the RETurn key to be separated from a duplicate found on some numeric keypads.
This seems reasonable until the regular RET key is undefined and then it sends
nothing at all! Overall, this is a messy situation because Kermit has no
advance information about the keyboard and which keys send what. Not only
that, but the duplicate RET may even return the same scan code as the regular
key, depending on which keyboard is being examined. I've tried my machine with
and without this feature and have ended by cursing it when I've undefined it
once too often without thinking. The subject is not entirely closed but the
odds are not favorable for a neat solution.]
------------------------------
Date: Thu, 24 Sep 87 16:59 EST
From: "GLENN EVERHART, 609 486 6328" <EVERHART%ARISIA%rca.com@RELAY.CS.NET>
Subject: MS Kermit 2.29C Report or Query
Keywords: MS-DOS Kermit
I have been attempting to create a MSKERMIT.INI file for the 2.29c rev of
Kermit and have hit what appears to be a brick wall. The keypad I want to
create basically uses the bottom 4 rows of the IBM AT keypad to look exactly
like the bottom 4 rows of a VT100 keypad, with PF1 thru PF4 mapped to F1-F4 and
F7-F10 acting as arrow keys. This is a particularly easy configuration to
remember and use.
In 2.29b and earlier, SET KEY SCAN could be used this way since the keypad 5
key had a different scan code from the 5 key above the main keyboard. In 2.29c
this appears to have changed. Moreover, it's not clear that ANY definition is
now possible to recapture this desirable behavior, since SHOW KEY now shows the
two "5" keys alike (note I have to be in numlock mode to get any scan code back
at all).
I'd like to request that some disambiguating method be re-inserted in the code
if possible before 2.30 is frozen. It's very handy to have access to all the
keys, in spite of the IBM screwups in the keypad 5 key case.
Glenn Everhart
Everhart%Arisia.decnet@ge-crd.arpa
[From jrd - The most recent version separates the keypad items from the
typewriter top rank aliases, such as the numbers. Of course, keypad 5 was
damaged by IBM so to use it at all the keypad must be shifted into numeric mode
by either NumLock or Shift keys. See if the current version is better for your
application.]
------------------------------
Date: Fri, 25 Sep 87 17:18:45 +0200
From: hans@ifi.uio.no
Subject: Problem with Input Translation and 'SET DISPLAY 7'
Keywords: MS-DOS Kermit
I connect to mainframes which (normally) use 7-bit ASCII characters for text.
By convention the characters [\]/{|} (following ASCII Z/z) are interpreted as
national (Norwegian) letters -- and not the standard brackets/braces, etc.
The IBMPC uses 8-bit ASCII, including the national letters (above ASCII 127).
To use the PC as a terminal, I have six "SET KEY" commands, and corresponding
"SET TRANSLATION IN" commands to do the mapping, the first pair being
"SET KEY \146 \91" and "SET TRANS IN \91 \146".
All goes well with the Aug 12 edition, but with the new (12 Sep) version
(MSTIBM.BOO.18,19 on CU20B), my input translations don't work any more.
But that's just what the latest manual (MST29C.DOC) tells me, too:
"The sequence of applying filters to received characters is: ....
4. translate if TRANSLATION INPUT is ON
5. if LOG SESSION is active then copy character to file
6. pass character to the terminal emulator which does:
.... else
if SET DISPLAY is 7-BIT then remove high bit before use."
The TOPS20 and unix systems I use normally send parity with output characters,
so I rely on (the default) "SET DISPLAY 7-bit". But then, of course, my newly
translated Norwegian letters are garbled.
Can my problem be solved with another combination of commands? If not,
could you consider changing the sequence of actions, referred to above?
Or is there another possibility? I really hope something can be done!
Hans A. ]lien, Inst. of Informatics, Univ. of Oslo, Norway (hans@ifi.uio.no)
[From jrd - Log file shows high bit in many characters even when Set Display 7
bit is active. That's the way it is designed presently, logging is done
between the Set Translation filter and the Set Display filter. Maybe we should
apply the 7/8 bit filter to the log file as well. On the same subject, some
Unix systems like to send characters with parity almost no matter what one
tells the operating system. On mine, stty -parity does not seem to help much
either, but then that machine wins more battles than me.]
[From jrd - In response to Hans ]lein: It seems that his TOPS-20 system uses
parity frequently and he uses SET DISPLAY to remove the high bit. I think the
proper thing to do is use SET PARITY xxx to remove the high bit from the
communications line and then the two filters above should produce the desired
National characters with SET DISPLAY 8-bit. Parity of MARK (or occassionally
SPACE) is acceptable to most 8-bit systems and chops off the high bit upon
reception (as well as stimulating 8 bit quoting on file transfers).]
[Ed. - Even though DEC systems like the DEC-20, VAX, etc, normally send parity
during a terminal session, the Kermit programs put the communication line into
8-bit "binary" mode for file transfer, so that 8th-bit quoting is not
necessary.]
------------------------------
Date: Tue, 29 Sep 87 16:01:17 mdt
From: Richard Cook <cook@TRAMP.COLORADO.EDU>
Subject: Kermit 2.29C VT-102 Emulation
Keywords: MS-DOS Kermit
I had noticed the problem with using terminal emulation in 2.29C, but what
seems to be happening is that some programs/utilities will try to use
reverse video when they see a VT-102. The escape characters sent to reverse
the video also reverse the intensity so that if you had white on blue you
get low intensity characters from then on (as in the status line). This is
"fixed" temporarily by escaping back to the PC (I'm on an IBM AT) and
reconnecting, but the next reverse video flips things back again. This
happens, for example, when I use the rn program to read Info-Kermit and rn
tries to highlight the subject field. The problem does not occur with the
original 2.29 Kermit.
[From jrd - Some utilities program the MS Kermit/IBM screen back to dim
(normal) intensity. That is correct. The host can change the attributes,
including intensity. The current Kermit is "smarter" and allows the screen to
show two levels of intensity, which are required by some applications. I think
we are stuck with that behavior until IBM changes matters or I add yet one more
Set Terminal command to change colors rather than intensity.]
------------------------------
Date: Fri, 2 Oct 87 09:10 EST
From: <BESSON@VUVAXCOM.BITNET>
Subject: Kermit-MS v2.29c
Keywords: MS-DOS Kermit
When using Kermit-MS version 2.29c to run GNU Emacs on a Vax, I find that
Ctrl-@, the command to set the mark, no longer works; it just rings the
bell with no other message. The mark is set properly with version 2.29.
Any ideas would be appreciated.
M. Besson
Villanova Univ.
[Ed. - The new MSTIBM.BOO, dated 8 Oct 1987, announced in Info-Kermit Digest
V6 #23 has an added key definition to make Control-@ send a null character
by default, as many have requested.]
------------------------------
Date: Wed, 23 Sep 87 14:07 EDT
From: "Ken Van Wyk, User Services, ext. 4988" <LUKEN@VAX1.CC.LEHIGH.EDU>
Subject: MS-Kermit 2.29c Comments
Keywords: MS-DOS Kermit
I've been playing with Kermit 2.29c quite a bit and I have a couple
comments/suggestions to make.
First, I really like being able to assign a Kermit "verb" to a key. This is a
very useful feature that was sorely lacking in earlier versions, in my opinion.
An additional verb that I would like to see is "quit", which actually exits
kermit, regardless of whether or not there are any pending commands in (say) an
MSKERMIT.INI file.
Also, I would *LOVE* to see a command line parameter (say, -F) which instructs
Kermit to read from a file *OTHER* than MSKERMIT.INI. This would greatly ease
the job of building a menu driven interface (for the rest of the world) around
Kermit. A command line could then read, for example, KERMIT -F
C:\KERMIT\VAX.INI or KERMIT -F C:\KERMIT\IBM.INI or something like that. Any
takers?
[Ed. - Good ideas, but no prognosis for whether such a feature will make it
into 2.30.]
Some users have also asked for COM3 and COM4 support in Kermit. Is this going
to work in 2.30?
[Ed. - 2.30 contains hooks for COM3 and COM4. See KER:MST29C.DOC for how
to use them.]
Finally, is 2.30 going to work on a Z-100? Is anyone working on that? If so,
will it support VT-100 (or 102...)? I know of a few Z-100 users who would
deeply appreciate this, myself included.
[Ed. - We need a Z-100 wizard to help with this. Any volunteers?]
Thanks!
------------------------------
Date: Thu, 15 Oct 87 07:47:40 PDT
From: Steve Dennett <DENNETT@SRI-NIC.ARPA>
Subject: Kermit with Zenith COM3
Keywords: MS-DOS Kermit 2.29C, Zenith
There has been some previous discussion of versions of MS-DOS Kermit that
use the (IBM?) COM3 port. Zenith, in the Z248 (80286) PC sold in large
quantities to the government, includes its own non-IBM-compatible COM3 port
on a board called the Z-304. One of our programmers is trying to adapt some
comm software for us, and is having a terrible time, and getting information
from Zenith is an uphill battle.
Has anyone successfully adapted Kermit (or any other comm program) to run
with *this* board's COM3 port? If so, I'd really appreciate pointers to the
code, esp. that used for handling interrupts when receiving information.
Thanks!
Steve Dennett
dennett@sri-nic.arpa
------------------------------
Date: Wed, 14 Oct 1987 08:06 -
From: Peter W. Day <OSPWD@EMUVM1>
Subject: Re: Printing through a PC
Keywords: MS-DOS Kermit 2.29B, Printing
>Date: Wed, 14 Oct 87 12:40:38 GMT
>From: Dermot O'Beirne <DOBEIRNE@IRLEARN>
>Subject: Printing through a PC
>
>Can anyone tell me how to set up our system to allow host printing
>commands to print through the parallel Centronics type and / or second serial
>RS232 ports of a PC when in VT100 emulation mode using KERMIT 2.29.
Kermit-MS (ver 2.29b) supports a PC-attached Printer using the ANSI defined
sequences
escape left square bracket 5 i (Print on)
escape left square bracket 4 i (Print off)
Send the "print on" sequence followed by the text to print followed by the
"print off" sequence. Anything between these sequences will be directed
to the PC-attached printer instead of the screen.
On an IBM computer, you are out of luck unless you can somehow send a character
which gets trabslated to an ESC. This is possible through a 7171 protocol
converter, but I don't know about other types of IBM ASCII connections.
Peter Day
Emory University
[Ed. - Thanks for the help, Peter. See Joe's message below also.]
------------------------------
Date: Wed, 14 Oct 87 10:22 MDT
From: Joe Doupnik <JRD@USU.BITNET>
Subject: Printing through a PC
Keywords: MS-DOS Kermit 2.29C, Printing
Your mainframe can send a pair of escape sequences to the PC which,
if everything is working properly, will relay further bytes directly to the
PC's main printer (PRN).
The sequence to start this "transparent printing" operation is
ESC [ 5 i which is Media Copy On or DEC's Controller Print ON
and
ESC [ 4 i turns off this mode.
Neither sequence is printed and nothing shows on the screen. This operation
and other similar kinds are described in the manual accompanying MS Kermit
version 2.30 (when it appears sometime next century).
A similar pair drives both the screen and the printer:
ESC [ ? 5 i turns it on (DEC's Auto Print On)
and ESC [ ? 4 i turns it off again.
Support of these is recent so be sure to get the latest MS Kermit
from Columbia (and yes, it is still volatile).
Regards,
Joe D.
------------------------------
Date: Tue, 6 Oct 87 14:17:45 EDT
From: BJ CAMERON (SYSTEMS DEVELOPMENT) <HESSE@WATDCS>
Subject: MacKermit Key Redefinition
Keywords: MacKermit
I recently received a version of MACKERMIT 8(34) from the Bitnet server at
Columbia. I was wondering if there is a way to access the extra keys
available on the new style keyboards? Is there a list of scan codes that
get returned for these keys?
[Ed. - Currently, no. The new keyboards and systems have an entirely
different way of handling the keyboard than is coded into Mac Kermit. Some
people in various places are working on an update, but there's no estimated
release date yet.]
------------------------------
Date: Mon, 21 Sep 87 16:57:03 EST
From: Bob Blackmun <ACC00RRB@UNCCVM>
Subject: MacKermit 0.8(35) bug?
Keywords: MacKermit
I have downloaded MACKermit 0.8(35) (otherwise known as XKMKER.HQX) from
CUVMA, run it through BinHex 4.0, and find that it changes my keyboard
definition file (created by XKMKEY.HQX) unless I first lock the keyboard
file. Is this normal? (I have not had this experience with the previous
(CKMKER.HQX, version 0.8(34)) version.)
[Ed. - Since we have had so many complaints about this, it must be "normal".
Let's hope a new release will appear soon that corrects these and other
problems, especially when Mac Kermit is run on the Mac II or SE. Meanwhile,
see messages below.]
------------------------------
Date: Mon, 28 Sep 87 10:39:20 EST
From: Bob Blackmun <ACC00RRB@UNCCVM>
Subject: Mac Kermit CKMKEY & XKMKEY
Keywords: MacKermit
We are having problems with CKMKEY 0.8 (6) and/or (7). Both versions
appear to clobber the terminal file while saving it, even if no changes
are made to the file. Is anyone else having similar problems? We have
found that CKMKER 0.8(35) does the same thing unless the terminal file
is locked. What are we doing wrong!!
[Ed. - Nothing, sad to say. But see next message.]
------------------------------
Date: Mon 12 Oct 87 22:39:11-PDT
From: Jim Lewinson <a.Jiml@GSB-HOW.Stanford.EDU>
Subject: MacKermit 0.8(35) Can't Save Settings File
Keywords: MacKermit, Settings
If told to, MacKermit SAYS it is saving the settings file on top of an
existing settings file, but it doesn't really do it. The old settings
remain. However, if you save it under a new name, it works just fine.
Then you can rename the new file to the old name and all works nicely.
However, it is a bug.
Jim
P.S. I'll bet you are going to add a message to end of this saying:
"Added to .BWR file". :-)
[Ed. - Added to .BWR file.]
------------------------------
Date: Mon, 28 Sep 87 22:57:31 PST
From: jww@sdcsvax.ucsd.edu (Joel West)
Subject: Mac .HQX files
Keywords: MacKermit, BinHex
Most user groups have a public domain disk that includes
Binhex V4.0
which is the program for encoding/decoding a complete Macintosh binary file
to printable characters. If you intend to be sending/retreiving Macintosh
documents or programs from KERMSRV or anyone on the mail system, you should
obtain a copy. (Also, as noted, it's on the Columbia Mac disk.)
------------------------------
Date: Wed, 23 Sep 87 17:59 EDT
From: DESCALANTE@rcca.bbn.com
Subject: Thanks on CONNECT.PASVT100
Keywords: QK Kermit
As it turns out, I had downloaded the QK-Kermit on July 20, and the Ctrl-Z
problem got me. Hadn't bothered looking at it much since then. Now I have
the right connect file and the KEYTABLE.DAT file, so thanks for the help.
Now for two by-the-ways:
1) Now that it compiled beautifully, seems to be having problems talking to
KERMIT32 on our VAX, although the terminal emulation is fine. Haven't
spent more than an hour on it, though, so haven't really isolated the
problem.
[Ed. - Try the new version announced in Info-Kermit Digest V6 #23 and see if
that makes the problem go away.]
2) Picked up Frank da Cruz's book, called something like "KERMIT - A File
Transfer Protocol" a month or so ago, since I'm much more familiar with
the whims of XMODEM than KERMIT and wanted some help. It's really
excellent in all three areas I noted -- as a comm tutorial, a KERMIT
reference, and programmer's guide. Thanks to Frank for taking the time
to write such a readable and thorough explanation of the protocol. Has
it been publicized anywhere on the net, or is he being quiet/modest
about it?
[From Frank - Thanks for the nice words. There was actually a totally immodest
announcement of it in Info-Kermit V5 #13 (Oct 8, 86).]
Anyway, once more, thanks for the help and the book.
David Escalante
------------------------------
Date: Mon, 12 Oct 87 08:27 EDT
From: GARTLEY@ALCOA.COM
Subject: Kermit Versions and Packet Size
Keywords: Kermit Features
Last week I downloaded Kermit for the MAC, IBM, and VMS. I found that the
IBM version 2.29b supports packet sizes greater than 90 bytes. After tring
the MAC 0.8(35) and VMS 3.3.111 I found both of these versions do not have
this feature implemented. Is there any versions that support larger packet
sizes. The main reason I would like this version is for file transfers on
our broadband lan.
Is there a table that lists the optimum packet size and data rate.
John Gartley
Gartley%alcoa.com@relay.cs.net CSnet
Gartley@atdncf.alcoa.com ARPAnet
[Ed. - The only versions (so far) which contain long packet support are
MS-DOS 2.29C (soon to be 2.30), CMS Kermit 3.1, PDP-11 Kermit, and VAX/VMS
C-Kermit 4E (the C version, not the Bliss version). The next time somebody
builds Mac Kermit from the current C-Kermit base, it too should support long
packets. The documentation of each Kermit program should give "capabilities
at-a-glance" (many do). Meanwhile, it would be useful to have a document
that lists the features of each Kermit program in a table. Hopefully, we
will get around to producing such a document. Volunteers are always
welcome.]
------------------------------
Date: Tue, 13 Oct 87 16:13 N
From: <HELMUT@HNYMPI51.BITNET> (Helmut Feldweg)
Subject: VMS: No Default Terminal Line for Transfers
Keywords: VAX/VMS Kermit
I'm new on this list, so the following question undoubtedly has been
asked before. Still, I don't know the answer:
We are running KERMIT-32 (version 3.0.051) on our VAX 11/750 running
VMS 4.4 using logical terminal lines generating terminal names
like _LTAn: where n increases by one for every user logged in
since the last shutdown of the system. It happens occasionaly that our
system managers manage to keep the machine alive without a shutdown
over a period of time, so 'n' will exceed 999. Our version of KERMIT
doesn't like terminal numbers greater 999 (= terminal names exceeding
8 characters). It says 'no default terminal line for transfers' and
refuses to accept any command. A way out is to create a new process
via "$ SET HOST node", where the trouble with high numbers doesn't occur,
but this is a boring procedure.
Any hints to avoid this?
Helmut Feldweg
Max-Planck-Institut fuer Psycholinguistik
Nijmegen, The Netherlands
e-mail: helmut@hnympi51.bitnet
[Ed. - Run version 3.2 or 3.3 of VMS Kermit, which contain a fix for this
problem.]
------------------------------
End of Info-Kermit Digest
*************************
-------