
Sunday 20-Sep-92 20:20:41

--227--

Ken, please concider marking these beta-releases "v2.30beta4" or
something.  All of us would instantly know when v2.30 is available as
non-beta that way.  And we could report beta-bugs with exactly version #s,
too.

--228--

Some BBSes allow you to 'drop a msg thread' (ie FORGET cmd).
The discussion can continue for those that wish to 'beat a dead horse',
but if you aren't interested in reading that topic (for whatever
reason.  "Nasty discussion" or just plain "not interested in it".)
you can FORGET (or later REMEMBER) it, and it'll be skipped during
all future READ cmds.

Not every topic (ie msg thread) is going to interest all of us, but
I hate to DROP entire subboards just to avoid them.

Maybe Ken will keep this idea in mind for possible inclusion in
a future release of Cnet.

--229--
>Seperate configurations for EACH area within CNet...  G/N/Pfiles, NewUsers
Or Gfile #0, Nfile #0, Pfile #0, User ID #0, would be the template
to use for all future ones, respectively.

(Trying to keep with Cnet's 'do it all online' (local and remote)
current setup.)

--230--
> 4 subboard(s) report new uploads since your last call.
> Quick-browse these new files now [Yes]? Yes
> There have been no new uploads since your last call.
I'm sure I'm going to get a ton of email/feedback asking me
to explain this over and over again.

--231--
Just allow a subboard to be duplicated.
Works like ML swapping.
>DUP 3 10
All the current settings of area #3 are now part of the newly
created area #10.  Just change the area name with EL and thats it.

You could even create/keep 5 areas that are just for this DUP use.
Set all your defaults once, and each time you need to create a new
area, pick from 1 of the 5 templates.

>DUP 9 20-40
I just created 20 new areas with all my designated defaults already
set (except the NAME would have to be edited) in 1 sec.

Time how long it would take to create 20 areas and set all
your defaults 'by-hand'.

--232--
PB> For now I think Ken should continue on his chosen path and UPGRADE the big
PB> stuff first (BBS, FIDO, UUCP) the cosmetics can wait for a while.
I think so too.  (Especially UUCP.)

But I also think we should post/mail Ken every conceivable idea/comment.
Good 1s, bad 1s, and totally insane 1s.
Let him decide to:
1)  Add it now.
2)  Add it later.
3)  Toss it out.
4)  Keep it on the back-burner as "under consideration".

The only 'bad ideas' are 1s that we never tell anyone.

I hope Ken feels this way too.
I don't think Cnet got to where it is today with "That's
a stupid suggestion.  Shut up.  Are you crazy?"
(Not you, but others have commented on suggestions with these
replies.)  A great way to kill new features or even the SUGGESTIONS
regarding new features.

--233--
>ADDRESS your response to the last caller (Yes/No) with a DEFAULT of [Yes]
Jim, I saw your vote topic.  Can't this be changed via BBSTEXT?
If not, it should be.  Then each side could set it just
like they wanted.

(Sure wish we could tack-on short pro/con comments like this right
onto the vote topics themselves.  It would follow standard Cnet
RESPONSE-type msg threads.  1 thread per topic.  We could read
some of the pros/cons that others have added before we vote.)

(And similarly, item posts in the base and udbases could
be made as vote-items or vote-responses.  Users could vote YES/NO
if they agreed/disagreed with that user's comments.  Nothing
fancy, just use 2 LONG vars that are already a part of each
post/response for storage.  (100% backwards compatibility.)

I think people would be surprised at how strongly a large # of
people would be for/against a certain idea.

Do you like this suggestion?
> 2093 users have voted YES
>    4 have voted NO
(See what I mean? ;-))

--234--
AK> If anything, make this a FLAG in the users account. If the "EDIT OWN
AK> ACOUNT" flag is ON, then it is OK, if not, then no!
AK> --->Analog Kid<---
What % of your users would you have with this flag set to Yes VS No?
Keep in mind that if you allow someone to edit their own
account, they can basically edit ANYTHING there and can drastically
change all the things you specifically are allowing/disallowing
them to do.

Cnet already has a whole list of things for security purposes.
Allow/disallow things based on access level, baud rates, timelocks,
a ton of flags, 2-word encrypted maintenance/DOS passwords, etc.

Ken, if you feel a certain thing needs to be more secure, require
the 2-word password ID scheme that is already a part of Cnet.
Don't say, "I'll make this more secure by entirely forbidding
anyone to ever access it again by entirely removing it."
(ie prohibiting a user to edit a system operator's account from remote.
Also, it is not possible to set the SystemMaintenance privilege
flag, or view the password of any user from remote....)

Make things more secure by "making them more secure" NOT removing
them.

