
Oct 1992

--301--
The file transfer window that pops-up during ULs and DLs doesn't do so
when running Cnet in a window on the workbench.  Is this a custom-
screen only feature?  (A lot of good info in that window that WB users
would probably like too.)

--302--

BBSmenu...
>10; Editor-empty or with text
>   *, !
I wanted "!" to also be used to execute a cmd from within the editor.
UNIX systems usually use "!".  Doesn't work with Cnet.
I'm assuming it is a bad choice and can't be used here?

--303--
ARexx...
> 'version'
> 'sendString' RESULT
is still showing "C-Net AMIGA 2.2" with "CNet AMIGA 2.30".

(c:Version is reporting the correct version # though.  Could you just
define 1 string within Cnet containing the version #.  You'd only have
to change that, and everything that uses/displays the version # would
always be correct in every update.)

--304--
Yes, a vote topic.  Remember that all the code for AM and AG is
still within Cnet, it just isn't displayed on the idle screen anymore.

Does anyone know why AM is a sysop maintenance feature only?  All a
caller could do is look at the data, nothing real damaging.  I'd love
to call any cnet and see all the stats at a glance.

Ken, please consider making this a global-cmd.  Does anyone know
if I can move AM there myself?  How?

--305--
> How about having C-Net allow there to be new messages when a new user calls...
> because usually it just says nothing is new, they think there's nothing on
> there, so they just log off..

There has been 1 response.

Maybe a BBSconfig option.
5     <-- First visit to UD/Bases sets new-scan dates to 5 days ago

--306--
Duplicating efforts...
1) Small, simple to set-up, minimial featured, included with the
   BBS front-door and tosser.  Ken's clever features, and extremely
   bug-free.  Supported as long as Cnet is in exsistance.
2) Loaded with features, 100K executable, expensive add-on, big memory
   usage, big disk space usage, full point support, HUBS/NECs goodies,
   routing, file requ's, etc.  Supported for an undetermined length of
   time by unknown persons.  Pay fees and wait for it to arrive.

I just don't see this as really 'duplicating efforts'.  I pity the
poor 1st-time Fidonetter that has to go through #2 when all he really
needs is #1.  And yes, I do think that represents the vast majority of
BBS operators.  Setting up fidonet at all, can be a very trying
tasking for some.  (I went through dozens of Foozle's set-up screens
before I gave up.  I just don't need all that at this time.)

I think it would greatly increase Cnet's attractiveness to those
looking at purchasing, as well as encourage 100s of novice SysOps to
finally get their feet wet in The Big World of Networking.

--307--
Ken please consider implimenting an MCI-Comment code of "/;".
> /; My comments here /;

We could comment things in any/all text files for our own purposes.

Also, instead of removing text from BBSTEXT, we could just comment it
out.  (And still be able to mark what/where line #1832 is displayed at
while online.)

--309--
Ken, where can I find the very latest Cnet features list?  Is the
1 under your Gfiles current?  I need to show it to a few (or more than
a few) non-Cnet SysOps.  (Especially the latest FidoNet/Usenet/term/
JoinLink/chat features.)

I'd also like to include the file with the pfiles I write/distribute.

--308--
> *4
> Sorry, you don't have enough file credits.
> *9
> Sorry, you don't have enough byte credits.

I thought Cnet allowed users to mark more files than they could
D/L on this call.  (So they could still D/L them after they U/Led
or even on their next call.)

I can understand limiting the D/L of files.  But what is the
point of restricting even the marking of files?

After a user scans on his areas for new files and can't mark the ones
he needs, when he calls back with his prepared U/Ls, he has to re-
search and mark all his files.  (And all his last-scan dates have been
reset anyway.)

I don't see anything wrong with letting anyone mark as many files as
they want (upto my marking-limit set in BBSconfig).  They still can't
do any D/Ling until they fulfill their U/L requirements.  (I also
think it would be a great incentive to U/L if they saw all the files
they have waiting for them on each call.)

I'm back to writing phone #s, subboard names, subsubboard names,
subsubsubboard names, and full filenames down on dozens of little
scraps of paper again, so I can find the files I need on my next call.

--309--
> Enter NEW if you have no account.
> Enter your handle: NEW
> Enter NEW if you have no account.
> Enter your handle: NEW
> Enter NEW if you have no account.
> Enter your handle: NEW
> Enter NEW if you have no account.
> Enter your handle: NEW

"Enter NEW if you have no account."
is still displayed even if the "No New Accounts" pull-down menu is
turned on.  "NEW" should display a 2nd string in BBSTEXT that allows us
to inform the user that "no new accts are currently being accepted".

--310--
There's a switch on most compilers that can be thrown to create
68020/68030/68881/68882 versions.  Maybe Ken could try 1 and see
if it creates any real big speed improvements.  (But does he want
to release each update in several different versions now, too?)

I think a better thing to discuss would be:
"What area of Cnet's speed are you trying to increase by having a
specific 68030 version?"  Then see if Ken can tweek things in the code
to improve speed for all CPUs, not just some.

I am more than happy with the speed of nearly everything as it is.
Things like "ZG" just have to check through so much data that it's
most likely going to take a while, no matter how the code is written.

Of course things like:
CNET> ZG 'MyString' &
could be added.  The trailing "&" would work on any cmd and it would
mean, "Spawn a background task, send me an OLM when you are done, and
mail me the results, or pack it and add it to my current "SS" list for
D/Ling later."

We'd need a global option in BBSCONFIG for "max # of tasks spawned at
any 1 time".  And most likely a field added to each user's account to
limit the "max # of tasks this user can spawn" (including 0).

But if "ZG" is the ONLY thing we are trying to speed up,
then maybe just have it ask the user:
1)  Run in background so you can continue to use the BBS?
or
2)  Sit here and wait and stare at the screen until it's finished?
How many people are going to pick #2?

