info-kermit@ucbvax.ARPA (03/13/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA> Info-Kermit Digest Tue, 12 Mar 1985 Volume 2 : Number 12 Departments: ANNOUNCEMENTS - Info-Kermit Mail Corrected Apollo (Pascal) Kermit UNIX KERMIT - C-Kermit and RTU 2.2 C-Kermit for Unix Version 7 C-Kermit vs 8-bit Files vs Parity HP 9000 Series 500 Kermit, suggestions... New C-Kermit for VMS MISCELLANY - Resonating Packets, Cont'd Wanted: Disk-Full Handling for Floppy Based Kermits ---------------------------------------------------------------------- Date: Tue 12 Mar 85 18:48:24-EST From: Frank da Cruz <SY.FDC@CU20B> Subject: Info-Kermit Mail To: Info-Kermit@CU20B Apologies to those who received several issues of the Info-Kermit Digest twice. The duplication was not caused by mail delivery problems; these issues were directed at Info-Micro and Info-Unix as well as Info-Kermit because they contained announcements relevant to the new Unix Kermit, which has been the subject of some discussion on those two lists in recent weeks. BITnet members of Info-Kermit are now addressed through the Wisconsin gateway, WISCVM, rather than the Berkeley gateway, UCB-VAX, which is being phased out. If you're a BITnet subscriber and did not receive this message, let me know! ------------------------------ Date: Sun 10 Mar 85 20:04:45-EST From: PHY1.J-GROVES@CU20B Subject: Corrected Apollo (pascal) KERMIT To: sy.fdc@CU20B.ARPA The corrected version of the apollo (pascal version) kermit, as per our conversation of the past week, is ready. I have been using it for about a week now and it seems to work properly, within its original bounds. I expect to add a number of useful features to the present code, such as terminal emulation (the Cyber terminal that is presently emulated is not useful to me) and remote capabilities. I will forward these additions to you as soon as they are complete. Phil Kravitz [Ed. - The original copy of Apollo Kermit (Pascal version) a number of lines truncated in the source file. Phil has figured out what the missing characters must have been and restored them. The updated copy is in KER:APOLLO.PAS on CU20B, available via anonymous FTP.] ------------------------------ From: Stan Barber <neuro1!sob@rice.ARPA> Date: Sat, 9 Mar 85 14:50:03 cst Subject: C-Kermit and RTU 2.2 To: sy.fdc@cu20b The generic SYSIII/SYSV version of kermit 4.2 seems to compile up just fine on RTU 2.2. I will examine the code more closely to see if there are refinements that might take better advantage of the system. Line locking seems to be the only problem when the /usr/spool/uucp file is writable by UUCP and root only. Stan [Ed. - I've received a lot of complaints about the uucp line locking. Before release of this version, all Unix experts agreed that /usr/spool/uucp would be publicly writable on all Unix systems. It turns out not to be true. In fact, on some systems it may not even be readable! This whole business is a can of worms. Why Unix did not, from the beginning, in all its forms, allow a tty device to be opened with exclusive access is beyond me... The next release of C-Kermit will come with some kinds of options as to how to handle line locking.] ------------------------------ Date: 9 Mar 85 16:43:30-CST (Sat) From: Gregg Wonderly <gregg%okstate.csnet@csnet-relay.arpa> To: sy.fdc@cu20b.ARPA Subject: C-Kermit for Unix Version 7 Frank, I have the Version 7 mods made to the new C-KERMIT (Release #2). The only necessary mods seem to be in the ck[xz]unx.c files. I still would like to do more testing, to make sure it really works properly. Gregg Wonderly Department of Computing and Information Sciences Oklahoma State University [Ed. - This will be incorporated into the next release.] ------------------------------ Date: Sat, 9 Mar 85 17:38:07 est From: hipl!tony@nyu-cmcl2 (Tony Movshon) To: sy.fdc@cu20b.ARPA Subject: C-Kermit vs 8-bit Files vs Parity If the 4.2bsd C-Kermit file-type is set to binary, parity is set to anything other than none, and the remote kermit (in this case, the old Unix Kermit 3.0) does not accept 8th-bit prefixing, C-Kermit goes ahead and sends the file anyway, despite the fact that it must know that it's stripping and throwing away all the high bits. Surely it should report an error? [Ed. - The behavior is correct, but you're right, C-Kermit should report an error in order to give the user the chance to interrupt or cancel the file transfer if this effect is not desired. The next release will issue a message when this happens.] ------------------------------ Date: 10 March 1985 22:57-EST From: Yekta Gursel <YEKTA @ MIT-MC> Subject: HP 9000 Series 500 Kermit, suggestions... To: sy.fdc @ CU20B I managed to get the new C-Kermit running on the HP 9000 Series 500 computers. This is a completely different machine than HP 9000 Series 200. The version of Unix we have is HP-UX 3.25 bqa. We will soon get the HP-UX version 4. I'll make it run on that as well. I do not mind supplying kermit support for HP 9000 Series 500 machines. I'll outline the changes that have to be made: I used the "make sys3" option with the following changes. 1) Remove the "-i" option from the CFLAGS and LNKFLAGS in the makefile. 2) In the line "wart ckprot.w ckprot.c; cc ... " replace "wart" with "./wart" in the makefile. The reason for this is that if "." is not in the current PATH, make will fail unable to find "wart". We have an open system, and "root" does not have "." in its path in order to prevent "trojan horses". People sometimes do funny things in an open system. Sigh. 3) In the file "ckxunx.c", on line 125: Comment out, or conditionalize out the line "#include <sys/file.h>". This file does not exist in HP-UX, the definitions are in the kernel. Similarly, in the same file on line 138: Comment out, or conditionalize out the line "#include <sys/ioctl.h> for the same reason. 4) In the file "ckzunx.c", on line 93: Comment out, or conditionalize out the line "#include <sys/file.h>", for the same reasons stated above. After these changes, C-Kermit will compile and run just fine. Finally, a suggestion: How about making the string "C-Kermit" which appears in all error messages, disconnect messages, default prompt, etc.. user specifiable at compile time, with "-D" flag for example, so that one can "customize" C-Kermit for a given machine by replacing it with something that identifies the machine? This will make life easier if one is going through a whole bunch of kermits. Even with two of them, it is sometimes confusing if both of the machines are running C-Kermit. Best, Yekta ( YEKTA@MIT-MC ) [Ed. - Good idea; perhaps the string could also be tied to "set prompt" at runtime. I expect your HP-9000 changes will be incorporated into the next release.] ------------------------------ From: stew%lhasa.UUCP@harvard.ARPA Date: 10 Mar 85 22:52 EST To: harvard!sy.fdc@cu20b.ARPA Subject: New C-Kermit for VMS OK, everything appears to be working. I would say it is ready for an alpha test release. Following is a complete list of the changes I had to make: CKCMD.H Added a #define for CR. CKCMD.C Changed all putchar's to conoc's. We want unbuffered output here, and that means conoc, no? Likewise getchar -> coninc. conoc(CR) added under #ifdef vax11c at the end of the input line. [Ed. - This will not necessarily be in the released version; it might break the take command, and also interactive operation on certain versions of Unix.] CKCONU.C Wrote a version of conect() that doesn't use fork(). What it does instead is call a system specific function, contti(c, src), which returns when a character is available from either console or comm. line. Also, a function, cancio(), is called at the end of the NO_FORK version of conect(). CKDEBU.H Added the parameters GOOD_EXIT and BAD_EXIT. On VMS, exit(1) is the success exit, not exit(0). CKDIAL.C Used a timed ttinc() rather than alarm(). On VMS, an alarm will not break through a pending read, so this method of timing out will not work. CKFNS2.C Used GOOD_EXIT rather than 0 in a couple of exit()'s. CKLOGI.C Used a timed ttinc() rather than alarm(). See CKDIAL.C. CKMAIN.C Used GOOD_EXIT rather than 0 in a couple of exit()'s. CKUSER.C Added a #define KERMRC ".kermrc" or "kermit.ini" under an #ifdef vax11c. Also changed some exit()'s. CKUSR2.C Added 19200 baud to the help string under #ifdef vax11c CKUSR3.C Added 19200 baud under #ifdef vax11c CKXVMS.C New file. Originally, I had this combined with CKXUNX.C. The result was 40K. The original CKXUNX.C was 30K and CKXVMS.C is under 19.5K. What do you think? CKZVMS.C New file. Figures are 27K (est.), 22.5K and 14.5K. Stew [Ed. - C-Kermit for VMS will be incorporated into a future release, depending upon when it arrives.] ------------------------------ Date: Mon, 11 Mar 85 17:50:26 pst From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:poulton@hplabs.CSNET> To: cc.fdc@columbia-20 Subject: Resonating Packets, Cont'd I ran into a problem with buffer flushing which was intended to avoid this resonating packet problem. Kermit-32 already does a flush-after-read operation. However, when talking to the HP 3000, we found that it was flushing out the XON handshake character from the 3000, causing the transfer to go very slowly. (It was never discovered when talking to IBM systems because they apparently always had sufficient delay on the IBM side to let the VAX flush before the XON came. The 3000 can send the XON soon after sending out a packet.) Flushing is, of course, not needed when talking to half-duplex machines like IBMs or HP 3000s, so the temporary fix was simple: I now have a hacked version of Kermit-32 which simply omits the flush. The moral of the story: if you add flushing on every packet (in addition to the normal flush-at-start-of-transaction) PLEASE PLEASE PLEASE turn it off when in HANDSHAKE XON or IBM_MODE. And while I'm at it, here's another request to Kermit implementors: please separate HANDSHAKE XON from the PARITY and ECHO options commonly lumped into IBM_MODE. The HP 3000 needs HANDSHAKE XON, but not the others! Ken Poulton [Ed. - Buffer flushing and line turnaround handshake can coexist, using the trick found in the new C-Kermit -- If handshaking is being done, then just redefine the packet terminator to be the handshake character. Then, once the packet is read, you can go ahead and clear the buffer. "IBM-MODE" is a hack appearing in the early Kermits -- the ones that didn't have command macros or take files or lots of different SET commands -- to allow them to talk to IBM mainframes. It's shorthand for "set parity mark", "set duplex half", "set flow-control off", "set-handshake xon", "set timer on". It's site-dependent in that not all IBM mainframes use mark parity, but otherwise it tends to do the trick. More advanced Kermits have separate SET commands for all these parameters, and also may have TAKE commands and/or command macros to let you modify them appropriately or set up new macros, like "SET HP3000". Getting these features into older Kermits is just a question of somebody doing the work.] ------------------------------ Date: 10 Mar 1985 0415-EST From: LSM.SMITH at DEC-MARLBORO To: SY.FDC at CU20B Subject: Wanted: Disk-Full Handling for Floppy Based Kermits I would like to see a new feature in KERMIT which would allow the receiving KERMIT to tell the sending KERMIT to pause indefinitely. If properly implemented, this would allow the receiver to tell the sender to pause, exit to the Operating System, format a new floppy, run KERMIT again, and allow the sender to resume. (This last step would probably require the user to supply the name of the file to store the incoming data.) This way very large text files could be stored. [Ed. - I'd like to see it, too. This is a tough issue because it requires new protocol to be defined and implemented. A workaround using present apparatus is to "set incomplete keep" on receiving kermits that have that feature. When a disk fills up, go back to the sender, copy the unsent portion of the file into a new file, and then send that. Clumsy, but if the file was 300K long, and 299K was sent successfully, it beats having to resend the whole thing...] ------------------------------ End of Info-Kermit Digest ************************* -------