--235--
After we've used VDE.C to create many of our own *.VDE files to edit
our own custom structures (not Cnet's 3), what do we do with them?

Is there a pfile (hopefully DOS, not Cnet) that can be run to
use our new *.vde data files?

--236--

100 subboards, which partitions are which?

> (5) Utilities:  AO1
> Please select a valid partition.
> (5) Utilities:  AO2
> Please select a valid partition.
> (5) Utilities:  AO3
> Please select a valid partition.
> (5) Utilities:  AO4
> Please select a valid partition.
> (5) Utilities:  AO5
> Please select a valid partition.

Ken!  Help!  Please make this show you which partitions are available
to this subboard so we don't have to guess.
> (5) Utilities:  AO1
> Please select a valid partition (7,10,14-20).

--237--
Ken, are you familiar with Usenet?
50,000 nodes, many universities, professors, engineers, designers,
authors.  You'll regularly see posts from Amiga hardware/software
vendors, folks that wrote KS/WB/DOS, designed Amiga's motherboard,
HD repair technicians, JVC Laboratory of America, Jet Propulsion Lab,
Trailing Edge Technology, Ardent Computer Corp, Harvard, Yale,
Cornell Univ. CS Dept, Biar Games Inc., Ardent Computer Corp.,
AT&T Bell Laboratories, NASA, Seagate, Microsoft, and on and on...

Very big, world-wide, very professional, not your usual
"kid's playing in Fidonet" echos.

ExcelsiorBBS already has Usenet support and a built-in frontdoor
mailer to get/send UUCP mail pkts.

--238--
For all of those that are having trouble with the bug that causes EA
to treat all user's 'autovalidate-flag' as its 'call-back flag'...

This only works with systext:udata.vde size of 12956 bytes.
LHA lh5 must show its checksum as "DB72".
(No "$VER:" version number given in any of the *.vde files (ugh).)

Run "NewZap SysText:udata.vde" in the hex-edit mode and change SECTOR
4, OFFSET 19B from 12 to 11.
(Only change it if that byte IS 12 hex already.)

Due to the magnitude of this bug (your system could unintentional make
100s of long distance phone calls) I was hoping a replacement
udata.vde would have been issued immediately after VDE's 07Aug92 debut.

--239--
ET shows I'm on a 25-line term.  I set my screen height for 25.
BROWSing bases shows 19 lines between page-pauses.
(17-line of info, a blank-line, and a prompt = 19 lines)

--240--
From what I understand Usenet support really isn't that hard
to add.  The Unix-wizards kept it simple and didn't allow the
limitations, inconsistencies and down-right incompatibilities that
are so much a part of Fidonet.

Ken, have you taken a look at:
AddUUCP.lha                86871 ----rwed 07-Jul-92 21:25:21
: Protocol & conventions used for Usenet
    2960    1266 57.2% 26-Jan-91 00:50:20  README
   45826   15138 66.9% 31-Dec-87 00:00:00  Protocol/RFC-1036
    6267    2361 62.3% 31-Dec-89 00:00:00  Protocol/RFC-1137
  106299   33760 68.2% 13-Aug-82 00:00:00  Protocol/RFC-822
   27823    8486 69.5% 31-Oct-84 00:00:00  Protocol/RFC-920
   26130    8895 65.9% 28-Feb-86 00:00:00  Protocol/RFC-976
   18625    8344 55.2% 08-Jan-91 06:45:32  Registering/map_README
    5410    2399 55.6% 25-Jan-91 22:50:22  Registering/README
   15586    5161 66.8% 25-Jan-91 20:59:34  Registering/US-DOMAIN.TXT

--241--
Count another big vote for AM+AG displays.
It would take a lot more than 'the current time', to convince me
it's worth losing the *70+* pieces of info that we lost.
:-(

--242--
I'd be in favor of this.  Should ALL not-recieved OLMs go
to your mail box?  Or just:
1)  System's  (YANK's, etc.)
2)  From the sysop.
3)  Sent by non-sysop to you specifically.
4)  Sent by non-sysop to ALL PORTS.
My desired-priority would be 2-1-3-4.

--243--
>Add a dialer or arexx script to Cnet...
You do know you can leave Cnet running, have it release the
ser port, then run a full term prg?  A term as simple or complex
as you want, dialers or no-dialers, arexx scripts or no arexx
scripts.

Keep Cnet a BBS.  Let JrComm and Ncomm be the terms.
(You could never equal JrComm's powerful dialer, nor Ncomm's
very powerful script language, and very, VERY powerful arexx port.)

--244--
I have a DOS pfile that I want to automatically detect if it's being
run from the CLI as opposed to online.  (So it can behave in 1 of
2 different ways.)  What is a 100% sure-fire confirmation?
(Something other than checking passed-args, etc.)  It is crucial
that it detect this properly AT ALL TIMES.

Also, when I run this DOS pfile online, how do I detect which line #
(0-23) it is being run by?  I already have access to a pointer to the
MainPort structure, but didn't see any way to tell which line #
the user is currently on.  (I'm sure it's staring me right in the face.)

(I assume I need this 'port #' before I can do anything with:
PortDoing[24], PortUser[24], PortZ[24], CRoom[24], CUser[24],
MyTask[24], MySignal[24], long SeparateTexts, nBBSTEXTbytes,
nBBSMENUbytes, nNOISElines, nNOISEbytes, OLMpath[24], EXTRACTpath[24],
YANKwork[24], PortID[24], Hidden[24], Muffled[24], Monitor[24],
ChatReq[24], Dumped[24], OLMWaiting[24], HideAll[24], MuffAll[24],
MonitorAll[24], OnLine[24], nPdepth[24], ChatCode[24], WantToOpen[24]...)

All works fine if I force the SysOp to call this DOS-pfile with a
"MyDOScmd %23" passed-parameter, but I want to make it "100%
automatically and 100% fool-proof."

--245--
I hear that all netmail addressed to non-existent users, gets tossed
to 'BAD'.  Even stuff addressed to "SYSOP".  (I thought "Netmail to
SysOp" was a pretty Fido standard, recommended pratice.)

Perhaps, by default, all netmail and local posts addressed to "SYSOP" could
go to acct #1.

And perhaps a new bbsConfig option could specify, "send all unknown netmail
and "user-not-found" local-mail to account #n".

--246--
>You have new mail--read now [No]?
It would tell you:
1)  How many, new/old pieces.
    I think most users would respond very differently to that
    prompt if it read:
    >You have 1 new letter, 40 old--read now [No]?
    OR
    >You have 37 new letters, 2 old--read now [No]?

2)  Default to YES if new-mail, NO if all old-mail.
    (It would just need to display 2 separate lines in BBSTEXT,
    respectively.)
    IF_NEW> You have %d new letters, %d old--read now [Yes]?  /?1
    IF_NOT> You have %d new letters, %d old--read now [No]?   /?0

