Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!decvax!decwrl!ucbvax!info-kermit From: SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) Newsgroups: mod.protocols.kermit Subject: Info-Kermit Digest V3 #34 Message-ID: <12168390938.12.SY.FDC@CU20B.COLUMBIA.EDU> Date: Thu, 19-Dec-85 12:27:48 EST Article-I.D.: CU20B.12168390938.12.SY.FDC Posted: Thu Dec 19 12:27:48 1985 Date-Received: Sat, 21-Dec-85 01:37:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Info-Kermit@CU20B Organization: The ARPA Internet Lines: 451 Approved: info-kermit@cu20b.columbia.edu Info-Kermit Digest Thu, 19 Dec 1985 Volume 3 : Number 34 Departments: ANNOUNCEMENTS - New Honeywell CP-6 Kermit New version of IMUSIC MS-DOS KERMIT - MS-DOS Kermit 2.28 jrd Problems and Fixes IBM-PC Kermit V2.28 jrd Display Problems TopView Support for MS-DOS Kermit More MS-DOS Kermit 2.28 jrd Problems MSBOOT.FOR for Unix f77 MISCELLANY - DEC-20 File Naming Problem Os9 kermit warning! Bugs in the CP/M Turbo-Pascal Kermit V1.00 Re: Apple-II Kermit Bugs ---------------------------------------------------------------------- Date: Thu, 18 Dec 85 10:50 EST From: Frank da Cruz Subject: New Honeywell CP-6 Kermit This is to announce a new Kermit program for Honeywell CP-6 systems from Lee Hallin at Honeywell (Lee-Hallin%LADC@CISL). This one is written in PL/6, a PL/I-like language, and includes text/binary file transfer, wildcards, all the prefixing options, server and client operation, command files, etc, but lacks CRC, file interrupt, attributes. (The other CP-6 Kermit is written in Pascal and comes from Bucknell University.) Lee's new CP-6 Kermit is available from CU20B via anonymous FTP as KER:HC6*.*. Again, apologies to everyone on BITNET for the hiatus in getting new files on KERMSRV; we should be back in business on that end after the holidays. ------------------------------ Date: Mon, 16 Dec 85 20:14 EST From: John Voigt - Systems Group Tulane Subject: New version of IMUSIC I have a new version (1.2) of IMUSIC KERMIT available. This version incorporates several fixes as well as enhancing the set ? function. I have sent you the complete source with all the new changes. JV/ [Ed. - Thanks! This replaces the previous version (1.1) on CU20B. It's in KER:IMUSIC.ASM.] ------------------------------ Date: 12 Dec 85 21:23:04 PST (Thu) Subject: MS-DOS Kermit 2.28 jrd Problems and Fixes From: donovan@aero I've attached a fix to MS-DOS Kermit v2.28 rjd for a problem in the send protocol. The problem occurs when a send command follows a Kermit generic command which causes flags.xflg to be set. This happens whenever a remote server displays output on the local screen. The GENRIC procedure in MSSSER is the culprit, but the simplest fix is to reset xflg in the SEND command processor just before the server entry point at SEND11. Here are diffs for MSSSEN. ..........mssend.old ; Send command ..........msssen.asm ; Send command - protocol handler to send a file ; Normal entry - SEND does file transfer preceded by "F" packet ; resets xflg ; Server entry - SEND11 does file transfer preceded by "X" packet ; set xflg = 1 before call ..........mssend.old send11: mov flags.nmoflg,0 ; Reset flags from fn parsing. [21a] mov ah,setdma ; set dta address [jrd] ..........msssen.asm mov flags.xflg,0 ; Reset flag for normal file send [mtd] SEND11: mov flags.nmoflg,0 ; Reset flags from fn parsing. [21a] mov ah,setdma ; set dta address [jrd] [Ed. - Thanks! This was the most glaring bug in this version.] Also, the Z-100 version has had a bug in backspace processing since v2.27. When entering Kermit commands at the prompt, backspace (^H) won't back up over characters on the screen. The problem is caused by a change made to MSSCMD.ASM near the label "cmge11". Backspace was removed from the set of characters which are echoed. The fix is to change MSXZ10.ASM to send an extra backspace. "diff"s below. ..........msxz10.old delstr db BS,' ',BS,'$' ; Delete string. [21d] home db ESC,'H$' ..........msxz10.asm delstr db BS,BS,' ',BS,'$' ; Delete string. [21d] home db ESC,'H$' The MS-DOS version with Joe Doupnik's modifications works with both HP150 and, with this fix, Z-100 modules. Joe's modifications are a major improvement to MS-DOS Kermit. I suggest that once the documentation catches up with the programming, the revised Kermit should be accepted as MS-DOS Kermit v2.29. [Ed. - Well, a couple more problems remain, and the contributions keep pouring in. But you're right, we have to draw the line somewhere. See below...] ------------------------------ Date: Sat 14 Dec 85 05:33:09-EST From: Kathleen Connors Subject: IBM-PC Kermit V2.28 jrd Display Problems I tried the new 2.28 version of Kermit for the IBM PC tonight. It still has some of the same problems (2 out of 3) that the old 2.28 version had, which I reported to you last June. 1) When you GET a file the file transfer screen puts an "s" in upper left hand corner of the screen. 2) The mode line under the same conditions displays nothing except a single "^" in the first position. The truncation of the file name upon receiving a file has been fixed. I am using a IBM PC I (64k motherboard), 512k of memory, DOS 3.0 and a internal Qubie (Hayes compatible) modem. Since these problems, albeit cosmetic, still exist I will probably continue to version 2.27. [Ed. - Has anyone else ever seen this? I haven't, and I've been running both 2.28 and 2.28 jrd on an IBM PC for a couple weeks.] Suggestions for future Kermits: 1) A means of clearing the terminal screen buffer from the local Kermit. 2) The Kermit initialization file should be allowed to be called KERMIT.INI instead of MSKERMIT.INI. [Ed. - The reason it's called MSKERMIT.INI is that if you accidentally transfer your KERMIT.INI file from a mainframe, you'd be in for some nasty surprises the next time you started Kermit up on your PC.] 3) The ability to send a file "raw" without the Kermit protocol just xon/xoff. [Ed. - Everybody wants this, along with login scripts and a DIAL command. Maybe someday someone will write the code.] ------------------------------ Date: 12/16/85 6:10:45 E.S.T. From: TUCBOB@TUCCVM.BITNET Subject: TopView Support for MS-DOS Kermit Here is a new MSYIBM terminal emulation module; the following changes were made: . ANSI set graphics rendition support extended to handle color attributes in addition to monochrome . Direct moves to and from the video buffer modified to use TOPVIEW interrupt codes, so that KERMIT can run in the background under TOPVIEW and take advantage of TOPVIEW windowing support. The following parameters are used in a TOPVIEW Program Information File to run KERMIT under TOPVIEW with the MSYIBM TOPVIEW support added. Memory: Variable. Suggest min and max be set to 128K to allow 'run' support. Set system memory to about 20K Screen type: D Pages: 4 Window size: 25 by 80 Offsets: 0 0 Writes directly to screen: no Accesses system keyboard buffer: no Runs only in the foreground: no Uses math coprocessor: no [Ed. - Thanks! I haven't had a chance to try this out, but if these are the only changes, then it should be compatible with JRD's new stuff, except for one minor change that JRD made about Heath line wrap. If anybody wants to try this out, the file is with JRD's Kermit, stored as PS:MSYIBM.TOP on CU20B only -- If you take it, please report back about how/if it works, and whether it's safe to distribute as the standard version.] ------------------------------ Date: Thu 19 Dec 85 09:24:23-EST From: Frank da Cruz Subject: More MS-DOS Kermit 2.28 jrd Problems Beyond the bugs reported already (like the X-Flag bug), there are at least two subtle problems with the new MS-DOS Kermit. First, even when assembled correctly with the "right" assembler and switches, it will sometimes (very rarely) start executing garbage after a CONNECT command. This happened to me exactly once in several weeks of constant use -- I had escaped back from a connection to the DEC-20, gave the DO IBM command, switched my port contention unit to the IBM mainframe, gave the CONNECT command, and poof -- system totally dead, had to be rebooted. A few other people have reported similar occurrences. I can't reproduce it; can anybody else? The second problem applies to earlier releases as well, but only shows up on a PC/AT, and (for us at least) only when communicating with a half duplex system at 9600 baud using handshake. The sympton is that, after the end of a file transfer session from the mainframe to the PC, after the mainframe sends the B (Break transmission) packet, the AT responds with its ACK, but the ACK shows up as garbage at the mainframe. If on the AT you SET DEBUG ON, the problem goes away. When the connection is run through a line monitor, everything appears normal; the AT responds to each packet from the mainframe immediately as the XON handshake appears, and ACK is in correct format. The speculation is that the AT is somehow ACKing the B packet "too fast". Even though we haven't caught it sending the ACK prematurely on the line monitor, the behavior is exactly what you'd expect if a transmission occurred before the line was fully "turned around". Why would this happen after a B packet, but not after any other packet? Several possible explanations suggest themselves: (a) unlike most other packets, the B packet requires no processing, and can be ACK'd immediately; (b) MS-DOS Kermit somehow forgets about handshaking after the B packet; (c) MS-DOS Kermit is handling the UART incorrectly. I think (b) is unlikely; we never saw any supporting evidence on the line monitor. While (c) is a possibility, it would take a lot of digging through the low-level code to show up a problem; a cursory inspection reveals nothing obvious (the UART's output holding register is always tested for emptiness before giving it the next character). If (a) is true, it would imply that the host is sending its XON before it is really and truly ready for input. Unlikely as this may seem (it's a lightly-loaded IBM 3083), the fact that the problem only happens with the AT -- which is much faster than the PC or the Rainbow -- lends some credence to this theory. If this is the real explanation, then the thing to do would be to insert a brief sleep in MS-DOS Kermit before ACKing the B packet. But there are also some other packets that don't require any processing, namely those that arrive with bad checksums; thus we might have to sleep before retransmitting or NAKing as well. If anyone can offer any insight or evidence to support any of these theories, it would be much appreciated. But beyond that, we may have here a presage of things to come. As microcomputers get faster and faster, they may begin to strain the assumptions underlying the design of our communications equipment. ------------------------------ Date: 13 Dec 1985 1427-EST (Friday) From: Tom Putnam Subject: MSBOOT.FOR for Unix f77 The subject FORTRAN program is supposed to be run on a host machine in conjunction with MSPCBOOT.BAS on a target MS-DOS machine to download MSKERMIT.BOO and similar binary files. The program requires several modifications to operate under UNIX. (We are running UNIX 4.2 BSD). In particular: * The variable ACK is declared as a 4-element array, but only the first element is ever used. The initial READ statement: READ (5,200) OK, SPACE, COMMA, ACK 200 FORMAT(4A1) implies that the whole array ACK will be read. Since the format does not allow enough elements, a second "line" or "record" of input is requested, so file transfer never gets off the ground. * The write statements include a blank for carriage control. Although some systems strip this character on output to the terminal, UNIX terminal output includes the blank and thus fouls up the character count check. I corrected these problems, converted the program to FORTRAN-77, and cleaned-up the logic a little so that we could use it on our systems. The modified version of the program is available via anonymous ftp from ASC.PURDUE.EDU in the "kermit" subdirectory, file name "msboot.f". [Ed. - It's also on CU20B as KER:MSBOOT.F.] Tom Putnam, Manager of User Services Purdue University Computing Center ARPANET: ac4@asc.Purdue.EDU or ac4@purdue-asc.ARPA BITNET: PUTNAMT@PURCCVM CSNET: ac4@purdue-asc-tn USENET: ac4@pucc-j.UUCP USMAIL: Mathematical Sciences Bldg. West Lafayette, IN 47907 PHONE: 317/494-1787 ------------------------------ Date: Tue, 17 Dec 1985 13:34 EST From: CPH%MIT-OZ@MIT-MC.ARPA Subject: DEC-20 File Naming Problem I am using TOPS-20 Kermit version 4.1 and running into the following problem: The filenames that I am using on my microcomputer are in the same format as TOPS20 filenames, that is, "..". The software system maintains the version numbers in the usual way. As we have quite a few of these computers, which are not tied together with a network, we use Kermit to transfer files to and from MIT-OZ, our DEC 20. This gives us all a shared file system to work from. Now, my problem is that I want to transfer files from my local machine to the 20, retaining the version number (note that this works fine when transferring from the 20 to the local machine). This is so the version numbers on the 20 will match the version numbers on the local machine. Unfortunately, TOPS20 Kermit doesn't have an option to do this. As far as I can tell, the only options I have are "set file naming unconverted" and "set file naming normal-form". In neither case is the version number I specify used to write the output file on the 20. Instead, the file is forced to be a "newest" generation -- either "FOO.BAR.34.0" (where the is "BAR.34") or "FOO.BARX34.0", respectively. Could this be changed? It seems to me that if the version number is explicitly specified, it does no harm to open the output file under that name if one does not already exist. Or, if that is not reasonable, could you add an option, say, "set file naming literal", that does what I want? It is really a pain for me to have to rename all my files after I transmit them. Thanks, Chris Hanson [Ed. - Thanks for the suggestion. I'll try to add another file-naming option to Kermit-20 in the next release.] ------------------------------ Date: Mon Dec 16 10:58:59 EST 1985 From: dolqci!irsdcp!scsnet!sunder@seismo.CSS.GOV Subject: Os9 kermit warning! A warning about using kermit under os9 on a tandy CoCo: If you use kermit with the multi-pak and the delux rs-232 pak, that is you intend to use /t2 as your outgoing device you MUST have the rs-232 pak in slot 1 of the multi-pak. In fact the device driver for /t2 requires that the rs-232 pak be in slot 1. ANY program that uses /t2 will only run if the rs-232 is in slot 1. Also it appears that you must have the carrier forced on BEFORE you run kermit if you are using sometype of smartmodem. (maybe some os9 wizard out there can find a patch to the device driver to let /t2 look for the rs-232 pak in another slot). Kermit on the CoCo is still (as far as I know - maybe bob larson knows more) untested using device /t1, the so called "bit banger" port. ~ Addresses: USmail: IRS, 1111 Constitution Ave. NW Washington, DC 20224 ~ ~ Atten: M. Sunderlin PM:S:D:NO Office Phone: ~ ~ UUCP: ...seismo!dolqci!irsdcp!scsnet!sunder (202) 634-2529 ~ ~ ...decvax!philabs!ubbs!sund (FTS) 634-2529 ~ ~ CIS: 74026,3235 ~ ------------------------------ Date: Wed, 18 Dec 85 13:32:59 cst From: Jeff Woolsey Subject: Bugs in the CP/M Turbo-Pascal Kermit V1.00 I have found and fixed a few bugs in the Turbo Pascal Kermit for CP/M-80, and made some simple but useful enhancements. Bug #1: Binary file transfers "worked" (everybody was happy with checksums) but the file was missing the 8th bit sometimes. &X would not get the 8th bit set, but &#X would. The code that checked for control characters in this case forgot that this was an &-quoted character if it wasn't also #-quoted. The fix in the else clause should be obvious. See procedure expand_packet in file KREC1.PAS here: [Ed. - Code omitted.] Bug #2: This first showed up as filenames listed by the DIR command being separated by linefeeds. The solution eluded me until I realized that I was in user area 10 (= ASCII linefeed) at the time. Fix it by not writing the first "character" of the file name. See procedure writefilename in file KDIR.PAS. Bug #3: The scourge of all machines using 16-bit signed integers. The displays of bytes (remaining to be) transferred wrap to negative integers above 32767. Since this number is calculated by multiplying blocks by 128 (an integer), you really only get 9 bits of information there. This can be remedied by multiplying by 128.0 (a real) and formatting the result. See procedure update in file KDISPLAY.PAS. See procedure open_file in file KOPEN.PAS. Enhancement #1: I got tired of having to tell the host explicitly the name of each file I was downloading when I should have been able to use wildcards. The impediment here is that Turbo Kermit goes to receive_init state when it gets the EOF packet, and expects a send_init packet from the host. Instead, it gets a file_header packet, and aborts. A two-line change allows Kermit to receive multiple files in this case. Find the repeat/case/until block that processes the incoming packets. Only one of the cases ever sets the state variable (to receive_init). Change it to receive_header, and add a clause to the until condition checking for state <> receive. See procedure rfile in file KREC1.PAS here [Ed. - Code omitted.] Enhancement #2: Especially in conjunction wtih Enchancement #1, I wanted to be able to see the name of the file being transferred along with all the other statistics being displayed. I stuck "gotoxy(58,2); write(fileref);" at the front of procedure open_file in file KOPEN.PAS. The above should be of general interest. What follows summarizes the other, more machine-specific changes that I needed to make. I undid the IOBYTE stuff so that I could support all 4 of the serial ports on my system. I have a 1200 bps autodialing modem and a dumb 2400 bps modem and I wanted to be able to autodial 2400 bps systems. I support searching through the various PAMS/PDSE/et.al. BBS lists and extracting the phone numbers. I rewrote pieces of the command processor to make it easier to add new commands while retaining the ability to abbreviate them to uniqueness, and I implemented meaningful semantics for commands like CONNECT 1 or RECEIVE FRED.PAS . I have a text capture mode, and if I desire the terminal handler converts ANSI escape sequences into H19 sequences for my console. ... The aim of Nuclear Freeze is to prevent Nuclear Winter. Jeff Woolsey ...ihnp4{!stolaf}!umn-cs!woolsey woolsey@umn-cs.csnet [Ed. - Thanks. I've put this message in full (with code) in KER:TURBO.BWR on CU20B, and have also passed it along to the Turbo Pascal Kermit authors.] ------------------------------ Date: Wed, 11 Dec 85 16:55:16 PST From: Samuel_Lam%UBC.MAILNET@MIT-MULTICS.ARPA Subject: Re: Apple-II Kermit Bugs >This may be related to the bug that strips out '&' on reception of files. This IS the bug that strips out '&' on reception regardless of the setting of text/binary and 7/8 bit data path. When it sees an '&' in the incoming data stream, it just unconditionally strips it and turns on the 8th bit of the next character. Sam Lam ------------------------------ End of Info-Kermit Digest ************************* -------