º  Volume 3   ³³³³³³³³³³³³  ³³  ÀÅ¿ÚÅÙ³  ÀÙ³³ÀÄÄÄ¿³³³³³³³ÀÄÄÄ¿  July 25    º
  º   Issue 3   ³³³³³³³³³³³³  ³³   ³³³³ ³Ú¿  ³³ÚÄÄÄÙ³³³³³³ÀÄÄÄ¿³   1992      º
                           ³This Month's Features³
³ Random Factors.......................................Wayne Bell (1@1)       ³
³                                                                             ³
³ Compucom Bites The Dust..............................Omega Man (1@5282)     ³
³                                                                             ³
³ TechnOTES............................................WWIVnews Staff         ³
³                                                                             ³
³ Optimizing HS/Link for WWIV 4.21.....................Lance Halle (1@6211)   ³
³                                                                             ³
³ Filo's Mod of the Month..............................Filo (1@5252)          ³
³                                                                             ³
³ Dateline: @#$*()#!...................................Omega Man (1@5282)     ³

               ³               Random Factors                ³
               ³   Creative Commentary by Wayne Bell (1@1)   ³

First, I'd like to make some comments on distributing mods to WWIV. I
(obviously) have no objection to distribution of mods, but people need to be
careful of distributing too much original source code along with the mods. To
quote from the WWIV source docs, "If your modifications would require you to
distribute over 100 lines of the initial BBS code, you should contact me
before you distribute it, sending me a copy, and asking if it's OK. Most
likely it will be."  Do not just distribute the modified routines, or (even
worse) the whole modified files. There are freeware versions of the program
'diff' floating around, that will show you exactly which lines were modified.
In creating 'upgrade' files for new versions of the BBS, I use the diff program
to help create the upgrades. It really isn't that difficult, and actually might
help you to catch some change you might have forgotten to document.

Secondly, on subboard add/drop requests. Please do >NOT< post a message on a
sub, saying "please drop my system from this sub."  Whenever I see a message
like that, I simply delete it and ignore it. Sub add/drop requests should come
through E-Mail only, from user #1 on the system to be added/dropped. Or, if
possible, use automated add/drop requests. Posts about adding/dropping are
likely to be missed by a sysop skimming posts (or not read at all, if the sub
is moderated by a co-sysop), and E-Mail from non-#1 accounts is meaningless,
as it could be anyone on the system sending the E-Mail.

Thirdly, WWIV v4.21a will probably be out in early August.

Lastly, net31 will probably be out at the end of July. net31 will return E-Mail
to unknown users, fixes up a few minor bugs here and there, has some additional
interfaces for other programs to interface to the net software, and will
support automated gathering of subs.lst info. I'll go into more detail in the
automated subs.lst feature after net31 has been out for a while, as it won't be
very worthwhile until many people are running net31. All you will have to do is
create a text file listing the sub types you want automatically reported, and
the net software will do the rest.

               ³          Compucom Bites The Dust            ³
               ³ Investigative Report by Omega Man (1@5282)  ³
               ³  With Contributions by The WWIVnews Staff   ³

Two months ago, TechnOTES reported rumors that Compucom, manufacturers of some 
of the lowest-priced high-speed modems, had ceased operations. While rumors had
persisted on the netted subs for months of financial problems and production 
setbacks, some of which were reportedly related to the recent death of a major 
Compucom executive, few took them seriously as the same rumors were also being 
passed around regarding both Hayes and US Robotics.


As the May issue of WWIVnews went to press, the rumors apparently became fact, 
as calls to the Compucom purchase and support lines either went perpetually 
busy or perpetually dead. Those few who could get through the lines to ask 
about the rumor were greeted with a recorded announcement informing of the
company's demise, and who they could contact for more information.

As expected, this information spread like wildfire throughout the computer
networks. However, some doubt was cast on its validity as _PC Sources_ reported
that Compucom was releasing two new versions of the Speedmodem during the
summer. A spokesperson for the advertising department of _PC Sources_ explained
that the report had been confirmed and sent to press two months prior - a
standard procedure in the journalism industry - and that at that time Compucom
was still in business. Naturally, this further confused the issue for all 
interested parties, especially when none of the other major computer 
publications were mentioning anything regarding Compucom's status. 


Only last month, _Boardwatch_ magazine became the first publication to confirm 
Compucom's collapse, which has been verified by subsequent follow-ups by 
members of the WWIVnews staff. One such follow-up resulted in the following 
statement from a former Compucom employee, which has since been reposted on 
several netted subs in the past few weeks:


                           Compucom Statement