--247--
Are there any plans to allow vars to be passed from the BBS to BBSmenu?
Currently, if I have a pfile (Cnet or DOS) that supports many different
features via cmd line options, I need to change BBSmenu to support ALL
of them.
BBSmenu>   FOO SLOW
BBSmenu>   FOO FAST
BBSmenu>   FOO ME
BBSmenu>   FOO YOU
BBSmenu>   FOO THIS
BBSmenu>   FOO ME FAST
BBSmenu>   FOO YOU SLOW
A pfile with just 6 options (that can be used in a variety of combos)
would need 720 new lines added to BBSmenu just to support them all.
(Some of my pfiles that I'm porting from Paragon to Cnet have 20
options, or 2,432,902,000,000,000,000 possible combos.)

But a BBSmenu that could do things like:
BBSmenu>   FOO | \#4c c:FOO.exe $0 \
or
BBSmenu>   FOO | \#4c c:FOO.exe -q $2 -r $1 \
would allow the user online to enter:
Main> FOO ME FAST TOO
and his cmd line options would be passed into the var in BBSmenu
$1, $2, $3, respectively.  (or $0 meaning all of them.)

One or two new lines in BBSmenu replaces the need for 1000s.
(Similar power via MCI in text files:  /#4 MyCmd $1 $4 $2 /.)

Heck, you could even do things like:
BBSmenu>  DOS | \#4 UserC:$1 \
and give everyone DOS access, but since only the 1st parameter is
be passed, they could only execute safe things like STATUS, DATE,
LIST, DIR, AVAIL.

Or a little more power for higher access users:
BBSmenu>  DOS | \#4 UserC:$1 $2 \     `20-22
allows 2 parameters.  "STATUS FULL",  "LIST dh0:", "AVAIL CHIP".

But SysOps COULD pass all parameters:
BBSmenu>  DOS | \#4 $0 \      `23
for full dos access.  Online just precede any dos cmds, and parameters
with the cmd "DOS".

--248--
For my highest of the 3 allows file ratios, and my highest of the
24 allowed groups, I wanted to set unusually high (but never totally
unlimited) file/byte ratios.  The structures support upto 255:1.
EG-VDE will only allow me to go as high as 99:1.

--249--
Perhaps someone will gather-up 15 of the best new, heavily modified
BBSText files and place them into 1 bundle for D/L.  We could all
go over them and pick/choose the best stuff for our own systems.
(Sure would made a nice 3rd Cnet disk.  880k of compressed,
assorted BBSconfig, BBStext, BBSmenu, BBScolors, BBSports, BBSlog,
the best Arexx scripts, DOS files, Pfiles, etc...)

--250--
What would be the quickest way to inform all Cnet SysOps world-wide
that a new release has gone non-beta?  (Without a need to call here
long distance over and over again, aonly to find out it still isn't
available yet?)

Maybe something like:
> CNet AMIGA 2.30beta (c)1990-92
> CNet AMIGA 2.30 (c)1990-92
every caller, to every C-net beta-test site, support site, and
even all the illegal boards, would instantly know that it has
gone non-beta.

All Fidonet tear-lines too...
>  --- Cnet v2.30beta
>  --- Cnet v2.30

--251--
Where does the different user's "acct #" VS his 
"unique ID #" come into the picture?

--252--

I'm not seeing massive #s of JoinLink sessions.  Why?
Any plans on allow unattended JOINLINK sessions?
The event-scheduler would have a new JOINLINK cmd.
Its ARGS parameter would be a new JOINLINK config path/filename.
(You could specify any 1 of several custom configs.)
All would automatically start/end during the specified time period.

4   <- Greatest # of systems allowed to link to you at 1 time
1   <- Your JOINLINK ID #
FOO <- Password sessions, only allow linking if pswds match other systems
5   <- I only receive incoming links on this port.   "0" means any/all.
40  <- Max # of mins any 1 system can be joined to you.
0   <- Join room #.
; The remainder of the config is only if you are dialing out.
1-313-981-1524  <- # to dial-out. "0" means you are "receive-only".
2               <- Use this port to dial-out.
30              <- If busy, redial every x secs.
100             <- Redial a max of x times during this period.

Also, how necessary is it to manually specify a JOINLINK ID # at all.
Could "0" be made to mean, "After the initial CONNECT, pick a random
ID # that is current NOT being used in the link"?  (I'm trying to
remove 3 drawbacks.  1) Everyone must pre-arrange a unique ID.  2)
Must pre-arrange an exact date/time.  3) All SysOps must be present
and manually setup their links.)

BBSLOG would need to track JOINLINK usage.

I'm sure some of the larger systems would allow incoming automated
JOINLINK calls on 1 of their spare lines at various times throughout
the day.

We could setup a Cnet National JoinLink Hour (NJH) similiar to Fidonet
mailhour each night.

--253--
Should I be running a v2.28 control panel with v2.30?
(Or did I goof-up my updating?)  They certainly don't have to be
exactly the same version #s, but always thought they matched
in the past.

--254--
So who's going to take Ken's update-README files and reformat them,
number pages, etc, so we can print them and insert them into our binders?
I thought that was the whole point of the new binder-format?

--255--
BBStext in dozens of places...
CURRENT>        Quit, Scan, New, Old, [All]
CONFIGURATABLE> Quit, Scan, New, Old, [All] /?A
POWER!!!>       Quit, Scan, New, Old, [All] /=A

--256--
Online here yesterday, "WHO" was showing I'm at 9600, I got a CONNECT
14400 when I logged in and was D/Ling LHAs @ 1600cps.  Is "WHO"
reporting my modem speed correctly?

--257--
Ken, any plans on allowing "command aliasing" by users?  It would work
similar to "15) Edit MACROS", but instead of ^E, ^F, ^G, users could
alias any string they choose into any other string.