Think of what YANK would be like if it didn't run in the background.
Don't laugh, for Paragon/Starnet and many other BBSes, #2 is
exactly what YANK does.

--311--
> List#-#, Add#-#, Step#-#, Resp#, Quit: A2,4-10,26-30,35-39
> Inserted 1 lines.
Ugh, quoting doesn't accept full, Cnet standard, "-" and "," ranging?

--312--
Everyone, let Ken know if you feel "cmd aliasing" is important to you.
If a user mails you and says he just can't get used to "*" for
marking files, you can tell him he can change it to "MARK" "TAG"
"SELECT" "PICK" "CHOOSE" "GATHER" "HIGHLIGHT" "CULL" or anything
else he wants.

Just let him edit his own Mail:User/47/aliases.txt file:
MARK = *
...
...
...

Or a SysOp could offer 3 different WHO cmds (WHO1 WHO2 WHO3).  
The user could alias WHO to whichever 1 he liked best.

(Or you could type "Echo >Mail:User/47/aliases.txt MARK = *" from
any CLI and add it for him.)

(Or type "JOIN Mail:User/*/aliases.txt as t:ALL" and show everyone
1000s of alias possibilities currently in use by other users.)

--313--
Your serial # is already available to anyone via pfiles or even
simple arexx scripts.  I sure hope Cnet's security/integrity isn't
based around keeping that 1-3 digit # a secret.

Here's 600 serial #s:  1-600.

--314--
> You can add me to the list of newwies! But I wish I could get
> through on the 14.4v.32bis line here save me some moneyu!

If Ken would release full info about how/where AG saves its data,
I'm sure we'd soon see things like:
> AG 3
> AG 1-3,7
Which would display an active graph just for those nodes.

Callers you could see just when the 14.4k line has its highest/lowest usage.

SysOp's could see if they need to add a new 14.4k or 9600 or 2400 modems
as the system expands.

--315--
When amaint does a purge of my msg areas, is there a way to have it
yank/compress what it is about to delete?  I'd love to make my last
x weeks worth of posts available for D/L, even though they are
no longer avaiable for reading online.

I'd love to call here and see a "Past History" area:
1  1-Oct  0 FW005.LHA   65K "Suggestions for the future" 01Sep92-01Oct92
2  1-Sep  0 FW004.LHA   64K "Suggestions for the future" 01Aug92-01Sep92
3  1-Aug  0 FW003.LHA   32K "Suggestions for the future" 01Jul92-01Aug92
4  1-Jul  0 FW002.LHA   45K "Suggestions for the future" 01Jun92-01Jul92
5  1-Jun  0 FW001.LHA   56K "Suggestions for the future" 01May92-01Jun92

--316--
".GET" in the editor doesn't work like it says in the manual.  That is,
"destroy what's in the buffer unless the filename is started with a
"+" char".  Nor do I think it should.  I assume it was changed for
safety's sake.

".PUT to a file" has a DEFAULT setting of "destroy your current file".
For safety's sake the default should be "append to file".  If users
wish to override this, with its destructive setting, THEN they should
have to specify an additional char to do so.
Maybe...
".PUT -t:MyFileName".  (to overwrite)
".PUT  t:MyFileName".  (to append) (the default)

--317--
Cnet v2.35...
> Upload base> zg
>
> Keyword text #1: xxxyyyzzz
> Keyword text #2:
> Filter text  #1:
>
> Also pack messages to download [No]? No
> Launching Yank process.  Wait for OLM, or retrieve within 3 days.
>
> **** YANK REPORT
>  501 message(s) matched.  Use RM to read.
>  Press RETURN to continue...

I just did a ZG for the string "xxxyyyzzz" and it found 501 matches.
Highly unlikely.

Are KEYWORD and FILTER working differently then before?
(What is FILTER?)

--318--
Ken, my BBSTEXT file is 2003 lines @ 47931 bytes long.

The value I'm getting from MainPort's nBBSTEXTbytes element says it's
47941 bytes.  And nBBSTEXTlines is showing 2008 lines.

I wanted to use these 2 values to manipulate BBSTEXT.

--319--
My log-in macro is "1) Logon MACRO : UM 0;WHO;U;MUFF;*" which always worked
fine.  Just recently is started to generate:

CNET> Now muffling all ports.
CNET> Unknown command "NSAL"
CNET> List, Quit, subboard#, ?=Menu
CNET> Upload base>

What is "Unknown command "NSAL""?

--320--
It's now 822am.

Cnet> 4 The Dark Angel       12:30a 120 New Baltimore, MI      USA UDBase
Cnet>                                   2nd II None - 313-949-0119

"WHO" is still reporting this user as being online.
A hung port?  A bug in "WHO"?
Or has TDA really been online for 8 hrs (and counting)?

--321--
My #0 default signature is:

> Lines in memory: 4
> Maximum lines  : 5
> Command:List
> 1)
>
> 2)
> -----
> 3)
> Bill Allen Beogelein, SysOp 313-473-2020, 2-line HST 14.4k USR DS, 1:2410/207
> 4)
> Still not a Cnet beta tester.  The above opinions are my own.

But when I post, I get the 5th line (shown below).

1
2 -----
3 Bill Allen Beogelein, SysOp 313-473-2020, 2-line HST 14.4k USR DS, 1:2410/207
4 Still not a Cnet beta tester.  The above opinions are my own.
5 Usenet:  50,000 systems!  30,000,000 readers!