Compucom has closed its doors (due to unforeseeable financial circumstances). 
We here at technical support would like to continue to support the product as 
long as we can ON OUR OWN VOLITION. At this time, we can NOT provide you with
refunds, RMA's, or Exchanges, though we can help with various support issues.
We can upgrade you to the latest EPROM, providing you either pre-pay for the 
roms, or have previously returned ROMS. A number of us speedmodem supporters 
are currently planning to establish our own Company, which will give us the 
ability to support the entire line of speedmodems. We will continue to make
important announcements and information available on the San Diego Support 
BBS (The General) at (619) 281-2622 and in the various speedmodem conferences.

Q. & A.

Q. I want my money back
A. The company is gone, we at tech support on our own volition, are trying to 
inform/help. You may have financial recourse depending on how you paid.

Q. What about firmware?
A. We are in touch with the chief design engineer, and hope to work with him 
in continued development.

Q. What about RMA's?
A. We will try and send it back to you.

Q. Warranty?
A. The Company is out of business.


Shortly after this statement began circulating, Shawn Stamps (2@4401) posted
the following additional information regarding Compucom's European division:


[..] the American arm of Compucom is dead. However, the company still thrives
in Europe (Compucom Europe, Ltd, in Glasgow) and they have been trying to keep
working on the upgrades, though with Lightning Communications licensing CSP
(the Compucom proprietary protocol - nasty thing that it is), the european
counterpart is terminating even the low level of support it has graciously
provided. I have been keeping in touch with them in the hopes that MAYBE I
could get ahold of the development hard/software for the damn thing, not to
make new modems, but to locate new parts and to try to fix the dern things.


Finally, a former Compucom employee in the tech support division, who asked to 
remain nameless, made the following commentary to a WWIVnews in e-mail on


The company had been experiencing financial problems for months. That much
we all knew. What we didn't know was just how bad those problems really
were. Most of us kept the information to ourselves, though; not because we
feared losing our jobs, but because we felt really strongly about our work.
For most of us, it was a labor of love, and we really busted our asses to
make sure each Speedmodems performed as flawlessly as possible. We really
feel what we produced weren't just high-tech tools, but works of art with
a little bit of our souls along for the ride!

Don't give up on the Speedmodems just yet, tho. We're still trying to supply 
some amount of tech support on our own, and we're trying to arrange some sort
of financing so we can resurrect the company under our ownership. If you're
really interested in keeping up with what's going on with what's left of
CompuCom, regardless of what we wind up calling ourselves, you can keep in
touch by calling this BBS in San Diego: THE GENERAL BBS, at (619)281-2622.



For every answer regarding Compucom's demise, there are quite a few questions 
still unanswered. While those who've purchased eprom upgrades may still be
able to get them from the continued tech supporters, it's not known what 
recourse is available for those who've not yet received modems purchased 
from Compucom prior to closing. At press time, Compucom had reportedly not 
filed for any form of protection under bankruptcy, and as stated above there
may not be any satisfaction to be gained from the tech support staff with
this respect. 

On the bigger picture, there's this nagging question: from a business 
standpoint, what factors actually contributed to the company's financial 
breakdown? Were they related to mismanagement, or was Compucom just another 
victim of the proprietary protocol curse? If the former, which might not
be likely if the positive customer satisfaction reports prior to closing 
were true, then chalk it up as another example of the decline of American 

If the latter, which is far more likely, then perhaps it might be wise to keep 
an eye on Telebit, USR, and any other modem manufacturer that deals in 
non-Hayes proprietary protocols. While we all would love to see the price
hold Hayes has on high-speed transfer protocols that work, the fact that 
Hayes essentially holds the patent on the "better" (read: first at bat and/or
biggest kid on the block) mousetrap may be too strong to ignore. 

Until someone comes up with a communications protocol that offers severe 
benefits over those offered by Hayes, buyers should consider only buying those 
high-speed modems that support Hayes protocols in addition to their own 
proprietary ones. As it stands right now the risk of getting burned may be
a bit too high for most of us to take the chance on something that's not 100%
compatible with Hayes at all speeds.

Which, of course, just might probably be where Hayes wants us all along.

               ³                 TechnOTES                   ³
               ³        Compiled by the WWIVnews Staff       ³

...brief shareware nOTE: one of shareware's few real success stories, Vern 
Buerg, has become the latest to be infected by the Greed Virus. The next 
release of his List utility, 1.84, will be the first commercial release of the 
product. The new Enhanced List will feature both ASCII and EBCDIC support, 7 
and 8-bit file formats, a hex reader, and built-in utils for managing files 
compressed with several of the major archivers. 

