ftp.wwiv.com/ftp.wwiv.com.zip/ftp.wwiv.com/pub/HATCH/WWIVNEWS.ZIP/9206.NWS

Text File | 1992-06-25 | 32KB | 556 lines

               ┌┐┌┐┌┐┌┐┌┐┌┐┌────┐┌┐  ┌┐┌─┐ ┌┐┌────┐┌┐┌┐┌┐┌────┐
 ╔═════════════││││││││││││└─┐┌─┘││  │││ └┐│││┌───┘│││││││┌───┘═════════════╗
 ║  Volume 3   ││││││││││││  ││  └┼┐┌┼┘│  └┘││└───┐│││││││└───┐  June 24    ║
 ║   Issue 2   ││││││││││││  ││   ││││ │┌┐  ││┌───┘││││││└───┐│   1992      ║
 ╚═════════════│└┘└┘││└┘└┘│┌─┘└─┐ └┼┼┘ ││└┐ ││└───┐│└┘└┘│┌───┘│═════════════╝
               └────┘└────┘└────┘  └┘  └┘ └─┘└────┘└────┘└────┘
                           ┌─────────────────────┐
                           │This Month's Features│
┌──────────────────────────┴─────────────────────┴───────────────────────────┐
│ Random Factors.......................................Wayne Bell (1@1)      │
│                                                                            │
│ "With Our Easy Payment Plan..."......................Filo (1@5252)         │
│                                                                            │
│ TAMing the WWIV Transfer Area........................Tolkien (1@3456)      │
│                                                                            │
│ Eight Ball's Guide to Duplicate Net Posts............Eight Ball (1@6913)   │
│                                                                            │
│ TechnOTES............................................WWIVnews Staff        │
│                                                                            │
│ Filo's Mod of the Month..............................Filo (1@5252)         │
│                                                                            │
│ Dateline: @#$*()#! - A Farewell From East Bay Ray....Omega Man (1@5282)    │
└────────────────────────────────────────────────────────────────────────────┘

───────────────┬─────────────────────────────────────────────┬───────────────
               │               Random Factors                │
               │   Creative Commentary by Wayne Bell (1@1)   │
               └─────────────────────────────────────────────┘

I thought I'd start out here with a few extended form-letter answers to some
e-mail that I've been getting recently.