--322--
Would anyone be infavor of an external more-cmd?
If the DOS executable Cnet:More existed, all output to the user
would be filter thru it before being displayed to the user.
Any MORE cmd that allowed standard <in >out would work.
(And there are already a ton of More-like prgs out there.
Ranging from simple to far more powerful/complex than we need.
Take your pick of any of them..)

--323--
Does there exist a file that cross references line #s with verbose
descriptions of what/where each line in BBSTEXT is displayed?
Something like:
> 4 New-user's default areacode
> 5 New-user's default country
> 6 N Used for More (Y/N/C) checking
> 7 Y Used for More (Y/N/C) checking
> 8 C Used for More (Y/N/C) checking

If not, would 20 volunteers be interested in getting together and each
documenting 100 lines of BBSTEXT?  We'd later join all 20 files and
have it complete.

Telling what "Press RETURN to enter system:" does is pretty obvious.
But what about the 100s of lines in BBSTEXT like:

> /n1filename:
> /n1Include %s [Yes]? /?1
> Override [Yes]? /?1
> /h6ed./n1
> ,
> ,
> ,
> Group:
> st
> Now  :  %s/n2
> fbmsm1poregfpfneufukdfdkmumich
> /c3%5d %.6s /c7%-20s %-20s /c2/:2%s%s/:0/n1
> /c6%4d /c7%-20s %-20s /c2%s/q1/n1
> /n1/q0/c6(/c7/vy/c6)/c7 /vz> /q1
> %3.3s'%2.2s
> %3d%c%s%c
> /q1/n1
> %-24s (%s):
> /c6 %3d
> %d.%dM
> your

This proposed 'description list' could also be used as a help-file for
a BBSTEXT updater program.  Automatically displaying WHERE a string is
used if it's particularly cryptic.

--324--
> Also pack messages to download [No]? No
> Results should be:
> [M]arked, [S]ent via email, [P]acked for D/Ling, [W]ait for completion:

Then you'd have your choice of retreval:
[M]arked              (Just marked for retrevel on this call only.)
[S]ent via email      (Read it right online, this call or next, no need to D/L.)
[P]acked for D/Ling   (D/L packed, selected file within x days.)
[W]ait for completion (Cnet's old method.)

Nearly all of that is already a part of Cnet's code.  We just
don't have a choice of which of the 4 to use.

I'd like to see a new special char (like "!") called "&".
Then not only "Z", but any cmd that we ended with "&" would give us
that same 4 choice menu.

BBS> ZG &
BBS> SG 'string' &
BBS> NS;N;S; &
BBS> UL;N;N;1... &
("UL" can also take a while on 2000 user systems.)

--325--
JS> Its the STORES and DISTRIBUTORS!  If they have left over stock when we
JS> announce a newer version, they SEND THEM BACK to us.  This is not good!!

Oh, I see.  Thanks for responding.
Would they also do this if:
Instead of incrementing v2.30, v2.31, v2.32, v2.33, v2.34, v2.35, v2.36
before releasing v2.37, just go abcdef and then release v2.31.
(As a side benefit, we'd all know that a new release went non-beta just
by looking at the #.)

Are distributors saying, "I've got v2.30 on the shelf, and look, v2.37
was just released, send them back, that's 7 releases old, (which
for some software is 7 months/years old)."
When it really was just 1 release update.

--326--
>How do I get BBSKEYS to work?  What is the format?

Top of page #12 of the old spiral-bound manual.
(Ken, please consider including a sample BBSKEYS files in the master
disks.  Well, worth the 100 bytes of space.  (Or at least I'm sure
all the long distance callers posting questions like this, would
feel so.)

--327--

I wanted to add every conceivable protocol to Cnet.  Could someone

CLI> lz a t:MoreProto.lha Cnet:bbsProto libs:xpr*

and U/L it for me.  Thanks.

--328--
I'd just like to see several of the 'set a max limit 1st' vars     
just removed entirely.  The Amiga (and certainly Ken, too) is smart
enough to handle things like this.  I remember some very early     
word processors on the Amiga that actually made you increase a     
'text size limit' variable before you loaded large documents.      
Now such a thing is unheard of.  Let the machine check the size of 
the file and adjust itself accordingly.

Ken, would it be possible to do away with "max # of subboards" config
variable, altogether?  As a sysop creates new subs, memory is allocated
for each 1 added.  If x are created, memory for x is allocated, x
subboards are saved, when the system is brought up, all x are
re-loaded.

--329--
Take a look at my MASTER.LHA header files:
SHORT CallerIdName     :1;//Log-in caller w/o asking name via CallerID
SHORT CallerIdPassword :1;//Log-in caller w/o asking password via CallerID
SHORT CallerIDThisCall :1;//Phone # matched # in acct via CallerID on this call
SHORT CallerIDVerified :1;//Phone # matched # in acct via CallerID at 1 time
SHORT CallerIDDrop     :1;//Drop carrier if CallerID doesn't match acct #

Ken, even if you don't choose to do anything w/Caller-ID right now, at
least reserve a few flags for it so pfiles/etc can use them.

Here's the Supra specs:
> Implements Caller ID
>
>         This is a feature is only available in some areas of the country.
>         In between the 1st and the 2nd ring, the phone company will send
>         information on who is calling you.  If you ere in terminal mode and
>         had told the modem to answer on the 3rd ring, you would see:
>
>                 RING
>
>                 DATE = 0321
>                 TIME = 1405
>                 NMBR = 5039672400
>                 NAME = SUPRA CORPORATION
>
>                 RING
>
>                 CONNECT 19200
>
>         To enable CALLER ID:
>
>                 AT#CID=1        Enables Caller ID in formatted format
>                 AT#CID=2        Enables Caller ID in unformatted format
>                                 (ASCII printable hex numbers)
>                 AT#CID=0        Disables Caller ID

You can do some powerful stuff with it.  But keep in mind that
not everyone always calls from the # listed in his acct as 'voice #'.
We must have control over CallerID usage.

--330--
When adding a new pfile...
> Enter full DOS path to file    : c:Date
> Text, Arexx, DOS, or CNet file?: DOS
> Additional DOS arguments       : []                                    .
[]<- Cursor appears here.          ^
                                   Not here.

(Ken, thanks for increasing the arg length from 20 to 64 chars.  I didn't
see it mentioned anywhere in the ReadMe, so I've still been trying to
write code that squeezes everything into the old 20 char max.)

--331--
Is there any way to scan for all the U/Ls or msgs posted "BY" or "TO"
a certain user?  Very handy for SysOps to check WHAT (not just how
many) files/posts a user has done in the last few months.

Ken, would it be easy to modified the current TOME and BYME code to
also allow "TO 'user name'" and "FROM 'user name'" ranging, too?

--332--
> Item                  Charge    Session
> Per call charge      $ .0005 $   0.0000
Do I have something set wrong some place or should 'session' read
'0.0005' also?  (For the current call the user is online with.)

--333--
> Respond or Pass  q
> Stopping.
> Forget marked message now [Yes]? Yes
> List, Quit, subboard#, ?=Menu
>
> Upload base  zg
> Keyword text #1: doors
> Keyword text #2:
> Filter text  #1:
>
> Also pack messages to download [No]? No
> Forget existing marked items  [Yes]? Yes

After 1 ZG, I cleared all my marked msgs.
My 2nd ZG still thought I had some marked and asks if I
want those cleared, too.

--334--
Ken, I've been attack dialing FW (off and on) since
around 3am Monday 12Oct92.  Rings, but no answer.
I finally got through at *EXACTLY* 12:01PM (noon).
Do you have an event scheduled wrong?

(Yes, I stayed up all night AGAIN.)

--335--
Ken, I hope my 300+ suggestions haven't gotten out of hand and they
are reaching you in the spirit in which they were intended.  Namely,
use/discard as needed.

Earlier this year you made the very generous offer to invite
me into your home to demo Cnet.  We never got together but you
made another offer of a free demo disk and free manual.  Can we
get together for dinner some day soon.  I could talk your ear off
about BBSes.  With 24-48 hr notice, I can make myself available 430pm-
7pm, 365 days/yr.  I'm right around the corner here in Livonia.  (7
Mile & Farmington).

I'd love to pick your brain and write/UL a text file about this
meeting.

I'm going to try and get together with Ken for lunch someday soon.
If it's OK with Ken, I'd like to write/UL the text of the conversation.
Be looking for:

> 21 30-Oct 231 LUNCH         LHA  56K Notes from Ken Pletzer, Bill
>                                      Beogelein lunch Oct92

--336--
I don't know how many DOS cmds that get hot-keyed responses from
the user via calls to getch(), but I assume it's 90-100% of them.

They work fine from the CLI, work fine via Cnet's online shell,
but just lock-up when called via the pfile menu or /#4 or /#5 MCI
codes within text files.

Is Cnet using a very different method when doing its pfile/MCI DOS cmd
calls as opposed to the way it runs them via its online shell?

I'm running SAS v6.0 & WB2.04 with its standard calls to getch()
for non-buffered input.

I thought for sure that non-buffered input calls "worked" before Cnet
v2.26 or so.  They didn't get true non-buffered input, you still had
to hit RETURN, but they didn't just lock-up the system.

Even prgs as common as LHA (maybe the most commonly used prg in
all of BBS-dom) has hot-key responses:
>'zzendpad.foo' already exists, overwrite? (Y/N/A/S/Q):

LHA's author has somehow gotten it to work everywhere.
1) From CLI.
2) From online CLI.
3) From Pfile menu.
4) Via MCI calls in text file.

