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