Ú¿Ú¿Ú¿Ú¿Ú¿Ú¿ÚÄÄÄÄ¿Ú¿ Ú¿ÚÄ¿ Ú¿ÚÄÄÄÄ¿Ú¿Ú¿Ú¿ÚÄÄÄÄ¿
ÉÍÍÍÍÍÍÍÍÍÍÍÍͳ³³³³³³³³³³³ÀÄ¿ÚÄÙ³³ ³³³ À¿³³³ÚÄÄÄÙ³³³³³³³ÚÄÄÄÙÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º 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.
IN SEARCH OF A CORPSE
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
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.
SEANCING THE GHOSTS
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
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
Usenet:
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
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.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
DR. QUINCY SAYS: DEATH BY HAYES?
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
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
business.
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
transfers.
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
program.
DEFINITIONS
ÄÄÄÄÄÄÄÄÄÄÄ
BLOCK
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.
BLOCK SIZE (-s)
Size of each block in bytes.
CONFIGURATION FILE
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.
CURRENT HS/LINK VERSION
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.
FORCE REMOTE TO USE LOCAL OPTIONS (-!)
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).
HARDWARE HANDSHAKING - CTS/RTS (default)
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.
SLOW HANDSHAKE (-hs)
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.
WINDOW (-w)
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)
OPTIMIZING HS/LINK FOR WWIV BBS'S THAT DO NOT MAKE NET CALLS VIA PCP
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
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
OPTIMIZING HS/LINK FOR WWIV BBS'S THAT MAKE NET CALLS VIA PC PURSUIT
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
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:
HSLINK -@C:\WWIV\BBS_CALL.CFG -P%2 -E%4 -U%3
Send command line:
HSLINK -@C:\WWIV\BBS_CALL.CFG -P%2 -E%4 %3
Receive batch command line:
HSLINK -@C:\WWIV\BBS_CALL.CFG -P%2 -E%4 -U%3
Send batch command line:
HSLINK -@C:\WWIV\BBS_CALL.CFG -P%2 -E%4 @%3
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.
HS/LINK AND YOUR TERMINAL PROGRAM
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
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:
-@NON_PCP.CFG
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
them.
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 ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