> 13) Edit SIGNATURES                  14) Edit "WHO" BANNER
> 15) Edit MACROS                      16) Edit CMD ALIASES
16
--- THIS --- MEANS --- THAT ---
0) All others
1) MINE        : READ BYME
2) YOURS       : READ TOME
3) TAG         : *
4) F           : U
5) M           : B
User's could now enter cmds they are more familiar with, "MINE/YOURS/
TAG/F/M" and the BBS would see the aliased-equivilents.

They'd work from any menu that supported those cmds.  They'd all have
to override whatever the sysop had setup as MINE/YOURS/TAG/etc..

(^E ^F ^G isn't exactly mnemonic.)

Maybe allow 10 such CMD ALIASES per user.                          
Pick choice #0 from the menu above and it would list everyone else's
aliases system-wide.  (100s of them.)  To give the user some ideas.

--258--

Ken, any plans on moving /c0-/c9 onto the end of BBSTEXT?
Any place Cnet has color (log output, Ctrl Panel, SysInfo,
UserInfo, etc), could now be set to whatever colors we want.  (Or
replaced with bold, italics, under_scored for non-color output, or
removed entirely.)

Also allowing us to remove 12 chars from each line of a 1,000 line
log.DLOADS log, saves 12,000 bytes of space.  It starts to add up with
several big such logs.

--259---

Which would be more readable at a quick glance of the SysInfo window:
1> Most space available: 108928938 bytes
2> Most space available: 108,928,938 bytes
3> Most space available: 108928 Kbytes
4> Most space available: 108,928 Kbytes

We'd lose the current per-byte accuracy, but I think if any of your
partitions get down to under 1K free, you're headed for trouble
whether it's 200 bytes or 800 bytes left free.

Or, if you really want to get fancy:
        0-  9,999 Displayed as  bytes.  "   0-9999"  (byte accuracy)
   10,000-999,999 Displayed as Kbytes.  " 10K-9999K" (K accuracy)
1,000,000->over   Displayed as Mbytes.  "1.0M-9999M" (100K-1M accuracy)
(Keeps all output 1 byte-10gig in a 5-char, right-justified field.)

(You wouldn't even need the comma separators then.)

The same 1 function could be used for ALL large # output everywhere.
EA, CR, EG, EL, file lists, etc

--260--

> CRedits:
>                     Files        Bytes
> Default ratios:      75:1         90:1
This apparently always shows ratio-set #1.  If your ratio-set #1
is set much higher, or much lower, than the current subboard setting,
users can get a very wrong view of what 1 UL will get them.
(They think they are getting 90:1, when they are getting 5:1, or
vice-versa.  A big difference.)

I'd like to see it:
 1)  If in a subboard, show that current subboard ratios.
 2)  If elsewhere, show ratio-set #1.

--261--

CURRENT>              **** OLM from John D (port 3)
I'M SPECIAL!>         **** OLM from John D (port 3 to port 4)
IT'S JUST A BULK OLM> **** OLM from John D (port 3 to all ports)
'nough said.

--262--

Marking-files > download-credits is a very good feature.  All BBSes
should do it.  Saving marked files from call-to-call is brilliant.
But on those times when you wish to D/L things on THIS call...

 > CRedits
1>                    Files     Bytes
2> -------------- ---------  --------
3> Your uploads  :        8    2024 K
4> Your downloads:       66   17365 K
5> Default ratios:      n/a       4:1
6> Your credits  : no limit   1983694
7> Usable today  :       21   1183214
8> Marked        :        9    983694  (Only shows if files are marked)
9> Remaining     :       11    199520  (Only shows if files are marked)

If you want to know how many more files you should mark (if you want
to D/L them on this call, NOT saved for the next).  (Especially
important on multi-disk set D/Ls.)

Currently we have to "SS", write down the files/bytes totals.
Do a "CR", and do the math on paper or calculator.
(It's pointless anyway, CR seems to NOT show the CURRENT subboard ratio set.)
Instead, let the BBS do the work.  (Line #7-#8=#9)

Heck, if their "marked files" are > "usable today", you could even
tell them how many/much they need to U/L (at the current subb ratio)
to fulfill the requirements.

If line #9 was <0, if would change from:
9> Remaining     :        11       199520
into
9> ULs needed    :         2        39220

In a related matter, "SS" would mark with a "*" those files that
won't get D/Led on this call:

1. ShareWare1.dms             398326
2. ShareWare2.dms             390492
3. ShareWare3.dms             698212
4. ShareWare4.dms             190932*
5. ShareWare5.dms             290393*
(* saved for next call)

Currently we have to do a "CR", write down the totals.  Do a "SS" and
add-up a continuous running total to see at which point in the file-
list the system will not D/L any more.  (Strangely, it seems to D/L
from the list in reverse order, too.)

--263--

BBSMENU proposal...
>   WHO                !rexx:MyCode.rexx
For each menu choice you can specify an optional "Arexx Verification-
Script (AVS)".  As always, they are specified by their full path and
filename which allows you to place them anywhere on your harddrive or
ramdisk.  The same AVS can be used for multiple menu cmds or you can
specify different AVSs for each menu cmd offered to your callers.

When a user attempts to execute a certain menu cmd, first the AVS
is executed.  It's a short, simple Arexx script that always returns
either 1 or 0.  If it returns 0, then the caller can NOT execute the
chosen menu cmd.  If the AVS returns a 1, then the caller CAN execute
the chosen menu cmd.  Your AVS can also display some text explaining
to the user exactly why that cmd is/isn't available to him at the
current time.

Your AVS can contain an unlimited number of criteria that must be met
before the caller is allowed to execute that chosen menu cmd.  A few
suggestions are listed below.
o) The caller's min/max access level.
   (Just like the 'old' BBS do.)
o) Check how many users are currently online.
   (Certain "high-CPU usage" cmds can be limited to certain users.)
   (Or certain multi-player games that require 2 or more callers
   online simultaneously.  Unlimited real-time possibilities.)
