About the Kermit file-transfer protocol and about terminal emulation under various Kermit implementations (archives of various Usenet discussions) -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- 2002: Newsgroups: comp.protocols.kermit.misc Message-ID: Organization: Columbia University Date: 1 Dec 2002 10:11:53 GMT From: Jeffrey Altman Subject: A Letter to the Kermit Community 1 December 2002: Today marks the end of a significant period in my life. For the last eight years I have been privileged to work on and support Kermit as my career. I began working for Columbia University after nearly seven years as a Kermit user and eventually as primary developer of OS/2 C-Kermit which became the basis for Kermit 95 on Windows 95/98/ME and Windows NT4/2000/XP. During this time the Kermit project shipped 23 releases. The initial version of K95 was shipped on Oct 5, 1995 just seven months after I joined Columbia University. K95 was not only a port of OS/2 C-Kermit to Windows but an attempt to make C-Kermit easy to understand for beginners by adding a Graphic Front End and to do so in a manner that would be inherently cross platform. Back then our dreams were to build a front end that could be supported on OS/2 and 32-bit Windows with the ability to easily port it to MacOS and X-Windows. At the time our development platform had to be selected, Java was not even announced to the world. (That occurred in early August 1995.) We selected Zinc as our cross platfrom development environment. Unfortunately, cross platform development environments that wrap existing OS components tend to be lowest common denominator feature sets and result in apps that are not entirely what the end user expects. (Java discovered this with the original AWT library and eventually constructed the Swing library to avoid the OS dependencies.) For Kermit, the reliance on Zinc allowed us to easily support both OS/2 and Windows but resulted in significant compromises in features as the years went on. The Zinc library was not only lowest-common- denominator but also suffered from two significant problems: . it is a memory and GUI resource hog . the authors never checked memory buffer overwrites These two issues resulted in significant problems in pre-1.1.21 releases of Kermit 95. First, as the number of configurable items in the Settings Notebook increased the required GUI resource allocation increased to more than 30% of the total GUI resources available on Windows 95/98/ME. This would result in unpredictable crashes. The memory overwrite bugs were primarily caused by a failure to allocate enough memory for path names. The Zinc library was originally developed to support DOS, 16-bit Windows, and OS/2. The 8.3 filename restrictions, coupled with the limited drive space available on those systems, resulted in short pathnames. It seems they never anticipated that anyone would want a pathname greater than 64 characters. Now with today's GUIs, coupled with removal of the 8.3 restrictions, it is common for the filename alone to be 64 characters, not even considering the rest of the pathname. The memory overwrites produced data corruption in the Zinc databases that stored the Connection Configurations. The problems became more obvious as users switched to Windows 2000 and began to install K95 in directories with long pathnames or across network shares access via UNC names. For 1.1.21 and later these issues were addressed by a combination of extensive debugging of the Zinc libraries coupled with limiting the number of GUI resources allocated at once. It is due to the latter that the Settings Notebook was broken up into separate (although annoying) settings pages. I'm not going to say that the choice of Zinc was a disaster, but in hindsight it would have been better if the decision to use Zinc could have been put off until Java for desktop development began to stablize. However, waiting until mid-1997 was not an option and now that Zinc has been deployed Kermit 95 has become dependent on its database format. Any attempt to migrate to something else would require either abandoning the existing user data or re-implementing the Zinc database format in the new language. Neither are desireable, nor did we ever have the resources. The use of Zinc did succeed in its initial goals: construct a GUI front end for C-Kermit that would reduce the need for end users to understand the C-Kermit command language in order to configure and establish connections to hosts over a wide range of connection types; and do so on multiple operating systems on multiple architectures in a manner that allowed for database portability. The initial versions of K95 were shipped on OS/2 (X86) plus Windows 95/NT4 (X86,MIPS,Alpha,PPC). We even had a PowerPC version for OS/2 but it was never publicly released since the operating system itself was never released. It was possible to use a single Dialer database on multiple operating systems in multi-boot scenarios. At one point I had a database shared by OS/2, Windows 95, NT4, and Windows 95 (Hebrew edition.) Porting OS/2 C-Kermit to Windows was a challenge in itself. C-Kermit is a single threaded application. OS/2 C-Kermit is multi-threaded (separate threads for command processor, keyboard/mouse input, screen display, and device/network I/O processing) but it can count on all thread independent signals being delivered to the first thread in the process. In Windows, thread-independent signals are delivered to the process in their own thread. To this day I am still not satified with the cross platform model I developed to handle events such as SIGINT. The existing implementation works well enough for most purposes and there have always been an endless number of new features to add to K95 such that I have never had the time to re-visit the design of this fundamental building block. Looking back over the last eight years it is somewhat incredible to think about what was achieved. In 1995, the source code for K95 was less than 80,000 lines in total. The executable for the Windows X86 was 786k. For the 2.1 release the base source code over 500,000 lines of code not including support for SRP, Kerberos, SSL/TLS, and SSH; the k95g executable is 3566.5K. The security protocol support adds another 1.2 million lines of source code plus almost 3MB in supporting DLLs. Then there is all of the documentation that was written: 88,000 lines (the original release had 5235 lines of documentation.) [This does not include the "Using C-Kermit" book which Frank and Christine were able to update only once during this time frame. To accommodate all of the new documentation which has been written, an updated "Using C-Kermit" current with version 8.0 would need to be 1800 pages in length.] I tried to look back and summarize all of the features that were added to Kermit in the last eight years and I became overwhelmed. There were 35 plus terminals that were emulated; streaming Kermit protocol; the Internet Kermit Service; all of the IETF work (TELNET AUTH SRP, TELNET AUTH KRB5, TELNET START-TLS, TELNET FORWARD-X, PKIX, TLS, KERBEROS 5, SSH 2, FTP AUTH TLS; TN3270 extensions; DNS SRV); UTF8 terminal support; URL hotspots; mouse event programming; Windows Telephony; DECNET; TELNET; RLOGIN; KLOGIN; Remote COM-PORT-CONTROL; HTTP; FTP; all of the security implementations; Bidirectional Printer Management; the GUI release; export permission; and thousands of other things that I just can't summarize because (to be honest) I can't remember. I tried to use the Internet Wayback Machine http://web.archive.org/web/*/http://www.columbia.edu/kermit/k95.html but it's almost as if everything on the current k95.html page is new. One of the greatest aspects of my work on Kermit has been that the impact of my work has not been limited only to the Kermit product and its users. Through Kermit I have participated in the Internet Engineering Task Force on numerous working groups and have either authored or edited over two dozen Internet-Drafts and RFCs. In addition, I have been an active contributor to various OpenSource projects: OpenSSL; MIT Kerberos; Tom Wu's Secure Remote Password distribution; Peter Runestig's Secure Telnet and FTP clients and servers; Denis Sbragion's Sredird Telnet Com-Port-Control daemon; plus many others. I participated as an unofficial observer in the Commerce Department BIS advisory council meetings on export control. Plus I was able to work with purely commercial companies to help them ensure that their products were compliant with protocols implemented within Kermit. With all of this there is always more that I wish I could have accomplished. We never did implement TN3270/TN5250 within Kermit. Nor did we ever port the terminal emulator to MacOS or X-Windows. The BeOS port never truly worked and we don't support PalmOS or Windows CE/ PocketPC devices. The Internet Kermit Service never received wide enough support from OS vendors such as IBM, Sun, HP, Compaq, and RedHat. Support for security features on VMS is still not complete. We never got to develop a drag/drop file transfer interface for Kermit, Zmodem, and FTP. But overall I believe that Kermit 95 is a very good product that in many ways probably does too much. :-) Unfortunately, my time to work on Kermit as a Columbia University staff member has come to an end and it is time for me to move on to other endeavors, even if I am not quite sure what they will be. I still consider myself a member of the Kermit Project even if I am not paid to be. Kermit has been a part of my life for fifteen years. It was a lab for me when I was in college and then grad school. When I got my first job as a developer after receiving my Master's, I continued to work on C-Kermit eventually taking the reins of the OS/2 port from Kai Uwe Rommel. I left that job for Columbia because the 20 hours a week I was spending on Kermit was a lot more enjoyable than the work I did for my employer. I can't imagine how it would be possible for me to simply give it up now but my work on Kermit has caused me to grow far beyond what is possible within Kermit. Therefore, Kermit is going to have to become a smaller piece of my life. My participation in open source projects such as MIT Kerberos and OpenSSL will continue. My participation in the IETF will continue. Over the last year and a half I have become very interested in Peer to Peer overlay networks and purely distributed authentication systems. I have been active in the Project JXTA community (http://www.jxta.org) and currently sit on its Board. I have been actively pursuing the creation of an IETF P2P Working Group to standardize a suite of P2P protocols; and an IRTF P2P Research Group to study the effects of P2P overlay networks on an Internet containing 10^14 nodes (today's Internet has less than 10^9 nodes.) It is my hope that my next employeer will provide me the opportunity to continue this work. In the meantime, I will be available on a contract basis through Internet Access Methods (http://www.iamethods.com) / (http://www.iamx.com) for development or consulting work on Kermit; Peer to Peer systems; or various Security efforts. I can be reached either at jaltman AT columbia.edu or jaltman AT iamx.com. Last but not least I want to say thank you to Frank da Cruz, Max Evarts, Christine Gianone, everyone I've worked with at Columbia University; and all of the wonderful users that have supported Kermit over the years most notably: Peter Runestig, Mark Zinzow, Kent Martin, Arthur Marsh, Perry Wolfe, Robert Strickler, Greg Belenger, Clarence Dold, Thomas Dickey, Jim Schneider, Vincent Fatica, Gene Alexander, and everyone else whose name I can't pull off the top of my head. Without you Kermit would not be any fun at all. Jeffrey Altman Volunteer Kermit Developer -- Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/ Secured with MIT Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc References: Message-ID: Organization: Columbia University Date: 1 Dec 2002 14:25:47 -0500 From: Frank da Cruz Subject: Re: A Letter to the Kermit Community In article , Jeffrey Altman wrote: : : Today marks the end of a significant period in my life... : Looking back over the last eight years it is somewhat incredible to : think about what was achieved... Anyone who has been following the goings on here since 1995 knows Jeff's key role in most of it, if only by his over-the-top devotion to 24x7 end-user support: http://www.columbia.edu/kermit/tsreviews.html Jeff is an extremely talented and hard-working person; we were lucky to have him and are unlucky to lose him. Ironically, Jeff's main passion over the past 5 years or so--security--is precisely what should have sealed our success, yet the market did not respond. Kermit 95 was one of the first, if not THE first, full-featured Windows communication software packages to support Kerberos IV, Kerberos V, and SSL/TLS, as well as the lesser-known Secure Remote Password, each of which offers MANAGEABLE secure authentication and strong encryption. But it turned out that, despite the many earlier requests for it, nobody actually wanted *manageable* security (because it must, indeed, be managed), and instead flocked towards SSH, which in many ways is a disaster waiting to happen: http://www.columbia.edu/kermit/sshclient.html#x3.2 This was a setback for us, because instead of concentrating on GUI development, essential not only in the mass market but also to many of our potential large licensees, we had to drop everything and add SSH to K95, which took a year, just so people could keep using K95 in an environment where Telnet servers were being turned off (rather than secured) and SSH was suddenly required for terminal connections. We had expected that at least some of the larger corporations and government agencies would be more serious about security. Live and learn. : One of the greatest aspects of my work on Kermit has been that the : impact of my work has not been limited only to the Kermit product and : its users. Through Kermit I have participated in the Internet : Engineering Task Force on numerous working groups and have either : authored or edited over two dozen Internet-Drafts and RFCs.... Shamefully this kind of activity is no longer valued in most workplaces. Devotion to standards and participation in their evolution rarely contributes to the bottom line, and are increasingly discouraged if not punished in these hard times except in the few companies that can still afford it -- a trend which has consequences for us all. : ... But overall I believe that Kermit 95 is a : very good product that in many ways probably does too much. :-) A common theme in the evolution of any software product. It starts out small and focussed; users request more features; the market makes new demands (such as SSH); the product becomes increasingly complex and "bloated"; eventually users begin longing for the good old days when the product was "lean and mean". But of course they can't go back to the original release because it lacks certain essential features that were added later--a different set of them for each user! Perhaps our mistake has been to listen too closely to our users and try too hard to please. Other products tend to displace K95 by offering users very little in terms of features or choices, and therefore are perceived as easier for most people to use. Kermit's strength, however, lies in its ability to be adaptable to almost any setting; perhaps it is best suited to situations in which professionals can configure it for end users -- employees or clients of a company, the population of a university, workers in a government agency. This is done through its command scripting language, which allows complex or repetitive procedures (such as EDI transactions) to be "canned" for use by relatively unskilled workers. I would like to think the value of this approach will become apparent as we suffer increasingly through the labor-intensive, error-prone, point-and-click interfaces that are coming to dominate the workplace and drag down productivity. : I still consider myself a member of the Kermit Project even if I am : not paid to be. I can't predict how much time Jeff can devote to Kermit in the future. Even if it's only 10% of his normal contribution, that's about a full-time job for anybody else :-) But let's not take this as an epitaph for Kermit 95. We have just released version 2.1, which is totally up to date with all the latest Kerberos, OpenSSL, and other security libraries, and seems so far to be quite solid. It's easy to install and easier to use than ever. It's easier to get too. As long it remains popular I'm sure Jeff won't forget about it. In any case, we intend to continue to develop and support it, as we always have done. If that changes, I'll let you know. Kermit 95 2.1 has just now gone to press. The new shrinkwraps--which, for the first time, contain the secure cryptographic version of the software -- should be available towards the end of December. You can preorder them at the old price starting today: http://www.columbia.edu/kermit/k95order.html Thanks, Jeff. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc References: Message-ID: <8ce22d01.0212021110.77c49d5a@posting.google.com> Organization: http://groups.google.com/ Date: 2 Dec 2002 11:10:28 -0800 From: Dan Skinner Subject: Re: A Letter to the Kermit Community jaltman@watsun.cc.columbia.edu (Jeffrey Altman) wrote in message news:... > 1 December 2002: A day that will live in infamy! Jeff; a comment from a Kermit newbie.(First use August 1990). You and Frank and all have lived up to a support model that is as different from its competitors as C-Kermit and K95 are different from their competitors, and that is a GOOD THING :-) I've tried to model my little company's products and services on your good example, down to absurdly low prices. How can I help you make it work, rather than How can I avoid responsibility is a model and a style that will always be in fashion! THANK YOU!!! Good Luck and Good Computing. Best Regards^ÅDan. JDanSkinner.com -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc References: <8ce22d01.0212021110.77c49d5a@posting.google.com> Message-ID: Organization: Columbia University Date: 2 Dec 2002 14:58:26 -0500 From: Frank da Cruz Subject: Re: A Letter to the Kermit Community In article <8ce22d01.0212021110.77c49d5a@posting.google.com>, Dan Skinner wrote... : : I've tried to model my little company's products and services on your : good example, down to absurdly low prices. Good luck. It's nice to know that some people still believe in such notions, which are largely held to be "legacy, deprecated" concepts long ago replaced by the more up-to-date "take the money and run". The best way to keep the old ideas alive is to not be shy about spreading the word across our wonderful Internet. In Kermit's case, it's especially important since most people still believe that it hasn't changed since 1983. "Kermit, oh yeah, I remember that, I used in college... A nice little toy for its time... What ever happened to it?" We have a web page to refer people to when they say things like that: http://www.columbia.edu/kermit/kermit.html To this day, people cling to incredibly clunky, obscure, and unsafe methods of doing things (such as automating an FTP session) that would be perfectly straightforward with C-Kermit or K95. My favorite is when someone asks how to do something involving recursive directory traversal in Unix (deleting files, moving them, transferring them, whatever) -- something that can be done in one simple command in Kermit, like: delete /recursive /before:1-jan-2000 *.txt The conversation rapidly devolves into heated arguments over the syntax of "find" and "xargs" versus various Unix versions and shells, and then over the ensuing week or two into insults and death threats, before it finally veers off on some tangent, such as English versus metric units of volume, weight, or mass as applied to bottles of beer. We need independent Kermit users to pop up on the newsgroups when people ask "How do I do such-and-such?" and Kermit is the obvious and sensible answer. Jeff and I do this a lot, but people would pay more attention if they heard it from a variety of actual users who benefit from it in real life. Why should they trust us? Yes, if you post on newsgroups you get spam. I get tons of it. It's annoying, but that's all. There are many worse things in the world, starting with unemployment. "Up with Common Sense!" Our new slogan? It's an inversion of Gracie Allen's campaign slogan in the 1940 presidential race. (Where is she now when we need her?) http://www.geocities.com/Hollywood/Hills/1836/campaign1940.html - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!emory!gatech!udel!news.mathworks.com!news.alpha.net!uwm.edu !lll-winken.llnl.gov!sol.ctr.columbia.edu!news.columbia.edu !watsun.cc.columbia.edu!fdc Message-ID: <3at022$rfc@apakabar.cc.columbia.edu> References: Date: 22 Nov 1994 14:43:14 GMT Organization: Columbia University Lines: 26 From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Subject: Re: re-dial in kermit 3.12 In article , Vito Kwan wrote: > > I am using MS-DOS kermit on my PC and try to find out how to re-dial > a phone number at a certain time interval, like 5-seconds. > Could someone please give me some hints? > Read the chapter on script programming in the manual? Use any of the standard dialing scripts, which already do this? Once again, the manual is: Christine M. Gianone, "Using MS-DOS Kermit", Second Edition, Digital Press / Butterworth-Heinemann, Woburn, MA, 1992, 345 pages, ISBN 1-55558-082-3. Packaged with version 3.13 of MS-DOS Kermit for the IBM PC, PS/2, and compatibles on a 3.5-inch diskette. US single-copy price: $34.95; quantity discounts available. Available in computer bookstores or directly from: Kermit Development and Distribution Columbia University Academic Information Systems 612 West 115th Street New York, NY 10025 USA Telephone: +1 212 854-3703 - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.terminals,comp.sys.ibm.pc.misc Path: utkcs2!gatech!destroyer!caen!hellgate.utah.edu!cc.usu.edu!jrd Message-ID: <1992Oct9.142143.59575@cc.usu.edu> References: <1992Oct5.021247.22556@samba.oit.unc.edu> Organization: Utah State University Lines: 23 Date: 9 Oct 92 14:21:43 MDT From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: Inexpensive Tek 4014/DEC VT220 Emulator? In article , jt@fuw.edu.pl (Jerzy Tarasiuk) writes: >>>>>> On Mon, 5 Oct 1992 02:12:47 GMT, sdoublie@med.unc.edu (Sylvie Doublie) said: > (some lines deleted) > Sylvie> connect by modem to computers at her lab. She needs the > Sylvie> program to emulate both Tek 4014 and DEC VT220 terminals. She doesn't > Sylvie> have much money to spend, so she'd like to get a [free or cheap] > Sylvie> program, but an inexpensive commercial application will suffice. > > > KERMIT can emulate Tek 4010 and DEC VT100, VT220, VT320 (at least > version 3.11 which I use just now to write this message). > And it at least can be tried free, get it (e.g. by FTP) and read > docs to know if she need pay (for commercial use would need). ----------- All accurate except for the very last point. Kermit USE is always free. Financial arrangements come into play when a Columbia Kermit becomes part of another product package offered for sale. The Kermit Project is heavily dependent on such arrangments and on the sale of the user's books, plus donations. If corporations were to contribute a fraction of the cost otherwise spent on a commerical product, we could do much more, and faster too, and buyers would still enjoy the benefits of a commercial-grade product with Tech Support and a professionally done user's manual (Digital Press and Prentice Hall does the publishing). Joe Doupnik .............................................................................. [see below for discussions of Kermit support policy] ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.protocols.kermit.misc Message-ID: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> Organization: Dunwoody Georgia Date: Sun, 27 Jul 2003 02:04:29 -0400 From: Bill Subject: Word Perfect Keyboard (Frank) Clueless! Well I am still attempting to help a Medical Transcriber change her connection with Kermit to a UNIX server. I thought she had made it work but she wasn't that lucky and the System Person said the old version of ProComm was the only one that would work. Anyhow today I tried to log in and got to the terminal screen after typing in the set terminal keyboard-mode wp, and as you advised checked the terminal type on the terminal page and there is no vt320-w! There isn't even an option in the scroll box. I don't think the set command is working (or I am putting it in the wrong screen!). I have also looked through the .ini files and they seem to be similar enough to do the simple things she needs to do (file retrieval and the upload of her work). I refuse to believe that the ancient version of ProComm is the only thing that will work! I really thought that it was out of production but [Symantec] still sells a version. She and I both are working from a template and maybe there are more options working from scratch? Any additional thought? Thanks Bill Atlanta .............................................................................. Newsgroups: comp.protocols.kermit.misc Message-ID: References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> Organization: Columbia University Date: 26 Jul 2003 16:01:15 -0400 From: Frank da Cruz Subject: Re: Word Perfect Keyboard (Frank) In article <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com>, Bill wrote: : : [I] checked the terminal type on the terminal page and there is no : vt320-w! There isn't even an option in the scroll box. I don't think : the set command is working (or I am putting it in the wrong screen!). VT320-W would not appear in the scroll box; it's not a terminal type, it's a keyboard mode applied to a terminal type. : I refuse to believe that the ancient version of ProComm is the only : thing that will work! : Me too. Let's try again, step by step. Let's assume you have a connection to the host, and have started WordPerfect on the host. K95 is in its terminal screen (normally blue, but could be any color). On the bottom of the screen (inside the frame) is a green line with white writing, called the Status Line, that says: o o o o VT320 Help: Alt-H Command: Alt-X (etc etc). At this point do: . Alt-x (i.e. hold down the Alt key and press the X key) . At the K-95> prompt, type the following command: set terminal keyboard-mode wp . Alt-x again to get back to the terminal screen. Now the Status Line should say: o o o o VT320-W Help: Alt-H Command: Alt-X (etc etc). and the WordPerfect Key mappings should be in effect. To return to the regular VT320 key mapping, do: . Alt-x (i.e. hold down the Alt key and press the X key) . At the K-95> prompt, type the following command: set terminal keyboard-mode normal . Alt-x again to get back to the terminal screen. and the "VT320-W" in the status line should revert to "VT320". There *should* be an easier way to do this: Ctrl-Alt-Shift-W is supposed to toggle in and out of WordPerfect keyboard mode. But for some unknown reason this does not seem to work on all PCs. If these instructions do not cause "VT320-W" to appear in Kermit's status line, send e-mail to kermit-support@columbia.edu, and we'll do the detailed troubleshooting. By the way, when you first posted this question you said you had the "latest kermit", and I assumed by that you meant you had Kermit 95 2.1.3. If that's not the case and you are talking about (e.g.) MS-DOS Kermit, then please say so. - Frank .............................................................................. Newsgroups: comp.protocols.kermit.misc Message-ID: References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> Organization: a2i network Date: Sun, 27 Jul 2003 20:17:08 +0000 (UTC) From: dold@WordXPerfe.usenet.us.com Subject: Re: Word Perfect Keyboard (Frank) I wanted to wait for Frank to respond first, with a K95 entry that was more graceful than my setup. I made my own mapping for WordPerfect and MSDOS Kermit-3.11 to a UnixWare box. I was also faced with another Unix (ESIX) system that came with bundled software and a fixed terminal type of vt100-pro, with some mangling to fit the Procomm-of-the-day mapping. By capturing what procomm sent to the unix system for each F key, I was able to build my own map of what Kermit needed to send. I probably still have that lying around somewhere. I looked at the Wordperfect mapping that was on the kermit site at that time, and chose not to use it, although I don't recall why. -- Clarence .............................................................................. Newsgroups: comp.protocols.kermit.misc Message-ID: References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> Organization: Dunwoody Georgia Date: Mon, 28 Jul 2003 10:38:19 -0400 From: Bill Subject: Re: Word Perfect Keyboard (Frank) Thanks! This evening was a break-through. The keyboard-mode needs to be issued after the session is started and then the W is appended to the terminal type. I have forgotten whether she used vt220 or vt320. I used the vt220W and go to the help screens and that lets you see the UNIX template. I expect that the days of UNIX WP and ProComm are pretty fuzzy memories to most folks now - certainly to me. We never used UNIX based applications, except for CAD workstations and they and their dark room requirements didn't last so very long because along came AutoCad and we were all PCs. Thanks for the help. If you find the ProComm mappings/Kermit version I am willing to try. Bill Atlanta .............................................................................. Newsgroups: comp.protocols.kermit.misc Message-ID: References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> Organization: Columbia University Date: 28 Jul 2003 10:06:44 -0400 From: Frank da Cruz Subject: Re: Word Perfect Keyboard (Frank) In article , wrote: : : I wanted to wait for Frank to respond first, with a K95 entry that was more : graceful than my setup. K95's WordPerfect keyboard mode is built-in. You can see what the default mappings in the Default.Ksc file, which is in your Kermit 95 directory tree somewhere; there's also a copy here: ftp://kermit.columbia.edu/kermit/k95/default.ksc Search for "SET TERMINAL KEY wp" and then read the next 146 lines. Of course you can change the mapping any way you like. : I looked at the Wordperfect mapping that was on the kermit site at that : time, and chose not to use it, although I don't recall why. It should have been just the ticket since these mappings were provided by WordPerfect themselves. K95 used this map as a model for its WP keyboard mode. - Frank .............................................................................. Newsgroups: comp.protocols.kermit.misc Message-ID: <3a3hivophckesp3qko7bm90q1bobfgn8jk@4ax.com> References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> Organization: Dunwoody Georgia Date: Wed, 30 Jul 2003 23:37:41 -0400 From: Bill Subject: Re: Word Perfect Keyboard (Frank) I have used FinePrint to print out the whole manual, and found the WP section. If the old mapping file is found it may be worth posting at Kemit. I expect that the Transcribers will all hit this at some point(?). Especially when the old version of ProComm(s) flake out. Pretty sure it will not run in XP and I haven't tried it on my Win2K machine. Thanks Bill (BTW the existing WP emulation works well enough to make corrections to the server copy, and apparently they mostly work on WP locally and then up-load the files. Kermit up-loads fine as is......) .............................................................................. Newsgroups: comp.protocols.kermit.misc Message-ID: References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> <3a3hivophckesp3qko7bm90q1bobfgn8jk@4ax.com> Organization: Columbia University Date: 30 Jul 2003 12:08:18 -0400 From: Frank da Cruz Subject: Re: Word Perfect Keyboard (Frank) In article <3a3hivophckesp3qko7bm90q1bobfgn8jk@4ax.com>, Bill wrote: : I have used FinePrint to print out the whole manual, and found the WP : section. If the old mapping file is found it may be worth posting at : Kemit. I expect that the Transcribers will all hit this at some : point(?). Especially when the old version of ProComm(s) flake out. : Pretty sure it will not run in XP and I haven't tried it on my Win2K : machine. : Why don't you post what you think the mapping should be and then we can compare it with what Kermit uses, and then we'll know why you think there is a problem. Remember: Kermit's mapping is the one recommended by the WordPerfect company itself. Anyway, you still haven't confirmed that you have actually activated Kermit's WordPerfect keyboard mode. I explained several times how to to do this. - Frank ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.sys.ibm.pc,comp.sys.ibm.pc.misc Path: utkcs2!darwin.sura.net!news.udel.edu!ravel.udel.edu!sigurd Message-ID: Sender: usenet@news.udel.edu Nntp-Posting-Host: ravel.udel.edu Organization: University of Delaware References: <1992Oct5.021247.22556@samba.oit.unc.edu> <1992Oct6.092905.19557@news.uni-stuttgart.de> Date: Tue, 20 Oct 1992 20:56:10 GMT From: sigurd@ravel.udel.edu (Sigurd Andersen) Subject: Re: Inexpensive Tek 4014/DEC VT220 Emulator? In article <1992Oct6.092905.19557@news.uni-stuttgart.de> skok@itwds1.energietechnik.uni-stuttgart.de (Holger Skok) writes: : Kermit emulates vt100 and Tek4014 and it's free (as far as I know). : I haven't found out though, how to store the Tek4014 image and convert : it to HPGL like it is possible with some commercial terminal emulators. : ... [ Others also sent various related messages which I will NOT summarize ] [as of 20 Oct 1992] The latest version of MS-Kermit (for MS-DOS-based personal computers) is 3.12. That's the version now distributed by Columbia University. Version 3.12 adds the ability to establish network connections using ODI drivers in addition to the connections using packet drivers that were possible with version 3.11. MS-Kermit and versions for other computer systems are fully copyable. The following quote is from the book, "Using MS-DOS Kermit," Second Edition: "Kermit programs can be freely reproduced and shared as long as this is not done for profit. No licensing or registration is required. However, Kermit programs are not in the public domain. In general, each Kermit program includes a copyright notice to protect its special status. ..." (page xxii) With version 3.11 or 3.12 (and possibly earlier versions), one can capture Tektronix graphics screens as "Aldus/Microsoft TIFF (Tagged Image File Format) 5.0 ... suitable for importation into applications such as WordPerfect 5.0, Aldus Pagemaker, Ventura Publisher, PC Paint, and others that support TIFF 5.0." (ibid., p. 85) Screen capture is initiated with the key combination Control-End. The graphics commands from a host that create the screen images can also be captured (using the LOG SESSION command) and played back using the REPLAY command. A reference for the book: "Using MS-DOS Kermit Connecting your PC to the Electronic World" Second Edition, by Christine M. Gianone. From Digital Press (ISBN 1-55558-082-3) or Prentice-Hall (0-13-952276-X). -- Sigurd Andersen Internet: sigurd@chopin.udel.edu CNS User Services __o or Sigurd.Andersen@MVS.udel.edu 115-B Newark Hall _ \<,_ Bitnet: ACS20833@UDELVM Univ. of Delaware (_)/ (_) Ph: (302) 831-1992 Fax: 831-4335 Newark, DE. 19716 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.os.vms Path: utkcs2!darwin.sura.net!paladin.american.edu!news.univie.ac.at!hp4at !mcsun!uknet!strath-cs!str-ccsun!dct.ac.uk!ccdarg Message-ID: <1992Oct20.154534.710@dct.ac.uk> Date: 20 Oct 92 14:45:34 GMT References: <1992Oct19.160704.1@uwovax.uwo.ca> <1992Oct19.215917.5808@ais.com> Organization: Dundee Institute of Technology From: ccdarg@dct.ac.uk (Alan Greig) Subject: Re: Shipping obj files using Kermit? In article <1992Oct19.215917.5808@ais.com>, bruce@ais.com (Bruce C. Wright) writes: > > In article <1992Oct19.160704.1@uwovax.uwo.ca>, > brent@uwovax.uwo.ca (Brent Sterner) writes: >> >> I have a user who wants to transfer .obj files to another site using >> Kermit. The files arrive, bit are not usable. The file organization >> seems to end up being munged, whether he uses binary mode or not. > > Yes, rather annoying how VMS .OBJ files and Kermit don't agree with one > another very well. :-( > C kermit 5A for VMS can transfer *any* VMS file preserving RMS attributes. It can even transfer to a PC (say) and then correctly restore the file on the way back. The moment it passes the beta stage (which is expected any day now...) I'll post out a copy of the announcement here. In the meantime you can probably get hold of it as follows. HOW TO GET THIS EDIT The new edit is available (on the Internet only) via anonymous ftp from host watsun.cc.columbia.edu [128.59.39.2], using text (ASCII) mode in the directory kermit/sw/. General C-Kermit documentation: ckaaaa.hlp Explanation of file naming conventions ckcplm.doc C-Kermit "program logic manual" ckccfg.doc C-Kermit configuration info ckcker.ann Info-Kermit Digest announcement of version 5A(179) ckcker.bwr General C-Kermit beware file ckcker.upd C-Kermit program update history since edit 179, plain text ckc178.upd C-Kermit 5A update history through edit 178, HUGE ckuker.doc plain-text user manual (still 179) ckuker.ps Postscript user manual (ditto) ckuker.mss Scribe source for user manual + ckuhdr.mss (ditto) VMS sources: ck[cuwv]*.[cwh], plus ckvcvt.c (labeled-file decoder) VMS build: ckvcdt.com plus ckvker.com (DCL), ckvker.mak (VMS MAKE), or ckvker.mms (MMS). Instructions: ckvins.doc. VMS executable: ckvker.hex, use ckvdeh.mar to decode it into .EXE format. NOTE: this executable does not include TCP/IP support. VMS docs: ckvker.hlp, ckvins.doc, ckvker.bwr VMS diffs: ckv184.dif (88K), use with cku184.dif. -- Alan Greig Janet: Alan@UK.AC.DUNDEE-TECH Dundee Institute of Technology Internet: Alan@DCT.AC.UK Tel: (0382) 308810 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 53502 of comp.os.vms: Path: utkcs2!gatech!rutgers!spcvxb!terry From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) Newsgroups: comp.os.vms Subject: Re: Shipping obj files using Kermit? Message-ID: <1992Oct20.232253.4168@spcvxb.spc.edu> Date: 21 Oct 92 03:22:53 GMT References: <1992Oct19.160704.1@uwovax.uwo.ca> <1992Oct19.215917.5808@ais.com> Organization: St. Peter's College, US Lines: 23 In article <1992Oct19.215917.5808@ais.com>, bruce@ais.com (Bruce C. Wright) writes: > Yes, rather annoying how VMS .OBJ files and Kermit don't agree with one > another very well. :-( Fixed in a forthcoming major release. C-Kermit 5A, now in beta test, adds a new file transfer type called "LABELED". Labeled transfers correctly pre- serve all the file attributes you'd ever want. You can transfer any VMS file structure between systems with this feature. I've moved RMS indexed files, .OBJ's, etc. You can even pass these files through an intermediate system which knows nothing about VMS files. I've moved VAX Notes conference files from one VAX to my PC and then back to another VAX and had them work fine. The current test version of C-Kermit is available from watsun.cc.columbia.edu in directory kermit/sw. At the present time I believe only sources are avail- able; you'll need the VAX C compiler (or DEC C for an Alpha AXP) to compile it. When the test period is over, a formal announcement will likely be made here. Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA terry@spcvxa.spc.edu +1 201 915 9381 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 676 of comp.terminals: Newsgroups: comp.dcom.lans.ethernet,comp.terminals Path: cs.utk.edu!gatech!howland.reston.ans.net!ux1.cso.uiuc.edu!uchinews!cs.umd.edu!afterlife!grday From: grday@afterlife.ncsc.mil (Gary Day) Subject: MSDOS Kermit and TCP/IP Message-ID: <1993May14.021506.3974@afterlife.ncsc.mil> Organization: The Great Beyond Distribution: usa Date: Fri, 14 May 1993 02:15:06 GMT Lines: 83 Xref: cs.utk.edu comp.dcom.lans.ethernet:4760 comp.terminals:676 On April 16, 1993 I posted the following: >I have an IBM AT running MSDOS 5.0 with a 3COM 3C505 LAN adapter. >Can someone please tell me what I need (i.e., packet driver or whatever, >and where I might obtain such) in order to use MSKERMIT 3.11 Several people asked me to post what I found out, so here it is. First, MSDOS Kermit may be used to communicate via TCP/IP lans in one of two ways. MSDOS Kermit provides direct support for TCP/IP lans via a set of SET TCP/IP commands. In order to use MSDOS Kermit in this mode, you need a packet driver. PCTCP-PLUS from FTP Software Inc. comes with a complete collection of packet drivers. These same drivers may be obtained from: Host: sifon.cc.mcgill.ca Location: /pub/ftp_inc/dos/pdrivers MSDOS kermit 3.11 is also available from this same location. You may need to refer to the documentation with your specific adapter to get the correct values to use when installing the appropriate packet driver. Specifically, you will need to supply a software interrupt number, the hardware interrupt number used by the adapter, the I/O address, and the memory base address. For example, I have a 3C505 card, so I use the command: 3c505 0x60 5 0x300 0xcc00 By the way, PCTCP-PLUS comes with a device driver called 3C505.COM which should not be confused with the packet driver by the same name. With the packet driver installed, you can invoke Kermit and give the appropriate SET TCP/IP commands, for example: SET TCP/IP ADDRESS 139.75.25.126 SET TCP/IP SUBNETMASK 255.255.255.0 SET TCP/IP GATEWAY 192.75.55.9 SET TCP/IP DOMAIN NCSC.MIL SET TCP/IP PRIMARY-NAMESERVER AFTERLIFE SET TCP/IP PRIMARY-NAMESERVER VALHALA SET PORT TCP/IP PARADISE You may need to get the help from your LAN manager to get the proper values to be supplied for the addresses and for the name servers. The second, and easier way to use Kermit on a TCP/IP LAN, is to use the TNGLASS "-e" option, which informs TNGLASS (from PCTCP) that an alternate terminal emulator is being used. This causes TNGLASS to make a TELNET connection, and then invoke the named terminal emulator, with which it will communicate via DOS interrupt 14. For example: tnglass paradise -e kermit In this case, you will need to inform kermit that it is to communicate via interrupt 14, by issuing the command: SET PORT BIOS1 All of this information and much more is given in the book: "Using MSDOS Kermit" by Cristine Gianone and this is a book that I highly recommend for serious MSDOS Kermit users. It also comes with MSDOS Kermit 3.11 on a 5 and 1/4 in. floppy. I am a blind programmer and use a screen reader driver, together with a speech synthesizer to produce speech from the displayed text. The MSDOS Kermit vt100 emulation is done through MSDOS I/O interrupt calls and thus works well with my screen reader. (Some earlier documentation indicates that Kermit performs terminal emulation via direct video memory access, but this appears not to be the case, at least for vt100 emulation). However, I have found that if I install a packet driver and try to make a direct TCP/IP connection with Kermit, my system will hang as soom as my screen reader is enabled. I haven't a clue why this should be. But the second method of using tnglass and interrupt 14 works fine. Gary R. Day: grday@afterlife.ncsc.mil Thanks to Wayne Hann, of the Cabot College of Applied Arts, WAYNE@FAC.CABOT.NF.CA for pointing me in the right direction. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.os.vms Path: cs.utk.edu!gatech!concert!rutgers!spcvxb!terry Message-ID: <1993May9.171512.5872@spcvxb.spc.edu> Date: 9 May 93 21:15:12 GMT References: <01GXWVNSRHQ89BVI9R@JCSVAX1.BITNET> Organization: St. Peter's College, US From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) Subject: Re: Kermit is toooooooo slow !! In article <01GXWVNSRHQ89BVI9R@JCSVAX1.BITNET>, HANY%JCSVAX1.BITNET@pucc.Princeton.EDU (Axioms can be viewed as a form of exact theology) writes: > > Our school runs VMS Kermit-32 version 3.3.111 on a VAX/VMS V5.4-2. > I find it pretty slow to transfer files using this protocol, specially > that our highest connection is at 2400 bauds. Still, at 2400, I get almost > triple Kermit's speed using ZMODEM when connecting to my local BBS. There's a number of reasons for this. First, your 2400 baud connection to JCS is either through the DCA front-end, or through the NJ Bell LANgate packet- switched network. Both of these introduce substantial delays when used for file transfer. A protocol which utilizes multiple-packet windows will perform better on this type of link. C-Kermit does this; I don't know about Zmodem. Second, Zmodem expects to be able to pass most control characters through the line. While I am told that it is careful to avoid using "troublesome" characters like ^S/^Q, I believe it will use ^V (or is it ^N?), which is the "attention charac- ter" for your DCA front-end. Kermit quotes all control characters in user files. > My question is: Is there any shareware/freeware software that is faster than > this version of Kermit ? I think that it won't be hard to convince our sys > mngr to switch if such a thing exists. It is equally important also to know > where can I get it. An FTP site will be the most convenient, but I am also > willing to call long distance if it is worth it. C-Kermit is substantially faster than Bliss Kermit-32 as long as both ends are capable of using long packets and sliding windows. Many other Kermits, in- cluding MS-DOS Kermit, support these features. C-Kermit is available by anonymous FTP from watsun.cc.columbia.edu. In your case, you'd want (as a minimum) kermit/v/ckvker.hex and ckvdeh.mar. As you probably know, I provide support for some of the more esoteric pieces of software on the JCS cluster. I'd be glad to install C-K there if system man- agement requests it. Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA terry@spcvxa.spc.edu +1 201 915 9381 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!nntp.memst.edu!ukma!eng.ufl.edu!spool.mu.edu !howland.reston.ans.net!darwin.sura.net!udel!news.intercon.com !psinntp!news.columbia.edu!usenet Message-ID: <1993May16.144933.16900@news.columbia.edu> Date: Sun, 16 May 1993 14:49:33 GMT References: Organization: Columbia University From: fdc@fdc.cc.columbia.edu (Frank da Cruz) Subject: Re: zmodem for kermit In article haymoree@quack.kfu.com (Ed Haymore) writes: > > How do I get a decent throughput with Kermit on a 14.4k modem? I can't > get anything more than about 350 cps -- with zmodem I get 1600+ cps on > the same setup. (compressed file, by the way) > > Even at 2400 baud, kermit's speed is about 50% of zmodem's. If the > quoting doesn't significantly increase the amount of data to transfer, > what makes kermit so slow? First, let's make sure you are using real and up-to-date Kermit software, and not the minimalistic and half-hearted Kermit implementations that you find in most commercial and shareware communication software. For DOS and Windows, use MS-DOS Kermit 3.12 (soon to be 3.13); for UNIX use C-Kermit 5A(188) (soon to be 189) (watch comp.protocols.kermit for announcements). Then make sure an effective method of flow control, preferably RTS/CTS, is enabled at each interface along the communication path. For example, tell MS-DOS Kermit to SET FLOW RTS/CTS, and give the corresponding settings to your modem. Set your interface speed higher than the modem's modulation speed. For example, using 14400 bps modulation, set your interface to 57600 bps if possible, or 38400 or 19200 otherwise. (This doesn't actually matter too much when transferring precompressed files, but it does matter for most other types of files, and is a good rule to follow in general when using modems that do data compression.) Tell both Kermit programs to SET WINDOW , where is a number somewhere between 2 and 20 -- the optimum value depends on the connection, the characteristics of the modem and the data. Tell both Kermit programs to SET RECEIVE PACKET-LENGTH 1000. Also, when sending binary files (like ZIP files) don't forget to tell the file sender to SET FILE TYPE BINARY (it will tell the receiver automatically). Using these settings, you should get about 1300 cps for ZIP or other precompressed files, and much higher rates for other types of files. MS-DOS Kermit 3.13 and C-Kermit 5A(189) will include a new feature that lets you boost throughput of ZIP and other precompressed files by about 20%, ON PERFECTLY CLEAN 8-BIT TRANSPARENT CONNECTIONS, bringing Kermit's performance in this situation to the same level as Zmodem's (as pointed out earlier, Kermit already outperforms Zmodem in most other situations: text files, most uncompressed binary files, noisy connections, connections with delays, 7-bit connections, etc). To get Kermit software, use anonymous ftp to watsun.cc.columbia.edu [128.59.39.2], directory kermit, get the file READ.ME, read it, take it from there. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.tcp-ip,comp.terminals Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!uunet!cs.utexas.edu!utah-morgan !hellgate.utah.edu!cc.usu.edu!jrd Message-ID: <1993Aug16.215757.71292@cc.usu.edu> References: <24n6pq$pr8@toffu.icl.fi> Organization: Utah State University Date: 16 Aug 93 21:57:57 MDT From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: Where to get VT-100 source code in public domain? In article <24n6pq$pr8@toffu.icl.fi>, jel@xerver.icl.fi (Jerry Lahti) writes: > westes@netcom.com (Will Estes) writes: > >>I need to write a simple VT-100 emulator as part of a commercial >>product. Where does one find the specifications for VT-100, and is >>there any code in the public domain for this emulation that can be >>used as either a reference or actually copied into a commercial >>product? > > Presumably Digital will sell you the appropriate reference manuals. > > MS-Kermit sources might serve as a reference, although the display > emulation is unfortunately :-) already at the VT-320 level. However, > I have not looked closely enough at the copyrights to know, if the > code could be directly incorporated into a commercial product. > > /Jerry Lahti > > -- > Jerry Lahti ! tel. +358-0-567 3639 > ICL Personal Systems Oy ! fax. +358-0-567 5670 > P.O.Box 780 ! Email: jel@xerver.icl.fi (Internet) > 00101 Helsinki, Finland ! X400: C=FI A=MAILNET P=ICL O=ICL S=LAHTI G=JERRY ------------------ Here's the copyright notice from MS-DOS Kermit: ; Copyright (C) 1985, 1993, Trustees of Columbia University in the ; City of New York. Permission is granted to any individual or institution ; to use this software as long as it is not sold for profit. This copyright ; notice must be retained. This software may not be included in commercial ; products without written permission of Columbia University. So no, one can't use the material for commercial products. The ref for DEC VT100's is from Digital themselves (that's by far the best ref too). Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!darwin.sura.net!howland.reston.ans.net!agate!dog.ee.lbl.gov !hellgate.utah.edu!cc.usu.edu!jrd Message-ID: <1993Oct31.194051.2931@cc.usu.edu> Date: 31 Oct 93 19:40:51 MDT References: <2aehhv$kbg@vixen.cso.uiuc.edu> <752109594snz@genesis.demon.co.uk> <2aejmc$77v@apakabar.cc.columbia.edu> <1993Oct28.204050.9223@omen.UUCP> Organization: Utah State University From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: Problems with com4 and Kermit In article <752109594snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk (Lawrence Kirby) writes: > > In article <1993Oct28.204050.9223@omen.UUCP> caf@omen.UUCP writes: > >>What's unreal about the Kermit in Telix, Procomm, et al? Do they violate the >>published Kermit spec? > > Many do. I've noted that in the past some implementations won't accept valid > negotiation packets even though published specs show how to deal with them, > even when the packets contain fields for the more advanced functions. > > ----------------------------------------- > Lawrence Kirby | fred@genesis.demon.co.uk > Wilts, England | 70734.126@compuserve.com > ----------------------------------------- To quote a section from the "Kermit News", Number 5, July 1993, which has a big article on the subject of performance. (start quote, with some abbreviations) Table 1 illustrates the performance of the Kermit protocol implementations found in different PC software packages. These measurements were made on a direct 19200-bps serial connection, downloading a typical ASCII text file (the VM/CMS Kermit-370 manual), 135087 bytes in length, from a Sun SPARCserver-10 with C-Kermit 5A(189) to the hard disk of an IBM PS/2 Model 70. Table 1 Kermit Implementations Compared Window Packet Time Speed PC Software Size Length sec (cps) Effic Remarks ----------- ------ ------ ---- ----- ---- --------------------------- Telix 1 94 131 1052 55% No Long Pkt, no Slide Window METZ 1 94 119 1158 60% No LP, no SW Smartcom III 1 94 113 1220 64% No LP, no SW PROCOMM PLUS 14 1000 77 1790 93% Window size is not selectable Zstem 340 2 1000 74 1863 97% Max window size is 2 MS-DOS Kermit 3 1000 72 1915 99% Full control-char prefixing MS-DOS Kermit 3 1000 69 1999 104% Only 0, 1 and 129 prefixed ------ MS-DOS Kermit v3.13 METZ v1.16 PROCOMM PLUS v2.0 Smartcom III v1.0A Telix v3.21 Zstem 340 v1.0.4 (end quote) Please contact Christine Gianone, cmg@columbia.edu, to request a copy. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!uunet!nntp.club.cc.cmu.edu !honeydew.srv.cs.cmu.edu!GS137.SP.CS.CMU.EDU!pwp Message-ID: Originator: pwp@GS137.SP.CS.CMU.EDU Organization: School of Computer Science, Carnegie Mellon X-Newsreader: NN version 6.5.0 #13 (NOV) References: <1993Oct31.194051.2931@cc.usu.edu><1993Nov01.112834.8307@omen.UUCP> <752171522snz@genesis.demon.co.uk> <1993Nov02.112928.17189@omen.UUCP> Date: Wed, 3 Nov 1993 04:57:15 GMT From: Paul Placeway Subject: Re: Problems with com4 and Kermit caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > >So where can the current Real Kermit(Tm) protocol specs be FTP'd from?? >It appears that one must use code from the latest Columbia Kermit sources, >and those are protected by a restrictive Copyright. Watsun.cc.columbia.edu. You know this already, and so does most of the rest of the planet. >>Most ZMODEM implementations do go as fast as the freely available specs >>permit. >Likewise for Kermit, and likely to stay that way. Yup. Unix Kermit 5a and MS Kermit 3, for instance. The current spec is the natural union of the latest protocol document and the final versions of the un-quoting additions from the Kermit mailing list, ALL of which are available for anonymous FTP right now (yes, I just checked). The spec MUST be right, because there are hundreds of Kermit implementations, often in different languages, which all actually work together. The only way to do this is to have a clear, complete, and available spec, and to implement to it. I know personally that the sliding windows spec is correct. I wrote a ground-up new implementation in 1988 (yes, 5 years ago). When I had it working to the spec correctly, it worked correctly against the existing code the first time I tried it. And the latest, fastest, Kermit is *still* backwards compatible to version 1. Zmodem cannot make the same claim, though for reasons of greed rather than any good technical reason. Now if the spec for the latest version of zmodem were available, and Omen just happened to make the best quality implementation, you shouldn't have any problem with compensation for your efforts, and users of machines too weird for Omen to support (eg. Macs, Amigas, hand-held calculators) would benefit from other high performance implementations. (And like Microsoft, if a small market becomes a big one, you have an easy chance to step in and sell even more.) On the other hand, if you want to run a closed spec, well, I can only suggest you ask IBM and DEC how they feel about the current popularity of Sun, or perhaps consider the current popularity of ARC vs. ZIP. The Market reacts to a good value. The inverse is also true... >Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf -- Paul Placeway -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 47123 of comp.dcom.modems: Newsgroups: comp.dcom.modems Path: cs.utk.edu!avdms8.msfc.nasa.gov!europa.eng.gtefsd.com!uunet!omen!caf From: caf@omen.UUCP (Chuck Forsberg WA7KGX) Subject: Re: Problems with com4 and Kermit Organization: Omen Technology INC, Portland Rain Forest Date: Fri, 05 Nov 1993 00:12:25 GMT Message-ID: <1993Nov05.001225.8163@omen.UUCP> References: <752171522snz@genesis.demon.co.uk> <1993Nov02.112928.17189@omen.UUCP> Lines: 92 In article Paul Placeway writes: >caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > >>So where can the current Real Kermit(Tm) protocol specs be FTP'd from?? >>It appears that one must use code from the latest Columbia Kermit sources, >>and those are protected by a restrictive Copyright. > >Watsun.cc.columbia.edu. You know this already, and so does most of >the rest of the planet. > >>>Most ZMODEM implementations do go as fast as the freely available specs >>>permit. > >>Likewise for Kermit, and likely to stay that way. > >Yup. Unix Kermit 5a and MS Kermit 3, for instance. The current spec >is the natural union of the latest protocol document and the final >versions of the un-quoting additions from the Kermit mailing list, ALL >of which are available for anonymous FTP right now (yes, I just >checked). The spec MUST be right, because there are hundreds of >Kermit implementations, often in different languages, which all >actually work together. The only way to do this is to have a clear, >complete, and available spec, and to implement to it. Um, last time I checked, Unix Kermit and MS Kermit are covered by restrictive copyrights. My "likely to stay that way" comment refers to Kermit support in "the popular implementations" of Kermit in ProComm, Crosstalk et al. I don't think DCA or Datastorm are any more likely to violate Columbia's copyright than they are likely to violate the copyright in rz/sz. The fact that someone was able to cobble together a program that works in one or two benign environments does not mean the spec is through or accurate. >I know personally that the sliding windows spec is correct. I wrote a >ground-up new implementation in 1988 (yes, 5 years ago). When I had >it working to the spec correctly, it worked correctly against the >existing code the first time I tried it. I'm not sure Frank completely agrees with you: . Sliding Windows. Of course, I know the history too. I worked closely with The Source throughout the development of sliding windows, but the implementations that they commissioned were rush jobs that left a lot to be desired. They were nowhere near "efficient and robust under stress". They were buggy as all get-out, hideous to contemplate internally, and broke more often than they worked. This was the code that was incorporated into shareware Procomm, by the way, and who knows where else. Eventually, we wrote our own sliding windows implementations completely from scratch. Compare them yourself for robustness and efficiency with The Source version. Of course, the good implementation is Copyrighted. >And the latest, fastest, Kermit is *still* backwards compatible to >version 1. Yup. It took me an hour to get C-Kermit 189 on SCO to send a binary file to C-Kermit 189 on a BSDI machine starting with the settings given in the Kermit News article. (The Kermits were using different dialects, then Ctrl-C had to be escaped.) Kermit lusers often encounter this dialect problem. So don't lecture me on compatibility. >Zmodem cannot make the same claim, though for reasons of greed rather >than any good technical reason. Now if the spec for the latest Oh yes ZMODEM can. Every case of incompatibility that I have been able to investigate has been caused by the implementor breaking the spec or the PD source code in one or more ways. As for greed, I might point out that I have licensed ZMODEM-90(Tm) under much more favorable conditions than Frank da Cruz has offered to license me the current Kermit technology. Thye July Kermit News obfuscates this issue by claiming Kermit software was never public domain. In fact, until recently developers were free to incorporate the Kermit source code into their programs. Apparently the financial situation at Columbia U has changed. >version of zmodem were available, and Omen just happened to make the >best quality implementation, you shouldn't have any problem with Yes, we do make the best implementation, which is why Frank da Cruz was careful not to use it for his so-called "True-Life Benchmarks" in his hit piece on ZMODEM. -- Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ Omen Technology Inc "The High Reliability Software" 17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 49457 of comp.dcom.modems: Newsgroups: comp.dcom.modems,comp.unix.questions Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!uunet!news.crd.ge.com!sixhub!davidsen From: davidsen@sixhub.tmr.com (Bill Davidsen) Subject: Re: DSZ for unix Reply-To: davidsen@tmr.com (bill davidsen) Organization: TMR Associates, Schenectady NY Date: Wed, 8 Dec 1993 03:30:02 GMT Message-ID: References: <1993Dec1.143941.252999@ucl.ac.uk> Lines: 30 Xref: cs.utk.edu comp.dcom.modems:49457 comp.unix.questions:57484 In article wjones@tc.fluke.COM (Warren Jones) writes: | If you have kermit version 5A, you can teach it to use sz/rz as | external protocols. Put something like this in $HOME/.kermrc: | | --------------------------- cut here ---------------------------------------- | # Generic external protocol | # | def extern ! exec /usr/local/bin/\%1 \%2 <\v(line) >\v(line),- | echo,- | connect Only on some implementation of UNIX. On some the serial port is owned by uucp (or bin, root, or ???) and the comm progs must run setuid. And in sysV you can't setuid to euid unless you are root or have V.4. Therefore you (as your login id) can't open the serial port with redirection, and the trick doesn't work. The solution is to add code to Kermit to run the prog using the port as stdin and stdout, and I did it, and am sending the code to Frank to incorporate. I really needed it, although Kermit is much faster than Zmodem on some lines, since zmodem seems to get a long way past an error before starting the retry (or something). The line is a modem pool connected via enet to the system called, and with the net and protocol and modems playing packets the zmodem performance is slower. -- Bill Davidsen, davidsen@tmr.com | C programming, PC based UNIX, data TMR Associates, +1 518-370-5654 | acquisition, device drivers. _____________________________________|______________________________________ cat - 'kat, a purr bearing mammal -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!emory!europa.eng.gtefsd.com!library.ucla.edu!agate !headwall.Stanford.EDU!Csli!paulf Message-ID: <1994Jan21.200109.12743@Csli.Stanford.EDU> Organization: The Three Packeteers References: <2hlpdn$e3m@golem.wcc.govt.nz> <1994Jan20.193454.25924@omen.UUCP> <1994Jan20.213158.29111@Csli.Stanford.EDU> <1994Jan21.181856.2768@omen.UUCP> Date: Fri, 21 Jan 1994 20:01:09 GMT From: paulf@Csli.Stanford.EDU (Paul Flaherty) Subject: Re: Protocol Shootout Results caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > >Paul, could you be so kind as to provide the pathnames for these files? >I don't see any of the three Kermit books in Columbia University's public FTP >area. All I found was a copy of an antique Kermit spec. Please provide >pathnames for: > 1. current Kermit protocol spec ~ftp/kermit/e/kproto.ps > 2. Using C-Kermit ~ftp/kermit/b/ckuker.ps > 3. Using MS-DOS Kermit ~ftp/kermit/a/mskerm.ps Those files, plus the most current .bwr text files, AND SOURCE CODE, make up an outstanding documentation example. -- -=Paul Flaherty, N9FZX | "Fighter pilots make movies. Bomber pilots make ->paulf@Stanford.EDU | history." -- Jake Grafton -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!emory!europa.eng.gtefsd.com!uunet!omen!caf From: caf@omen.UUCP (Chuck Forsberg WA7KGX) Subject: Re: Protocol Shootout Results Organization: Omen Technology INC, Portland Rain Forest Date: Sat, 22 Jan 1994 13:04:28 GMT Message-ID: <1994Jan22.130428.10097@omen.UUCP> References: <1994Jan20.213158.29111@Csli.Stanford.EDU> <1994Jan21.200109.12743@Csli.Stanford.EDU> <1994Jan21.181856.2768@omen.UUCP> In article <1994Jan21.200109.12743@Csli.Stanford.EDU>, paulf@Csli.Stanford.EDU (Paul Flaherty) writes: > >caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > >>Paul, could you be so kind as to provide the pathnames for these files? >>I don't see any of the three Kermit books in Columbia University's public FTP >>area. All I found was a copy of an antique Kermit spec. Please provide >>pathnames for: >> 1. current Kermit protocol spec > >~ftp/kermit/e/kproto.ps No, that's the 1986 spec. It doesn't describe "Real Kermit" according to Columbia University. >Those files, plus the most current .bwr text files, AND SOURCE CODE, make up >an outstanding documentation example. Paul must think "Kermit" means "free". This is no longer true. Copyright (C) 1985, 1993, Trustees of Columbia University in the City of New York. The C-Kermit software may not be, in whole or in part, licensed or sold for profit as a software product itself, nor may it be included in or distributed with commercial products or otherwise distributed by commercial concerns to their clients or customers without written permission of the Office of Kermit Development and Distribution, Columbia University. This copyright notice must not be removed, altered, or obscured. -- Chuck Forsberg WA7KGX caf@omen.COM 503-621-3406 Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ Omen Technology Inc "The High Reliability Software" TeleGodzilla BBS:621-3746 FAX:621-3735 CIS:70007,2304 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!agate !headwall.Stanford.EDU!Csli!paulf Message-ID: <1994Jan22.184854.18205@Csli.Stanford.EDU> Organization: The Three Packeteers References: <1994Jan20.213158.29111@Csli.Stanford.EDU> <1994Jan22.130428.10097@omen.UUCP> <1994Jan21.181856.2768@omen.UUCP> <1994Jan21.200109.12743@Csli.Stanford.EDU> Date: Sat, 22 Jan 1994 18:48:54 GMT From: paulf@Csli.Stanford.EDU (Paul Flaherty) Subject: Re: Protocol Shootout Results (Really: Kermit Legal Status) caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > >No, that's the 1986 spec. >It doesn't describe "Real Kermit" according to Columbia University. Well, that's the current protocol spec. If by "Real Kermit" you include stuff like the command interface, that can be had from reading the source code. The status of the protocol spec is listed in the forward: #begin kermit.columbia.edu:~ftp/kermit/e/kproto.doc# PREFACE TO THE SIXTH EDITION The sixth edition (June 1986) of the Kermit Protocol Manual is being issued for two major reasons: to correct minor errors in the fifth edition, and to include new sections on two major protocol extensions: long packets and sliding win- dows. No attempt has been made to reorganize, rewrite, or otherwise improve the protocol manual. The Kermit protocol has been presented in an entirely different -- hopefully more thorough, organized, coherent, and useful (if not more formal) -- manner in the book, "Kermit, A File Transfer Protocol," by Frank da Cruz, Digital Press, Bedford MA (1987), ISBN 0-932376-88-6, DEC order number EY-6705E-DP. If you have the book, you won't need this protocol manual. On the other hand, if you don't have the book, this manual should still contain all the necessary information. The Kermit Protocol Manual will continue to be freely distributed in perpetuity. #end kermit.columbia.edu:~ftp/kermit/e/kproto.doc# >Paul must think "Kermit" means "free". This is no longer true. You're confusing "free" with "public domain". There are all sorts of copyright arrangements in which the author maintains the copyright, but the product remains economically free. The purposes behind keeping the copyright include but are not limited to: preventing other people from exploiting your work for financial gain, preventing others from introducing bugs into software with your name on it, granting special conditions to certain user communities, etc. > Copyright (C) 1985, 1993, Trustees of Columbia University in the City of New > York. The C-Kermit software may not be, in whole or in part, licensed or > sold for profit as a software product itself, nor may it be included in or > distributed with commercial products or otherwise distributed by commercial > concerns to their clients or customers without written permission of the > Office of Kermit Development and Distribution, Columbia University. This > copyright notice must not be removed, altered, or obscured. Nothing in this notice is inconsistent with economically free availability. Now, before you bring up your previous argument with respect to Kermit News Volume 5, let me do it for you: #begin kermit.columbia.edu:~ftp/kermit/e/newsn5.txt# It's KermitWare! While Kermit software is not a commercial product, it is not in the public domain either, and never has been. It is not "shareware." It's not "freeware." It is copyright by Columbia University. See page -TERMS for our terms and conditions. #end kermit.columbia.edu ~ftp/kermit/e/newsn5.txt# This is meaningless unless you also quote the TERMS page: #begin kermit.columbia.edu:~ftp/kermit/e/aaxfly.doc# TERMS AND CONDITIONS The Kermit software--including source code--is furnished without warranty of any kind, and neither Columbia University, nor the individual authors or publishers, nor any institution that has contributed Kermit material, acknowledge any liability for any claims arising from the use of Kermit. Since source code is available, users may fix bugs and make improvements, and are encouraged to contribute their work back to Columbia for further distribution. Kermit software may be ordered by private individuals, corporations, academic or government institutions, and other organizations for their own internal use, but the software may not be resold or otherwise redistributed to external clients, customers, or contractors without written permission of the Manager of Kermit Development and Distribution at Columbia University. Contact us for further information. #end kermit.columbia.edu:~ftp/kermit/e/aaxfly.doc# Again, nothing is inconsistent with economically free availability. Note especially the phrase "Kermit software is not a commercial product", and the fact that "The Kermit Protocol Manual will continue to be freely distributed in perpetuity". Looks pretty free to me. -- -=Paul Flaherty, N9FZX | "Fighter pilots make movies. Bomber pilots make ->paulf@Stanford.EDU | history." -- Jake Grafton -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!gatech!swrinde!cs.utexas.edu!utah-morgan!hellgate.utah.edu !cc.usu.edu!jrd Message-ID: <1994Jan25.173740.8796@cc.usu.edu> Date: 25 Jan 94 17:37:40 MDT References: <1994Jan24.011009.2030@eisner> <1994Jan25.151426.22711@omen.UUCP> Organization: Utah State University From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: Protocol Shootout Results In article <1994Jan25.151426.22711@omen.UUCP>, caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > In article <1994Jan24.011009.2030@eisner>, > billy@mix.com (Billy Youdelman) writes: >>In article William C Fenner >> writes: >> >>> But Kermit, in the way that it was set up for Columbia's test, has no >>> way to interrupt the transfer *at*all*. Tough luck if something happens >>> and you don't want to see all the spew on your screen. >> >>How about sending it an error packet? >> >>Billy Y.. >> > > Neat idea. Perhaps the next version of C-Kermit and MSKermit will do that. > Of course an error packet may be as effective as stopping the Queen Mary > by dragging an oar if Kermit already has five 5000 byte packets queued up. > > -- > Chuck Forsberg WA7KGX caf@omen.COM 503-621-3406 > Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ > Omen Technology Inc "The High Reliability Software" > TeleGodzilla BBS:621-3746 FAX:621-3735 CIS:70007,2304 -------------- An error (E) packet is just fine, and it works unless the other side has become rather hopelessly locked up. As I mentioned offline to another person I think I've tried ^C^C maybe twice over the past year, and I tend to use Kermits rather frequently (I wonder why). An Error packet is available from the keyboard during a file transfer session, as are less drastic X (skip this file) and Z (skip the rest of the file group) keyboard interruptions. These features have been in Columbia Kermits for years and years, are part of the original protocol, are described in the user's manual books, are on the screens. Consequently the comment at the top of the inclusion is false. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!nntp.memst.edu!ukma!eng.ufl.edu!saimiri.primate.wisc.edu !sdd.hp.com!sgiblab!darwin.sura.net!howland.reston.ans.net !sol.ctr.columbia.edu!news.columbia.edu!usenet Message-ID: <2i699f$5h2@apakabar.cc.columbia.edu> Date: 26 Jan 1994 17:29:19 GMT References: <1994Jan26.162400.4383@omen.UUCP> Organization: Columbia University From: fdc@fdc.cc.columbia.edu (Frank da Cruz) Subject: Re: Protocol Shootout Results In article <1994Jan26.162400.4383@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > > In article <758917572snx@crynwr.com> nelson@crynwr.com (Russell Nelson) > writes: > ... > Bravely spoken by someone with a commercial link to Columbia > University's Kermit software. > ... > The real "wonk issue" is that Columbia knows my observations are > correct. They have not even attempted to rebut them. Frank da > Cruz declined to appear at the Jan 6 Protocol Shootout knowing > full well the troubling questions about Kermit News he would be > forced to address. > I already addressed all these points weeks ago. Chuck clearly believes that by reiterating them on a daily basis, they will become gospel. However, I will not engage in public bickering with someone whose primary debating tactic is to always get in the last word. The Kermit News article speaks for itself -- Chuck can refute it all he wants to, and you, good readers, can judge for yourselves. Bear in mind, however, that this is not an all-or- nothing issue -- use one, use both, use neither. I am only posting this to dispel the notion that anyone is hiding, and to point out that Chuck is acting an awful lot like Senator Joe McCarthy of yore, brandishing his lists, naming names, and assigning guilt by association. I would not like to think that participants in this newsgroup hesitate about their postings for fear they will be publically vilified and ridiculed. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!nntp.memst.edu!ukma!asuvax!farallon.farallon.com!agate !howland.reston.ans.net!sol.ctr.columbia.edu!news.columbia.edu!usenet Message-ID: <2imthj$pu5@apakabar.cc.columbia.edu> Date: 2 Feb 1994 00:53:07 GMT Organization: Columbia University From: fdc@fdc.cc.columbia.edu (Frank da Cruz) Subject: Re: Protocol Shootout Results Lines: 441 Against my better judgement I promised Chuck I would respond to his "Protocol Shootout Report". I apologize for prolonging this ridiculous debate, and I would encourage Chuck to refrain from further gratuitous snipes at each person who posts a message even remotely supportive of Kermit or critical of Zmodem, not to mention using innocent questions -- even on unrelated topics -- as an opportunity to fire off another salvo. I think everybody comes off looking and feeling better if we just answer users' questions and try our best to solve their problems, and stop using this forum as a soapbox. Chuck says: > For Russ' sake I do hope Crynwr software derives more income as a > result of their relationship with Columbia Kermit than the cost of a > single $20 DSZ registration. And for Chuck's sake, I hope he does not make a regular practice of disclosing business details about his customers in public. This is not a big confidence builder for potential customers. Chuck says: > ...as it was written and as people read it, Kermit News #5 is a > promotional piece that seeks to enhance Columbia's revenues by > trumpeting the relative performance of Columbia's product under a > selected set of conditions and alternatives carefully contrived to > promote the idea that Kermit is faster than competitive alternatives. > Of course it's a promotional piece. However, the test conditions are fair. Four representitive types of files -- including the ones where Zmodem's well-known strengths lie -- were transferred over different types of connections. Chuck's primary complaint, as I understand it, was that I did not use ZMODEM-90(TM)-Moby-Turbo(TM) extensions in my tests. Fine, I never said I did. I used the software that everybody uses and compares Kermit against, the packages we have heard about constantly over our many years of help-desk experience, and the article is totally explicit and detailed about what was tested. Chuck says: > So we're back to where we started before Columbia University's Kermit > News #5 broadside attack on their competition: Use Kermit for > traditional IBM mainframes and other weird iron, otherwise use ZMODEM > to get the best in speed, the reliability of 32 bit CRC, and Crash > Recovery for real world error recovery. That's clearly a skewed opinion. Here is my skewed opinion: Use Kermit anywhere at all. Use Zmodem on a small subset of "anywhere at all". You can't use Zmodem on the rest of "anywhere at all" because it does not work, or it does not exist, in that environment. This includes at least all 7-bit connections, which are quite common outside the BBS world, and all of the "oddball" operating systems that one finds on IBM mainframes, etc, which, one supposes, are only to be sneered at. I would be very surprised to learn of a connection where Zmodem works and Kermit does not. On those connections where "regular" Zmodem protocol works at all, you can get Kermit to work just as well or better. Zmodem-90-Moby-Turbo(TM) might well go faster than Kermit if you have it available to you on both ends, and the connection is cooperative, and if that is true, then hats off to Chuck. Chuck says: > Columbia could have improved on this situation by developing a > compact, high performance version of the WKERMIT (The Source) Kermit > driver that could be used by bulletin boards, Telix, ProComm, Qmodem, > et al. Perhaps it is not too late for Columbia to correct the > situation. This is absolute nonsense, and a red herring on two counts. The implementation Chuck is referring to (a) is nine years old, (b) was a quick hack that hardly ever worked, and (c) depended, in the PC version, on proprietary libraries for communications functions. The "WKERMIT" Chuck is referring to did not allow long packets, had horrible error-recovery characteristics, and because of the communications strategies used, would get hopelessly hung if there were any confusion about modem signals, to the point that you'd have to reboot your PC, and it did not support any kind of flow control. Furthermore, it had no terminal emulator, no script language, no convenience features like key mapping, and none of the server-related Kermit protocol functions are supported. Anybody who wants to check out this "compact, high performance version" of Kermit for themselves, feel free: host kermit.columbia.edu, directory kermit/extra, files wkermit.*. Note: wkermit.exe is binary, the rest are text. In short, it is a primitive package and its Kermit protocol implementation is limited and fragile. It was a stopgap commissioned by The Source [an early online service], cobbled together in a hurry by a contract programmer from even-then obsolete C-Kermit source code, to be used until the real thing came along. Although it was some time in coming, the real thing did, indeed, come along, and WKERMIT was promptly retired. > Columbia could have improved on this situation by developing a > compact, high performance version of the WKERMIT (The Source) > Kermit driver that could be used by bulletin boards, Telix, > ProComm, Qmodem, et al. Perhaps it is not too late for Columbia > to correct the situation. > Red Herring #2 -- Suppose we rephrase this as: "Omen Technology could have improved on this situation by developing a compact, high performance version of the Zmodem-90(TM)-Moby(TM)-Turbo(TM) driver that could be used by bulletin boards, Telix, ProComm, Qmodem, et al. Perhaps it is not too late for Omen Technology to correct the situation." SHOOTOUT RESULTS Chuck says: > Last July Columbia University used its non-profit mail permit to > distribute thousands of copies of Kermit News Number 5. > Point for Chuck. Yes, as a nonprofit institution, we do indeed get a break on bulk 3rd-class mailings. So what? > In "The Truth about Kermit File Transfer Performance" tenured > Columbia University professor... > That I'm not. > ...Frank da Cruz proudly announces that Kermit "outperforms X-, Y-, > and ZMODEM protocol transfers every time." Out of context. Anybody who reads the article knows that that "ZMODEM protocol transfers" refers to the ones that were performed in the suite of tests, using the specified software (Procomm, Telix), and "every time" refers to each test that was performed. Again, I invite anybody who is interested, and especially anyone who feels compelled to take sides on this issue, to actually read the article. I will be glad to send you printed copy if you send me your postal address. You can also ftp it from kermit.columbia.edu, directory kermit/e, files: newsn5.txt (ASCII) newsn5.ps (PostScript) > It is not my intention to defend a competitor's product. But, > the reported Kermit efficiency of Procomm Plus (93%) and Zstem > (97%) are very close to that of Columbia's own MSKermit (99%). > Right; I did not want to imply that all non-Columbia PC Kermit implementations are lousy, but I did want to show that MS-DOS Kermit is equal to or better than the best of them. I also left out some others that were ridiculously bad. > Frank's 104% figure for MSKermit is misleading because the reduced > control character prefixing responsible for the MSKermit speedup also > works sending to Procomm Plus. Columbia does not disclose this > inconvenient result. In fact, C-Kermit sending to Procomm Plus > transferred some of Columbia's test files in less time than the > C-Kermit-MSKermit combination required. > Score half a point for Chuck. It's true, I did not know that Procomm could handle unprefixed control characters. In fact, it can handle *some* unprefixed control characters. But carriage return (Ctrl-M) is not among them, so all we gain in text file transfers in this case is the ability to send linefeed bare. When I repeated the test downloading the same text file to Procomm under the same conditions as the original test, except with all possible control characters unprefixed, Procomm's score went up from 93% to 94%. > After shading the truth about competitors' Kermit downloading > performance, Frank's paper proceeds to redefine the YMODEM protocol > I developed in the 1980's. > Sorry if I misrepresented YMODEM -- Nevertheless, the YMODEM protocol used in the tests was as stated: sb on the host, and YMODEM protocol in the PC software. Whatever it is! > Thanks to Columbia's ignorance of file transfer protocols I don't know > what protocol they actually used for the "XMODEM" and "YMODEM" tests > listed in Columbia's True-Life Benchmarks. > It's clearly stated in the article: sx and sb on the host, XMODEM or YMODEM protocol in the PC software. > But Columbia's published numbers reveal a seriously slovenly > experimental procedure. XMODEM and ZMODEM in all their forms transmit > file data verbatim, without any prefixing. As a result, data patterns > have no effect on X/YMODEM throughput. > The results given in the article are exactly as reported by the software, and each trial was run three or more times. Theory is fine, but in the real world all sorts of factors can cause variations. We have been through this time and again. > In addition, Columbia Kermit programs significantly understate the > time required to perform a file transfer. Kermit reports a file > transfer took 112.98 seconds when in fact the machines were tied up > more than nine seconds longer. > Here's what actually happens: if you install C-Kermit according to instructions, it comes with an initialization file that reads in your dialing and services directories and defines all sorts of macros. Obviously, this can take some time, especially on slow computers. These are convenience features that have nothing to do with file transfer, that can be skipped. sz does not have features like script programming, dialing directories (let alone dialing), and so starts up faster. If you want Kermit to start up as fast as sz, you can tell it to skip the initialization file and give the file-sending and parameter-setting commands on the command line, for example: kermit -Y -v 5 -e 5000 -s foo.zip For real speed, you can even build a nonstandard version of Kermit that excludes all sorts of time-and-space-consuming features: the interactive command parser, the built-in debugger, the character-set translator, etc, and reduce the startup time to practically nil AND make it run faster too. I did not do that, because it would not be representative of the C-Kermit software that people actually use. Second, there is a deliberate default delay of 5 seconds after you give a SEND command to a remote-mode C-Kermit, to give the user time to "escape back" to the local Kermit and give a RECEIVE command. This is purely a convenience feature and has nothing to do with the protocol -- it gives the user time to read an instructional message and then to escape back without seeing the first packet on the screen. Of course you can set the delay to be any length of time you want, including zero, and you can disable this feature altogether. (AND you can also use the autodownload feature to obviate the need for escaping back altogether -- yes: Kermit has autodownload too, *and* autoupload). For the record, Kermit's timers start ticking when the first packet is sent or received, and stop when the last packet is sent or received. > One set of Columbia's measurements was so preposterous that I > simply couldn't resist having a bit of fun with it. We noticed > that cutting the communications speed from 19200 to 9600 > actually increased the speed of a Columbia Kermit file transfer > from 2648 to 2736 characters per second. (p.13, Tables 2 and 5.) > This is indeed what happened. Explain it any way you like. > One of the tricks Columbia used to discredit ZMODEM in their > "True-Life Benchmarks" was to carefully select files with > redundant data that responds unusually well to Kermit's run > length compression while at the same time refusing to use ZMODEM > compression. > In fact, we chose four types of files: 1. A typical text file (the IBM Mainframe Kermit manual). 2. A UNIX binary file, which, admittedly, had big runs of zeros. 3. An MS-DOS binary (.EXE) file (MS-DOS Kermit itself). 4. A ZIP file (the MS-DOS Kermit distribution file set). Each of these files illustrates properties of the two file transfer protocols. Nothing is rigged or pre-engineered here -- these are perfectly normal files. We could easily have left out (for example) the ZIP file, which would have skewed the results far more in favor of Kermit, or picked a text file that could have been compressed a lot more. > The most egregious instance of this deception is seen with Columbia's > selection of a Sun Sparc binary of the "uuencode" program. This is a > tiny program stored in a 24576 byte file. All but a few thousand are > nulls. Naturally this does wonders for Kermit transfer speeds. Had > Columbia's protocol boffins read the sz 3.24 documentation they could > have discovered that ZMODEM compression does even better. > But only if you use it with PC software that includes ZMODEM-90(TM)-etc extensions. I actually did use the compression option (-Z) on sz, but it had no effect since, apparently, Procomm and Telix don't do anything with it. And yes, the "uuencode" file was chosen deliberately to illustrate the dramatic effects of Kermit compression on this type of file. So what? People actually do transfer this type of file from time to time. > Real world users download mostly compressed files,... > This is debatable. As I pointed out yesterday, the readers of this newsgroup are are not typical of the world's computer users at large. > ... and here the winner is YMODEM-g, closely followed by MobyTurbo(Tm) > ZMODEM, regular ZMODEM, with Kermit bringing up the rear. > YMODEM-g has not much more resemblence to a file transfer protocol than Kermit's TRANSMIT command, or "copy foo.zip com1". If it works, of course it's fast, because it doesn't do anything other than blast the data at the other end, all in one piece, with a filename on the front and checksum on the end (I'm sure Chuck will correct me if this is a gross misrepresentation of YMODEM-g technology). Recovery from transmission errors is, to use Chuck's words, "by sudden death". > So why is Kermit not the fastest when it only prefixes a few control > characters? The question is incorrect. Columbia claims that only 0, > 1, and 129 need to be prefixed, but this doesn't work sending to > MSKermit 3.11. > Of course it doesn't, we never said it did. We were using MS-DOS Kermit version 3.13, which is the first release to support this feature. Also, our advice about which characters need to be prefixed goes into a lot more detail -- there are no simple formulas. Today, for example, I found that when using a local Annex terminal server, the following characters must be prefixed in addition to whatever might be required by the Kermit programs themselves: 15 18 21 23 29 127 143 146 149 151 157 255. Not all connections in the world are totally transparent, the way BBS users are accustomed to. > The most impressive demonstration, and the likely reason Frank da Cruz > did not choose to appear at the Shootout is Kermit's performance in > the noise test. Or, to be more precise, Kermit's non-performance. In > the Kermit News True-Life Benchmarks, Frank da Cruz specified a window > size of 5 and a packet length of 5000. Undoubtedly Frank chose this > long packet length to minimize Kermit's high per packet overhead > compared to ZMODEM SUBpackets. > 8-10 bytes out of 5000 = 0.18 percent. Who is going to quibble about that? Of course I chose long packets to improve performance -- that's what they're for. This is all explained in the article. > XMODEM, YMODEM and Kermit cannot resend a packet with a different > size. The problem is even worse with Kermit's selective > retransmission protocol. When we attempted to replicate Columbia's > 9600 bps plus noise test (Table 5) Kermit failed every time. Well, > almost every time. The first few times Kermit worked, but that was > only because C-Kermit quietly refused to send the specified 5000 byte > packets because a needed "set buffer" command was not included. When > Kermit actually uses the specified 5000 byte packets with noise bursts > at 2 second intervals, no data packets get through. Why? It takes 5 > seconds to send a 5000 byte packet at 9600 bps but the specified noise > bursts come faster than that. Kermit croaks every time unless the Jim > Kirk Kobiashi Maru procedure is used (relax the test). > Chuck makes a good point here. He's right: if the noise bursts came at precise 2-second intervals, the first data packet would never have gotten through. But the noise bursts were being generated on a UNIX system, whose actions are governed by a scheduler, and are therefore not precise. Once the first data packet got through, the remaining packets were shortened automatically. I deliberately chose the worst possible conditions under which Kermit could function at all with the same settings that I was using in the preceding tests. I could have sweetened the results considerably by tailoring Kermit's settings *in advance* for noise resistence, and increasing the noise level. For example, noise every 1/2 second, and short, 94-byte packets (which are, by the way, Kermit's default) rather than 5K packets. Kermit would have come out even further ahead than it did in the article. > I made an informal survey of the guests at the shootout. As so > many have noted, line noise today manifests itself mostly in > disconnected calls. > We've been through this before too. Just because this is 1994, you can't assume that all telephone connections are clean (here in the New York City area, T1 clock slippage is still a frequent occurrence). Ask residents of other countries -- especially in Eastern Europe, the former Soviet Union, China, Africa, and South America, about their telephone systems. We also cannot assume that everybody in the world is using error-correcting modems. Even assuming all that were true -- no more noise, no more errors -- we still have other sources of error, overlooked all too often: improperly (or un-) implemented flow control, data overruns on PCs that do not have buffered UARTs, interrupt conflicts, etc. > When this happens ZMODEM's Crash Recovery is relevant, allowing the > safe resumption of interrupted file transfers. Since Kermit has no > such feature Columbia chose not to discuss this most vital of ZMODEM's > many features. > ZMODEM's crash recovery is indeed a useful feature, but... (a) It only works for binary-mode transfers. (b) It only works when the file sender has a stream-oriented file system that supports an "fseek()" operation. It doesn't work for text-mode transfers because files can change size during text-mode transfer because of record-format conversion. It doesn't work on record-oriented file systems, or with record-oriented file formats. A fully capable "crash recovery" feature would work for both text and binary mode transfers, and it would not make any assumptions about the features of the file system. It would be built into the protocol at the session layer. It would involve checkpoints, commitments, and protocol messages that would allow resumption not only of an interrupted file transfer, but even of the connection itself. These are complicated issues requiring a lot more thought than "hmmm, how long is the file? n bytes? OK, fseek(n) and start blasting away". This kind of "crash recovery" could be added to Kermit software with about five minutes' programming time, but it would be useful only in the circumscribed world where Zmodem's method is also useful, and Kermit caters to a more diverse audience. When crash recovery appears in Kermit protocol and software, it will be generally useful. Later, Chuck says: > This historical dissertation overlooks one critical fact. If a > desired text translation is not performed by the file transfer > protocol, the translation can be made later. No information lost. > > But when Kermit modifies files with spurious text translations > that file is destroyed. > > In the real world one cannot equate the two situations. > No matter whether the default transfer mode is text or binary, somebody will transfer files in the wrong mode; it can't be avoided. Chuck is right, transferring a binary file in text mode results in garbage. But: "If a desired text translation is not performed by the file transfer protocol, the translation can be made later. No information lost." Is it? Maybe this is true in the English (ASCII) speaking world. Do any readers of this newsgroup transfer textual data written in Albanian, Bulgarian, Byelorussian, Czech, Danish, Dutch, Faeroese, Finnish, French, German, Hebrew, Hungarian, Icelandic, Irish, Italian, Japanese, Macedonian, Norwegian, Polish, Portuguese, Romanian, Russian, Serbocroatian, Slovak, Slovene, Spanish, Swedish, or Ukrainian? Between unlike systems that use totally different encodings for the "special characters" of your language? Did you know that Kermit handles the character sets for all these languages, and more? Let's look at just (say) German. Here are a few of the common *and* *totally* *different* encodings I can think of for German: German ISO 646, ISO 8859-1 (and -2), IBM PC code pages 437, 850, and numerous others; IBM Mainframe (EBCDIC) code pages 037, 500, and numerous others; DEC Multinational, Data General International, Macintosh, Atari, HP Roman8, NeXTSTEP. Is it the responsibility of every German-speaking computer user to know all of these character sets and have translation utilities that work between every pair of them on every kind of computer? OK, so everybody should speak English and then everything works. But then what about record formats? Suppose I transfer a text file from a record-oriented system in binary mode by mistake. I lose the record boundaries. Suppose it's a BASIC or FORTRAN program, or a poem. Vital information is lost -- the program won't compile, the poem won't scan. In an ideal world, computers would have been designed from the beginning with considerations like this in mind. Imagine how easy all our lives would be if file systems and organizations and character sets were all compatible? Then we would have one and only one transfer mode, and it would always work, and always produce useful results. But this is the real world, in which nobody can agree on anything, and everyone proclaims their own way of doing things a "standard". - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!ornl!rsg1.er.usgs.gov!darwin.sura.net!howland.reston.ans.net !cs.utexas.edu!uunet!nwnexus!camco!camco!not-for-mail Date: 23 Feb 1994 19:42:27 -0800 Organization: Celestial Software, Mercer Island, WA Message-ID: <2kh7n3$h26@camco.celestial.com> References: NNTP-Posting-Host: camco.celestial.com From: bill@camco.celestial.com (Bill Campbell) Subject: Re: SCO kermit In frank@tsh.com (Frank Mostek) writes: : :Would a kind soul please email me the SCO version of kermit? I bought :the source, but our customer does not have the C compiler on the SCO :box, and I don't have access to a SCO box. Considering that the binary for 3.2v4 is 437632 stripped, this isn't really a candidate for e-mail. I have it on ftp.celestial.com if you have ftp access. Bill -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!gatech!howland.reston.ans.net!europa.eng.gtefsd.com !library.ucla.edu!ihnp4.ucsd.edu!dog.ee.lbl.gov!hellgate.utah.edu !cc.usu.edu!jrd Message-ID: <1994Mar7.093039.12780@cc.usu.edu> Date: 7 Mar 94 09:30:39 MDT References: <1994Mar7.134440.29536@ibr.cs.tu-bs.de> Organization: Utah State University From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: Kermit: How to get rid of echos ? In article <1994Mar7.134440.29536@ibr.cs.tu-bs.de>, c0033010@ws.rz.tu-bs.de (Sven Kuehne) writes: > > I don't know if my question will fit into this newsgroup, but comp.protocols. > kermit seems to be a bit deserted ... > > How can I tell Kermit to be quiet when executing a script ? I only wanna > see thing I write out by using 'echo ...'. I don't want things from > 'output ...' or the replies of the other side written to the screen. I've > tried 'set local-echo off' but it doesn't help ! > > Does anyone know how to achieve this ?! It might be simple ... > Sven > #===========================================================================# > # Sven Kuehne Rechenzentrum tel +49 531 391-5548 # > # TU Braunschweig fax +49 531 391-5549 # > # Abteilung Netze und Hans-Sommer-Str. 65 email c0033010@ws.rz.tu-bs.de # > # Arbeitsplatzrechner D-38092 Braunschweig s.kuehne@tu-bs.de # > #===========================================================================# Two answers for you. 1. As discussed in the user's manual, the book "Using MS-DOS Kermit", the script commands INPUT and OUTPUT control their echoing with SET INPUT-ECHO ON or OFF. Maybe you need to acquire the manual, details on screen two of the Help command. 2. The Kermit News group material goes straight to Columbia rather than being reflected worldwide. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!rsg1.er.usgs.gov!jobone !newsxfer.itd.umich.edu!caen!usenet.cis.ufl.edu!usenet.eel.ufl.edu !news.mathworks.com!hookup!news.moneng.mei.com!howland.reston.ans.net !news.sprintlink.net!EU.net!sun4nl!echelon!kees Organization: Echelon Consultancy, Enschede, The Netherlands Date: Mon, 31 Oct 1994 17:01:10 GMT Message-ID: References: <392u8h$hvr@apakabar.cc.columbia.edu> From: kees@echelon.nl (Kees Hendrikse) Subject: Re: ANSI (Was: MS-DOS Kermit 3.14 Beta-9 Ready) In <392u8h$hvr@apakabar.cc.columbia.edu> Frank da Cruz writes: > > In article kees@echelon.nl (Kees Hendrikse) writes: >> (...) would it be very hard to also implements the 'SCO console' emulation, >> a.k.a. SCO-ANSI? > I believe this is basically the current ANSI screen handling, but with the > keyboard handled differently -- instead of transmitting the characters > associated with the keys, the scan codes are transmitted. Scan codes are optional (settable with stty for scan-code terminals). In Ascii-mode the function keys send escape sequences. F1 sends ESC[M, shift-F1 sends ESC[Y etc. Screen handling is PC-Ansi/vt100-like, except for scrolling, coloring, special things like 'send-screen-to-host'. > To the best of my knowledge, this is used only for communicating with the > SCO console driver. True? SCO ansi can be used via the serial driver as well, by using the 'ansi' termcap/terminfo entries. Quite a few terminal-emulation packages have a sco-ansi option now (James River's Ice-ten, for example), which makes it the emulation of choice with these programs. -- Kees Hendrikse | email: kees@echelon.nl | ECHELON consultancy and software development | phone: +31 (0)53 836 585 PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 337 415 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!mp.cs.niu.edu !vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com !news.mathworks.com!udel!news-4.nss.udel.edu!chopin.udel.edu!not-for-mail Date: 1 Nov 1994 16:10:18 -0500 Organization: Broken Toys Unlimited Message-ID: <396arq$fqc@chopin.udel.edu> References: <1994Nov1.100933.2067@gems.vcu.edu> From: darkstar@chopin.udel.edu (Jerry Alexandratos) Subject: Re: More lines per page? In article <1994Nov1.100933.2067@gems.vcu.edu>, Brainwave Surfer wrote: :Dear Netbeings, : I have a wonderful relationship with MS-dos kermit. apart from dos, :the package is fine. I'd like to figure out how to set the video such :that I can use one of the other modes, like 50 lines per screen, etc. :Everything else is ok, but i'm lusting for more of the page like I can :get on my Decterms in Motif. : :Jim [sig deleted] Okay, here's what you need to do on both ends of the connection. PC--make sure you've got either an EGA card (for 43 line mode) or a VGA card (for 50 line mode). Some cards support some funky things like 60 lines under some Super-VGA setting or another. make sure you load an ANSI driver like ansi.sys or nnansi.sys issue the following mode command `mode con: lines=50'. start kermit. UNIX-connect to host. issue an eval `tset -sQI ` command to set the TERM and TERMCAP environment variables. For example eval `tset -sQI vt220` evaluates and sets the variables for vt220 term. Make sure that you put in the ``I'' argument. If you don't, then you'll see your screen cut in half and only the first 25 lines being drawn on. If this happens, then you'll have to go to the kermit command line and do a `ru mode con: lines=50' command to reset your local terminal. Issue the `stty rows 49' command to set the number of rows (or `stty rows 50' if you don't use the status line at the bottom of the screen), followed by a `reset' command. That should do it. I don't know how to do this if you're connecting to other types of host. I think that for IBM's it doesn't make a difference if they're in fullscreen mode, then they'll use all of the available lines. As for other types of hosts, your mileage may vary. --Jerry -- |> Jerry Alexandratos ** "vengo de la tierra del <| |> darkstar@strauss.udel.edu ** fuego ten cuidado cuando <| |> darkstar@canary.pearson.udel.edu ** llamas mi nombre..." <| -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!mp.cs.niu.edu !vixen.cso.uiuc.edu!howland.reston.ans.net!gatech !news-feed-1.peachnet.edu!emory!metro.atlanta.com!spcuna!ritz!kudut References: Organization: Mordor International BBS - Jersey City, NJ Date: Tue, 1 Nov 1994 18:03:47 GMT Message-ID: From: kudut@ritz.mordor.com (Ken Udut) Subject: Re: Receiving files "automatically" In article , drw@runge.mit.edu (Dale R. Worley) writes: > >I'd like to know if there's any way that I can get (MS-)Kermit to >receive a file "automatically" when the remote end runs a Kermit that >is attempting to send a file. As far as I can tell, right now once I >start the remote Kermit sending, I have to get out of CONNECT, and >then manually issue a RECEIVE command, then reconnect. This seems >quite pointless, so probably there is a way to make it all happen >automatically. But I haven't been able to find it in the >documentation. What version of Kermit are you running? Latest beta test is 3.14, revision 10, available at kermit.columbia.edu under the directory: /kermit/test/bin/mstibm.zip To automatically send/receive files via Kermit, please check out the KERMIT.UPD file that comes with the beta. It explains how to engage autoupload/download with Kermit. NOTE: MS-Kermit must be version 3.14, and C-Kermit (assuming that is what is on the host side) must be version 190. >Also, is there a "dial this number and connect me to it" command? >So far, I have been stuck doing a CONNECT and then manually issuing >ATDT to the modem. To dial, type "dial xxx-xxxx" or edit the DIALUPS.TXT file and add the phone number you wish to dial in the format specified in that file. If I'm not mistaken, if you use the "dial" macro, it will connect you. Otherwise, if you are a purist and want to do ATDT before the phone numbers, then put a CONNECT at the bottom of your MSCUSTOM.INI. >And why is it that Kermit comes with almost no documentation? It comes with a *lot* of documentation. The KERMIT.BWR and KERMIT.UPD file are both sets of documentation. If you issue a HELP at the Kermit prompt, you get more information. While you are typing in a comment, but you are not sure what to type in next, press a ?, and you will magically get help for that command. Indeed, you can learn almost everything there is to know about MS-Kermit, programming scripts, macros, etc. (which aren't really all that hard!) simply by using the information provided with the Kermit distribution. >Or is the rumor that Kermit is "free" just a front for selling books? Indeed - it is a rumour. Is it true? No. Ken kudut@ritz.mordor.com LISTOWNER of Y-RIGHTS@SJUVM.STJOHNS.EDU-'discussion on the rights of kids/teens -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!gatech!howland.reston.ans.net!wupost!simtel.coast.net!w8sdz Message-ID: <9411030524.AA13559@SimTel.Coast.NET> Date: Thu, 3 Nov 1994 05:24:58 GMT Organization: SimTel, the Coast to Coast Software Repository (tm) References: <397oln$cp3@israel-info.datasrv.co.il> From: w8sdz@SimTel.Coast.NET (Keith Petersen) Subject: Re: Zmodem on kermit 4dsoft@zeus.datasrv.co.il (4th Dimension) writes: > >Im looking for a way to perform file transfer via the Zmodem utilities >while working in kermit. > >Examples will be appreciates. ; ;Thanks to Jason Merrill for this ;define to add zmodem protocol transfers. Add it to your mskermit.ini. ; define rz run dsz F ha cts est 0 14400 rz \%1 \%2, define sz run dsz F ha both est 0 14400 pB4096 sz \%1 \%2, define t run dsz F ha cts est 0 14400 t \%1 \%2, Keith -- Keith Petersen Moderator of comp.archives.msdos.announce and the MSDOS-Ann mailing list Internet: w8sdz@SimTel.Coast.NET or w8sdz@Vela.ACS.Oakland.Edu Uucp: uunet!umich!vela!w8sdz BITNET: w8sdz@OAKLAND -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu !cc.usu.edu!jrd Message-ID: <1994Nov3.223304.31997@cc.usu.edu> Date: 3 Nov 94 22:33:04 MDT References: Organization: Utah State University From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: 132-column Mode and MS-Kermit Verbs In article , korty@london.physics.purdue.edu (Andrew J. Korty) writes: > > My friend and I just discovered the world of 132-column mode, and we > have a few questions for all who are familiar with its numerous > wonders. > > 1. My friend wants to define a key to switch between the modes while > in terminal emulation mode, but we couldn't find a verb that does > this. Is using verbs the only way? Also, we'd like to know if > there's a way to define a key to escape back to command mode and > execute a Kermit command (of any kind). Check the user's manual, the book "Using MS-DOS Kermit" whose details are given on the Kermit HELP screen and the *.UPD files issued since then. You can assign a Kermit macro as the definition of a key. The macro can do anything you could say at the Kermit prompt, including issue SET TERM commands. Syntax is SET KEY keycode {\Kmacroname} and the \K must be inside the curly braces. > 2. I'm running DOS Kermit under OS/2 in a full-screen DOS session. > When I use 132-column mode, everything works fine until I switch back > to the desktop, at which time the video proceeds to get completely > screwed up. The only way to save things is to go back to Kermit and > do an Alt-X (which puts the screen back in 80 column-mode) and then go > back to the desktop (which is still screwed up) and activate a screen > saver or something to refresh the screen. It's between OS/2 and your video driver and your monitor. Please remember that there is no standard on 132 column video modes so that OS/2 has no idea of what state the display is in and hence little idea of what to do about it. Better video drivers could help more, however. > 3. Also, Kermit's documentation claims that it can auto-detect the > screen width requested by the host, but doesn't seem to. Maybe you mean the opposite here. Hosts can request 80 or 132 columns from VTxxx terminals, nothing more. Kermit obeys those requests. Perhaps you mean that Kermit can tell the host its current screen size upon request, which is true. There is no "auto-detect" in this arrangement, by either host or terminal emulator. Kermit can also report screen size in Telnet Options packets, if the host agrees to do so. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!usenet.eel.ufl.edu !news.mathworks.com!hookup!news.moneng.mei.com!howland.reston.ans.net !sol.ctr.columbia.edu!news.columbia.edu!usenet Date: 7 Nov 1994 22:26:13 GMT Organization: Columbia University Message-ID: <39m9i5$e00@apakabar.cc.columbia.edu> References: <39lv9v$2s@vixen.cso.uiuc.edu> From: fdc@fdc.cc.columbia.edu (Frank da Cruz) Subject: Re: Will the New MS-DOS Kermit have MINPUT? In article <39lv9v$2s@vixen.cso.uiuc.edu> adam@symcom.math.uiuc.edu (Adam H. Lewenberg) writes: > > Will the New MS-DOS Kermit have the MINPUT command? I would like my > scripts to work in both MS-DOS Kermit and C-Kermit, so it would be > nice if MINPUT was supported n MS-DOS Kermit. Adam Lewenberg > It is kind of late in the Beta cycle to consider adding this. However, you might be able to make do by defining an MINPUT macro, something like this (courtesy of James Sturdevant): define minput set alarm \%1,- :top,- if alarm end 1,- input 1 \%2,if success asg mynput 1,if success end 0,- if not def \%3 goto top,reinp 0 \%3,if succ asg mynput 2,if succ end 0,- if not def \%4 goto top,reinp 0 \%4,if succ asg mynput 3,if succ end 0,- if not def \%5 goto top,reinp 0 \%5,if succ asg mynput 4,if succ end 0,- if not def \%6 goto top,reinp 0 \%6,if succ asg mynput 5,if succ end 0,- if not def \%7 goto top,reinp 0 \%7,if succ asg mynput 6,if succ end 0,- if not def \%8 goto top,reinp 0 \%8,if succ asg mynput 7,if succ end 0,- if not def \%9 goto top,reinp 0 \%9,if succ asg mynput 8,if succ end 0,- goto top and then use it like this: minput 60 CONNECT ERROR {NO CARRIER} BUSY RING if fail errfail {No response from the modem} if eq \v(program) C-Kermit asg mynput \v(minput) goto CASE_\m(mynput) - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!usenet.eel.ufl.edu!news.mathworks.com!hookup!swrinde!cs.utexas.edu!uunet!winternet.com!jamess From: jamess@winternet.com (James Sturdevant) Subject: Re: Will the New MS-DOS Kermit have MINPUT? Date: 8 Nov 1994 23:35:50 GMT Organization: StarNet Communications, Inc Lines: 21 Message-ID: <39p20m$rn1@blackice.winternet.com> References: <39lv9v$2s@vixen.cso.uiuc.edu> <39m9i5$e00@apakabar.cc.columbia.edu> NNTP-Posting-Host: icicle.winternet.com X-Newsreader: TIN [version 1.2 PL2] Jeffrey Hurwit (jhurwit@netcom.com) wrote: : In article <39m9i5$e00@apakabar.cc.columbia.edu>, : Frank da Cruz (fdc@fdc.cc.columbia.edu) wrote: : >In article <39lv9v$2s@vixen.cso.uiuc.edu> adam@symcom.math.uiuc.edu (Adam H. : >Lewenberg) writes: : >> : >> Will the New MS-DOS Kermit have the MINPUT command? I would like my : >> scripts to work in both MS-DOS Kermit and C-Kermit, so it would be : >> nice if MINPUT was supported n MS-DOS Kermit. Adam Lewenberg : [macro and example of how to use it deleted] : Yes, this would work, but it's a little big, and memory is at a : premium for some of us. I tend to use take files more, and save : memory for key settings and screen rollback. Well, there is no reason that you can't put the text into a take file and then define minput to take the take file. Macros are no more than memory resident take files. JamesS -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!usenet.eel.ufl.edu !news.mathworks.com!udel!gatech!howland.reston.ans.net !sol.ctr.columbia.edu!news.columbia.edu!usenet Date: 8 Nov 1994 16:52:40 GMT Organization: Columbia University Message-ID: <39oaco$5us@apakabar.cc.columbia.edu> References: From: fdc@fdc.cc.columbia.edu (Frank da Cruz) Subject: Re: Receiving files "automatically" In article drw@runge.mit.edu (Dale R. Worley) writes: > Hmmm... Just checked my KERMIT.HLP (version 3.13, gotten from > watsun.cc.columbia.edu, I think, but I can't check right now, its FTP > server is hosed), and it doesn't say that, although it does mention > the DIAL command in passing at one point. > My comments were in reference to version 3.14. I think you will find a lot of improvements in version 3.14 over 3.13. > If I wanted to buy the manual for a telecomm program, I'd go to my > local software store and buy Procomm. > A noble attitude. In other words, since you don't want to buy a manual, you expect real human people to work for you, for free. To develop software for you AND document it, AND answer your questions, all for free, and listen to your complaints about how they did it. Please, go buy Procomm. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!rsg1.er.usgs.gov!jobone !newsxfer.itd.umich.edu!zip.eecs.umich.edu!panix!news.mathworks.com !hookup!usc!howland.reston.ans.net!agate!dog.ee.lbl.gov!news.cs.utah.edu !cc.usu.edu!jrd Message-ID: <1994Nov10.062523.32448@cc.usu.edu> Date: 10 Nov 94 06:25:23 MDT References: <39kmo6$k82@ctsc.hkbc.hk> Organization: Utah State University From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: Can Kermit 3.14 run on PCTCP's ODIPKT In article <39kmo6$k82@ctsc.hkbc.hk>, s11976@ctsc.hkbc.hk (PM Wong) writes: > > We have been using Kermit's telnet (over either packet driver or Novell's > ODI, i.e. Da Lancinni's ODIPKT) for quite some time now. Recently some > PCTCP's apps have to be run and we want to keep the user Kermit telnet. > So it'll be handy if Kermit can run on top of PCTCP's ODIPKT > (I don't want to go for the tnglass option as batch files have been > written that use kermit's telnet all along) ---------- I replied to this privately but here is a summary. FTP Inc's ODIPKT has a license detection feature in ARP which prevents Kermit or other non-FTP program from accessing ARP packets over their ODIPKT. Both FTP's stack and Kermit will run over Harvard's ODIPKT, but never together. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com !howland.reston.ans.net!news.sprintlink.net!nwnexus!news.halcyon.com!coho!ken Date: 9 Nov 1994 19:46:33 GMT Message-ID: <39r8up$37e@news.halcyon.com> References: <39eco1$h7k@news.halcyon.com> From: ken@coho.halcyon.com (Ken Pizzini) Subject: Re: C Kermit and meta keys In article <39eco1$h7k@news.halcyon.com>, Ken Pizzini wrote: > > In article , > Jason Venner wrote: >> >>I use C-Kermit on my linux machine and dial into various unix hosts. >> >>Kermit does not seem to honor the meta key. >>Is there a way to make it recongnize 8 bit characters and pass them through >>to the remote side? > > set term byte 8 This was only a partial answer. He also needed to set command bytesize 8 --Ken Pizzini -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!gatech!howland.reston.ans.net!agate!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: C-kermit -ix and binary transfers (not working) Message-ID: <1994Nov19.182311.33328@cc.usu.edu> Date: 19 Nov 94 18:23:11 MDT References: <3am2rr$ete@vixen.cso.uiuc.edu> Distribution: usa Organization: Utah State University Lines: 34 In article <3am2rr$ete@vixen.cso.uiuc.edu>, adam@symcom.math.uiuc.edu (Adam H. Lewenberg) writes: > I am having some trouble sending binary files from the UNIX machine at > school to my OS/2 system at home. Here is what happens: > > 1. If I type kermit -ix, escape back to my OS/2 Ckermit, and then type > 'get file.zip', my OS/2 C-kermit starts receiving the file but announces > that the FILE TYPE is "TEXT (no translation)". Huh? > > 2. If I start kermit with no command line options, type > 'set file type binary' at the C-kermit prompt, type 'send file.zip', > escape back to the OS/2 C-kermit and then type 'receive' my OS/2 > C-kermit recieves the file and tells me the FILE TYPE is BINARY. > > > Why does 2 work while 1 does not? Shouldn't the '-ix' force all file > transfers to be binary? I used to have NO trouble (before I installed > the current version of the Unix C-kermit). > > The Unix C-kermit is > > C-Kermit 5A(190), 4 Oct 94, for Solaris 2.x > Copyright (C) 1985, 1994, > > while the OS/2 kermit is > > C-Kermit 5A(190) BETA.23, 18 Sep 94, for OS/2 2.11 32-bit > Numeric: 501190 ----------- I believe the release notes for C Kermit explain that the client now controls file TYPE via the SET FILE TYPE command given on the client. It's part of file attributes, named the "whatami" component, where the client informs the server of its binary/text state. It's a step forward, really. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1194 of comp.protocols.kermit.misc: Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!uwm.edu!spool.mu.edu!agate!overload.lbl.gov!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc,alt.winsock Subject: Re: winsock/pkt dvr hack possible? Message-ID: <1994Nov21.105430.33454@cc.usu.edu> Date: 21 Nov 94 10:54:30 MDT References: <3a67j8$j39@Mercury.mcs.com> <3anvci$dut@relay.tor.hookup.net> Organization: Utah State University Lines: 29 Xref: cs.utk.edu comp.protocols.kermit.misc:1194 alt.winsock:12192 In article , soren@aztec.co.za (Soren Aalto) writes: > In article <3aoc2h$bit@apakabar.cc.columbia.edu> jaltman@watsun.cc.columbia.edu (Jeffrey Altman) writes: > >>>> Jeff is correct. The top of a sockets API is a TCP stream channel of >>>>bytes, not packets. "It could be done..." means creating a second TCP/IP >>>>stack feeding from the streams channel and packaging it into TCP/IP over >>>>Ethernet frames to be passed to the application. Not very desirable, nor >>>>realistic. >>>> Joe D. > And _that_ is the real problem. I have wondered at times if the > TCP/IP stack functionality and the Comms/SLIP/PPP functionality > shouldn't be separated into two programs--you could have a > packet driver that "reflects" stuff & attach the comms driver > for SLIP/PPP/whatever to one side and Winsock to the other. ----------- Nice idea but not practical here. There are a great many coupling threads (variables, calls) between the high level and comms level material in Kermit so that control may be exercised and speed retained. And there is much more to comms than serial or the internal TCP/IP stack; SET PORT exhibits the list (and some choices transparently encompass two or three variations from the same vendor). Winsock is for pure Windows programs, not for DOS programs. MS-DOS Kermit removes itself from comms channels when done with them. Few commercial TCP/IP stacks do so (none that I know of). Were winsock guys to get off the pot when done the problem would be smaller. So please consider hounding your winsock vendor to go un-TSR upon last close and to not be present until an application makes a demand. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1176 of comp.protocols.kermit.misc: Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!library.ucla.edu!agate!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc Subject: Re: Question about ASK usage in MS-Kermit script Message-ID: <1994Nov20.184340.33391@cc.usu.edu> Date: 20 Nov 94 18:43:40 MDT References: Organization: Utah State University Lines: 23 In article , mrbaker@hodcs.ho.att.com (-M.BAKER) writes: > Hello: > > I have a question about ASK. I am writing an MS-Kermit > script which prompts > the user to enter a filename, so I "ASK" for it. No problem > there. But I would like to be able to detect if the user merely > hits the ENTER key without typing anything else in first. > > There is probably an obvious answer. I have looked all over & > experimented with no success. I am a new user of Kermit, hence I > am working from .HLP, .UPD, and .BWR while waiting for my copy > of "the book" to arrive. > > Can someone please help? (Examples appreciated) ----------- ask \%a prompt> prompt> if equ "\%a" "" echo The user did not provide text or if defined \%a echo The user did provide text and so on. Don't use {\%a} {} because they will parse out to empty, leaving if equ echo The ... which is not what is wanted. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1195 of comp.protocols.kermit.misc: Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!gatech!howland.reston.ans.net!math.ohio-state.edu!caen!hearst.acc.Virginia.EDU!murdoch!fulton.seas.Virginia.EDU!esh6h From: esh6h@fulton.seas.Virginia.EDU (Erik Hatcher) Subject: Re: Is there anyway to quit kermit without hanging up? Message-ID: Sender: usenet@murdoch.acc.Virginia.EDU Organization: University of Virginia References: <3aqkqo$6ia@apakabar.cc.columbia.edu> Date: Mon, 21 Nov 1994 21:07:34 GMT Lines: 17 In VMS you can "exit" C-Kermit and keep the modem allocated. I use the VMS ALLOCATE command and then go into Kermit and exit, then go into Kermit again and when I'm done I DEALLOCATE. Works like a charm and is extremely useful for my particular application (queuing files to send to various "nodes" but keeping the connection up in case the next file queued is for the same node!). Erik -- Erik Hatcher + "But every now and then we just have http://fulton.seas.virginia.edu/~esh6h | to howl with the wolves." | - Werner Heisenberg ---------------------------------------+------------------------------------- -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!gatech!howland.reston.ans.net!agate!dog.ee.lbl.gov !news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: Telnet Data Mark displays as "r" on MSK 3.13. Message-ID: <1994Nov21.074313.33432@cc.usu.edu> Date: 21 Nov 94 07:43:13 MDT References: <785307785snx@djwhome.demon.co.uk> Organization: Utah State University In article <785307785snx@djwhome.demon.co.uk>, david@djwhome.demon.co.uk (David Woolley) writes: > When an interrupt signal is generated on our SCO machines > (3.2V4.2), MS-Kermit (3.13, patch about 13, but there are no > obvious fixes listed up to patch 20**) displays an "r". NCSA > Telnet handles this correctly, and examining the event trace > shows that a Telnet Data Mark signal is being sent. > > This happens for both Telnet interrupts, and interrupts generated > by sending the stty interrupt character. > > This is really only a cosmetic problem, and normally results from > being too lazy to change the interrupt character or remap the > backspace key before talking to the machine in question. It > doesn't happen for SunOS 4.1.1. > > ** the patch level 20 file is at home, not in the office. -------- Data Marks are rather rare events, but you ought not have seen an "r" as a consequence. DMARK is 242 decimal, which after chopping the high bit yields 114 decimal "r". But the DMARK should have been sent as IAC DMARK (255 242), and the Kermit Telnet code would (quotes) have absorbed both bytes. If you are still reading along, the way I understand this situation is the SCO machine was trying to flush bytes sent to the MSK client, by sending IAC DMARK in a TCP segment with the TCP URGENT bit set. The recepient is supposed to discard all data up to and including the IAC DMARK. Folks have commented upon this less than clear or desirable "feature" of Telnet, and Kermit does not play that game. Just how much discarding should occur is ambiguous, and I chose not to chase down internal buffers to do the flush. In any case, the commands are really intended to be sent to servers where a job may be blocked unable to read the data stream for the Interrupt Process command pair IAC IP or similar; they ought not be sent to clients. If you still have the trace I'd appreciate receiving a copy. Thanks, Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1265 of comp.protocols.kermit.misc: Path: cs.utk.edu!gatech!bloom-beacon.mit.edu!panix!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: Kermit AS400 implementation ??? Date: 28 Nov 1994 14:02:12 GMT Organization: Columbia University Lines: 27 Message-ID: <3bcnt4$6v8@apakabar.cc.columbia.edu> References: <3bcfii$mgq$1@mhadf.production.compuserve.com> NNTP-Posting-Host: watsun.cc.columbia.edu Keywords: AS/400 In article <3bcfii$mgq$1@mhadf.production.compuserve.com>, Helmut Stoecklin <100303.1604@CompuServe.COM> wrote: > Is there a Kermit implementation for a IBM AS400 out in the field? > Of all the computers and operating systems in the world, there are only a couple for which nobody has ever written any Kermit software, and the AS/400 (and its predecessors, the Systems /34, /36, and /38) is one of them. Evidently this line of computers must be very hard to program; from what little I know about them, everything is "different" -- the text character set (it's not ASCII), the file system (probably record- oriented), the communication methods (some kind of bizarre proprietary "twinax" block-mode affair). But we have hurdled such obstacles before in the IBM mainframe world, thus we have the experience and know what is required. We get this question frequently, so there is definitely a big demand. But we do not have an AS/400 ourselves for development, and even if we did, we don't have a programmer to do the work. Back in the early days of the Kermit project, there were dozens of sites developing Kermit software for every imagineable platform. Maybe it's time to revive that early spirit. Anybody who is seriously interested in developing a Kermit program for the AS/400 (or porting an existing program, such as C-Kermit) should contact me. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1385 of comp.protocols.kermit.misc: Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!uwm.edu!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc Subject: Re: Arcnet Packet Driver? Message-ID: <1994Dec9.112623.34998@cc.usu.edu> Date: 9 Dec 94 11:26:23 MDT References: <3c96mj$bej@cello.gina.calstate.edu> Organization: Utah State University Lines: 18 In article <3c96mj$bej@cello.gina.calstate.edu>, jpowell@cello.gina.calstate.edu (Larry Powell) writes: > Does MSkermit support the use of Arcnet packet drivers? > The reason I ask is that the docs with the packet drivers say that > to use arcnet, the client software must support it (arcnet) specifically. > They make mention of KA9Q being the only known client to support it. > I use arcnet with Novell which works fine. I also tested kermit with > the Netbios that comes with Novell (Lite) and it works also. I tried a > brief test of the packet drivers ARCNET and ARCETHER and they both failed > to initialize and/or self test. > Thanks, > --Larry Powell jpowell@cello.gina.calstate.edu, lpowell@eis.calstate.edu --------------- As the documentation says, MSK supports Ethernet (DIX/Ethernet_II/ BlueBook) and SLIP Packet Drivers, as well as working directly over ODI for these and other lan topologies. Be sure to use MSK 3.14 beta or later (when there is a later) for TCP/IP over Arcnet ODI drivers due to an ODI ambiguitity problem. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Path: cs.utk.edu!gatech!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc Subject: Re: Flow Control in MS-DOS Kermit 3.14 Message-ID: <1994Dec9.201750.35072@cc.usu.edu> Date: 9 Dec 94 20:17:50 MDT References: <3c2me7$d29@sundog.tiac.net> <1994Dec7.095922.34783@cc.usu.edu> <3c7enb$atf@sundog.tiac.net> Organization: Utah State University Lines: 53 In article <3c7enb$atf@sundog.tiac.net>, ciaraldi@max.tiac.net (Michael Ciaraldi) writes: > Dear Joe, > These (4 and 5) are two different cases, and they are different from 3. > Each may be appropriate in certain situations, and I wanted to find > out if Kermit supported them. > > Consider a VAX with a serial card that has large output buffers, as many do. > If a terminal (or Kermit emulating one) just passes through > ^S and ^Q characters (case 3), what happens when the user hits a ^S (XOFF)? > It gets sent to the host. The host CPU detects it and stops sending data. > However, there may be several thousand characters still in the > output buffer of the serial card, and there is no mechanism for the > host CPU to notify the card to stop sending. So, even though > the user has hit ^S, several more pages of data appear on the screen > and scroll off the top of the screen. I've seen this happen many times. > Fortunately, MS-DOS Kermit has a screen scrollback buffer, > but this is still a problem for most users > (those who are not using Kermit, of course). > > In case 4 and 5, when the user hits ^S, Kermit would stop sending > updates to the screen. It would just accumulate any incoming > data from the host into a buffer, then send it to the screen later > when the user hits ^Q. The difference between 4 and 5 is that > in 5 the host also gets notified, so there is a chance that the buffer > will not overflow. In the user's manual is the keyboard verb \kholdscrn. That is equivalent to DEC's HoldScreen key. Accumulating into a buffer is what triggers almost all flow control activity: it reaches a high or low water mark. For snappy flow control response reduce the capacity of the comms channel. Too much storage capacity will result in lost bytes, with no way to prevent that from occuring (except buy a faster PC). > > On case 8, I asked because I was doing some tests on Kermit > last week and found what I thought was funny behavior. > I wired my PC to a Unix machine's serial port and used > another comm program on the Unix machine to talk to that port. > The Unix machine was set for no flow control. > I gave the command SET FLOW XON to the PC Kermit, > then did a TRANSMIT. The contents of the file started > appearing in the window on my Unix machine. > Then I hit a ^S on the Unix machine. The PC kept sending the file. > Shouldn't Kermit have stopped sending the file until > it received a ^Q? I have no idea what the Unix machine actually sent, if anything. Tell MS-DOS Kermit SET DEBUG ON and enter Connect mode to debug the Unix side. MSK should respond to the XOFF, and when it has something to send while blocked it will wait about 8-10 seconds before breaking through and sending (a deadlock prevention mechanism). Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1409 of comp.protocols.kermit.misc: Path: cs.utk.edu!gatech!udel!news.mathworks.com!news.kei.com!ub!ns1.potsdam.edu!news.potsdam.edu!nelson From: nelson@crynwr.crynwr.com (Russell Nelson) Newsgroups: comp.protocols.kermit.misc Subject: Re: Arcnet Packet Driver? Date: 12 Dec 1994 04:51:44 GMT Organization: Crynwr Software Lines: 16 Message-ID: References: <3c96mj$bej@cello.gina.calstate.edu> NNTP-Posting-Host: nh2.potsdam.edu In-reply-to: jpowell@cello.gina.calstate.edu's message of 9 Dec 1994 01:06:27 -0800 In article <3c96mj$bej@cello.gina.calstate.edu> jpowell@cello.gina.calstate.edu (Larry Powell) writes: I use arcnet with Novell which works fine. I also tested kermit with the Netbios that comes with Novell (Lite) and it works also. I tried a brief test of the packet drivers ARCNET and ARCETHER and they both failed to initialize and/or self test. ARCNET won't work with Kermit. ARCETHER should. If it doesn't initialize, perhaps you used an incorrect command line? What version of ARCETHER and command line did you use? -- -russ http://www.crynwr.com/crynwr/nelson.html Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key 11 Grant St. | +1 315 268 1925 (9201 FAX) | What is thee doing about it? Potsdam, NY 13676 | What part of "Congress shall make no law" eludes Congress? -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1410 of comp.protocols.kermit.misc: Path: cs.utk.edu!gatech!newsxfer.itd.umich.edu!sol.ctr.columbia.edu!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: term type in telnet-macro (Kermit 3.14) Date: 12 Dec 1994 14:08:33 GMT Organization: Columbia University Lines: 49 Message-ID: <3chlh1$cl0@apakabar.cc.columbia.edu> References: <3bul2u$47d@infosrv.rz.unibw-muenchen.de> NNTP-Posting-Host: watsun.cc.columbia.edu In article <3bul2u$47d@infosrv.rz.unibw-muenchen.de>, Peter Schmolck wrote: >I'm using MS-Kermit 3.14 Beta-14. My UNIX-hosts do not know what to do >with "vt320", and when trying to adjust my mscustom.ini definitions I >noted an inconsistency (or bug?). ... the myhost define in mscustom.ini: > > define myhost - > telnet myhost 23 vt320,- > if success assign myhost telnet \v(session) > >set the terminal type, and not only the TELNET-negotiated "telnet >term-type" (which I rather preferred the macro to do). > Well, as the accompanying comment says, it's only a sample, which you should adjust for the host(s) you are actually using, e.g.: set telnet term-type vt220,- telnet myhost,- if success assign myhost telnet \v(session) Kermit sends its actual terminal type during TELNET negotiations UNLESS you have given a SET TELNET TERM command, which overrides the actual terminal type, but only for the purposes of telling the TELNET server what kind of terminal type you have. This is useful, for example, if Kermit's terminal type is VT320, but the host knows the same terminal by a different name, such as VT300, and does not recognize Kermit's terminal name. >When I changed the myhost define from vt320 to vt220 the result was, that -- >expectedly -- the status line entry changed to VT220, but --unexpectedly-- >the remote TELNET server still received a "VT320". (??) > I checked this just now and it didn't happen to me. Probably you just continued the same session, and the terminal type was not renegotiated? >BTW, mskermit.bwr says: "... to create an override string with command > SET TCP/IP TELNET-TERM-TYPE." >Instead this should read either "set tcp/ip term-type" or "set telnet >term-type". > You're right, we'll fix it. Thanks! - Frank x x x x x x x -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1412 of comp.protocols.kermit.misc: Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc Subject: Re: term type in telnet-macro (Kermit 3.14) Message-ID: <1994Dec12.073551.35191@cc.usu.edu> Date: 12 Dec 94 07:35:51 MDT References: <3bul2u$47d@infosrv.rz.unibw-muenchen.de> Organization: Utah State University Lines: 48 In article <3bul2u$47d@infosrv.rz.unibw-muenchen.de>, p41bsmk@kommsrv.rz.unibw-muenchen.de (Peter Schmolck) writes: > I'm using MS-Kermit 3.14 Beta-14. My UNIX-hosts do not know what to do > with "vt320", and when trying to adjust my mscustom.ini definitions I > noted an inconsistency (or bug?). > > The telnet macro in mskermit.ini: > > define TELNET - > set flow none,- > set port tcp \%1 \%2,- > pause 0, if fail end 1,- > if def \%3 set term type \%3,- > if succ c > > and accordingly the myhost define in mscustom.ini: > > define myhost - > telnet myhost 23 vt320,- > if success assign myhost telnet \v(session) > > set the terminal type, and not only the TELNET-negotiated "telnet > term-type" (which I rather preferred the macro to do). When I changed the > myhost define from vt320 to vt220 the result was, that -- expectedly -- > the status line entry changed to VT220, but --unexpectedly-- the remote > TELNET server still received a "VT320". (??) > > BTW, mskermit.bwr says: "... to create an override string with command > SET TCP/IP TELNET-TERM-TYPE." > ^^^^^^^^^^^^^^ > Instead this should read either "set tcp/ip term-type" or "set telnet > term-type". ----------- It's not your fault, it's ours. In reality the MSK command SET PORT TCP/IP acquires just two arguments: host and port number. It doesn't look for a terminal type. The way to use a different terminal type is SET TERMINAL TYPE kind or just SET TERMINAL kind. This will pass along to the host, upon request, the same terminal type spelling we see in commands. Here is the canned list, lifted from the code: "UNKNOWN","H-19","VT52","VT100","VT102","VT220","VT320", "TEK4014","VIP7809","PT200","D463","D470","wyse50","ANSI" As you point out, the program uses SET TCP/IP TERM-TYPE ident as the way to tell the host a different identication string than the default method. The docs will be modified to be clear and correct on both items. Thanks, Joe D. [ subsequent releases have added a couple more ] -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1398 of comp.protocols.kermit.misc: Path: cs.utk.edu!emory!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc,comp.protocols.ppp Subject: Re: [?] Merit PPP and MS-DOS Kermit 3.13 PL17 Message-ID: <1994Dec10.090145.35091@cc.usu.edu> Date: 10 Dec 94 09:01:45 MDT References: Organization: Utah State University Lines: 12 Xref: cs.utk.edu comp.protocols.kermit.misc:1398 comp.protocols.ppp:7928 In article , monty@indirect.com (Jim Monty) writes: > Can I run MS-DOS Kermit 3.13 over a PPP (specifically, Merit PPP) > connection? If so, how? Exactly. ----------- The indications are that "etherppp" provides an Ethernet Packet Driver interface to applications. I phrase this as indications because I've never been able to get etherppp to avoid hanging my PC as it installs itself in memory. If you get it to install cleanly then treat it as an Ethernet (which kind???, hopefully DIX/Ethernet_II/regular) Packet Driver. By default Kermit will look for a Packet Driver when its internal TCP/IP stack begins. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1405 of comp.protocols.kermit.misc: Path: cs.utk.edu!gatech!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc Subject: Re: 3.14 beta 14 and PC/TCP Message-ID: <1994Dec11.104027.35139@cc.usu.edu> Date: 11 Dec 94 10:40:27 MDT References: Organization: Utah State University Lines: 36 In article , jw@adasoft.ch (Jamie Watson) writes: > > I must be doing something wrong, but I can't figure out what... > > I am trying to use 3.14 Beta-14 with FTP Software PC/TCP 3.0 to connect > from my laptop to my Unix system. The laptop is a Toshiba 1950CS, with > a Xircom PCMCIA ethernet adapter. The Unix system is a DECsystem 5000/50, > running Ultrix 4.4. > > When I first start the system, I can reach the Ultrix system with all of > the normal PC/TCP utilities (ping, tn, rlogin, etc). I then start kermit, > and give it what I think are the minimum configuration commands to get it > working over TCP/IP: > > set tcp addr 193.72.200.10 > set tcp host 193.72.200.7 > con > > It connects, and everything seems just fine. But after I log out, and > terminate kermit, none of the PC/TCP utilities work any more! If I try > to ping the Unix system, I get "ARP failed", and nothing I have tried can > get this working again, short of rebooting the laptop. But if I start > kermit again, I can still connect to the Unix system! I'm really very > confused... -------------- The situation is easy to clarify. SET PORT TCP in Kermit means to use Kermit's internal TCP/IP stack. That stack requires either a suitable Packet Driver or ODI to talk to the lan adapter. FTP Inc's stack does more or less the same thing. You loaded FTP Inc's stack and then told Kermit to go to the same board and grab it; you are not running "over FTP Inc's stack." I'm surprized that you we able to run Kermit over the board with FTP still using all the TCP/IP material. If you want FTP Inc's stack to remain resident and run Kermit over the top of it you must use FTP's TNGLASS program, and tell Kermit SET PORT BIOS1. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1521 of comp.protocols.kermit.misc: Path: cs.utk.edu!gatech!howland.reston.ans.net!sol.ctr.columbia.edu!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: Help needed in slip setup! Date: 26 Dec 1994 17:19:49 GMT Organization: Columbia University Lines: 60 Message-ID: <3dmtvl$l5k@apakabar.cc.columbia.edu> References: <3dl8jc$54f@vixen.cso.uiuc.edu> <1994Dec25.203048.36009@cc.usu.edu> NNTP-Posting-Host: watsun.cc.columbia.edu In article <3dl8jc$54f@vixen.cso.uiuc.edu>, somebody@prairienet.org (Carlos Ramirez Pnet Admin) writes: > Hello everyone after various attempts to setup config files for using > slip especially with dns I have given up and decide to ask assistance. > Thus can someone be so kind as to mail be a sample config files for using > kermit with slip for dos. > Did you read the instructions? This is from the file NETWORKS\SETUP.DOC in the MS-DOS Kermit 3.14 Beta ZIP file: MAKING SLIP CONNECTIONS To make a SLIP (Serial Line IP) connection, follow these steps: 1. SET PORT 1 (or whichever serial port you will be using for the SLIP connection). 2. SET SPEED 19200 (or whatever speed you will be using) 3. SET FLOW RTS/CTS (or NONE) Don't use Xon/Xoff flow control on a SLIP connection! SLIP and Xon/Xoff are incompatible with each other. 4. Establish a connection to the terminal server or other device that will be providing SLIP service. Determine the IP address and other information (e.g. gateway address) that it has assigned to you. Normally, these are displayed on your screen before the terminal server enters SLIP mode. 5. Escape back to the MS-Kermit prompt and EXIT from MS-DOS Kermit. The connection is left open. 6. Start the SLIP8250 driver, telling it to use the same port (hex address and IRQ number must be supplied) and speed (decimal) used in (1) and (2) above, and to use hardware flow control (-h), for example: slip8250 0x60 -h slip 4 0x3f8 19200 7. Start MS-DOS Kermit again. Do NOT give it a SET PORT command for the serial port where SLIP is running. Instead, give the SET TCP ADDRESS, SET TCP GATEWAY, and other necessary SET TCP commands. Then, to make a connection, use SET PORT TCP
, where
is the IP hostname or address of the IP host you want to connect to. Note: Even though you might think it's silly to exit from Kermit and then start it again, when you could simply start the SLIP driver from the Kermit prompt, there is a reason: starting a driver from inside an application results in memory fragmentation. Note 2: In version 3.13 and later, it is also possible to obtain BOOTP service on a SLIP connection if your SLIP server is configured to provide it (for example, Cisco terminal servers can do this). Also, MS-DOS Kermit's SHOW COMMUNICATIONS command will display the IP address of the BOOTP server. > On a side note I have beta 13 of kermit what new since then? > Of interest to you would be an improvement in the efficiency of SLIP service, which came in Beta 16 (the current Beta). - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!emory!gatech!newsxfer.itd.umich.edu!sol.ctr.columbia.edu!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Subject: Re: Where's the last version ? Date: 2 Jan 1995 16:37:53 GMT Organization: Columbia University Lines: 58 Message-ID: <3e9a51$ft7@apakabar.cc.columbia.edu> References: <3e3pniINNped@mendel.sis.pasteur.fr> NNTP-Posting-Host: watsun.cc.columbia.edu In article <3e3pniINNped@mendel.sis.pasteur.fr>, Daniel Azuelos wrote: >Please, where's the last working version of Kermit for Mac ? > CURRENT STATE OF MACINTOSH KERMIT As of: Sat Nov 12 11:00:53 1994 *** BULLETIN *** Mac Kermit 0.991(190) dated 16 August 1994, or later, fixes the problem with downloading under newer System releases (7.1.x). Now files can be downloaded on newer systems such as Centris 660 AV with OS 7.1, Power Mac 7100/66 with OS 7.1.2, etc, without bombs or other nasty effects. It should also fix certain binary/text-mode confusion that seemed to result in corrupted files when downloading in binary mode. ***************** The last formal release of Mac Kermit was 0.9(40) in 1988. Unfortunately, it does not work very well on newer Macintoshes or Systems. However, newer versions are too big for 512K Macs or below, so you'll have to run 0.9(40) on these old models. A great deal of work has been done on the program since 1988, but the result (so far) is still not of release quality, though it is quite suitable for most purposes. The current pre-pre-release of Mac Kermit (still far from a final release) is 0.991(190), based on C-Kermit 5A(190). It is available via anonymous FTP from kermit.columbia.edu [128.59.39.2], directory kermit/f. A comprehensive user manual will be published when the final 1.0 release is complete. Sorry, I can't give any reasonable estimate about when that will be. Watch the Kermit Digest (or comp.protocols.kermit, same thing) for further announcements. You can subscribe to the Kermit Digest by sending email to LISTSERV@CUVMA.BITNET (or LISTSERV@CUVMA.CC.COLUMBIA.EDU) containing the text: SUBSCRIBE I$KERMIT your-personal-name-here Mac Kermit files, ftp from kermit.columbia.edu in text mode from the kermit/f directory: ckm190.hqx -- current prerelease of Mac Kermit in BinHex 4.0 format ckmker.doc -- user documentation for 0.9(40), the previous release (1988) ckmker.ps -- PostScript version of user documentation for 0.9(40) ckmker.bwr -- Notes about the current prerelease, FAQ's, etc ckmker.fon -- Notes about the new Mac Kermit terminal emulation font and in the kermit/charsets directory: maclatin.* -- The new Mac Kermit font itself Read the ckmker.bwr ("beware") file for further details. (End of ckmaaa.hlp) -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1566 of comp.protocols.kermit.misc: Path: cs.utk.edu!gatech!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc Subject: Re: kermit auto DL/UL! Message-ID: <1995Jan2.142944.36328@cc.usu.edu> Date: 2 Jan 95 14:29:44 MDT References: Organization: Utah State University Lines: 23 In article , jbishop@primenet.com (Jeff Bishop) writes: > After examining kermit packets closely a friend has determined two strings > that can be used to start kermit transfers automatically from {COMMO} (any > other term program for that matter). This is not using the APC logic described > in kermit.upd though. > > The two strings are: > > For upload I am using "^a# N3" download "^a5 S~". > > I have tested this and it works using msdos kermit on both sides. ----------- Only if a) Control-A is used as the start of packet character, and the checksum is correct b) this pattern can never exist in real data c) the other end is willing to send idle NAKs The S packet material is vital, is not nearly so short as you have describe, and must not be broken into pieces. Unfortunately, none of a..c is a requirement. Maybe your friend should also examine the protocol specs carefully to see the variations. In general, there is no safe pattern. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1622 of comp.protocols.kermit.misc: Path: cs.utk.edu!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!panix!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: Grabbing text from a remote session Date: 8 Jan 1995 19:16:08 GMT Organization: Columbia University Lines: 33 Message-ID: <3epdlo$232@apakabar.cc.columbia.edu> References: NNTP-Posting-Host: watsun.cc.columbia.edu In article , Erik Hatcher wrote: >I want to have C-Kermit on a VAX dial up a remote computer >and enter in a Support call for processing by our company. >The process of entering the support call generates a sequence >number for that call that needs to be given back to >our client for future reference. This sequence number just appears >on the screen when the information is being entered. > >Is there a way that I can grab this ever-changing value off the >screen some how? I was thinking that I could possibly log the >session to a file and then read it back from that file, but >I won't be in "connect" mode so "log session" would not grab >it. Is there an appropriate "log" command that I could use >to file away the remotes responses?? > There are numerous approaches, none of them pretty. You are deeply into the area we know as "screen scraping". First of all, LOG SESSION should, indeed, work during script execution, as well as in CONNECT mode. So the brute-force approach is to LOG SESSION and then grovel through the session-log file afterwards to find the sacred number, either by hand or by program. Well, if it can be done by program, that means there is some pattern that allows you to locate the number. If that is true, then you can also use INPUT or MINPUT commands in your Kermit script to locate (say) the thing that comes just before or just after the number, and then you can pull the number out of the \v(input) buffer by using string functions such as \findex(), \fsubstring(), etc, in a Kermit script program. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1630 of comp.protocols.kermit.misc: Path: cs.utk.edu!gatech!swrinde!elroy.jpl.nasa.gov!lll-winken.llnl.gov!sol.ctr.columbia.edu!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: 2 questions Date: 9 Jan 1995 13:55:38 GMT Organization: Columbia University Lines: 74 Message-ID: <3erf8q$1rl@apakabar.cc.columbia.edu> References: <3eqjo6$p9k@bingnet1.cc.binghamton.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Keywords: Initialization, Telnet In article <3eqjo6$p9k@bingnet1.cc.binghamton.edu>, wrote: >I use ms Kermit to connect via telephone modem to my university Suns. > The suns uses >c-kermit (about 2 versions back I think). >1. Every time I do file transfers I must reset several variables in >c-kermit; flow control, windows, blocks etc.. Is it possible for me >to have these commands as a script or macro in my home directory. > Yes, all of the above, as explained in the manual, "Using C-Kermit". The recommended method is to install the standard C-Kermit initialization file, .kermrc, in your home directory, and then create a .mykermrc file, also in your home directory, containing the desired customization commands. For those who don't like the standard .kermrc file (which sets up such items as your services directory, dialing directory, etc), just make a .kermrc file. >How would I tell c-kermit to use that script.? > See above. You can also tell C-Kermit to use any file at all as its initialization file, using the -y command-line option: kermit -y filename And at any time C-Kermit is showing its prompt, you can tell it to execute commands from a file: C-Kermit> take filename And you can define macros and execute them like so: C-Kermit> define fast set rec packet-length 2000, set window 4 C-Kermit> fast And you can put the macro definitions in your initialization file or any other file that you can "take". All of this is explained in the manual. >2. It has been suggested in the past that the telnet capabilites of >kermit are superior to the normal telnet. Is it possible to use those >telnet capabilties with my modem connection. I mean can I put c-kermit >into Server mode and use its telnet. Is there any possible benifit >to gained by doing this over the normal telnet capabilites that are on >the Unix system? > You mean, after dialing up to your Unix system, you want to know why you might want to use C-Kermit instead of telnet to connect to another system on the Internet? The advantages include: . Kermit is more user-friendly ("help", "?", command and filename completion, etc). . The telnet implementation works in some cases where regular telnet does not. . Kermit has scripting (automation) capability; telnet does not. . Kermit has (in the UNIX version, a limited form of) key mapping; telnet doesn't. . Kermit can convert among many different character sets, telnet can't. . Kermit has session logging, telnet doesn't. . Kermit can make 8-bit telnet connections; some telnet clients can't. . Kermit can transfer files over a telnet connection, telnet can't. The last point is important in the increasing number of cases where the telnetted-to host or service does not provide ftp; e.g. Internet BBSs, or Internet versions of commercial dialup services. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1634 of comp.protocols.kermit.misc: Path: cs.utk.edu!gatech!howland.reston.ans.net!sol.ctr.columbia.edu!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: Mac Kermit .991(190) 8bits ? Date: 10 Jan 1995 14:00:57 GMT Organization: Columbia University Lines: 30 Message-ID: <3eu3up$e8p@apakabar.cc.columbia.edu> References: <3esgd6INN4dm@mendel.sis.pasteur.fr> NNTP-Posting-Host: watsun.cc.columbia.edu In article <3esgd6INN4dm@mendel.sis.pasteur.fr>, Daniel Azuelos wrote: >When using Mac Kermit .991(190) I'd like to be able to type >8bits character, much the same way we (on this side of the planet) >are used to do it on any Mac. > >As an example, 'Alt-e e' should give an 'e acute' both on the >screen and on the host computer to which I'm connected: >displayed as é, and sent to the computer as 0xe9. > You should be able to do it. Please read the ckmker.bwr file that accompanies Mac Kermit 0.991(190). You will see there are many shortcomings in the international character-set support, but it still can be done. You have to tell Kermit (in the Terminal settings) to allow 8-bit characters, and you have to select Latin-1 as the character-set. The big problem is with entering 8-bit characters. Since Mac Kermit's font is not a regular system font, but rather a built-in one, you can't use Keycaps in the normal way, which is frustrating. Nevertheless, you should be able to enter 8-bit characters in the normal way, provided you have not done anything to the Alt (Option?) key in the Modifiers dialog of the Key Settings menu. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 104454 of comp.os.vms: Path: cs.utk.edu!gatech!howland.reston.ans.net!spool.mu.edu!uwm.edu!rutgers!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.os.vms Subject: Kermit Performance (was Re: Zmodem) Date: 8 Jan 1995 17:54:56 GMT Organization: Columbia University Lines: 147 Message-ID: <3ep8tg$qc4@apakabar.cc.columbia.edu> References: <3en6v1$eer@nyx10.cs.du.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Keywords: Kermit, C-Kermit, Zmodem In article <3en6v1$eer@nyx10.cs.du.edu>, Michael Donohue wrote: >AN earlier post said that Kermit was not entirely bad for transfering >files. I tried and tried, but the max cps I could get was 157 or so on a >9600 bps line. > >Could someone please tell me ... the settings for kermit? > I have posted the following message to this group several times -- if there is an FAQ, I hope this can be added to it. But first, a word from our sponsor. The current version of Kermit for VMS is C-Kermit 5A(190). It supersedes all previous VMS Kermit releases and programs, including all versions of Kermit-32, which is no longer supported. You can get C-Kermit 5A(190) by mail order from Columbia University, or by anonymous ftp to kermit.columbia.edu, directory kermit/f, file ckvaaaa.hlp, read it, go from there. You can also access the Kermit repository via the Web at URL: http://www.columbia.edu/kermit/ The Kermit software effort is funded primarily by mail order and book sales. Users of C-Kermit (and MS-DOS Kermit) are encouraged to purchase the appropriate manual -- it will show you how to use the software and how to get the most out of it (e.g. answering questions like the one above, so they need not be posted to dozens of newsgroups over and over and over again). If you type "help" at the C-Kermit> or MS-Kermit> prompt, you should get (among other things) a complete reference to the appropriate manual. If you want more information, access the Web site listed above or send e-mail to kermit.columbia.edu. The following message is almost a year old and discusses the previous release of C-Kermit, but aside from that, it still applies. In article gap5u@faraday.clas.virginia.edu (Gregory Perron) writes: > > I'm downloading from a vax 4000-90 thru a terminal server of some sort > to my PC. 14.4's at both ends: I have a cardinal internal; they have > us robotics. I get messages of 14.4, lapm, v.42bis, etc. But, > downloads have been hideous. > > I've given up on sz, because of too many aborted transfers. I > *think* the problem is w/ the vax, but I'm not sure. [I get flawless > 1600-1650 cps dl's on zipped files from a local bbs] Yes, I tried all > the -ebrw permutations I could think of. > > On to kermit: I use procomm plus/dos 2.01 on my PC. On the vax, > ckermit pops up and says: > Ckermit 5a(188) 23 NOV 92, OpenVMS Vax. > You'll get better results with C-Kermit 5A(189) or later, which has two new features described below. C-Kermit 5A(189) is available via anonymous ftp to kermit.columbia.edu, directory kermit/b, get the file ckvaaa.hlp, read it, take it from there. > My ckermit.ini file has: > set send pack 1000 > This command is not needed; see the documentation. > set receive pack 1000 > set buff 20000 20000 > set file type bin > set windows 10 > set block 3 > > Symptoms: max dl cps has been around 1100 for a zipped/jpg/gif file. > And that's unusual: 950-1050 is more normal. It's almost like I'm > only at 9600, modem report aside. > I can't speak for Procomm, but I ran some tests using MS-DOS Kermit 3.13 (the current version) on a 486/66 over a V.32bis/V.42/V.42bis dialup connection to a Cisco terminal server, and from there to a VAXstation 3100 running VMS 5.x and C-Kermit 5A. The calling modem is a Telebit T3000, the answering modem is a USR Courier. MS-DOS Kermit 3.13 is available via anonymous ftp to kermit.columbia.edu, directory kermit/bin, binary mode, file msvibm.zip. In these tests, I downloaded a 330K ZIP file (MSVIBM.ZIP -- the MS-DOS Kermit 3.13 distribution). My serial interface speed was 57600 bps, and I used RTS/CTS flow control between my PC and the modem, and RTS/CTS was also active between the answering modem and the terminal server. In the first test (10 window slots x 1000-byte packets, same settings as yours), I achieved an effective throughput of 1091 cps, like you got. Since the connection between the terminal server and VMS is via TCP/IP TELNET, and we know that TCP and IP will handle the flow control between the VAX and the terminal server, I told C-Kermit to SET FLOW NONE (its default setting is XON/XOFF) and ran the test again: 1136 cps. Now that we've got the basics taken care of, we can work on tuning. Next I tell C-Kermit to: SET CONTROL UNPREFIX ALL SET CONTROL PREFIX 1 129 255 (version 5A(189) or later is required for this; see the CKCKER.UPD file for explanation) -- This removes control-character prefixing overhead for all but 3 characters (4 really: NUL, Ctrl-A, Ctrl-A plus parity, and the TELNET IAC character). Now I get 1549 cps. Note: control-character unprefixing is of benefit primarily for precompressed files, secondarily for uncompressed binaries, and has very little effect at all on text files. Well, the PC I was using is one of the new "high-speed, low-cost" models, and so lacks a buffered UART. All of the above transfers suffered various amounts of retransmissions due to UART buffer overruns. Switching to a much slower PC (a PS/2-70, 15MHz I think) that has a 16550A buffered UART, same transfer, same parameters, the throughput goes up to 1601 cps. Now, since I don't have to worry about buffer overruns any more, I increase Kermit's packet length to 5000 (SET RECEIVE PACKET-LENGTH 5000). Throughput: 1608 cps. And now, since this is a precompressed file, I note that neither Kermit's run-length compression, nor the modem's V.42bis compression will do any good -- and some would say that they slow things down a lot. Let's see. I turn both off: Kermit: SET REPEAT COUNTS OFF (C-Kermit 5A(189) or later required). Modem: ATS190=0 (Telebit T3000) and download the file again. Result: 1616 cps. Not a big difference. Lessons (which apply mainly to this particular type of connection): 1. Buffered UARTs are better than nonbuffered UARTs. 2. Be sure to get the flow control at both ends. 3. Use long packets (1K - 5K, whatever works) and sliding windows (4 or more). 4. Once you've got all that working optimally, you can squeeze out another 20-30% efficiency with control-character unprefixing. 5. After that, don't bother too much with fine tuning, particularly with disabling modem or software compression - it makes very little difference. Please, before we have another flurry of postings from people asking for the "optimal" list of control characters to be unprefixed, THERE IS NONE. Every connection is different, with its own unique characteristics. Read the documentation. Ditto for all the other variables we have looked at here: window size, packet length, flow control, etc. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!cssun.mathcs.emory.edu!hobbes.cc.uga.edu !news-feed-1.peachnet.edu!news.duke.edu!convex!cs.utexas.edu !howland.reston.ans.net!gatech!newsfeed.pitt.edu!uunet !news.nyc.pipeline.com!news.cs.columbia.edu!news.columbia.edu !watsun.cc.columbia.edu!fdc Date: 11 Apr 1995 14:31:41 GMT Organization: Columbia University Message-ID: <3me3sd$cb8@apakabar.cc.columbia.edu> References: <3mbt5c$epg@cronkite.ocis.temple.edu> From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Subject: Re: Tuning Kermit In article <3mbt5c$epg@cronkite.ocis.temple.edu>, John Price wrote: : We're using kermit to do file transfers from an IBM 3090 through a Cisco : terminal server. After reading the faq, I noticed that Cisco might have : problems with tn3270 emulation, so I tried logging in to a unix machine : (system V release 3 I believe) and using it's tn3270. I get the same : throughput, at about 90 char length packets (oscilates between 89 and 90). : : When I set packet lengths above 100, i get lockup. I suspect that our : tn3270 has a maximum packet lenght around 100, which would mean 90 is about : all we could do. Any hints? : When you go through a 3270 emulator, you're at its mercy. This is a perfect example of why Kermit lets you specify the packet length, and why it uses a short default packet length. If longer packets kill the 3270 emulator, then that's all there is to it. Preliminary reports indicate that Cisco release 10.3 will let you transfer files through its 3270 emulator with packets up to about 1900 bytes in length. That's a big improvement. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!gatech!news.mathworks.com!uunet!spcuna!news.columbia.edu!watsun.cc.columbia.edu!fdc Subject: Re: Kermit MS-DOS Library... Message-ID: <3nrbo6$73r@apakabar.cc.columbia.edu> From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Date: 28 Apr 1995 18:21:58 GMT References: <3nq5ms$be8$1@mhafc.production.compuserve.com> Organization: Columbia University NNTP-Posting-Host: watsun.cc.columbia.edu Lines: 17 In article <3nq5ms$be8$1@mhafc.production.compuserve.com>, Hans Rehfeld <100125.3631@CompuServe.COM> wrote: >Is there a I/O library for MS-DOS available, which has sliding >windows implemented? If yes, where is it accessable? Is it for >free ? > If there is one, it is not from Columbia University, and it is probably not for free. For DOS, we would prefer that you use MS-DOS Kermit itself as an external protocol, which is quite simple and convenient in version 3.14 (the latest version). If this is to be included in a commercial or shareware application, you'll have to license it, just as you would have to license any commercial "comm library". The advantage of doing it this way is that you get the best Kermit implementation and at the same time you help to support the Kermit effort. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 2761 of comp.protocols.kermit.misc: Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!lll-winken.llnl.gov!hookup!solaris.cc.vt.edu!spcuna!news.columbia.edu!usenet From: fdc@fdc.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: _tid variable in OS/2 Ckermit 191 Date: 8 May 1995 13:55:19 GMT Organization: Columbia University Lines: 17 Message-ID: <3ol7s7$evg@apakabar.cc.columbia.edu> References: <1995May6.191609.9845@mercury.ncat.edu> NNTP-Posting-Host: fdc.cc.columbia.edu In article <1995May6.191609.9845@mercury.ncat.edu> hkennedy@mercury.ncat.edu writes: > I noticed a variable named _tid for setting up the terminal mode in login > scripts. However, I found no reference to this variable in the ckermit book > or in the update docs. Could someone give an example of a script using this > code. Thanks, > It's the terminal ID string that the terminal sends in response to a What Are You? query, normally ESC Z, from the host, which can vary according to terminal type. It is not actually used in any of the login scripts, but it can be. It would be particularly handy for logging in to VMS. It is not a built-in variable, but is defined in the CKERMOD.INI file. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 2866 of comp.protocols.kermit.misc: Path: cs.utk.edu!gatech!news.mathworks.com!news.kei.com!nntp.et.byu.edu!news.provo.novell.com!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc Subject: Re: Help With Underline Color! Message-ID: <1995May23.184650.52006@cc.usu.edu> Date: 23 May 95 18:46:50 MDT References: <3pta72$9s1@chopin.udel.edu> Organization: Utah State University Lines: 42 In article <3pta72$9s1@chopin.udel.edu>, darkstar@chopin.udel.edu (Jerry Alexandratos) writes: > > Okay, I tried posting this about two weeks ago, but I think it got lost > in the shuffle. > > I'm using MS-Kermit v3.14 patch level 3 to connect to a unix host. > I've got the following lines in my mscustom.ini: > > set term color 10,37,44 > set term under 1,33,44 > > So, everyone can assume that I use a blue on white screen on a vga > monitor and I want my underlined characters to be bright yellow on > blue. > > However, that's not the behavior I get from set term under. It sets > the color to yellow on blue (this means that it comes up brown looking > on blue). > > It's like it doesn't interpret the 1 at the beginning of the string. > > But here's the really unusual part. If I go back to the MS-Kermit> > prompt after I've connected and I type the command in by hand, the > colors come out as typed in! > > Am I missing something, or is this a bug in the way it's determining > the colors? ------------ It's not a bug that I know of, and it works fine here. But let me add some things to consider at your end. Intensity during terminal emulation tries to follow your DOS screen, in that a DOS bold white on blue screen shows the remote host text also bold white on blue unless the host says otherwise. That's equivalent to DEC dim white on black, or DEC "normal." If the host says do a bold operation then MSK flips intensity and you see dim but that's now DEC "bold." All this to look nice initially. So the results depend on how you got started and what the host said as well as what you said. [This reads like one of those intelligence tests where Mary is 5 years older than Jane was before Jane stopped counting.] The other mention is it could be that screen color sequencing in your startup files overrides the lines you added, so try moving yours around to double check. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 3036 of comp.protocols.kermit.misc: Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!emory!swrinde!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!lll-winken.llnl.gov!osi-east2.es.net!oracle.pnl.gov!mica.inel.gov!pmafire!mars.poci.amis.com!cwis.isu.edu!news.cc.utah.edu!news.cs.utah.edu!cc.usu.edu!jrd Newsgroups: comp.protocols.kermit.misc Subject: Re: set carrier on, server ## Message-ID: <1995Jun15.165614.54075@cc.usu.edu> From: jrd@cc.usu.edu (Joe Doupnik) Date: 15 Jun 95 16:56:14 MDT References: <3rptu3$nhr@feenix.metronet.com> Organization: Utah State University Lines: 95 In article <3rptu3$nhr@feenix.metronet.com>, brit@metronet.com (Brit Systems) writes: > I am using MS-Kermit 3.14. > > I'm running through some scenarios with > "set carrier on, server" and what happens when you loose the carrier. > > Here is what I get. > > 1) set carrier on, server, break connection, server exits Yup. The way it ought to be. > 2) set carrier on, server, start getting file, break connection, > file transfer terminates, server waits forever > (at least as long as I wanted to wait). Correct. The current session terminated. Server mode was perpetual. > 3) set carrier on, server 120, start getting file, break connection, > file transfer terminates, server waits until timeout then exits. The very last part needs improvment but basically it's ok. > 4) set carrier on, server 120, start getting very big file, > file transfer completes, server exits since it it past timeout. Yes, that's what the 120 says, be a server for that long. > Specifically on scenario 2 and 3, is this just me? > > And on a related issue. > > 1) dial someone, set carrier on, start sending file, break connection, > file transfer terminates. Yup. Correct. > 2) don't call anyone, set carrier on, start sending file, > file transfer eventually times out. Never a carrier then no CD drop state, and hence "no problem." Head scratching goes here. > It seems that only connect checks if CD before it starts. > Send, receive, remote and server don't seem to check CD when they start. > Is this right? They don't. They have no idea of the state of the comms channel so they work so long as bytes can be sent or they run out of retries. See below for more on this part. Again, modems aren't the only way of talking. > So if I want to check CD myself, what's the best way. > "wait 0 cd" seems to work but it prints and ugly "?Timeout message". > > \v(carrier) only says what you set carrier to. > > Is there a \v(cd)? I seem to have seen \CD written but don't know > how to use it. No, there isn't. Maybe there should be, but then modem comms are only one of many comms channels. In addition, testing for CD involves firing up the serial port and we may not want that to happen. > Thanks again, for the many times ya'll have helped, > Robbie Barton ---------- Let me be candid on this topic. From the beginning of MS-DOS Kermit steps were taken to ensure the program would not fail because some modem wire wasn't high or low. That philosophy has carried (sic) forward to the present. Kermit is not dependent on a modem being present and healthy. Near the release time of MSK v3.14 we had a very reasonable request to drop connections when CD vanished, and I added code to accomplish that task. We got there but just barely. For CD dropping to be a failure one must first have CD asserted, which explains your "don't call anyone" case. There's room to quibble here. From your report we see that matters are slightly muddled regarding what to do when CD drops. The principal reason for the muddle is CD is a data link item and ought not penetrate into the higher level software such as protocol stacks etc. There are many other communications pathways which do not involve CD. In addition, the Kermit file transfer stack has automatic retries on failures (from any cause, reasons for failures are normally worthless: failed is failed) and they don't know about the comms link troubles. So retries occur, and server mode is basically a loop with retries (with CD off most of the time, of course), and so on. What can we do about this? Not much right now. I'll have to do the doing in the next release and try to add CD sensitivity where possible without making a hash of the code. It won't be perfect in the sense that CD dropping kills the program in a flash, as happens to programs totally dependent on modems, but it will be better than at present. And we need to explain a little more carefully what terminating a session means versus exiting server mode completely. Thanks, Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 3040 of comp.protocols.kermit.misc: Path: cs.utk.edu!news.msfc.nasa.gov!europa.chnt.gtegsc.com!news.sprintlink.net!news.bluesky.net!solaris.cc.vt.edu!spcuna!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: Ckermit for Unix and VTKeys Date: 17 Jun 1995 15:55:58 GMT Organization: Columbia University, New York City Lines: 68 Message-ID: <3rutue$cum@apakabar.cc.columbia.edu> References: <1995Jun15.035925.13393@mercury.ncat.edu> NNTP-Posting-Host: watsun.cc.columbia.edu In article <1995Jun15.035925.13393@mercury.ncat.edu>, wrote: >I using Ckermit with Linux, and CKermit is not sending the correct key >strings for PF1 and PF2. I looked in the manual it just said make sure that >the correct emulation is in effect, and the have the key assignments >correct for VT300 emulation in the X-Term session. > >Of intereset when using "show key" the only the first part of the key >string is shown in the case of PF1 only \27 the other part is on the next >line with the Ckermit prompt. > >Is it possible to use VT key emulation in a connect session with Ckermit >for Unix (I'm using Linux). > Time to add this one to the FAQ. C-Kermit comes in basically two varieties: . The version for OS/2 that had direct access to the keyboard and screen, and therefore can see keyboard scan codes and so on, and can do true terminal emulation. Here you have comprehensive key mapping ability. . The versions for UNIX, VMS, and so on, that do not have direct access to the keyboard and screen, and rely on your console driver, terminal window, external terminal emulator (such as MS-DOS Kermit), or actual terminal to perform the terminal functions. UNIX is an interesting case. Traditionally, UNIX was accessed through a terminal that was plugged into a terminal port on a timesharing system. Thus, there *is* no keyboard and screen -- just a communication port. In recent years, this type of access has been largely replaced by terminal servers, but there is still no keyboard and screen. However, now that we have a plethora of PC-based UNIX varieties that run on workstations (PCs) that actually *do* have a keyboard and screen, it would seem to make sense that Kermit should be able to see all the keys. Unfortunately, this is not the case. Most varieties of UNIX do not let the application see the keyboard. There is no kernel function called "get keyboard scan code". There is only read(), and read() reads a character, not a multibyte scan code. Thus, even if your console driver has programmed (say) your F1 key to send (say) ESC O P, Kermit will read three characters in succession, as if they were three keystrokes, not one. It has no way of knowing that you pressed the F1 key. As far Kermit knows, you pressed the Esc key, then the O key, then the P key. Now perhaps Linux *does* have a system call to let an application at the keyboard. But... (a) In what contexts does it work? Only on the raw console? In an xterm window? etc etc. (b) Does it require special privilege to execute? (c) What about all the other versions of UNIX that run on PCs -- FreeBSD, SCO, Solaris/Intel, etc etc? (d) What about all the other versions of UNIX that run on non-PC workstations -- SunOS, Solaris/Sparc, HP-UX, AIX, SGI, etc? So the answer is, for now at least -- and as the documentation states -- C-Kermit's SET KEY command in UNIX (and VMS, AOS/VS, VOS, etc) works only for keys that generate a single 8-bit value, 0..255. Other types of mappings will have to be accomplished outside of Kermit by configuring your console driver, your xterm (e.g. with Xmodmap), and so on. I'll add this to FAQ. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 3072 of comp.protocols.kermit.misc: Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!emory!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd Newsgroups: comp.protocols.kermit.misc Subject: Re: Wyse 50 function keys Message-ID: <1995Jun22.114156.54488@cc.usu.edu> From: jrd@cc.usu.edu (Joe Doupnik) Date: 22 Jun 95 11:41:56 MDT References: Distribution: na Organization: Utah State University Lines: 11 In article , dmg@interaccess.com (Brian K. Willard) writes: > I am using kermit 3.14 for dos, connected to an rs6000. When using a vt320 > emulation and the wpunix.ini I can use my function keys in WP for AIX. When I > switch to Wyse50 emulation none of my function keys work. I need this because > our office supports many hardware platforms, and we have clients on ADDS > machines that need to use Wyse50. ------------ They are present, but not preassigned to keys. Use SET KEY and the Wyse 50 function keys are keyboard verbs \KwyseF1..\KwyseF16 plus \KwyseSF1..\KwyseSF16 (shifted Wyse function keys). Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 3594 of comp.protocols.kermit.misc: Path: cs.utk.edu!cssun.mathcs.emory.edu!atglab.bls.com!gatech!news.mathworks.com!panix!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: Pre-announcing Kermit for Windows 95 Date: 3 Sep 1995 14:55:50 GMT Organization: Columbia University Lines: 65 Message-ID: <42cflm$15a@apakabar.cc.columbia.edu> References: <425lub$4rr@apakabar.cc.columbia.edu> NNTP-Posting-Host: watsun.cc.columbia.edu In article , Rick Sladkey wrote: > I suppose it's obvious but I assume that source will not be available > for Kermit for Windows 95? > Some parts will, some parts won't. The parts that won't were all done here, at our own expense -- and that's money that must be recouped. This is not from a desire to be secretive, but rather because historically code from our software has been incorporated into hundreds of commercial and shareware programs, most often without permission. If the new Windows 95 code is of any value, and we believe it is, the same thing would happen if we made it public. Our project was not established for that purpose. > I realize you must be doing this to survive but how can you expect to > compete with communications programs that have twice the features for > half the price? > None of the communications software that has been announced for Windows 95 is less expensive than Kermit 95. Most of it is in the $129 range. For universities, our academic site licensing plan should allay all fears about cost. This was posted yesterday. > Let's say you really do come through on all of the features and the > price comes down to 20 bucks. Let's say you do survive. Is is really > worth it to give up the very thing that it is to be Kermit: free > software with source? > The world has changed since 1981. The Internet (then, the ARPAnet) was a forum for sharing and cooperation and mutual help. Now it's a hotbed of entrepreneurs who are principally concerned with how to profit from the work of others. The question is: despite all that, do people still want Kermit software? I think that millions of them do. It is up to us to figure out how to be in a position to furnish to them in the long run. > It seems better to me to throw in the towel and say it was an > experiment that didn't work than to compromise in the name of survival. > We decided not to do that. As you can see, the other Kermit software versions (MS-DOS, UNIX, VMS, IBM Mainframe, and hundreds of others) are still there. Should we shut those down too? If not, then how shall we pay for their upkeep? > Or better yet, can't you just charge for support and see how far that > gets you? It doesn't seem to me you've investigated that avenue yet. > Believe me, over the past 3 or 4 years we've investigated every option, including that one. > I am happy for you if the decision you have made makes you successful. > Every one needs a job or funding. But I think it is a sad turn of > events. > Sure it is. So is the rampant commercialization of the Internet. But that is an unstoppable force, and one which was devouring our project. Whether it is good or bad remains to be seen, but it is real, and it will change "our little world" forever in ways we can scarcely even begin to imagine. Those of you who are interested in this type of discussion are invited to read through the archives of comp.procotols.kermit.misc, comp.os.vms, comp.dcom.modems, and many other forums in which it has taken place at great length over the past two or three years. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc Subject: Re: MS-Kermit 3.14 - Problem with Wyse-50 Emulation Message-ID: <1995Sep14.212654.61352@cc.usu.edu> Date: 14 Sep 95 21:26:53 MDT References: <811093642@gkja> Organization: Utah State University Lines: 36 In article <811093642@gkja>, Graham Jenkins writes: > One of our Applications suppliers is using sequences as shown in > the example below for marking screen-areas to stand out. > Unfortunately, the "revert-to-normal" bit doesn't work quite the > same under KERMITE (mid-95 3.14 release) with a Wyse50 emulation > as it does on a real Wyse50. Is there perhaps a patch for this? > > --- > #!/bin/sh > # wy50test.sh Tests screen feature escape codes for Wyse-50 with > # MSKermit-3.14 (mid-'95 release, kermite). > > # Sledgehammer reset > echo "\0033(\0033\`A\0033A00-NORMAL\c" > sleep 3 > > # Standout (Reverse character protect, write protect) > echo "\0033\`6\0033)-STANDOUT\c" > sleep 3 > > # Normal > echo "\0033(-NORMAL\c" > sleep 3 > > # Sledgehammer reset > echo "\0033(\0033\`A\0033A00-END" > exit 0 ----------- Yes, this is a genuine bug, sigh. It turns out that fixing it is something of a chore deep in the code because of the way sundry video attributes are munged (changed) by the ESC ` sequence. I'll have this fixed in the next release, as they say, because it is turning out to be too complicated to generate as a Patch file item. I have a real Wyse-50 to help decode the affair. Thanks, Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: utkcs2!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!news.cse.psu.edu !rutgers!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Date: 26 Jun 1996 19:16:49 GMT Organization: Columbia University Message-ID: <4qs2b1$28v@apakabar.cc.columbia.edu> Subject: Re: K95 wyse60 emulation soon? In article <4qrsbc$mrm@samba.rahul.net>, Clarence Dold wrote: : Robert J. Strickler (bstrickl@thrunet.net) wrote: : : We have a client that is currently using w3.1 and procomm with wyse60 : : emulation, the accounting system has been modified to generally expect the : : wyse60 and it looks to be expensive to unmodify it to a more generic vt100 : : expectation. They would like to move about 25 workstations to w95 and a 95 : : terminal emulator. K95 looks like a great fit except that it needs this : : emulation. Any estimates on the availability? : : You don't mention what kind of connection you are using. : I used MSKermit under Win95 for dialup access for a while, until I got K95. : If you need TCP connectivity that would be a different story, but the serial : portion of MSK 3.14 worked fine. But MS-DOS Kermit does not include Wyse60 emulation, only Wyse50, which is different. Kermit 95 1.1.5 will emulate Wyse 30, 50, 60, and 370. -- fdc -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.announce,comp.protocols.kermit.misc Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!cssun.mathcs.emory.edu !swrinde!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!chi-news.cic.net !newsfeed.internetmci.com!news.sprintlink.net!in1.uu.net!panix !news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Organization: Columbia University Approved: fdc@columbia.edu Date: 23 Oct 1995 20:15:15 GMT Message-ID: <46gt4j$jpl@apakabar.cc.columbia.edu> Subject: New Kermit Tech Support Policies This is to announce new technical support policies for Kermit software. Effective immediately, but with a grace period extending through November 30, 1995: . Phone support may be obtained by calling +1 (900) 555-5595. Presently, this number is available only to those calling from within the USA. Calls to this number cost $2.50 per minute. . Phone support may be also be obtained by calling +1 (212) 854-5126. This number may be called from anywhere in the world. The cost of each call is $25.00, chargeable to your MasterCard or Visa account. . Phone support is available at no charge to tech-support liaisons at sites that have purchased site licenses or bulk right-to-copy licenses. The number is +1 (212) 854-5126; a bulk or site license serial number is required. (Note: this category presently applies only to Kermit 95) Technical support is also available at no direct charge as follows: . On the Web. Point your Web browser at http://www.columbia.edu/kermit/ and look through the Kermit FAQ and other topic areas. . By netnews. Read and post questions to comp.protocols.kermit.misc. Members of the Kermit team will respond to questions on a best-effort basis. Others may also respond. . By email to kermit-support@columbia.edu. Members of the Kermit team will respond to questions on a best-effort basis. Why the new policy? Simple: One-on-one telephone support is costly and inefficient, and the demand for it has been skyrocketing in recent years. Charging for this service will allow us to expand it to keep pace with demand. You may begin using the 900 number right away. Callers to 854-5126 will be informed that this service will no longer be free after November 30. Thank you for helping us to serve you better! Frank da Cruz and Christine M. Gianone Managers, the Kermit Project Columbia University -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 3959 of comp.protocols.kermit.misc: Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!cssun.mathcs.emory.edu!swrinde!tank.news.pipex.net!pipex!news.mathworks.com!newsfeed.internetmci.com!chi-news.cic.net!news.wctc.net!spcuna!news.columbia.edu!watsun.cc.columbia.edu!fdc Newsgroups: comp.protocols.kermit.misc Subject: Re: how to get DOS kermit c source code? Message-ID: <46jurh$c8l@apakabar.cc.columbia.edu> From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Date: 25 Oct 1995 00:02:57 GMT References: <45pk9f$so3@info.bta.net.cn> <4672ol$pak@Venus.mcs.com> <1995Oct20.092232.64321@cc.usu.edu> <46hf3j$li3@Mercury.mcs.com> Organization: Columbia University NNTP-Posting-Host: watsun.cc.columbia.edu Lines: 28 In article <46hf3j$li3@Mercury.mcs.com>, Leslie Mikesell wrote: >... >What I'm saying is that Berkeley copyrighted code has found it's way >into almost everything, and has helped a lot of people. There is >room for freeBSD, BSDI, and things like 'slirp', a slip/ppp emulation >that is basically a full tcp/ip implementation running in user >space that would never have happened if the base code had been >restricted. Once upon a time I thought that was the philosopy >behind kermit too. > > It was, but times changed. I think you are missing the difference between the Kermit project and various other projects on the net that you associate with "free software". The difference is: we are working on this full time, and with some of us, it is our real job -- even our career. We are here for the long haul, as long as there is a demand, to develop and support Kermit protocol and software. You can't say that about most of the other software that you cite. The BSD project is shut down, the people scattered to the wind. Many of the other examples are one-shot deals -- the people who created them moved on to something else -- you can't get good, dependable support for that type of software. You can for Kermit. By the way, if you or anybody else wants to contribute code, make improvements, etc, nothing is stopping you. But you have to leave administration of our copyright up to us, because long after you have moved on to something else, we will still need to be here. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 4318 of comp.protocols.kermit.misc: Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!usc!chi-news.cic.net!news.wctc.net!spcuna!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: Caps-Lock Problem with K95 Date: 12 Dec 1995 13:32:13 GMT Organization: Columbia University Lines: 15 Message-ID: <4ak08t$850@apakabar.cc.columbia.edu> References: <30cc57f7.3760203@news.sccsi.com> NNTP-Posting-Host: watsun.cc.columbia.edu In article <30cc57f7.3760203@news.sccsi.com>, Joe Winett wrote: > Has anyone had weird problems with Upper and Lower case in K95? > Sometimes it's like Kermit is in CapsLock, but all keys are really > shifted -- 'a' sends 'A' and '7' sends '&', etc... > This is a bug in the Windows 95 console driver. Caps Lock acts like Shift Lock for 32-bit console applications that read scan codes (not just characters). Hopefully Microsoft will fix it. There is no way to fix it in Kermit, as it stands, because the characters you see are the ones that Windows is reporting. We are working to convert Kermit 95 to a full GUI, non-console application, and that will avoid the problem by not using Microsoft's console driver any more. Watch this space for announcements. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 4341 of comp.protocols.kermit.misc: Path: cs.utk.edu!cssun.mathcs.emory.edu!swrinde!newsfeed.internetmci.com!in1.uu.net!news.new-york.net!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: Unix WordPerfect and MSKerm3.14 Date: 19 Dec 1995 14:52:05 GMT Organization: Columbia University Lines: 52 Message-ID: <4b6jil$6l7@apakabar.cc.columbia.edu> References: <95352.095758U54294@uicvm.uic.edu> NNTP-Posting-Host: watsun.cc.columbia.edu In article <95352.095758U54294@uicvm.uic.edu>, wrote: > Following the instructions in KERMIT.BWR got my WordPerfect 5.1 on > SCO SV386 3.2v4.1 running smoothly. BUT...can someone tell me why > removing the VT320 reset from WordPerfect's terminal initialization > string should keep MS-Kermit 3.14 from switching character-writing > direction? (This was my symptom, anyway). > Our first attempt, circa 1990, at implementing a mechanism by which the host could control the terminal emulator was the "TERMINALR/TERMINALS" macros, which could be invoked by a high-numbered escape sequence we thought would be safe: ESC [ 34 h / l Before choosing this sequence we not only researched the DEC technical manuals, but also made numerous frustrating attempts to contact the authority within DEC that was in charge of assigning new escape sequences to ensure that DEC did not have any plans for this one, and request that they reserve it for us. We were never able to locate the right people. So, perhaps unwisely, we went forward with this feature, and the UNIX and VMS WordPerfect used this feature heavily to dynamically switch key maps. As luck (or Murphy's Law) would have it, DEC subsequently picked this same sequence to control screen-writing direction in its Hebrew-model terminals, and later this sequence found its way into many applications that had nothing to do with Hebrew, as a standard part of the terminal initialization. Soon, users of diverse VMS applications such as DECnotes, All-In-1, etc, began to report that whenever they started up these applications, strange things would happen: a file would begin to transfer, their key map would change, etc. In fact, these were the actions defined in their TERMINALR macros. So we had to give up on the TERMINALS/TERMINALR mechanism in version 3.14 and adopted the far more flexible APC mechanism, and changed Kermit to treat the former TERMINALS/R escape sequence as a screen-writing direction changer. So now users of the "old" WordPerfect and the new Kermit were in for a new surprise -- their screens would come out backwards! In short, both Kermit and WordPerfect had to be changed to get around the conflict between the two uses for the same escape sequence. The tale is told in the KERMIT.BWR file for version 3.14, in the Incompatibilities section, and the new APC mechanism is documented in the KERMIT.UPD file, Section 10. > Incidentally, for the umpteenth time, thanks to da Cruz, > Gianone, Doupnik and the cast of thousands who made Kermit. > On behalf of all of us, you're very welcome! - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 4408 of comp.protocols.kermit.misc: Path: cs.utk.edu!willis.cis.uab.edu!nntp.msstate.edu!cssun.mathcs.emory.edu!swrinde!news-relay.us.dell.com!natinst.com!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc Subject: Re: The Future (was Re: Connecting to the Same Site Multiple Times) Message-ID: <1995Dec29.173301.70177@cc.usu.edu> Date: 29 Dec 95 17:33:01 MDT References: <4bcrfp$lvh@piano.synapse.net> <4bt2qs$ap@gaia.ns.utk.edu> <4c1kem$j5r@huron.eel.ufl.edu> Organization: Utah State University Lines: 108 In article <4c1kem$j5r@huron.eel.ufl.edu>, afn10375@afn.org (David A. Johns) writes: > Joe Doupnik (jrd@cc.usu.edu) wrote: > > # > Out of curiosity, do any of these priorities involve > # > MSDOS-Kermit, or has development on that platform essentially > # > stopped? > # ----------- > # I hope you favor dogs rather than cats, given what > # curiosity does. Just what is it that you need? That's quite a wish-list David, and a couple days after the official due-date! But let me add a few comments on the items as we talk here on News. > Well, I think my vote would go for more functionality in the > scrollback buffers (mark and save, search, buffer input while viewing > the buffer, etc.) and a real plain-text session log (and yes, I have > read the .bwr). I guess you mean full editing, and hence a reasonably competant full screen editor to match. That's quite a bit of code, and any editor would have to work by shutting off comms so that screen and keys remain strictly local. Also the scroll back buffer normally lives above 1MB, in expanded memory. That means the editor needs spill buffers up there too to handle the large rollback buffers permitted by MSK. I think its easy to see that this can get out of hand. The session log is plain-text if that's all the host sends to us. Which means it sends a line of text followed by CR/LF, and no cursor steering, screen embellishments (bold, reverse video, etc), whatnot that make up full screen work rather than glass-tty work. Otherwise our screen is likely decorated semi-randomly as the cursor is moved here and there, and thus what we see isn't the way things arrive or logged. > I'd also like to see a way to preserve the scrollback buffer when > logging out of a TCP session. It is preserved, actually. But to see it we must be in terminal emulation mode where the character sets and visual attributes are available. It is available when a new session is started, or when we rollback during another session. > A nice addition to the script language would be a handful of > user-defined string triggers, like the string that starts automatic > ZModem downloads in programs that have that (I think NetTerm, a > winsock program, also watches for the KERMIT READY TO SEND signal and > starts a download hands-off). We've thought about these too. It might help to understand how matters work. Triggers require that MSK buffer bytes entering the terminal emulator, do not act on them, and do parsing of the accumulated stream as each byte arrives. MSK does this for host-triggered printing, and for the APC command. Those commands are well structured, short, and unambiguous (not overlapping any other acceptable commands). So, accumulation/constant reparsing without display and hence bursty screen updates (if any sometimes) turns out to be not what people would accept, nor would I for that matter. We put a lot of thought into the security side too. Whatever happens must be safe and under control of the user; no launch and forget strategy. That means we don't launch external programs based on arbitrary strings arriving. Not only do such strings happen in other circumstances (rather like the Hayes triple + syndrome) but the consequences may not be what the user can live with. > Someone else has just mentioned having full access to the input > buffer. I managed to use \v(input) to get the IP address on a SLIP > line (thus fully automating the process you outline in the network > docs), but I can imagine it would be nice to be able to work with more > than one line. As mentioned previously, a succession of INPUT statements can gather a succession of "lines", so that facility exists now. > It would be nice to have input that comes in while at the command > prompt (like when a macro is running or during a transmit) piped back > into the emulator so that they end up in the log and the buffer. You have a point. It's not possible presently. I should caution that INPUT is not always running and hence there are gaps in the INPUT buffer stream, and that stream wraps in its circular buffer. INPUT material does go into the session log. > Right now if you call MSK from another program it can read the port > speed, but not the parity. I have one system I call that uses 7o1 > (yes, odd parity), so in order to write general transfer scripts (in > Commo's macro language), I have to parse out the parity and send it to > Kermit. Since DOS reports the parity (with MODE and MSD, at least), > it seems that Kermit should be able to read it. ? MSK does not run UART chips with hardware parity. Hardware parity is a nice way of not communicating due to differences at each end. MSK uses parity in software and it is highly forgiving during terminal emulation (SET DISPLAY 7/8 etc). Furthermore, during file transfers MSK automatically determines parity as much as is possible, and switches to it with a message. I can add code to probe the UART for existing parity, if that would really do a lot of good. > By the way, I use Commo, calling Kermit for special purposes rather > than using Kermit for everything primarily because of the first three > suggestions above. > > I could probably think of more if you're interested. Wishlists are always welcomed, even though only portions are possible to include in the programs. > David Johns Thanks David, Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 4472 of comp.protocols.kermit.misc: Path: cs.utk.edu!cssun.mathcs.emory.edu!gatech!newsfeed.internetmci.com!howland.reston.ans.net!torn!news.ccs.queensu.ca!news.ccs.queensu.ca!not-for-mail From: mike@ccs.queensu.ca (Mike Smith) Newsgroups: comp.protocols.kermit.misc Subject: Re: 2 PCs directly linked? Date: 12 Jan 1996 08:54:55 -0500 Organization: Queen's University, Kingston Lines: 33 Sender: mike@post.queensu.ca Message-ID: <4d5p7f$dmj@ccs-sparc2.queensu.ca> References: <4d3i3q$nn0@n.ruf.uni-freiburg.de> <4d4bgc$59o@apakabar.cc.columbia.edu> <4d5fj6$jfk@huron.eel.ufl.edu> NNTP-Posting-Host: ccs-sparc2.ccs In article <4d5fj6$jfk@huron.eel.ufl.edu>, djohns@freenet4.freenet.ufl.edu (David A. Johns) writes: |> I know Kermit can do almost anything, but this seems like overkill to |> me. If the machines are close enough to use a null modem, the obvious |> answer isn't a terminal program, but the Interlink program that comes |> with DOS. With that program you can not only send directory |> structures (with xcopy), but you can also zip files from one machine |> into an archive on the other, use the DOS replace program to update or |> freshen files, etc., etc. The DOS help file under intersvr.exe even |> describes how to transfer the server files from one machine to the |> other without needing disks. |> |> David Johns Maybe. Maybe not. I tried to set up Interlink for a friend who wanted to move stuff from his laptop to his desktop. He lives in another city and didn't forewarn me I would be consulting during my visit. :-) Anyhow, whether it was ignorance on my part or something odd about Interlink running bwtween his two particular machines, the file transfers were unbearably slow. Fortunately we had access to the net and pulled down a copy of MSK. It worked beautifully. And I discovered something that surprised me--there was a dramatic improvement in file transfer speed when the server was the old laptop rather than the new desktop. This is contrary to Frank's advice so perhaps my memory is wrong. However, it is definitely worth testing both possibilities on your equipment. In our case, the change improved file transfer speed from 3,700 to 10,000 cps. Which is kind of "Wow!" when you see it happen. -- Mike Smith mike@ccs.queensu.ca Queen's University Michael.D.Smith@QueensU.CA Computing and Communications Services (613) 545-2024 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 4555 of comp.protocols.kermit.misc: Path: cs.utk.edu!news.msfc.nasa.gov!news.ingr.com!news.internetMCI.com!newsfeed.internetmci.com!chi-news.cic.net!usc!ccnet.com!rahul.net!a2i!dold.a2i!dold From: Clarence Dold Newsgroups: comp.protocols.kermit.misc Subject: Re: K95: Caps Lock affects number keys Date: 29 Jan 1996 05:54:09 GMT Organization: a2i network Lines: 28 Message-ID: <4ehne1$33b@hustle.rahul.net> References: <310c534e.104050636@news.aus.sig.net> NNTP-Posting-Host: foxtrot.rahul.net NNTP-Posting-User: dold Ami Bar-Yadin (ami@sig.net) wrote: : I use K95 to dial in to my office's computer, and was using an old : program which requires it's menu selections to be entered in upper : case, so I pressed CAPS LOCK on my keyboard. When I needed to enter : some dates, I used the number keys on the main keyboard (not the : numeric pad) and got the symbols instead of digits, ie ")!@#(%" : instead of "012395". From the file "bugs.doc", in the K95 distribution: .6. Keyboard Scan Codes (M) . .Certain keyboard scan codes, constructed by Kermit 95 from information .reported by Windows, are inconsistent between Windows NT and Windows 95. .These include Num Lock and Numeric Keypad /. . .More seriously, Windows 95 returns returns the shifted version of .non-alphabetic characters when Caps Lock is on; for example, if you press .the "2" key on a USA keyboard with Caps Lock on, you get "@" instead of "2". .This is a Window 95 bug. The same code under Windows NT returns the correct .values. This bug doesn't seem to affect Notepad.exe or MSDOS windows. -- --- Clarence A Dold - dold@rahul.net - Pope Valley & Napa CA. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 4564 of comp.protocols.kermit.misc: Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!chi-news.cic.net!newsfeed.internetmci.com!panix!news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: MSDOS C-Kermit 3.14 Keyboard ScanCodes Date: 30 Jan 1996 15:17:04 GMT Organization: Columbia University Lines: 18 Message-ID: <4elcpg$9hd@banzai.cc.columbia.edu> References: NNTP-Posting-Host: watsun.cc.columbia.edu In article , Vladimir Alexiev wrote: : (Frank, if you think this is useful, feel free to put it in the : distribution.) : : MSDOS C-Kermit 3.14 Keyboard ScanCodes for 88-keyboard (decimal). : Please send additions (especially 101-keyboard codes) and corrections : to vladimir@cs.ualberta.ca. 29 Jan 1996 : : key norm shft ctrl c+s alt s+a c+a c+s+a : --------- ---- ---- ---- ---- ---- ---- ---- ---- : Space 313 825 1337 1849 2361 2873 3385 3897 : Thank you, Vladimir. In fact, this table already appears in "Using MS-DOS Kermit" (and its translations), and it is also online in the archive as kermit/a/msvibm.key, dating from 1989. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 4570 of comp.protocols.kermit.misc: Path: cs.utk.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!inet-nntp-gw-1.us.oracle.com!news.caldera.com!news.cc.utah.edu!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc Subject: Re: K95 emacs.ini doesn't map Alt as Meta Message-ID: <1996Jan30.090609.72706@cc.usu.edu> Date: 30 Jan 96 09:06:09 MDT References: <4e62gs$63d@apakabar.cc.columbia.edu> Organization: Utah State University Lines: 16 In article , Vladimir Alexiev writes: > In article <4e62gs$63d@apakabar.cc.columbia.edu> jaltman@watsun.cc.columbia.edu (Jeffrey Altman) writes: > >> Ctrl-Space. >> SET KEY \1056 \Knull > > 1056? On my keyboard it's 1337! (IBM XT 84 keys, DOS 3.1, MS-Kermit 3.14). > And I just posted a list of all the scancodes... I guess it won't be very > useful then :-( ---------- Whoa! MS-DOS Kermit deals with keyboards by reading what the Bios reports. It does not have a canned list of every "scan code" in the program. And it's not C Kermit but MS-DOS Kermit (no relation). You have just demonstrated the failure of the canned table approach, and the success of the MS-DOS Kermit approach. Machines can and will differ. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1755 of comp.sys.stratus: Path: cs.utk.edu!not-for-mail From: shuford@cs.utk.edu (Richard Shuford) Newsgroups: comp.terminals,comp.os.msdos.apps,comp.os.msdos.mail-news,comp.protocols.kermit.misc,comp.sys.stratus Subject: Monty Python, Flying Sheep, and Kermit (was Re: Searching Terminal for XT-PC) Followup-To: comp.protocols.kermit.misc Date: 2 Feb 1996 16:54:06 -0500 Organization: University of Tennessee, Knoxville--Dept. of Computer Science Lines: 67 Distribution: world Expires: 30 Mar 1996 22:11:22 EST Message-ID: <4eu15uINN4ad@duncan.cs.utk.edu> References: <4e3uol$jur@news.rhrz.uni-bonn.de> <4eivvv$4q2@news1.wing.net> <4erosl$9mr@sun001.spd.dsccc.com> NNTP-Posting-Host: duncan.cs.utk.edu Summary: modern Kermit implmentations can be fast Keywords: Kermit, terminal, protocol Xref: cs.utk.edu comp.terminals:5375 comp.os.msdos.apps:27952 comp.os.msdos.mail-news:4867 comp.protocols.kermit.misc:4579 comp.sys.stratus:1755 In article <4erosl$9mr@sun001.spd.dsccc.com>, jmccarty@spd.dsccc.com (Mike McCarty) writes: > >>)Axel Schneider (schneid2@zeus.informatik.uni-bonn.de) wrote: >): >): I am looking for a terminal program, that is suitable for an XT >): IMB-compatible PC, can run under DOS 3.0 and fits on a 360kB Floppy >): Disk (no harddisk available). > > Kermit is okay if all you ever want to do is pretend to be a terminal. > But if you want to do general communications, it is terrible. File > down/upload are quite slow. Monty Python's Flying Circus once did a sketch about Flying Sheep. One character observed, "Notice that they do not so much fly as plummet." The old farmer leaned on his fence and explained, "Sheep are dim. Once they get an idea into their heads, there's no shifting it." A similar case has arisen with popular opinion concerning the Kermit file-transfer protocol. Unless you are a sheep (or a technical writer for a modem vendor), remember this: If you use Kermit correctly, it ain't necessarily slow. With a correctly done implementations of the modern Kermit protocol in place on BOTH ends of the connection, with both client and server given appropriate setup commands, Kermit transfers can be as fast as your modem will run. Three things contribute to the misconception: (1) Many host-system administrators have failed to install a new version of Kermit on their systems in the last 10 years. The older programs may not have support for long packets and sliding windows--the modern protocol features which increase speed. (2) The default tuning parameters are conservative, in the sense of wanting to make certain that SOME data transfer happens, even if slowly, despite possibly hostile communication conditions. Whereas other popular protocols take the attitude, "If I can't go fast, I won't go at all." (3) The instruction books for most new modems assert, with no reasons given, that "Kermit is slow". The writers, we assume, are not aware of issues (1) and (2). I'm typing this using MS-Kermit 3.14, the most recent Kermit program by Joe Doupnik for MS-DOS. It performs an excellent emulation of a DEC VT320 terminal and performs the Kermit file-transfer protocol with the speed-enhancing long packets, sliding windows, and prefix control. (And it fits on a floppy disk.) The latest C-Kermit program, by many authors, is available for many systems, including those running UNIX, VMS, AOS/VS, OS/2, or Stratus VOS, and also implements those features. The World Wide Web site for Kermit is entered by this URL: http://www.columbia.edu/kermit/ and performance issues are discussed in this section: -- ...Richard S. Shuford | "Plans fail for lack of counsel, ...shuford@cs.utk.edu | but with many advisers they succeed." ...Info-Stratus contact| Proverbs 15:22 NIV -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!gatech!newsfeed.internetmci.com!panix!usenet From: bsd@panix.com (Brian Downing) Subject: Re: K95 emacs.ini doesn't map Alt as Meta Date: 27 Jan 1996 11:40:43 -0500 Organization: PANIX Public Access Internet and UNIX, NYC Lines: 27 Sender: bsd@panix.com Message-ID: References: <4e62gs$63d@apakabar.cc.columbia.edu> NNTP-Posting-Host: panix.com In-reply-to: bsd@panix.com's message of 27 Jan 1996 08:39:08 -0500 To: bsd@panix.com (Brian Downing) X-Newsreader: Gnus v5.0.13 In article bsd@panix.com I wrote: ;from emacs.ini set key \2168 \27x ; Alt-x set key \2168 \27y ; Alt-x ;should be set key \2168 \27x ; Alt-x set key \2169 \27y ; Alt-x Obviously I meant ;from emacs.ini set key \2168 \27x ; Alt-x set key \2168 \27y ; Alt-y ;should be set key \2168 \27x ; Alt-x set key \2169 \27y ; Alt-y I didn't cut and paste from window to window so I messed up the comments when I typed and then cut/paste w/emacs. -- [ Brian Downing ] [ bsd@panix.com ] [ '95 VFR750F ] -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 4613 of comp.protocols.kermit.misc: Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!newsfeed.internetmci.com!inet-nntp-gw-1.us.oracle.com!news.caldera.com!news.cc.utah.edu!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc Subject: Re: bugs in Ckermit and Mskermit vt100 mode Message-ID: <1996Feb9.064844.73658@cc.usu.edu> Date: 9 Feb 96 06:48:43 MDT References: <4fe3po$1gr@bignews.shef.ac.uk> Organization: Utah State University Lines: 17 > > 2) With MsKermit 3.14 for DOS with input echo on in an automated > login sequence, the vt100 initialization string returned by tset > (?) will result in the screen being switched to 40 column mode. > This happens with the termcap/terminfo supplied with SCO UNIX ODT > 3.0. This does happen for logins done by hand. The > problem appears only with