File ktfc0d5.txt, copyright (C) Peter Lyall Easthope, 2000. All rights reserved. ** Contents What is it? Benefits of using KTFC Disclaimer Requirements What is in the package? How do I get KTFC? Installation User Configuration Sending a message Receiving a message Signature Lines Serial Port Problems Tidying the Mailbox Scanning Other Conferences Automated Startup FAQs System Specific Notes Macintosh Microsoft Windows MS-DOS Oberon Unixes and other systems running C-Kermit Bugs Limitations Support References Conditions of Use Fee Registration Thanks History Trademarks ** What is it? KTFC is the acronym for "Kermit To FirstClass". See references 1 and 2 below. KTFC is also the name of a script set which allows Kermit to communicate automatically with a FirstClass Server. ** Benefits of using KTFC - Kermit works on many systems including MS-DOS, MS Windows and unixes. KTFC has the potential to work with any Kermit which has script processing at least as good as MS-DOS Kermit 3.1.6. See System Specific Notes and reference 1. - Messages are read and composed off line using a text editor. - Options for user configuration are set by switches which are easily changed with a text editor. - Signature lines can be appended to a message automatically. - User confirmation before sending a message and before deleting an old message from the server is optional. - Messages can be read from directories other than the Mailbox---a directory in OneNet for example. - The KTFC scripts in their entirety are accessible to user customization. ** Disclaimer This software is provided "as is" without express or implied warranty. The author disclaims all warranties with regard to this software, including all implied warranties of merchantability and fitness. In no event shall the author be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of this software. The author may change the software and documentation and issue a revision at any time without prior notice. ** Requirements KTFC has been tested with MS-DOS Kermit 3.1.6 and FirstClass Server 3.5.2. Kermit is available for many operating systems. See reference 1 and System Specific Notes. Installation and use of Kermit and KTFC require an editor. In DOS, EDIT is recommended. Various text processors can also be used. The vi and emacs editors are commonly used in unix systems. Before attempting to install KTFC the user should install Kermit and configure it so that communication can be established with a FirstClass server. Using the terminal emulator in Kermit, the user should be able to log in to the server and to read and send mail interactively. To allow the key on a PC to produce a backspace in the FC Server task, the Kermit command "set key \270 \8" should be issued---usually in the MSCUSTOM.INI or .kermrc file. ** What is in the package? The KTFC version 0.5 package comprises these 7 files. Each file contains plain text. datefil0.5 An auxiliary script; see Automated Startup below. ktfc0d5.txt This file. mailout File where outgoing messages are queued. prolog0.5 The script containing the user configuration, the login code and other procedures used by scan and sr. readme.kfc A brief description of the package. scan0.5 The script which reads the mailbox, deletes outdated messages from the FC server and reads directories other than the mailbox. sr0.5 The script for sending and receiving messages. The version number m.n is real. In the following discussions the version number is omitted from the file name. Thus, a mention of the file name prolog is really a reference to the file prolog0.5. ** How do I get KTFC? KTFC might be found on an Internet server or on your FirstClass server. If you find the 7 files on a ftp or iksd server transfer them to your Kermit directory. If binary mode is used for the transfer, the files will be received on your machine with the end-of-line notation that they have on the server. If text mode is used for the transfer, the end-of-line notation will be translated from that on the server to that used in your system. Text mode is appropriate, for example, if unix files are brought to a MS Windows machine. Various utilities and editor capabilities can also translate end-of-line notations. Alternatively, get the MIME file ktfc0d5.64. This is a text file which can be transmitted in an e-mail message. 0d5 represents the version number 0.5. The .64 extension on the file name refers to MIME base64 encoding. Transfer this file to your Kermit directory in text mode if you wish to use it. Alternatively, get the ZIP file ktfc0d5.zip. Transfer this file to your Kermit directory in binary mode if you wish to use it. ** Installation The objective of installation is simply to have the 7 files of the KTFC package in the Kermit directory with the correct end-of-line notation for the system. These are a few system specific notes. *** MS-DOS This is the procedure for extracting the files from the MIME archive in MS-DOS. If ktfc0d5.64 is on a diskette in the a: drive and the Kermit directory is c:\util\kermit type this. copy a:\ktfc0d5.64 c:\util\kermit Move to the Kermit directory. In our example type this. cd c:\util\kermit Expand the archive using a MIME base64 decoder. MIME en/decoding programs are available for all operating systems in current use. In MS-DOS I use MIME64 written by Karl Hahn. Search for mime64b.zip on the Web. If mime64.exe is in the \mime directory type this to expand the KTFC archive. \mime\mime64 ktfc0d5.64 The 6 files plus this readme.kfc will be produced. After extracting the files, mime64 will report "No MIME base64 lines found in ktfc0d5.64". Don't worry about this message. If using ktfc0d5.zip follow the analogous procedure. Unpack the archive with pkunzip.exe which is readily available from BBS and Internet servers. *** Macintosh As of early 1999, development of Mac Kermit was not keeping pace with MS-DOS Kermit or with C-Kermit. KTFC has not been tested with Mac Kermit. Mac users should consider one of the off-line FirstClass clients---BulkRate by Greg Neagle for example. *** Microsoft Windows MS Windows users should also consider the OffRoad client written by Hans Haider. I have not tested KTFC with Kermit-95 but, of course, anyone is welcome to try that configuration. Until successful use of KTFC with Kermit-95 is established I can not offer the same level of support for that configuration as is provided for KTFC in the MS-DOS system. *** Unixes Testing in a unix system is on my "to do" list. Until testing is completed I can not offer the same level of support for KTFC in a unix system as is provided for KTFC in the MS-DOS system. If you wish to try KTFC, get the individual files in text mode. Alternatively, get ktfc0d5.64 or ktfc0d5.zip, unpack the archive and translate the end-of-lines using dos2unix or the like. *** Other Systems Files in the .64 and .zip archives have lines ending in . The end-of-line notation may have to be translated for your system. Reports of problems and successes are welcome. ** User Configuration Approximately the first 70 lines of the prolog script is the User Configuration. This is where you set parameters and switches according to equipment and preferences. Open an editor on prolog and change the line "set modem HAYES" according to your modem. In MS-DOS, modem files are in the modems directory in your Kermit directory. You should already have a modem file specified in the MSCUSTOM.INI file. If your modem does not use COM2 change the line "set port com2" accordingly. If you do not know which com port is used try com2. If this fails check your MSCUSTOM.INI file. In the line "def _dialnum {}" insert the number of your FC server inside the {} brackets. Prefix the number with T for tone dialing. For pulse dialing give the number alone. To avoid being asked for your UserID every time you log in, change the line "def AU 1" to "def AU 0". To avoid being asked for your Password every time you log in, change the line "def AP 1" to "def AP 0". If AU is defined to 0 replace "guest" with your UserID. If AP is defined to 0 replace "please" with your Password. Additional configuration features are discussed as FAQs below. Save prolog. Quit the editor. KTFC is ready to use. ** Sending a message These instructions assume that you are in the Kermit directory and that Kermit works. To verify that Kermit is working, log in to your FirstClass server and send or read a message interactively. Solve any problem before attempting to use KTFC. Using an editor, compose outgoing messages in the file mailout (yyyymmdd.out if the dated OutFile is configured. For more information see "FAQs > ... How is the name of the outgoing file changed?"). Syntax is explained below. Close the editor. Type the command to invoke Kermit to process sr and strike the or key. With MS-DOS Kermit version 3.1.6 and KTFC version 0.5, type this. msk316 -f sr0.5 The KTFC version and the login process should be reported on the screen. If the login fails, try to identify the problem precisely. Once a problem is identified the solution may be simple. A prompt for each message gives the opportunity to avoid sending. This is useful if an old message has been left in the OutFile. Once you have sent a few messages and become familiar with KTFC you will probably want to shut off this prompt; see "FAQs > What is the purpose of the CS flag ... ?" After sr sends and reads all pending messages Kermit will quit and the prompt from your operating system will appear. Using the editor again, delete from the OutFile any message you do not want to send the next time sr is processed. Alternatively, old messages can be left in the OutFile and two message separator lines can be placed where sending is to stop. sr will not send messages in the OutFile which follow a pair of separator lines. The paired separators can be the first two lines of the OutFile. This is the syntax of the OutFile. The stock OutFile, mailout, contains example messages which you can use as a template. The example is addressed to the author; there is no harm in sending it. ========== syntax of text in OutFile ===================== {[n] [] } ========================================================== =============== syntax of ====================== [To:] {[To:]} [Copies: {[Copies:]}] Subject: ========================================================== Notes. 1. Line breaks must be as shown. For example, a message ends at the end of a line and a recipient address ends at the end of a line. In DOS the end-of-line notation is , in Mac it is and in unix it is . In most text editors the end-of-line character(s) is (are) inserted by pressing or . This produces a line break in a text file. Otherwise the end-of-line characters are invisible. Square brackets, [], enclose a construct which can occur 0 or 1 times. Curly brackets, {}, enclose a construct which can occur 0 or more times. A term in pointed brackets and the brackets, for example, must be replaced by appropriate text. Other text, Subject: for example, must appear just as shown. may contain any ordinary text typed with an editor, excluding end-of-line characters of course. is any ordinary text including end-of-lines and excluding the message separator at the beginning of a line. 2. Every message must have the first line. [To:] must be a name in the directory of your FirstClass server or a valid Internet address. A valid Internet address has the form "[,] @", not including the quote characters of course. The "," portion is optional. The remaining portions are required. These are two valid Internet addresses for me. peter_easthope@gulfnet.pinc.com Peter Easthope, peter_easthope@gulfnet.pinc.com sr checks for an @ character in the address. If one is found the address is assumed to be an Internet address and the characters ",i" are sent after it. Do not put ",i", ",I" or ",Internet" after an Internet address in the KTFC OutFile. If you do, this gateway identifier will be duplicated and the address will fail. 3. The "Copies:" section of the message header is optional. 4. The "Subject:" line is necessary and may not occupy more than one line. The of the subject line may be empty. 5. Limitations on with MS-DOS Kermit are described under System Specific Notes. 6. The OutFile can contain more than one message. A message separator line, a line beginning with the message separator defined in the User Configuration section of prolog, separates messages. KTFC is distributed with the separator being "**EndOfMsg**", not including the " characters. 7. No messages after two consecutive separator lines are sent. 8. All lines between the "Subject:" line and the next message separator line, or the end of the file, are included in the message body. If one of your messages must contain a line beginning **EndOfMsg** change the message separator. Refer to "FAQs > I want to send a message which contains ...". 9. If the message separator is immediately followed by the character n, sr will not send the signature lines after the message text. 10. The message separator is not required after the last message. The end of the file is the end of the message. ** Receiving a message Type the command to invoke Kermit to process sr and strike the or key. With MS-DOS Kermit version 3.1.6 and KTFC version 0.5, type this. msk316 -f sr0.5 Messages in mailout will be sent and incoming messages which have not previously been read will be appended to the file mailin (yyyymmdd.in if the dated InFile is configured). ** Signature Lines "Signature" lines are applied to the end of each outgoing message by the procedure Sig invoked in ProceedMsg. The signature lines are defined at the end of the user configuration section of prolog. The number and contents of the signature lines can be changed by the user. The value assigned to SigLen must be the number of signature lines. If, for example, 4 signature lines are intended, the line "def SigLen 2" must be changed to "def SigLen 4". The 3rd and 4th lines must be defined; ie. lines "def \&s[3] {...}" and "def \&s[4] {...}" must be added immediately following "def \&s[2] {...}". The signature on an individual message can be suppressed by appending the character "n" to the separator. This is shown in the formal syntax above. "n" is meant to suggest "no signature". The signature can be eliminated permanently from all messages by commenting the line "xif not equal ... {Sig}" near the end of ProceedMsg in the sr file (ie. by inserting a ";" at the beginning of the line). ** Serial Port Problems This topic really belongs to Kermit rather than to KTFC but some details are just too significant to ignore. Kermit documentation recommends RTS/CTS flow control, sometimes called hardware flow control, in preference to XON/XOFF flow control. The serial link between a computer and an external modem can be deadlocked by changing the flow control in Kermit to RTS/CTS before changing the flow control in the modem. When this is done Kermit waits indefinitely for CTS assertion from the modem but the modem never asserts CTS because it continues to use XON/XOFF flow control. If you have an external modem, view the modems\*.scr file with the editor. The command to turn on RTS/CTS flow control in the modem, "output AT &H1&R2\13" for example, should preceed the command "set flow rts/cts" which sets flow control in Kermit. Every serial port and internal modem in a PC with the old ISA bus had a Universal Asynchronous Receiver Transmitter or UART. (A machine with the newer PCI bus may be delivered with Windows specific hardware such as a Winmodem. These notes on serial ports and UARTs may not apply to such a machine.) Communications through such a serial port or modem pass through a register or buffer in the UART. If the register or buffer is overrun, MS-DOS inserts a BEL character in the data stream. You will notice the BEL character because a tone will be emitted from the system speaker. If this error occurs in characters which KTFC depends upon to make a decision, it will fail. When KTFC fails you might find a BEL character among those it was processing. Kermit documentation, KERMIT.BWR for example, recommends a UART referred to as a 16550A to avoid errors. Additional information about UARTs can be found in reference 4. The 16550A is found infrequently on serial port cards for the ISA bus. If you have an external modem on an ISA system, the UART of the serial port is likely to be poorer than the 16550A. If this is the case the external modem is unlikely to work reliably at speeds above 9600 b/s. If your modem is faster and you observe errors, set the speed down to 9600 b/s. Make a backup copy of the modems\*.scr file and then open your editor on it. Look for a line such as "set speed 57600". If the speed setting is that simple, change it to "set speed 9600" and save the file. In some *.scr files the speed is set by a more complex process. In such a case study the code carefully before changing it. This is how I modified ppi.scr for a Practical Peripherals MC144MTII. Originally the speed was set by "atok 38400". That line was commented and a line "atok 9600" was inserted. That set the intended speed. Following the line "chkok {Can't initialize modem}" the line "goto config" was inserted. That skipped the model specific speed setting process. Following the label :CONFIG are these lines. echo Enabling modulation negotiation... output AT \m(_modcmd)\13 chkok {Can't enable modulation speed negotiation} define _modcmd These four lines are commented so that negotiation does not push the speed up again. With these changes saved, ppi.scr reports a connection at 9600 b/s. ** Tidying the Mailbox Old messages accumulate in the mailbox on the FirstClass server. The user can log in interactively and delete unwanted messages. This process is automated by scan. This script examines each message in the Mailbox. If a message is unread scan reads it into the InFile just as sr does. If a message has already been read, scan calculates the age---the difference in days between the creation date and the current date. Each message older than the value in the variable MsgLife is a candidate for deletion. If the variable CDM has the value 1 the user is prompted to confirm deletion. If CDM is 0 the message is deleted without user confirmation. According to previous examples, the script is invoked with the command "msk316 -f scan0.5". ** Scanning Other Conferences Many users routinely read messages in conferences other than the Mailbox. This includes conferences in OneNet. The scan script automates retrieval of such messages. Before scan can be applied, the path from the home conference to each conference to be scanned, must be placed in the User Configuration section at the beginning of the scan script. For example, on the GulfNet FirstClass server the conference "Science Talk" is reached by keying <6> <1> <1> <3> ; the path is 6 11 3. Note the path from the Home conference to each conference you wish to scan. Open the editor on the scan script and find the definition of ListLen. ListLen must be given the number of conferences to be scanned. Change the 0 in the line "def ListLen 0" to the number of conferences you want to scan. Next, the values for the \%d[ ] array must be inserted. Each line beginning with "def \%d[1] {3 3}" specifies a path inside the {} brackets. Decomment ";def \%d[1] {..}" and ";def \%d[2] {..}"; ie. remove the ";" character at the beginning of each line. Add additional definitions as required. The index of the last component of d must be the value of ListLen. Inside each pair of {} brackets put a path as described in the preceeding paragraph. Save the scan file and close the editor. With MS-DOS Kermit version 3.1.6 and KTFC version 0.5, type this. msk316 -f scan0.5 The messages retrieved will be found in the file which is also used for incoming mail. Normally I run scan once per day. On average a scan of 18 directories at 9600 b/s takes about 10 minutes. ** Automated Startup MS-DOS can be configured to automate the use of KTFC at startup. Adding these two lines to the end of the autoexec.bat file allows sr to be processed automatically when MS-DOS is started. cd \kermit msk316 -f sr0.5 Modify the cd command if your Kermit directory is not \kermit. Modify the Kermit invocation if you are using a MS-DOS Kermit later than version 3.1.6. A second arrangement automatically opens EDIT on an OutFile when MS-DOS is started. Configure the dated OutFile as described in "FAQ > ... How is the name of the outgoing file changed?" At the end of the autoexec.bat file insert these three lines. cd \kermit msk316 -f datefil0.5 editdate.bat The command "cd \kermit" tells MS-DOS to switch to the Kermit directory. "msk316 -f datefil0.5" invokes Kermit to process datefil. datefil checks whether a dated OutFile exists for the current date. If not, the dated file is created and a template of address, subject and message separator lines are written to it. Finally, a MS-DOS batch file containing the command to invoke EDIT on the dated OutFile is created in the Kermit directory. Processing of datefil is then complete and Kermit exits. "editdate.bat" invokes EDIT on the dated OutFile. The user can then compose one or more outgoing messages. When that is complete the user should exit from EDIT. Message transfer is initiated with the command "msk316 -f .out" where is typed in the format yyyymmdd. Variations of these automation arrangements can be adapted to other systems. ** FAQs *** Q. Why are sr and scan not integrated into a single script? sr pushes the limits of MS-DOS Kermit. All the macros required to implement the capabilities of sr and scan in one script can not be defined. If scan is configured to read several conferences, it requires much more time to process than does sr. I run sr several times each day to update the mailbox; usually scan runs only once per day. *** Q. scan connects to the server and reads a few conferences. Then the screen goes blank. What is wrong? Nothing. The screen fills and then clears. There is a delay before writing to the fresh screen as scan processes a big directory. *** Q. How can interpretation of a Kermit script be interrupted other than by switching off the power? A. +; hold down the key and strike . *** Q. With MS-DOS Kermit, why is there a period at the beginning of each blank line in an incoming message? A. This is a side effect associated with a "work around" for an idiosyncrasy of MS-DOS Kermit. See System Specific Notes > MS-DOS Kermit > The Side Effect Problem. *** Q. My InFile is getting too big. What can be done? A. The simplest solution is to delete the file. In MS-DOS type "del mailin". If you want to save the messages, the file can be renamed; for example, type "rename mailin mailin1". *** Q. What is the purpose of the line "log session \v(ndate).log" in the User Configuration section of prolog? It invokes session logging, which is explained in _Using MS-DOS Kermit_. To activate session logging decomment these lines. ;if exist \v(ndate).log del \v(ndate).log ;log session \v(ndate).log KTFC will process faster when it is not logging a session. *** Q. Incoming messages are placed in mailin but I want them in files named according to date of receipt. How is the name of the incoming file changed? A. The name of the incoming file is the value in the macro variable InFile defined in the User Configuration section of the prolog file. Decomment the line ";asg InFile \v(ndate).in". An example of such a dated file name is 19990627.in. *** Q. Outgoing messages are placed in mailout but I want them in files named according to date. How is the name of the outgoing file changed? A. The name of the outgoing file is the value in the macro variable OutFile in the prolog file. Decomment the line ";asg OutFile \v(ndate).out". If sr is executed on June 27 of 1999, it will try to send messages in a file named 19990627.out. If no such file exists, no messages will be sent on that day. *** Q. Old messages are accumulating in my Mailbox on the FC server; deleting them interactively is tedious. How can old messages be deleted from the server automatically? A. Run the scan script. Messages older than MsgLife will be deleted. MsgLife is assigned a value near the beginning of the scan script. Change the value if you wish. *** Q. What is the purpose of the CS flag in the prolog script? A. CS is the acronym for Confirm Send. With CS set to 1, sr will read each outgoing message in the OutFile and then prompt the user for confirmation before sending. When you tire of giving this confirmation, use the editor to set the value for CS to 0. *** Q. What is the purpose of the DAR flag in the prolog script? A. DAR is the acronym for Delete After Receipt. With DAR set to 1, sr and scan will attempt to delete each unread message in the Mailbox after reading it. If INPUT of a message fails while it is being received and DAR is set to 1, there is a possibility of the message being deleted before it is retrieved from the server correctly. Most users will be best served by leaving DAR with the value 0 and relying on scan to delete outdated messages. *** Q. I want deletion of messages to occur without the prompt for confirmation. How do I turn off the prompt? A. The prompt to confirm deletion occurs or not accordingly as the switch CDM is set to 1 or 0. When you tire of giving this confirmation, open the editor on prolog and set the value for CDM to 0. *** Q. Processing of sr (or scan) failed while a message was being received. What should be done? Check that your modem has "hung up" and then restart the script to finish processing. The failure probably resulted from a serial port error, discussed in Serial Port Problems above, or from one of the limitations of MS-DOS Kermit, described in System Specific Notes. In any case the faulted message is no longer unread and will not cause the script to fail again. A message can be read using Kermit interactively and can be recorded in the session log. Session logging is explained in _Using MS-DOS Kermit_. *** Q. I want to send a message which contains a line beginning with **EndOfMsg** but this is the message separator. How can the message be sent intact? A. Change the message separator. Open the editor on prolog and find the variable MSep in the User Configuration. Change the assigned value to any string you wish. The length need not be 12 characters. Choose a string which is not likely to appear in future messages. ** System Specific Notes *** Microsoft Windows Microsoft Windows is not available here. Reports from users are welcome. Appropriate information will be incorporated into documentation of subsequent releases for benefit of MS Windows users. *** MS-DOS The Side-Effect Problem KTFC was developed on MS-DOS Kermit. Originally an incoming message was handled using \v(input) directly. Problems became evident. For example, if an incoming message contained Kermit code, the interpretation of KTFC was "sidetracked". Kermit Support recommended that \v(input) be copied to a macro variable and that subsequently the macro variable be used rather than \v(input). This was implemented in the procedure SaveLine in the sr script. SaveLine prevented Kermit code received by INPUT from sidetracking the interpreter but then a new problem appeared. Lines containing visible characters had a comma appended. This was solved by deleting the last two characters from the line and then writing the line to the file with writeln. Perversely, another problem appeared. A line which was empty was deleted. This was solved by replacing an empty line with a line containing a period. All these features are implemented in the SaveLine defined when KTFC is used with MS-DOS Kermit. With other systems SaveLine is defined to simply record \v(input) in a macro variable. These complications would be eliminated if INPUT simply recorded incoming characters in a buffer where they would remain unchanged and available until explicitly cleared. Other Problems A minus sign "-" at the end of a line in an outgoing message causes that line and the following line to be joined when sent to the server. Avoid ending a line in an outgoing message with a "-" character. Transmission failures for messages containing the characters "\" and "{" have been observed. Leading blanks are stripped from a line when a message is sent. Leading and trailing blanks are stripped from an argument passed to a macro. A problem specific to MS-DOS Kermit can cause script processing to fail. Refer to "FAQs > Processing of sr (or scan) failed ...". *** Oberon I use the PC Native Oberon operating system; see http://www.oberon.ethz.ch/. Kermit is not yet implemented in Oberon so I use MS-DOS Kermit to transfer mail. I reboot the machine with Oberon to read incoming messages and to compose outgoing messages. Edit and ET in Oberon are very well suited to editing message files. The Oberon.Text file contains these groups in the InitCommands section. { DOS.CopyFrom "c:/kermit" mailin ~ } { ET.OpenAscii mailin } These commands are in System.Tool. ET.OpenAscii mailin DOS.CopyTo "c:/kermit" mailin ~ ET.OpenAscii mailout DOS.CopyTo "c:/kermit" mailout ~ *** Unixes and other systems running C-Kermit Testing with C-Kermit on a unix system is on my "to do" list. Reports from users are welcome and appropriate information will be incorporated in future releases. ** Bugs Bug reports and suggestions are welcome. Analysis of a bug resulting from a specific message requires a copy of the message which caused the problem. The user may need Software independent of KTFC to send a message for diagnosis. ** Limitations The limitations of MS-DOS Kermit described in System Specific Notes can not be completely overcome by KTFC. The ability to send and receive attachments using the X-modem protocol imposed by the FC server would be nice. If this can be implemented for C-Kermit it is unlikely to work with MS-DOS Kermit because of limitations described above. Nevertheless, a binary file can be transmitted by ASCII encoding it, with a MIME algorithm for example, and including the encoded file in the body of a message. I have no plans to implement attachment handling. Rather that descend to each target directory from Home, scan might perform a tree traversal. The "*" which marks a FirstClass directory containing unread items might be used to improve efficiency. The sr script pushes the limits of MS-DOS Kermit and the programming requirements for tree traversal are likely to exceed the capability of MS-DOS Kermit. I have no plans for work on this implementation. The calculation of the age of a message does not take account of February 29 in a leap year; the age of a message which is on the server on February 29 will be one day longer than calculated. scan will allow this message to remain on the server one day more than specified by MsgLife. This is unlikely to be seriously harmful. ** Support Are you having difficulty installing Kermit? Are you modifying a KTFC script and in need of help with Kermit programming? Questions about Kermit and Kermit programming should be sent to the Usenet forum comp.protocols.kermit.misc. Not all FirstClass servers subscribe to this forum and you might not have access to it from home. Most public libraries now have Web terminals. Anyone can go to http://www.deja.com/, open an account and have access to comp.protocols.kermit.misc. The Deja account allows subscription to e-mail delivery of the forum. KTFC users can subscribe to the ktfcinfo mailing list. Send a message with empty subject field and empty message body to ktfcinfo-subscribe@egroups.com. You will be asked for a confirmation. Once your subscription has been accepted, you can send support questions to ktfcinfo@egroups.com. To learn more about eGroups read http://www.egroups.com/. To leave the mailing list, send an empty message to ktfcinfo-unsubscribe@egroups.com. Messages sent to ktfcinfo should be plain ASCII text. html code wastes communications and human time; please refrain from sending it. A query posted to ktfcinfo may benefit other Kermit users. I will tend to give more attention to a query in ktfcinfo than to the same query sent in a personal message. Mention your operating system (Linux, MS-DOS or something else), Kermit version number and KTFC version number. Be as specific as possible in describing the problem. If there is an error message, record and report it. Your InFile or OutFile or the session log may be required. If you can not send e-mail, post is acceptable. My address is given below under Registration. Please do not ask for support by telephone. ** References 1. Kermit in many forms is available from http://www.cc.columbia.edu/kermit/ and from ftp://kermit.columbia.edu/kermit/. Kermit softwares are products of Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025, USA. 2. FirstClass is produced by SoftArc Inc. See http://www.softarc.com/. 3. MS-DOS Kermit is documented in _Using MS-DOS Kermit_, Second Edition by Christine M. Gianone, (C) 1992, Butterworth-Heinemann / Digital Press. C-Kermit is documented in _Using C-Kermit_, Second Edition by Frank da Cruz and Christine M. Gianone, (C) 1997, Butterworth-Heinemann / Digital Press. Additional information is available from the Web site in reference 1. Features of the Kermit language additional to those described in the manuals are described in files available from the Columbia server, reference 1. 4. Information about UARTs is available at these locations. http://www.linuxdoc.org/HOWTO/Hardware-HOWTO-10.html http://www.redhat.com/support/docs/howto//PPP-HOWTO/PPP-HOWTO-8.html Submit "UART 16550A" to a Web searcher to find additional information. ** Conditions of Use The copyright to each file in the KTFC package belongs to the author. The files are not in the public domain. Please attribute KTFC to the author when mentioning it in a publication. If registered, you may ... modify the files for your individual use. ... use the original or modified files for personal, academic or commercial communications. ... distribute the archive ktfc0d5.64, the archive ktfc0d5.zip or the complete set of 7 files. The package may be distributed via a network from a server freely accessible to the public or by storage media. Regardless of registration you may not ... violate my copyright by plagiarism. This includes appropriation and publication of the name KTFC and of any significant portion of a KTFC file. ... distribute individual files isolated from the KTFC package. ... distribute KTFC under a different name. ... publish similar data under a name resembling KTFC. KtFC, ktfc, KTFC3 and XKFTC, for example, are too similar. ... suggest, imply or state an affiliation between KTFC and an entity other than the author. ... charge a fee for distribution of KTFC. ... distribute KTFC to customers of a business, exclusive of the public at large. This includes distribution on a storage medium and distribution via a network. ... use KTFC within a hardware or software product which is given away or sold. For any use or distribution outside of these conditions please contact the author. ** Fee For an individual, the registration fee is 25 US dollars or 35 Canadian dollars. This covers use of version 0.5 of KTFC and future revisions until further notice. The fee also covers consultation to assist in installing, configuring and troubleshooting up to about 30 minutes of my time. The magnitude of the fee is valid until 2000 August 31 and may change after that date. Everyone mentioned under Thanks is exempt from payment. Extensive time may be required to adapt a script to a specific purpose. Assistance with modification of scripts may be subject to charge in addition to the KTFC registration fee. The fee does not include support for Kermit. ** Registration Registration is by sending me a name, contact address and the fee specified under Fees. The post is not perfectly reliable; I can not take responsibility for a loss of cash or other instrument of payment in the mail. Registration fees are my principal source of income; I really appreciate receiving them. Support can not be provided to users who are not registered. If the fee is beyond your means, let me know. Peter Easthope, peter_easthope@gulfnet.pinc.com 2701 Privateers Road RR2, Pender Island, BC V0N 2M2 Canada ** Thanks to ... Maria Watson for extensive testing. ... the staff of the Kermit Project at Columbia University for assistance with Kermit; in particular to Jeffrey Altman, Frank da Cruz and Christine Gianone. ... Professor Joseph Doupnik for assistance with MS-DOS Kermit. ** History 1999 January Prototype of KTFC developed with Kermit 3.14. 1999 02 16 KTFC0.0 testing. 1999 02 20 Kermit 3.15 installed. 1999 02 20 Attempt to use \fsubstring(\%a,1,1) to identify unread messages. 1999 05 11 \fsubstr(\%m,1,1) successfully identified unread messages. 1999 05 16 Improved extraction of message number. 1999 05 17-18 Incorporated \fsubstr(\%m,1,1) to simplify processing of header of outgoing message. 1999 05 22 KTFC0.1 released for testing. 1999 05 26 Reported bug in handling of a blank character (20_F) in an argument to a macro, to Kermit Support. 1999 05 28 Incorporated minput to simplify handling of special cases of input, including [More] prompt. 1999 05 29-06 03 Corrected syntax of string comparisons; eg. if equal \fsubstr(...) \%m changed to if equal {\fsubstr(...)} {\%m}. 1999 06 05-06 07 Added handling of defective and ambiguous addresses. Various improvements using SWITCH statements. 1999 06 12 Fixed end-of-file handling. Double message separator no longer needed after last message. 1999 06 28 Moved deletion of message into macros. 1999 07 04 Improved the recognition of the end of an incoming message. 1999 07 05-14 Moved all code for receiving messages into macros. 1999 07 15 Added user configuration section at beginning of KTFC. 1999 07 16 Reorganized code preceding macro definitions. 1999 07 17 Released KTFC0.2 for testing. 1999 07 17-18 Improvements to SkipDeja. Kermit 3.16 bug found: leading blanks deleted by INPUT, leading and trailing blanks deleted when argument is passed to macro. 1999 07 22 Improvements in handling of login. 1999 08 23 -1999 09 15 Sending of message header rewritten in macros. 1999 09 22 KTFC0.3 script frozen. 1999 09 22-23 Simple mailbox tidying code added. 1999 11 07 Code to avoid a message number beginning with 0 --- eg. "05". 1999 11 14 KTFC0.4 script frozen. KTFC split into script for sending and receiving messages SR and script for tidying the mailbox TIDY. 1999 12 03-04 Code for applying "signature" lines at the end of a message added to SR. 2000 01 04-20 Added code for reading messages from directories other than the mailbox. 2000 02 01-03 Code common to SCAN, SR and TIDY moved to PROLOG. 2000 02 19-21 Mailbox tidying incorporated into SCAN thereby obsoleting TIDY. 2000 03 01-08 Miscellaneous revisions to README.KFC. 2000 03 09-10 Internet address recognition added; ",Internet" no longer required in address. 2000 03 10 Name README.KFC changed to KTFC0P4.TXT. 2000 03 11-19 Miscellaneous revisions to KTFC0P4.TXT. 2000 03 20 Revisions to KTFC0P4.TXT and preparations of MIME -2000 04 06 archive. 2000 04 06 Error in calculation of age of message with attachment corrected. 2000 04 24-28 Definition of dial and chkmdm macros placed in PROLOG; MSKERMIT.INI and MSCUSTOM.INI are no longer required. 2000 04 28 In SR a bug in inputing control sequences when sending a message was corrected. 2000 05 01-04 Miscellaneous revisions to KTFC0P4.TXT and README.KFC. 2000 05 08 Names of script files changed to lower case. 2000 05 09 Documentation revised accordingly. 2000 05 10 KFTC0.4 Released to the Kermit Project, Columbia University. 2000 05 19 \&o[1] tested in place of OutLine. 2000 05 20 Definition of SaveLine made system dependent. Procedure SLEC removed. 2000 05 19-21 Miscellaneous revisions to ktfc0d5.txt. 2000 05 24 KTFC0.5 Released to the Kermit Project, Columbia University. ** Trademarks "Macintosh", Apple Computer, Cupertino, CA. "FirstClass", SoftArc Inc., Markham, ON. "Kermit", Henson Associates, Inc., New York, NY. Name used with permission by Kermit Distribution, Columbia University Center for Computing Activities, New York, NY. "IBM PC", International Business Machines Corp., Armonk, NY. "Linux", registrant: Croce, William R. Della, Jr., Boston, MA. last listed owner: Torvalds, Linus, Santa Clara, CA. "MS-DOS", "Microsoft Windows", Microsoft Corporation, Redmond, WA. "Red Hat", registrant: Red Hat Software, Inc. Durham, North Carolina. "UNIX" exclusive licensee: X/Open Company Ltd. registrant: American Telephone and Telegraph Company Corporation, New York, NY. last listed owner: UNIX System Laboratories, Inc. Delaware, NJ.