...While these new features may be handy, especially for WWIV sysops who use 
List to view their logs, the price tag is still a bit too pricey for something
that used to be a hell of a lot cheaper. While one can't fault Buerg for 
trying to make his efforts more worth his financial while, one can't help but 
recall how Qmodem registrations dropped dramatically after John Friel sold it 
to Mustang Software for commercial release. A trimmed-down version for the 
shareware market that helped make Buerg a success would be very prudent, 
especially when very few sysops need EBCDIC support anyway!

...brief shareware nOTE #2: one of shareware's other few real success stories, 
Phil Katz' PKZIP, still hasn't seen an official release of the long-awaited
version 2.0. Although there was a beta release of the new version, numbered
v1.93, according to Katz himself this version was extremely buggy and has
also been altered so that it appears to be an official release of a 2.xx
version. PKZIP users are urged not to use any version of PKZIP identifying
itself as a 2.xx release until further notice. The WWIVnews staff is looking
further into this matter, and next month's WWIVnews will feature a more 
in-depth look into the current status of PKZIP 2.xx.

               ³      Optimizing HS/Link for WWIV 4.21       ³
               ³           by Lance Halle (1@6211)           ³
After talking at length with Sam Smith, the author of HS/Link, I think I have 
the proper setups to make HS/Link work reliably with PC Pursuit. I also found 
out a couple of other things that really speed HS/Link up for regular 
The first part of this document defines some terms that are used in the rest 
of this discussion. The second part discusses ways of setting up HS/Link to 
optimize normal WWIV BBS connections. The third part describes the problems 
involved using HS/Link on WWIV with PC Pursuit, and how they can be taken care
of, and part 4 deals with optimizing HS/Link for use with your terminal 
HS/Link sends data in packets (blocks). Normally each block contains a unique 
sequence number and checksum info to aid in data verification and error 
detection and recovery.
Size of each block in bytes.
An ASCII file that is used to set HS/Link's options. This file can be created 
with HSCONFIG, or with your editor. The default configuration file is 
HSLINK.CFG. This is the file that HS/Link looks for if no other is specified on
the command line. To specify another configuration file start your command line
as follows: "HSLINK -@filename". Don't type the quotes. The filename is the 
name of the alternate configuration file you want HS/Link to use. This MUST be
the FIRST option on the command line.
Be sure to use the LATEST release of HS/Link. While the current version is
always compatible with older versions, you will not get the benefit of the
latest enhancements and fixes if you are using an old version. At the time of 
this writing, the latest RELEASE version is 1.12.
This option causes the remote (called) end to use some of the options specified
by the calling end. This does NOT affect any of the options having to do with 
security, such as the upload path, or the overwrite option. It does affect 
block size (-s), xon/xoff (-hx), and windows (-w).

A means of flow control where the modem asserts the CTS (clear to send) line 
when it is able to receive data from the computer. If it's buffer fills up, it 
drops the CTS line. In the same way, the computer asserts the RTS (request to 
send) line when it is able to receive data from the modem, and drops it if it 
is busy. This scheme is used by High Speed modems that can operate with a port
speed that is higher than the connect speed.

Sends Xoff or lowers RTS during disk I/O. This causes the computer to signal 
the modem not to send any data during disk I/O. It is available for systems 
with slow disk access. It may help if you get frequent CRC errors of COM 
overruns on clean lines.
The number of blocks HS/Link will send before stopping and waiting for an
acknowledgment (ACK)
XON/XOFF (default)
A software method of telling the other end to suspend/restart sending data. It 
is not generally necessary for error correcting modems, but no harm is done by
leaving it enabled. (Do not disable this if Slow Handshaking (-hs) is required
by your system)