o) Check the caller's area code and/or zip code.
   (Caller's from the other side of the country aren't really
   going to need to know about the exact date/time of your
   local user-group meetings and other such "local info" menus.)
o) Check the current date.
   (Certain cmds can be limited only to certain days of the week.)
o) Check the current time.
   (Certain cmds can be limited only to certain peak or off-peak times.)
   ('Fixed' or in 'real-time' as determined by date/time of last caller.)
o) Check the user's age.
   (Certain adult-access cmds can be limited to certain min/max age groups.)
o) Check the user's bps.
o) Check # or size of U/Ls or D/Ls made.
o) Require passworded cmds.

So instead of specifing just a min-max access range, you can do things
like:  
This menu cmd can be executed only on Mon's, Wed's, Fri's between 7pm-
9am or 2am-6am, and 4pm-11pm on Sat's, and all day every 3rd Sun.  But
only if <6 callers are online, 2 or less which are >2400bps, none can
be 14400.  But not if the caller is in the same zipcode as your BBS.
And he must be over 18 if he's from MI, CN, MA, FL, CA, or over 21 if
from AL, PA, TN, KY, and have access to msg areas 3, 7, 11 or 23, 34
and 44.  But only if his access level is between 1-5 or 7 or 10 or
more.  If he's made less than 10 calls to the system, he must have
made at least 4 U/Ls totaling at least 63k, but not more and 231k and
the most recent one being within the last 55 days.  If >10 calls, at
least 9 U/Ls @ 983k bytes are required.  And there must be at least 1
other node currently open to accept new callers.

Needless to say, you are limited only to your imaginations.  I know of
no other Amiga BBS, written to date, that has this powerful, but
simple, flexibility.

--264--

Ctrl Panel, USERINFO window...
>  Up files: 3           Up bytes: 80
>Down files: 123       Down bytes: 9431

SYSINFO window...
> Least free on: UDBASE0: (2341 bytes)
>  Most free on: UDBASE7: (1093922 bytes)

All numerical output should be right-justified if you want columns to
align correctly.

Also, the 'byte counts' shown in USERINFO are really "Kilo byte"
counts.  (As they should be.)

--265--
> Is there a problem with using an overly-large stack size?      
Only if it causes you to run out of memory elsewhere.           
                                                                 
The Cnet executable could be made to check for its needed min   
stack size and exit safely if it can't get what it needs.
Ken would NEVER again have to read/answer msgs like #0.         
Users would NEVER again wonder if they had a stack size problem.

--266--
I would have wanted the timelocks to effect just the actual D/Ling
from that sub, instead.

I can understand the need to limit D/Ling, but currently, if you set
any area up with a timelock, it also forbids all MESSAGE reading,
POSTING, RESPONDING there, too.  Things that most SysOps try
desperately to encourage, not delay/discourage.

Overall, timelocks are open for great abuse by SysOps.  
Who wants try and save $$$ on your phonebill by:
   1)  Spending $500-$1000 for a hi-speed modem.
   2)  Wait until the wee hrs of the morning when rates are lower.
Only to see "Sit and wait 10 mins before you can access that sub?"

I still think timelocks should be available, but SysOps should use
them with the greatest of care.

--267--
> Wants Auto-Dialer built-in or via arexx...
> But I don't think adding an Arexx port is asking to much...

Cnet already has an arexx port.  Usable online & offline.
Maybe add a new call that would activate any of the pulldown menu
functions of the control-panel and node-screens.
 
Then just 2 added functions ctrlPan() and nodeMenu() would get us:
1)  Pop the cancel panel in/out of icon mode.
2)  Chat avail on/off
3)  Close UD, close Pfiles, (or re-open)
4)  Open close userinfo/sysinfo windows
5)  All the other menus

1) Log-on
2)  Add input to stream cmds.
3)  Log-off
4)  Enter Term mode (heres your full u-write-it auto-dialer)
5)  Open/close/save/print buffers  (Open buffer, run something, close,
    mail me the buffer)
6)  Open/close window/screens.
7)  Set color depth, workbench, interlace screens.
8)  Automated Join-Links
9)  Term can UL and DL, change baud, etc.

Quite a bit of power, with just 2 new arexx calls.
'ctrlPan'  0x0004 I
'nodeMenu' 0x0004 T
      Qualifier-key + menu-keyStroke

Nearly all of the above can NOT currently be done at all (under
software control).

--268--
Just wondering, why do i see so many sysops that hate users dropping
the carrier instead of loggin out correctly?  Paragon/Starnet had   
bugs in it that would cause trouble if you did that.                
But Cnet doesn't seem to mind at all.                               
The worse thing that any good, solid BBS software should experience 
would be that the 1 caller doesn't get his last-things-done         
pointers saved to disk.  (But even that is only damaging to that      
1 caller.)

--269--
> --- version 2.27  25-August-1992
> 98. If you run FIDO, you must delete the "max items" lines from your
>  BBSFIDO files (if you run the 2.27 versions of the FIDO programs!)
Which line is this?
This 1?
> 400   ; Max Items/List     (must match BBSconfig)

If so, it's still in the v2.30 cnet:BBSfido file (datestamp 13Sep92).

--270--
Should EL's "QWK reply upload sub?" be markable Yes/No?
Doesn't seem to be.