But there's a strange 6 second delay between each hot-key call.
But only for #3-#4.  Not #1-#2.

I haven't been drinking.

--337--
It's great that ADD'ing pfiles asks/uses the full path of the pfile.
It's great that it immediately checks for the file's existance.
(Don't change either.)

But how do I make it see my RESIDENT'ed cmds?
> Enter full DOS path to file   : FOO
File could not be found.

Maybe:
>File could not be found.  Use anyway (Yes)?

Mem/speed benefits for Resident cmds are just too powerful a feature
to passover.  Run 1 copy instead of 8.

--338--
File transfer and log-off...

Non-mnemonic...
>Countdown to auto-logoff:  SPACE to abort, ! to disconnect:  0

Mnemonic...
[A]bort logoff returning to BBS.   [D]isconnect now.   Count-down in: x

--339--
The idle AM screen used to display 70 variables about the system.
SysInfo displays only 17 of those.  (There just isnt' the room.)

(And you can't have a SysInfo window open, if UserInfo is already open.
And you can't iconify the control panel and still view SysInfo.)

I used to brag to Paragon/Starnet SysOps that "we" had 2 items displayed
on the idle screens.  Version # and Line #.

Cnet *had* (past tense) 70.

--340--
BBSmenu from master disk v2.30...
>30; Computer types; list no more than 24

Any plans on allowing more than 24 computer types to be mentioned
in BBSMENU?  (The structs can already hold 32 types.)  With nearly
a dozen Amiga models alone, it's easy to hit the 24 max quickly
if you add a few IBM/Atari/Mac/etc also.

(It seems to already handle >24.  Or am I running a risk by doing so?)

--341--
If he revamps them someday, the arexx GetUser #s should match the MCI
code #s.  He'll only have to worry about maintaining 1 list of docs
instead of the current 2.

--342--
If I do an "RA" and later do another "RA", the system will re-show all
the msgs that I've already read.  Doesn't it update the new-scan date/
time for each area that I've completed a 'read new' on?

I feel it should.  Do you?
Or is there a reason for it working the current way?
(I know I can jump back to the main menu and "NS" cancel them all.)

--343--
I was thinking more along the lines of using realloc() calls.
Maybe realloc() enough mem for 10 new subboards at a time.

No need to set a very large BBSconfig value to be safe.
No need to waste the extra memory that the above would cause.
No need to re-set it as you add bases.
1 less line in BBSconfig to update when converting from new Cnet release.
Never see another "did you check BBSconfig max bases?" Q&A post again.

Cnet BBS:  "The system automatically grows as you do..."

--344--
Anyway to activate the UP/DOWN arrow keys when in the online DOS
shell?  (To edit/execute previous cmds.)  This is a great feature and
seems to be available everywhere else online but here.

--345--
Why does my system keep looking/failing to find the follow files:

sysMenus:Main.-1, Gfiles:_tt0.Entry.-1, Gfiles:_sys.Entry.-1,
News:_tt0.Entry.-1, News:_sys.Entry.-1, Pfiles:_tt0.Entry.-1,
Pfiles:_sys.Entry.-1, SysText:tt0.conf.-1, etc...

R> I've seen the bbs looking for those too, but mine doesn't lock up.
Doesn't seem to cause any problem at all.  Just wondering:
1)  Am I missing some important, powerful feature here? OR
2)  1000s of "looking/failing" hits on the harddrives for files
    that will *NEVER* be found.

--346--
NS> The last two are TOTALLY USELESS, and IMHO, not enough of a reason to
NS> bring
NS> SAM back.
It can be very hard to accept that "not everyone likes things the
way I do".

NS> A> Why do I care what has happened on the BBS since I last rebooted the
NS> computer? --- I have not once said to myself "Ok. I'm going to reboot the
I think it can be a great testimonial to the stability of Cnet.
"The system has successfully done 1340 D/Ls, 290 U/Ls, taken 890 posts,
answered 1903 calls over the last 2 months without ever a need
to be rebooted, or even brought down and reset."

NS> would be MY OWN INFORMATION (how many posts/emails/etc I sent during my
NS> last call). IMHO, that is also useless information. The information is
NS> also
NS> readily available in the caller log - not enough reason to reinstate the
NS> old SAM.
You can see total call counts, UL counts, DL counts, post counts,
Gfiles read counts, Pfile counts, etc in the caller logs?  Where?
My logs just display mile long lists (as they should), no totals
for last caller, since setup, since reset, current, etc.

NS> readily available in the caller log - not enough reason to reinstate the
NS> old SAM.
We are not limiting Cnet by allowing clock/AM/AG toggles.  In fact,
we are limiting things but NOT allowing it.

If the 3-way toggle is brought back, you'll still be able to leave
your's in the clock-mode 24 hrs per day.
(I don't want to see you peeking at AM/AG at all.  :-))

--347--

NS> BA> Mnemonic...
NS> BA> [A]bort logoff returning to BBS.   [D]isconnect now.   Count-down in:
NS> x
NS> I personally like the old way better. I can care less about mnemonics - I
How many of the cmds on your BBS rely on them?
VF, View Feedback
VN, View New
EA, Edit Account
EG, Edit Group
WF, Write File
RF, Read File
AM, Activity Monitor
LC, Call Log
It's a very easy way of remembering 100s of cmds.

Would you say 90% of your BBS cmds represent mnemonic-methods?
Your free to make ST=View Feedback, XY=View New, KI=Edit Group,
WN=Read File, etc.  But why?

And here, it's more important than ever to have Ken pick his
keystrokes carefully.
1)  They can't be changed via BBSMENU (nor do I think they should be)
2)  A wrong key-hit and you instantly drop carrier.