If you operate a WWIV BBS that does NOT make NET callouts via PCP, then the
following HSLINK.CFG file settings and INIT settings should be optimum for you.
HSLINK.CFG - use HSCONFIG or a word processor to create
 -A  /* don't send ACKs */<< don't type the >>
 -S4096/* sets 4k blocks */ << comments >>
 -W0 /* do not wait for ACK /*
INIT settings for HS/Link
 Description  : HS/Link
 Xfer OK code : 0
 Require MNP/LAPM   : N
 Receive command line:
 HSLINK -P%2 -E%4 -U%3
 Send command line:
 HSLINK -P%2 -E%4 %3
 Receive batch command line:
 HSLINK -P%2 -E%4 -U%3
 Send batch command line:
 HSLINK -P%2 -E%4 @%3
 Bi-directional transfer command line:
 HSLINK -P%2 -E%4 -@ @%3
OK, now for the problem with PCP. Being a timeshare net, it does not transmit 
data continuously, especially during busy times. There may be delays in data 
transmission. If the HS/Link default block size of 1024, or 4096 is used, and 
the default window of 8 is in effect, HS/link will send 8 of these blocks 
before stopping for an acknowledgment. If PCP is busy, this may be more data 
than it can "swallow" in one gulp. Once PCP gets behind, it may have problems
recovering, in which case the data may or may not get through. Even if it  
does, the ACK may not get back to the sending end, in which case HS/Link waits
for it's internal timeout, before trying again. Often PCP cannot recover at 
all, and HS/Link will finally about the transfer.
This problem can be resolved by using smaller blocks, and smaller windows. A 
setting of 512 or smaller for the block size is recommended, and a window of 4
should work fine. This will give PCP smaller blocks of data, and HS/Link will 
stop more often to check that the data has been received.
This sounds easy to implement, but there is one problem with WWIV that we have
to overcome. We are able to set the command line that HS/Link uses for regular
BBS callers by using the INIT program, BUT we have no way of controlling the 
command line that the NETWORK uses for it's callouts. This means we are stuck
using the same configuration for both our NET calls and our regular callers. 
There is a workaround that will do the job for those systems that make NET
callouts via PCP, but still want their regular callers to get the best speed 
out of HS/Link. We can set the options we want to use for NET callouts in the 
HSLINK.CFG file, since that is the one HS/Link looks for by default. Then we 
can create another configuration file to use when a regular caller activates 
HS/Link. We can specify that alternate configuration file on the HS/Link 
command lines in INIT. If you called your alternate config file BBS_CALL.CFG,
and it was in your C:\WWIV directory, then your HS/Link setup in INIT should 
look like this:
 Description  : HS/Link
 Xfer OK code : 0
 Require MNP/LAPM   : N
 Receive command line:
 Send command line:
 Receive batch command line:
 Send batch command line:
 Bi-directional transfer command line:
 HSLINK -@C:\WWIV\BBS_CALL.CFG -P%2 -E%4 -@ @%3
Your default HS/Link config file that will be used for the NET callouts should
look like the following. It should be named HSLINK.CFG, and should be in the 
same directory as HS/Link. This is the optimum setup for use with PCP:
 -!  /* force remote to use these settings */
 -S512 /* use 512 byte blocks */
 -W4 /* wait for ACK after every 4 blocks */
Your alternate config file for use with regular callers should look like this,
and the name should match what you specified in INIT on the HS/Link command 
line (ie. BBS_CALL.CFG), and should also be in the same directory as HS/Link.
 -A  /* don't send ACKs */
 -S4096/* sets 4k blocks */
 -W0 /* do not wait for ACK /*
These should provide optimum setup for those WWIV BBS systems that callout via
PCP and want the best for their non PCP callers. Regular PCP callers should 
configure their terminal programs to use a setup like the HSLINK.CFG mentioned
in part 4.
The calling party has the responsibility of determining the best HS/Link
configuration options for his/her particular situation (PCP, Non PCP, etc).
You should configure HS/Link for your terminal program, and include at least 
the following options in the .CFG file. Be sure to include the (-!) to force 
the remote to also use your preferences.
If you are calling via PCP, then your HS/Link config file should look like the
following one. You should also use PCP's default handshaking:
 -!  /* force remote to use these settings */
 -S512 /* use 512 byte blocks */
 -W4 /* wait for ACK after every 4 blocks */