--271--
Check into YA's PREVIEW option.  I could list several things that        
would make PREVIEW a smarter PREVIEW.  When is this most annoying?       
I read response #47, I add my reply #48, after saving, I have to         
re-read MY #48.  When I call back tomorrow, if new responses have        
been made, I have to re-read MY #48 AGAIN!  I wrote it.  Do i need       
to read it twice?  (I don't know if yanking would make it a 3rd read.)   
                                                                         
Or annoying when the previous response is excessively long.              
Re-read 100 lines again, just because someone responded to it with "Thank
you".  Maybe just preview the last x lines of the previous msg.          
Maybe NEVER preview YOUR posts.  Maybe NEVER preview if you just         
posted your response 1sec ago.

PREVIEW is a very good way to remind the user about the current
discussion.  But when it starts getting in the way, instead of helping out...

--272--
Ken, is there a function I can call within Cnet that works like:
> BOOL ExpandMCI(struct UserData *info, BYTE *in, BYTE *out);
to do MCI code expansion for me?

--273--
>New "Alias cmds" feature...
You'd only need run an English based system.  Callers could alias
cmds into their own language as they see fit.

I'm tempted to ask for a lot more than 5-10 of these.
Maybe just have a global BBSconfig option.  SysOps could set whatever
max they'd want based on mem/disk availability.  (I'd set mine
extremely high, 50 or so, per user.)

It would be interesting to scan all the aliased cmds of all callers.
If 900 people feel that my file-area cmd should be [F]ile instead
of [U]Dbase, maybe it's time to make that my default in BBSmenu.

Tell all your callers, if you don't like the menu choices here, just
make-up your own.  It's Cnet!

--274--
> EP;16
> 16) Edit CMDS ALIASES
Instead of limited the allowed aliases to a certain max.
Or wasting large amounts of disk space giving everyone a fixed
BYTE cmd_alias[10][50] type limit.  Maybe just have choice
#16 run the online editor and allow users to:
> MYCMD     "BBSCMD $1 MESS $2"
> USERS     "WHO"
> MYNEWCMD  "BBSCMD $1 MESS $2"
> MAIL      "MS$1!"

User's could make as many aliases as their mail:user-dir size
max would allow.

Those callers wanting only a few (or none) save disk space.

--275--
1) Powerful write-file-description-later features.
2) Powerful ranging features.  (#s or keywords)
3) But they don't always work together.

> (17) Images>  W 1-9 (or...)
> (17) Images>  W BYME
> This item already has a description!
> This item already has a description!
> This item already has a description!
> This item already has a description!
> This item already has a description!
> Please enter a short description for this file.

Please mention the filename so we know which one we are being asked
to [W]rite for:
> Please enter a short description for "MyFileName.LHA".

--276--

If I try to JOIN an invite-only subboard, the system correctly
shows, "Sorry, you have not been invited to that subboard.", but
then marks this sub as 1 of my default areas with "+" any way.

--277--
>12 message(s) saved in mbox.
>12 message(s) @ 5k saved in mbox.  Room for 4k more.
Normally, I wouldn't ask for such a luxury-item (OK, OK, yes I would)
but since as long as your mbox is full you'll never get any more mail
at all, isn't "available room left" pretty important?

--278--
Usenet support.  Very good to hear.  Ken, I know you are only 1 person,
and there's only so many hrs in a day, and we all have interests/      
obligations (to ourselves and others) outside our computers, keep      
update the good (non-IBM) work.

--279--
Someone with vote-topic-add access should add:
1)  Do you feel the Amiga version of Cnet with suffer in the
    areas of updates/bug-fixes/support after Ken starts working
    on an IBM version?

a)  Not at all.
b)  Very little.
c)  Somewhat.
d)  Greatly.
e)  Entirely.

Be some interesting results.

I'd have to vote "D", myself.  But I hope I'm very, very wrong.

--280--
Would anyone (other than me) like to see the AG (both SYSINFO &
online) have the bar that represents the current time, in a different
color (SYSINFO), or use different "*" char (online)?  I always have to
check the current time to see "where in the graph are we right now?".

--281--
>going 2.0 only is rather drastic...
Even when no one has any idea on how many 1.3 VS 2.0 cnets are running?
What if 95% are already running WB 2.0?

>At least this early...
CBM officially released WB 2.04 on 01-Oct-91.  So it'll already be
a year old this Thursday.  User's were running 2.03 2.02 2.01 long,
long before that.  This isn't a new developement.

>But get fido finished, UUCP, and other things
> you have mentioned.
Even if REMOVING all the WB1.3 support code makes adding these new
features faster/simpler for Ken?

I would hate to have to add/write a large piece of code to make
something remain WB1.3 compatible when:
1)  A very small % of the users are running 1.3.
2)  The same thing could be added for WB2.0 support with many
    of the new features built-into WB2.0.
3)  And here's the biggy:  TEAR OUT ALL THAT WB1.3 CODE THAT YOU JUST WROTE,
    ALL THAT WORK AND TOSS IT OUT, when Cnet does go WB2.0 only.
    (Very soon, maybe.)

--282--

New proposed BBSCONFIG option:
1  <- Mail all error msgs to this acct.  0=no one, 1=SysOp, n=acct #n
Then all error msgs generated by Cnet would also be carbon-copied mailed
to that acct #.

> NOTE: can not find "UDBase20:11.1/"
> Refused U/L to area x, partition has < min-space allowed for new U/Ls.
> TEST FAILED:    UDBase0:SWHQ/MyCode4.dms
> ID tried/failed by ...
> Wrong password attempted/failed by ...
> Missing sys.menu/sys.help/gfiles/pfiles/nfiles files (full paths, please)
> Etc...

1) We wouldn't have to search logs for them.
   (Cnet doesn't even log some of them.  Please add!)
2) We wouldn't have to beg users to inform us when they see these
   error msgs. (Callers don't always take/have the time & $$$ to do so.
   Nor should they have to.)
