21-Aug-89 22:01:53-GMT,24015;000000000001 Return-Path: Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0) id AA16194; Mon, 21 Aug 89 18:01:51 EDT Received: from watsun.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB) id AA12585; Mon, 21 Aug 89 17:59:17 EDT Received: by watsun.cc.columbia.edu (4.0/SMI-4.0) id AA15908; Mon, 21 Aug 89 17:22:26 EDT Date: Mon, 21 Aug 1989 17:22:25 EDT From: Christine M Gianone To: Info-Kermit@watsun.cc.columbia.edu Subject: Info-Kermit Digest V10 #2 Reply-To: Info-Kermit@cunixc.cc.columbia.edu Queries-To: Info-Kermit-Request@CUNIXC.CC.COLUMBIA.EDU Message-Id: Info-Kermit Digest Mon, 21 Aug 1989 Volume 10 : Number 2 Today's Topics: Announcing Pick Kermit Version 0.3 C-Kermit 4F(094) Available for Testing ISO/Kermit Correspondence Archive File Comparitor for IBM Mainframes CMS Kermit 4.1.001 Warning MS-Kermit Scripts and IBM 7171 Protocol Converters Using KERMIT for File Transfer Between a PRIME and an RT PC C64-Kermit Problem Re: Using Kermit on Ethernet? Kermit for Navigator Errors Compiling Amiga Kermit Send digest submissions to Info-Kermit@CUNIXC.CC.COLUMBIA.EDU, requests for addition to or deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CUNIXC.CC.COLUMBIA.EDU or to KERMIT@CUVMA.BITNET. Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN, WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.0), IP host number 128.59,39.2, or to CUNIXC, CUNIXC.CC.COLUMBIA.EDU, a VAX 8700 running UNIX (Ultrix), IP host number 128.59.40.130. Login as user anonymous (note, lower case), any password, and GET or MGET the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. 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 kermit/a/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 Aug 21 12:13:32 1989 EDT From: Christine M. Gianone Subject: Announcing Pick Kermit Version 0.3 Keywords: PICK, Microdata, McDonell Douglas, REALITY, Ultimate, IBM PC >From Joe Fisher of Austin, Texas, comes release 0.3 of Kermit for the PICK operating system, written in DATA/BASIC. Version 0.3 replaces version 0.2C of January 1987. The previous release worked only on the Microdata REALITY system, but the new release works on the following systems: Microdata (now McDonell Douglas) REALITY 4.2E DEC MicroVAX II with Ultimate Coprocessor R10*182P IBM PC/XT and compatibles under PICK R83*2.0 IBM PC/AT and compatibles under PICK R83*2.2 The source files have been completely recoded and reorganized to be compatible with Kermit Distribution. They contain only printable ASCII characters. There is a new manual, in PICK Runoff format, PICDOC.RNO, containing user and installation instructions. Thanks to Joe for his efforts in preparing and contributing this new version. The files are in the D area of Kermit Distribution, under the prefix PIC (kermit/d/pic*.* on watsun, PIC* * via BITNET KERMSRV). ------------------------------ Date: Mon Aug 21 12:33:41 1989 EDT From: Frank da Cruz Subject: C-Kermit 4F(094) Available for Testing Keywords: C-Kermit, UNIX Kermit The forthcoming new release of C-Kermit 4F is coming closer. Many of the problems reported by the beta testers have been solved, but a few more must be fixed before final release. Since 4F(085) was announced for testing in Info-Kermit V10 #1 on July 14th, many changes have been made: - attempt to allow the program to compile correctly on Apollo SR10 BSD - attempt to fix the crazy echoing upon reconnecting after file transfer in AT&T-based Unix systems - fix the OS/2-specific code so that it compiles correctly - added new support for Masscomp/Concurrent RTU - added support for AT&T 6300 - fix TRANSMIT command to be interruptible by Ctrl-C - various minor bug fixes, cosmetic improvements, and code reorganization - fix IBM/Rolm CBX dialing - fix support for NeXT in the makefile - improved support for Hayes modem responses - new Microcom modem support - updated support for OS-9/68K - fixed dynamic packet size recalculation to only shorten packets upon real errors - fixed file size and throughput reports in STATISTICS command - attempt to eliminate many compile-time point-type mismatches caused by calls to signal() Some outstanding problems: - The OS/2 version reportedly compiles and runs correctly, but the CKOKER.BOO file which is provided is based on a much older version of C-Kermit. OS/2 users who build the new version are encouraged to send in an up-to-date CKOKER.BOO file. - The VAX/VMS support code (CKV*.*) is not yet updated to agree with this version. The new VMS code should be available within a week or two. - Similarly, the Macintosh code is slightly behind this version, and may need some reconciliation. - Support code for other non-Unix systems such as Commodore Amiga and Data General AOS/VS has not been updated in a very long time, and can not be compiled with the current version of C-Kermit. - BIG PROBLEM: On an AT&T 3B2/300, but apparently nowhere else, C-Kermit fails to write out one or more file buffers when receiving files. - Many Unix systems now disagree on the data type of the signal() function. Previously it was always (*int)(), but now it is (*void)() on some systems like AT&T System V R3, SUNOS 4.0, etc. C-Kermit includes a SIGTYP definition in CKCDEB.H to handle this, but this needs to be updated to reflect the situation on the many different systems C-Kermit tries to support. So far the only bad effect seems to be compile-time warnings about pointer mismatches. C-Kermit users are urged to get the latest pre-release and try it out on their systems and report any problems to me, so that this new version can finally be formally released, and work can begin on the next version. The files are in kermit/test/ck*.* on watsun, and T:CK*.* on BITNET KERMSRV at CUVMA. ------------------------------ Date: Mon Aug 21 12:33:44 1989 EDT From: Christine M. Gianone Subject: ISO/Kermit Correspondence Archive Keywords: International Character Sets The mail archive of the "ISO / Kermit" discussion group is now available as kermit/test/mail.txt on watsun, and as T:MAIL.TXT on BITNET KERMSRV. The messages discuss the recent proposal to extend the Kermit protocol for transfer of text files composed of different national character sets, as well as the first three drafts of the proposal itself. Please notify me if you want to be added to this discussion group. A fourth draft of the proposal will be available shortly. ------------------------------ Date: Fri, 1989 May 12 15:16:26 EDT From: "John F. Chandler" Subject: File Comparitor for IBM Mainframes Keywords: IBM 370 Kermit For those who don't already have a favorite file-comparison program, here's a note concerning one that is available in the Kermit distribution under the name IK0VER.FOR (that's I K Zero, not I K OH). It's specialty is comparing files of 80-byte records with sequence numbers in columns 73 through 80, and it writes out the differences in the form of an update file for converting one input file into the other. The syntax of the updates is compatible with that used by the UPDATE command of CMS (the control cards begin with the string "./ " in columns 1-3). It is not difficult to write a companion program for applying the updates -- such a program is also available in the Kermit distribution in versions for MVS, TSO, and MUSIC (in assembler). IK0VER is entirely in Fortran and contains comments with directions for converting from F77 to F66. John ------------------------------ Date: Tue, 20 Jun 89 15:59:13 EDT From: Brian Holmes Subject: CMS Kermit 4.1.001 Warning Keywords: IBM 370 Kermit After installing version 4.1.001, so far I have only noticed one bug. When I invoke the new version I always get the message "Invalid Kermit command" before I get the CMS-KERMIT> prompt. I notice that the string '$_' appears on the screen after I invoke the new version and before I get the error message. It appears that '$_' is getting passed to KERMIT somehow and of course this would generate the error. I grabbed a completely new version from KERMSRV before I started too. Has anyone else had a problem similar to this? Brian Holmes CSC Operating Systems & Communications SNAIL : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A. BITNET : BHOLMES@WAYNEST1 INTERNET : Brian_Holmes@UM.CC.UMICH.EDU UUCP : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES [From John Chandler - The message before the Kermit prompt is undoubtedly due to something in your KERMINI file left over from "the old days". The most likely that comes to mind is "SET SERIES1 ON", which was abandoned as of 4.0 in favor of "SET CONTROLLER SERIES1". Nearly all the other obsolete forms of Kermit subcommand are still accepted in Kermit-370, such as "SET FILE-TYPE BINARY" (should be "SET FILE TYPE BINARY") and "SET RECFM F" (should be "SET FILE RECFM F"). The "$_" appearing on the screen suggests something entirely different, namely, that you are connecting through a fullscreen terminal that isn't Yale-ASCII-type. Kermit-370 attempts to detect the kind of terminal controller by issuing a Yale ASCII status request (which contains an undefined 3270 order plus a dollar sign and x'BC'). If the controller doesn't recognize the special order as a status request introducer, the remaining characters will simply appear as text on the screen. Kermit will then, incidentally, decide that the controller is of type GRAPHICS, but it might also be a real 3270-type terminal (in which case, you wouldn't be able to do any file transfers). Still, the screen would normally be cleared after the status check, but some protocol converters sometimes leave garbage on the screen anyway.] ------------------------------ Date: Fri, 04 Aug 89 09:46:51 ADT From: DEDOUREK%UNB.CA@cuvmb.cc.columbia.edu Subject: MS-Kermit Scripts and IBM 7171 Protocol Converters Keywords: MS-DOS Kermit, Protocol Converters, IBM 7171 Xref: 7171, See IBM 7171 This is in reply to Mike Porter's query in Info-Kermit Digest, v9n7. Sorry about the long delay in replying, but because of a BITNET problem, I just received this issue this week. We also run IBM7171 protocol converters as the main access to the IBM mainframes. I have developed several scripts for automatically logging in, e.g. to TSO. In doing that work, I have gained some experience in writing such scripts. The following comments might be useful to others: On a fast PC, it is possible to send a reply to the 7171 too soon (even though the 7171 is a full duplex device with type ahead buffers). Apparently, some software clears the typeahead, e.g. when VTAM turns the terminal over to a new application. For example: INPUT 10 TERMINAL TYPE: OUTPUT vt100\13 starts the output as soon as the colon is received. Use of Kermit in "line monitor mode" (set debug on) shows that our 7171 is configured to send a blank after the colon. I use INPUT 10 TERMINAL TYPE: ; where the semicolon appears to say that the input string ends at the character immediately preceding. Use of backslash code for blank might be better style. This is particularly important when the 7171 sends an escape sequence (e.g. cursor positioning) following the visible text. I have found it frequently necessary (on my 286 machine) to wait for the escape sequence before sending. (BTW, escape sequences frequently include semicolons; remember to backslash escape semicolons in input statements as in: input \27[2\;36H I once spent many hours finding a bug in a script) The problem of the 7171 sending set-up sequences during the script processing and these not being transmitted to the emulator is a very annoying one when trying to automate logons for users. jrd's proposed solution of: set input-echo off input 10 terminal type: ; output vt100\13 connect won't work for us because there is a whole sequence of input/output statements to do the logon to TSO or whatever before the connect, whereas the 7171 insists on sending the initialization immediately in response to the "vt100\13". (Question to jrd: with set input echo off, just how much input is buffered for eventual processing by the emulator?) One possible solution would be addition of commands to MS Kermit of the form: set terminal vt100-keypad-mode application or similar. A script could then anticipate the required setting of all the emulator modes and explicitly set them before connect. I can see no way of doing this in MS Kermit 2.32/A. (jrd: have I missed something?) The current workaround is to instruct users to type the "7171 reset" key (control G on our system) after logging in. This retransmits all of the vt100 setups while the emulator is listening. Unfortunately, it is easy for a user to forget this, which causes strange problems, e.g. in the TSO editor. I have tried ending scripts with output \7 connect (yes, with set input-echo off) to try to ask for a reset just before the connect in the hopes that the emulator would then catch the sequences. Works perfectly in the next office on an IBM PC/XT. On my PS/2 30-286 (an 80286, 10MHz, 1 wait state machine) the communications goes into a loop! The 7171 is continuously sending garbage stuff. I have not had the time to determine whether the 7171 has botched and is sending junk, or whether MSKermit is continuously sending stuff and the 7171 is merely responding with error messages. (Typically, TSO invalid command, etc). I presume that the problem is that the reset occurs too soon after the last part of the logon command to TSO on my faster machine. I will report on this problem if I discover more information. John DeDourek, Professor School of Computer Science University of New Brunswick Fredericton, N. B. CANADA E3B 5A3 dedourek@unb.ca -- Registered Domain Name DEDOUREK@UNB -- BITNET / NETNORTH (Canada) dedourek@unb.bitnet -- For mailers which only know how to get to bitnet this way. [From jrd - There are two buffers. The serial port circular buffer is typically 1500 bytes. Script commands and the emulator draw from it, and characters cannot be returned afterward. Script commands may use a private 128 byte buffer for pattern matching; this buffer is not accessible by the emulator. This means that characters drawn out of the primary serial port buffer by the script commands will not be seen by the terminal emulator. (To reiterate a common item: the terminal emulator is not active during scripts, and this is the root of the discussion here). I agree that \32 is much safer rendition of a trailing space than a movable comment indicator. One may also use curly braces around the pattern string, such as: INPUT 10 {TERMINAL TYPE: } ; optional comment If one checks DEC VT10x terminals one finds that keypad applications mode can be set only by the host. The same is true for the VT300 series terminals. However, the VT320/102/52/H-19 emulator the next release of MS Kermit has the command SET TERMINAL KEYPAD {NUMERIC, APPLICATION}. There must be a 7171 problem associated with a too rapid response from the PC. One way of achieving a tiny wait interval is to say PAUSE 0, the processing time for which is a few milliseconds.] ------------------------------ Date: 26 May 89 20:22:39 GMT From: mskinner@boston5.vnet.ibm.com Subject: Using KERMIT for File Transfer Between a PRIME and an RT PC Keywords: IBM RT PC, Prime Concerning using KERMIT for file transfer between a PRIME and an RT: IT NOW WORKS! Thanks to everybody who took the time to offer me suggestions, both in the forum and directly. I REALLY appreciate it. It turned out to be a protocol problem -- like the RT version of KERMIT, the PRIME version also has a KERMIT setup file (that I had been overlooking); so when KERMIT on the PRIME was made active, it would change the parameters that I had set using the PRIME's ASYNCH (or whatever) command. Making sure parity was set to "mark" on both systems is what specifically fixed the problem. And to think the only Kermit I knew two weeks ago was the one on Muppet Babies... Thanks again for all the help. -- Mark Skinner (MSKINNER at BOSTON5) 8-234-6521 ------------------------------ Date: Tue, 13 Jun 89 22:30:30 EST From: ray@gibbs.physics.purdue.edu (Ray Moody) Subject: C64-Kermit Problem Keywords: Commodore 64 Kermit, C64 Kermit >I have the following configuration : a Commodore C64, a 2400 baud Hayes >compatible modem and a modem adaptor that connects the former two together. >When I used a terminal software called CCGMS 6.0, the system worked nicely up >to 2400 baud !!!!! However, when I used KERMIT, it was a complete failure no >matter what baud rate I tried !! Commodore Kermit is only capable of 2400 baud on a C128, not a C64. Support for 2400 baud is likely to appear in the future (hey; a C64 is a slow machine.) There is a problem that occurs at 1200 baud on some modems when connected to a C64. The C64 thinks it is a C128 and uses slightly different timing. Some modems don't care, others do. There is a fixed version of Kermit 2.2, but this version is not widely distributed. There are no known problem with 300 baud. >The problem is : After the usual procedure >of dialing the number manually and hearing the high pitch tones, the modem >did not kick in to do the rest !! Are there some parameters (that I am not >aware of) that need to be set beside baud rate in KERMIT ? What about a >parameter in KERMIT called rs232-registers ? What should be its hex value? >Any help is appreciated !! My guess is that there is something *inside the modem* that is not set properly. Perhaps you are not sending an AT sequence that your terminal program does. The "set rs232-registers" command is going away soon. In older versions of Kermit, the "set rs232-registers" command was used to specify baud and parity with a cryptic hex number. The typical "gotcha" in Commodore Kermit is changing parity without changing word-size. If you are using no parity, you should be using eight bit words. If you are using any other parity, you should have seven bit words. (Perhaps this ``feature'' is too confusing to be worth keeping.) Ray ------------------------------ Date: Tue, 20 Jun 89 21:16:37 EDT From: "Roger Fajman" Subject: Re: Using Kermit on Ethernet? Keywords: Ethernet > [Ed. - There are many requests for this. The most practical approach to > adding TCP/IP Telnet support to MS-Kermit would be to take the board-level > drivers from NCSA Telnet and convert them into TSR Bios-level drivers for > COM1. Then let MS-Kermit's SET PORT BIOS1 command do the rest. This > apparently already works with certain commercial IP products, e.g. Interlan's > TCP/IP Gateway for Novell networks (see Info-Kermit V9 #8).] FTP Software recently announced INT 14 support for their PC/TCP product, which supports many network boards. I haven't had an opportunity to try it with MS Kermit yet. ------------------------------ Date: Sat, 03 Jun 89 18:01:01 EDT From: Peter Jones Subject: Kermit for Navigator Keywords: Navigator, Blind, Braille Some time ago, I announced I would be interested in developing a KERMIT system for the VBII terminal for the blind, an 8080-based braille workstation. I have decided to abandon this project, as too much investment would be required to support and debug an 8080 program in our environment. Telesensory Systems Inc has announced a new device called the Navigator. This is a PC-like system with braille I/O. As we use PC's at UQAM, support would be available. I'm wondering if anyoune has tried Kermit on the Navigator. Would a special version be required? Peter Jones MAINT@UQAM (514)-282-3542 "All's well that ends." :-) ------------------------------ Date: Fri, 21 Apr 89 09:16:59 MET From: "Boelen, Lodewijk J.M." Subject: Errors Compiling Amiga Kermit Keywords: Amiga C-Kermit, Commodore Amiga Lectori Salutem In December I have got both the sources and a BOO-ed version of Kermit on my Amiga. By curiosity I compiled the sources with the Lattice 3.10 compiler to get acquainted with the software available on my new (second hand) AMIGA2000. I love that machine! I remarked the following compiletime errors: 1.there are many warnings 89 on the variables "pid" and "D7Save" and others; 2. ckitio.c: .1 error 71: formal declaration error "m"; .2 error 9: undefined identifier "m"; .3 error 63: duplicate declaration of item "m"; 3. ckifio.c: error 57: semicolon expected; 4. ckuus3.c: error 25: invalid macro usage. The total time needed for compilation on my two-diskette machine, with an adapted make-file, is 15 minutes. On scanning the sources near the marked lines I made some changes I will describe hereafter. All the compiletime errors were gone but the one in ckuus3.c. To get a Kermit program I had to attack the BOO-ed version I guessed to be in ckiker.upd. When anyone is interested I will mail my critics and the way I got a working Kermit program. I could emulate a terminal, that's all. I called for HELP but got no responses on the sources problems. So I waited for the newest version, announced in the meanwhile, hoping on the errors to be corrected. Before yesterday I compiled the newest sources the first time. I was sad to find the same errors as described above plus one: the version of HEARN's ckucmd.c is cut off. After receiving the TUVMA-version and applying the corrections, yesterday I got in the same situation as in January. So now my second call for HELP! Here are the corrections on the lines of the actual version: 1. ckitio.c: all the errors are gone when you change line 692 from: "int n, m;" into: "int n;" and insert after line 695: "int m;"; 2. ckifio.c: a little above line 343 you can find: "return(...));". If you change this line in "return(...);" (one ")" less!) all is well. I don't know C though it looks very nice, but also a colleague could not find a solution on the error in ckuus3.c. I wonder if the warnings are not harmful, but I don't know to correct them. Can anyone help me? I would be grateful, Lodewijk. [Ed. - To our knowledge, nobody has worked on the Amiga-specific portion of C-Kermit since Steve Walton's contributions of January 1987, listed in ckiker.upd. If anyone out there has worked on upgrading C-Kermit's Amiga support to the current version of C-Kermit -- or better still, the test version 4F with file attribute packets -- please let us know! Or if you are willing to volunteer to take on the job, also please tell us. Until then, the best we can do is add Lodewijk's message to the ckiker.bwr file.] ------------------------------ End of Info-Kermit Digest *************************