Info-Kermit Digest V8 #4
Christine M Gianone
Departments:
ANNOUNCEMENTS -
CU20B IP Host Address to Change
Okstate Dialup Number to Change
Kermits Needed
Announcing C-Kermit for OS/2
MS-DOS KERMIT -
Automatic Switching Between Text and Graphics in MS-Kermit
MS-Kermit 2.31-test6
MS-DOS Kermit 2.30
MS-Kermit 2.31-test6
IBMPC Kermit 2.31 UB problem
MS-Kermit 2.31 -- SET PORT UB-Net1
MS-Kermit 2.31 Bug (Feature?)
MS-Kermit v2.31 Scripts
Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.
Kermit files may be obtained over networks and by mail order. On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:. You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV). To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.
----------------------------------------------------------------------
Date: Mon, 1 Aug 88 12:00:00 EDT
From: Christine M Gianone <SY.CHR...@CU20B.CC.COLUMBIA.EDU>
Subject: CU20B IP Host Address to Change
Keywords: CU20B, FTP
As of August 15th, 1988, Columbia University Computer Center IP host
addresses will change by replacing the 32 with a 40 in the third octet of
the IP address. In particular, the host number of CU20B will change from
128.59.32.128 to 128.59.40.128. If you have trouble FTP'ing Kermit files
from CU20B on or after August 15th, you can specify the new host number until
your site's host tables are updated to reflect the change.
------------------------------
Date: Mon, 01 Aug 88 15:46:23 -0500
From: Mark Vasoll <vasoll%a.cs.oks...@RELAY.CS.NET>
Subject: Okstate Dialup Number to Change
Keywords: Okstate
On August 6, 1988 the phone number for the UUCP and Kermit servers at
Oklahoma State University will change:
Old number: (405) 624-6953
New number: (405) 744-6953
A "that number has been changed" recording has been promised, but I
don't hold a lot of hope for it.
Mark Vasoll
Computing and Information Sciences Email: vas...@a.cs.okstate.edu
Oklahoma State University
Stillwater, Oklahoma
------------------------------
Date: Fri 29 Jul 88 17:27:32-EDT
From: Frank da Cruz <SY....@CU20B.CC.COLUMBIA.EDU>
Subject: Kermits Needed
Keywords: Future Kermits
Now that Kermit is about seven years old, it has spread to cover nearly every
major computer and operating system, and many minor ones -- well over 300 in
all. But there are still some notable systems for which no Kermit programs
exist. Among them:
- The IBM System/34, System/36, System/38, AS/400. Some of these machines
lack asynchronous communication interfaces, so Kermit file transfer will
be possible only if the commonly-used protocol converters can be put into
transparent mode, as the IBM 370-series mainframe Kermits do for their
3270 protocol converters.
- Support in IBM mainframe Portable Kermit-370 for DOS/VSE and CICS.
- Wang VS and other minicomputer systems.
If you know of anyone working on these projects, or are interested in doing
it yourself (for fame but not fortune), please let us know!
------------------------------
Date: Fri, 29 Jul 88 14:54:36 -0100
From: PD Software <syspds%central1.lan...@NSS.Cs.Ucl.AC.UK>
Subject: Announcing C-Kermit for OS/2
Keywords: C-Kermit, OS/2 Kermit
Announcing C-Kermit for OS/2
A version of C-Kermit for OS/2 is now available for beta testing. Any bugs,
suggestions or complaints should be sent to C.A...@uk.ac.edinburgh. This
first version is 1.0a - the 'a' indicates it is a pre-release version.
I've used the letter 'O' as the system-specific identifier for OS/2, so
the release files are named as follows:
CKOKER.EXE The executable program
CKOKER.DOC Documentation
The sources for the program and the Scribe source for the documentation
will be made available when beta testing is over (ie when bug reports
slow to a trickle?).
C-Kermit for OS/2 runs on OS/2 Standard edition 1.0 (or on 1.1 in a
Presentation Manager window, although this is untested). It makes use of
the COM.SYS (or perhaps COM01.SYS) device driver, which must be loaded in
the CONFIG.SYS file. There are believed to be no major bugs, but the
following minor problems exist:
* Stop bits: There is currently no mechanism for altering the number of stop
bits, which is fixed at 1.
* Server breakout: There is no way of stopping server operation from the
keyboard, short of Control-Break.
* Dial: The DIAL command has not been tested. It is impossible to terminate
the dialling process short of pressing Control-Break.
* Multiple copies: Multiple copies of Kermit accessing multiple comms ports
simultaneously has not been tested.
* Terminal emulation: No particular terminal is emulated, and therefore the
keyboard has only the natural key-to-ascii-code mapping. This means that
(for instance) the Del key does not produce code 127, but a code of 0
followed by 224. The only exception to this "natural" mapping is that the
backspace key is explicitly mapped into 127. It is hoped to implement a
VT100 emulator and a keyboard remapper to circumvent these problems. This
may also improve the speed of terminal writing, which is slow compared to
MS-Kermit.
* Multiple send from command line: At present, a wildcard file specification
cannot be given as the argument to the '-s' command line option. Thus, only
a single file can be sent using a command line.
* Flow control from keyboard: In connect mode, if a Control-S is typed at the
keyboard to pause a long file listing, it may or may not work, depending on
the state of the device driver's flow control flags.
There are also some further minor bugs or areas for improvement which are
detailed at the end of the documentation.
Chris Adie
26/07/88
[Ed. - Many thanks! The files are in KER:CKOKER.*. We normally do not
release programs without source code, but we make an exception in this case
because of the high level of interest in OS/2. Test at your own risk!]
------------------------------
Date: Tue,28 Jun 88 16:24:40 BST
From: P.W...@uk.ac.hull.cc.vme
Subject: Automatic Switching Between Text and Graphics in MS-Kermit
Keywords: MS-DOS Kermit 2.31
Someone here is using a package which uses DEC VT100 codes during its text
output and Tektronix 4010 codes for its graphics output. The package expects
the terminal to automatically switch between text and graphics modes at the
appropriate points. If MS-Kermit is used with the package, automatic switching
from text to graphics takes place in some cases (for example when the package
sends ESCAPE Control-L) but not in others (for example when the package sends a
Tektronix drawing command). In comparison, UNITERM on an Atari ST always
switches when necessary.
Should the codes which cause MS-Kermit to automatically switch from text to
graphics mode be expended to include the Tektronix FS, GS, RS, and US commands?
This automatic switching can, of course, be disabled if necessary via the
Kermit DISABLE TEK command.
Phil Wade,
Hull University Computer Centre.
[From jrd - While automatic switching for all Tek commands (there are more
than the FS, GS, RS, US set, clearly) can be convenient for isolated packages
it both adds a lot of code to MS Kermit and exposes users to many unexpected
switches when files are displayed with embedded control codes. Overall, I
think we are better off with the just the current two automatic entry points.]
------------------------------
Date: Fri, 01 Jul 88 11:36:28 BST
From: CP...@UK.AC.CAM.PHX
Subject: MS-Kermit 2.31-test6
Keywords: MS-DOS Kermit 2.31
I've come across a number of peculiarities while using 2.31-6 from batch
files, or MAKE files, with a PS2/60. When the command
kermit send dirname\filename.C dirname\filename.C
is entered (having set up a kermit on an EPSON AX in server mode) the
filename used at the other end is
dirname\filename.CX (Note the added X in the extension)
I assume that this is a bug -it's certainly annoying! The addition of the X
does not occur with extension names of 2 or more characters. If the send
command is not the last on the line then the X is not added either, i.e.
kermit send dirname\filename.C dirname\filename.C, quit
saves
dirname\filename.C
at the remote end. The "sending as" within kermit works fine.
Another quirk is when Control-C is used while a file transfer is in
progress. This causes the server kermit to hang up waiting for more
packets. The way I've found around this is to ask it for a "rem dir" a few
times and Control-C out it, producing the "host not receiving" (not
verbatim!) error message. Eventually the server gets the message and gives
a directory listing.
Yours,
Chris.
[From jrd - Chris, you need to reread the MS Kermit User's Manual. First,
the SEND command can take two arguments: local filname and optionally the
name to use in the outgoing packet. It does not take a list of files to be
sent; use a list of SENDs. Second, Control-C is a non-protocol exit and does
not notify the other side. Hence the host waits for more packets in the file
exchange. Use Control-Z instead, as indicated on the file transfer screen
status line.]
------------------------------
Date: Thu, 7 Jul 88 20:02:31 bst
From: Leila Burrell-Davis <lei...@uk.ac.sussex.cvaxa>
Subject: MS-DOS Kermit 2.30
Keywords: MS-DOS Kermit 2.30
MS-Kermit is normally pretty good about renaming files that don't conform to
MS-DOS filename conventions, but it is distinctly upset by a file with a
colon in its name, e.g. episode:1
I found this rather annoying when I left it overnight downloading a lot of
files from a un*x machine, only to discover the next morning that it had
given up as soon as it got to the filename with the colon in.
You may like to pass on details of this `feature' to the program's author
(:-).
Leila Burrell-Davis, Computing Service, University of Sussex, Brighton, UK
Tel: +44 273 678390 Fax: +44 273 678335 JANET: lei...@uk.ac.sussex.cvaxa
ARPA: leilabd%cvaxa.sus...@cunyvm.cuny.edu
BITNET: lei...@cvaxa.sussex.ac.uk UUCP: lei...@cvaxa.uucp
[From jrd - DOS uses colon as a device name terminator/separator. Try this at
DOS level-
C> copy oldfile new:name.ext
DOS will tell you that there is an illegal destination (no device "new:").
DOS also uses multiletter device names which may optionally end in a colon.
Kermit cannot determine whether or not you mean use a specific device and
thus does not change the colon to another legal letter.]
------------------------------
Date: Thu, 07 Jul 88 15:36:00 BST
From: Mr. A. O. V. Blanc <YMU...@uk.ac.umist.central-services.prime-a>
Subject: MS-Kermit 2.31-test6
Keywords: MS-DOS Kermit 2.31
We have obtained a copy of MS-Kermit 2.31-test6 for testing. I have
been running it on several PC models (IBM, Opus, and Comcen) and testing
it against our Kermit-CMS version 4.0, the IBM generic Kermit with
updates up to SC88092. During the tests -- which went very well, on the
whole -- the following difficulties appeared:
(1) The reported size of the packets received never gets larger than 4,
which is clearly incorrect.
(2) The file size used to calculate the percentage transferred is quite
far off, which some files terminating when only 25% had allegedly
been transferred. Different ways of measuring file size may be
responsible, but users would surely feel happier if the percentage
were changed to 100% when the transfer terminates successfully.
(3) The two Kermits cooperated nicely when connected through a 7171
comms processor, but not when using a CAMTEC PAD. In this case the
connection works normally until the Kermits begin trading packets.
Then the IBM apparently insists on a fifteen or twenty second pause
before accepting each line of input. This results in a transfer
rate of 3 to 4 packets per minute, which is intolerably slow, and
the input problem remains even after Kermit ceases to execute. I
know this sounds like a CMS problem, especially since it seems to
occur under similar circumstances with MS-Kermit version 2.30. It
does not happen, however, when I use version 2.29c!
(4) I am not surprised that MS-Kermit receives only the date and not
the time of a file's creation, since the warning of this appeared
in the MSTIBM.BWR file. When files are transferred from the micro
to CMS, however, both date and time seem to be ignored.
Thanks to Joe Doupnik for his extensive work improving MS-Kermit and its
script facility.
[From jrd - some of the 2.31test series had a file length arithmetic problem
which lost the high order part of the file size figure sent by the host.
Fixed some time ago.
CMS Kermit apparently sends the date of a file but not the time. In that case
MS Kermit records the time as 00:00:00, which is legal, but DOS then shows
this as blanks on the screen. The release version of MS Kermit 2.31 adds two
seconds to let DOS display some numbers for the time.
The long pause does appear to be either a CMS or a front end processor
problem; see if using regular length packets helps these fellows. You might
say to MS Kermit SET SEND PAUSE <millisec> because some IBM systems do not
become ready for reception until long after turning around the line. If this
were the case the mainframe would miss the start of a packet and would have
to wait for a timeout and a repeat; the timeout is normally 13 seconds to
receive an acknowledgement.]
------------------------------
Date: Fri, 22 Jul 88 18:00:06 PDT
From: doug%Tybalt.Caltech.Edu%CITIAGO...@CUVMB.CC.COLUMBIA.EDU
Subject: IBMPC Kermit 2.31 UB problem
Keywords: MS-DOS Kermit 2.31, Ungermann-Bass
I recently downloaded IBMPC Kermit v2.31. An excellent package, as
usual. The UB NetCI interface looked particularly interesting, since we
currently require a resident BIOS rerouter to use the CI from Kermit.
Unfortunately, as soon as characters were received from the CI, the PC
hung. After reducing other software to its bare essentials, I began to
suspect Kermit. After downloading MSXIBM.ASM and DEBUGing through
KERMIT.EXE, a probable cause appeared.
The IRET in RPOST would send the CS off to never-never land, causing the
machine to hang. This was because the "call rpost" in UBRECV assumed a near
(intra-segment) call, and only pushed the IP+2 on the stack, and not the CS.
As a solution, I recommend making UBRECV and all other interrupt routines
type PROC FAR, since that more accurately describes what they are. (IRET =
far RET + POPF). Then UBRECV would assume a far call.
I certainly appreciate all the work that you are putting into Kermit.
It fills an essential gap here at Caltech.
There are a couple more minor problems with the UB NetCI interface in
IBMPC Kermit v2.31. I downloaded the source this evening and MSXIBM.ASM
required the following changes before the UB CI would work:
1. Change all interrupt procedures to PROC FAR (mentioned earlier)
2. Add lines between outch3: and outch3a: as follows -
outch3: cmp clone,0 ; real uart?
je outch3a ; e = yes
cmp clone,'N' ; network?
je outch8 ; e = yes, using netbios
add--> cmp clone,'U' ; UB?
add--> je outch8 ; e = yes, using netbios setup
jmp outch6 ; default for others ('B' clones)
outch3a:push cx ; Save registers
3. In ubsend, xmtbuf does not contain our info- xmtbufx does; so change
jcxz ubsend1 ; dont send zero chars [ohl]
mov bx, offset xmtbuf ; buffer address in es:bx [ohl]
mov ax, datas
mov es, ax
to
jcxz ubsend1 ; dont send zero chars [ohl]
changed-->mov bx, offset xmtbufx ; buffer address in es:bx [ohl]
mov ax, datas
mov es, ax
These three minor changes appear to fix the interface. Thank you again
for providing the program and source.
-Doug Schafer
do...@tybalt.caltech.edu
[Ed. - Thanks for the fixes! They have been passed along to Joe Doupnik,
and there should be a maintenance release of 2.31 soon, which fixes this and
a couple of other problems.]
------------------------------
Date: Fri, 15 Jul 88 15:42:24 EDT
From: cucard!dasys1!era...@columbia.edu (Ed Ravin)
Subject: MS-Kermit 2.31 -- SET PORT UB-Net1
Keywords: MS-DOS Kermit 2.31, Ungermann-Bass
I just tried using MS-Kermit 2.31 on our Ungerman-Bass network. The
MS-Kermit docs say that when I issue the "CONNECT" command after "SET PORT
UB-Net1", I should see the NET-CI prompt and be able to use the usual NET-CI
commands. Alas, I saw nothing. Not only that, but when I tried to exit
Kermit, my PC went into a "waiting state", where the PC hangs up, but a
chirp is issued every few seconds to let you know that it is still trying to
access something or someone on the network that can't be found.
I can still use U/B's NET-CI driver (NETCICOM.DRV) without any problem: not
only that, but if I use NETCICOM to redirect a com port (such as COM3), and
then tell MS-Kermit to use port BIOS3, everything works fine and I can
access the NET-CI interface without difficulty. Any idea why I can't use
the "SET PORT UB-Net1" command?
Ed Ravin
era...@dasys1.UUCP
or
era...@trintex.UUCP
[Ed. - See previous message. The problem will be corrected shortly.]
------------------------------
Date: Tue, 19 Jul 88 00:31 PDT
From: CARL FUSSELL <CARL%SCU.B...@CUVMB.CC.COLUMBIA.EDU>
Subject: MS-Kermit 2.31 Bug (Feature?)
Keywords: MS-DOS Kermit 2.31
I just downloaded the latest version of MS Kermit (2.31). There seems to be
some unexplainable behavior when running a script. We run a typical script
to login to a VAX/VMS system. The script worked fine under version
2.31-test5 but caused a strange problem when used under the final 2.31
distribution. The problem that appears is that TAB characters aren't
displayed correctly. Instead of tabbing to the next tab stop, the display
is tabbed to column 80 with the remaining text wrapping to the next line.
This does not happen using the same script with V2.31-test5.
The script line that causes the problem is the initial CLEAR statement.
Leave it in and the problem described above appears.... remove it (or
comment it out) and it works. Fortunately for us, everything works ok with
the line removed.
Anyway, just tho't I'd pass this along... (the script is attached if
interested.)
Carl Fussell
Santa Clara Univ
CA...@SCU.BITNET
[Ed. - We have had one other similar complaint -- i.e. that the CLEAR
command, which is supposed to clear only the serial port input buffer,
also clears the tab stops. But no matter how hard we try, we can't
reproduce it. We'll try again to pin it down. Meanwhile, the workaround
is to put a "SET TERM TAB" command after the CLEAR command.]
------------------------------
Date: Mon, 25 Jul 88 13:01:26 -0500
From: Mark Bergman <ber...@ROCKEFELLER.ARPA>
Subject: MS-Kermit v2.31 Scripts
Keywords: MS-DOS Kermit 2.31, Scripts
Many thanks for all the improvements in MS-Kermit v2.31! Its already making
lives easier here by providing a much-requested auto-dialing capability. I
do have a question about using the INPUT command as part of a take file
(actually mskermit.ini) to allow the user to choose what number to dial. I
want to ask the user whether to connect to the Rockefeller University system
or not (expanding to other choices in the future).
I was trying statements in the form:
echo Connect to the Rockefeller system? (yes or no)\13
input 45 yes @CON
if success goto CONTINUE
which fails (according to an "if success" test) when the first key is
pressed, regardless of the input. No <RETURN> is needed, and the input is
not echoed.
I also tried statements in the form:
echo Connect to the Rockefeller system? (yes or no)\13
input 45 @CON yes
if success goto CONTINUE
This succeeds (according to an "if success" test), in every case. The input
is not checked, but it always succeeds. The input text also must be
followed by two <RETURNS> before it is recognized, and the characters are
not echoed while this is run.
I wanted to know if you had an example of a script that read and tested
input from the keyboard. I also wanted to know if there was any way to
supress the "?Timeout" error message. The script provides it's own error
message.
Mark Bergman
Rockefeller University
Computing Services
Box 247
1230 York Avenue
New York, New York 10021
212-570-7510
BEST PATH==> ber...@rocky5.rockefeller.edu
ber...@rockvax.bitnet
ber...@rocky2.uucp
[Ed. - Version 2.31 does not include a mechanism to do what you want.
INPUT only looks at the communication port, not the keyboard. A future
release will include this feature.]
------------------------------
End of Info-Kermit Digest
*************************
-------