
PAMS:

I am going to attempt to describe more in detail, how the Michtron NETwork
system works. What files gets created and when..

When first setting up MNET, you have the folders INMESS, where inbound messages
are stored for processing, OUTMESS, where outbound compiled messages are
stored, and CONFER, where the actuall messages are kept.

When setting up the CONFER folder, you will need to set the MYSYS file within
this folder. This stores the TAG line that is displayed at the bottom of each
message. The MYSYS file contains both the NODE number of your system and your
TAG line.. The length of your TAG can not be more than 70 characters long. With
this in mind, MYSYS can not be longer than 74 characters, or the rest of the
TAG line will be truncated.

HOW ARE THE MNET MESSAGES CREATED AND STORED?

By use of the MBBS editor, the messages are created. We did this simply because
that tool is readily available and makes the MNET more compatible with MBBS.
Once a message is written and the save command initiated, it will store the
message in file >CONFER.xxx<, where xxx is the message number. The header
information is stored within the CONFER.LOG file. Information stored here is:

NODE that the message originated from. This is usefull so that messages don't
get repeated over and over within the network.
FROM who the message was from.
TO who the message is to.
SUBJECT, what the message is about.
CONFERANCE this is defined as 1 character in the ASCII format. Example,
subtract 32 from this ASCII value to determine the conferance number. As of
now, we are only using 1 conferance so the character will be a !, or ASCII
value 33. As we develope the use of conferances, we can have up to 232
conferances online with this system.
MESSAGE NUMBER, this is 3 digits that tells MNET what file to retrieve for this
header.
DATE, this 4 digit variable is the packed integer of todays date, as per
Michtron.
TIME, this is created within the system to display the time of the message.

This same header information is stored in the OUTMESS folder in a file called,
datenode.net, 6294100A.net. This file is the control file for MNET to arc the
correct messages to the mail packet with the same datenode but with an ARC
extender.

OUTMESS.LOG is created to store the datenode.net's that need to be processed by
MNET.PRG


WHAT OTHER FILES ARE CREATED BY THE PROGRAM?

A file called POINTER.CON is created to tell MNET what was the last file
entered into the system. This file is VERY important as it controls the making
of NEW messages and also is used to determine how many new messages each user
has.
Another file called MNET.DAT is created. Every day, MNET will perform its
'CLEANUP' routine, where it removes the headers of deleted messages. Example:
Let's say you delete a message from the MNET system, the actual message is
deleted, CONFER.xxx, but the header remains.  I could have very easily
programmed MNET to do a cleanup after each deleted message, but that could take
very long if you deleted several messages. During the cleanup routine, here is
what happens:

The MNET.LOG is opened and reads the first line.
It determines the message number and determines if the message is still active.
If it is, the header is copied to the MNET.DAT file. If no message is found,
the header is not moved.
After is has completed this for every message, it then reads the confer.dat
date back into the confer.log file.

TODAY.DAT is used for the MNET patch for HUB systems only. However, this file
is created each time someone enters the MNET system from MBBS.

In each of the INMESS and OUTMESS folders, a file called DIRECT.TXT is created
when MNET.PRG is run. This file contains the directory of each of the folders.
Only files with .ARC extenders are kept within DIRECT.TXT. This is used for
uploading and downloading of your files from MNET.PRG.


WHEN MNET.PRG IS RUN, WHAT EXACTLY IS HAPPENING?

When MNET.PRG is first executed, it creates the title screen and attempts to
load the following files:
MNET.KEY, the encrypted file that unlocks MNET
MNET.CFG, the file telling MNET where files are kept and how its to operate
NODE.LST, the node list.

MNET then will check the INMESS folder to determine if any mail needs to be
processed. If so, it does. Each mail packet should include at least 1
CONFER.xxx file along with 1 and only 1 datenode.net file. Once the packet is
un-arc'd and it locates the datenode.net file, it will process the messages
into the CONFER folder. Remember, datenode.net contains the header information.
This information is added to CONFER.LOG and also added to datenode.net in the
OUTMESS folder. The messages are copied into the CONFER section and off to the
next routine.

MNET then will check the OUTMESS folder to determine if any messages needs to
be inserted into a mail packet. MNET will search for OUTMESS.LOG to tell MNET
what datenode.net files to process. It then opens that datenode.net file and
reads line by line. The MNET program than reaches out to the CONFER folder and
retrieves the message corresponding to the header. A ARCfile is created with
the same datenode filename and the messages and datenode.net is added. This is
done until all datenode.net's have been process as per OUTMESS.LOG.

MNET will now allow you to create the BATCHQUE file. This file stores the
filename and pathname of each file selected by you to send to your HUB. NOTE: I
have entered the last day that you called above so that you have an idea as to
which files to send. Exit the BATCHQUE by hitting CANCEL.

If you are a HUB(2) or SPOKE(3), your system will then attempt to call your
HUB. It will try forever. A CONTROL-C will break the dial sequence and exit the
program. Once connected, MNET will wait for the USERNAME and PASSWORD prompt
and enter the information as per the MNET.CFG file.

Once the HUB system recognizes you as a MNET BBS, it will send NEW files via
YMODEM BATCH. The system knows you lastday called because MBBS stores that
information for us. The reason I used YMODEM BATCH is that it will send the
filename of the file for us. It will loop until all files are sent.

The system then will ask for a filename to upload. If no files are to be sent,
an ESC character is sent and you are logged off. If files are to be sent, MNET
will send the filename and prompt the MBBS to send XMODEM 1K. When sending
files, it stores them into the INMESS folder. The MNET patch program will
prompt you in the MNET.LOG if a file might be a repeated file. This is done by
checking the date of the DATENODE.ARC versus the lastday called.

Carrier is dropped and the mail that was received, if any, is processed as
above.

The system then shows the status screen and exits.


I hope this simplifies what MNET is doing and what files gets created and when.
I really appreciate the patience everyone has displayed while we still attempt
to work the bugs out of this program. The end result will be an error free
NETWORK that the MBBS sysops can use.