3) We wouldn't have to catch error msgs only if we are sitting right
   here watching a opened-screen (many aren't) user's session.

We'd just log-in under acct #1 (or a specifically created "Mr. Errors"
acct #n) and all our waiting mail would inform us of all recent errors/
problems with the system.

>4 Tue 29-Sep-1992  8:21p Sysop                System Error Msg
>
> item: 4 (of 4)
> subj: System Error Msg
> from: System
> on  : Tue 29-Sep-1992  8:21p
>
>  On 29-Sep-92 8:23pm...
>  The system could not find Pfile:MyDir/MyCode.

I've mentioned to a few Cnet SysOps that I saw a "file sys. missing"
or "Can't find UDBASE20:" msg and they thanked me and said they had
been running like that for months and never even knew about it.  It
would also help cut down on the # of non-bug-need-help posts online
here.

Yes, error msgs *are* that important to us.  And as 4-12 line,
100 UDbase, 1000 Fidonet area, 5000 UUCP area, 20,000 file, systems
continue to grow, they become more important than ever.

--283--

Am I correct in assuming Fidonet currently works like:
1) Convert cnet-type msg into fidonet-type. (1000s of files.)
2) Convert them into individual fidonet-type msgs.  (1000s of files.)
3) Bundle the fidonet-type msgs into packets.
4) Send the packets out.
Any way to go right from #1 to #3, skipping the intermediate step
entirely?  (Saving time, disk space and fragmentation.)

Is this 4 step method also planned for UUCP?  Going 1-3-4 would still
allow Cnet's own custom msg format to be used online.

--284--

SCAN GLOBAL FIRST doesn't list just the 1st item.
SCAN GLOBAL LAST doesn't list just the last item.
I was hoping to just take a quick look at the 1 newest post in
each subboard.  (With my ORder set correctly.)

And also use it as:
BROWSE GLOBAL LAST, to have a global, interactive [D]rop feature,
on my 1st call to a new system.

--285--

Search/scan range specifiers...
I didn't see it mentioned any where, but I take it that GLOBAL
must always be the 1st specifier?  Could it be allowed anywhere on
the input line?

Can the 25 range-specifiers also be allowed to be abbreviated?
SCAN GLOBAL FREE     (SCA GL FR)  (S G FR)
SCAN GLOBAL FAVORITE (SCA GL FA)  (S G FA)
The user would only need to the 1st x chars (enough to distinguish
them from the other specifiers.)  (This is already available other
places online, but not here.)

Some of these can get pretty long to type over and over again online.
And a sysop can only BBSMENU-alias so many or the 1000s of possible
combos.

--286--

Is there a limit on the # of Yank bundles I can have before D/Ling
them?  If I do a YANK of 1 area, and later try to do another, Yank
still reports OK, but I didn't yank anything (and can't until I clear/
download my old yank bundle.)  I am nowhere near my max-#-of-msgs-
yankable.  And nowhere near my max-marked-file limit.

I can understand limiting the amount of diskspace these bundles take.
But not an unconfiguratable limit.  And certainly not a limit of 1 max.

BBSCONFIG...
5    <- Max # of yanked bundles at 1 time per user.

Or better yet, and much more space-accurate (the whole point):
100K <-Max total size of yanked bundles at 1 time per user.

And YANK always needs to OLM success/fail info correctly.

--287--

I sure hope PUBLIC-SCREENS are 1 of the 1st things that are added
for WB2.0-only support.  You can open shells, editors, help windows,
etc right on the specified Cnet screen, referenced by screen name.
CLI> NEWSHELL CON:0/0/640/20/WindowName/CLOSE/SCREENCNET1
CLI> Run Ed t:tmp WINDOW CON:////Ed/CLOSE/SCREENCNET2

--288--

GLOBAL SCAN, BROWSE, SEARCH, etc only scan my currently selected areas
(as they should).  If I'm trying to find something that may or may not
be in those areas (Hey, if I knew where it was, I wouldn't be
searching for it), is there an option that can override this?

It just isn't feasable to try and write/down 100 sub-sub-sub base
names/#s, join all my dropped ones (ugh), do the search, then re-drop
the 100 (ugh).

It would be used/work similar to the GLOBAL modifier but
searching ALL subboards, whether JOINED or DROPPED.

1) SCAN JOINED         (Just like GLOBAL, does now.)
2) SCAN DROPPED        (Only search the dropped boards.)
3) SCAN JOINED DROPPED (Search both)

(Ken would really just need to add "DROPPED" to make all 3 possible.)

This new specifier would also be of great use to SysOps.
They could have their accts setup to their desired joined/dropped
areas but still do things like:
> SCAN JOINED DROPPED UNVAL
to find unvalidated files everywhere.

--289--
> Yeah, i noticed that too... I liked it better the old way when it was    
> quicker. Now i see my users just slapping return waiting for their OLM's.
                                                                            
Nothing at all in the README file stating this was changed in any way.      
                                                                            
Ken, please mention ALL changes.  Its the only way we can check things      
for bugs.  And even if not buggy, we still need to know of things           
that are now working very differently than before.                                      
                                                                            
README 2 secs of work> "OLM were changed".

--290--
R>  Ken, any thought to having the standard Amiga-X key combo clear the field
R>  if at the local console? I hate backspacing/deleting...                  
It's really annoying to backspace/delete when the field you are editing     
is only 1 char wide anyway.                                                 
ORDER                                                                       
2 BACKSPACE 3                                                               
You'd think just hitting "3" would do it.                                   
No real heavy Amiga-X, left cursor, right cursor editing needed             
on 1 char max fields.

--291--
R>  I use &0WH to run the BBS Who command... works for me.. the number doesn't
R>  seem to do anything that I noticed..                                     
I hope you are right.  I'd hate to find out later that                      
"0" does something very different than 1,2,3,4.  (ie allow                  
sysop maintenance cmds or other dangerous stuff.)                           
                                                                            
