Copyright 1994-2016 by Kevin G. Barkes All rights reserved. This article may be duplicated or redistributed provided no alterations of any kind are made to this file. This edition of DCL Dialogue is sponsored by Networking Dynamics, developers and marketers of productivity software for OpenVMS systems. Contact our website www.networkingdynamics.com to download free demos of our software and see how you will save time, money and raise productivity! Be sure to mention DCL Dialogue! DCL Dialogue Originally published January, 1994 It's Not Easy Being Green By Kevin G. Barkes Ask someone what they know about Kermit, the ubiquitous file transfer program named after the greenish Muppet character, and you'll probably hear things like it's an old mainframe file transfer protocol, that it's slow, and that it will talk to just about anything with a serial port. Such is life when you work in an obscure little office on the outskirts of the Columbia University campus in Manhattan, with a handful of people and no marketing or advertising budget. The truth of the matter is Kermit is a big-time, full-featured comunnications program. More than just a file transfer protocol, Kermit (especially MS-Kermit for PCs and C-Kermit for OpenVMS) offers the fastest file transfer rates available, superb terminal emulation, automatic international character set translation, Pathworks, TCP/IP and other local area network support, key mapping, scripting, and a host of other advanced characteristics. For example, the latest OpenVMS version of C-Kermit has a marvelous feature: complete support for all OpenVMS file types. By using the SET FILE TYPE LABELED option, C-Kermit can transfer any file type between OpenVMS systems, including .obj, .exe, .tlb, backup savesets and even indexed files. This means no more trying to figure out file type commands, using copy/overlay or fiddling with file headers to get a file back to its original condition. To send a whole directory of various file types, just throw the remote C-Kermit into server mode and issue a wildcard SEND *.*. The latest version of MS-Kermit supports the labeled file type as well, so you can transfer stuff from an OpenVMS system to a PC and then on to another OpenVMS system. I transfer as much as 3-5mb of data a day between VAXes and PCs with automated Kermit procedures, and I couldn't live without it. Kudos to Terry Kennedy of St. Peter's College, the primary developer of OpenVMS C-Kermit, for a great piece of software. As for the misconceptions: 1. It's an old mainframe file transfer protocol. Kermit made a big impact on the mainframe world and gained a lot of fame from the fact it can work on systems with only a 7-bit data path, which is common is such installations. But there are literally hundreds of versions of Kermit which run on just about any computer system ever made. The joke that it can talk to a toaster with a serial port is only mild exaggeration. 2. It's slow. This misconception remains due to several factors. Many people have older versions of Kermit which supported only the original small packet transfers of less than 100 bytes. Kermit-32 for VMS, for example, is still widely distributed despite the fact it is ancient and hasn't been updated in ages. C-Kermit is the standard for OpenVMS systems these days, and its performance and features are impressive. C-Kermit has large packet sizes, sliding windows and data compression which can greatly enhance throughput. Problem is, C-Kermit, when used in its default mode, is sort of like OpenVMS BACKUP. The default BACKUP settings result in optimum data safety but consume more tape and time. Similarly, C-Kermit "out of the box" uses few of its advanced features. It assumes ultra-conservative settings to insure accurate data transfer in worst-case conditions. Under normal circumstances, though, you can dial in large packets, sliding windows and other advanced features to get Kermit cranking. C-Kermit can easily meet or exceed the performance of Zmodem, the most widely used protocol on bulletin board systems and PC communications software. Then why do the versions of Kermit on many BBS systems not support the new Kermit features? Simple economics. Because Columbia University prohibits vendors from making a profit from selling Kermit, there's little incentive to include it or update it to the latest spec. And in the MS-DOS arena, MS-Kermit's features usually beat most commercial terminal emulation/file transfer packages, at least on a price/performance basis. (Update: visit http://www.columbia.edu/kermit for the latest Kermit info.) While Kermit is available free from a number of sources, the best place to get it is directly from Columbia University. As Kermit creator Frank da Cruz points out, folk who purchase direct from Columbia will get "up-to-date, complete, untampered-with, and fully documented versions, and we get some income in proportion to usage, which is what allows us to continue our development and technical support efforts." Fully documented are the key words here. Many distributions of Kermit lack any doc, so users unfairly judge the program's performance based on its default settings. If you have a copy of C-Kermit around, type HELP and follow the directions. Better yet, buy Kermit directly from Columbia U. Prices for OpenVMS C-Kermit range from about $100 (on DOS-format diskettes) to about $185 (TK50, OpenVMS BACKUP format), including source code, installation instructions, and a copy of the Digital Press book, "Using C-Kermit". It's also available on 9-track tape, 8mm cartridge and 1/4-inch cartridge. For additional information on Kermit, contact the Kermit folk directly per the information in the box which follows this article. For the fastest, most accurate response, direct your inquiries directly to Columbia University, not to me. Give Frank and his hardworking volunteers a boost... buy a copy of Kermit or at least one of the Kermit books from Columbia U. Trivia: Kermit got its name because of a Muppet calendar hanging in the office where Frank da Cruz and his associates were working. Let's be thankful he wasn't working in an automobile body shop... UPDATES: Frank Noell of Channel Islands Software reports version 2.1 of his DCL to FORTRAN precompiler (DFP) is now being shipped. This release's big features include the lexical "extensions" F$GETUAI and F$SETUAI, which allow easy access and modification to a system's User Authorization File (UAF). DFP's F$GETUAI actually surpasses the capabilities of the $GETUAI system service, permitting a convenient mechanism for checking and updating literally every item in the UAF. DFP reads in DCL command procedure files and outputs clean OpenVMS FORTRAN code. The compiled programs can run up to 30 times faster than native DCL procedures. EXE files produced by DFP can be installed with privileges, so users who need to perform "system" operations can do so without having privileged accounts. DFP uses only existing and documented OpenVMS routines, so the FORTRAN source can be easily modified by those proficient in the language. But if you're a FORTRAN illiterate like me, you can just compile and link the stuff and let 'er rip. I also received DiskMizer version 1.2 from Intersecting Concepts. The maintenance release provides a user-controllable built-in data cache which significantly improves performance in situations where applications perform sequential block reads. The new version also introduces a revised compression algorithm which is about 40% faster than the old one, at the expense of slightly reduced compression ratios. A few other minor bugs were also squashed. Since buying DiskMizer last August, I've had absolutely no problems with it. Probably because I'm a single user on a workstation, I never really noticed a performance hit, and since upgrading to a 4100 Model 60, it's been totally invisible. The new release went in smoothly, and it does work faster (although when you're dealing in subsecond response times to begin with, the improvement is hard to gauge accurately). As of November 5, 1993, I still don't have the BBS connected to the Internet, although mail to kgbarkes@gmail.com comes through fine (and in ever-increasing quantities). Several "foolproof" software packages went belly up on me, although the one I'm currently playing with seems promising. The connection to the Internet is via uucp to the local PSI POP in Pittsburgh, so ftp and telnet aren't available. However, the system I'll probably use does have a mailserver, so folk will be able to get uuencoded files by sending a mail message to kgbreport.com. Don't do it yet, though... once everything is running, I'll let you know. In the meantime, SYS$OUTPUT is available via dial-up to 412-854-0511. (Update: No, it isn't. see www.kgbreport.com) ******************** ON THE WIRE: Lots of messages this month over the Internet. Thanks to Kevin M. Haney, Mike Titus, Chairlie Byrne, Tommy Noble, Jim Vanderveen, Tom Dyas, Donald Gudehus, Jay Provost, Tom Fisk, Douglas Bolinger, Christopher L. Markis, Scott Harrod, Michael Mesnikoff, John Mathias, Irv Eisen, Marc Shannon, Mike Voss, Warren Lewis, Wayne Brandt, Roger Jenkins, George Carrette, "Elliot" at LaserMaster Technologies, and Steve Nunez. I answer all mail I receive. If you don't hear from me within a week, the reasons are probably: a) I didn't get it; b) you have a screwy e-mail return address; c) you didn't put your name and address on your letter. You'd be amazed how often that happens... e-mailers, make sure your name appears in your message, too. If I don't return your message, try again. ******************** DEALING WITH DEC I: Looks like the OpenVMS marketing ploy has backfired on DEC. Lots of folk are posting questions on various bbs systems asking whether they should "upgrade" from VMS to OpenVMS or switch to other vendors' "really open" Unix-based systems. DEALING WITH DEC II: It took about five passes, but the hardware/software maintenance contract for the new VAXstation appears to be correct. How do large sites cope with this? A DEC employee on CompuServe commented that in 19 years he's never seen a contract go through ok on the first try. Funny way for a "customer driven" company to operate. The poor contracts lady at my local office did send me a coffee mug for my troubles. DEALING WITH DEC III: After straightening out the support contract business, I thought my relationship with DEC would return to normal. Right. On October 29, I received a Fedex letter from Digital Leasing and Remarketing. The package contained an invoice for the monthly lease on the system. Invoice date: October 25, 1993; payment due date: October 14, 1993, or eleven days in the past. Drat. I knew I should have spent the extra money to get that temporal flux capacitor for the VAXstation. ******************** Kevin G. Barkes is an independent consultant who is knee-deep in financial aid forms as he prepares to send his son off to college this fall. The kid ignored Dad's first recommendation: to become a blacksmith. Kevin lurks on comp.os.vms and can be reached at kgbarkes@gmail.com. ------------------------------------------------------------- KERMIT INFORMATION: The Kermit Project website: http://www.columbia.edu/kermit E-mail: kermit@columbia.edu (Internet) Postal mail: Kermit Development and Distribution Columbia University 612 West 115th Street New York, NY 10025 USA Voice: +1 212 854-3703 Fax: +1 212 663-8202