FAST.DOC V4.0 by Brad Ferguson [76354,2733] Revised July 28, 1986 WHAT IS FAST.DOC? This file describes a simple and economical way to read messages and send replies at high speed, all WITHOUT the need for special software. Reading messages and responding to them is done off-line; you pay connect charges only for those few minutes it takes to download Forum messages and upload your replies to them. While some computers have programs that can handle messages efficiently, not ALL do ... and this is the method for the rest of us. Any word processing program capable of storing files as text can be used for FAST.DOC, as can any telecommunications program able to capture and send such files. FAST.DOC can be used at any baud rate. WHAT ABOUT BAUD RATES? Which baud rate should you use for sending and receiving messages? I'd strongly suggest the fastest rate available to you, if you have a choice. For example, while 1200 baud costs about double the per-minute rate of 300 baud during non-prime hours, all sending and receiving is accomplished four times more quickly -- leading to a bottom-line savings of 48%. You need not make special arrangements with CompuServe to upload or download at a rate faster than 300 baud: Just do it. CompuServe's host computers will know what your modem is sending. CompuServe also offers 2400-baud service at some nodes; published hourly non-prime rates indicate a bottom-line savings of 59% over 300-baud service and 22% over the 1200-baud rate. THE OPTION CHANGES YOU'LL NEED FROM THE FORUM To use the FAST.DOC method, you'll have to order some option changes from the Forum. When you arrive at the Forum and get the "hello" prompt, the first menu will appear. On the "hello" menu will be a SET OPTIONS category. Choose it before you do anything else, even if you have messages marked for you. (If you've already changed your options so that you don't get menus, then simply enter OP at the first "Function:" prompt upon your arrival at the Forum.) Follow the directions on how to register option changes. When you've finished, your list of options should read: 1 (SM) Stop After Msgs [Never] 2 (CN) Name [NOTE: Whatever handle you're using] 3 (PC) Prompt Character [] 4 (ED) Editor [EDIT] 5 (SU) Subtopics [...] 6 (HI) High Msg Read [NOTE: Whatever message number applies] 7 (RE) Replies Info [NOTE: This doesn't matter with FAST.DOC] 8 (UM) Use Menus [No] 9 (TY) Type Waiting Msgs [No] 10 (SK) Skip Msgs You Left [No] Notes on the above: The prompt character (item 3) is left blank. Use the EDIT editor (item 4) from now on. EDIT (formerly known as FILGE) is easier to use in any case, and it suits the FAST.DOC method better. For item 5, choose any or all subtopics; it doesn't matter to FAST.DOC. Answering "Yes" to Type Waiting Messages (item 9) will deliver all your pending messages when you enter the Forum. It's an automatic RM command. You may or may not want to exercise this option. If you're in the habit of reading all your messages every time you enter the Forum, then you might do well to answer "Yes." If, however, you're like me and enter the Forum for other reasons -- for example, to go to a conference or download something from the data libraries -- you may not want your marked messages delivered to you every time, but only when you're in a "message mood." In that case, you should answer "No." (Once you've had your pending messages delivered, the "read me" flag is dropped and the only way you're going to find them again easily is to search for them.) The old SIGware allowed you to order Brief prompts through Options. You can't do that any longer ... but you CAN do a SET BR at any "Function:" prompt to accomplish the same thing. Whether you use brief prompts or not makes no difference to FAST.DOC; getting rid of the menus is enough. When you've correctly entered these options, all messages sent to you will roll smoothly onto your screen with no interruptions. You'll have to make sure that your terminal program is set to capture as text everything that happens during the session. This will allow you to read the messages at your leisure, later, when you're off-line. If you have a terminal program that cannot capture an incoming file, you will have to print out the messages in real time, as they come in -- at a substantial reduction in speed, too, since under these circumstances you will HAVE to use 300 baud: No home-use printer can echo a feed at a higher baud rate. CAPTURING A DOWNLOAD WITH FAST.DOC After you've selected all your Forum options, you'll see a "Function:" prompt. First, do an RM and get all the messages marked for you. They'll spool onto your screen and into your capture file. When you get the "Function:" prompt again, it's up to you to decide what to do. If you don't want to see any of the messages to other people, either leave CompuServe by doing a BYE or an OFF, or do a DLn to a Data Library, or whatever else you want. (The letter "n" represents a digit.) If you're done with downloading messages, don't forget to close your capture file. The new SIGware allows you to automatically exclude subtopics in which you have no interest. As a result, when you do an RN or RTN at the "Function:" prompt, you will get only those messages in the subtopics you are interested in. The old SSn command (where, again, "n" represents a digit) is still in effect and has not changed, so you may still choose subtopics to read at any time. (Macro users need not change their message-retrieving macros to suit the new SIGware.) Whichever way you go -- choosing subtopics by using SSn commands or the Options default -- you will still have to figure out which subtopics you're most interested in: General, Star Trek, Doctor Who, the Con Suite, or whatever. (SSn users: Each of these subtopics has been assigned a number, and that's the number that follows the SS part of the command.) THE DIFFERENCE BETWEEN RN AND RTN RN means "Read New"; it is a command that will send you all the messages that have been posted in the Forum, starting with the last message you read. (If you've chosen several subtopics by default through Options, RN will give you only the messages in those subtopics.) These new messages will come your way in strict numerical order. A more useful command is RTN, which stands for "Read Thread New." This will give you all new messages in the context of the threads for which they were written. RTN downloads are much easier to follow, and there's absolutely no reason not to use the command. Therefore, I'll refer to the RTN command for message retrieval. HOW TO DOWNLOAD MESSAGES OF INTEREST If you've used Options to default to subtopics that most interest you, simply do an RTN at the first "Function:" prompt. If you are an SSn user interested in only one subtopic, though, the proper command sequence is: SSn;RTN The semicolon between each command is essential, but do not follow the final command in the string with a semicolon. End your command string with a return. SSn users who want to see messages in more than one subtopic should chain the commands this way: SSn;RTN;SSy;RTN;SSz;RTN Now sit back and watch those messages just FLY onto your screen. By the way, you'll see all those RM messages for you come up again when you do an RN or RTN, and they'll already be flagged as having been read. (The SIGware puts an "X" in parentheses next to the recipient's name and user ID.) Don't worry about it. When you've downloaded all the messages you want, go BYE or OFF at the "Function:" prompt if you're finished with CompuServe. (You'll automatically get the "Function:" prompt when all pending messages have been downloaded.) DEALING WITH ALL THOSE MESSAGES When you've gone off-line, it's time to begin reading messages. Use your own approach. You can print out a hard copy of your messages file; you can scribble notes to yourself as you read and use those notes as a basis for your replies; or, if you have a multi-windowed word processor, you can open the messages file as one window and a new text file, for writing replies, as another. If your computer can "swap" between applications, set your telecommunications program to display your messages file, boot your word processing program as the other application so you can write replies, and just switch back and forth. HOW TO CODE YOUR REPLIES Now with all your messages in hand and a can or six of refreshment by your side -- and without the CompuServe meter tick-tick-ticking away -- you can think about responding to all those people. Here's what a standard message looks like: #: 89365 S2/Star Trek 01-Sep-86 21:22:58 Sb: #89311-Quark Fm: John Smith 12345,6789 To: Jane Doe 98765,4321 What's a Quark, anyway? Wasn't that something in Finnegan's Wake? Or did you mean "NARK," as in "NARC," as in "trouble"? Back to the instructions: As you can see, the Quark message that started this thread was #89311. This particular message is #89365 (the first number you see). We're going to be working with the 89365 number; we'll be ignoring the other one. There are now several ways to reply to this message. The first is by doing the equivalent of an RE, or "reply to message" -- except you won't be doing it in "real time"; you'll be doing it off-line with your word processing program. Boot your word processing program. The first thing you want to do is write something that will tell CompuServe which message you're responding to. That will be an RE, followed immediately by a number -- no spaces, no number sign (#) or anything else. Then simply write your reply. To respond to John Smith's message, just do this: RE89365 John, QUARK was an NBC comedy series that was a parody of Star Trek. It didn't last very long. Richard Benjamin played the captain. /EX S Back to the instructions: What did I do there? Well, the first thing was to do an RE# command so that CompuServe would send the reply automatically to John Smith. (CompuServe looks up whoever sent message #89365 and then relays your answer to him. It saves a lot of trouble.) I followed that command with a return. (By the way, it doesn't matter if you enter any of these commands in caps or lower case.) Then I wrote my message to John. Now this is VERY IMPORTANT. CompuServe limits each line of a reply to a certain number of characters. When you're responding to messages in "real time" and forget where you are, CompuServe sends a bell code after each character as you approach the 80-character limit. (When you get a bell code, your computer should go "beep!" or something else equally disturbing.) Obviously, you won't get a bell code from CompuServe if you're writing replies off-line. To guarantee that you won't go over CompuServe's limit, END EACH LINE ON YOUR SCREEN WITH A RETURN! If you're at the end of a word, which you usually will be, end that line with a spacebar-return so words won't smash into each other when EDIT rewrites your replies. The EDIT editor ignores your returns and inserts its own when it's writing your messages to other people's screens, so don't worry about your replies coming out in crazy line lengths. EDIT will keep things neat. After I finished my message to John, I hit a RETURN, which brought me to a new line. In EDIT, you have to signal your message is completed with an /EX (slash-E-X). Then I hit a return and followed it with an S, ordering CompuServe to store the reply. Then I hit a return again, to make CompuServe accept the S command. In this way, I easily imbedded all my commands in my reply. Another way to respond to a message is by starting a new thread. That's easy, too. Remember that L command? That's what we'll use: L;John Smith 12345,6789;Here's the Answer John, QUARK was an NBC comedy series that was a parody of Star Trek. It didn't last very long. Richard Benjamin played the captain. /EX S2 Back to the instructions: The L command told CompuServe I'm leaving a message. The next thing I did was type a semicolon, and then I told CompuServe to whom I was leaving the message and his user ID. In fact, all you need to leave the message properly is the user ID -- but it looks unfriendly. Remember that if you don't include the recipient's user ID, he won't be able to get the message directed to him when he RMs. Sometimes the SysOps will put in the user ID for you, but why make life more difficult for the SysOps? Do it yourself. I followed the address with a semicolon and the subject of my message. Then I did a return, wrote the message and followed it with an /EX, return, S2, return. Since this is a fresh thread, CompuServe has to be told which subtopic it goes to, so you must follow the S with a 2 (for the Star Trek subtopic); no semicolon is needed between the S and the number of the subtopic. You can string together any number of messages in this way. Just follow one after another, remembering to hit a return after the S command in the previous message so that you have a new line for the next RE or L. Sending a message or reply privately -- so that no one but you and the recipient can read it -- is very easy. After /EX, instead of typing S or Sn (remember that "n" is a digit), just type SP or SPn. The new SIGware allows you to respond nearly automatically to a message via EasyPlex (also known as E-Mail). To do this, instead of doing an Sn or an SPn after the /EX, do an MA. (There is also an MU command to send something to EasyPlex unformatted -- that is, EDIT will not reformat your message to suit the recipient's computer. This is similar to the SU command available for Forum replies. SU and MU are most useful when you're sending keyboard graphics to another person.) You'll want to use MA when you know your recipient won't be logging onto the Forum for a few days, and you want to be sure he or she gets your reply. HOW TO SAVE YOUR REPLIES FILE ON DISK When you've finished writing all your replies, remember to save them as TEXT! This is IMPORTANT, because CompuServe will not be able to make any sense whatsoever out of the compressed binary format computers generally use when storing data on their own disks. UPLOADING YOUR REPLIES TO THE FORUM Now you have to send your replies into CompuServe. The process is very similar to uploading a file, except that it's simpler. Reopen your terminal program. Make sure you've done a couple of things before you call CompuServe. First, make sure your terminal program is set to send TEXT, not XModem or whatever else you might have; CompuServe won't understand anything but text. Second, activate your XOn/XOff protocol; this will allow CompuServe to slow down your message feed if things get a little hairy on the other end. (You'll see the message flow slow down a bit when this happens, but it'll pick right up again a second or two later.) Now get connected to CompuServe and enter the Forum. If there are more messages waiting for you, ignore them for now. At the "Function:" prompt, tell your terminal to send the file of messages you've written, and watch them zip onto your screen and into the guts of CompuServe. While you're watching, you'll see all sorts of horrible things happen. Your messages and their addresses will seem to interrupt prompts from CompuServe. Parts of your messages will seem to be missing or overwritten by CompuServe. You'll be warned about line delays of as much as 21 seconds. You'll think all sorts of things are going wrong. You'll think you've crashed the entire North American datanet. You'll think the FBI will be at your house by daybreak. Well, don't worry. CompuServe is remembering everything you're sending and putting it all in the right place. It just LOOKS like garbage. If you're unsure of what you've done, then after you get the "Function:" prompt again (which you will, once your terminal program has finished sending your message file), do an RS to see all the messages you've just sent. (Refer to the Forum help file for information on how to read-scan messages. Do an H at the "Function:" prompt.) ABORTING AN UPLOAD You're bound to make a typographical or other error once in a while that will force you to abort your upload. (The most frequent cause of FAST.DOC aborts has been when the original messages have been deleted by the SysOps, or they've just plain scrolled off, and CompuServe cannot find the message to which it can send your RE reply.) When this happens, stop your upload immediately. There's little you can do to fix the reply that caused the abort, unless it's a simple typographical error in an imbedded command. If so, go back to your word processing program and fix the mistake. Then delete all replies from your file that have been successfully sent -- otherwise, they will be uploaded twice. If the reply aborted because the message to which you're replying has been deleted, there are only two things you can do. If you remember to whom you wrote the reply and his user ID, send your reply as the beginning of a fresh thread, using the L command. If you can't, the simplest thing to do is delete the reply from your text file. In any case, delete all the replies you have sent successfully, in order to avoid duplication. That's about it. Any problems, get back to me at 76354,2733. STANDARD DISCLAIMER I have uploaded this file to only one Forum: the Science Fiction and Fantasy Forum on CompuServe. You shouldn't be seeing it anywhere else except the Model 100 SIG where permission has been granted to upload. If you do, I'd appreciate knowing about it -- not that I expect a ripoff artist is going to leave this paragraph intact, but you never know how dumb a ripoff artist might be. I also do NOT endorse or guarantee other help files the others don't, that's the author(s)' problem.