31-Dec-86 15:55:39-EST,14580;000000000000 Mail-From: SY.FDC created at 31-Dec-86 15:54:33 Date: Wed 31 Dec 86 15:54:33-EST From: Frank da Cruz Subject: Info-Kermit Digest V5 #20 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12267256864.290.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Wed, 31 Dec 1986 Volume 5 : Number 20 Today's Topics: Series 1/7171 Support in NIH TSO Kermit Speed Problem Between ProComm and Kermit-CMS C-Kermit With Intel Xenix Fix for Unix Kermit on SCO System V C-Kermit and Valid Workstations Where to Send HP-1000 Kermit Requests ---------------------------------------------------------------------- Date: Sat, 20 Dec 86 21:00:25 EST From: "Roger Fajman" Subject: Series 1/7171 Support in NIH TSO Kermit Keywords: TSO, MVS/TSO Kermit One important correction to Info-Kermit V5 #19: NIH TSO Kermit does not presently have Series 1/7171 protocol converter support. We don't have those machines. If someone wants to send us the modification, we will be glad to include it. [Ed. - Oops! Sorry. It appears that reports of the death TSOS1 were somewhat exaggerated. Volunteers? Also, note that the "other" new TSO Kermit, expected in the not-too-distant future, should indeed support both Series/1 (full screen) and 37x5 (linemode) style hookups.] Also, I checked the files as they appear on KERMSRV at CUVMA, and found some erroneous translations between vertical bars and exclamation marks. The following files contain real exclamation points: TSNKER.ALP (just a comment), TSNKER.DOC, TSNEDR.DOC, TSNMAC.DOC, and TSNTBL.ASM (in the translate tables). The last one is the most serious. [Ed. - Oops again! That's what comes from reading EBCDIC tapes on a Unix system with 'dd'... We'll try to get clean copies of these files over BITNET to replace the current copies. It has also been reported that some files have U and e where square brackets ([) and (]) ought to be.] ------------------------------ Date: 1986 Dec 22 13:52 EST From: (John F. Chandler) Subject: Speed Problem Between ProComm and Kermit-CMS Keywords: ProComm, CMS Kermit, Series/1 I have seen reports of the problem from a number of places now, some not specifically mentioning the use of a 7171, but none mentioning anything else. The implication of the latest report (in Kermit Digest #19) is clear: ProComm needs to be fixed. However, I should add that the XON added to the end of each packet by CMS Kermit is not essential and could be removed if necessary. It was added as a convenience for the micro Kermit -- the rule of thumb is: when talking to an IBM mainframe, always wait for an XON before sending the next packet. The rule is not true for the various protocol converters (Series/1, 4994, and 7171), but the added XON makes it harmless. How does ProComm perform when told to wait for the XON? ------------------------------ Date: Mon, 22 Dec 86 21:26 CST From: Wilkinson@HI-MULTICS.ARPA Subject: C-Kermit With Intel Xenix Keywords: Xenix, C-Kermit I have been running 4D(061) under Intel Xenix(3.3) on an Intel 286/310 system for some time now with no problems. I used "make xenix". I also got a clean compile/link for an older UniPlus (UniSoft System III) for 4D(061). It is running, but I have not used it extensively. I used "make sys3". Richard {Wilkinson@HI-MULTICS.ARPA} ------------------------------ Date: 21 Dec 86 04:30:32 GMT From: ihnp4!killer!alleng@seismo.CSS.GOV Subject: Fix for Unix Kermit on SCO System V Keywords: C-Kermit, SCO Xenix, Xenix I have some info that may be useful in trying to determine why kermit (wermit) specifically ckuker does not want to run on Xenix sys V (SCO). I noticed a discrepancy in the server mode prompt from any other system to an SCO system. On most systems, the prompt is "# N3". HOwever, on Xenix, the thing comes up "# N/". A Xenix system will talk to another Xenix system (SCO), but cannot communicate with any other systems for protocol transfer. The problem comes from performing functions on unsigned and signed ints. For some reason (compiler bug), when certain operations are performed on standard ints, the sign bit gets set (lsb in MS byte). This makes checksums come out screwy. To resolve this, edit the module 'ckcfn2.c' (by the way, we are talking about ckuker here) look for the function 'C K U 1'. You will notice an 'int chk' below the function heading. Simply change it to 'unsigned int chk' and the version should work perfectly. My thanks to all who helped isolate this... Allen [Ed. - Hmmm... What version of C-Kermit has everyone been using? This change was made months ago, either in 4D(061) or 4D(060). Maybe if everyone with SCO Xenix systems tries the current version - 4D(061) - the problem will disappear. Could some SCO Xenix users verify this??? By the way, I think Allen meant to say 'C H K 1' rather than 'C K U 1'.] ------------------------------ Date: Tue, 9 Dec 86 16:12:13 pst From: hplabs!valid!carolf@gumby.arpa (Carol Fernihough) Subject: C-Kermit and Valid Workstations Keywords: C-Kermit, Valid Workstations I'm unclear as to where to mail bug reports regarding kermit. I'd like my mail find its way to 1) kermit programmers at Columbia University, and 2) a network, so that I could receive responses from other users who can suggest fixes. Would you please forward this mail if necessary, and let me know where I should send UUCP mail. Although I have access to kermit information via the mod.protocols.kermit newsgroup on Usenet, I do not have permission to post to the moderated newsgroup. [Ed. - UUCP mail can be sent to ...!seismo!columbia!cu20b!info-kermit] I have tested version 4D(060) of c-kermit quite extensively on Valid's workstation, which is an S320 running 4.2 BSD UNIX. I compiled c-kermit using "make valid". I've found the following problems when transferring files between two S320's: * Use of the -k option corrupts the file during kermit's transfer: This problem also arises when transferring files between the S320 and c-kermit (compiled using "make sys3") on the IBM PC/AT. machineA# kermit -iwl /dev/ttys0 -b 9600 c-kermit(machineA)> connect (log onto machineB) machineB# kermit -ik > file.from_machineA (escape back to machineA) c-kermit(machineA)> send file file -> FILE, Size 50 The text file that arrives on machineB is 52 bytes long since it has a CR LF at the beginning of the file. Binary files are corrupted in the same manner. Text files are corrupted when sent using the -k option with no -i option. [Ed. - We can't reproduce this problem on our 4.2BSD (Ultrix 1.1, really) VAX 750, but it's probably related to the well-known bug which inserts an extraneous CRLF into standard output every 4096 characters (this only happens with the -k option). There's nothing in the C-Kermit code that inserts this CRLF, so it must have something to do with Unix's blocking. Does anybody have an idea what must be done to convince Unix to leave out the CRLFs -- some kind of mysterious ioctl or fnctl applied to stdout, maybe?] * Can't use -c option When I escape (^\c) after starting kermit on machineB, I escape out of the kermit on machineA. This also happens when kermit is started in server mode. c-kermit(machineA)> kermit -cl /dev/ttys0 -b 9600 -iw (log onto machineB) machineB# kermit -iw [Ed. - This is the documented behavior. When you invoke Kermit with action commands (either protocol or connect, or both) on the command line, it acts like a normal Unix command, i.e. it exits when done. Leave out the -c option, and you'll get an interactive Kermit session that you can escape back to.] * This problem occurs randomly. When host to host, and connected to machineB: c-kermit(machineB)> exit (logout from csh) Can't get character: I/O error [Back at Local System] c-kermit(machineA)> (exits directly back to kermit on machineA - should need ^\c first) The problem also occurs randomly when machineB is running in server mode: c-kermit(machineA)> finish c-kermit(machineA)> connect machineB# logout Can't get character: I/O error [Back at Local System] c-kermit(machineA)> [Ed. - This probably is caused by your ports and cables. Most likely, you've got the systems connected by a true null-modem cable, in which one computer's DTR is connected to the other computer's CD and/or DSR. The remote computer may be configured to drop DTR upon logout, which would cause the local one to sense that CD or DSR disappeared, and to return an I/O error the next time you tried to read or write characters to the port. The Kermit connect command exits when it gets an i/o error. Solution: trade in your true null modem cable for a "fakeout" cable in which DTR is connected to CD and DSR within the local connector, or reconfigure your ports to be less persnickety about modem signals.] * When kermit is invoked from a script command, the command line options are ignored. machineA# kermit -iwl /dev/ttys0 -b 9600 machineA's /.kermrc file contains: script gin:--gin:--gin: name ssword: passwd \ machineB#--machineB# kermit~s-iwx send binary_file binary_file.from_machineA The attempted transfer simply times out because kermit on machineA is NOT in server mode, nor have the other command line options taken effect. Workaround: Rather than including command line options in a call to kermit from a script, put the necessary commands in the script or in the remote machine's .kermrc. [Ed. - This is just a guess, but maybe the '-' in '-iwx' is the culprit, since dashes are meta-characters in uucp-style scripts. Try changing 'kermit~s-iwx' to 'kermit~s~055iwx' and see if that works.] * Finish doesn't always work When using a server, type finish, then connect. Kermit will sometimes connect back to kermit on the remote machine rather than the shell on the remote machine. [Ed. - This depends upon whether you invoked Kermit with -x on the command line (in which case it exits to the shell) or with the interactive 'server' command (in which case it returns to C-Kermit> command level).] I've also begun to test c-kermit between the S320 and the Microvax, running VAX version 2.1. I compiled c-kermit on the Microvax using the CKVKER.COM DCL procedure. I've found the following problems: S320 -> Microvax * Can't transfer binary files Both host to host and server transfers corrupt binary files. [Ed. - Presumably you gave the -i option or 'set file type binary' on both ends. Have other users of C-Kermit on VMS found this to be true? I think the problem is that VMS binary files are not simple streams but are structured with particular blocksizes, etc. There's no code in C-Kermit to do this. I hope somebody who's familiar with VMS and VAX-11 C will add this code, or provide some hints or workarounds to this problem.] * Bye doesn't work When running kermit on the microvax in server mode, type bye, then connect. Bye acts like finish because kermit will connect to the microvax command interpreter prompt. At this point, type logout (which doesn't echo on the screen). [Ed. - Again, sounds like something to do with VMS. Maybe VMS doesn't allow a program to log out its own job unless the program is started or configured with some specific capability. Can any VMS experts answer this?] * Finish doesn't work When using the microvax as a server, type finish, then connect. Kermit will connect back to kermit on the microvax rather than the command interpreter. [Ed. - As in the Unix case, it depends on how the program was invoked.] * Exit doesn't always work Sometimes no action will be taken in response to exit. Quit always works however. [Ed. - That's strange, because quit is simply a synonym for exit -- both are associated with exactly the same code.] Microvax -> S320 * Directory doesn't work Directory listed only one file in a directory containing several files. * Cwd doesn't work Cwd caused an access violation and exited from kermit. c-kermit(microvax)> cwd %SYSTEM-F ACCVIO, access violation, reason mask=00, virtual address=00000000, P4 %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel pc abs pc CKVFIO system 3233 17 15122 CKUUSR docmd 1796 1a2 12F53 CKUUSR parser 1635 182 12B69 CKCMAI main 930 BC D918 $ (could not echo - logged out) [Ed. - Again, I appeal to VMS experts for help sprucing up the VMS-specific functions in the CKV*.C modules.] I also have a question. What is the reason for not reading the .kermrc file when the command line contains an action? [Ed. - No special reason except that the structure of the code made it hard to do. This feature should be added in a future release.] UUCP address: ucbvax!hplabs!pesnta!valid!carolf Thanks! Carol Fernihough [Ed. - And thanks to you for your detailed reports. This is how Kermit programs keep getting better. I hope I've answered each point satisfactorily. If not, let me know. - Frank] ------------------------------ Date: Wed 24 Dec 86 10:56:43-EST From: Christine M Gianone Subject: Where to Send HP-1000 Kermit Requests Keywords: HP-1000 Kermit, Interex Paul Schumann has been getting many requests for his version of Kermit for the HP-1000 but is unable to provide such a service. He has asked that in the future people please make such requests of Columbia University or the HP User Groups since these groups are set up to do this kind of distribution. If anyone is interested in becoming a member of the HP User Group, the address is as follows: Interex 680 Almanor Avenue Sunnyville, CA 94086-3513 ------------------------------ End of Info-Kermit Digest ************************* -------