[comp.os.vms] new reply.doc document

ERIC@UOFT02.BITNET (07/07/88)

BACKGROUND:

  REPLY was written for basically two reasons:  1)  a co-worker wanted a
program to send reply messages like the GONE EXEC  and  it's  variations
under CMS,  and,  2) I was trying  to  learn  the  C  language  and  was
experimenting with the SMG library routines.  REPLY seemed a logical way
to learn about both of these.  I did not see it as being a  real  useful
program at the time, but apparently from the response I have had, it has
indeed turned out to be useful to many people.
  Since its start, it has been modified many times,   and no longer even
uses SMG routines. It is now much faster and more reliable.  It requires
no special priveleges to use.
  It is designed to be used on VAX/VMS systems running JNET with BITNET,
although it may work as-is or with minor modifications on other networks
and with other network software.  It is set up to work on DEC VTxxx type
terminals only, but again, this can be changed with little effort.


GENERAL DESCRIPTION:

   This  program  will  log to a log file any messages sent to you while
you are out.  It will then issue a reply message to the sender if it was
a user message. The program will correctly handle the following types of
messages:

        SEND    messages from the current node    (log and reply)
        SEND    messages from another node        (log and reply)
        MAIL    messages from any node            (log, no reply)
        BATCH   messages                          (log, no reply)
        ^T      messages                          (log, no reply)
        NETWORK messages (message with no userid) (log, no reply)

  Unfortunatly,  this program must be run while you are logged  in  at a
terminal;  you  can  not  be  detached, disconnected, or logged out. The
reason for this is that (as far as I can tell),  VMS  will  not  send  a
message  to  any  user  unless  there is a physical terminal attached to
that user.  If anyone finds (or knows) a way around this, let me know.

   There  are  two  ways  of running REPLY. The first method is with the
standard VMS RUN command. If run this way, REPLY will  use  the  default
reply message. The other way is to define a DCL symbol or command to run
REPLY.  For example, if the executable file is in sys$system, then:

$ REPLY :== $ sys$system:reply.exe

  Then, to run the program with the default message, simply enter:

$ REPLY

  To run the program with a different message, type:

$ REPLY "I am in a meeting - I will be back at 2:30 PM"

  When the program is run, it sets up a small menu.  This tells you  the
number of new user messages received (sent via SEND),  the number of new
system messages received (all other messages, including ^T),  the number
of old message already in the log file,  the current date and time,  and
a command explaination and command prompt. (The counts and the date/time
are not printed if you are not on a VT10x/VT2xx terminal).

 There  are  two commands in the program: Q (for quit) and E (for edit).
Q will simply exit the program. E will call either the EDT editor or the
default TPU based editor to allow you to edit the message logging  file.
The editor called depends on the logical REPLY$EDIT in the process  name
table.  If the logical REPLY$EDIT is set to "TPU" then it will call  the
TPU based editor.  If the logical REPLY$EDIT is set to anything else, it
will call the EDT editor.  A Control C/Control Y will also exit from the
program (although this is not recomended). When in an editor, any editor
^T trapping (or other AST routines) will not work, as AST's are disabled
while the editor is called. Using the EDIT command also disables message
trapping.

  When 'user messages' are received  (those send by a user with the send
command or equivalent) a reply (either a default or a user supplied one)
is sent back to the original sender.  When a file is received, a default
reply is sent back saying the file was received.    Any  other  messages
(like control/t, mail, etc) are simply logged to the file,  and no reply
is sent.

  All messages are stored in "SYS$LOGIN:MESSAGES.LOG."

  The program assumes the existence of the following logical names:

        SYS$LOGIN               - assigned by the system login.com
        SYS$NODE                - assigned by DECNET on startup...

        SYS$RSCS_NODE           - assigned by JNET before JNET 3.4
or      JAN_LOCAL_NODE          - assigned by JNET after  JNET 3.4

        REPLY$EDIT              - assigned by user, not manditory!

        If SYS$LOGIN or SYS$NODE are not defined,  then  REPLY  will not
work.  If niether SYS$RSCS_NODE nor JAN_LOCAL_NODE is defined reply will
use the value of SYS$NODE.


ACCESS:

  REPLY can be obtained from the kermit file server at the University of
Toledo, KERMSRV@UOFT02.  For information on how to use KERMSRV, send the
following (VMS) command (or its equivalent):

send kermsrv@uoft02 help

To get a copy of the files, send one of the following commands:

send kermsrv@uoft02 vmsdump reply.*
send kermsrv@uoft02 punch   reply.*


COMPILATION:

   The REPLY program is completely contained in one source file.  Simply
compile and link as you would any normal VAX C program. For example:

$ cc REPLY
$ assign sys$library:vaxcrtl.olb lnk$library
$ link REPLY
$ deassign lnk$library


ADDITIONAL NOTES:

  I have a check in the code to try to avoid infinate loops by not send-
ing any more than 4 messages in a row to any one user.   This should fix
all problems with servers, databases, etc. and any problems with sending
messages to yourself(?). You can still hardcode specific names to ignore
into the program (as was done with csnews@maine)  so that it does not do
four or more replies before giving up. This is only suggested if you use
a particular server, database, or whatever on a regular basis.

KNOWN BUGS:

  None. All known bugs have been fixed.


RELATED PROGRAMS:

  See also MESSAGE.C - This program runs as a subprocess  (spending most
if not all its time hibernating) and logs all incoming messages  of  any
kind to a disk file so that you have a perminate record of all messages.
This is useful if you for some reason need a record of messages,  or  if
you routinely loose messages due to the screen clearing,  or due to  the
size of a screen if you receive many messages in a short period of time,
or whatever else...


AUTHOR:

Eric Jon Rostetter (ERIC@UOFT02.BITNET)
Computer Services
University of Toledo
2801 West Bancroft
Toledo, Ohio 43606 USA