Info-Kermit Digest Mon, 17 Sep 1990 Volume 12 : Number 5 Today's Topics: Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.2.1 Selecting CONTROLLER type in Kermit-370 Announcing KERMIT-12 Version 10g Kermit Proposal SET FILE TYPE Prime8 Help for Dividing Source Re: A New Version of Kermit for OS/2 Presentation Manager Re: Info-Kermit Digest V12 #2 Kermit incapatability with LSE Kermit 3.01 Arrow Key Problem 132 column mode in MS-Kermit? Kermit & Telebits Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU, requests for addition to or deletion from the Info-Kermit subscriber list to Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU or to KERMIT@CUVMA.BITNET. Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Wed, 1990 Sep 12 18:30 EDT From: "John F. Chandler" Subject: Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.2.1 Keywords: IBM 370 Kermit, VM/CMS Kermit Xref: CMS Kermit, See VM/CMS Kermit, IBM 370 Kermit This is to announce the release of Kermit-370 version 4.2.1 for CMS. As usual, the new version comes in VM/SP and VM/XA/SP flavors, but the changes are the same for both. Version 4.2.1 has several improvements over 4.2.0, the most important being: 1. Spurious flow-control "packets" from MS-DOS Kermit are now ignored. 2. Overflow of the fullscreen buffer is now avoided when the receiving Kermit asks for 2K packets. 3. Kermit-370 now supports transfers in LATIN2 and LATIN3 and file storage in CP870, CP880, and CP905. In addition, L1, L2, and L3 are recognized as aliases for the three LATIN sets, and two-character abbreviations are accepted for the other transfer sets as well. The new sets add support for Afrikaans, Albanian, Catalan, Croatian, Czech, Esperanto, Galician, Hungarian, Maltese, Polish, Romanian, Slovak, Slovene, and Turkish. 4. Kermit-370 supports file transfers through the IBM 3174 AEA with B2 microcode. The support is restricted to terminals with the ASCII Graphics capability in three ways: a) The terminal type must be defined in the 3174 to support graphics (only the built-in VT241 and Tektronix 4205 types plus suitable user-defined terminal types). b) The line must be defined without an associated Host Addressable Printer. c) If the 3174 is owned by VTAM, the connection must be made with a logmode that allows the Read Partition Query (such as M2SDLCNQ). Kermit-370 automatically detects the B2 AEA and sets CONTROLLER accordingly (to AEA if graphics is allowed, to NONE if not, or to GRAPHICS if Query is denied). Since the 3174 supports full 8-bit communication, it may be useful to configure the ports for 8-bit data and to set both SEND and RECEIVE PARITY to NONE in Kermit-370. 5. Kermit-370 now uses the FILE COLLISION settings for all files in a group rather than just the first. 6. Kermit-370 has three new subcommands: REMOTE MAIL, REMOTE PRINT, and REMOTE SUBMIT. They transmit a file (or group of files via wild cards) tagged for mailing, printing, and submitting as job, respectively. The new release is in the form of updates to be applied to the 4.2.0 source. The new files are IKCKER.UPD, IKCKER.BWR, IK0AAA.HLP, and IK0KER.UPD (the latter is only a catalog of all the updates, not the updates themselves). The new code has been tested on most known types of protocol converter (many thanks to the beta testers!) to make sure the 3174 support does not harm the existing support for Kermit file transfer, but problems may still turn up. Bug reports are welcome, as usual. A similar release 4.2.1 will soon be available for TSO and MUSIC. John [Ed. - Thanks, John! The new files are installed in kermit/b on watsun and are also available from KERMSRV@CUVMA on BITNET. This program is truly amazing in its adaptability to the infinitely varied 3270 emulation communications environment, and it is a groundbreaker in character set conversion. Let's hope that the other Kermit programs catch up in the latter department soon. For that to happen, we need examples and listings of the PC, UNIX, Macintosh, etc, character sets used for all the language supported by Latin Alphabets 1 through 5, Latin/Cyrillic, and others. If you have them, please send them in and we'll do our best to support them.] ------------------------------ Date: Thu, 1990 Sep 13 11:50 EDT From: "John F. Chandler" Subject: Selecting CONTROLLER type in Kermit-370 Keywords: IBM 370 Kermit One of the improvements in release 4.2.1 is a more thorough DEBUG output that proved very useful in bringing the support for the IBM 3174 to completion. This enhancement makes no difference to routine file transfer, but it raises the possibility of determining easily the exact response of any kind of protocol converter to the efforts of Kermit to decide which CONTROLLER type to use. To this end, I ask all installers of release 4.2.1 to take a few minutes and create a debug log for each (fullscreen) environment where Kermit-370 might be used, provided, that is, that you do not apply the optional update SC89058. Even if you have applied SC89058 in the past, it might be worthwhile to omit it as an experiment. The desired debug log is created by starting Kermit-370 and entering the subcommands SET DEBUG I/O LONG, SET LINE, and QUIT. I would be grateful if you would send the resulting KER LOG along with the following information: level of VTAM (if any) driving the session, model of front-end processor (if any) and software, model of protocol converter (if any) and software. These results would be interesting even for real IBM 3270-type terminals or protocol converters unable to support Kermit file transfers. It is possible that the information collected will enable Kermit to distinguish certain environments that currently fail to trigger the correct default CONTROLLER type. John P.S. My e-mail address is: Internet: PEPMNT@CFAAMP.HARVARD.EDU BITNET: PEPMNT@CFAAMP ------------------------------ Date: Thu Sep 6 1990 11:00:00 EDT From: Charles Lasner Subject: Announcing KERMIT-12 Version 10g Keywords: PDP-8, PDP-12, VT-78, DECmate, OS/8 Xref: DEC PDP, See PDP This is a maintenance release of KERMIT-12. A minor problem relating to incorrect CPU identification messages has been fixed. The problem only appeared when the CPU was a KK-8A single-board CPU; this configuration was previously untested. Thanks to Johnny Billquist of Sweden for his assistance in pinning down the problem. KERMIT-12 operation was not affected in any other way, as only the DECmate-specific identification is crucial; earlier PDP-8 family members are treated in a generic fashion except for the "frill" of model identification (all PDP-8, PDP-12, VT-78 models use software-compatible port hardware; all DECmates are incompatible and must be handled individually). We are still looking for volunteers to test the various DECmate III and DECmate III+ configurations. The rest of the release concerns the encoding of files into the "ASCII-fied" format. The format has been modified to be more robust, since the original method has proven itself to be problematic in certain practical circumstances (as reported in K12MIT.BWR). The new ENCODing format is based on five-bit encoding with repeat compression. As much as 256 repeated 12-bit words will be expressed in a five character field. Any repeated 12-bit value can be compressed, as opposed to simple zero compression, as in other common encoding schemes. (PDP-8 files often have repeated strings of the value 7402 octal, which is the HLT instruction.) The only printing characters required to pass through any distribution "path" are 0-9, A-V, X, and Z. The alphabetic characters can also be lower-case. All command lines are framed by ( and ); all data lines are framed by < and >. These characters can be changed if required, as they are not part of the data; they could be replaced by W (w) and Y (y) if necessary. (Changing the framing characters requires slight modification of the ENCODing and DECODing programs.) The new format supports a 60-bit file checksum to ensure proper decoding at the other end. The former 12-bit checksum could be compromised on long files. The new ENCODing programs creates internal (REMARK commands stating the ENCODed file's creation date, and the original file's creation date. This will aid in distribution of PDP-8 files where the user wishes to maintain proper file dates. The date algoritm used is the one proscribed by the OS/8 DIRECT program. (OS/8 systems only OPTIONALLY support file dates, and there is an eight-year "anomaly" associated with identifying the year; the user must determine the credibility of the year portion of the date. The value provided by the ENCODE program for the original file creation date is always today's year or the previous seven years as necessary; this field will not be provided if the system doesn't support the required AIW feature.) Overall file size is theoretically as much as 6/5 of the original encoding format (as the earlier format was based on six-bit encoding), but actual size varies downward due to slightly less file overhead (wider lines mean less CR LF; there is now less automatically generated verbiage), and the random improvement afforded by simple repeat compression. Virtually all K12MIT-related files are re-released at this time. There are several new files. Due to the "fragile" nature of TECO macro files, the file K12GLB.TEC is no longer being distributed directly; the file K12GLB.ENC is the same file in the new ENCODE format. The new files have been installed in the regular places: BITNET/EARN Internet KERMSRV@CUVMA watsun.cc.columbia.edu Description K12MIT ENC kermit/d/k12mit.enc Encoded binary of KERMIT-12 K12MIT DOC kermit/d/k12mit.doc Documentation file K12MIT BWR kermit/d/k12mit.bwr Updated "beware" file K12MIT DSK kermit/d/k12mit.dsk Description of RX02 diskettes K12MIT ANN kermit/d/k12mit.ann Announcement of KERMIT-12 K12MIT UPD kermit/d/k12mit.upd Release update file K12DEC PAL kermit/d/k12dec.pal Decoding program K12ENC PAL kermit/d/k12enc.pal Encoding program K12PL8 ENC kermit/d/k12pl8.enc Encoded binary of PAL8 Ver B0 K12CRF ENC kermit/d/k12crf.enc Encoded binary of CREF Ver B0 K12MIT PAL kermit/d/k12mit.pal Main source file of KERMIT-12 K12PCH PAL kermit/d/k12pch.pal KERMIT-12 source patch file K12CLR PAL kermit/d/k12clr.pal Memory clearing file K12MIT LST kermit/d/k12mit.lst Symbols-only listing file K12PRM PAL kermit/d/k12prm.pal Sample VT-78 config file K12GLB ENC kermit/d/k12glb.enc Encoded TECO file macro K12ENC DOC kermit/d/k12enc.doc Encoding format description [Ed. - Many thanks, Charles. Believe it or not, there are still quite a few PDP-8 based systems out there, and even some PDP-12s. You won't find very many other new software packages that support them!] ------------------------------ Date: Thu, 6 Sep 90 08:47 CST From: Subject: Kermit Proposal SET FILE TYPE Keywords: Kermit Protocol Please accept these remarks regarding the proposed SET FILE TYPE extension to Kermit. 1. The labels are transmitted in normal Data packets. Therefore an ignorant Kermit receiver will write them into the file as data. This is a MAJOR change to the protocol, which has always provided transparent file exchange. When reading such a file, how is a program to know that labels have already been included? Will these files cause problems for other file-transfer protocols such as Xmodem? [Ed. - No, it won't cause problems with Xmodem. Xmodem or any other file transfer protocol, including a Kermit program that does not know about labeled files, will store or send a labeled file just like any other file, without interpreting the label information.] 2. Stored-in-File labels are incompatible with the MacBinary protocol in standard use on Macintosh computers. [Ed. - That's true. But MacBinary format cannot be adapted to other kinds of file systems such as VAX/VMS. Kermit can still be used to transfer MacBinary files, and a MacBinary option will be added to Macintosh Kermit before its next release.] 3. The sending operator must now decide whether to send with labels or not. Previously, the sender had no choices to make. We should not be adding complexity to the process if we can help it. [Ed. - This is true. However, without labels it is impossible to transfer a complex file and retain all of its features. Therefore this proposal addresses only computers with complex file systems, like VAX/VMS, IBM mainframes, etc, and does not affect other computers. Users can continue to use Kermit on these systems in the normal way, but now they will also have an additional tool to let them successfully transfer files that they could not transfer before.] 4. Perhaps a better approach would be to use: SET FILE TYPE system type Where 'system' identifies the receiving file management system, (RMS, VSAM, etc.) and 'type' identifies the appropriate attributes. Example: SET FILE TYPE RMS INDEXED where RMS represents Vax RMS file management, and INDEXED identifies the incoming file as an indexed file. This approach requires that the sending and receiving routines be similarly intelligent about the information required to successfully transmit and write the file, but allows unintelligent intermediary programs (repositories, bulletin boards, etc.) to receive and send the files without any special settings (other than SET FILE TYPE BINARY). [Ed. - It is a cardinal principle of Kermit or any other well-designed file transfer protocol that any particular computer must not be required to have knowledge about the formats and conventions of any other kind of computer. Rather, each Kermit implementation knows only the data formats of its own computer and those defined for the "standard intermediate representation" on the wire. Otherwise, hundreds of different programs would require modifications to know about hundreds of different computers. Not only is this a waste of computing and human resources, but it's a moving target.] It also allows the following sequence to take place: machine 1 Kermit send -> machine 2 Kermit receive (FILE TYPE BINARY) machine 2 BrandX send -> machine 3 BrandX receive machine 3 Kermit send -> machine 4 Kermit receive (FILE TYPE xxx ttt) Machine 1 sends the file BELIEVING that the receiver knows how to handle it, but only the machine 4 program needs to know. However, machine 3 can also use the file, if it recognizes, or is told to recognize, the file type. [Ed. - The Labeled File proposal works the same way.] A simplification of this approach would be to use SET FILE TYPE AUTO which would cause the receiver to perform some recognition process before writing the file. [Ed. - The labeled file proposal includes this possibility too.] We have recently developed a Macintosh VT100 terminal emulator which incorporates Kermit file exchange, and automatically distinguishes TEXT documents from applications and formatted documents. The users need only tell the Vax to SET FILE TYPE ASCII/BINARY depending on whether they intend to edit it on the Vax, or transfer it to another Mac. The program pre-pends the Macbinary header for non-text documents when sending, and recognizes it when receiving. I think you'll agree that the LABELED proposal only adds complexity to our situation, and requires users to make unnecessary decisions about the process. [Ed. - Your application seems to be Macintosh-centered, in the sense that you regard the VAX as a repository for Macintosh applications, which you encode in MacBinary, but you make no provision for storing VAX applications or complex binary VAX files on the Mac. For your purposes, MacBinary will do just fine.] ------------------------------ Date: Tue, 28 Aug 90 17:27:31 EDT From: John M. Crawford Subject: Prime8 Help for Dividing Source Keywords: Prime Kermit Enclosed is a short file which provides the necessary Primos editor (ED) tricks to divide (and then build) Kermit 8.12 for Primos. You might consider appending it to the PRIME8.ANN file (or another) for general distribution to Prime kermit users. John M. Crawford (614) 292-1741 Computing Services Center College of Business craw4d+@osu.edu 1775 College Road craw4d@prime.cob.ohio-state.edu The Ohio State University crawford-j@osu-20.ircc.ohio-state.edu Columbus, Ohio 43210 [Ed. - Many thanks! Your ED file is now enshrined in PRIME8.ANN.] ------------------------------ Date: Wed, 29 Aug 90 10:23:11 PLT From: Wim Bonner <27313853%WSUVM1@cuvmb.cc.columbia.edu> Subject: Re: A New Version of Kermit for OS/2 Presentation Manager Keywords: OS/2 Kermit The message said that the Kermit files were in the OS/2 test area pending comments from the user community. Is this where I make comments? I tried the Kermit program just now. It has an annoying habit of going full screen. I have a 1024x768 screen, so an 80,25 screen will fit in less than a quarter of the screen, and leave room for much more on the screen. I am running OS/2 1.2, and was not able to get the lights on my modem to blink when I typed characters after Connecting. That is normally a good indication something is wrong. All of the other communication programs that I've tried work fine. Wim Bonner - 27313853@WSUVM1.CSC.WSU.EDU - V(509)335-4436 [Ed. - Thanks. We'll collect all such comments and put them in an envelope and send them back to the contributor. Meanwhile, has anyone else gotten the program to work?] ------------------------------ Date: Sat 25 Aug 90 11:51:37-CDT From: Rob Pettengill Subject: Re: Info-Kermit Digest V12 #2 Keywords: MS-DOS Kermit 3.02, Macros, Variables, Scripts The behavior of the macro positional parameters has changed in the new test release of MSKermit 3.02. Previously when a take script was taken in a macro the \%n positional arguments were defined in the take script - with this version they are undefined. The previous behavior was reasonable for a script. Are you tring to make take files behave more like macros? If so then it should be possible to pass positional arguments to the take files explicitly. In any case the behavior in the current 3.02 does not seem desirable. ;rob [Ed. - That was a mistake, which has been corrected in the latest 3.02 release. Macro parameters are now on a call stack so if macro A calls macro B, A's parameters are still intact when B returns. The mistake was indeed that a TAKE file was being treated like a macro. In the latest edit, it is not: if macro A TAKEs a command file, A's parameters are available to the TAKE file, as before.] ------------------------------ Date: 29 Jul 90 23:18:00 CDT From: "COLLINS, STERRETT" Subject: Kermit incapatability with LSE Keywords: MS-DOS Kermit 3.0, LSE, VAX/VMS, Terminal Emulation I am using MS-Kermit v3.0 on a Kaypro 286 operating MS-DOS v3.21, connecting to a VaxCluster operating VMS v5.3 . I have tried using the language sensitive editor (LSE v3.0), but Kermit fails to emulate the terminal that LSE expects. I have tried setting terminal/nodec_crt3, which partially corrects the problem, but still not satisfactorily. I am not sure that LSE does not think that every member of the VT300_Family of terminals is a Regis terminal. I have access to a Regis_Emulating communications software package, which I do not normally use for licensing considerations, but which, if I switch to that after having entered LSE using Kermit, is able to emulate the terminal properly. The possible answers would seem to be: "The operating system does not successfully detect the correct terminal characteristics." "The Operating system does successfully detect the correct terminal characteristics, but this information is not propperly transferred to LSE." I only know that SHOW TERMINAL reveals that it does not have the REGIS characteristic, but does have the SIXEL charactersitic, and the DECCRT_3 characteristic. sterrett collins physics department texas tech university [From jrd - Another case where Kermit command SET DISPLAY 8 needs be done to avoid clobbering the 8-bit control sequences sent by the host.] ------------------------------ Date: Mon, 23 Jul 90 19:44:42 GMT From: seminara@penelope.oswego.edu (Greg Seminara) Subject: Kermit 3.01 Arrow Key Problem Keywords: MS-DOS Kermit, Arrow Keys Arrow keys work only sporadically when connected to a UNIX host from a DOS PC running Kermit 3.01 if you are using a full-screen "curses" application. Seems to be sending either the wrong ansi sequence or is sending the sequence too fast. If you press arrow keys with a significant pause between each press, keys usually work OK. Emulation is vt102 for kermit and TERM is set to "kermit" or "vt100". Kermit 2.32a and before work fine under identical conditions. - HELP! [From jrd - your Unix host has a problem with communications. If characters in a control sequence are NOT sent in rapid succession then EMACS reacts differently than expected. In addition, some host machines apparently have intrinsic difficulties running in true full duplex. Unix loves to echo arriving characters willy nilly. So when Unix is sending a control sequence while one is arriving from Kermit and Unix is also echoing it then Kermit receives both sets of information with characters intermingled. If the sequences arrived separately then Kermit could cope. This is pretty silly behavior by Unix; the application should attempt supressing echos. There is nothing that Kermit (nor a real terminal) can do about it.] ------------------------------ Date: Thu, 30 Aug 90 14:28:57 CDT From: moore@ncsc.navy.mil (Moore) Subject: 132 column mode in MS-Kermit? Keywords: MS-DOS Kermit, 132 Columns, Screen Settings Greetings. I have a very persistent user here who wants the word directly from the horse's mouth regarding a feature of MS-Kermit: I've always thought that EGAs cannot do 132-column mode (except by simulating it in graphics mode). MS-Kermit doesn't change that, right? Isn't it the "responsibility" of the hardware to switch modes, and then Kermit just detects and uses that mode? [Ed. - True. Except that in version 3.0 and later it also supports automatic switching between 80 and 132 column mode via the COLS80.BAT and COLS132.BAT mechanism. That is, if Kermit gets the escape sequence telling it to switch modes, it will try to run the appropriate BAT file that does the PC- or adapter-specific things required to switch modes.] Can Kermit simulate 132-column mode by letting the user pan an 80-column window left and right? [Ed. - No.] Thanks for any help. Jim moore@NCSC.navy.mil ------------------------------ Date: 27 Aug 90 11:42:05 GMT From: mrsvr!saturn.shaw@uwm.edu (Tom Shaw ct58 Ex 5084) Subject: Kermit & Telebits Keywords: Modems I'm looking for anyone who has/is doing something similar to this: I am transferring binary and ASCII files across dial-up phone lines using Telebit Trailblazer Plus modems and kermit. The transfers are between 2 Suns, one running Sun OS 3.5 and the other running Sun OS 4.01. The size of the files range from 2500 bytes to 800kbytes. Does anyone have any tips, traps to avoid, benchmarks of what kind of rate I should be expecting for ASCII and binary files or any hands on advice. I am using kermit version 4E(72). In the past few weeks, I've heard stories about using Telebits in Germany, what kind of problem is there and are there any other countries I might have a problem connecting and transfering to? Any help would be appreciated. Thanks Tom [Ed. - As you may know, Telebits have Kermit built inside them. If you activate this feature, Computer A actually talks Kermit protocol to Modem A, Modem A talks high-speed error-correcting PEP protocol to Modem B and Modem B talks Kermit protocol to Computer B. This is all done transparently to the Kermit programs, but you have to put the originating Telebit into "Kermit spoof" mode. See your Telebit manual.] ------------------------------ End of Info-Kermit Digest *************************