24-Oct-91 16:13:57-GMT,28687;000000000001 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA17894; Thu, 24 Oct 91 12:13:53 EDT Date: Thu, 24 Oct 91 12:13:52 EDT From: Christine M Gianone To: Info-Kermit Subject: Info-Kermit Digest V14 #9 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: Info-Kermit Digest Thu, 24 Oct 1991 Volume 14 : Number 9 Today's Topics: Announcing Kermit for Microsoft Windows 3.0 Announcing a New Release of HP-3000/MPE Kermit Recent Kermit Protocol Extensions Kermit News Articles MS-DOS Kermit and DR DOS Release of Additional Kermit-12 Utilities Re: New Serial Printer Driver for MS-DOS Kermit Flow Control for IBM Mainframe Half Duplex Connections MS-DOS Kermit Speed Under MS-Windows Kermit Packet Length Fluctuations Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU or KERMIT@CUVMA.BITNET. Requests for addition to or deletion from the Info-Kermit subscriber list should be sent to LISTSERV@CUVMA.BITNET or LISTSERV@CUVMA.CC.COLUMBIA.EDU. These messages must be of the form: SUBSCRIBE I-KERMIT (To start a subscription) UNSUBSCRIBE I-KERMIT (To cancel a subscription) REGISTER I-KERMIT (To correct your name) 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. All files in these directories should be transferred in text (ASCII) mode. 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: Tue, 22 Oct 91 12:00:00 EDT From: Christine M. Gianone Subject: Announcing Kermit for Microsoft Windows 3.0 Keywords: Windows 3.0, Kermit for Windows Written by Bill Hall, Santa Clara, CA, specifically for Microsoft Windows 3.0, announced for testing in Info-Kermit V13 #5, June 1991. Since no complaints have been received, this version has been moved into the "A" area, replacing the previous version of Bill's Windows Kermit program, which works only under Windows 2.0. This is not MS-DOS Kermit, but a completely different program. It uses the point-and-click Windows user interface, and it runs in a window in Real, Standard, and Enhanced modes of Windows 3.0 on any model PC or PS/2 that supports Windows 3.0, and emulates the VT52, H19, and VT100 terminals. The program is the subject of an article written by Bill in the January 1991 issue of Microsoft Journal: "Adapting Extended Processes to the Cooperative Multitasking of Microsoft Windows". The new version of Windows Kermit lacks many of the advanced features of MS-DOS Kermit: VT220/320 emulation, key mapping and macros, international character sets, Tektronix graphics, long packets, sliding windows, script programming, network support, etc, but some of these items are on Bill's list for future releases. The files are in kermit/a/wk*.* on watsun.cc.columbia.edu (Internet) and are available as WK* * from KERMSRV at CUVMA on BITNET / EARN. First get the file wkaaaa.doc (WKAAAA HLP), read it, and then decide which other files you need to get. The old version of this program, which is still required for Windows 2.0, has been moved to kermit/c/win*.* on watsun (WIN* * on CUVMA). Thanks once again to Bill for this excellent contribution! ------------------------------ Date: Tue, 22 Oct 91 12:01:30 EDT From: Christine M. Gianone Subject: Announcing a New Release of HP-3000/MPE Kermit FROM: Tony Appelget General Mills, Inc PO Box 1113 Minneapolis, MN 55440-1113 Apparently my contribution of HP3000 Kermit has hit the streets. I am getting complaints, mostly because sites do not have current SPL compilers. Since I first sent you my updated version of HP3000 Kermit, we have obtained HP Spectrum machines. Although Kermit did not fall flat on its face, problems arose and I fixed them. It is time for me to send you an update. Enclosed on this disk are the following: This letter. My HP3000 Kermit source. My HP3000 Kermit object. The object file is straight classic HP3000 code, ready to run. It has not been BOOed or otherwise been made eye-readable. I assume that you have the facilities to readily do that conversion if you choose. I have run the classic HP3000 code through HP's OCTCOMP processor and the resulting code file seems to be well-behaved on a Spectrum machine. (Signed) Tony Appelget [Ed. - Many thanks, Tony! The new files are on watsun.cc.columbia.edu in kermit/d/hp3*.* for Internet access, and available as HP3*.* from KERMSRV at CUVMA on BITNET/EARN/CREN. The .OBJ file has been converted to hex format, which should be easily deodable: each 2 bytes are the hexadecimal encoding of an 8-bit byte. Ignore line ends. A binary copy of the object file is in kermit/bin/hp3kerm.obj (watsun, Internet only).] ------------------------------ Date: Tue, 22 Oct 91 12:02:00 EDT From: Frank da Cruz Subject: Recent Kermit Protocol Extensions Keywords: Kermit Prototol, Character Sets, International Character Sets Keywords: Compression For the past several years, Kermit programs have been appearing that translate character sets during transfer of text files. This is necessary because of the many different incompatible encodings used for national and international (non-ASCII) characters on different kinds of computers. The protocol extension that specifies exactly how this is done has been undergoing continuous revision and refinement. The current description can be found in the file kermit/e/isok6.txt (ISOK6 TXT on BITNET KERMSRV). Some background can be found in an excellent paper by Andre' Pirard of the Universite de Liege in Belgium, kermit/e/pirard.txt (PIRARD TXT on KERMSRV). To increase the efficiency of 8-bit text file transfers through 7-bit connections, a locking-shift option has been added to the Kermit protocol. This is documented in the file kermit/e/lshift.txt (LSHIFT TXT on BITNET KERMSRV). The next major effort in Kermit protocol expansion (no commitment expressed or implied!) is the addition of an effective and portable compression method. We're in the information-gathering phase now. The method that is finally chosen must be single-pass, in the clear legally (unlike LZW, which is tied up in patent infringement litigation, or MNP-level-whatever, which is licensed commercially), well-behaved and effective for all types of data (7-bit text or 8-bit text in any language, binary executables, numeric data, raster images, etc), relatively easy to program, and not horrendously consumptive of CPU cycles or memory. For maximum transportability, the result of compression should be a sequence of 7-bit ASCII printable characters (32-126 or a subset of these). Suggestions, pointers to specifications for various methods and analyses of them, etc, would be most appreciated. ------------------------------ Date: Tue, 22 Oct 91 12:01:00 EDT From: Christine M. Gianone Subject: Kermit News Articles Come on, send in those articles! We're not going to publish the next issue of Kermit News until we have some good ones. I'm looking for interesting stories about Kermit -- how it is being used in different countries, industries, and different sectors of the economy; what role has it played in recent historic events; why was it chosen over other alternatives, what features are especially attractive or useful, etc, as well as amusing anecdotes, technical contributions, reviews of recent Kermit releases, etc. Kermit News is a real journal, ISSN number and all. Get published! ------------------------------ Date: Sat, 12 Oct 91 3:59:16 EDT From: Charles Lasner Subject: MS-DOS Kermit and DR DOS Keywords: DR DOS, MS-DOS Kermit and DR DOS There is a cosmetic problem with DR DOS 5 (early and late) and DR DOS 6 whereby the OS doesn't do an automatic CR/LF when the application terminates so therefore the KERMIT prompt gets overlayed with the DOS prompt. Otherwise all works very well. DR DOS 6 can deliver even more memory than DR DOS 5 and certainly much more than MS-DOS 5 or any version depending on your hardware. Without resorting to an admitted "trick" of memory management, DR-DOS can deliver 627K out of 640K to the user program (on 386 systems using EMM386.SYS) and 628K on C&T NEAT-chipset 286 systems. This seemingly high number is because pieces of DOS reside in either upper memory or high memory or both. MS-DOS KERMIT runs fine in all of these configurations. The real trick is when you enable the so-called memmax +v option, whereby the video buffer is mapped into the physical space where some of the upper memory lives, thus allowing the remapping of live memory space at A000 and up. The net result is that the machine grows to a whopping 724K (yes, that's 1024=1K units!), but all of the video's graphics modes are disabled. "well-behaved" software believes that your video hardware is now a CGA only, complete with the minimal CGA graphics modes, but all of the extended modes go away. My machine is a 20 MHz "King of Neat" system with an Ahead Systems 1 Meg VGA. All of the extended modes (1024x768x16 or 256, 800x600x16 or 267, 640x480x256) and all of the normal VGA and EGA modes just disappear. Yet, the VGA ROM is still present (and also RAM shadowed for speed). Applications seeking these modes find only the CGA stuff. Needless to say, many applications are incompatible with this much memory, but fortunately MS-DOS KERMIT isn't one of them. It's real cute to run KERMIT, then do a PUSH to DOS to find out that you still have over 600K beneath you! [From jrd - Interesting. Both MS and DR DOS are making some progress. The current version of QEMM/386 takes this further by reusing the area occuppied by some ROMS (video, system, some others) with no, zero, loss of functionality. It's called Stealth mapping. I advise all memory mappers (people) to never put anything in video display areas because that belongs to the video system and may/will be used by programs. Simpleminded ideas about video modes determining a video display adapter are for the birds so my advice is still sound.] ------------------------------ Date: Thu Oct 10 1991 12:00:00 EDT From: Charles Lasner Subject: Release of Additional Kermit-12 Utilities Keywords: .BOO, PDP-8, PDP-12, VT-78, DECmate, OS/8 Xref: DEC PDP, See PDP This is a release of companion utilities to KERMIT-12 for the purpose of enhancing file distribution. Two areas are addressed: 1) Initial program acquisition, 2) Binary file encoding. 1) Utilities are provided to create and load copies of KERMIT-12 "on the fly" from a server such as a remote time-sharing system or a local PC on the other end of a "clean" connection to the PDP-8. Unfortunately, most PDP-8 family systems lack a communications predecessor to KERMIT-12. Most communications applications were limited to terminal emulation only, so it is rare that any PDP-8 system has an existing utility sufficient to acquire KERMIT-12. (Of course some sites have prior versions of KERMIT-12 already.) Assuming an error-free serial connection to the other system, it is possible to down-load KERMIT-12 directly into the PDP-8 memory without a protocol. This is similar to the process used for years by DEC field service to load paper-tape copies of diagnostics. Loading is limited to a single PDP-8 field at a time. Performing several load operations yields intermediary image files which can be combined into K12MIT.SV identical to the release version (except for irrelevant loading artifacts which is a consequence of the operating system itself). The format chosen for Initial Program Load (.IPL) is an encoding that yields ASCII files that should pass through any system with ease. The scenario of loading is assumed to be either direct system-to-system, or between a remote system and one of its terminals. All control characters (such as CR and LF) are ignored, thus the encoded files contain frequent line breaks to make the encoded file pallatable to the serving system. Strictly lower-case letter messages are added at the beginning and end of the file to serve as leader trailer fields as well as file documentation. Please note that while spaces are insignificent, the rest of the ASCII character set is used for loading information, so editing of .IPL files must scrupulously avoid changes to the "body" of the file. A simple program (K12IPL.PAL) is provided for .IPL loading of a single field. The user must customize it for local requirements, and then enter two variant forms of the loader. (Future releases could require additional variants to be created. The current release occupies two fields.) This process is similar to customizing the communications requirements of KERMIT-12 itself. The program is sufficiently small to allow manual entry into the system debugger (ODT) directly. Examples of such an entry session are provided as K12IP0.ODT and K12IP1.ODT. The source program may also be retyped by any available means (TECO, EDIT, etc.) if desired. Only standard PDP-8 peripherals are supported such as KL8E, KL8-JA, etc., as opposed to KERMIT-12 itself which supports various DECmate communications hardware as well. It was felt that the greatly increased complexity of supporting the DECmate communications ports would make this process too unwieldy. However, it is possible to load the data through the DECmate's printer port. The VT-78 and all prior PDP-8 models are fully supported. Distribution files include K12FL0.IPL and K12FL1.IPL which are the encoded copies of field zero and field one respectively. K12IPL.DOC is a discussion of the .IPL encoding format itself. K12IPG.PAL is the utility used to create K12FL0.IPL and K12FL1.IPL from the standard release file K12MIT.SV. (K12MIT.SV is itself distributed in encoded form as K12MIT.ENC and now also K12MIT.BOO (see below). K12IPG can be used with other programs for similar purposes if required.) 2) Utilities are provided for encoding and decoding arbitrary OS/8 files using the popular .BOO format encoding scheme. .BOO format should be compatible across dis-similar systems thus avoiding intermediary "hazards." While quite popular in the MS-DOS world for file distribution purposes, .BOO format as originally designed has an inherent weakness that makes reliable use on OS/8 family systems impossible. I have designed an extension to the format to make .BOO format sufficiently reliable to allow implementation of an encoder and decoder for OS/8 systems. Note that ENCODE format is still the format of choice for file distribution because of its more robust nature, but the shorter files created by a .BOO encoder may be desirable in certain circumstances. .BOO format files cannot pass through WPFLOP "paths" to distribute files on DECmates or VT-78, so ENCODE format is mandatory on systems used this way. The relevant problem with .BOO format has to do with file length anomalies that are a consequence of the format itself. .BOO files either end on a repeat compression field or a complete three-byte data field expressed as four characters, each only six bits significant. Should a file end with only one or two eight-bit data bytes, two or one additional null bytes will be appended to pad out the last data field. This leads to files that are one or two bytes longer than intended. At least this is the behavior on systems like MS-DOS which maintain a file byte count. Since OS/8 files are multiples of whole records, each of which can be viewed as a collection of 384 bytes, any change in a file's length of even a single extra null byte will cause the creation of an extraneous whole record. Besides wasting space, it is conceivable that an OS/8 file corrupted in this manner could actually be dangerous to use! Note also that this problem can be cumulative in that repeated transmission between systems where the file is stored locally in some decoded form, and then encoded locally before transmission to another site, can cause the problem to worsen indefinitely. Clearly, .BOO format must be firmed up to prevent this form of file corruption before it can be used safely on PDP-8 systems. (It has also been noted that widely distributed .BOO encoding programs exist on certain systems which exhibit defects such as erroneous appendage of additional null bytes onto the end of the file not indicated by the file's contents. This is clearly a program bug and not an inherent problem with .BOO format design.) The method chosen to correct the existing .BOO anomaly is to append a correction field to the end of every file requiring it. The basic correction unit is ~0 which means literally a repeat compression field with a count of zero. This construct is ignored by most .BOO decoders because it contributes nothing to the file. (At the bare minimum, .BOO decoders should implement the robustness of ignoring this type of data. It is conceivable that due to design error, a decoding program could "blow up" when encountering this data. Imagine a file lengthened by 2^32 null bytes! The exact amount of extraneously generated null bytes would likely be 2^{how many bits wide are integers on the machine} or one less than that.) .BOO-encoded files may now contain either ~0 or ~0~0 at the end to indicate whether one or two bytes are to be "taken back" respectively. Tests on MSBPCT.BAS and MSBPCT.C as currently distributed by CUCCA indicate that these corrections are perfectly ignored, thus decoded files are erroneously inflated by one or two bytes. This is the expected behavior of these older decoders. When used with PDP-8 DEBOO.SV (distributed in source form as K12DEB.PAL), the correct file length is maintained. PDP-8 ENBOO.SV (distributed in source form as K12ENB.PAL) is the first encoding program that creates the correction field as necessary. It is hoped that this "pioneering" effort will cause other systems' encoders and decoders to be similarly updated. Overall program operation for the encoder and decoder is identical to the equivalent programs for ENCODE format. Documentation is contained in the source files. As in the ENCODE format decoding program, the target file name can be taken from the original file name imbedded within the file, or optionally the user can specify a target file name as well as a target device. When encoding, the imbedded file name will always be the original name of the file supplied as input to the encoder. The user can specify any valid combination of output file name and device for the resultant encoded file. OS/8 files passed through ENBOO/DEBOO are packed/unpacked according to the standard OS/8 "3 for 2" scheme to ensure byte accuracy where relevant. This allows files which are ASCII, but too "delicate" for ordinary transfer to be sent between unlike systems with total accuracy. This includes any file where the precise placement of CR and LF may be critical, or contains unusual characters in the file such as BEL or ESC. A perfect example of this is the interchange of TECO macros between PDP-8s (used with OS/8 TECO.SV) and IBM-PCs (used with MS-DOS TECO.EXE) with a unix system as an intermediary storage site. Both end systems use like line termination schemes incompatible with the intermediary system. Since both systems support .BOO format, the files can still be sent without loss. Most of the existing K12MIT-related files are unchanged. K12MIT.DSK is updated to reflect all new files pertaining to .IPL or .BOO utilities. K12MIT.ANN and K12MIT.UPD are updated per this announcement. All files distributed in ENCODE format are replicated in .BOO format. The new files have been installed in the regular places: BITNET/EARN Internet KERMSRV@CUVMA watsun.cc.columbia.edu Description K12MIT ANN kermit/d/k12mit.ann Announcement of KERMIT-12 K12MIT UPD kermit/d/k12mit.upd Release update (this) file K12MIT DSK kermit/d/k12mit.dsk Description of RX02 diskettes K12IPL PAL kermit/d/k12ipl.pal .IPL loading program K12IP0 ODT kermit/d/k12ip0.odt ODT session creating IPL0.SV K12IP1 ODT kermit/d/k12ip1.odt ODT session creating IPL1.SV K12FL0 IPL kermit/d/k12fl0.ipl .IPL encoding of K12mit (FL0) K12FL1 IPL kermit/d/k12fl1.ipl .IPL encoding of K12mit (FL1) K12IPG PAL kermit/d/k12ipg.pal .IPL-format encoding program K12IPL DOC kermit/d/k12ipl.doc Description of .IPL format K12ENB PAL kermit/d/k12enb.pal .BOO-format encoding program K12DEB PAL kermit/d/k12deb.pal .BOO-format decoding program K12MIT BOO kermit/d/k12mit.boo .BOO encoding of KERMIT-12 K12PL8 BOO kermit/d/k12pl8.boo .BOO encoding of PAL8 Ver B0 K12CRF BOO kermit/d/k12crf.boo .BOO encoding of CREF Ver B0 K12GLB BOO kermit/d/k12glb.boo .BOO encoded TECO file macro [Ed. - Thanks, Charles! Additional information can be found in the new file, k12mit.not (K12MIT NOT), a message from Charles to the "PDP-8 lovers" mailing list.] ------------------------------ Date: Tue, 01 Oct 91 19:40:40 EDT From: "Roger Fajman" Subject: Re: New Serial Printer Driver for MS-DOS Kermit Keywords: Printers, Serial Printers, MS-DOS Kermit and Serial Printers > But DOS does not include any provision for flow control with a serial printer > (parallel printers do this in hardware, automatically). Therefore it is > common to have printing problems when your communication speed with the host > is faster than your printer's speed. The solution is to install a printer > driver that provides the needed flow control between the PC and the printer. This is only partly true. XON/XOFF flow control is not supported, but the IBM PC and compatibles support hardware flow control on serial printers. In order to use it, you must have a printer that will drop some control signal on the RS-232 interface when it wishes to stop incoming data and an appropriately wired null modem cable. Many serial printers can be configured to drop DTR (Data Terminal Ready) on a buffer nearly full condition. A suitable null modem cable for such a configuration is wired as follows: 20 (DTR) to 5 (CTS), 6 (DSR), 8 (CD) 5 (CTS), 6 (DSR), 8 (CD) to 20 (DTR) 2 (TD) to 3 (RD) 3 (RD) to 2 (TD) 7 (SG) to 7 (SG) 1 (PG) to 1 (PG) (optional) Not all of these connections are strictly necessary, but I like to make them this way because it makes the cable symetrical and works in a lot of situations. Roger Fajman Telephone: +1 301 402 1246 National Institutes of Health BITNET: RAF@NIHCU Bethesda, Maryland, USA Internet: RAF@CU.NIH.GOV ------------------------------ Date: Wed, 02 Oct 91 09:11:18 -0400 From: Joe Morris Subject: Flow Control for IBM Mainframe Half Duplex Connections Keywords: Printers, Serial Printers, MS-DOS Kermit and Serial Printers Keywords: IBM Mainframes and Flow Control, Flow Control and IBM Mainframes In INFO-KERMIT 8.14, Clement Lepoutre (CJLEPOUTRE@FAIR1.BITNET) reports having problems while printing through Kermit to a local printer. The problem is that while the printer is cheerfully doing its thing, the data arriving from the host overflows the buffers and drops into the bit bucket. > Is there something settable in Kermit for it to take a larger or smaller > hunk of information before it gets sent to the printer? We would like to > work at a [comm line] speed faster than 1200, obviously. Thanks for any > suggestions. To which Joe Doupnik replied, including the tag note: > Plan B: If the "mainframe" in your message is an IBM one, and your > connection to it is a half-duplex linemode connection, flow control can't > be done. The only workaround in this case is to send printed material to > your disk instead of to the printer (SET PRINTER filename) and later print > the file by ordinary means. Without flow control, the mainframe will > easily overrun the printer. I haven't used it for years (mainly because we've got only one async line for line-mode users...and I think it was last called in 1988) but there's a zap for the 37x5 EP and PEP code which can provide flow control for IBM half-duplex systems *if* you can deliver EIA flow control (RTS/CTS) to the mainframe port. It's marketed by COMM-PRO Associates in Manhattan Beach, CA. In our case we're running a Sytek async LAN, and it can be set up to take XON/XOFF at one end of a path and deliver CTS/RTS on the other. It's not a perfect solution, but given half-[duplex] ASCII architectural limitations it resolved our problems. (We needed it because the Sytek net does speed translation, and we had to support local users at 9600 BPS and dial users at 300 BPS on the same port. It worked.) ------------------------------ Date: Tue, 15 Oct 91 10:21:51 EDT From: H W Payne Subject: MS-DOS Kermit Speed Under MS-Windows Keywords: Windows 3.0, MS-DOS Kermit and Windows 3.0 In the July 25th, Kermit Digest issue I made a comment that using MS-DOS Kermit, MS-DOS 4.01 and MS-Windows 3.0 causes the native win3 comm driver to max out at 9600 bps. This note was referring to the following configuration: telephone link PC Comm Port <---> MNP modem <-------------------> MNP modem <-----> SUN OS 386 PC V.42 link with workstation MNP 3, 4 or 5 Both modems are identical and are rated for 9600 bps. Kermit was used to set the PC's Com Port speed to 19,200 bps. The PC is a 386 (25 MHz) with an asynchronous communications element (VL16C452) which is programmable to 1.8 MHz. After talking with many people I still can NOT get the modems to talk to each other at 19,200 bps. How can I get 19,200 bps between the two modems with a third party driver? E.W.Carlson, how did you do it? [Ed. - We have attempted to make contact with E.W. Carlson too, but so far no response. We observe the same effect on a 386SX (PS/2-55SX) -- it has to flow-control the host at 19200, but seems to keep up at 9600. On a regular 386 (PS/2-70) it does keep up at 19200.] ------------------------------ Date: Fri, 11 Oct 91 15:47:51 -0400 From: "Blaise M. Barney" Subject: Kermit Packet Length Fluctuations Keywords: Packet Length, Kermit Protocol Why would kermit quit sending packet lengths of 1000 (specified with both the set send packet-length 1000 and set receive packet-length 1000 commands) and drop down to about 90? This occurs after approximately ten minutes of file transfer at a packet length of 1000. [Ed. - Certain Kermit programs, notably Kermit-370 4.2 and C-Kermit 5A, when sending files, reduce the packet length automatically when transmission errors occur, and then gradually increase it again as transmission errors subside. This is done to reduce the chances that a future packet will be corrupted by noise, as well as the retransmission time. The method used by Kermit-370 is described in Kermit News Volume 3 Number 1, June 1988, available online as kermit/e/newsv1.n3 (Internet) and NEWSV1 N3 (BITNET KERMSRV).] ------------------------------ End of Info-Kermit Digest *************************