[comp.protocols.kermit] Info-Kermit Digest V8 #4

SY.CHRISTINE@CU20B.CC.COLUMBIA.EDU (Christine M Gianone) (08/04/88)

Info-Kermit Digest         Wed, 3 Aug 1988       Volume 8 : Number 4

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.CHRISTINE@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.okstate.edu@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:  vasoll@a.cs.okstate.edu
Oklahoma State University
Stillwater, Oklahoma

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

Date: Fri 29 Jul 88 17:27:32-EDT
From: Frank da Cruz <SY.FDC@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.lancaster.ac.uk@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.Adie@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.WADE@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: CPA1@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 <leilabd@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: leilabd@uk.ac.sussex.cvaxa
ARPA: leilabd%cvaxa.sussex.ac.uk@cunyvm.cuny.edu
BITNET: leilabd@cvaxa.sussex.ac.uk      UUCP: leilabd@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 <YMUMAL@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.BITNET@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
doug@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!eravin@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

			eravin@dasys1.UUCP
		or
			eravin@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.BITNET@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
CARL@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 <bergman@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==> 	bergman@rocky5.rockefeller.edu
        	bergman@rockvax.bitnet
        	bergman@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
*************************
-------