--348--
NS> This is cool because I will enter a single message base several times in a
NS> single call to "SN" or "RN" because I had been distracted by OLM's, ideas,
NS> etc. the previous times I went in. If it had reset simply because I had
NS> read the messages (and not had read the messages, hung up, called back), I
NS> would be screwed and have to enter a "NEW" command.

Even if the scan-date only gets reset for:
BA> *each area that I've completed a 'read new' on?*
The keyword being *completed*.  Not those that I've been distracted from
while in the middle of reading.

If you've read all new, and EXITED that base, (BOTH) then
reset that base's scan-date.  You are done with it.
This becomes more and more important with large BBS with 100s of
areas available.

NS> the NS menu), download/upload, logoff. I almost never see users type RA
NS> more than once in a single session, and I've never seen a complaint of the
NS> same messages being shown twice in running my BBS for over a year.
Don't they get distracted in the middle of a RA or BA as much as
you and I do?  I get distracted a lot.  That's why I'm asking for
this feature.
But just for RA, not SA or BA.

--349--
T> hate to disagree but I think it's perfect the way it is, the first time
T> someone calls a Cnet board (remember your first?) they're getting their
T> feet wet and one OLM will destroy their board self confidence, the second
T> time they call, they can read the messages that are new and current.
I was lost beyond all belief on my 1st call to a Cnet system.
And that was after many years of calling (as well as running) many
different BBSes.  And not just on my 1st call, but on my 1st
*50* calls.  I was lost.

This 'default read new date' isn't suggested to further confuse
1st time callers, but to allow them to get into the swing of things
by already having x days for msgs waiting for a RA cmd.

T> the second time they call, they can read the msg that are new and current.
A rough time on their 1st call, and there just might not be a 2nd call.

Seeing a dozen "no new news", "no new msgs", "no new files",
"you can't enter that area for 10 mins", "that area is empty" and
do they think they've dialed into a wonder system, or what?

