
7		            
7		                            
7		                      
7		                          
7	                   

        ͻ
        Vol 1      This month's features of IceNET NEWS      Issue 2
         Oct       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~       1992  
             1. Slightly Fictional History of IceNET....Louie 6@1   
                                                                    
             2. Backing up...............................Jim Wire   
                                                         1@3950     
             3. Sysops Speak - Validation...........IceNET Sysops   
                                                    (At Large)      
             4. IceNET Puzzle of the Month..........Generic Sysop   
                                                    1@5851          
             5. Mod Discussion-BANZAI02.............Airmon          
                                                    1@7491          
        ͼ





                   A Slightly Fictional History of IceNET
                   --------------------------------------

        As an editor of IceNET one of the many pieces of e-mail we get here is
the request for information.  Of these some are the request for the start of
IceNET.  Well with a little proding Jim and I have got our resident political
expert Louie to put the origin of IceNET in a few of his own words..

        It was a Dark and Stormy night - well, not really, but it sounds alot
better when you start dumb things like this with that phrase.  Jim was sitting
around the Penthouse with nothing much to do. You can only look at the naked
girls so many times.

        So, naturally Jim decided to put up a BBS. What else was he supposed to
do?  Well, Northstar and IceFrezzer got involved somehow.  They aided Jim in
deciding what software to run, what to call the board and in emptying a lot of
beer cans around the penthouse.  So, when it got around to deciding on a handle
for Jim...naturally the Brain Trust at work couldn't think of anything better
than "JIM".  Icefrezzer was in favor of "Godzilla, Emperor of Death" for a
while, but then Icefrezzer passed out and Northstar said "I think he's dead,
Jim" and wellm, BBS history was made.

        Of course, when Northstar and Jim decided to form a small local network
in this area of the universe we call Buffalo, NY.  They decided to name it in
the honor of their thought-dead commard in Bytes, Icefrezzer.

        But then, Icefrezzer came to and let the honor go to his head.  Of