If you use "direct" connections ( regular lines), then your HS/Link config file
should look like this:
 -!  /* force remote to use these settings */
 -A  /* don't send ACKs */
 -S4096/* sets 4k blocks */
 -W0 /* do not wait for ACK /*
In the event that you do both PCP and Non PCP calls, you can give one of these
files a different name (ie NON_PCP.CFG), and then on the HS/Link command line 
for your Non PCP calls, include the following as the FIRST option:
Be sure to include the path name, ie @C:\TELEX\NON_PCP.CFG

I hope this takes some of the mystery out of HS/Link operation. Sam Smith
(HS/Link author) has looked this over, and it has his blessings. If you have 
any problems, or discover something I have overlooked, or described
incorrectly, PLEASE notify me as soon as possible. I will attempt to update
this document as new information becomes available.

               ³          Filo's Mod of the Month            ³
               ³              by Filo (1@5252)               ³

The Mod-of-The-Month Selection represents my choice of what appears to be a 
useful, practical mod to WWIV. It does not mean it is the best mod posted or 
even that it works as I may not have tested it. Given the limitations of this 
media, uuencoded mods are NOT eligible for selection as mod-of-the-month.

This month's selection is a combination of two mods posted earlier. Each mod 
provided a means of permitting users that experience logon trouble to send 
feedback to the Sysop.  Since this problem occurs frequently, it seems to be a 
useful mod. Braves's (1@8131) combination of the two other mods seems to be a 
colorful approach.


This mod was made for WWIV 4.21. I always wanted a mod that would allow users
to be able to do something if they forgot their password or just hit the wrong
macro or Whatever. I saw this mod and another one on the Mod net and tried 

I liked them but wanted what each of them had into one so I combined them and
added some stuff. I hope you like it. Well on with the Mod!

Difficulty - .0001 out of 10

Backup your source! (Unless you feel real Lucky!)

/* == */ existing code!
/* ++ */ add!
/* += */ change!

Ok Load up LILO.C

  } while ((!hangup) && (!ok) && (++count<3));                        /* == */
  if (count==3) {                                                     /* += */
    pl("6User not found...");                                        /* ++ */
    outchr(12);                                                       /* ++ */
    pl("                   3ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»");          /* ++ */
    pl("1Would you like to: 3º  2R)7etry logon            3º");  /* ++ */
    pl("                   3º  2L)7ogon as a newuser     3º");    /* ++ */
    pl("                   3º  2G)7oodbye (hang up)      3º");    /* ++ */
    pl("                   3º  2E)7mail Braves (hang up) 3º");    /* ++ */
    pl("                   3ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ");          /* ++ */
    outstr("       1Your choice:  ");                                /* ++ */
    ch=onek("LRGE");                                                  /* ++ */
      switch(ch) {                                                    /* ++ */
         case 'R':                                                    /* ++ */
           nl();                                                      /* ++ */
           getuser();                                                 /* ++ */
           break;                                                     /* ++ */
         case 'L':                                                    /* ++ */
           nl();                                                      /* ++ */
           newuser();                                                 /* ++ */
           ok=1;                                                      /* ++ */
           break;                                                     /* ++ */
         case 'G':                                                    /* ++ */
           hangup=1;                                                  /* ++ */
           ok=0;                                                      /* ++ */
           break;                                                     /* ++ */
         case 'E':                                                    /* ++ */
           email(1,0,0,0);                                            /* ++ */
           hangup=1;                                                  /* ++ */
           break;                                                     /* ++ */
      }                                                               /* ++ */
  }                                                                   /* ++ */
  checkit=0;                                                          /* == */
  okmacro=1;                                                          /* == */

That's It! Save it and Compile!

               ³             Dateline: @#$*()#!              ³
               ³     Editor's Notes by Omega Man (1@5282)    ³

32767 bytes per file. It's not just a good idea, it's the law.

Wellll...maybe not quite *that* good an idea...

This month, that "law", along with the last-minute addition of an in-depth look
at the demise of Compucom, took it's toll on the space I had allocated for my 
editorial. Since I've rescheduled that editorial for next month's issue, I'll
take what little space I've got to enlighten everyone on yet another major 
change to WWIVnews that's about to take place in the next couple of months.

Laws that are detrimental to that which they are designed to protect can be
changed if those affected pursue the proper channels of authority. Or, at 
least that's what they told us in our civics classes, right? Well, in the case 
of WWIVnet and WWIVnews, this meant 1@1 himself, Wayne Bell. 

After consulting with - ok, ok, *begging* - Wayne at length on the matter, 
with the release of Net31 the file size limit will essentially be removed for 
WWIVnews. What Wayne has devised is a way for WWIVnews to be transmitted over 
the network in 32k segments, and reassembled by Net31 into one complete file.

What this means is that WWIVnews will see yet more expansion following the
release of Net31. Some of the original plans for the revamping included some
regular features that were dropped ue to the file size limit. These features
included such standard publication staples as a Q&A column, a regular Group 
events update section, a networked sub review column, and a regular update 
piece for onliners and utils. 

So, once Net31 has had time to be distributed and installed - at least one 
month, maybe two - expect to see these features to finally see the light of 
day. Of course, if you're interested in writing one of these features, feel 
free to drop me a line at 1@5282. Lord knows we're going to have space to
fill for a change :-)

Speaking of that file limit, It seems I've got just enough space left for the 
closing credits. Stay tuned, people - the WWIVnews Adventure is about to really
get a really swift kick in the butt!

³                             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            ³