"That area is empty" is a biggie.  When it's not EMPTY at all.
It could have 10,000 files available for D/L.
They just don't have full access on their 1st call.

--350--
T> I also agree with it, Although it hasnt been a problem I've always hated
T> users who liked dropping carrier instead of going through the proper
T> procedures, When I dl/ed the file I knew immediatly I was going to use it.
I think, in part, dropping-carrier comes from the 95% of the non-cnet
BBSes that don't allow global-cmds.  Some sysops design systems that
make a caller go hunt of the LOGOFF cmd.  I've often had to [Q]uit,
[Q]uit, [M]ain, [P]revious Menu, several times to get back to a place
that lets me LOGOFF.  Thank God for Cnet's global-cmds.

As long as it doesn't damage the BBS (Paragon locks up) I don't care
when/where/why a user *deliberately* drops carrier.  If it's really
that "rude", why do you want "rude" callers to stay online x additional
secs in order to go through the proper log-off cmds?
Free-up the line for someone else.  (I have >2500 users fighting for
my 2 lines.)

Callers that *accidently* drop carrier are another matter.  Are
they doing something wrong?  Do I have something set wrong?  Are
1000s of my callers getting cut-off for some reason?

If anything, Cnet should keep track of the # of dropped-carrier
calls each caller has.  (Only takes 2 bytes.)  Wouldn't you wonder
what was going on if you ran a dropped-carrier-pfile and saw that
100s of your calls had 100s of log-offs via dropped-carriers?
(Or could check and see that user #893 had 240 of his 245 calls
as dropped-carrier.  Just send him email and ask him if everything
was OK.)

If so many of us are *that* concerned about dropped-carrier,
let the BBS track it for us.

Add a new AM value.  (But to track down *who* is dropping-carrier,
Cnet would have to have a per-user variable for it.)

--351--
KP>      How much will we have to pay for the new pages?  Just postage?
And when?  I'd buy the new binder IMMEDIATELY if I could get new
pages upto v2.30 (or even v2.37).

What I fear is going to happen, is the new pages won't get written
until 1000s of changes have been made to Cnet.  Then who wants
the giant task of sitting down and writing all that?  (As well as
missing tons of things.)

If the pages where done as-the-system-changed:
1)  No giant single task be done later.
2)  Nothing left out.
3)  The manual is current as of changes Ken made YESTERDAY.

Time consuming?  Yes.  But will it be any less time consuming to
do it 6-12 months from now?  A task that takes 20 hrs today, still
takes 20 hrs later.  (But later, the additional changes to Cnet will
make it a 2000 hr project to write the docs.)

All that would have to be done is a commitment from Ken it mention
EVERYTHING changed in the README file.  And 1 (or more) volunteers
would re-format it into a form that we could all dump to our printers
and insert into our manuals.

No printing/mailing need be done on Ken's part.

What a waste for 600 of us to *EACH* reformat the same README
into manual-page format.  (And the READMEs aren't complete anyway.)

--352--
NS> BA> "That area is empty" is a biggie.  When it's not EMPTY at all.
NS> BA> It could have 10,000 files available for D/L.
NS> BA> They just don't have full access on their 1st call.

NS> Do what I do. In sys.new user, have a statement such as:
NS> "This is your first call, so there will be no new messages/files for you
NS> peruse. Take this time to DROP/ADD any and all subboards from you select
NS> list! That way, when you call back, it only takes one command to browse
NS> through everything that has been posted/uploaded since this call!"

I'd like to change bbstext from:
>"That area is empty"
into
>"You currently don't have access to any of our /XXX subboards"
>"You currently don't have access to any of our /YYY pfiles"
>"You currently don't have access to any of our /ZZZ gfiles"
for MCI expansion into:
>"You currently don't have access to any of our 234 subboards,
> 23 pfiles, 47 gfiles."
(But we need these new MCI codes.)

Let the user know, "we have a lot to offer", "if you have the right access
level".

Instead of "We have nothing", which is what ""That area is empty"" implies.


--353--
NS> I agree with TRAX. I've gotten many complaints that CNet is >the< hardest
NS> BBS software to learn how to use, especially if one is used to WWIVing
NS> (bleeech!) Besides, if there were, say, 5 days worth of new messages
NS> queued
NS> up for a new user, and he accidentally hits "R" from the NS prompt, he
NS> will
NS> have to sit through like 1000 new messages on some of our BBS's (unless

That's why it would be a BBSconfig value.
Large, high traffic BBSes could set it to 1 day instead of 5.
Smaller, low traffic BBSes could set it to 20 days.
You and everyone that wants it to work as it does now, would set
it to 0 days.

Everyone is happy.

--354--
Case #1:
You are doing an RA, 1/2 way through a certain sub you get distracted
and have to exit the sub, abort the cmd, or go do something else.
That 1 base's new-scan date is NOT changed.

Case #2:
You are doing an RA, you've completed the reading for a certain sub,
you get distracted and go do something else.
That 1 base's new-scan date is now set to the current date/time.

The big difference is:
Did you fully complete your reading for that sub?
If YES, then you are done with it, why re-read it?
If NO, then your next RA will re-read it.

Here's what can happen currently:
You spend 2 hours RAing 100 subs.
You get to the 99th one.
You're 1/2 way through reading it, you get distracted
and have to exit the sub, abort the cmd, or go do something else.
When you try an RA afterwards, you have to re-read 2hrs worth
(all 98 previous subs) of stuff that YOU ALREADY READ!!!!

I've not heard from anyone that this is truely how it currently
works, but it appears to.  I sure hope someone will tell me
I'm wrong.

--355--
BT  If you ran a PC bbs you would find out that the updating policy is fine,
BT  but I DO not agree with how PS chooses their beta testers.  ALL of the
BT  ones that I see are developers of some kind.  There needs to be some end
BT  user sysops that just use the bbs.  PCboard  has over 200 beta testers

I would think Ken would have gone with an extremely diverse cross-section
of users as beta-testers.  Single line, 10 line, Fido, no-Fido, UUCP,
no-UUCP, CD-ROM, non-CD-ROM, heavily modified, stock, 68000, 10, 20
,30, 40 machines, limited RAM, tons of RAM, limited HD space, tons
of HD space.  IT's the only way to tell how the BBS will respond
when it is released on the public that are going to be using it
in a wide variety of ways/setups.

--356--
LH> I know that this can be done with an offset variable, but I would rather
LH> have it
LH> as a GETUSER that wouldn't change with every update. This affects dozens
Do offsets change with *EVERY* update?

Perhaps more dummy-padding in the structs would allow Cnet to expand
and have the offsets change every 25th update, or so.

--357--
LH> Hi there Bill, What I would really like to see is a step further than
LH> this...
LH> Why not set a users scan date to each message that he reads? What I mean
LH> is, how
LH> often have you had to leave <logoff> immediately, and be in the middle of
LH> reading a message area? You are then faced with the choice of reading to
LH> the end
LH> of the message area, or leaving immediately and having to read all the
LH> messages
LH> in that area again... I think when the user exits a message base during a
I've seen BBSes that do exactly this.  Unfortunately this is
A LOT of extra info that needs to be stored to disk for every
caller in every base for every msg.

1) Per msg
2) Per base
3) Per user
It's #1 style.
Currently Cnet does #2.
It's better than #3 , which is what many BBS do.  It saves to disk
just 1 scan date.  If you scanned msgs AT ALL, then your scan date is
updated and when you scan again on your next call you miss the
remaining 99 sub's new msgs because you scanned *1* on your previous
call.