First off, no, I do not yet have a date for v4.21a/net31. Net31 will probably
be out 2-3 weeks before v4.21a. The net31 release may be in about 1-2 months.
Maybe sooner, maybe later. When available, net31 will be available (hopefully)
on the SDS's and on the WWIV Support Systems. The compiled version of v4.21a
(when released) should be available on the SDS's and the WWIV Support Systems,
while the source code to WWIV will be available only on the SDS's. As a
reminder, the current SDS's are: @1, @4, @2902, @3459, @5252, @5401, @5460,
@5819, @6211, @7400, @7663, @8350, @9800, and @856 (in Japan). The WWIV source
code should >NOT< be available on any system which is not in the above list of
SDS's. And, the source code on the SDS's is available only to users that I
have authorized to D/L it from there (leave me e-mail from your account on the
SDS, giving your name, full address at time of registration, and WWIV reg #).
If you see the WWIV source code anywhere else, they are >ILLEGALLY<
distributing it, and I'd appreciate it if you would e-mail me telling me about
it.

For those interested (and I'm surprised at the number of people that are), in
v4.21a, there will be a file in the DATA dir listing the networks of which you
are a member. For each network (you specify network name and node number),
there is a separate directory to hold the network files (*.NET, BBSLIST.*,
CONNECT.*, BBSDATA.*, SUBS.LST, SUBS.1, SUBS.2, and *.NET from the GFILES dir).
Net e-mail is then stored with an index into the database of networks to
identify which network it came from. Subs also have an index into the networks
database indicating which network the sub is on. Net-related parts of the BBS
then index into this networks database. For instance, when you scan a net sub,
a global variable is set to indicate which network is the current network. For
e-mail, the BBS will search all available networks for the network with the node
number you specify. If there is more than one network with that node number,
you are presented with a list, and asked to choose one. Functions relating to
calling the network executables (NETWORK.EXE, etc) are in a loop to process all
networks, or to find the correct one. For networks with separate executables
(the link pre-processor, or the DE1.EXE for IceNET), the separate executables
go into the network directory.

If you are interested in starting your own network: Do not e-mail me and ask me
how to do it. There is no .doc file describing how to set up your own network,
and I'm not going to write one. If you are not familiar enough with how the
net software works to set it up on your own (perhaps with some help from
others), then you should NOT be starting your own network. Instead, play around
with the network software, get some external programs that use the net, and
examine them. Look through the network data files, and figure out how they work
on your own. Please feel free to ask others about specific things like, "How
long can a system name be?" or "what is the highest group number possible", but
don't just ask, "How do I set it up?"  You'll then know a lot more about how
the net works, and will be able to handle problems when (not if) you encounter
them.

Even if you do know enough about the network to start your own, first think: Is
it worth it?  Do not just start up your own network because you think you'll
then have power and prestige. It isn't worth it (believe me). If you don't have
anything that will make your network different from other networks already out
there, then PLEASE do not start another one. I really am afraid of having lots
of carbon-copy networks out there, and having arguments about, "My system is in
12 networks" - "Yeah?  Well, mine is in >14< networks!"  It really would be
pathetic if we ended up with a few hundred systems that were all in the same
set of 15 networks. What would be the point?

And, for a final note, a slight clarification/update on the netup software that
is being "sold" for $300. If you don't already have a network up with 20-30
systems in it, it isn't worth it. If you don't have a network up and running,
don't even ask me about it - get things working first. It is $300 because I
have to write a separate EN1.EXE/DE1.EXE set of programs for each network, and
don't want to bother setting it up if someone isn't REALLY sure they want that.

───────────────┬─────────────────────────────────────────────┬───────────────
               │      "With Our Easy Payment Plan...."       │
               │    How to Register WWIV The Deferred Way    │
               │              by Filo (1@5252)               │
               └─────────────────────────────────────────────┘

Editor's note: With the "register or die" deadline either passed or imminent
(depending on the Group you're in), quite a number of sysops who wished to
remain in WWIVnet but couldn't scrape up the $50 in one lump sum were in
need of some sort of installment plan for registering. Such a plan is now
in effect, and is being administered by Filo (1@5252) as part of his new
duties as WWIV Software Services Coordinator. As to how this plan will work,
Filo's comments below, as posted on the National Sysops' Sub sheds some light
on the issue.

─────────────────────────────────────────────────────────────────────────────

New Payment Option

Some sysops have indicated that they just cannot get $50 together at one
time to register. With this in mind, a new payment option has been
developed and will be used by WWIV SOFTWARE SERVICES.

A sysop who wishes to take advantage of an installment plan option,
would fill in the application (see Net29 or Net30) and mail it to WWIV
SOFTWARE SERVICES (see recent letter from Random to All Sysops) and
write on the Application INSTALLMENT PLAN. The sysop would make 3
payments of $20 each. This is how it would work:

Payment 1 -- extends the trial period for 60 days
             applies toward registration
Payment 2 -- extends the trial period another 60 days
             applies toward registration
Payment 3 -- completes the registration fee ($50)
             pays $10 for handling & postage (rather than normal $5).

Total cost under payment plan must be at least $60. If a foreign node
takes advantage of this, the total fee would be $65 instead of current
$60.

Installment Payments are NON-REFUNDABLE. If you do not make the next
installment payment on time, you lose the money you have paid in.

Under this arrangement, the 'poor' sysop can take as long as 4 months to
pay the full amount.

───────────────┬─────────────────────────────────────────────┬───────────────
               │        TAMing the WWIV Transfer Area        │
               │              By Tolkien (1@3456)            │
               └─────────────────────────────────────────────┘

Over the years, the task of keeping up with the file areas on our board had
begun to get wearying. A misspelling in a description seemed to take too
long to rectify. Editing or creating an extended description was even worse.
And then there's virus scanning, stripping out archive comments, and inserting
GIF file resolutions. As a result, I often found the sysop directory filling
up with hundreds of files, which made the thought of having to laboriously
wade through it all just that much less appealing.

Wayne tried to make some of this easier in WWIV itself, with the upload event,
but it never seemed to work all that well for me. Internal modifications to
the code allowed inserting GIF resolutions and virus scanning, but then you
had to do those modifications again, and again, and again, every time a new
version of WWIV would come out.

In 1990 I decided that there needed to be some sort of program devoted solely
to making all these tasks easier, something that wouldn't have to be redone
every time a new version of WWIV was released. I sat down then and began to
write such a thing, but at that time the task was simply beyond me, the scope
too large for me to deal with.

Another year and some went by, I learned a thing or two, and I decided to try
it again. I figured I'd rather spend a hundred hours writing something to
make life easier forever after rather than spending a twenty hours a month
just trying to keep pace.

And, somewhat amazingly to me, I finally succeeded. Thus was TAM born,
standing for Transfer Area Manager. Now editing descriptions, sorting, moving
files, renaming directories, virus-scanning, comment-stripping, viewing docs
inside archives, inserting GIF resolutions, making sure that WWIV's file size
matches the actual size of the file in DOS, even viewing a GIF file to see if
the description is accurate - it's all a keypress or two away. Even better,
when multitasking I can go take care of the transfer area in one window while
someone is online in another. The labor is vastly reduced. I don't feel like
screaming when I see twenty or thirty or fifty files appear in the sysop
directory. I spend a third the time taking care of the transfer area now than
I ever did before.

In short, if you're spending hours and hours maintaining your file areas, you
shouldn't be. It's always going to take *some* work, but there's no reason
anymore for it to take half the fun out of life.

While I'm here, some questions that have come to mind since I first released
TAM need to be addressed:

"Does TAM support file-locking while operating under a multitasker?"

Nope. I suppose that potentially there could be a problem with that if a
directory file were being written to at exactly the same moment TAM is messing
with it. In practice, however, this has not happened to me or to anyone else of
whom I am aware. The odds are greatly against any such problem because TAM does
things fairly quickly - read, write, bail out. Additionally, under OS/2 you are
protected from any possible problems.

"What about modified directory structures?"

I wrote a compiled version that works for those who have Tony Godfrey's GoldSys
mod installed. That executable, along with the "normal" one, is included with
every TAM archive. Source availability - no one who could benefit from having
the source has ever asked me for it. Even if I did give the source code to
someone, to compile it would require Async Professional and Turbo Professional
from TurboPower Software (at around $100 each). Obviously, I cannot give
*those* away so the only people to whom I would even consider giving the source
to would be those who could furnish me verifiable serial numbers for both of
the above. Unlikely, but if it ever happens, I'd probably give it to that
person.

"Just how much overhead does TAM require?"

Memory requirement is about 320K, so it would be possible to run TAM on a 512K
system if shrink were available - probably. In practice, anyone who is running
WWIV on a 512K system really needs to consider upgrading to 640K. TAM runs
fine in 640K, although when it needs to call another program (VPIC, PKZIP,
whatever) it has its own internal shrink method that swaps out of memory to
expanded memory if it's available or hard drive if not. Obviously, having some
EMS available makes things run at a better clip, but it works either way.
Having said this, the more memory you do have available, the more files you
can put in a file area and still be able to sort. TAM's upper limit in
practical use is about 2000 files per file area and up to 256 file areas. The
actual supported limit is 9999 files per file area but you would lose the
ability to sort such a file area long before reaching that absolute limit due
to memory constraint. Still, this is a simple way to overcome WWIV's default
499-file limit for a file area and doesn't require the source code or any
knowledge of programming at all.

"Are any of the aesthetic mods supported?"

As far as colorizing file descriptions and directory names, TAM allows
insertion of basically any character (via the standard control-P control-C
sequence for WWIV color codes), so it's simple to create truly gruesome color
combinations for file descriptions. (Come see some of ours if you want an
example of icky.)

"Does TAM work remotely?"

No. And yes. No, in that TAM does not itself support ANSI or asynchronous
communications. Yes, in that nearly any program can be run remotely if you
use a piece of software that intercepts direct screen prints and sends that
information out the modem. DOORWAY is the most common ShareWare program that
allows this.

"Does TAM convert archive types?"

No. And yes. It does not do so directly, but since you can yourself define
eight hotkeys that call up any program or batch file you want, you can
achieve the same thing with minimal effort: once you've created the batch
files that do the conversion, the process would be to hit the hotkey, then
type in the new extension yourself after the batch file is done processing.
However, this is not an ideal method. Depending on the support I receive, I
intend to make it a simple one-key command to perform such conversions with
no extra effort at all.

Is this a blatant plug? Well, to some degree, yes, but not entirely. Lots of
people don't even know such a utility now exists, because I haven't plastered
that fact all over every sysop sub in the world. Mainly, I just want people
who are tired of the drudgery of maintaining a large transfer area to know
that there is a solution available. I'd have killed for such a utility two
years ago, or even last year. I suspect there are quite a few who are in the
same shoes I was in then. And actually, if you can find something that does
the job better than what I've done with TAM, use that instead; that's the
American way, after all.

───────────────┬─────────────────────────────────────────────┬───────────────
               │  Eight Ball's Guide to Duplicate Net Posts  │
               │           by Eight Ball (1@6913)            │
               └─────────────────────────────────────────────┘

As hard as it might be to believe, duplicate posts on networked subs these
days are almost NEVER caused by someone screwing up with their N*.NET or
NN*.NET files. Although this still happens, there are two other software-based
causes that should also be considered when duplicates appear: incomplete
packet transfer and LNET disuse. The three types are detailed as follows:

Type I: There is a glitch in net connects somewhere. On the sending node,
Zmodem or HSLINK thinks the transfer failed, but on the receiving node it got
the file fine. The sending node will keep the net packet and send it again
(along with new stuff, if any) on the next net connect. If it happens again
this can lead to triplicate, quadruplicate, or more.

Type II: N[N]*.NET file screwup. Subscriber created N*.NET file instead of
NN*.NET file, or host entered node number into N*.NET file more than once.

Type III: Someone deleted a post or e-mail off the local node but forgot to use
LNET to remove it from the net packet (or didn't know how to, or even that
he/she had to)


How to tell is something is a duplicate:

Look at the dates in the headers. If they're the same, it's a duplicate. If
they're different, it's highly likely someone tried to delete a post but didn't
remove it from the network packet using LNET. That's very rare though. (This is
type III below)


How to tell which type you have:

Are you getting more than TWO copies of each post (i.e. 3 or more)?  If so, the
problem is almost certain to be Type I (very very rarely type II, and even more
rarely type III).

If the number varies (sometimes you get 2, sometimes you get 6, sometimes you
get 3) it's almost definitely type I also.


If you are a subscribing node:

  A. Are the duplicates only occurring on more than one sub that you
     carry?  If yes, problem is probably type I, otherwise it's probably
     type II (very very very very rarely type III)

  B. Are the duplicates also happening in e-mail?  If yes, the problem is
     almost _definitely_ type I (very rarely type III)

In general it's easier for hosts to determine where the problem lies...


If you are the host node: (using net val makes things easier...)

  A. Do you see single posts from more than one subscriber?  If so the
     problem is probably type I and is happening somewhere between that
     subscriber and your node.

  B. Do you see single posts but subscribers see duplicate posts?  If
     yes, the problem is definitely type I, and is happening somewhere
     between your node and the affected subscribing nodes (not all
     subscribers will see duplicates, and this will help you detect
     exactly where the problem is)

  C. If you have net validation turned on, do the duplicated posts say
     "Not Network Validated"?  If yes, the problem is almost definitely
     type I (very very very small chance of type III). If the incoming
     posts do *NOT* say "Not Network Validated" then the problem is
     _definitely_ type II (although be SURE you didn't just validate them
     and forget)


Fixing the problems:

Type I: First you have to figure out where the problem connect is. It might be
one of your connects, but not always. The only sure way to tell is to watch a
connect. DSZ or HSLINK will return a successful transfer on one side but not on
the other. (You won't know until the following connect, and you have to be the
receiving node to find out). Solution: Make sure both nodes are running the
same dated version of the transfer protocol. If you are, and the problem
persists, then you should both get a different version of it.

If the problem is not between you and the connect, you will have to figure out
the routing between the node generating the duplicate messages and the node(s)
receiving the duplicate messages (because not all subscribers might be getting
them). Then you have to have each of the nodes along that path check their
connects. It's best for the host to work towards the subscriber(s) while the
subscribers work towards the host. If you have trouble figuring out the
routing, bug someone (knowledgeable area sysop or AC ideally, less ideally GC
or Wayne)

Type II: Find out what node is generating duplicates. That node should check
for a properly named N[N]*.NET file and ensure that there are no duplicated
node numbers in it.

Type III: Tell your users how to use LNET and have subscribers do the same.

Hope this helps. Suggestions for additions and/or questions are welcome.

───────────────┬─────────────────────────────────────────────┬───────────────
               │                 TechnOTES                   │
               │        Compiled by the WWIVnews Staff       │
               └─────────────────────────────────────────────┘

...The big news the past month is Cyrix' announcement of the first of a series
of 486 hybrid clone chips. This first chip, the 25mhz Cx486SLC, is a hybrid
containing many of the features of both Intel's 486SX and 386SX processors. The
Cyrix chip uses the 486 instruction set and lacks an internal math coprocessor,
like the 486SX, but operates at 32 bits internally with a 16 bit external bus
in the same manner as a 386SX. The chip is designed to be a "pop and drop"
replacement for existing 386SX machines, especially those that lack Intel's
"clock doubler" sockets. Cyrix also plans to release versions for 386DX
machines, as well as a 33mhz version of the Cx486SLC, by the end of this year.

...It should be noted, however, that the new Cyrix chips are not without their
drawbacks. Hardware-wise, the Cx486SLC only has a 1K internal cache (as opposed
to Intel's 8K cache on the 486DX), and the 486 instruction set is based on
microcode that is reverse-engineered to be compatible with Intel's 486 code,
and is proprietary to Cyrix and raises compatibility questions. Legal-wise,
Intel is attempting to secure court injunctions against Cyrix to prevent
release of the chip pending further legal decision on whether the new chips
infringe on Intel copyrights. Latest word on the rumor mill is that Texas
Instruments, with whom Cyrix has been negotiating for rights to use the new
Cyrix clones, may soon throw in their financial weight behind the Cyrix legal
defense fund in exchange for a sweeter chip deal with Cyrix.

...Last month's TechnOTES touched on the drop in prices for Floptical and
Flextra removable mass storage devices. This month there have been similar
price cuts for other forms of removable mass storage. Removable hard drives,
primarily those by Quantum, have dropped in price a bit below previous MSRP.
A 50 meg drive with docking adapter can now be found for under $600 on the
street, with drive sizes available up to 240 megs. Disk Technologies has a
comparable product line ranging from $799 for 20 megs to $1500 for a 120 meg
drive. Prices are expected to drop further on the smaller drives as the demand
for Windows on laptops forces manufacturers to focus their resources on
producing larger drives.

...Iomega, not to be left out in the cold, has a new Bernoulli Box out as well.
Connectable to any PC with an ISA bus, this drive supports both the 44 and 90
meg formats, and sports a 19ms access time, or so claims Iomega. Prices on the
street are around $900, but used Bernoulli's are beginning to show up on the
used peripheral market at about half MSRP, and it's not uncommon to find used
Boxes with three or four disk cartridges. At the same time, prices on 5.25"
Magneto-Optical drives are expected to drop somewhat in light of the arrival of
the new 3.5" format. The 5.25" M-O format can hold upwards of 600 megs a
cartridge, while the 3.5" M-O disks store only a fifth of that at 120 megs.
Drive prices are a bit high still (upwards of $2000 a drive, and $75 a disk),
but again are expected to drop in the coming year to about half that.

...For systems that have exceeded all possible bus combinations for hard drive
installation, Prima Storage Solutions offers a line of external HD's that
connect through the parallel port. With prices ranging from $999 for a 85 meg
drive to under $3400 for a 545 megger, this places the externals at prices per
meg comparable to Bernoullis or Removable HD's, but cheaper than either the
Flextras or the Flopticals. Micro Solutions offers a smaller but similar (not
to mention cheaper line of parallel port externals, with the high-end price
being $795 for a 100 meg drive.

...Regardless of the format, any form of removable mass storage would work well
for systems that have large file sections (such as .GIF's) that are incapable
of adding additional drives, and whose file sections would be better suited by
frequent rotation.

───────────────┬─────────────────────────────────────────────┬───────────────
               │          Filo's Mod of the Month            │
               │              by Filo (1@5252)               │
               └─────────────────────────────────────────────┘

The 'Mod of the Month' will be my pick of the mods appearing on WWIV
Modifications Net Sub (SubType 2370; host 5252) during the month or time
period since the last issue of WWIVnews. It will not necessarily represent
the best mod or the 'neatest' code, but it will be my pick of the mods. I do
not guarantee it to be bug-free and do not make any representation regarding
whether or not I tried it out. Because of the format of the news, mods that
contain EXE, COM, UUcode, etc., will not be considered for selection.

This month's pick was written by Lance Halle and is a fix for the failure of
some high-speed modems to detect that user has ansi installed.  As such,
it is a highly useful mod.

─────────────────────────────────────────────────────────────────────────────

Here is a FIX for the intermittent failure of WWIV 4.21 to properly detect if
a caller is ANSI compatible.

     Edit MODEM.C as follows:

          Search for the following fragment at the end of void answer_phone
────────────
    incom=outcom=1;
    if (!(modem_flag & flag_ec))
      wait1(45);
    else
      wait1(2);
────────────
          Change wait1(45) to wait1(72)
          Change wait1(2)  to wait1(36)

This will increase the delay after carrier detect before the BBS sends the
string to detect if a caller is ANSI compatible. The delay will increased from
2.5 seconds to 4 seconds for callers with error correcting modems. It will be
increased from 1/9 second to 2 seconds for callers with non error correcting
modems.

Error correcting modems seem to take longer than non-error correcting modems
before sending their connect string to the terminal program. Also many terminal
programs are just plain slow processing those connect strings. If the BBS sends
out the ANSI inquiry string before the caller's terminal program is ready, that
string may be missed entirely. Since there was no response to the inquiry,
WWIV assumes the caller cannot handle ANSI.

This mod increases the delay to allow the caller's terminal program more time
to finish handshaking chores. It has been tested with numerous callers, and the
BBS has not failed to correctly detect ANSI since the mod was installed. I
checked with Wayne, and it has his blessing as far as safety goes.

───────────────┬─────────────────────────────────────────────┬───────────────
               │             Dateline: @#$*()#!              │
               │     Editor's Notes by Omega Man (1@5282)    │
               └─────────────────────────────────────────────┘

I had originally planed a commentary regarding the registration deadline
for this month's column, but Jeff Garzik (AKA East Bay Ray) unexpectedly
sent the following commentary in e-mail. It can best be described as what
we journalists call a "-30-" column, which signifies that the article is
the last the writer has officially written for the publication. That article
usually takes the form of a "farewell address", and details what the writer
feels are his accomplishments and touches on why he/she/it is departing in
the first place.

This, without question, is what Jeff has done. So, without further adieu,
here's Jeff's "-30-" column.

─────────────────────────────────────────────────────────────────────────────

First of all, I would like to say congratulations on a job well done. I just
got the first issue of WWIVnews under the new "management" and I can say
sincerely that it is a great deal better than mine. It helps me see where I
went wrong in putting together my issues - organization. One person really can
make a difference.

To let you know a little about WWIVnews, you have to know a little bit about
Fido. When I first joined FidoNet a year or so ago, I received this "neat-o"
archive every week or so, which contained the current issue of FidoNews, the
FidoNet newsletter. After the space of about a month, I realized that WWIV,
growing as it was, definitely needed such a newsletter as well. So, after
pestering $F4 (1@1) a lot, I got my wish. That surprised me - a (then)
16 year-old junior in high school with no journalistic/publishing experience
whatsoever. I did the best I could, and I think (not my own back patting, I
received a lot of 'thank you' letters during my WWIVnews's lifespan) I did a
pretty good job.

I also know when I see a better job. Right from the start, when I first saw
Omega Man's posts, I noticed a certain degree of professionalism in them. That
is the "little touch that means so much" in a publication such as this. A
column by Wayne, a mod-of-the-month by Filo. Great ideas.

Finally, a couple people wanted to know why I stopped doing WWIVnews. Two
reasons. One, I wasn't very aggressive in my submission-hunting; and two, my
senior high school graduation was fast approaching, and I had other plans
besides a BBS during the summer and beyond (Ga. Tech - CompSci major). It
wasn't the network, which is filled with tons of great people, or the network
administrators, who work their asses off for little thanks, or even the network
software, with its much-cursed 32,767 byte packet limit.

Thanks WWIVnet for a great time!

┌───────────────────────────────────────────────────────────────────────────┐
│                             Closing Credits                               │
├───────────────────────────────────────────────────────────────────────────┤
│ WWIVnews is an independent newsletter published monthly as a service to   │
│ the WWIV community of sysops and users. The opinions and reviews expressed│
│ herein are the expressed views of the respective writers, and do not      │
│ necessarily reflect those of the WWIVnews staff. Reproduction in whole or │
│ in part is allowed provided proper credit is given. All rights reserved.  │
├───────────────────────────────────────────────────────────────────────────┤
│ The distribution sites for WWIVnews are the Klingon Empire BBS (512-459-  │
│ 1088), WWIVnet node @5282, and the WWIVnews Editorial Desk networked      │
│ subboard, subtype 15282 host 5282. Information regarding article and      │
│ editorial submissions, back issue requests, and the WWIVnews Writer's     │
│ Guide, can be requested in e-mail from the WWIVnews editor, 1@5282.       │
├───────────────────────────────────────────────────────────────────────────┤
│            WWIV and WWIVnet, copyright 1986,1990 by Wayne Bell            │
└───────────────────────────────────────────────────────────────────────────┘