course, Jim and North thought it had something to do with devine intervention
on his behalf (and why isn't it bewhole? Behalf sounds like its a second hand
mircal, doesn't it?).

        Then the great expansion came upon IceNET and soon it was a full seven
boards.  Imagine that, seven boards.  Hell, WWIVNet was only pushing about 1100
at the time.  Thats alot. (NOT!)  Soon after that it had managed to make it all
the way up to about 12 or so and then the War Council had another meeting.
"Gentleputz's, we have a mission.  That mission is to stop Wayne Bell and his
evil forces from world domination of WWIV-Land" was Jim's remark.  In the
center of the room, on the table with assorted beer cans present all around was
a large colored map of WWIVNet. "This is our plan for World Domination" was
what Jim said next..."First we take New Orleans".  When I asked why New Orleans
Jim said "Shut up number one, don't you realize what marti graw is?"  Louie
responed with "I'm not #1. I'm #6. Can't you see that little number next to my
handle in e-mail and on posts you big meany?!?" and started jumping up and down
shaking the Penthouse alot. (So, I'm a big person... Sue me!)  After Louie was
calmed down with a beer the move was made.  New Orleans was taken and the War
Council rejoiced.

        Next were invasions of every nook and crany of the American
BBS-Landscape.  It was proceding nicely until one day, somebody realized all
that manual channing of the net files was just getting a tad time consuming
everywhere.  So, naturally a Plan to obtain Evil-Waynes net stuff was devised.
"First, we make him think we aren't a threat" Jim said.  The general response
from the War-Council was how to make him think that after the little bomb in
the PO Box incident.  (why did you think Filo handles all that stuff now?)
Killertrees (who looks just like you think a Killertrees would look) had a
suggestion of a little visitation to Wayne making him realize it would be worth
his while.

        So the organizing committee for Treats Against the Random-Putz (TARP)
had Killertrees fly out to Southern Calfornia and have a little talk with that
Wayne Dude.

        Grath tried to defend Wayne, but well, he was made into a Shiskabob.
Then it was all explained what IceNET Really meant IceGagglishes in Lake Erie
if he didn't cooperate.

        The NETup stuff was obtained and Wayne hasn't been the same since. We
hear he is still trying to get the stains out of his Underware.

        Then came the next major dession.  The dession not to do battle with
the Empire (er...WWIVNet).  "They are too strong still.  use the force, Luke.
use the force..."  So the dession to take out the WWIVLink dudes first was
decided upon.  First, make them have these really big arguments over weather to
get NETup or contunie to use that clunky stuff they had. The idea being that
alot of would run away from Link and make them join IceNET. Once in IceNET...
they would be members for life under penalty of death.  What you say?  You
didn't read the fine print in the IceNET application.  I'm so sorry, NOT.  Then
came the faitful day that IceNET would rivil WWIVLink in size and well the War
Council had decided to make sure that Wayne Bell dude would really have his
bell rung, but then, that hasn't taken place yet in the Battles of the WWIV
type networks and well, we don't want to spoil the surprise for Wayne now,
would we. Just one thing, Wayne, hire large bodyguards!  Guys that could stop a
charging Killertrees with a battleaxe.

                <EVIL LAUGHTER FROM THE AUTHOR> Hahahahahaha

        So there you have it.  All your answers and a story to beat.  Louie may
be reached at the following address:

    IceNET 6 @1
    WWIVnet 6 @7655
    WWIVLink 6 @17662
    (yeah, 6 6 6)



 Featured Article 
Ľ

                       Jim Wire on The Importance of Backing up

        As a sysop, backing up your system is important to both you and your
users.  Users will tolerate the loss of the user list more readily than the
loss of data files for a game.  I know that you've all heard the saying, `Real
sysops don't backup'; but I AM a REAL sysop, and I backup religiously.  I've
run a BBS on hardware thrown away by others for well over 5 years now.  Since
most of my hardware was discarded by someone else because it failed, I have
learned that there is only one rule.  It WILL fail.  This rule is no less true
of new equipment; but with old equipment you learn to believe, even honor it
very quickly.

        There are some things others think constitute backups that are at the
best unsecure, at worst foolhardy.  If you routinely (automatically) copy a
roup of data files to the only place other copies of those files exist without
making certain that the files are intact, you are inviting disaster.  If the
files become corrupted and you `BACK' them up onto the last copy you had that
was not corrupted all is lost.

        Here are some more things you may not have thought about:

1.  Backing up onto your only backup is suicide.  If you should have a hard
    drive crash during the backup, or even a short term power interrupt, both
    the drive and the backup can be rendered useless.  You should have at
    least two sets of backup media, and alternate between them.  As you will
    see later, the strategy I actually use requires more than two sets.

    In the event of a floppy drive failure during your backup, you no longer
    have a meaningful backup either.  Should your hard drive fail before the
    floppy drive is replaced and your backup accomplished, you have no backup
    and all is lost.

2.  Files copied (compressed or otherwise) to another partition or directory
    on the same hard drive are only of short term use.  These file may be
    useful if you discover a corrupted data file; but in the event of a
    hardware failure (power supply, mother board, hard drive, controller card,
    or drive cable) you can not recover them easily.  Depending on the mode
    of failure all of it may be gone forever.

3.  Files copied (compressed or otherwise) to another drive on the same
    controller card are only useful until you can really do a backup.
    These files may be useful if you discover a corrupted data file; but in
    the event of a controller card failure you can't recover them, unless
    you replace the failed controller card with one that is 100% compatible.
    Replacing hardware under those constraints may not be cost effective or
    expedient.

    With SCSI or IDE drives, the above may not be true.  The controller
    card is not truly a controller card; but a host adaptor.  Any drive
    of these two types should work with any host adaptor of the same type

4.  Backing up for the first time, when the hard drive starts to act `WEIRD'
    is the wrong thing to do.  Usually you notice the `WEIRDNESS' because
    some of your data files have become corrupted.  Since this corruption
    is ordinarily not noticed until it has become severe; it is probably
    too late to get many of your files back.  The time to back up is when
    things are running amazingly well, and it has been two weeks since the
    board crashed.

5.  Backing up too frequently may also cause problems.  If you should
    discover files have been corrupted and the files have already been
    backed up to all your backup media you can not recover.

                        Selecting a backup program:

1.  You will want a program that offers data compression.  One that can
    selectively compress files is best.  Though the compression will be
    either on or off for the entire backup.

2.  Make sure that the program can restore individual files and makes those
    files easy to find.  It does you no good to have a file backed up if
    you can not easily get to it to restore it.

3.  Find a program that can survive the failure of one diskette out of the
    backup with minimal loss of data.  Test this feature of the program
    and make sure it works as you would expect.

    Make a backup that consists of at least three disks.  Remove the second
    disk from the set and compare.  See how much data was lost.  Do the same
    thing with the first and then the last disk.

    Many backup programs put vital information on the first or last disk in
    the set.  Make certain the program you choose can survive the loss of
    any single diskette in the set.

4.  If you are using a program that is new to you, it is best to keep an old
    set from the program you used before around while you develop confidence
    in your new program.  Run a backup with the new program and restore some
    files to make sure it works the way you expect.  I actually had one
    backup program, a long time ago, that was not able to restore files.
    Talk about a rude awakening.  Seems that one of the data files required
    to restore was left behind on the hard drive (which was dead).

                                My backup strategy:

1.  Floppies:

    A.  I do my backups on Mondays and Fridays to alternate sets of disks.
        These sets are divided into two subsets, one is for the BBS and all
        of its data files and the other is the download area.  For the
        BBS subset I use maximum compression, for the download area I
        use no compression at all, trying to compress compressed files is a
        waste of time and can actually take more floppies.  I do not back up
        software that installs as quickly or easily as it would restore (DOS,
        PCTOOLS, and BORLANDC).  I use 1.44MB floppies (2 drives) and
        CPBACKUP from Central Point Software.

    B.  The first Monday of each month I rotate in a third set of disks and
        retire the most recent backup for a month and take it home (the BBS
        system is in my office at school).  This safeguards files that may
        get corrupted and that corruption lies undetected for an extended
        period of time.

    C.  The first time I use a set of diskettes for backup I verify the
        integrity of the backup.  This is not the same as having verify
        on during the backup; I do the backup, then a compare.  If any of
        the diskettes fail it is marked as such and removed from the set
        on the next backup, which is also followed by a compare.  When I
        have a set that has produced 2 successful compares I trust it, and
        no longer do the compare.  The backup diskettes seem to last
        indefinitely, since they are written to and read from sequentially
        at all times and never randomly.

1.  Tape

    A.  The tape transport I have in my system is one that I would not replace 
        with a similar system were it to fail.  Due to this fact, I do not rely 
        on it for my main backup.  I use it for backups that I intend to 
        restore from in the near future, it sees limited use in my backup 
        strategy.

    B.  I keep the current backup in the transport so that I can restore
        files from remote easily.

    C.  I have it set up so that I can do a backup from remote for a variety
        of reasons, vacations and all.

        You may see that with my strategy if I have a total hardware failure I
can restore the BBS to another CPU in a matter of about an hour and have the
system back on line with data no more than 5 days old.  It is not as good as
I'd really like it to be; but within the constraints of my hardware, it will
do.  I spend no more than three hours a week backing up.  On Fridays I defrag
the BBS drive AFTER the backup and that is included in the three hours.

        Well, I'll turn instructor mode off now.  If you got through this
disertation and are still awake I hope that you gained something....


Jim Wire
HIT BBS


 Math Teaser 
Ľ


I want to have a small math teaser column in the IceNEWS.  Heres a math problem

     They've counted the cats in Llanfair,
     Which number a third of a square.
     If a quarter were slain,
     Just a cube would remain,
     How many, at least, must be there.


Generic Sysop, 1@5851



 System Restrictions 
Ľ

    The cost of a sysops machine can't always be measured in dollars.  The
starting of a board carries a lot of time, energy, patience and other factors
that a persons can't put a price tag on.

    After a board is up, the sysop must deal with the threat of viruses and
hackers and other dangers that come with the electronic hazard.  Questions of
protection and ways to limit what users do come up.

    One way a sysop can guarantee the safety of his board is limit the user
group he has.  Closing the board down to a few select people does in fact make
the board a lot safer.  One factor that also leads to a short life span of a
board is closing it to a small group of users.  The decisions are out there and
you must decide.  Which way will you turn and what are your views of computer
safety?  When asked this, these are the reactions that were sent to IceNET
NEWS:

    Generic Sysop #1 @5851 writes, "I don't believe that all the system
restrictions are needed. It is plainly true that out of the hundreds of calls a
BBS will get in a month there will be a few unrespectful users or hackers, but
thats just a fact of life.  The unrespectable users are mostly people that
don't understand about the time and effort that a sysop puts into their BBS.
Some first time modemers believe that bulletin board systems are run by people
who get paid for their work. Most of the time a long chat with these people
straighten them out and some of them even become good, providing users.  The
ones who know but just don't care can easily be deleted from the system.  After
three or four times they will get sick of logging on as new and give up.

    Then, you have the hacker breed.  You must make sure that your system is
hack proof and then the only damage these "users" can do is cause a few
headaches. It's really not as bad as it seems out here in sysop land.  I, being
a sysop, fully believe that it's worth the time, money and effort spent on
running a quality system. I like to see my users happy with their BBS
environment."

    Bengal #1 @2451 adds, "I do not think sysops should close their systems in
fear of hackers.  Then all of the boards would be running scared like all of
the Pirate boards who are so paranoid about getting busted.  Like around here
in our section IceNet, if we think that there might be a troublesome user for
various reasons like hacking then we ask the others about that particular user.
to see if anyone has any knowledge of that user trying to hack another board.
If we get confirmation, then we can get rid of him on our board as well.  Back
to the point though. I think closing a system is just bad business so to speak.
Also, I don't think a sysop should really tell a user they are not welcome on
his board just because no one has heard of him/her. I mean in my opinion that
gives a board the wrong image."

    Floyd #2 @3480 has this to say; "I think that a sysop should run his/her
board ANY way they see fit.  If they have a lot of hack attempts they should do
just enough to remove that possibilty.  There are ways to make to make your
board essentially hack-freewithout restricting users too much.  Of course
boards that have a lot of hack attempts will have to take action, but for most
boards that take appropriate precautions it wont be a problem."

    Martin #1 @6257 said, "I'm probably one of the more "conservative" Sysops
in the net, as least from what I gather from many of the posts here.  I have,
from day ONE, made a policy of voice validating callers.  This is without
exception, and I have never regretted it.  It has allowed me to run a "tight"
board, with the ability to keep problem callers from ever having an account on
the board again unless they move or change their phone numbers.  It's also
allowed me to stop at least one caller who left some obscene and derisive mail.
I simply called his home and told him that if I got one more piece of mail from
him like that I would speak with his parents.  That put an immediate stop to
the bullsh*t.

        Byte #1 @7454 adds, "I can tell you what I have resorted to after 6
years of running a BBS.  Due to Problems with several users here, ( I don't run
a U/D ratio nor a Post/Call Ratio), the users were calling back giving "Names"
that were not correct and using multiple accounts.  After trying unsuccessfully
to voice validate everyone I gave up.  I am using a registered version of CBV
and if you don't use it or can't you don't have access.  (with exception of the
Auto-Validation for SysOps, that I have not had the time to Fix for WWIV
4.21a).  I will validate long distant callers after midnight and before 6 A.M.
because of costs.

        Blok #3 @5806 added, "although I know of several boards in this area
that use some (or all) of the validation technques mentioned, I use them only
in the case of users requesting access to areas that are age restricted.  (ie.
the Adult games, or the X-Rated Gif file area, (one user with access so far)
and then I use voice validation, and verification of identity through personal
contact if there is any question.  In general, as long as it's a good fake
account, let 'em have it."

        JAFO #1 @8857 thoughts were, "I believe voice validation is a MUST.
Although people can get around it by giving the number of their best friend or
something, it is usually a good means of protection.

        I personally don't have a NUP at the moment, but I feel that when I get
my 16.8 Dual, I am going to put one up.  I'll also change the NUP once a week,
so that nobody can give out the NUP except me.  That is a sure fire way of
knowing exactly who is calling my board.  Also, it's easier to just say I don't
want to give them the NUP than to delete them once they've called.  I always
feel guilty when I deny someone access and delete them.  It would be *much*
easier to just say something to them in e-mail.




                             Mod o' the Month
                             by Airmon 1@7491 (soon to be @9901)
                             Featured Mod: BANZAI02.MOD
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

        Hello fellow IceNet sysops, I am here to bring you: "Mod o' the Month".
In this column, I will bring you a mod that I feel is both well written, and
beneficial to sysops.  Of course, the mods I bring you each month, are simply a
matter of my opinion.  I got this idea from Filo, and his column in the WWIVnet
Newsletter.  I hope you like it.

        This month's "Mod o'the Month", is BANZI02.MOD, written by Buckaroo
Banzai, IceNet 1@3467.  This mod is a Multi-Network/Multi-Mail mod.  I think
this is an excellent mod, and extremely useful.  See if you like it too.

/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\

NAME: BANZAI02 - Multi-Net Multi-Mail
BY  : Buckaroo Banzai
DATE: 09-08-92
VERS: WWIV 4.21a+ ONLY
DESC: True Multi-Networked Multi-Mail (with Mailing Lists)

        Back when I first purchased the source to WWIV, oh, I think that was
4.12, I found a mod that I really got along with.  It was called "NSMAIL".
Written by 8-Ball, it allowed SubHosts to send mail to the sysops of all
subscribing systems of any sub they hosted.  The only thing it lacked, however,
was the ability to send mail to Co-sysops, or Limited CoSysOps who ran other
message bases.  Well, I was teaching myself C, so I sat down and put a few
things together (don't ask me how, I lost the old source code) and it worked!
Then, as luck would have it, I was laid off.  My Laptop, company property, was
stolen (given back to the company), and with it, my only copy of the modified
source code (since zapped by WIPEINFO).  Real Drag.  So when I got the source
to 4.21a, I decided to try and figure out how it was done (again), maybe with a
little improvements.  I re-installed NSMAIL, made a few changes due to the fact
that NSMAIL was written for 4.11, and then sat down to figure out what I had
done before.  After fruitless hours of effort, I trashed that idea and started
from scratch.  This mod, based loosly on (and compatible with) NSMAIL, will
allow you to create a mailing list in your data directory with up to 100
addresses.

                                On to the Mod:

STEP ONE:

        Erase your source code.  Yep, all of it. (Yea, right. if you did that,
you DESERVE what you've got comming.)

STEP ONE and ONE HALF:

        Grab your handy backup copy of your source, and unzip it into a good
working directory.  Or skip this step if you skipped #1.  In short, MAKE SURE

YOU HAVE A BACK-UP!

STEP TWO:

        Fire up your trusty copy of Qedit and load BBS.C.  Look for the
following code in function mainmenu, and make changes as appropriate.

    if (strcmp(s, "CHAT")==0) {
      nl();
      pl(((*(char far *)0x00000417L ^= 0x10) & 0x10) ?
                       "Sysop now available" :
                       "Sysop now unavailable");
      sysoplog("@ Changed sysop avail status");
      topscreen();
    }
    if (strcmp(s,"NMM")==0) {                        /*_+_MNMM_*/
      sysoplog("@ Used NetMultiMail");               /*_+_MNMM_*/
      nmmail();                                      /*_+_MNMM_*/
    }                                                /*_+_MNMM_*/
  }
/**************************************************/

Save BBS.C.

STEP THREE:

        Load up MULTMAIL.C, and step down to the end of the file.  Block read
the next two items into the file. The first is a structure declaration for
holding the addresses of each person on the list.  The second is the void
called by the 'NMM' command above.

typedef struct {
    int thisuser,
        thisnode,
        thisnet;
} address_rec;

void nmmail(void)
{
  char s[81],s1[50],s2[81];
  int i,q,x,max;
  FILE *fp;
  address_rec add[100];

  nl();
  prt(1,"(*> NetMultiMail <*)");
  nl(); nl();

  outstr("Which mailing list? ");
  mpl(8); input(s2,8);
  nl();
  sprintf(s,"%s%s.NMM\0",syscfg.datadir,s2);
  outstr("Reading in Distribution Control File: ");
  pl(s);
  if (!exist(s)) {
    prt(6,"ERROR!\7");
    pl("  The specified file does not exist.");
    return;
  }
  if ((fp=fopen(s,"r"))<0) {
    prt(6,"ERROR!\7");
    pl("  Could not open Distribution Control File");
    return;
  }
  for (i=0;(!feof(fp));i++) {
    q=fscanf(fp,"%d@%d=%d",&add[i].thisuser,&add[i].thisnode,&add[i].thisnet);
    if (q!=-1)
      npr("\r\n%i @ %i, %s",
        add[i].thisuser,
        add[i].thisnode,
        net_networks[add[i].thisnet].name);
  }
  fclose(fp);
  max=(i-1);
  npr("\r\n\nTotal Addresses in List: %i\r\n",max);

  nl();
  prt(2,"Enter name of file to send: ");
  input(s1,50);
  if (!s1[0])
    return;

  for (i=0;i<max;i++) {
    set_net_num(add[i].thisnet);
    sprintf(irt,"NetMultiMail List :%s",s2);
    if (add[i].thisnode) {
      load_workspace(s1,1);
      email(add[i].thisuser,add[i].thisnode,-1,0);
    }
  }
  nl(); pl("Done!");
}


Save MULTMAIL.C.

STEP FOUR:

        If you already have installed 8-Ball's NSMAIL, you're done.  Just MAKE
FCNS, MAKE, and call it a day.  Otherwise, you're in for some fun.  I will not
lie, the rest of the directions (with a few upgrade changes) are taken straight
from NSMAIL, as they are the exact commands needed.  Why waste good ascii when
it's already been typed once?


Step 5:  Now we get into the nitty gritty of the mod.  Load up MSGBASE.C and
search for void email (unsigned short un, unsigned short sy, int forceit, int
anony).

*** ADD TO THE LIST OF VARIABLE DECLARATIONS (you would be surprised how many
people miss this instruction in my other mods.  So I'm putting it in all caps
for the vision-impaired)

  int nsmail=0;

Don't forget the =0 or it will won't work.

Step 6: Still in MSGBASE.C (we'll be here for the rest of the mod) add the
code shown at the very beginning of the existint code. /*==*/ shows existing
lines, /*++*/ shows lines to add.

/*++*/ if (forceit<0) {
/*++*/   forceit=1;
/*++*/   nsmail=1;
/*++*/ }
/*++*/
/*==*/ if (freek1(syscfg.msgsdir)<10.0) {
/*==*/   nl();
/*==*/   pl("Sorry, not enough disk space left.");

Step 7: Look down (still in void email) for the lines below.  It's about
110 lines in my source but I've played around with it, so somewhere around
100 lines.  /*==*/ shows existing lines, /*++*/ shows lines to add.

/*==*/  m.msg.storage_type=EMAIL_STORAGE;
/*++*/  if (nsmail)
/*++*/    inmsg(&msg,t,&i,!forceit,"NSMAIL",ALLOW_FULLSCREEN,s2,0);
/*++*/  else
/*==*/    inmsg(&msg,t,&i,!forceit,"EMAIL",ALLOW_FULLSCREEN, s2, 0);
/*==*/  if (m.msg.stored_as==0xffffffff)
/*==*/    return;
/*++*/  if (nsmail)        /* Don't forget to change this to your handle */
/*++*/    strcpy(t,"4Multi-Mail from Buckaroo Banzai0");
    /* use the ^P^C sequence for the color here */
    /* in the Turbo editor you should get <heart>4 then <heart>0 */
/*==*/  if (anony & anony_sender)
/*==*/    i|=anony_receiver;

Step 8: We're done with void email.  It would probably be a good idea to
save the file now, just to be safe.  In any case, you now should find
void inmsg(messagerec *m1, char *title, int *anony, int needtitle,
char *aux, int fsed).  It's above void email but it's a long-ass function.
Once again,

*** ADD TO THE LIST OF VARIABLE DECLARATIONS

  int nsmail=0;

Step 9: Now add the following code right before the existing code, just
like you did for void email.

/*++*/  if (strcmp(aux,"NSMAIL")==0) {
/*++*/    nsmail=1;
/*++*/    strcpy(aux,"EMAIL");
/*++*/  }
/*==*/  if ((fsed!=0) && (!okfsed()))
/*==*/    fsed=0;

Step 10: Hop down about 30 lines and look for and mod as shown:

/*==*/  nl();
/*==*/  helpl=6;
/*++*/  if (!nsmail) {  /* this is the only line added here */
/*==*/  if (okansi()) {
    /* after this it inputs the title.  I forget how it looks because */
    /* mine is modified but the helpl=6 should be enough to find it */

Step 11: Look down about another 25-35 lines (this is after the title
input.  Again, mine is modified so I can't show you what an unmodded
version looks like but the fsed part should be enough to find it)

/*==*/    }
/*==*/  }
/*++*/  }   /* this is the only line to add */
/*==*/  if (!fsed) {
/*==*/    sprintf(s,"Enter message now, max %u lines.",maxli);
/*==*/    pl(s);

Step 12: Save everything and re-compile.

*** USE OF THE MOD ***

Ok, I take over again here.  The mod is fairly user-friendly. Go into your data
directory, and create a file (any file) with an extension of .NMM. This will be
your NetMultiMail List. The format of the file is as follows.

xxx@yyyy=z
xx@yyyyy=z
x@y=z

Any number of digits, as long as the UserNumber (xxx) and the Node Number(yyyy)
are both less that 37200.  Standard limit. The '@' and '=' MUST be there, as
format controls.  The Network(z) is the one that's gonna give people trouble.
This number is determined by subtracting 1 from the number listed in the 'N'
section of INIT for any Network you belong to.  FOR INSTANCE:  Say you run a
three-net system.  Your first network is WWIVNet, your second, WWIVLink, and
your third, IceNET. If you were sending mail to 1@1 WWIVNet, 1@3050 IceNET, and
143@13900 WWIVLink, your file would be as follows:

1@1=0
1@3050=2
143@13900=1

Get it? If not, feel free to Email me. My thanks go out to 8Ball, whereever he
may be, for not suing me for using his words (and code), and to my lovely
CoSysOp (and wife!) Arianna for long hours of backrubs.

DISCLAMER: If your Cat barfs on your keyboard, or your baby dumps Pepsi in your
new Tape Backup Unit, IT AINT MY FAULT.

===============================================================================

IceNEWS Editor..............LouHal  @10
IceNEWS Proofs..............Jafo    @