I think #2 is a nice compromise. But, but, but only if it
updates each area's scan date AS YOU LEAVE IT AFTER READING EVERYTHING
NEW THERE.

I hate to flag-Cnet-to-death but it Ken's worried about users liking/hating
this change then make it a user's prefs flag.
> Update scan-date pointers continuously: YES/NO

--358--
After a user has read/killed all his waiting email, prompts like:
> Quit, Scan, New, Old, [All] :
should be skipped entirely.

He can't SCAN/NEW/OLD or ALL anything.
Why offer such a prompt when all anyone can do is QUIT anyway?

--359--
Ken, any plans on expanding the amount of info contained in
"LinkPortData"?  (As well as adding more than the current 0 bytes of
padding to allow for future expansion.)

Maybe someone would come up with a new new "/MAP" cmd in a JOINLINK
conf session would generate a graphic display of LINK IDs (3 examples):

    1     2
     \   /
      \ /
7------5 -----4
      / \
     /   \
    6     3

8---1---9---3
             \
              \
               6---5---4---7---2

1---20      3---25
     \     /     \       10     29   30--1    38--39 40 41---18
21    \   /       26     |       \   /      16      \ | /
 |     \ /               |        \ /       |        \|/
22------8-------9---42---27--28    2------5-6---------7---37--19
       / \          |    |    \   / \     |          /|\
      /   \         |    13    \ /   \    32        / | \
    23     24   12--4--11       14    15       31--33 34 35--36

Then followed by the map's legend:
   Number       Name                City, State, Country  User Count
1) 313-981-1524 Cnet BBS HQ         Canton, MI  USA           3
2) 313-473-2020 Amiga ShareWare HQ  Livonia, MI USA           4
3) etc, etc...

--340--
Any plans on including the # of times a msg has been read in the msg's
header?  Not for any other purpose other than statistically reasons.

There's already plenty of room (thank you!) in HeaderType and ItemType
structs, so things would still remain 100% backwards compatible.

Would callers be interested in knowing that their post or reply has
only been read 3 times or 1000s of times?

Would SysOps be interested in knowing that even though subboard #41
rarely gets posts/replies, it is still 1 of the heaviest READ bases
online?  (I usually make my decisions on thing like that to tell which
low-activity bases to KILL off.)

