EMAIL SYSTEM OPERATORS GUIDE
for the AMUS EMAIL package
Written by DAVE HEYLIGER - AMUS Staff and author of EMAIL
PROGRAMS
========
The AMUS EMAIL package consists of the following programs:
EMAIL.LIT - the actual EMAIL program
MAILON.LIT - records users who are on the system
MAILOF.LIT - records users who are off the system
MALINI.LIT - initializes the AMUS EMAIL system
MAILOP.LIT - a "priority" program that defines users
WHOSON.LIT - displays EMAIL users, who's on/who's off
All of the above programs should be located in the SYS: account,
DSK0:[1,4].
NOTE: When assembling EMAIL.M68, it will only go through "Phase 2".
You must then enter .LNKLIT EMAIL to create EMAIL.LIT.
INSTALLATION
============
To install EMAIL on your system requires the following three steps:
1) Defining the requirements of EMAIL and defining all of
the users of EMAIL (individual's "mailboxes") with the
MAILOP program.
2) Creating a "shell-of-sorts" that runs MAILON.LIT when the
user logs on and runs the MAILOF.LIT program when the user
logs off.
3) Modifying your AMOSL.INI bootup file to install and
initialize the AMUS EMAIL package.
STEP 1 - Running the MAILOP program.
The MAILOP program is a "priority" program. It requires the
user to be in the OPR: account, DSK0:[1,2] before the program can be
run. This program should only be run by one individual. Therefore,
the OPR: account should have a password. You may place a password on
this account with the SYSACT command.
Before you dash madly off and run the MAILOP program, you
need to decide on a few parameters. They are: (a) the approximate
MAXIMUM NUMBER OF USERS you will ever have defined on the AMUS EMAIL
system, and (b) unique NAMES and PASSWORDS for each user you wish to
initially define (6 characters max each). Once these two parameters
have been defined, you may LOG to the OPR: account and enter MAILOP.
Now that you are in the MAILOP program, you have the following
choices: ADD user, DELETE user, CHANGE user password, LIST all users
and their corresponding passwords, INITIALIZE the AMUS EMAIL package,
and QUIT.
Choose the INITIALIZE option by entering in an "I". You must
now enter in the approximate maximum number of EMAIL users you think
you might define. Be liberal. For example, if 20 people are in your
office, you might choose 40. Note that the number you choose should
be divisible by 20 (i.e., 20, 40, 60, ... ,100, 120 etc.). This will
create the following files in the BOX: account on your system, DSK0:
[7,2] (see FILE STRUCTURE later in this document to see the exact
structure of each file listed below):
EMAIL.DAT - a random file containing each individuals stats.
EMAIL.USR - a random file that is copied into system memory.
EMAIL.SYS - a sequential file that creates space in system
memory for EMAIL.USR.
Once you have initialized EMAIL with MAILOP, you should never
need to do this procedure again. MAILOP will "beep" at you if you try
to initialize EMAIL and any of the above 3 files are already on your
system.
You are now ready to ADD users to the AMUS EMAIL package. To
do this, simply type in an "A". MAILOP will ask for a user NAME and
PASSWORD (6 characters max each). Begin adding in the users you would
like to define to EMAIL. Once a user is defined, you may select "A"
again for each additional user you would like to add. MAILOP will
"beep" at you if you try to add two users with the same name.
NOTE: after ADDing, you MUST REBOOT to record the user. The name has
been added to the EMAIL.USR file but this information has not
been loaded into system memory via MALINI (see FILE STRUCTURE
below for details before you press that reset button!). DO NOT
reboot if this is your very first run and steps 2 and 3 have not
been completed! DO reboot each time you add new users later in
your wonderful life!
To examine all of the user's NAMEs and PASSWORDs that are
currently defined on EMAIL, choose the "L" option (for LIST). You
will see all of the users listed to the screen, including their
PASSWORDs! This is why only ONE user should run the MAILOP program.
The password for each user insures privacy of EMAIL. If everyone knew
everybody's password, they could read other peoples mail! Therefore,
make sure that only a select few have access to MAILOP (i.e., get that
password on the OPR: account or don't tell people about MAILOP!).
Suppose now that you would like to modify a defined user's
PASSWORD (the user requested to you that they would like a new EMAIL
password). Select the "C" option (for CHANGE). MAILOP will prompt you
for the user's name you would like to modify the password for. If you
enter in a defined user, MAILOP prompts for the password. Enter in the
new password to update the new entry. Use "L" to examine the changes
if necessary. Reboot the system if MALINI has been executed to record
the new change if steps 2 and 3 have been already performed.
Finally, to DELETE a user, select "D". MAILOP will ask you for
the name of the user you would like deleted, and if you enter in a
defined user that already exists, this user will be deleted. Again, a
reboot is necessary unless steps 2 and 3 are not complete.
NOTE: before you ever delete a user from EMAIL, it might be a good
idea for the SYSOP to "log on" as this user and clean up this
individuals mailbox (delete all messages in their box and delete
all of this users UNREAD mail. Also clear their AUTO reply - see
EMAIL.MAN for details on these functions). Also, after you have
deleted a user, be sure to REBOOT the system to record changes.
STEP 2 - Creating a "Shell"
EMAIL was created with the idea in mind that each individual
who logs on gets "captured" by the system at logon and "released" from
the system at logoff. In order to achieve this type of "shell", you
need to create two command files - an "ONLINE.CMD" command file, and
an "OFFLIN.CMD" command file. Both files should reside in the CMD:
account, DSK0:[2,2]. Let's take a close look at each file.
Note: by no means is this a tight security shell, and you may call
these files any name you like.
"ONLINE.CMD"
This file should be FORCEd to each JOB on bootup. You will see
where to place this file in your AMOSL.INI file in STEP 3 below. For
now, let's examine the purpose and structure of this file.
The sole purpose of this file is to capture the EMAIL user
when the individual logs on your system. Each time the system boots
(or after a user has used "OFFLIN" below), the MAILON program is run
on the JOB. All this program does is ask for the user's EMAIL name and
records this user as being on-line. After the MAILON program is run,
you may then run your normal "menu" shell, return them to the dot, or
what-have-you. Below are two simple examples of what your ONLINE.CMD
file might look like.
a) if your system normally has a user at "the dot" on bootup:
:R
MAILON
********* (end of VUE)
b) if you have a "menu" program or ??? FORCEd to each user on bootup:
:R
MAILON
RUN MENU ;or whatever....
********* (end of VUE)
"OFFLIN.CMD"
This command file should be run each time a user logs off your
system. All this command file does is run MAILOF to record the EMAIL
user as off-line, runs LOGOUT.LIT to log the user off, and finally,
makes the ONLINE program run again to capture the user on the next
logon. In other words, have your users enter in OFFLIN (or whatever
you decide to call it) instead of LOGOFF. Below is an example of how
OFFLIN.CMD might look:
:R
MAILOF
LOGOUT
MAILON
******** (end of VUE)
STEP 3 - Modifying AMOSL.INI to include AMUS EMAIL
AMUS EMAIL requires slight modification of your bootup file
AMOSL.INI. Below are the step to create your new bootup file.
a) LOG SYS: - this will log you to where AMOSL.INI lives
b) COPY EMAIL.INI=AMOSL.INI - copy AMOSL.INI and call EMAIL.INI
c) VUE EMAIL.INI - VUE the copy of AMOSL.INI
d) add in the following:
where you see many "SYSTEM program name" lines, enter
SYSTEM BOX:EMAIL.SYS
and after the final "SYSTEM" command, enter in
MALINI
e) where you see some lines similar to
"ATTACH TRM,JOB"
"FORCE JOB"
"MEMORY xxxK"
etc...
add in the as the LAST item on the list of items FORCEd to the JOB
"CMD:ONLINE"
(you should do this for each JOB that users will be using)
f) FINISH from VUE - this writes the modifications to the disk
g) LOG OPR: - log to the operator account
h) test your new bootup file by entering in
MONTST AMOSL,EMAIL.INI
i) if it WORKS (You should see the MAILON program on each users
terminal), then proceed to (j) below, else reboot the system
with the reset button and return to step (a)... somewhere you
have made a mistake!
j) make EMAIL.INI your permanent bootup file by entering in
COPY AMOSL.INI=EMAIL.INI
EMAIL is now up and running and you are ready to go!
FILE STRUCTURE
==============
Below is a synopsis for those of you who would like to know
how the EMAIL system files are used.
EMAIL.DAT (located in the BOX: account, DSK0:[7,2])
EMAIL.DAT is a random file that allocates 1 block per EMAIL
user. If you defined 40 EMAIL users as the maximum number of users,
then EMAIL.DAT is 40 blocks long. Each block contains the following
breakdown:
- 40 records of 6 bytes that contain USERS MAIL
a) read/new flag 2 bytes
b) filename (packed) 4 bytes
-------
6 bytes (total 240)
- 40 records of 4 bytes that contain UNREAD MAIL
a) filename (packed) 4 bytes
-------
4 bytes (total 160)
-----------
sub-total:400
* in addition, there is an 80 byte "auto reply" buffer holding
user's cute auto reply in ASCII at offset 400
As you can see, there are some limits to the EMAIL system. You
are allowed to have up to 40 new and saved mail, plus 40 unread mail
files per user. If a user has all 40 slots filled in the new/saved
mail array, no other user will be able to send mail to this user until
this user creates space with the DELETE option in EMAIL. If the user's
UNREAD mail array is full, the user still may send out messages, but
EMAIL will not record these messages in the senders UNREAD listing.
As more users are defined on the system as your system grows,
more and more of EMAIL.DAT is used (1 block/user). This is why you
should be liberal in your allocation of "maximum number of EMAIL
users". Better safe than sorry, so be sure to leave room for growth.
When a user is DELETED from EMAIL via MAILOP, the block is
"up for grabs" by the next new user added to EMAIL. If there was some
new/saved mail or unread mail left by the deleted user, this new user
would "see" this junk. Therefore, remember: always clean out a user's
mailbox who is going to be deleted BEFORE you delete them. This will
leave your new EMAIL user with a clean slate.
EMAIL.SYS (located in the BOX: account, DSK0:[7,2])
EMAIL.SYS is just a "dummy" sequential file that gets loaded
into system memory at bootup to reserve space for the EMAIL.USR data.
EMAIL.SYS has a size of one block more than EMAIL.USR (for buffer
safety and pointer compensation). This file contains absolutely
nothing but nulls ("0"), but is very important to the operation of
EMAIL.
EMAIL.USR (located in the BOX: account, DSK0:[7,2])
EMAIL.USR is a random file that is INT(max user number/20) in
size. When the file is created via MAILOP, the only "live" data is the
relative block number pointer into EMAIL.DAT: user number 1 has the
first block of EMAIL.DAT, user number 2 the second block, etc. When
a user is actually defined on the system via MAILOP, the user's NAME
and PASSWORD are written to EMAIL.USR. The other variables for the
user (see below) are alway nulls ("0's") in this file.
Each block of EMAIL.USR holds statistics for 20 users. Each
user occupies a total of 24 bytes. Below is the breakdown:
- Each user occupies 24 bytes as follows:
- name (packed rad50) 4 bytes
- password (packed rad50) 4 bytes
- record pointer to .DAT 2 bytes
- record "in use" semaphore 2 bytes
- 3 JOBIDX records 12 bytes
---------
TOTAL ARRAY SIZE PER USER: 24 bytes
* There are 480 bytes used in each block, 32 bytes are unused
per block. This was done to make programming easier (divisible
by 20 much easier than 21!).
* The first block contains a count of the total number of blocks
in EMAIL.USR located at offset 508. inside block "0".
* EMAIL.USR is loaded into system memory, replacing a bogus file
EMAIL.SYS byte for byte (mirror image of EMAIL.USR in system).
The MALINI program does this copy for us.
* EMAIL.SYS will now dynamically be updated when users log on
and off and when updates to EMAIL.DAT are critical (their
semaphore and IDX values ONLY).
FILES CREATED BY EMAIL
======================
EMAIL will always consist of the programs listed at the top of
this document plus the EMAIL.DAT, EMAIL.USR, and EMAIL.SYS files that
are created via MAILOP. However, EMAIL will also create other files on
your system as users begin to employ EMAIL. Let's take a look at what
files are created by EMAIL, which ones are "permanent", and which ones
are "dynamic".
There are 3 file types sent by a user: 1) a file created via
VUE from within the EMAIL program, 2) a previously created VUE file
NOT created from within EMAIL, and 3) a "bulk mailing" file.
There is also a "USER.BLK" file created if the user ever
defines bulk mailing packets.
1) File Created via VUE from within EMAIL
When a VUE file from within EMAIL is created, the file is always
located in the user's PPN who executed the EMAIL VUE command. The file
will also always have a *.MAL extension. Upon a EMAIL SEND, the file
is taken from whatever account the user was logged, and it is moved to
the BOX: account. The name of the file remains the same, but the data
inside the file is encoded so that no one may VUE or TYPE this mail
message once sent except through EMAIL. This insures privacy.
The actual name of the *.MAL file is rather UNIMPORTANT. A
user may call their mail files any valid "garbage" name they like -
the filename is "transparent" to the EMAIL system as far as the end
user is concerned. Therefore, a DIR on the BOX: account will more than
likely display all sorts of wild names to you, all ending with .MAL.
NEVER erase ANY file in the BOX: account that has a .MAL extension!!!
After the user has sent a file of type (1) to a user and the
file is encoded in the BOX: account, the original file plus the .BAK
file that VUE created in the users PPN is then ERASEd! Note ERASEd.
This keeps all PPNs clear of *.MAL files that were sent via EMAIL.
2) File created in PPN outside of EMAIL
If a user first creates a VUE file (or for that matter, uploads an
ASCII file via modem) in a PPN and this file DOES NOT END WITH .MAL,
then the user may send this file via EMAIL to a user and EMAIL will
NOT ERASE this file. Only *.MAL files that are sent via EMAIL are
ERASEd. However, once the user sends this file once, they may not send
this file to anyone else unless they RENAME the file (EMAIL will give
the user instructions in this case since every *.MAL file in the BOX:
account must be unique).
3) File created (or not) via EMAIL sent with the BULK option
When a user needs to send an identical message to a group of users,
then they may create a VUE file from within EMAIL and use the BULK
option. This option takes the filespec and creates "random" filenames
and sends a unique filename copy to each specified user in the BULK
packet. If the ASCII file had a .MAL extension, the .MAL file and the
corresponding .BAK file would be deleted after all copies of the
original were sent. If the file was NOT a .MAL file, the file will
remain in the user's PPN. The "random filenames" are created via the
system time, so you will also see many "######.MAL" files in the BOX:
account. Do not erase these files.
In addition to the *.MAL files created by EMAIL, if a user
ever decides to create bulk mailing packets, there will be a file
created in the BOX: account that has a filename of "email user.BLK".
(i.e., DAVE.BLK for EMAIL user Dave). This file is a one block random
file that contains this user's unique bulk mailing "packets" (a packet
may contain up to 15 EMAIL users inside). Here is how this one block
file is broken down:
- bulk mailing "packets" that contain the following:
Name of Packet (packed RAD50) 4 bytes
Names of users (packed RAD50) 4 bytes/user (15 max)
---------------------
total per packet: 64 bytes
8 packets/user: 512 bytes
USING WHOSON.LIT
================
WHOSON.LIT is a bonus program. It is almost identical to the
WHO option from within EMAIL. This program will look at EMAIL.SYS and
list all users who are defined on EMAIL. Users who are on-line are
displayed in bright, off-line users are displayed in dim.