Either way, it definitely needs to be documented.

--292--
Optional MUFFLE reason...
> MUFFLE
> Port, handle, or *=ALL? 3
> Reason (optional): "Can't chat right now.  Long distance call!"

Users trying to CC you won't get:
> "You may not send an OLM to that port."
(Some SysOps have this string worded rather "strongly".)
> "You are being muffled."
> "He doesn't want to chat with you."

Would now become your custom:
> "Can't chat right now.  Long distance call!"

--293--
If you CC to request a chat with any/all ports (*), you also
send your request to yourself.  (Not really necessary.)

--294--
Any plans on having the scroll-gadget on the control panel do its
scrolling of visible node in real-time.  (Not just when you release it.)

--295--
In the status window, the "CO" computer type displays the 1st 5 chars
of the computer type name.  What are the remaining 6 numbers?  I can't
find it mentioned in the manual nor in all the README's issued since
v2.08.

--296--
DM> Bill we have gone thru this once before on the BBS and it was the general
DM> concensus that we wished to keep C-net style message bases.. Now to go
DM> straight from the C-Net messages to a fido compatiable message, we would
DM> have to have our message bases set up as they are on DLG on other BBS
DM> packages with .msg format.  This would in essence do away with the

BA> Am I correct in assuming Fidonet currently works like:
BA> 1) Convert cnet-type msg into fidonet-type. (1000s of files.)
BA> 2) Convert them into individual fidonet-type msgs.  (1000s of files.)
BA> 3) Bundle the fidonet-type msgs into packets.
BA> 4) Send the packets out.
BA> Any way to go right from #1 to #3, skipping the intermediate step
BA> entirely?  (Saving time, disk space and fragmentation.)

BA> Going 1-3-4 would still
BA> allow Cnet's own custom msg format to be used online.
 
Don, thanks for responding.  I'm having a great deal of trouble
getting anyone (including Ken) to even comment (let alone answer
questions) on all this stuff.

I'm still fairly new to Cnet, compared to you old timers.  

I too like the additional info and (currently and future) possibilities
available with the Cnet style format, not available in Fidonet/UUCP
style format.

But why would:
BA> 1) Convert cnet-type msg into fidonet-type.
BA> 3) Bundle the fidonet-type msgs into packets.
BA> 4) Send the packets out.
(Skipping #2)
prevent Cnet style msgs from being used online?
(My 1-2-3-4 step list is NOT a request to change any formats of
anything.  Just change the capabilities of xfido/ifido prgs.
When we are talking about 1000s of Fidonet msgs, and 10000s of
UUCP posts, skipping step #2 could be very significant.)

--297--
There were apparently a lot more changes made to v2.30 than ever got     
mentioned in the README file.  I guess we won't find them all until
we sit here and execute & test every feature new and old.  (I wish 
I had the time for the "treasure-hunt" method.)                    
(And I'm sure we'll still miss a few.)                             
                                                                   
Perhaps 1 of the beta-testers will list ****ALL**** the changes    
made to v2.30 for us.

--298--
Use another port to dial-out once online.  An incredible feature.  A
flag to limit (YES/NO only) who does/doesn't have access to this
feature, just can't cut it with something this powerful.  We need to
limit what phone #s are called.

The filename convention would be the same one used by BBSCHARGES:
SysText:BBStermX.A
SysText:BBSterm1.0
SysText:BBSterm2.23
X is the BBSEVENT shedule #.
A is the user's access level.

The contents of these files could follow the SYS.AVALID file format:
AREACODE   DIALCODE  PREFIX-RANGE    NAME OF BBS or COMMENT
313                    9811524    Cnet HQ BBS
313           -        421-456    (Users can dial-out to these exchanges.)
619         1-619      5551234    (Users can only dial these #s.)
("?" would show users a list of their possible dialing # choices.)

BBSEVENT would also need a matching TERM cmd so we could
specify date/time periods (Weekend or low PM phone rates, etc.)

BBSEVENT ARGS would list the only ports that could be used as dialouts
(ie 2,4-5,8).  So we could limit it to a certain bps max line, as well
as limit the # of callers that would be dialing-out at any 1 time.

I think if you took a VOTE to find out how many SysOps have given TERM
privileges to their users, you'd find very, very low #s.  What a waste
of a great, powerful feature.  We can't control what #s are dialed
out.  (You are basically giving someone full access to place calls
anywhere in the world on your phone bill.)  (User's can even pester
VOICE #s by dialing them now.)

Yes/No access flags are great, but TERM-access needs the same power
that Cnet already has in netmail-sends, call-back validation, etc.
Namely, controlling WHERE these calls can go.
Without it, I can only grant TERM-access to 1 of my 2500 users.
Me.

--299--
> long  Hours;             /* 190 restricted entry hours */
> long  HourUnionFlags;    /* 194 */
> long  HourAccess;        /* 198 groups which may Enter during Hours */
I can set hours, I can set the groups those hours effect, but what
are "union" flags?

(I'm working on my 6th "not-able-to-finish due-to-no-docs" pfile.)

--300--
Is there a string in BBSTEXT that gets displayed if no new vote
topics are found?  (Which happens pretty often.)

My log-in checks for new vote topics and new mail.  User's are just
going to be confused when they see:
> Checking Voting booth...
> You don't have any messages.

Or:
> Checking Voting booth...
> There have been no new uploads.

Or:
> Checking Voting booth...
> Jumps right to new msgs/files/mail/fortune/this date in history/etc.

Should be:
> Checking Voting booth...
> "No new vote topics." or "New vote topics found."
> Then on to show new msgs/files/mail/fortune/this date in history/etc.

*** EOF 313-473-2020 Bill Beogelein 1:2410/207 ***