>base #40, 17 posts, 110 replies,  421 reads
>base #41,  7 posts,  12 replies, 9032 reads
>base #42, 33 posts, 274 replies,  109 reads
(I'm sure someone would write a pfile for this.)

It would most likely cause a lot of extra writes to disk, though.
Maybe a BBSCONFIG option for it:
1 <- Track msg read-counts? (0=NO, 1=YES)

(Even ancient, bug-filled versions of ParagonBBS track this properly.)

--341--
>I get error #11, what is it?
Others have already asked Ken for a list of these error #s.
Nothing yet.

Ken, would it be possible to include your header file that had
these error #s in the master disks 'programmer' dir?

--342--
If you post a public, but addressed, item/response to someone is there
anyway to see if they've read it?  Some systems have a "(REC)" or
"(R)" marker in the header.

--343--
No I don't have any indexing source handy.  But it's not a horribly
complex as 1 might think.

Let's say each base has 2 files that store all of that msg base's 1000
posts & replies.  (You've already eliminated 988 files that would
normally be needed.)

HEADER/INDEX FILE:
Each msg has a ~200 byte header.  So the 1 file (the index) is only
200K.  In addition to the user's name/date/subject, that header/index
file also contains a pointer to the actual position and length in a
separate msg text file.

MSG TEXT FILE:
The msg text file might have posts of varying length 2k-5k each.
So that file is big.  2-5 megs.

If you want to read msg #57.  You quickly jump to the 57th header
in the index file, see that the actual msg text is stored at
byte 190943 in the text file and is 1343 bytes long, another fairly
quick seek(), and the text is displayed.

Of course, scans and browses come up instantly just by reading/
displaying the index file only.

BBS-PC! had 2 index files.  One sorted by date and one alphabetically.
This could give you A->Z, Z->A, new->old, old->new sorts.

When a msg is "deleted", it's the index file that is told that
it no longer exists.  The corrisponding space in the text file
can then be re-used for the next msg post.

For threaded msgs, the index file would also have to maintain
position info for "parent" and "child" msgs.

--344--
Msg storage:
Method #1:  1 file per msg.  (Currently method)
Method #2:  1-2 index pointer files + 1 header file + 1 msg text file
            per sub.

      Speed         Disk space   Memory  Programming Ease   Backup Ease
------------------------------------------------------------------------
#1: Med-fast       Extremely hi   Same     Very simple       Very Slow
#2: Extremely fast Extremely lo   Same     Complex           Very Fast

I'm sure it's up for debate, but I see method #2 tieing or winning in
4 out of 5 (80%) important areas.

LH>  system? I would like both smaller size and more speed, both of which I
LH>  think can
LH>  be achieved by using a form of the Hudson message format. That is indexed
LH>  pointers to about 3-4 files for each message base.... works in Xenolink.
Len Haggblad, is the Hudson message format public domain?  Do you
have the header files or info on implimenting it?  Could you U/L it?
Perhaps Ken could go with an extended/modified (to support the
additional features of Cnet) version of Hudson.

LH> works in Xenolink
E-X-T-R-E-M-E-L-Y fast.  I haven't seen anything like it anywhere.
Let's face it, BBS are mmost likely going to get bigger and bigger
in the coming yrs.  Cheap $99 600meg read/write optical floppy
drives will be abundant sooner than you think.  Horribly large file
and msg bases.  Cnet better be ready for it.  The yr 2000 is only
7 yrs away.

--345--
During a ZG, I've asked that msgs NOT be packed for DLing.
>Also pack messages to download [No]? No
but still am told:
>**** YANK REPORT
>You must first download your EXISTING yank file.

I'm not trying to yank anything.

(I am VERY glad to see yank reporting more info than it did
before, though.)

--346--
UN>  I think this is very poor considering some BBSs do not even pause for
UN>  a second to locate 100+ new messages in an area.
They use pointer/indexing files.
The 100 newest msgs are the 1st 100 pointers in the index file.
Absolutely NO searching for them.
And that goes for msg bases that have 1000 posts or 100,000.

When you walk over to a terminal that handles the country's Social
Security or tax payers records and enter a person's name, you
don't think it just starts at record #1 and searches through
150,000,000 records in 1 giant file until it finds a match, do you?
(Or worse yet open/read/check/close 150,000,000 individual files.)

It's more like:
Search a 100meg index file that points to each of the records
in the bigger 100gig file.

And I've even seen index files that they themselves have index files.
Search a 10meg index file that points to each element of an 100meg
index file, that points to each of the records in a 100gig file.
(That's overkill for a BBS prg, though.)

And that's on a blindingly fast/powerful mainframe machine.
By comparison, the old 680x0 needs all the help/speed it can get from
the fastest, cleverest indexing algorithms available today.

Cnet deserves such.
(I'm starting to sound more and more like Ross Perot.)

--347--
NS  Bill - the consequence for sacrificing holding the new pointers is that if
NS  I want to jump back into a SUB (say it's a UDsub) and do a quick SN before
NS  selecting files that were uploaded since my last call, I can. With your
NS  system, that won't be possible.

NS  I like the way it is now. The purpose of the new pointers (from what I've
NS  been led to believe) is to display the NEW MESSAGES SINCE LAST CALL. Not
NS  since last scan.
As an added side-benefit, what if you've completed all your reading
online and do some time D/Ling, pfile playing, news reading, etc.
And now want to do another RA but just of all the new msgs posted
while you were online.  (Big 8line systems, heavy msg posting, Fidonet
and Usenet feeds that have come in, etc.)
RA will re-read everything again.  (If you hadn't called in a week,
that can be 100s of msgs.)

Cnet is the only BBS package that I (on the average) end up reading
ever msg twice.  (Sometimes 3 or more times.)  Most annoying.
And relog-in and/or cancel-NS solutions just add more work for the
user.  (And I'm certainly NOT a beginner.  The poor new user.)

Make it easier, not harder.
Make it automated, not manual.

--348--

>How do I send new users email automatically?
>Create systext:Nmail

Would you have had this difficulty if nmail had been named NewUserMail
instead?  Or something equally descriptive?

Or ANYTHING different than the EXACT same name as the NMAIL (netmail
executable) which has nothing whatsoever to do with this.

--349--
Ken, which value in PortData tells if a node is LOCAL or REMOTE?
I tried using "myport->PortZ[line]->LocalMode" but got:
1 With user online a local  port.
0 With user online a remote port.
0 With no user online a local port.
0 With no user online a remote port.

I need to tell if the PORT ITSELF is local-only, regardless of
whether a user is on it at any given time.

--350--
Ken could put an end to ever trying to please everyone again.
Just make the whole thing an arexx script.
Arexx would do all the work, and a single new 'ADDUSER' cmd would
write it to disk.  The script could even do some pseudo-artificial
intelligence checking on the user's application and automatically
validate, not validate, or not even write the info to disk, if
the user didn't answer all the questions as desired.

You'd see some incredibly slick arexx scripts for this.
Some could ask the user to verify his answer after each question,
or only at the conclusion.

---Bill Beogelein, 313-473-2020, Fido 1:2410/207, 22Oct92



