Install this file as CHAT HELPCMS on VM/CMS.
.CM File: SUMMARY HELPCHAT A1 (07/08/86 10:31:16) .FO OFF *********************************************************************** * * * A summary of the Chat help files * * * *********************************************************************** This file will tell you where to find what you are looking for. If you have never used the Chat program, you should select either the "Overview" file if you are an experienced VM/SP user, or the "Tutorial" file if you think you would feel more comfortable with a help file designed for novice VM users. *ChatCMD A menu of Chat commands (those you enter after the "===>" sign) CHATDISC How to use Chat as a disconnected answering machine program CHATFILT How to use the Chat message filtering facility CHATNAMES Help information for the improved Chat NAMES command CHATRDRL Technical description of the CHATRDRL reader-scanning module CHATRL Help information for the improved Chat RDRLIST command Install How to install Chat on a public disk or file server Layout A description of screen layout under Chat Messages A description of Chat messages Modem Using Chat on a modem terminal -- selecting the right options Nicknames Chat nicknames conventions Options A description of the Chat options (from nicknames screen) Overview A general overview of Chat for experienced VM users PFkeys PFkeys settings under Chat Relay Communicating with Relays under Chat -- special facilities Requires Technical requirements for running the Chat program Summary The file you are currently reading Tags A description of the status area tags under Chat Tutorial First use tutorial for unexperienced VM users .CM File: TUTORIAL HELPCHAT A1 (05/30/86 18:29:14) .FO OFF *********************************************************************** * * * First use tutorial for unexperienced VM users * * * *********************************************************************** This help file is a general description of the Chat "Network conversation sifting facility" program -- what it is, what it is NOT, and how to use it for the first time. Later, when you have become experienced with the program, you will be able to learn more from the other menu selections, but right now you will only need to read this file and the "PFkeys" file (and possibly the "Layout" file too, if you feel like reading lots of help) before getting started. In this introductory file we will assume that you are already familiar with the standard IBM TELL and NAMES commands and that you know how to query about a user to see if he is logged on. Well, at least you should have read the IBM helpfiles about TELL and NAMES and roughly understood them -- you'll see, Chat is even simpler (more user-friendly) than the CMS commands for network communication... In this helpfile and in all the other ones we will use the convention that "Chat" = the program, while "chat" is the usual english word. Just in case you might come to get confused with the various meanings... First of all you should get a general idea of what Chat does. Chat is not a multi-user Chat machine exec, such as RELAY or FORUM -- nothing to do with channels, /SIGNON commands, private messages, etc. For those who are familiar with these programs, Chat is rather a kind of full-screen TALKTO program including a GONE-like answering machine and much more. But please don't feel discouraged if you don't know anything about GONE and TALKTO -- you really don't need to! Chat is a full-screen program that will interface itself between you and the system to make your life a lot easier when conversing with people on the network. It will receive messages for you, analyze them, strip off the nasty unutterable system prefixes (eg "DMTRGX171I" -- Yuk!), search your NAMES file for the nickname of the person who sent the message and display it in ENGLISH: You'll get "From Christina: Hello, how are you?" Instead of "DMTRGX171I FROM CHZRZU1A(K345762): Hello, how are you?" (Note: this "Christina" is an imaginary person, please don't send any mail to her!) Furthermore, Chat will sort out the messages you send and receive accor- ding to the nickname of the person you are talking with, and display them on different "logical screens" (up to 6 different screens). You will be able to switch from one logical screen to the other at will by pressing a single PFkey. Those "screens" are of the scrolling type, not the "MORE..." type, so that you lose only one message (the oldest one) when the screen becomes full. There is an independent command line for each logical screen so that if you are typing a message on a given screen, you can quickly switch to another one if needed (eg to answer an urgent message from your boss) and then resume the message you had not finished typing by just pressing a PFkey (even the cursor position is preserved across screen switches!). But anyway you won't need to switch screens or do anything complicated for your first use of Chat. And you will only need to learn about two PFkeys: - The "QUIT" PFkey is number 12. You can exit the Chat program anytime by just pressing PF12. Sorry about the incompatibility with the latest IBM standard, but you'll see the reason why QUIT is PF12 and not PF3 when learning the settings of the other PFkeys. - The "Switch to screen number 1" PFkey is PF1 (you can use PF13 as a replacement if your terminal is one of those where pressing PF1 is a real pain, and PF24 = PF12 too). PF1 will be your "home" key, the one to press if something goes wrong and you don't understand what is happening to you. If PF1 doesn't succeed, press the "emergency" PF12 key to exit from Chat... and feel free to have another attempt! Now read carefully before getting started. Find yourself a friend to chat with (preferably an experienced Chat user on a console not too far from yours), and define a nickname for him using the NAMES command (if not already done). Let's assume his nickname is "Mike" (why not?). When Mike is ready to chat with you, quit the help files and issue the following command: (guess what?) "CHAT" You will then be presented with a screen with a darned lot of input fields (don't panic, you won't have to fill them all!) and a bunch of repelling "options" to set ON or OFF and you'll feel your right hand irresistibly going towards the PF12 key... No, not now, you'd miss something!... Hopefully the cursor is placed on a field that doesn't look too bad -- it just reads "1. ________" -- and the fearsome option fields are far below the cursor... Now just key-in "Mike" (no need to remove the trailing underscores) and press the PF1 key. The screen layout will then change to a familiar XEDIT-like command line, with "Screen number 1" being displayed in the status area. And there is a nice "Tell Mike" command in the input area, with the cursor just at the right position. And an empty screen with a red (or just hilighted if your console is a monochrome one) message saying that "This screen is now dedicated to Mike"... Let's have a try and type "Hello, Mike!" and then ENTER. You get a red (intensified) message saying "Starting new Chat session on...", then a green (unintensified) message with "To Mike: Hello, Mike!". Heck!! That darned program is already mal- functionning, it has put two nasty spaces before "Mike"! Doesn't look nice at all! But it did send the message to Mike, no problem there. Some seconds later you get a "From Mike: hiya!" (intensified yellow) and understand why there were two additional blanks after the "To"... Don't feel embarrassed for not having understood it before when it was so obvious, some experienced VM users have had the same reaction before you... Now you can Chat with Mike as long as you want (you just have to type a message, press ENTER and wait for his reply). Don't stay too long, though, because you could get into trouble if another user sent a messa- ge to you while you are trying Chat -- you don't know yet how to handle multiple messages from several users... Not much trouble, anyway; you would just have to press your "home" PF1 key, or the "emergency" PF12 key if you are really lost... Ok, just try it now and come back to that help file when you've done it. You'll then learn some more about multiple screens and screen switching. Well... I guess that I should now change the header to *********************************************************************** * * * Second use tutorial for (less) unexperienced users * * * *********************************************************************** Now that you've learnt how to use Chat to communicate with a single user, you're probably wanting to learn more about the program. If this is not the case, I apologize for having bothered you with all that reading and testing and will be happy to get an angry mail from you (mail to ERIC at FRECP11). The first thing you will have to learn is the setting of the "screen- switch" PFkeys: as you might have guessed, PF2 switches to screen 2, PF3 switches to screen 3, (...) PF6 switches to screen 6. This should not be too difficult to remember... That's the reason why the "quit" key is PF12, not PF3: PF1 = screen 1, PF2 = screen2, PF3 = quit, PF4 = screen 4 and PF12 = screen 3 would have been quite a mess... Now assume you want to talk with Mike AND Christina. You get back to Chat by issuing a "CHAT" command and find yourself back where you had left. You could resume your conversation with Mike if you wanted to. But it's with Christina that you want to talk now. So you press the PF10 key and get back to that unsightly "nicknames screen". The "1." field is now filled with Mike's nickname, userid and node, and the cursor has been subsequently placed on the second field, which reads "2. ________". Quite logically, you enter "Christina" in that field and press the PF2 key, in much the same way as you had entered "Mike" on field number 1 and pressed the PF1 key. You are presented with the second screen, which is now dedicated to Christina (of course you know it is dedicated to her!! That stupid program doesn't need to print that message!). So you start chatting with Christina on screen 2, impatiently waiting to see what will happen when Mike sends a message... Feeling yourself daring, you press the PF1 key to get back to Mike's screen, tell him to send you a message, and quickly sneak out of his screen by pressing PF2... While you were typing a message for Christina ("Well, I'm waiting to s"), you hear a beep, look at the console and realize that you have been switched back to Mike's screen... Here is the message you had asked him to send. You quickly answer "thanks" and get back to Christina's screen to see what happened to the message you were keying in when Mike's message came in. It was apparently removed from the command line while the program switched back to Mike's screen... So you press the PF2 key and, lo and behold, there it is, the message that you had been typing is now back in the command line with the cursor placed in the exact spot where you had left it... You can now resume your message (..."to see what will happen when Mike sends a message") So you start relating your experience with Chat to Christina when you hear a beep (again!), look at the screen and find yourself on screen 3 (three???? Never said I wanted to use that screen!!!!), with the usual messages, "This screen in now dedicated to Bob...", "Starting new Chat session on..." and a message from that guy who just wouldn't let you be yesterday at the party... Curse him!! How do I get rid of him? Perhaps an angry message would do it. Such as "Sorry, I'm busy, another day please!" You send that message and get back to screen 2. Getting curious about it, you press the PF10 key to get back to the nicknames screen and realize that the third field is now filled in with Bob's nickname, userid and node -- as if you had yourself asked to speak with that guy (How did this stupid program DARE think that I might be wanting to speak with such a !"$!"+%!=!"$ ????) Still cursing, you press the PF2 key and start telling Christina about this guy you can't manage to get rid off when you are again pulled back to screen 3! You press the PF2 key immediately, without even caring to read the message -- and get pulled back to screen 3 again!! Bob is now sending a "love" picture to you!!!! And everytime you press PF2 to resu- me your message you get switched back to Bob's screen because another message has arrived!!! Curse that darned program for being so stupid! Hopefully the picture wasn't too long and you had time to send a message to Mike ("Help!! I'm beset with messages from everywhere!!!!") before receiving another "kiss" picture from Bob, which, along with the help messages from Mike and the "What's up? You still there?" from Christina, makes the terminal flash and erratically jump from one screen to the other, beeping as if to announce Doomsday... You helplessly wait for the bombing to end and switch to Mike's screen to read his messages. He tells you to go to the nicknames screen (Yuk!!) and change the "Automatic screen-switch" option to NO. Feeling that you really don't have any other choice, you press the PF10 key and blindly move the cursor towards those unsightly option fields, hoping that you will find the right one and won't do any mistake... "NO"
Phewww... Made it... About three seconds after you have changed the option to "NO", you hear a beep (oh no! Not again!) and you see a blinking yellow tag at the bottom of the screen: "Incoming message on #3". But this time the screen doesn't switch!... Good deal! You neglect the blinking tag and switch to Mike's screen to tell him that you have defeated Bob and thank him for his irreplaceable help... The "Incoming message on #3" tag has now been replaced with a stubborn "Message pending on #3" indication that keeps blinking in the status area... Not knowing that Bob is an awfully nasty person with whom you don't want to talk, Chat keeps reminding you that he has sent you a message and you didn't switch to his screen to read it yet... But otherwise it's convenient to have the nasty messages printed on another screen where you can choose NOT to switch to... Well, now you'd better be trying all that stuff before you forget it. When you've become accustomed to it, you'll be able to wander though the other helpfiles (start with the "Nicknames" file), learning more about the program -- "lentement, mais surement" as we froggies use to say... .CM File: OVERVIEW HELPCHAT A1 (05/30/86 18:28:37) .FO OFF *********************************************************************** * * * An overview of the Chat program for experienced VM users * * * *********************************************************************** This help file is a general description of the Chat "Network conversation sifting facility" program -- what it is, what it is not, and how to use it. In this introductory file it will be assumed that you are proficient with the standard IBM TELL and NAMES commands. To avoid a possible confusion with several other (older) program bearing the same name, I would first like to state that Chat is not a multi-user chat machine exec such as RELAY or FORUM -- nothing to do with that. It is rather a kind of full-screen TALKTO program which includes a GONE- like answering machine, a message filtering program and much more. Apart from the usual RSCS message trimming and nickname-search, Chat will sort incoming and outcoming messages by nicknames and display them on diffe- rent "logical screens". There are 6 different logical screens, and each of them can be "dedicated" to a particular user. Every message sent to or received from that user will be displayed on that screen and will not mess up the other screens. You can switch from one screen to another by pressing the corresponding PFkey and the latest messages printed on that screen will be re-displayed. There is an independent command line for each logical screen, which is automatically pre-set to "Tell nickname", where "nickname" is the nickname of the person to which the screen is dedicated. The contents of the command line is preserved (along with the position of the cursor) whenever you switch from one screen to another. You can therefore switch to another screen to send an urgent message and switch back to the original screen to resume typing your message. There is a special screen, called "screen 0", where all messages will be prin- ted regardless of nickname, thereby simulating the usual VM console out- put. Some messages (eg RSCS messages) will be automatically directed to this screen so as not to mess up the other screens. Getting started with Chat: assume you want to talk to user Mike (from your NAMES file). All you will have to do is enter Chat (by issuing the command: "CHAT"), type "Mike" in the first input field and press the PF1 key. More generally speaking, PFn will switch you to screen number n, and the n-th input area on the nicknames screen corresponds to screen number n. You will then be able to chat with Mike (the messages will appear on the screen as soon as they are received), or with several users at once. You may exit Chat at any time by pressing the PF12 key. If you ever receive a message from a user which has not yet been dedica- ted a screen, Chat will automatically assign the first "free" screen to him and print the message there. Probably the best thing to do now would be to have a try at Chat. You'll then be able to learn more about it by reading the "Layout", "Tags", "Nicknames" and "Options" helpfiles (preferrably in that order). Then you'll have to wade through all the other helpfiles when you have time... Good luck! .CM File: PFKEYS HELPCHAT A1 (05/30/86 18:28:39) .FO OFF *********************************************************************** * * * PFkeys and PAkeys settings under Chat * * * *********************************************************************** The release 1.6 of Chat does not allow the user to change the settings of the PA/PFkeys. This facility will be implemented in a subsequent release. The key settings are currently the following: CLEAR -- Re-display current screen. All screen modifications are lost. PA1 -- Nickname screen: Display the Chat HELP menu. Other screen: Clear the screen output area. The input area and cursor position are preserved. PA2 -- Enter CMS SUBSET mode. All messages will be stacked and displayed upon return. Please note that incoming messages in excess of 255 will be irremediably lost to Chat due to CP limitations. The CP/VMCONIO settings will be turned to OFF before entering CMS SUBSET and possibly changed back to IUCV if the "Trap VM and CP output" option is in effect. You should never try to enter CMS SUBSET by entering "SUBSET" on screen 0 (at least not when VM output is being trapped). PF1 -- Switch to Screen 1 PF2 -- Switch to Screen 2 PF3 -- Switch to Screen 3 PF4 -- Switch to Screen 4 PF5 -- Switch to Screen 5 PF6 -- Switch to Screen 6 PF7 -- Switch to previous screen PF8 -- Switch to next screen PF9 -- Switch to Screen 0 PF10 -- Switch to Nicknames Screen. PF11 -- Force screen into holding status. PF12 -- Exit to CMS. The current settings, including nicknames and all screen displays, will be preserved in a file called "CHAT LASTSESS A0" and restored at the next invocation of Chat. Please note that pressing the PF12 key causes the screen modifications to be lost (ie not saved in the LASTSESS file). You should therefore press the ENTER key, then the PF12 key if you have made modifications to the screen, unless you do not care about losing them. This little annoyance is the consequence of the "safety" of the PF12 exit function that allows you to exit from Chat even when the screen format has been destroyed or is invalid (which can be the case if you use an unsupported console model). Would the modifications be analyzed and kept, there could be a chance of your being irremediably hung in certain (critical) conditions. PF13 = PF1 PF14 = PF2 (...) PF24 = PF12 ENTER -- Nickname screen: Validate screen modifications Other screen: Execute the command typed in the input area Note for french (and possibly other) users: PA1 = AP1 and PA2 = AP2 PF1 = P1, etc. CLEAR = RAB MEM IN (yuk!! Can't imagine a worse translation!) .CM File: LAYOUT HELPCHAT A1 (05/30/86 18:28:02) .FO OFF *********************************************************************** * * * Screen layout under Chat * * * *********************************************************************** Here is a description of the "conversation screen" layout and of the meaning of the various colours/hilightings used by Chat. Each of the six "conversation screens" is divided into three parts: 1) The "output area", which consist of the first 22 (or 30, depending on physical screen size) lines. Both incoming and outbound messages will be printed on that area, as well as possible other messages from the "system" (ie from the Chat program). This area can be cleared by pressing the PA1 key. 2) The "input area" (or "command line"): This 132-character input area allows you to enter commands for Chat to execute. If the screen has been dedicated to a particular user, that area will be automatically filled with a "Tell nickname" command whenever emptied, be it manually (ERASE INPUT + ENTER) or as the result of a Chat command being executed. 3) The "status area", located in the bottom right corner of the screen. Chat will always display a tag in that status area (refer to the "Tags" selection of main help menu for more details on the subject). Output area messages colour/hilight conventions: - Outbound messages (from you) are displayed as nonhilighted green and are prefixed with "To Nickname: " or " " if the screen is a relay screen (see the "Relay" selection of main menu). - Incoming messages from YOU are displayed on screen 0 as nonhilighted blue, without any header, unless you have specifically assigned a screen to yourself. Messages from you include Single Console Image Facility (SCIF) messages and VM/CPCONIO output. - Incoming messages from other users are displayed as hilighted yellow and are prefixed with "From Nickname: " (or unprefixed if the screen is a relay one). - Incoming messages of the "CP WARNING" class are displayed as red, hilighted and blinking and are prefixed with a "WNG From Nickname: " header. Furthermore, a WARNING-class message will always cause an automatic screen-switch to occur, regardless of the corresponding option setting (see "Options" selection from main help menu). - Messages from the "system", including text of user-entered Chat or CMS commands, are displayed as hilighted red. - Messages from the CHATFILT program (see the "CHATFILT" selection from main menu for more details on that topic) are displayed on the current screen as blue & nonhilighted or red & hilighted, as decided by the programmer. See also the "SpecialCMD" selection from the commands menu for more information on these messages. .CM File: TAGS HELPCHAT A1 (05/30/86 18:29:08) .FO OFF *********************************************************************** * * * Status area tags under Chat * * * *********************************************************************** Chat will often display a tag in the status area (at the bottom right corner of the screen) to tell you when a message has been received or when an error has occured. Normal-condition tags are green, error tags are hilighted, blinking red and message receipt ones are hilighted, blinking yellow. Here is a detailed description of the various tags: - "Screen number n" Green, nonhilighted, nonblinking This is the default tag. It tells you the number of the screen that is currently displayed. - "*** Be patient ***" Green, hilighted, blinking This tag is displayed when you press the PA1 key while under control of the nicknames screen, thereby invoking the HELP function. Calling CMS to format the help file can take some seconds, and you should NOT press the ENTER key until the help screen is displayed (that would place you in VM READ status and possibly insert unwanted blank lines in the help text). - "*** Too long ***" Green, hilighted, blinking This tag is displayed when the message you are attempting to send is too long for RSCS (Chat got a "RSCS NOT RECEIVING; MSG TOO LARGE" error from CP). You should move the cursor back and insert a "logical message-end character" (see "Options" helpfile from menu) somewhere in the message, or reduce its length by erasing part of it the input area is preserved). - "Incoming message on #n" Yellow, hilighted, blinking This tag informs you that a NEW message has just been received and directed to the indicated screen. You should switch to that screen as soon as you have finished typing the message or set of messages that you are currently keying in. Anyway, Chat will remind you about that message until you switch to the specified screen to read it, possibly entering "holding" status to ensure that the message is not lost (see below). These tags are displayed as the messages are received, possibly overriding a previous tag. - "Message pending on #n" Yellow, hilighted, blinking This tag informs you that there is a message waiting to be read on the indicated screen. This is a message for which an "Incoming message" tag has already been displayed -- and you have ignored it. You should switch to the appropriate screen to read that message after finishing the message or set of messages you are currently typing. When a message-pending condition occurs on several screens, the message-pending tags are displayed in ascending screen-number order, with only one tag being displayed at a given instant (ie if screens 1, 3 and 6 have a pending message condition, the tag for screen #1 will be displayed until you move to screen 1, at which time the tag for screen #3 will be displayed, etc.) - "*** Holding ***" Yellow, hilighted, blinking When this tag is displayed, you are automatically switched to the appropriate screen (regardless of the "Automatic screen switch" option setting), the bell is rung and all incoming messages are withheld on ALL screens until you press an interrupting key (ENTER, PF, et al.) You must then make sure you have read all the messages on that screen and press ENTER to release the condition. Normal scrolling will then be resumed, possibly leading to another holding condition. Note that while the screen is held and message receipt is withheld, messages in excess of 255 will be lost due to CP limita- tions. If the "Scrolling window" option is set to something higher than 1, there might be unused blank lines at the top of the screen when the holding condition occurs. This is normal since in that case, several lines will be scrolled at once when the holding condition is relea- sed (ie this is NOT a bug). - "*** Error ***" Red, hilighted, blinking This tag indicates an error condition in a command you typed in the command line (eg missing nickname or message text on "Tell" command, "Dismiss" command attempted from screen 0, et al.) The command line is not erased so that you can correct the command and re-execute it. .CM File: NICKNAME HELPCHAT A1 (05/30/86 18:28:17) .FO OFF *********************************************************************** * * * Chat nicknames conventions * * * *********************************************************************** In this file you will find information about the conventions used by Chat for displaying "network addresses" (ie nickname or userid at node), together with some information on Chat's re-routing capabilities and SMSG/SEND/CP TO commands support. I) Displaying nicknames When Chat receives a message from a network user, it will search your NAMES file for the nickname corresponding to that user. If none is found it will have to display the network address "as is". The nickname will be converted to mixed case before being printed, using the following algorithm: - First letter in the nickname and first letter following a non alpha- betical character gets capitalized. - All other letters are converted to lowercase. Examples: Christina, Mr.Brown, Jean-Jacques The maximum nickname length under Chat is 14 characters. This will make it possible to use the person's first name in (nearly) any case without having to truncate it. Since the standard IBM NAMES command does not support nicknames longer than 8 characters, it is strongly recommended that the Chat-NAMES command be used to maintain the NAMES file, at least when nicknames longer than 8 characters are to be added/changed. Refer to the "CHATNAME" selection from main menu for more details on the Chat-NAMES package. If no nickname could be found for the message originator, the full net- work address (USERID at NODE) will be substituted, with the "at NODE" prefix being removed if the message originated from the local node. Additionally, Chat will automatically (and temporarily) assign a special nickname to that user so that you don't have to repeat the full network address each time you send a message to him. That special nickname will be either ":n" or "Relay:n", where "n" is the number of the screen that was automatically assigned to the user. The latter form is used when the userid of the message originator is "RELAY" and allows you to get the "relay-format" output without having to define an actual nickname for that user. See the "Relay" selection from main menu for more details on the subject. Therefore: Nickname -- nickname from your NAMES file USERID at NODE -- full network address for a user which is not in your NAMES file USERID -- user of your own node which is not in your NAMES file :n -- special (temporary) nickname defined for a user not in your NAMES file Relay:n -- same as above, corresponds to an originator-userid of "RELAY" Please note that although a "special nickname" can be used for communica- ting with its associated user in much the same way as a normal nickname, messages to and from this user are still displayed with the full network address, viz USERID at NODE. II) Assigning/un-assigning screens Chat will automatically assign a new screen to any user who sent you a message and has not yet been dedicated a screen (but this can be changed by means of the Chat message filtering program -- see the "CHATFILT" selection from main menu for more details). You will, however, have to manually assign screens to new users when you want to initiate the con- versation. To do this, you will have to switch to the "nicknames screen" by pressing the PF10 key; Chat will then automatically place the cursor on the field corresponding to the first empty screen (unless all six screens have been assigned), and you will just have to enter the user's nickname or network address (see conventions above) and press the ENTER key. You can then switch to that screen and start sending messages. A message will be displayed, both on the selected screen and on screen 0 confirming that the screen was assigned. To un-assign a screen, you can either: (1) Switch to the nicknames screen, move the cursor to the correspon- ding field, type a (single) blank and press the ENTER key. The corresponding screen will be freed but not cleared (ie its con- tents will remain unaltered). (2) Switch to the screen you want to get rid of and type either "Drop" or "Dell" right after the arrow. The latter can be achieved very easily by pressing the backward-field ("|<--") key and typing a "D" over the "T" of "Tell". The screen will then be cleared and un-assigned. See the "Drop" and "Dismiss" selections from the commands menu for more details. The "R." field does not correspond to any message-screen. It is used in conjunction with relays and contains the relay-nickname you are current- ly using. Refer to the "Relay" selection from main menu for more details on this. III) Re-routing facility It may sometimes be necessary to override the default path used by the system to convey your messages to the person you intend to talk to, for example when one of the lines in this path is not operational. This operation is called "re-routing" and allows you to have the messages sent "via" a specific node of the network. This re-routing is not auto- matic since you must determine yourself which node is to be used as a "via" to allow the message to get through. Once you have determined that there is a problem with the default path and you have chosen a suitable "via" node, you must provide this infor- mation by re-assigning the appropriate screen to "nickname via vianode" instead of just "nickname", where "vianode" is the node you want the messages routed via. Example: you (CHATUSER at FRECP11) were speaking with your friend Sylvia (S_KRONER at AUVM) when on of the links on the default path to her (DEARN - GWUVM) suddenly went down. You call for help and the network operator tells you to try to re-route your messages via BITNIC. You change the nicknames-screen entry for Sylvia, which looked like this: 1. Sylvia (S_KRONER at AUVM) to 1. Sylvia (S_KRONER at AUVM via BITNIC) by entering "Sylvia via bitnic" in the corresponding input area. Chat will then automatically re-route all your messages to her via BITNIC. *** Important notes *** 1) Chat will not automatically reset the "via" indication when the failing line is available again. It is your responsibility to check the default path from time to time and to reset the "via" indication (by re-entering the initial definition in the appropriate nicknames screen field -- just "Sylvia" in our example) when the link comes back. 2) All your messages will be traced to the RSCS console log when you use re-routing. This means that the system operator can (technically) intrude into your private conversation -- or he might as well hapha- zardly stumble on one of your messages while searching for something else, without meaning to "eavesdrop" or anything. 3) A "via" indication can be made permanent by defining a ":via" tag in the corresponding entry of your NAMES file, with the "via-node" as value. In the above example, you would have to add a "Tag: VIA Value: BITNIC" line in Sylvia's entry (if using NAMES; if you use XEDIT to modify your NAMES file, this will be a ":via.BITNIC" indication). Note that an explicit "via nodeid" entered along with the user's address on the nickname screen will override the NAMES file indication. 4) This Sylvia Kroner is an imaginary person, please don't try to send mail or IDCARDs there! IV) Alternate message vehicles for messages sent to local users Chat will, by default, send messages to users of the local node with a CP MSG command, which will display a 5-lines message to the user's terminal with time stamp and message text. This is a fast and reliable way of displaying messages, and it will work on any VM/SP system (this is a standard IBM command). It will, however, quickly fill up the screen with blank lines and time stamps (4 messages fill up the screen on a 24-lines display station). You might therefore prefer to have Chat send messages via RSCS (as if the user were from a remote node), in which case they will appear as single-line messages with the standard RSCS header. Please note that because of a bug in the RSCS system, you will get no error message if the target user is not logged on or did not re- receive the message. Also, the message will not be sent if the RSCS sys- tem is down or has crashed. If you want Chat to send the message via RSCS, you must specify a "fake" re-routing indication of "via RSCS", either by entering it on the nicknames screen or defining a "via" tag with value "RSCS" in the NAMES file entry corresponding to this user. Some nodes on the network have installed a general-user command, "CP TO", which will send a one-line message with time stamp and originator's userid. This command is much better than "via RSCS" because the header will be shorter and you will not have to depend on the RSCS system being operational. It will also reduce system overload. Chat can be made to use that command by specifying a "via CPTO" indication for the user. Please note that if the "CP TO" command is not available at your node, no message will be sent and the alarm will be rung to indicate there was an error. Sometimes it can be useful to use Chat to communicate with "conversatio- nal" system accounts such as PVM, MAILER, auto-operator, etc, which do not accept commands sent via regular messages. It is possible to have Chat automatically use the "CP SMSG" command when sending messages by specifying a "via SMSG" indication, preferrably in the user's NAMES file entry (so that the indication is permanent). A similar facility is offered to users who have "secondary user" privile- ges on one or more virtual machines and want to communicate with them by means of the "CP SEND" command: a re-routing statement of "via SEND" will cause Chat to use the "CP SEND" command when "talking" to the corresponding user. Here again, it would be better to include a tag in your NAMES file to make the change permanent. Refer to the available IBM help for more details on the "CP SEND" command. Last, but not least, the default message vehicle ("CP MSG" command) can be changed to either "RSCS" or "CP TO" by defining a dummy entry in your NAMES file with nickname = any value (will be ignored), userid = '*', node = local node and an adequate "via" tag. For example, the default of "CP MSG" could be changed to "CP TO" by adding the following entry into your NAMES file: Nickname: Default_Via Userid: * Node: FRECP11 Tag: VIA Value: CPTO (assuming your own network address is CHATUSER at FRECP11) Since this setting will be extracted from your NAMES file only during initialization (this being for obvious performance considerations), you will have to quit Chat and re-enter it to place any "default message vehicle" change online if it was made from within Chat. .CM File: OPTIONS HELPCHAT A1 (05/30/86 18:28:34) .FO OFF *********************************************************************** * * * A description of the Chat nickname-screen options * * * *********************************************************************** In this file you will find information about the various user-definable options of Chat (those that are listed on the nicknames screen). The settings of these options are saved in the LASTSESS file, together with the screen contents and associated nicknames, and will be automatically re-activated at the next invocation of Chat. Automatic screen switch --------------------- This option indicates whether Chat will automatically switch the screens upon receipt of a message. The initial setting is YES, meaning that whenever a message is received, the input area of the current screen will be saved and the screen corresponding to the message-originator will be automatically displayed. It is strongly recommended that this option be changed to NO as soon as you become proficient with Chat. The reason why the initial setting is YES is that it allows a novice Chat user to get out of a screen he has inadvertently switched to as soon as he receives a message (eg from an experienced user teaching him how to use the program). Setting this option to YES can be useful if you have logged on to VM only to receive (possible) messages from other users while you are busy doing something else. When this option is set to "NO", an "Incoming message on #n" tag will be displayed in the status area whenever a new message is received. You will then be reminded about all messages that you have not already seen by a "Message pending on #n" tag in the status area. See the "Tags" selection from main menu for more details on those tags. Note that the screen will still be automatically switched, regardless of the setting of this option, whenever a screen enters "Holding" status or you receive a "CP WARNING" from a system operator. Ring alarm upon screen switch --------------------------- This option controls whether Chat will ring the bell when an automatic screen switch occurs. The default value is YES, and it is recommended that it be left active unless you leave the "Automatic screen switch" option active too. You will therefore be informed of any "unexpected" automatic screen switch caused by a holding condition on another screen or by a warning from a system operator. Ring alarm upon message receipt ----------------------------- This option controls whether Chat will ring the bell when an incoming message has been received. The default option is YES, and its setting is only a matter of personal taste. Keep a log of all transactions ---------------------------- When this option is set to YES, all incoming and outcoming messages will be logged in separate disk files ("nickname LOG" or "ALL LOG" for screen 0 messages). The default setting is NO. You should be aware of the fact that changing this option to YES is likely to use up an important amount of disk space, especially if you often use RELAY. Note that this option will be automatically cancelled (to avoid repeated error messages) when- ever a severe disk error occurs (eg disk full, disk not accessed, disk is R/O). Also, messages issued by the CHATFILT filtering program (qqv) will not be logged to disk. The filemode of the LOG files can be changed by means of the "Chat log filemode" option (see below). Translate: Input to lowercase --------------------------- This option should be set to YES if (and only if) you use an all-upperca se terminal. This will cause your output to be translated to lowercase, with capital letters being inserted wherever required, ie at the begin- ning of the sentence, after punctuation marks (!?.) and whenever an isolated "i" appears. Example: HERE'S A SAMPLE SENTENCE. CHAT WILL MAKE IT NEATER, I'M SURE IT WILL! --> Here's a sample sentence. Chat will make it neater, I'm sure it will! Trap VM and CP output ------------------- This option controls whether VMCONIO and CPCONIO output are trapped by Chat or not (if you do not know what VM/CPCONIO means, you should leave that option disabled). The default value is NO, and only experienced VM users should consider changing it to YES if necessary. Note that it is not possible to issue a "CP SET VM/CPCONIO OFF/IUCV" command from within Chat since the preset value for these options will automatically be re-inforced by Chat after execution of a CMS command (in case a "stupid" exec might have tampered with them). Chat will automatically turn both options off before entering CMS SUBSET (PA2 key) so that you are resto- red to the normal CMS environment. Please note that VM/CP output in excess of 255 lines will be directly output to the screen (as if they had not been trapped at all). This is a restriction of the operating system. When trapped, VM/CP output will be printed to screen 0 as blue, normal intensity. It will be logged to the "ALL LOG" file (if applicable). It will not be passed to the CHATFILT filtering program (qqv) for proces- sing. The author will not feel responsible for any hanging/loop condition occur ring under Chat with this option active, unless it can be proved that the problem was due to a bug in Chat rather than to the inexperience of the user. Message-end char -------------- The logical message-end character, if defined, allows you to split a message line into several "physical" messages to be sent to the same user. For example, if the message-end character is set to "%", issuing a "Tell Eric Hello!%How are you?%Did you get my note?" will send three different messages to user Eric and is virtually equivalent to: "Tell Eric Hello!" "Tell Eric How are you?" "Tell Eric Did you get my note?" This option is particularly useful on slow modem terminals where it is necessary to minimize the number of I/O operations. The default value is OFF. PF-keys simulation ---------------- This option should be activated if (and only if) you use Chat from a terminal which does not have any PF-key. It will allow you to "simulate" a PF-key depression by entering its number in the command line, either directly after the "===>" arrow or just after a "Tell nickname" command and pressing the ENTER key. For example, both "===> 10" and "===> Tell Eric 10" will "press" the PF10 key. Since there is no input area on the nicknames screen which would allow you to switch to a message-screen by typing its number and pressing ENTER, it was decided that pressing ENTER without altering any field will switch you from the nicknames screen to screen 0 (from where you will be able to switch to any other screen). Please note that inserting a blank before a numeric value in a "Tell nickname" com- mand will disallow PF-key simulation, as will any character entered after the numeric value itself, making it possible to send messages star ting with numeric values to a user even though the PF-keys simulation option is active. For example, "===> Tell Eric 10" and "===> Tell Eric 10 miles away." will both be processed as regular messages. Scrolling window -------------- This option indicates how many lines should be scrolled when the last line of the screen has been used and another line must be printed. The default value is 1 line and causes a line-per-line scrolling. It is strongly recommended that this value be increased to 6 or more when Chat is used from a slow terminal, since it will reduce I/O transfer in a significant proportion (see the "Modem" selection from main menu for more details). The best way to understand how this "scrolling window" actually operates is probably to try setting it to 5 or so and observing the result... Line-end character ---------------- Similar to the message-end character, the logical line-end character allows you to enter more than one Chat/CMS command on a single physical line, thereby decreasing the number of I/O operations required to enter the commands. This option is strictly identical to the CP TERMINAL LINEND feature. The default setting is OFF. Translate: Output to uppercase ---------------------------- You should set this option to YES if (and only if) your terminal is una- ble to handle lowercase characters properly. It will convert any and all screen output to uppercase, thereby effecting a software "A,a / A" key. Chat log filemode --------------- When used in conjunction with the "Keep a log of all transactions" featu- re, this option allows you to change the default filemode to be used for the "nickname LOG" files. The default is "A" and can be changed to anything in the A-Z range as required. Please note that specifying an invalid filemode will cause an error message (from CMS) to be displayed and will automatically cancel the "Keep a log of all transactions" option (to avoid repeated error messages). .CM File: MESSAGES HELPCHAT A1 (04/28/87 14:49:18) .FO OFF *********************************************************************** * * * A description of Chat messages * * * *********************************************************************** Here is a detailed description of all the messages from Chat. Please note that status area "tags" are dealt with in another section. - "This screen is now dedicated to Nickname (userid at node)" (red, hilighted) This message is automatically issued by Chat whenever a new screen is allocated to a user, be it manually (if you entered his name on the nicknames screen) or automatically (if he sent you a message and a new screen could be allocated for him). - "Screen number n now dedicated to Nickname (userid at node)" (red, hilighted) This message is displayed on screen 0 whenever a screen is allocated to a user, while the preceding message ("This screen is now dedicated to...") is issued on the corresponding screen. - "Starting new Chat session on mm/dd/yy hh:mm:ss" (red, hilighted) Whenever Chat must print something on a screen which had not yet been modified since you last entered Chat, it will be preceded by that message to introduce a discontinuity in the screen as well as in the corresponding log-file (if any). That way you will always be able to tell when a break occured in any given conversation, and when it was resumed. - "Disconnected at mm/dd/yy hh:mm:ss" (red, hilighted) This message will be displayed after you issue a Chat "Disconnect" command to provide a useful time stamp. It will appear only on those screens which have been modified during your disconnection. - "Reconnected at mm/dd/yy hh:mm:ss -- nnn message(s) on this screen" (red, hilighted) This message will be displayed upon reconnection from a Chat "Disc- onnect" command to indicate the amount of messages that were dis- played on the corresponding screen during your disconnection. This information is very useful since some of them might have "scrolled out" of the physical screen. It will not be printed on the screens which have not been altered during your disconnection. - "Unknown CP/CMS command" (red, hilighted) Similar to its CMS equivalent, this message indicates that you have attempted a command that is unknown both to Chat and to CMS. - "Invalid SUBSET command" (red, hilighted) Similar to its CMS equivalent, this message indicates that you have attempted a CMS command that is not valid when issued from CMS "SUBSET" mode. Note that this can only happen if you have invoked Chat from CMS SUBSET mode, in which case a warning message will have been displayed at initialization. - "Chat: command_text" (red, hilighted) This message indicates that the command you have entered has been interpreted as being a Chat command and was executed. This does not necessarily mean that it executed successfully, though: another error message might follow. - "CMS: command_text" (red, hilighted) This message indicates that the command you have entered has been interpreted as being a CMS command and was executed. This does not necessarily mean that it executed successfully, though: another error message might follow. - "Missing argument" (red, hilighted) This message is self-explanatory, and relates only to Chat commands. - "Invalid argument" (red, hilighted) This message is self-explanatory, and relates only to Chat commands. Typical invalid arguments are: userid or node longer than 8 charac- ters, non-decimal argument, invalid CMS fileid, etc. - "File not found" (red, hilighted) This message is self-explanatory. It relates to the Chat "Picture" command. - "Warning -- disk-logging option has been cancelled." (red, hilighted) A permanent error occured while writing to a disk logfile. Since repeated attempts to write to the logfile disk (as specified by the "Chat log filemode" option on nicknames screen -- see "Options" selec tion from main menu for more details on the subject) would only cause repeated occurences of the error, and consequently repeated error messages, the disk-logging option has been automatically cancelled. You should correct the problem and set it back to "YES" to resume disk logging. Typical permanent errors are: "disk not accessed", "disk is R/O", "disk is full", etc. Note that "invalid character in fileid" is not considered as a permanent error since it might affect only a speci- fic logfile (invalid character in nickname). - "Warning: you have entered Chat from CMS SUBSET mode." (red, hilighted) This message is self-explanatory and is displayed at initialization when the CMS SUBSET mode is found to be active. Chat will function correctly under CMS SUBSET but some commands might be rejected by CMS. *********************************************************************** * * * Severe errors which cause Chat to terminate * * * *********************************************************************** - "DMSCHT001E Not enough storage to start Chat." This message is self-explanatory. There is no other solution than to free some storage space and call Chat again. This can be achieved by exiting XEDIT, FILELIST, RDRLIST, NAMES, or any similar environment that requires a lot of storage; a "NUCXDROP *" command might free a little space, and releasing some (unused) disks would probably be very efficient. - "DMSCHT002E Chat should not be called recursively." You have attempted to call Chat recursively, issusing a second CHAT command from either the Chat environment itself or another environ- ment (such as XEDIT or RDRLIST) that you had previously called from Chat. In that case you will get back to Chat by successively quitting one (or more) environment. - "DMSCHT003E Error calling HNDIUCV." The CMS internal command "HNDIUCV" returned an error condition to Chat. You should try to call Chat anew after a "cold" start of your virtual machine (ie log off the system and log on again). Contact an experienced Chat user or a system programmer if you get the same error again. - "DMSCHT004E Error calling CMSIUCV." The CMS internal command "CMSIUCV" returned an error condition to Chat. You should try to call Chat anew after a "cold" start of your virtual machine (ie log off the system and log on again). Contact an experienced Chat user or a system programmer if you get the same error again. - "DMSCHT005E Error calling HNDINT." The CMS internal command "HNDINT" returned an error condition to Chat. You should try to call Chat anew after a "cold" start of your virtual machine (ie log off the system and log on again). Contact an experienced Chat user or a system programmer if you get the same error again. - "DMSCHT006E Path to "*MSG" unexpectedly severed." The IUCV-path to the Message System Service handler was unexpectedly severed. You should try to call Chat anew after a "cold" start of your virtual machine (ie log off the system and log on again). Contact an experienced Chat user or a system programmer if you get the same error again. - "DMSCHT007W Charlot is in place and already trapped by another program" You have tried to invoke Chat with the Charlot program being active and already "trapped" by another message-processing program. The status of the Charlot trap has been left unchanged. You should termi- nate the program that is currently trapping Charlot and re-issue a CHAT command. A "Charlot Terminate" command, or a cold start of your virtual machine (log off and log on again) will clear the problem if the trapping program has abended. - "DMSCHT008W You must issue a "CHAT NEW" command to place your new version online." You have received a new version of the Chat package on your disk, and the version that is currently loaded in your virtual storage is an obsolete one. You should issue a "CHAT NEW" command to discard the version in your virtual storage and place the new one online. If the problem persists, try to order the "CHAT EXEC" and "CHAT MODULE" files from Netserv, receive them, and try again. Contact the author if this does not fix the problem. - "DMSCHT009E Chat was started in disconnected mode with console stack empty." You have started Chat while your virtual machine was in disconnected mode (probably from your PROFILE EXEC, after being AUTOLOG-ged), and the console stack was found to be empty. Chat is not able to function in disconnected mode, except when under control of the Chat "Discon- nect" command, since it obtains command from the virtual console. The only way to have Chat function from a disconnected virtual machine is to stack a "Disconnect " command in the console stack prior to invoking it. Refer to the "CHATDISC" selection from main menu and to the "DISConn" selection from the commands menu for more details. - "DMSCHT010E Chat cannot be used on a teletype terminal." You have started Chat from a teletype terminal (ie one without full- screen capabilities). Chat requires a full-screen terminate to operate properly. - "DMSCHT011E Error reading NAMES file." An I/O error occured while reading your NAMES file into storage. You should try to enter Chat again and, if the error occurs again, contact your system support personnel. - "DMSCHT012E Cannot read NAMES file from a CDF (blksize 800) disk." Chat uses a very efficient method to read your NAMES file. This method is about 10 times faster than the "normal" one, but for technical reasons it cannot work on old "CDF" architecture disks. If you get this message, you should probably consider re-formatting your A-disk to "EDF" architecture (ie blocksize 512, 1k, 2k or 4k). This will result in faster and more reliable I/O operations from CMS. CDF disk support has been kept in CMS only for upwards compatibility reasons. .CM File: REQUIRES HELPCHAT A1 (09/20/86 20:41:04) .FO OFF *********************************************************************** * * * Technical requirements for Chat * * * *********************************************************************** Chat requires VM/SP Release 3 or above for all of its components to function properly. VM/SP 2 is not suitable since it lacks the CMS IUCV support (HNDIUCV and CMSIUCV system macros). There is no problem about running Chat on a VM/SP 4 system -- on the contrary, better performances can be expected on a VM/SP 4 system due to CHATFILT and CHATDISC being EXECLOADed by CHAT EXEC. Console support: Chat should support any kind of full-screen terminal with a "decent" screen size. All data streams have been optimized so as to ensure fastest possible I/O response time and best operator eye comfort. Model 5 terminals (27x132) are supported in 24x80 compatibility mode only. Supported models are: 3277-2 (no blinking, no colour, 24 lines) 3178-2 (no blinking, no colour, 24 lines) IBM PC (no blinking, no colour, 24 lines) 3190 (no blinking, no colour, 24 lines, in 4-sessions mode only) 3278-2 (blinking, no colour, 24 lines) 3278-3 (blinking, no colour, 32 lines) 3278-4 (blinking, no colour, 43 lines) 3278-5 (no blinking, no colour, supported in 24x80 mode only) 3279-2 (blinking, colour, 24 lines) 3279-3 (blinking, colour, 32 lines) 3279-4 (blinking, colour, 43 lines) 3279-5 (no blinking, basic-colour, supported in 24x80 mode only) 3179-G (blinking, colour, various user-definable modes) 3180 (blinking, no colour, various user-definable modes) 3278-2A (no blinking, no colour, 20 lines) 3279-2C (no blinking, basic-colour, 20 lines) Models known NOT to be supported: 3277-1 (12 lines, 40 columns -- screen is too small) 3190 (in native mode, a 3190 is supported only as a 24x80 device in "big characters" mode) On the above table, "blinking" only indicates whether Chat can support the feature at all on this type of terminal or not. Some terminals mar- ked as "blinking" might still not have any blinking capability because of the controller they are connected to. A console marked as "no blin- king" might have blinking capabilities but Chat would not be able to use them. Similarly, "colour" indicates that 7-colours mode is supported if available. Chat might still function on other console models. As a rule of thumb, Chat should be able to handle any 3270-compatible console which either has a 24x80 compatibility mode or has a physical screen width of 80 columns or less and not less than 20 physical lines. Consoles with more than 43 lines will be supported in 43-lines mode. Please report to the author (Eric Thomas ) if you have any console support problem (Chat can handle both new-format and old-format data streams, the only problem being to select the correct one). Removal of unwanted control characters: Chat changes all characters whose EBCDIC code is in the X'00' --> X'3F' range to blanks to avoid hanging the console. This can result in special (printable) characters being changed to blanks on some console models, but the same characters would hang some modem-using emulators... Storage requirements: Chat uses a free storage work buffer of about 30k-bytes. The total storage space used up by Chat is approximately 45k-bytes (program + buffer). CPU time consideration: Chat is an assembler language program and is therefore much faster than any equivalent REXX or even EXEC2 program. There are, however, some operations that intrinsically require a large amount of CPU time. The following steps can be taken to reduce Chat's CPU usage if really necessary: 1) Turn the "Automatic screen-switch" option off. 2) Set the "Scrolling window" option to a larger value. 3) Avoid using a CHATFILT exec -- erase it or make it the simplest possi- ble. Do not issue any CPU-time consuming option from it, notably no NAMEFIND command. 4) Turn the "Keep of log of all transactions" option off. 5) Set the "Message-end character" OFF 6) Set the "Line-end character" OFF (if not using a modem) 7) Avoid using a personalized CHATDISC exec -- just erase it and let Chat send the standard message to everybody. 8) Turn both "Translate:" options off, if at all possible... In fact the options that require the most important amount of CPU time are the 3278 to 3277 data stream conversion (which cannot be turned off and is required only for 3277-type terminal, ie those not capable of blinking) and the "Translate output to uppercase" option, but it is impossible or not advisable to turn them off. I/O speed considerations when used on modem line: See the "Modem" option from the main menu. .CM File: AMPRSAND HELPCHAT A1 (05/30/86 18:27:18) .FO OFF & (ampersand sign) The format of the Chat "&" command is: .BX 1 14 73 .IN 2 & any-command-string .BX OFF .IN Putting an ampersand in the first column of the command line before a Chat command causes it to be redisplayed in the command line after it has been executed. This is identical to automatically issuing a "?" command after the command has been executed. The "&" character must be entered immediately following the prompting arrow ("===> "). .CM File: QUESMARK HELPCHAT A1 (05/30/86 18:28:50) .FO OFF ? (question mark) The format of the Chat "?" command is: .BX 1 14 73 .IN 2 ? (operands are ignored) .BX OFF .IN The Chat "?" command will cause the last command entered on the current screen to be re-displayed in the command line. You can then re-execute it by just pressing ENTER. The "?" command must be entered immediately after the prompting arrow ("===> "). Usage notes: 1) The cursor will be placed at the precise location where it was left when the command was executed, ie not necessarily at the end of the command string. This was felt to be much more convenient when retrie- ving command such as "XEDIT FILEn DATA", where you would like to modify "n" and not "DATA". 2) Chat keeps a different "last command buffer" for each screen, thereby making the 6 screens independent from each other. Although this is in most cases much more convenient than a "global" last command buffer, it makes it impossible to retrieve a command that was issued from a screen different than the currently displayed one. 3) Successive execution of a "?" command will cause Chat to swap its "last command" and "previous-to-last command" buffers, thereby allo- wing you to retrieve the previous-to-last command with two successive invocations of the "?" command. The previous-to-last command can also be retrieved with a single "??" command (qqv). .CM File: QQ HELPCHAT A1 (05/30/86 18:28:47) .FO OFF ?? (double question mark) The format of the Chat "??" command is: .BX 1 14 73 .IN 2 ?? (operands are ignored) .BX OFF .IN The Chat "??" command will cause the previous-to-last command entered on the current screen to be re-displayed in the command line. You can then re-execute it by just pressing ENTER. The "??" command must be entered immediately after the prompting arrow ("===> "). Usage notes: 1) The cursor will be placed at the precise location where it was left when the command was executed, ie not necessarily at the end of the command string. This was felt to be much more convenient when retrie- ving command such as "XEDIT FILEn DATA", where you would like to modify "n" and not "DATA". 2) Chat keeps a different "last command buffer" for each screen, thereby making the 6 screens independent from each other. Although this is in most cases much more convenient than a "global" last command buffer, it makes it impossible to retrieve a command that was issued from a screen different than the currently displayed one. .CM File: QUERY HELPCHAT A1 (05/30/86 18:28:49) .FO OFF QUERY The format of the Chat QUERY command is: .BX 1 14 73 .IN 2 Query nickname QELL userid userid AT node .BX OFF .IN The Chat QUERY command will query about another computer user, telling you if he is currently logged on, disconnected, or not logged on at all. If the person you are querying about is on the same computer as you, you will get the answer immediately (see usage note 1). Otherwise the command will be sent through the network to the appropriate computer and there will be a certain delay between your request and the reply. A message saying "LINK NOT ACTIVE", "LINK NOT CONNECTED", "NO PATH TO", etc, means that your request could not be processed due to a problem with the network lines -- just wait for a few minutes and try again. A message saying "userid - DSC" means that the person you are querying about is disconnected, while any other message starting with "userid -" means that the person is connected to the computer and (probably) available for chatting. In either case, the message will be displayed on screen 0 (use the PF9 key to switch to there). Usage notes: 1) Query requests for users not in your NAMES file are treated as a "CMS QUERY" command (see Chat "CMS" command). It is therefore possi- ble to issue a CMS "QUERY" command from Chat without having to prefix it with "CMS". For instance, you could issue a "Q DISK" command from Chat without having to enter "CMS Q DISK", assuming that you do not have any nickname called "DISK". 2) The "QELL" synonym for the Query command allows you to query about the person assigned to the currently displayed logical screen by pressing the backward-field key ("|<---" key located on the right of the second keyboard row -- the one ending with "uiop"), typing a "Q" over the "T" of "Tell Nickname " and pressing ENTER. 3) The "AT" keyword can be entered in mixed or upper case. 4) The "Query" command supports re-routing via another node (ie "SMSG RSCS CMD routenode CMD targetnode CPQ U targetid"). This can be achieved either by specifying "via nodeid" when entering the nickname on the nicknames screen or by defining a ":via" tag in your NAMES file. 5) The "via SMSG" and "via SEND" options of the "Tell" command (qqv) are not supported by "Query" and cause a "CMD SMSG CMD..." command to be issued. 6) The CHATFILT program, as shipped with the Chat package, will automati- cally parse the "userid - DSC" and "userid - cuu" messages and dis- play one of the following user-friendly messages to the current screen: Nickname is not logged on. Nickname is disconnected. Nickname is logged on terminal number xxxxxxx. Note: 'userid at node' will be substituted to 'nickname' if the user could not be found in your NAMES file. .CM File: QUIT HELPCHAT A1 (05/30/86 18:28:52) .FO OFF QUIT The format of the Chat QUIT command is: .BX 1 14 73 .IN 2 QUIT (operands are ignored) .BX OFF .IN Invoking the QUIT command is identical to pressing the PF12 key and will exit from the Chat program. This command was intended mainly as an emer- gency exit command for users who inadvertently entered Chat from a cheap terminal which doesn't emulate PFkeys, making it impossible for them to press the PF12 key (see "PF-keys simulation" option for more details on the subject). It can also be placed on the console stack by an EXEC program to termina- te the Chat environment. .CM File: TELL HELPCHAT A1 (05/30/86 18:29:12) .FO OFF TELL The format of the Chat TELL command is: .BX 1 14 73 .IN 2 TELL nickname message-text userid userid AT node .BX OFF .IN The Chat TELL command is similar to the CMS TELL command, causing the message to be sent to the specified computer user. The message text will the be printed on the appropriate logical screen, using the appropriate header (see "Layout" selection from main menu). Unlike its CMS counterpart, the Chat TELL command allows you to communi- with any RSCS machine on the network, local or remote. For instance, a Chat "Tell Zurich cpq n" could be substituted to the usual "CP SMSG RSCS CMD CZHRZU1A CPQ N" command, assuming that you have defined a nickname of Zurich for RSCS at CZHRZU1A (note: this assumes that the userid of the RSCS virtual machine in your node is "RSCS"; modify the nickname definition accordingly if not the case). Usage notes: 1) The current version of Chat does not support lists of persons. The supplied nickname must therefore be the one of a single computer user. To send messages to a list of users, use the "CMS TELL" command (see information about the Chat "CMS" command). 2) Your NAMES file will not be sought unless the specified nickname has not been dedicated a screen. This will save a considerable amount of CPU time compared to repeated use of the CMS "TELL" command. 3) The "AT" keyword, if present, must immediately follow the userid (ie there must be only a single blank between userid and "AT"). Otherwise it will be ignored and considered as being part of the message text. It is therefore possible to send a message starting with the word "at" to a user by typing an additional blank before the message text (this blank will be removed by RSCS if the person you're talking to is a remote user). The "at" keyword can be entered either in mixed or upper case. 4) Chat will automatically place a "Tell Nickname " command on all the screens that are dedicated to a user whenever the command line is blanked out. Any Chat command to be entered on the command line should be typed over the word "Tell". For instance, if you want to execute a "Disconn" command, you must move the cursor backwards and type "Disconn" over the word "Tell" -- "Tell nickname Disconn" would just send a message to the specified nickname. It is therefore recommended that all Chat commands be entered from screen 0 (where the command line is always left blanked) -- except for "Tell", "Drop" and "Dismiss" which should be entered from a normal screen. 5) The "Tell" command allows you to re-route your messages via a specific node if the "via nodeid" option was specified when entering the nick- name or if a ":via" tag was found in the appropriate entry of your NAMES file. See the "Nicknames" selection from main help menu for more details on the subject. 6) If you specify to re-route the message "via SMSG" or "via SEND", the message will be sent to the target user with a "CP SMSG" or "CP SEND" command (respectively), ignoring the nodeid. In this case, the messa- ge text will be upcased before being sent. Note that this option has precedence over the implicit use of "SMSG RSCS CMD nodeid" when applied to a RSCS virtual machine, ie you can use "via SMSG" or "via SEND" even with the RSCS virtual machine. 7) Messages to local node users can be sent either: - Via a "CP MSG" command (default), - Via RSCS (if you specified that the message be re-routed "via RSCS" when assigning a screen to the user on the nicknames screen), or - Via a "CP TO" command (if you specified that the message be re- routed "via CPTO"). The CP "TO" command is a nonstandard CP com- mand that is available at some nodes and will send a one-line message to the indicated user. Please note that if this command is not available at your node, all messages sent via Chat will be lost (and the console buzzer will be rung to indicate the error). Furthermore, the default option of using the "CP MSG" command to send messages to local node users can be overriden by defining a dummy entry in your NAMES file with nickname = any_value (ignored), userid = '*', node = your_node and a ":via" tag of either "RSCS" or "CPTO" (as required). Note that a specific ":via" tag in the NAMES file entry of the person you are speaking to, or a specific "via xxx" on the nicknames screen, will override this default option. Since this setting will be extracted from your NAMES file only during initialization (for obvious performance considerations), you will have to quit Chat and re-enter it to place the modification online if it was made from within Chat. .CM File: PICTURE HELPCHAT A1 (05/30/86 18:28:44) .FO OFF PICTURE The format of the Chat PICTURE command is: .BX 1 14 73 .IN 2 PICTURE filename nickname userid userid AT node .BX OFF .IN The Chat PICTURE command allows you to send a "picture" to another compu- ter user. The contents of the file "filename PICTURE *" will be dumped to the specified user, using several "TELL" commands. You should be aware that sending numerous pictures across the network can result in considerable network load and can be very painful for 1200 bauds modem users. On the other hand, it can be very useful to dump the contents of a short program or note to someone when the file transmission queues are discouraging.... Usage notes: 1) Although a "PICTURE" command will generate several "TELL" commands to send the file text to its intended target, nothing will be logged in the corresponding screen. There will not be any "To nickname: text" message. 2) A "PICTURE" command will always cause messages to be sent via RSCS, even when the destination user is from the local node. The reasons for this are obvious. 3) The "AT" keyword, if present, must immediately follow the userid (ie there must be only a single blank between userid and "AT"). Otherwise it will be ignored and considered as being part of the message text. It is therefore possible to send a message starting with the word "at" to a user by typing an additional blank before the message text (this blank will be removed by RSCS if the person you're talking to is a remote user). The "at" keyword can be entered either in mixed or upper case. 4) The "Picture" command supports the "via SEND" and "via SMSG" features of the "Tell" command (qqv), as well as its ability to "speak" to RSCS virtual machines by automatically issuing a "CMD nodeid text" command when the target userid is the same as the local RSCS userid. It will NOT, however, upcase the message text before sending it, as the "Tell" command does, in much the same way as a CP command entered from the keyboard is translated to uppercase while the same command is left in mixed case if executed from an EXEC program. .CM File: NN HELPCHAT A1 (05/30/86 18:28:26) .FO OFF nn The format of the Chat "nn" (number) commands is: .BX 1 14 73 .IN 2 nn .BX OFF .IN The Chat "nn" commands, where "nn" is a number in the 1 to 12 range, simulate the depression of a PFkey: entering "nn" immediately after the prompting arrow ("===> "), or immediately after the "Tell Nickname " command text, is equivalent to pressing the PFnn key. When entered directly after the prompt arrow, these commands operate even if the "PF-keys simulation" option is set to "NO" (see "Options" selection from the main help menu), but this option has to be set to "YES" if the "nn" command is to be accepted when entered after a "Tell Nickname" command line. Example: ===> 10 ===> Tell Christina 10 would both "press" the PF10 key, switching you to the nicknames screen. Usage notes: 1) This command was designed only to allow Chat to run on those cheap terminals where there is no such thing as a PFkey. The default option is therefore not to allow the "nn" commands after a "Tell Nickname" command line. .CM File: EQUAL HELPCHAT A1 (05/30/86 18:27:54) .FO OFF = (equal sign) The format of the Chat "=" command is: .BX 1 14 73 .IN 2 = (operands are ignored) .BX OFF .IN The Chat "=" command will cause the last command entered on the current screen to be re-executed. It must be entered immediately after the prompting arrow ("===> "). .CM File: DROP HELPCHAT A1 (05/30/86 18:27:52) .FO OFF DROP The format of the Chat DROP command is: .BX 1 14 73 .IN 2 DROP (operands are ignored) DELL .BX OFF .IN When entered from a screen which has already been dedicated to a user, the Chat DROP command will: 1) Clear the screen from which it was entered, 2) Clear the input area (ie the command line) from that screen, 3) Un-assign the screen as if you had switched to the nicknames screen and you had blanked out the corresponding field. Unlike the DISMISS command (qqv), the DROP command will not erase the disk-logfile for the corresponding user. Usage notes: 1) Attempting a "DROP" command on screen 0 will result in the usual error tag being displayed ("*** Error ***"). Since screen 0 is not dedica- ted to any specific user, it cannot be "dropped". 2) The "DELL" synonym for the DROP command allows you to drop the person assigned to the currently displayed screen by pressing the backward- field key ("|<---" key located on the right of the second keyboard row -- the one ending with "uiop"), typing a "D" over the "T" of "Tell Nickname " and pressing ENTER. .CM File: DISMISS HELPCHAT A1 (05/30/86 18:27:50) .FO OFF DISMISS The format of the Chat DISMISS command is: .BX 1 14 73 .IN 2 DISMISS (operands are ignored) .BX OFF .IN When entered from a screen which has already been dedicated to a user, the Chat DISMISS command will: 1) Clear the screen from which it was entered, 2) Clear the input area (ie the command line) from that screen, 3) Un-assign the screen as if you had switched to the nicknames screen and you had blanked out the corresponding field, 4) Erase the disk-logfile for the user assigned to that screen. The DISMISS command is therefore a "stronger" version of the DROP command (qqv). Usage notes: 1) Attempting a "DROP" command on screen 0 will result in the usual error tag being displayed ("*** Error ***"). Since screen 0 is not dedica- ted to any specific user, it cannot be "dropped". .CM File: CMS HELPCHAT A1 (05/30/86 18:27:44) .FO OFF CMS The format of the Chat CMS command is: .BX 1 14 73 .IN 2 CMS command-text .BX OFF .IN The CMS command allows you to execute any CMS command from within Chat. The command text will be printed to screen 0, and Chat will edit a ready message ("R; T=...") identical to the one provided by CMS and print it on screen 0 upon command completion. Usage notes: 1) Any CMS command can be called from Chat (not just CMS SUBSET commands) with the following exceptions: a) Chat cannot be called recursively, ie you cannot issue another CHAT command from within Chat. b) Any command causing the Chat program to be removed from storage will cause CMS to abend. This includes "NUCXDROP CHAT" and "NUCXDROP *" commands. c) Any command causing termination of the IUCV connection esta- blished by Chat will cause it to stop functionning. These inclu- de IUCVTRAP, WAKEUP release 5, etc. 2) The command will be executed as per a REXX "Address CMS" command, not just "Address COMMAND", ie exactly as if it had been entered from CMS command mode. 3) Any command entered from the Chat environment and not recognized as begin a Chat command will be passed to CMS for execution, thereby effecting an implicit-CMS function similar to XEDIT's IMPCMSCP option. It is therefore useless to prefix the command with "CMS", unless the CMS command to be executed is also a valid Chat command. 4) While the CMS command is executing, all incoming messages (and possi- bly all the output from the command if you run the "Trap VM and CP output" option -- see "Options" selection from main menu) will be held to be displayed upon completion of the command. You should there fore avoid calling long CMS commands from Chat (eg XEDIT, NOTE, MAIL) since you would not notice messages sent to you until you got back to Chat. Furthermore, if more than 255 messages are sent to you while the CMS command is executing, all messages in excess of 255 will be displayed on your terminal and lost to the Chat program. 5) The settings of the MSG, WNG, CPCONIO and VMCONIO options will be changed back to their original value upon return from CMS, in case the CMS program you called might have clobbered the settings to suppress a "PUN FILE..." message or suchlike. It is therefore impos- sible to change the settings of the CP/VMCONIO options by issuing, for instance, a "SET CPCONIO OFF" command from Chat. Use the "Trap VM and CP output" option instead (see "Options" selection from the main help menu). 6) An erase/write operation is performed on the console after completion of the CMS command, except if the command was recognized as being an unknown CP/CMS command, an invalid SUBSET command, or if the command started with "CP". For example, "CP IND" will not cause an erase- write operation, but "IND" alone will. 7) (information for system programmers developping applications under Chat) Chat issues an HNDINT CLEAR before calling CMS to execute the command and thereafter issues an HNDINT SET (preceded by the usual CONWAIT). The CMS command itself is called from an internal REXX pro- gram (resident within the Chat module itself). The Chat CMS command therefore conforms EXACTLY to the REXX "Address CMS" conventions. The screen will be erased and re-written (using erase-write) upon return from CMS. .CM File: DISCONN HELPCHAT A1 (07/04/86 22:32:13) .FO OFF DISConnect The format of the Chat DISConnect command is: .BX 1 14 73 .IN 2 DISConnect Message has been recorded. .BX OFF .IN The DISConnect command disconnects you from your terminal and places Chat in an "answering-machine" state, in which it will record all incoming messages and (possibly) reply with a message to their originators. The standard reply message is: "* Disconnected -- reply-message-text", where reply-message-text is the text you specified in the DISConnect command, or "Message has been recorded." if you did not specify any parameter. When you reconnect to your account, you will have to press ENTER once to get back to Chat (after having entered a CP "Begin" command as usual, if your account runs with the CP "SET RUN OFF" option). Chat will have printed the following messages on all the screens where a message was received during your "disconnection": Disconnected at MM/DD/YY HH:MM:SS (the various messages that were received on that screen) (...) Reconnected at MM/DD/YY HH:MM:SS -- nnn message(s) on this screen The screens where no message was received will be left unchanged. Addi- tionally, all incoming messages will be logged on the "ALL LOG" file, with a time stamp on columns 82-98, regardless of the "Keep a log of all transactions" option (see the "Options" selection from main help menu). The optional "CHATDISC" exec, which is automatically called whenever a message is received in disconnected mode, allows you to customize the reply message, defining different replies according to the message ori- ginator. See the "CHATDISC" selection from main help menu for more details on the subject. Usage notes: 1) Chat will re-configure its internal work area according to the device characteristics of the console when reconnecting, so there is no problem about disconnecting from an IBM-PC and reconnecting on a 3279-3B, for example. 2) If the CHATDISC exec cannot be found on any of your disks, Chat will use the default "* Disconnected -- reply-message-text" message to reply to the originator. However, the following messages will be ignored and will not be replied to: - Messages from yourself (this includes CP/VMCONIO text) - Messages from a RSCS virtual machine (userid = rscs userid on YOUR node) - Messages starting with an asterisk If you decide to create a CHATDISC EXEC, it should also conform to these three rules (but anyway you should read the "CHATDISC" selec- tion from main menu before starting a CHATDISC exec). 3) Chat will use a "CP MSG" command to send the reply message to users of the local node, so that the message gets replied even if RSCS is not available (or has crashed). The CHATDISC EXEC, if any, should conform to this rule unless you are sure that your RSCS will always be avail- able. 4) Chat will automatically exit from disconnecting answering mode upon reconnection when the "Trap VM and CP output" option is activated. In this case it will not be necessary to hit ENTER to get back to Chat. .CM File: SPECIALC HELPCHAT A1 (05/30/86 18:29:00) .FO OFF Special Chat commands for macro writers -- to be issued from the console stack only. The general format of the Chat special commands is: .BX 1 14 73 .IN 2 ^Cargs .BX OFF .IN Where "C" is the command name (see below) and "args" are the arguments to the command, if any. These commands are intended to be issued from the CMS console stack only (ie the Chat macro should &STACK the command for later execution by Chat), and do not cause the data entered on the Chat command line to be lost. Note that there is no blank between the "^" sign, the command name and the arguments. Any invalid "special command" will be ignored by Chat to avoid the possible loops which could occur if an error message was printed, causing control to be returned to the macro issuing the illegal command, etc. Here follows a brief description for each of the recognized Chat special commands: The "^n" screen-switch command .BX 1 73 .IN 2 ^n .BX OFF .IN This command will cause Chat to switch to screen number "n" after having preserved the command line. The PFkey-simulation commands, "nn", should not be used for that purpose since they would cause any data entered on the command line to be lost and could switch to the wrong screen if the user had changed the PFkey assignation. The "^*" message-echo command .BX 1 73 .IN 2 ^*Xmessage .BX OFF .IN This command will cause the specified message text ("message") to be printed to the current screen, without any header being inserted before the actual message text. This message will not be logged to disk. The first character of the argument, "X", indicates whether the message is to be hilighted or not: "H" indicates a red, hilighted message while any other value indicates a blue, unintensified message. Note that a message can be easily displayed on screen 0 by issuing a CP "MSG * message-text" command, which will furthermore cause an "Incoming message on #0" tag to be displayed. .CM File: MODEM HELPCHAT A1 (05/30/86 18:28:14) .FO OFF *********************************************************************** * * * Using Chat on a modem terminal * * * *********************************************************************** Several features have been added to the Chat program to make its use possible (and even comfortable) on modem-connected, or otherwise slow, terminals. Here is a description of the steps that should be taken to configure Chat for modem use: (1) The main problem with Chat is that it scrolls the screen, which makes it necessary to rewrite the entire screen whenever a new message is received. This problem can be fixed by changing the setting of the "Scrolling window" option on the nicknames screen. The "scrolling window" is the number of lines that are scrolled out of the physical screen when a scroll operation is performed; the same amount of blank lines are then made available at the bottom of the screen and filled little by little, without need for a screen refresh. The ini- tial setting is 1, but it can be increased to 9 if required. (2) Another problem is to minimize the number of screen switches. The "Automatic screen-switch" option from the nicknames menu must be set to "NO" to suppress all automatic screen-switching operations. Every possible effort must be made to minimize the number of manual screen-switches as well. It is strongly recommended that the Chat message filtering exec, CHATFILT (qqv), be altered to echo all RSCS messages (and possibly all messages from similar local servers) to the current screen (instead of screen 0). Refer to comments in "CHATFILT EXEC", as well as to the CHATFILT selection from main menu for more details on the subject. (3) In an attempt to reduce the number of I/O operations, it is recommen- ded that you define a logical "Line-end character" as well as a "Message-end character" (from the corresponding options on the nick- name screen) and you use them whenever possible to send several com- mands in a single transmission. Chat's line-end character feature is identical to CP's TERM LINEND feature and provides a means to send several "logical" commands on the same physical command line. The message-end character allows you to enter more than one message in a single "Tell" command: each message-end character will start a new message (to the same user). Refer to the "Options" selection from main help menu for more details on these commands. (4) Since the nicknames-screen is quite "large" and requires much time to be transmitted through the modem, you should try to avoid switching to it. Un-assigning screens can be achieved by means of the (very fast) "Drop" command (qqv) without having to switch to the nicknames screen. (5) Modem-connected terminals are usually cheap models which lack lower- case characters, PFkeys, etc. Chat is able to handle terminals with less than 80 physical columns, provided than a corresponding CP TERM LINESIZE command has been issued prior to entering Chat. In that case the "status area" (normally located at the bottom right corner of the screen) will be moved to the upper left corner to make sure that it will appear on the display. (a) Lowercase characters: if your terminal cannot handle lowercase characters (eg it displays them as semi-graphic characters), you should turn on the "Translate: Output to uppercase" option on the nicknames screen, as well as the "Translate: Input to lowercase" option (see below). (b) ALL CAPS input: if your terminal is able to display lowercase characters without providing them on the keyboard, or if for any other reason you are unable to enter your messages in lower case, you should turn on the "Translate: Input to lowercase" option on the nicknames screen. This will cause your input to be converted to lowercase, with capitals being inserted wherever required, ie at the beginning of the sentence, after punctuation marks (.?!) and when an isolated "i" appears. Example: THIS IS A SAMPLE SENTENCE. CHAT WILL MAKE IT NEATER, I'M SURE IT WILL! ---> This is a sample sentence. Chat will make it neater, I'm sure it will! (c) Lack of PF-keys: the "PF-keys simulation" option from the nick- names screen should be activated. You will then be able to simulate the depression of a given PF-key by entering its num- ber on the command line of any message-screen, either directly after the arrow or after a "Tell Nickname" command. Since there is no command line on the nicknames screen, it was decided that pressing ENTER when the nicknames screen is displayed and no field has been altered will cause Chat to switch to screen 0, as if the PF9 key had been pressed. .CM File: RELAY HELPCHAT A1 (06/13/86 20:53:22) .FO OFF *********************************************************************** * * * Communicating with Relays under Chat * * * *********************************************************************** Chat provides a set of facilities for communication with Relays, making the output neater and saving some disk space when logging the output to disk. In order for these facilities to be activated, you must change the nick- name(s) of your usual relay host(s) to something starting with the word "RELAY" (eg "RELAY", "RELAYUTC", "RELAYHEC"). You will then have to assign a screen to your relay, exactly as if it were a normal user. If the userid of the relay you plan to connect yourself to is "RELAY", you can activate this facility without defining a new entry in your NAMES file by assigning a screen to 'RELAY at host_relay_node'. In that case a special 'Relay:n' nickname will be temporarily assigned to the relay. Chat will then automatically: 1) Suppress the "From Nickname: " header on that screen. 2) Suppress the "To Nickname: " header on that screen and replace it with a relay header (see below) 3) Change any single leading dot (".") in an incoming message to a blank. Relays send leading dots when formatting a long message to paragraphs because RSCS would strip leading blanks from the message. Example: This line is a normal one, but the . continuation line will start with . a dot so that RSCS doesn't strip the . blanks. Chat will automatically remove all these trailing dots. 4) Suppress printing of the messages from relay to screen 0. Since a considerable amount of messages is to be expected from relay, it was deemed unnecessary to display them on screen 0 where they would perpetually scroll the important messages out of the screen... 5) Parse the "/Signon" and "/Nickname" commands and alter the nicknames screen "R." field accordingly (see below). The field will be left unchanged if you do not specify any argument to the command. 6) Suppress the possible message-prefix (from MSGNOH-endowed relays). This prefix is usually "Relay: ", but anything with a ": " sequence within the first 8 characters of the message will be removed. You must also fill in the nicknames screen "R." field (located below the field corresponding to screen number 6) with your own relay-nickname, ie the one you have used on the "/SIGNON" command when signing on to relay, not your NAMES file nickname for the userid at node of your host relay. Relay headers for outbound messages: the standard "To Nickname: " header is replaced with the following header when on a relay screen: - No header at all if the message text started with a "/" or "&" (relay command prefix characters) - No header at all if the nicknames screen "R." field has been left blank - " " if the nicknames field "R." field has been previously filled with the nickname you are currently using on relay. .CM File: CHATDISC HELPCHAT A1 (05/30/86 18:27:36) .FO OFF *********************************************************************** * * * How to use Chat as a disconnected answering machine program * * * *********************************************************************** In this file you will find information about the use of Chat as a GONE- like answering machine. You can skip the next paragraph if you are already familiar with automatic answering programs. What is an automatic answering machine program? Similar to a mundane answerphone, it will record messages sent during your absence and send back an acknowledgement to the sender, saying where you are, what you are doing and when you will be back. A phone set being intrinsically stupid and perfectly tactless will leave a message saying that you are at a party today and hope to have fun there until 3 am; and if for some reason your boss unexpectedly decides to give you a ring to tell you that "Well, I know I've asked you to finish that urgent job as soon as you can, but I really wouldn't want you to think I am a tyrant or any- thing... Listen, I've just watched 'Tosca' at the TV and I was struck by the physical resemblance between that Scarpia and me, and that Tosca had the very same hair as you and it kept tormenting me and... Hey, what's that message??? Where did you say you were????", you can be sure your answerphone will impassibly and unerringly deliver the fatal message.... It being a fairly well-known fact that computers are much more complex than phone sets (just ask your local telephone company clerk if he can help you find out what's going wrong with the IBM 3090-400 you've just finished installing in your dining room), you would expect a compu- ter-programmed answering machine to be a little more intelligent than that stupid answerphone that now lays broken in the middle of the yard after having delayed your pay raise by an undefinite but probably not unsignificant period of time... Indeed, Chat will allow you to set up different replies according to the person that "calls" you: one for your boss, saying "Good night sir. I'm so busy with that piece of work you gave me yesterday that I decided to start my answering machine so as not to get disturbed by phone calls. Will do my utmost best to have finished that job tomorrow.", another one for your office friends, saying "Hiya! I'm at Christina's party! Why don't ya join us???"; another one for your boyfriend (the same but with some sweet nothings appended); and yet another one for that !$+%*&!^! Bob who keeps on bothering you day and night, saying something that you probably wouldn't want to see in a public help file like this one. But since computers are generally gifted with Artificial Imbecility (AI), you would still have to tell the pro- gram who is Bob, who is your boyfriend, who is your boss, etc., so that it doesn't send your boyfriend the message that was initially intended for Bob, and vice-versa... In fact you will have to write a short pro- gram in a language that the computer is able to understand (don't panic, it's not THAT difficult!), telling it who is to receive which message, etc. To start the Chat built-in answering machine program, you must issue a "DISConnect" command from the Chat environment. This command accepts a message text as optional parameter, and causes Chat to wait for incoming messages, log them on disk and reply with a message. The standard messa- ge is: "* Disconnected -- your message has been recorded." if you did not specify any argument to the "DISConnect" command, or: "* Disconnected -- message text", if you did specify a message text when issuing the "DISC" command If you just want Chat to behave as a mundane phone answering machine, sending the default message back to everybody, you do not need the CHATDISC EXEC program -- just erase it from your disk and forget about it. In the following discussion we will assume that this is not the case and that you wish to set up Chat for "intelligent" message answering. The "CHATDISC EXEC" program, if present, will receive control from Chat whenever a message is received while in answering machine mode (ie after you have issued a Chat "DISC" command). The sender's "userid" (account number) and "node" (host computer identification), the text of the mes- sage he sent you and the text of the standard reply message (the one you specified when you executed the "DISC default-reply-message-text" com- mand) will be passed to the program. CHATDISC will then have to decide on an appropriate reply message, send it, and return control to the Chat program. An "Exit 0" instruction in CHATDISC will tell Chat not to send any further message to the sender, while an "Exit 1" instruction will cause Chat to send the standard reply back to the sender. This simple convention makes it possible for CHATDISC to ignore a message (no reply at all) or to send both a personalized message and the stan- dard reply. For example, you may wish to ignore all messages from system servers such as DIRMAINT, which are totally unable to receive reply mes- sages, least of all to analyze them and decide not to bother you any more since you are not there to read the message. Or you may wish to send an additional message to some friends to whom you have something particular to say, for example: * Disconnected -- Hi, Christina!! Will you be at the party tonight? * Disconnected -- gone for lunch, back in an hour or so. The first message being issued by CHATDISC and the second being the stan- dard reply message (issued by Chat). Important notes: 1) ANY reply message issued by CHATDISC must be prefixed with an aste- risk. NO message starting with an asterisk should ever be replied to. This will avoid possible "message wars" between two disconnected answering machines who would keep replying to each other... 2) Messages from yourself, or from a RSCS machine, should not be replied to. When functioning in "answerphone" mode, Chat will not reply to these messages, and it is your responsibility to make sure that CHATDISC does not reply to these messages. 3) If you run with the "Trap VM and CP output" option activated, you should take all appropriate steps to make sure that no message is printed to the virtual console when processing the incoming message. You should notably make sure that no message is printed when your disk becomes full, or then "remember" the condition (via GLOBALV) and never attempt any further disk logging. Another solution would be to stack a "QUIT" command to terminate Chat upon receipt of a "DISK FULL" message. 4) All the functions of the "GONE" exec are not implemented in the stan- dard CHATDISC provided with the Chat package, but there would be no technical problem about adding them. 5) Chat optionally allows you to set up your timer while disconnected in such a way that it will "eat" some CPU time at regular time intervals (every 10 minutes) to make sure that your account doesn't get forced off by your system's resource limiter or similar -- assuming there is one. This is realized by adding a "CP SET TIMER REAL" command into CHAT EXEC (before the call to the module, of course). Please not that it is your responsibility to make sure that your administration staff allows the use of disconnected anwering machines -- the author should in no way be considered responsible for any problem that might arise due to use (and possible abuse) of the CHATDISC program. 6) More information about the "DISConnect" command can be found in the appropriate helpfile from the "CHATCMD" help sub-menu. .CM File: CHATFILT HELPCHAT A1 (06/07/86 16:08:43) .FO OFF *********************************************************************** * * * How to use Chat message filtering facility * * * *********************************************************************** The Chat message filtering facility is a user-tailorable REXX procedure ("CHATFILT EXEC") that allows you to filter incoming messages. It will receive control upon receipt of a message from a user which has not yet been assigned a screen, and will decide whether a new screen should be automatically allocated for this user (default option) or not. In the latter case, the messages will either be printed on screen 0 (and only there) or completely ignored, as indicated by the CHATFILT program. Since the exec will NOT be called when the message originator has alrea- dy been dedicated a screen, it will require only a very limited amount of CPU time on the average, unless of course you keep receiving messages from someone you do not want to talk with and to whom you do not want to assign a screen. For the same reason, the exec is not called to process CP/VMCONIO output from yourself (those are automatically directed to screen 0). Possible applications for this filter are: (the lines marked with an asterisk indicate that the "standard" CHATFILT EXEC - the one shipped along with the Chat package - supports that particular function) (1) Cancel the automatic screen allocation process by causing all messa ges from new users to be sent to screen 0. You can then manually assign screens, in the order that you choose, to those persons with whom you want to speak. (2) Cancel the automatic screen allocation process and block out all messages from new users. A message is sent back to the originator, saying that you are busy and cannot receive any message right now, and the message is ignored (and possibly logged to disk, at your option). You can still converse with up to six people by manually assigning a screen to them -- in that case their messages will not get blocked. You can drop them whenever desired by just de-assi gning the screen. You can also define a list of users whose messa- ges must never be ignored (eg your boss or husband/wife). * (3) Cause all messages from file servers and/or system accounts to get printed to screen 0 instead of being dedicated a screen. Suggested userids to be trapped to screen 0 are: MAILER, LISTSERV, NETSERV, DIRMAINT, CMSBATCH. Please note that messages from RSCS are always confined to screen 0. * (4) Cause all messages starting with an asterisk to be trapped to screen 0. * (5) Suppress all "FILE (nnnn) ENQUEUED ON LINK xxxx" messages (from RSCS). Since an error message is sent when the file is rejected, you need not have any qualms about discarding this useless and boring message. * (6) Parse the "SENT FILE..." messages and neaten then up. Example: File 1234 has been sent across the Geneva to Roma line to Bob File 1234 has been sent across the Roma to Israel line to Bob File 1234 has reached Bob * (7) Parse the "FILE SPOOLED TO userid -- ORG..." messages from RSCS, scan your reader for the file and display a message to current screen, such as: File "CHAT MODULE" (2345) from Eric has been placed in your reader * (8) Parse the "CPQ:..." messages, search your names file for the corres ponding nickname and display a nice message, such as: Rosanne is disconnected. Christian is not logged on. Sylvia is logged on terminal number 56C. (9) Display all RSCS messages to current screen rather than screen 0. This is particularly useful for modem users since it will save you a screen switch operation. The code for this function has been provided in the "standard" CHATFILT EXEC in "comments" form and can be easily made operational. *(10) Parse the "LINK xxx INACTIVE", "LINK xxx NOT CONNECTED" and "PATH LOST TO xxx" messages, search your NAMES file for the correspon- ding nicknames and display a message such as: Link failure on the Geneva to Roma path Link failure on the Roma to BITNIC path Please refer to the comments in "CHATFILT EXEC" for more information. It is strongly recommended that unexperienced REXX programmers do not try to add new functions to the standard exec since any REXX interpretation error might cause the console to hang and might require a "cold" startup of your virtual machine (log off and log on again) to clear the problem. The cause of this little annoyance lays in the fact that Chat cannot give the control of the terminal back to CMS while CHATFILT is being called -- refer to the comments in CHATFILT EXEC for more details on this topic. .CM File: CHATNAME HELPCHAT A1 (05/30/86 18:27:40) .FO OFF Chat NAMES command (CHATNAME) The format of the CMS CHATNAME command is: .BX 1 14 73 .IN 2 CHATNAME >>> .BX OFF .IN The CMS CHATNAME command is identical to the standard IBM NAMES command, with the following differences: 1) Not only the nickname, but the userid, nodeid and person's full-name can be specified on the command line, making it much easier to add new nicknames. This is particularly convenient when someone sent you a message and you want to add a nickname for him: you do not have to write his userid and node on a scrap of paper before calling NAMES as was the case with the standard IBM command. 2) The length of the nickname field has been expanded to 14 characters, the maximum length accepted by Chat. 3) The nickname is trimmed to mixed case according to the Chat conven- tions (see "Nicknames" selection from main help menu for more details on the subject). 4) The console "insert mode" key can be used freely under CHATNAME, which was not the case under the standard NAMES (you had to move to the end of the text and press the ERASE EOF key before being able to use the insert mode key). 5) The screen layout has been slightly altered to make sure that CHATNAME is not mismatched for the standard NAMES exec. 6) A "Charlot RELOAD" command is issued upon exit from the program to reload the NAMES file into storage, when using the Charlot message filtering program. This will only affect the users of the Charlot program. The CHATNAME program is an optional component of the Chat package and requires the following files: CHATNAME EXEC (maybe renamed to NAMES EXEC on your system) CHATNAME XEDIT CHATXNAM MODULE If these files are not present on any of your disks, you may order them from ERIC at FRECP11 (Eric Thomas). .CM File: CHATRL HELPCHAT A1 (07/08/86 10:36:45) .FO OFF Chat RDRLIST command (CHATRL) The format of the CMS CHATRL command is: .BX 1 14 73 .IN 2 CHATRL (no argument is accepted) .BX OFF .IN The CMS CHATRL command is similar to the standard IBM RDRLIST command, with the following exceptions: 1) The file sender's nickname, if any, is substituted to the standard "userid node" indication, making the list much easier to read. Nick- names with a blank ":node" entry are supported. 2) Mails sent via a MIT mailer are displayed with the sender's nickname or "userid node" indication instead of the mailer machine's one, provided that the mailer's userid is "MAILER". 3) The nickname is trimmed to mixed case according to the Chat conven- tions (see "Nicknames" selection from main help menu for more details on the subject). 4) An assembly language reader queue processor is used to minimize execu- tion time when building the list. This new processor can handle an unlimited number of reader files, unlike the standard RDRLIST which cannot cope with more than 110 files (which could cause notes not to be received in chronological order, even though the supplied reader list had been sorted by date). 5) Messages are passed to the XEDIT environment if it is found to be active. For example, issuing a CHATRL command against an empty reader while under XEDIT would display "No file in your reader." in the XEDIT message area instead of clearing the XEDIT screen and forcing you to press the CLEAR or PA2 key thereafter. 6) The MSGSERV program is automatically activated, if present. MSGSERV is a program written by Martin Scheffler (also known as "MegaByte") to direct all incoming messages and CP/CMS output to the XEDIT messa- ge area. Contact Martin Scheffler (I7090202 at DBSTU1) for distribu- tion. 7) For performance considerations it has been decided that the file ori- gin field ("userid node" or " ") would not be re-computed each time you execute a prefix command from Chat-RDRLIST. This means that if you execute a prefix command that dynamically changes the file TAG, the userid/node/nickname indication on the reader list will not be updated until you depress the Refresh PF-key (PF2). This little restriction will, however, save a considerable amount of CPU time, especially if you have a large NAMES file. The CHATRL program is an optional component of the Chat package and requires the following files: CHATRL EXEC (maybe renamed to RDRLIST or RL EXEC on your system) CHATXEQ XEDIT CHATRDRL MODULE If these files are not present on any of your disks, you may order them from ERIC at FRECP11 (Eric Thomas). .CM File: INSTALL HELPCHAT A1 (04/28/87 14:40:45) .FO OFF *********************************************************************** * * * How to install Chat on a public disk or file server * * * *********************************************************************** Special note about file servers: any official (ie not clandestine) file server is allowed to distribute the Chat package, provided that it com- plies to the following rules: 1) The name of the programs must not be changed without express autho- rization from the author. 2) The file server owners must accept to make new versions of the pro- gram available on the server within a reasonable delay. The reason for this restriction is that any severe "bug" in the program will usually cause about fifty complaining notes a week to be sent to the author's reader. That traffic must be stopped as soon as the problem is corrected, for obvious reasons (both technical and psy- chological...) 3) The author is notified of the installation of the program so that he can send new versions of the program to the server's owner. The following files must be made available on the public disk or file server: CHAT MODULE CHAT EXEC (Chat package) CHATXEQ XEDIT CHATRDRL MODULE (Chat-RDRLIST package) CHATNAME XEDIT CHATXNAM MODULE (Chat-NAMES package) None of these programs should ever be renamed. The users should be asked not to copy them to their own minidisks and not to alter them in any way. Failure to observe this rule could result in mild to severe damage to the user's virtual core and/or minidisks, for which the author could not be held responsible. Only experienced system programmers should make changes to these programs. The following programs must be made available under the same conditions, but they can be renamed if desired: CHATRL EXEC (Chat-RDRLIST package) suggested name: "RL", "CRL" CHATNAME EXEC (Chat-NAMES package) suggested name: "CNAME", "CN" It is of course possible to rename them to "RDRLIST" and "NAMES" respec- tively to override the default IBM execs, but this is not recommended. An alternative solution would be to install them as "RDRLIST" and "NAMES" on a public disk devoted to network files, while the versions on the system disks are left unchanged. Users should NOT copy those files to their own disks, even if they want to have them with another name. In that case they should define synonyms for the execs on the system disk to be sure that they always use the latest version. The following files must be made available on the public disk or server: CHATDISC EXEC CHATFILT EXEC (Chat package) They must not be renamed. The users are, however, encouraged to copy them to their own minidisk and to alter them to suit their needs; changes to these execs will be signaled in the CHATnn CHATMEMO files which will have to be made available to the users (see below), so that they can ma- ke the change in their own personalised copy. CHATnn CHATMEMO files: these files contain a detailed description of all the changes that took place in Chat from one release to the other. They should be made available to all the Chat users, which should be told to have a look at them from time to time. A new/revised CHATnn CHATMEMO will be sent along with each update to the Chat program and should be inspected by the local Chat contact to check that there is no new pro- blem with the (possible) local modifications to the system before the new version is placed on the system disk (this does not apply to servers). Only the two lastest CHATMEMOs need to be kept -- as a rule of thumb, any such memos that has been removed from Netserv is no longer required and can be discarded. It is strongly suggested that a notice be added into the local "user newsletter" system, if any, to tell the users about the newly obtained version of the program. Help files: file servers will only need to keep the CHAT HELPCMS file. This file is a concatenation of several helpfiles, including two help- menus. The scattered HELPCHAT files can be extracted from the HELPCMS file by means of a special exec, CHATHELP, available from the author. The HELPCHAT/HELPMENU system will be used by Chat if available, but for technical reasons the bare HELPCMS file takes precedence over it (otherwise a HELPMENU file on the help-disk would not be detected by a STATE command unless it has been preivously accessed). It is recommended that the Chat help information be kept in HELPCHAT/HELPMENU form if Chat is installed on a public disk, in which case CHATHELP must be run every time a new HELPCMS file is obtained to automatically regenerate the scattered HELPCHAT files. It is recommended, but not mandatory, that the files be placed on the help disk (usually MAINT 19D). In any case, it is MANDATORY that the old CHAT HELPCMS file be erased, otherwise it would be displayed and the HELPMENU file would just be ignored. Obtaining the files: the Chat package 'per se' can be obtained from the nearest Netserv server, which will always have the latest version (unless a link has been down for a long time). Those among you who have Netserv privileges can even set up an Automatic File Distribution (AFD) request for the Chat files (see "NETSERV HELPFILE" for more information on AFD). Other users can contact the author to be added onto the Chat distribution list, in which case they will automatically receive a note from the Chat distribution account (CHAT at FRECP11) whenever a new version of the program has been made available on the Netserv servers. The Chat-RDRLIST and Chat-NAMES packages cannot be obtained from Netserv but are automatically distributed by the Chat distribution account. Con- tact the author (Eric Thomas ) if you wish to be added to the Chat distribution list. Help files in other languages: although it is obviously impossible to provide all the Chat helpfiles in several languages, it would be interes ting to have "general introduction" helpfiles in other languages for the potential Chat users which are not familiar with english. Some Chat users have translated some of the english helpfiles (or written new ones) in their own tongue, and have accepted to make them available to everybody. - Prof.Dr. P.L. Reichertz (from Medizinisches Hochschulrechenzentrum Hannover, Germany) has written a set of two helpfiles in German: CHATEIN HELPCMS -- Allgemeine und kurze Einf}hrung in das CHAT CHATINST HELPCMS -- Allgemeine implementierungshinweise They are available from Netserv as GERMAN CHATMEMO. - Luis Miguel Fernandez Candocia (from Universidad Complutense de Madrid, Spain) has translated, in collaboration with other people of his University, the complete set of Chat helpfiles into Spanish. These files are available as SPANISH CHATMEMO. If you have written or translated helpfiles for Chat in your own language and you are willing to make them available to users from other systems, just contact me (Eric Thomas ) and I will mention them in this helpfile. I will try to make them available on Netserv (as "GERMAN CHATMEMO", "SPANISH CHATMEMO", etc), provided that they are general enough (ie a file explaining from which system disk the files can be obtained at this or that node is not suitable). .CM File: CHATRDRL HELPCHAT A1 (07/08/86 12:14:07) .FO OFF Technical information about the CHATRDRL assembler reader-queue processor This information is designed for EXEC/REXX programmers who develop appli- cations using the CHATRDRL module as a sub-program. This is not the help information file for the Chat-RDRLIST command (CHATRL). The format of the CHATRDRL command is: .BX 1 14 73 .IN 2 CHATRDRL userid node RSCS-userid MAILER-userid Available options are: NONAMES REALRDR REALPUN REALPRT ALLFILES .BX OFF .IN CHATRDRL is a reader-queue assembler processor which was primarily desi- gned to support the Chat-RDRLIST command. It will scan the contents of your reader and stack an information line for each file (in RDRLIST for- mat). Unlike EXECIO, CHATRDRL is not limited by the 8k-reply-buffer-size "feature" and can handle any number of spool files. It will, additional- ly, substitute the file sender's nickname (from your NAMES file) to his userid/node, whenever applicable. Note that the NAMES file is read into storage at initialization using the considerably fast block-read method (ADMSBLKR), then pre-processed and converted into a smaller fixed format table which is then scanned via BXLE whenever required -- it is really as fast as it CAN be. Available options: NONAMES indicates that the NAMES file must not be used for searching nicknames. Note that this option will considerably speed up CHATRDRL, especially if your NAMES file is large: CHATRDRL spends about two-thirds of its time to read in the NAMES file, format it and scan the table... REALRDR indicates that the real system reader must be processed. This option is restricted to privileged (class E) users. It implies the NONAMES option, and yields a slightly different output (see below). REALPUN is identical to REALRDR except that the system punch chain is scanned. REALPRT is identical to REALRDR except that the system print chain is scanned. ALLFILES is applicable only when one of the REALxxx option is specified; it indicates that normally unseen files, such as files being processed by system (ie being printed, being SPTAPEd), files currently open for reading, must be included in the list too. These files will be identified by an asterisk in column 1 of the RDRLIST-line, and cannot be CP TRANSFERred, CP PURGEd, etc. However, some applications (such as counting the total number of lines in the system spool) might require information on the- se files. Note that files which have not yet been enqueued on the reader chain, such as files which have not yet been closed, started console, will not be listed. The only way to obtain them is to scan the VSPLCTL block of every URO VDEVBLOK, for every user in the system -- a CPU consuming task indeed... Options must be entered immediately after the last mandatory keyword (MAILER-userid), without any parenthesis. Notes on real reader-chain processing: 1) When one of the REALxxx options is specified, the first four arguments become irrelevant since the TAG data is not inspected and the NAMES file is ignored. They can be conveniently replaced by place-holders, eg "CHATRDRL . . . . REALRDR". Note that the TAG information is kept on disk by CP and is therefore not easily accessible, to say the least... 2) Real-reader scanning in a time-sharing environment is intrinsically tricky since another user can be dispatched at any time and can PURGE the very file you were processing, causing the pointer to the next file in chain to become invalid... Whenever CHATRDRL detects such a condition, it will immediately return to the caller with a return code of 2. It will probably have stacked some lines already, and the last one will probably be garbage; therefore the calling program should clear everything that might have been stacked by CHATRDRL (using a DESBUF/DROPBUF command as applicable) and re-issue the command. The condition should not persist, unless (perhaps) a SPTAPE DUMP with the PURGE option is in progress. It is therefore suggested that the follo- wing algorithm be used to invoke CHATRDRL: Do 10 /* 10 retries should suffice */ 'MAKEBUF' 'CHATRDRL . . . . REALRDR' If rc ^= 2 Then Leave 'DROPBUF' End If rc = 2 Then Call Sorry_couldn't_manage_to_have_CHATRDRL_function 3) You should also be aware of the fact that, for the same reason, it is possible for CHATRDRL to "miss" some reader files if a CP ORDER com- mand is issued just at the wrong instant. This condition is impossible to detect (although in certain cases it CAN be detected, eg when it causes files to be listed twice) and is VERY unlikely to occur. 4) The output produced by CHATRDRL when scanning real spool chains is slightly different (see detailed description below) and includes the (real) SFBLOCK address associated with the file, making it possible for the calling program to obtain any information about the file that CHATRDRL did not provide, eg DISTcode. Note that since the file might have "disappeared" at the time the calling program examines the SFBLOCK, yielding irrelevant information, it is strongly suggested that the spoolid be retrieved from the SFBLOCK along with the desired information (on the same DCP command) and compared with the spoolid returned by CHATRDRL; if they do not match, the file should be ignored (it has just been purged). Note that the spoolid might still be intact in real storage while the file has been purged (eg if the storage used by the SFBLOCK was not yet recycled); but in that case the WHOLE SFBLOCK will probably have been left intact and the information obtai- ned from it would be correct, although no longer useful. Format of output lines: .BX 1 9 40 75 cols Virtual reader chain Real spool chain .BX 1 blank normal file: blank "unseen" file: asterisk 2-6 blanks idem .BX 7-14 filename, or "(none)" idem 15 blank idem .BX 16-23 filetype, or "(none)" idem 24 blank idem .BX 25-27 spool device type idem (PUN, CON, PRT, RDR, DMP) idem 28 blank idem .BX 29 file class idem 30 blank idem .BX 31-38 sender's userid (local) origin userid 39 blank idem 40-47 sender's nodeid (local) owner's userid 48 blank idem or 31-47 sender's nickname N/A .BX 49-52 file hold status idem (NONE, USER, SYS, USYS) idem 53 blank idem .BX 54-61 number of records idem 62 blank idem .BX 63-67 creation date (mm/dd) idem 68-71 blanks idem .BX 72-79 creation time (hh:mm:ss) idem 80-82 blanks idem .BX 83-90 filename, or "(none)" real SFBLOCK address 91 blank idem .BX 92-99 filetype, or "(none)" reserved (blanks) 100 blank idem .BX 101-103 spool device type idem (PUN, CON, PRT, RDR, DMP) idem 104 blank idem .BX 105-108 spoolid idem 109 blank idem .BX 110-126 copy of columns 31-47 idem .BX OFF Return codes: 0 Normal return code 1 Reader (or specified real spool chain) is empty 2 Problem scanning real reader chain. See usage note (2) 28 Invalid option Any comments, remarks or suggestions should be directed to: Eric Thomas .CM File: CHAT HELPMENU A2 (07/08/86 10:30:28) A file may be selected for viewing by placing the cursor under any character of it and pressing the PF1 or ENTER key. A MENU file is indicated when a name is preceded by an asterisk (*). If you are reading this for the first time, select "Summary". For a description of the CHAT commands, select "ChatCMD" (menu helpfile). .SP 2 .FO OFF *ChatCMD CHATDISC CHATFILT CHATNAMES CHATRDRL CHATRL Install Layout Messages Modem Nicknames Options Overview PFkeys Relay Requires Summary Tags Tutorial .CM File: CHATCMD HELPMENU A2 (03/30/86 16:17:26) A file may be selected for viewing by placing the cursor under any character of it and pressing the PF1 or ENTER key. The minimum command abbreviation is indicated as uppercase. .SP 2 .FO OFF & ? ?? = CMS DISConn DISMISS DROP nn PICTURE Query QUIT SpecialCMD TELL