
Monday 25-Jan-93 04:27:56

--600--

We already can control who has access to MCI levels 1,2,3.
But until we can control WHAT MCI codes fall into those groups, we
will always be faced with this problem.

As SysOp, my 'solution' is to forbid ALL MCI codes from ALL users.
What a waste of a very powerful feature.

If you want to let them display some bold text, you also have to
let them CLEAR SCREENS in every one of their msgs.

If you want to let them display a system variable, you also have
let them stick 10 /WAIT 9 secs (90secs) in msgs.

If you want to let them disable word-wrap, you also have to let
them stick 10 /BELL9 cmds (90 bells) in msgs.

Any time you want to give users the power to run one MCI code,
you also have to give them 5-20 others too.

Here's something I sent Ken back in Aug 1992.  No comment from
him about it yet.

We'd all go nuts trying to agree on which MCI levels did what unless...
An MCI.cfg file could tell which MCI levels had access to which codes:
>Format:  <MCI LEVEL>  <THESE MCI CODES ALLOWED>
0
1   A C D G H K
2   A C D G H K L Z R S T
3   A C D G H K L Z R S T B E F I
4   A C D G H K L Z R S T B E F I J M N P
5   A C D G H K L Z R S T B E F I J M N P Q W V X
This does NOT reflect how I'd have mine set-up.  But you see the
unlimited possibilities.
1)  5 levels instead of 3.
    (You could actually do 0-255 with the same method.)
2)  Divide them up any way YOU want.

And it gets even worse with all the new powers in the new MCI codes.

I'm NOT saying Ken designated the MCI 1,2,3 groups poorly, it's just
that there's a million different ways it could have been done, and we
can only use 1 of them.  The default.

Do I think it's worth all this extra work?  For a fully user usable MCI?
YES!!!!

(This was added to CNet v2.60/R2, BBSTEXT lines 4-5.  THANKS!)

--601--
TK> Whats the difference between the amaint commands DOS CMD and RUNDOS?
TK> Or are they the same command but one was accidentally left in there
TK> when the config program changed?
I think RUNDOS was called RUND in the ReadMe.
RUND displays its output to the current port.

I think "DOS CMD" was called DOS in the manual.
Which executes the cmd.  Nothing is said of its output, but I assume
it goes to NIL:.

Which do you like better:
1)  Renaming cmds and not documenting it.
2)  Keep the same cmds and not documenting them.
(I'm sorry Ken.  I'm in a bad mood today.  It won't happen again.)

TK> Also, I noticed that ALOGON was dropped from the amaint commands.
TK> Anyone know why?
I have it in v2.42e as #9.

--602--
I've never like any software that handles defaults like that.
(Backspace 1-10 times before you can even start entering text.)

I like the style CNet uses elsewhere:
CNet> Computer type ([0]):
[RETURN] always gets the bracketed default.  Or enter what you what.

Sort "ORder" is another place this would be better.
(In VDE too.)

Consistency, Consistency, Consistency.

--603--
Don M> It seems that Bill Allen has found yet another way to annoy the hell
Don M> out of some of us, namely by being allowed the ability to add vote
Don M> topics on Future World when the urge so strikes him..
Don M> Which of the following best suits your opinon as to Bill having
Don M> continued access to post vote topics when he so wishes??
Don M>      #:Possible answers
Don M>      1:Don't allow Bill to add Vote Topic
Don M>      2:Allow any idiot to put up a vote..
Don M>      3:I just love Bill Allen's votes..
Don M>      4:It doesn't matter..

Bahahabahahbhahbahbahbahb.
I'm Famous!!!!     I'm Famous!!!!
Don, you're a hoot.

As always, Ken is free to cut-off my vote access, CNet sub access,
update access, and even delete my account.  But I doubt it will
ever come down to that.

--604--
Don, what do you think of this idea?  Would you be in favor of it?
Use it?  You could skip any/all items you didn't like.  You'd never
even know certain folks were calling here.  They would become totally
transparent to you.  I think this will become more and more necessary
as systems grow larger and more crowded and some folks just can't play
together nice.

"Twit" filters like those available on big UNIX BBSes.
(To skip stuff you don't care to read, or that is usually just too
long to read.  Or you could even skip your own posts, since you
already know what they say.)

CNet> "EP"
CNet> 15) Edit MACROS                16) Configure USER filters

CNet> Enter upto 10 IDs each.
CNet> [1] Skip items posted by user IDs    : 23,456,122,31,2
CNet> [2] Skip files uploaded by user IDs  : 3,87,21,5-10
CNet> [3] Skip responses posted by user IDs: 98,372,763,12
CNet> [4] These users can't send you mail  : 2,4,6,123,4
CNet> [5] These users can't OLM you        : 34,567,12,2-30

Oh, by the way, my user ID here is 367.

--605--
Ken, is the Arexx cmd 'SendFile' prepending an extra linefeed onto
the top of every file it displays?

I'm trying to do something like this:
Arexx> 'Transmit' "(------ CUT HERE -------)"
Arexx> 'SendFile' filename
Arexx> 'Transmit' "(------ CUT HERE -------)"

But it always gives:
CNet> (------- CUT HERE -------)
CNet>                                     (Extra line feed here.)
CNet> Line #1
CNet> Line #2
CNet> Line #3
CNet> Line #4
CNet> (------- CUT HERE -------)

If you could remove it and have 'sendfile' just send-file, it would be
greatly appreciated.

Of course, those wanting an extra LF could always add 1 themselves.
But those not, have no way to remove it.
So the default output of 'sendfile' should be 'as-is'.  (Making both
groups of users happy.)

--606--
From within Arexx, what is the 100% sure-fire way to tell if
the current user is the SysOp?

1) Check for acct #1?
2) Check for ID   #1?
3) Check for level 23?
4) Check for name "SysOp"?
5) Check for handle "SysOp"?

I've been making my arexx scripts offer additional cmds to anyone
having BOTH #1 and #2.  Is this the best, 100% guaranteed method?
Now and in the future?

--607--
Is anyone familiar with all those telecomm/networking CNet *HARDWARE*
products I see advertised in IBM magazines?  What are they?  Will
naming conflicts someday pose a copyright problem?  (For them or Ken.)

--608--
FIND is great.  FIND is very fast.  But it doesn't tell you the # of
the file or the # of the sub they are located in.  So you know they
are online some place.  But have to go and look for them anyways.

I think FIND should not only tell you where, but put-up a READ-type
display, not its current brief, SCAN-type display.

If fact the info shown is even briefer than SCAN's.  (And remember,
this is for files that I'm specifically trying to locate.)

I was hoping the index-pointer file would NOT need to be increased
in size to do this.
(Keep it small and fast.)
But would just point to the file's full data and it could be displayed.

Doesn't the index-pointer file just contain.
1)  The full name
2)  The short description
3)  A pointer to find the actually file data

>AreaCode.LHA              8K  Amiga Disk Utilities
>                              Tells City for Area Code entered. visa-versa
>                              too!
>AreaCode.lzh             15K  Amiga Disk Utilities
>                              Areacode<-->city converter v1.24 14Dec92
>                              Please delete all older versions.

>Amiga Disk Utilities (1;4;3) (<--- How do I get there?)
>1 25-Jan   0 AreaCode   LZH  15K Areacode -- city converter v1.24 14Dec92
>                                 Please delete all older versions.
>9  7-Jan   4 AreaCode   LHA   8K Tells City for Area Code entered. visa-versa
>                                 too!
 ^
 |
 |
 Which files #?

Many large systems (the 1s where you really do need a good FIND) have
several "Picture Dirs", so telling me it's in a "Picture Dir", doesn't
tell me much.  (Which 1?  IBM's, Atari's, Amiga's, CBM's?)

Even if EVERY sub has a unique name.  How do you find the 1 you are
looking for if it's in a sub/sub/sub/subdir?

I'll even settle for showing the physical sub # (if we have a quick
way to jump to it) instead of "(1;4;3)" #-paths.

Or should FIND just kick you into the BROWSE-mode, where you could Read/
Examine/Quit-at-this-dir/Etc?

E> > I think the best solution would be to prompt the user with:
E> >
E> > Select this file (yes)?
E>       Ahhh.. Yes..   After using "FIND" this would be great, allow us the
E> option of selecting the file then and there...

Or the ever popular, ever familiar:
CNet> Browse (*, Download, Read, Quit)>

--609--
Here's some text embedded into TrapDoor's executable.  It starts out...

TD> This program is a program. It is not a coffee-machine. It is
TD> neither a horse nor an elephant. It is simply a program. An Amiga
TD> program.
TD> Etc, etc, and etc...

Wouldn't you be asking questions like, "Is the author 12 years old?"?
Why make the executable even bigger than it already is with this stuff?

I could understand sticking text like this into small, useless
programs that are junk anyway.  But why do this to a powerful tool
like TrapDoor?  Doesn't the author wish his hard work to be taken
seriously?

Do you think Ken would hardcode text like this into CNet or its
other executables?  I would have never even given CNet a 2nd thought.

I'm not trying to trash TD.  The quote is taken word-for-word as
written by the author.  Thems the facts.

Some people are just too busy being CERTAIN that Bill was "cheap,
stupid and lazy".  And missed some of the many legitimate pro/con
reasons Bill has listed.

--610--
Don, I made the suggestion to Ken, to allow a date-offset for voting.
I'd gladly set 100% of my topics so NO ONE would 'have to vote' on
them.  (Nor even see them as 'new' during log-in.)

You'd never even have to know they were there.

--611--
Would anyone like to see item headers also show if (and when) the
item had been re-edited last?  Users can do a lot of changing after
their posts have been made.  Even to the extend of saying they never
said the things that they definitely DID post originally.

> item: 1
> subj: Headers
> from: Bill Beogelein
> on  : Tue 29-Dec-1992 02:18p (Wed 27-Jan-93 03:12a)
                ^                       ^
                |                       |
       Original post date       Last edited date

CNet already has a variable set aside for this.  It's just not displayed.

(It would only be displayed on re-edited stuff, so most posts
wouldn't even have their headers changed.)

--612--
Currently:
CNet> More responses. Respond, Pass or ENTER to continue

Would you base your decision to PASS or CONTINUE if you knew
how many more responses you had left to go?  I would.

CNet> 2 more responses. Respond, Pass or ENTER to continue

CNet> 121 more responses. Respond, Pass or ENTER to continue

I might skip down "a few" responses and pick-up reading there.

--613--
I was hoping FIND (either optionally or by default) could also search
the short file descriptions, in addition to the filenames.  (It
appears to only do the latter.)

"SG 'foo'" does this, but FIND is lighting-fast.
(I assume this is due MORE to FIND's index/search method used, and LESS
due to the fact that it is searching "just filename" instead of
"filename+descriptions".)

--614--
> 168.  By sacrificing one of the user-macros (control-G), a new field
> has been added to the user data.  The field will hold an optional
> "Organization" that the user wishes to be associated with.

I assume this sacrificing was done so that all the elements in the
structure wouldn't need to be 'shifted'?  ("Breaking" everything that
comes after the "insertion" point.)

Would it be possible to change:
> char Macro[4][36];    /* 4 user-defined macro keys */
into
> char padding[144]; /* Reserved for future expansion of ZipCode,
                        Country, PhoneNo, PassWord, Comments type vars */

And move:
> char Macro[4][36];    /* 4 user-defined macro keys */
to the end of the structure as:
> char Macro[8][36];    /* 8 user-defined macro keys */

Nothing would be 'shifted'.  And there would be 144 bytes of space
for future expansion.

I REALLY love the power of these macro-keys.  But they've dwindled
down two just 2.  (Are they going to dwindled to 0-1 someday?)

> char Macro[4][36];    /* User-defined macro keys */
Or, better yet, can you just set aside the curent 144 bytes (or
whatever) and let the user use the space as he sees fit.
>  3 macros, upto 48 chars each.
>  4 macros, upto 36 chars each.
>  6 macros, upto 24 chars each.
>  8 macros, upto 18 chars each.
> 10 macros, upto 14 chars each.
> 12 macros, upto 12 chars each.
> 24 macros, upto  6 chars each.
(Or any count*size thats <=144.  Mix, some short, some long.)
All with NO addition size added to the current structure.

I'd use 15-20 very short 5-10 character macros myself.
(I don't think too many users are using the current 36 char long ones.)

When defining them (EP), the user could pick the macro-key used, as
well as the macro to display.
CNet> Enter macro-key: A
CNet> Enter text to display when "A" is hit:  MY;A;MACRO`
CNet> Enter macro-key: T
CNet> Enter text to display when "T" is hit:  MY;T;MACRO

^E (or whatever) would then call-up a macro-menu instead of macro itself.
CNet> [A] MY;A;MACRO`
CNet> [T] MY;T;MACRO
CNet> [V] MY;V;MACRO`
CNet> [X] MY;X;MACRO
A hot-key response puts the corresponding macro into the input stream.

Whatever is done, I'd sure like to see 5-10, or even 4, instead of 2
handy macros.

--615--
How about cover ALL possibilities?

1)  Entering "D" only, gets you:
CNet> Enter filename or number [16. CURRENT.LHA] :
2)  You can still choose a different file.
3)  No need to backspace 8-30 times to erase it.
4)  Enter by filename.
5)  Enter by file #.
6)  [RETURN] gets you the current file by default.
7)  The user is shown the filename and # in the prompt.
8)  D! skips the prompt.

9)  or, of course, entering "D34" would get you file #34 without any prompt.

Am I missing any possibilities?  (And nothing really BIG is changed
from the way we are all used to now.)

--616--
Regarding my early suggestions about fully automating JOINLINK via EVENTS...

BA> 1)  Control which #s are dialed.  (Namely, #s that are local calls.)
BA> 2)  Limit which port (or ports) are used.
BA> 3)  Limit the date/time periods that sessions are run.
BA> 4)  Min # of idle lines must exist before a session is allowed.

As long as I could do all of the above via EVENTS, I'd even be tempted
to give some (or all) of my USERS the ability to start their own
JOINLINK sessions.  As long as I can control the above 4 things, what
could it hurt?

--617--

AK> after the upload. At the same time, I have the idle timer set to three
AK> minutes. The LHA testing took longer than three minutes and thud dumped
Is there a way to do this (some times lengthy) testing as a background
task?  Mail or OLM the user the results?  Perhaps only on all
files >x Kbytes long?  *200* secs is a LONG time to sit and wait as your
'reward' for taking the time to UL.

And, No, turning off all testing isn't a solution.
The files do have to be tested sooner or later (the sooner the better),
but the Amiga m-u-l-t-i-t-a-s-k-s.

CONFIG> Background TEst files more than: _________

0 (K) would Background TEst them all.
99999 (K) would always make the user wait.
300 (K) would be about a reasonable setting.

DS> BA> And, No, turning off all testing isn't a solution.
DS> BA> The files do have to be tested sooner or later (the sooner the
DS> better),
DS> BA> but the Amiga m-u-l-t-i-t-a-s-k-s.

DS> Try turning off the testing after a upload.  The file will be tested
DS> during
DS> AMaint.  If I called a board that made me wait to have a file tested I
DS> would
DS> never call it back.  Nothing worse then watching your phone bill increase
DS> and your hung there testing a file.

Like I said, that's not the real 'solution'.
1) Could take up to 24hrs before any files get tested.
   (Some systems get 100s of calls during that period.  Many people could
    DL (or want to DL) all these totally untested files.)
2) I'd rather test files, 1-by-1, as they are ULed, in the background.
   Instead of testing 50 of them all at once during amaint.
3) Why have TEsting at all, if you just have to turn it off?
I say, make it 'more real-world usable' instead of, 'Hey, don't use it'.

if ul_size > cfg_min
        'run' TEst
else
         TEst

That's all it would take, to REALLY make 'TEsting' fully usable.
CNet already has all the 'TEsting' code, all the 'OLM' code, all the
'mail-me' code, written & debugged, and already part of the executable.

S> If you had your way, BBSCONFIG would be over 1000 lines long! (Oh yeah...
S> it's got a lame window interface now... that makes it even worse. Figure
S> 200 screens of options to set. Just background ALL the TEsting and
Nope, not 1000 lines nor 200 screens.  In fact, NO new screens would have
to be added, there's plenty of room in the current ones.

S> Just background ALL the TEsting and
S> TRansforming. That way, the dude can go do something else, like download,
Kind of pointless to spawn a separate task to check a 10k file.
The "spawning, OLMing, Mailing" would probably take longer than the
test itself.

If Ken's in favor of the idea, but against the configing of it, then
hardcode it at 'background test only those files >100K'.
(Or what size would everyone suggestion?)

--618--
A cmd that would list the previous response would sure be handy from
the .QUOTE-prompt.  CNet could call the same function that it already
has/uses to [S]can from the "Respond or Pass" prompt.  So I hope
coding-work and executable size-increase would me minimal.

> Command:Quote
> [L]ist#-#, [A]dd#-#, [S]tep#-#, [R]esp#, [H]unt#-#, [Q]uit:  H3-

> 3 Don M             Analog Kid        Sun 24-Jan-1993  4:12a
> 4 Don M             Bill Allen        Sun 24-Jan-1993  4:16a
> 5 Bill Allen        Don M             Sun 24-Jan-1993  6:21a
> 6 Analog Kid                          Sun 24-Jan-1993 11:58a
> 7 Don M             Bill Allen        Tue 26-Jan-1993  1:09a
> 8 Don M             Analog Kid        Tue 26-Jan-1993  1:11a
> 9 Bill Allen        Don M             Tue 26-Jan-1993  7:30a

To see which [R]eplies you wish to quote from.
I just had to do a R1/List, R2/List, R3/List, R4/List ... R40/List...

The ability to quote from multi-msgs is great.  But I sure have
a long/hard time finding the things to multi-quote from.  Especially
as ever growing items get 20-200 responses.

--619--
Is there any room for a middle-ground between:

1)  Blindly fast, due to indexing and searching through less data,
    but it's limited to filename searches only.
2) Slow, because it's non-indexed, AND has to transverse the full data
    of all items.

(I'm guessing at how both works.  Please correct me where needed.)

3) Medium-fast, due to indexing (like #1) but searching filenames
   and descriptions-data only (NOT like #2).

We won't always know the exact filenames (or even close enough to
hit them via wildcarding).  But searching for a certain word in
in the filenames+descriptions can usually find what we need.

I'm never going to say FIND is 'overly' fast, but it does seem to come
up instantly.  Even if #3 DOUBLED the delay, it would be plenty fast.
(Don't change it, if its going to slow things down 20 fold.)

Or are options planned for FIND.  FIND in filenames (the default)
VS FIND in filenotes (optional).

--620--
T>         While I'm addressing you...I like MANY of your suggestions.
This is very good to hear.  But don't tell me, TELL KEN WHAT YOU LIKE,
DON'T LIKE!!!

You can't imagine (or maybe you can) what an opportunity you have here.
A BBS author that listens.
Try that with Paragon/Starnet.

T>         Are your suggestions being collected into a preservable media
T> for addition to CNet extending into the year 2000+?  You've a most
T> unique mind.  You run a large BBS, you program C and Arexx pfiles and
T> you still find time to generate ideas for Cnet...seemingly endlessly.
T> When do you sleep?

I have every single 1 in a file: KEN.LHA.  (619 comments, and counting.)
I originally tried to prevent non-CNetters from reading it.
But it's gotten out into the public community.  So, I'm not going to
fight it.  I hope MANY authors can benefit by it.  And may the best
BBS win.  (It can be just as important to know what to add the software,
as it is to know what to NOT add.  I hope Ken is skipping MUCH of my
ranting and ravings.)

>You've a most unique mind.
Have you been talking to my psychiatrist, again?

T> When do you sleep?
Sleep?  I'm not familiar with the word.

--621--
There's about 10 things that Ken could do to greatly limit the
# of ARexx/C-pfile/DOS-pfiles that break during updates.  I'd be
happy to list them, but I think he already knows what most of them
are.  If he hasn't seen fit to impliment them after 2-3 years of work,
I don't think he's interested.

This is the real solution.
1) PREVENT AND LIMIT BREAKAGE.
NOT
2) BREAK THINGS AND WORRY ABOUT WHO'S GOING TO WRITE THE CONVERSION TOOLS.
(But, unfortunately, this item is about #2, not #1.)

--622--
Ken, you are going to need some aspirins for this one.
So get ready.

Would anyone have any use for 1 (or more) of these elements in each
user's account?  You need NOT add "all or none" of them.

Even if CNet does ABSOLUTELY nothing with them right now, they'd
already be in place for future expansion.  (No need to keep 'breaking'
things.)

Even if CNet does ABSOLUTELY nothing with them EVER.  DOS, C, and
Arexx pfiles could still set/get the values and do wonders.  And with
no need to create/load/save tons of additional, separate data files
for each user.

 1)struct IsDate LastDL;      // Date/time of last DL this caller made
 2)struct IsDate LastPost;    // Date/time of last post this caller made
 3)struct IsDate LastReply;   // Date/time of last reply this caller made
 4)struct IsDate LastRead;    // Date/time of last msg read by caller
 5)struct IsDate LastUL;      // Date/time of last UL this caller made
 6)struct IsDate LockOutFrom; // User is locked-out from  this date/time
 7)struct IsDate LockOutTo;   // User is locked-out until this date/time
 8)struct IsDate NoDLsFrom;   // User can't DL from this date
 9)struct IsDate NoDLsUntil;  // User can't DL until this date
10)struct IsDate NoULsFrom;   // User can't UL from this date
11)struct IsDate NoULsUntil;  // User can't UL until this date
12)struct IsDate NoPostsFrom; // User can't post/reply from this date
13)struct IsDate NoPostsUntil;// User can't post/reply until this date
14)struct IsDate PaidStart;   // Paying member's account started
15)struct IsDate PaidEnd;     // Paying member's account will end
16)struct IsDate KillOn;      // Acct automatically deleted on this date

#1-5 could check for callers that haven't ULed files or READ msgs in x
days.  A simple arexx script could lower their access/time/ratios/etc
all automatically.  And raise it again afterwards.  Do things like "If
you UL every 30 days, you'll stay at level 10.  If you don't, you stay
at level 5."

#6-13 could also be used by arexx to 'suspend' a user's ability to
call/DL/UL/post FROM/TO a certain date.  "No DL's for 10 days because
you ULed junk."  "You can't post msgs for 5 days because of the
content of your last post.")  (Let's face it, if you delete an acct,
the user just creates another one tomorrow.  But 'suspension' would
let them know they can have their old access back if they behave for x
days.)

#6-13 could also work WITH 1-5.  Automatically 'suspend' for x days
because caller hasn't ULed in y days.  All via a small arexx script.

#14 would be for the 'optional pay systems' many SysOps run.  If
callers buy blocks of usage per month (or per year), #15 will keep
track of the 'ending-period', but if dues are renewed again and again,
you'll never know a true 'start-date' without #14.  ("This user is
paid thru Jan94.  But is this his 1st paid year or 9th?")

#15 already supported via EXPIRE.  (But doesn't track #14.  Ugh.)

#16 could set-up trial/demo accounts.  Automatically deleted after x
days.  (I think CNet can current raise/lower access levels with
EXPIRE.  But can it KILL too?  You can have a ton of trial/demo
accounts that are 'lingering' around, if you don't have KILL date/time
powers.)

#16 could work in #1-5, too.  "If a user hasn't ULed in x days,
his account will be gone in y days."

Of course, these arexx scripts could automatically mail (or display
text at log-in) the user mentioning these things.

> If you UL every 30 days, you'll stay at level 10.
> If you don't, you stay at level 5.

> You appear to be ULing every 0-4 days.
> The system just automatically raised your access to level 15.

> You can't post msgs for 5 days because of the content of your last post.

> No DL's for 10 days because you uploaded a duplicate file.

> Don't create another acct, you're full access and all credits will
> resume in 25 more days on 14-Feb-93.

> You can't access the system until 30-Jan-93 (7 more days) because you
> haven't ULed since 15-Apr-93 (198 days ago).

> Your acct is paid-up from 20Jan93 through 20Jan94.
> Thank you for your continued support from 20Jan88.

> This trial-account will automatically be deleted in 6 days (on 29Jan93).

> You haven't ULed in 231 days, if you continue, your account will be
> gone on 31Jan93.  (You have 6 more days to UL.)

As I've stated, most of the above can be done with CNet's current
arexx cmds or in C-pfiles.  You would need not expand CNet itself for
that.

But NONE of the above features can be done with you don't store the
variables that the arexx scripts will need.

--623--

Ken writes....
BB> Does anyone have a good game to upload for me to test?  One that USES raw
BB> i/o?
Did you find 1?

If not, here's a good, but simple test:
(This is under SAS v6.2)
C> #include <stdio.h>
C> main()
C> {
C>    char c;
C>    c=getch();
C> }
It'll get a correct hot-keyed response from the CLI.

When run from the pfile area online, as a DOS cmd, it just locks up
under CNet v2.42e.

If you've already got this working under newer releases, THAT'S GREAT!

--624--
Now that CNet is tracking 'best CPS', you could even compare your CPS
to CNet's 'best'.

After each batch DL, you could see:

CNet> FileName1.LHA 1823CPS,  91% efficiency,  88% of best rating.
CNet> FileName2.LHA 1782CPS,  94% efficiency,  89% of best rating.
CNet> FileName3.LHA 1698CPS,  97% efficiency, 107% of best rating.

--625--
While we are on the subject of 'resident', I'm not sure the "ADD"
option is a good idea.  All it does is allow the possibility of
accidently adding a 2nd (and 3rd/4th/5th...) copy of the same prg to
your 'resident' list.  I'm not sure WHY/WHEN you'd need to do that.
Making 1 copy 'resident' is plenty.  (And that's the whole idea of
this.)

I also notice, once you get 2 (or more) copies resident, it becomes hard
to un-resident them.  "c:resident cnet:bbs REMOVE" just keeps reporting,
"object not found" even though there's 2 copies of them, both with "0"
usages.

Does anyone know how to remove a 'double-resident' cmd?

> Response...
You and I must be running two VERY different versions of 'Resident'.
Here's how the version from WB2.1 works.
(As per the manual, and as per my tests.)

> The ADD is there because it's better to have it! =) See, if you DO have the
> ADD, then if for some reason you were to do it twice, it will add it twice.
> But if you DON'T have the ADD there, typing "resident cnet:bbs cnet:bbs" will
> toggle whether it is resident or not.
No toggling is done upon the 2rd (or future) executions.

> I guess it's just assumed that people
> would rather accidentally load two of them, than to accidentally un-resident
> it.
No un'residenting is done.  With or without ADD.

> Unfortunately Commodore did not see fit to provide an option that will
> look and see if that command is already resident and only add it if it's not.
No option is needed.  Just don't specify ADD.  And only 1 copy will
be made resident.

> I have no trouble removing multiple residented BBS commands, as long as
> they're not in use. It always tries to remove the FIRST occurance of the
> resident command.
How are you even specifying which 1 to remove?
Nothing in the manual, or nothing that I've tried, allows 'specifying'
"remove the 3rd copy".

--626--
S> Has anyone else noticed how amazingly often people put their OWN names in
S> the "TO" part of the message??? It seems like such a simple question, yet
S> at least 50% or more of messages on most BBSes have the same "To" person
S> is the sender... I've watched people do this on my BBS too... I don't know
S> why they can't understand it... Do people not know the definition of
S> "ADDRESSEE"??? It's such a simple question...
S> > Enter the ADDRESSEE'S handle [No one].

I've caught myself doing this also.
But see no where near "at least *50% or more* of the msgs" on "*MOST*
BBSes" having this problem.

I don't think anyone is specifically entering their own name here.
It's CNet's prompt that encourages this mistake:
CNet> Address this message to [Your Own Name]:
when replying to ANY msg that you posted.

It would be nice if CNet could tell it was about to send a msg
to yourself and gave you:
CNet> Address this message to [No one]:
instead.

(But CNet should never PREVENT you from sending a msg to yourself.
It does have a useful 'self-reminder' purpose, at times.  I email myself
often.  "Bill, remember to checkout <such and such> on your next call
to this BBS.")

--627--
S> Is BBSTEXT really the place to put this sort of thing? I always thought of
S> BBSTEXT as the text that will be displayed on the system. Shouldn't things
S> like JoinLink name, default archiver, and this go in a separate file?

A new BBSDATA file, maybe?
With 2000 lines to edit, 1 mistake, 1 accidently deleted line, can
'throw-off' everything.  Try accidently deleting any *1* line in
the first *1500* lines of BBSTEXT and watch your system go *VERY* crazy.

(I'm surprised Ken doesn't have a "*** CHECK-LINE ***" string in
BBSTEXT every 500 lines or so.  CNet could check that everything was
'aligned' properly.)

A 20-50 line BBSDATA file for non-display strings, (and VERY important
ones, sometimes) would be easier to manage.

--628--

RF> BA> Did you know that both can be run at the same time in the 'shared'
RF> BA> mode?
RF>
RF> With Cnet and Trapdoor? I cant even get the CNet term to work when TD
I haven't tried CNet+TrapDoor+Term.

RF> is running.. it loses half of the characters and screws things up when
RF> I try to call another bbs. I can only imagine what another term would
RF> do to it..
I wonder if Ken's own frontdoor would better work with Ken's own BBS?
I sure hope he writes one someday.  I just keep hearing about MORE and MORE
incompatibilities when trying to run universal, generic, 3rd party front
doors.

But then, I guess I can't expect them to work as good as a FD designed
*specifically* for the BBS, by the BBS's author himself.

--629--
Things work slightly different on my system:
1)  A single gadget click on the control panel, quickly logs off
    all callers from all lines, closes all screens and windows, removes
    all lines from memory, and closes the control panel (just like it should).
    (If it's not working like this for you, something is definitely wrong.)
2)  I execute a DOS script called "t" which runs my choice of terminal prgs.

All recent versions of CNet support #1.
All recent versions of most terminal prgs support #2.

If 1 gadget click and 1 keystroke is too much of a 'hassle', you can
totally eliminate step #1, and run in the 'shared mode'.  CNet fully
supports it.  All decent terminal programs *should*, most do, but a
few don't.  If your's doesn't then:
A)  Contact your terminal's author.  Tell him to "correctly
    share resources on a multitasking machine like the Amiga".
B)  Use method #1-2 above, instead.

If Ken would allow us to control nodes and the Control-Panel under
software control, then #2 could do all of #1 and #2.  The entire
process would be "Run your script by typing "T" from the CLI".

Ken, if you tell me how to do any/all of the following under software
control, I'll gladly write a prg that will do it:
 A) Open close CNet node windows and screens.
 B) Iconify/Uniconify the Control Panel.
 C) Add/remove nodes.
 D) Start/stop the Control Panel.
I assume all of it can currently (or should) be done by sending
the correct msgs to The Control Panel.  But how?

Or better yet, a new 'control' Arexx cmd.  Or just do a 'pulldown menu'
cmd.

--630--
Sometimes a small fragment of a quote (from mme or others) can be
misleading, and I'll want to go back and read the full content.

It would really help me find which response (sometimes from a list of
100s) a quote taken from if this:

CNet> On 01-06-93, BILL ALLEN wrote:

was changed to this:

CNet> On 06-Jan-93, BILL ALLEN wrote in response 74:

(Also, very handy during responses with several different quotes from
1 or more different users.)

(Also, uses a clearer date format.  Eliminating CNet's conflicting use
of "01-06-93", when it already uses the "06-01-93" format elsewhere.
Stick to 1 format or the other, NOT both.)

--631--

Regarding Fidonetting at Ken's BBS...
GA>  I guess we'll just have to keep bugging him.
GA>  Has he ever given a response of any kind on this matter?

S> Hmm, thinking about Fido is he??? How about C-Link???  Now that has tons
S> of Cnet echos on it....

But no where near the # of Fidonet itself.  If Ken is going to do it,
why not have access to a handful of echos from a list of 50 tons
instead of 2?

We talked about it for more than a month here.  No one could give me
a SINGLE thing that 'starting your own network' (ie CLink) could do, that
Just Plain Fidonet couldn't do also.

I'd love to see Ken add CLink or other fidonet echos here.

Maybe a bribe?  If 100 SysOps are paying an extra $50 per month
in LD phone bills, that's 100*50*12= $60,000 per yr.

Even if we gave Ken 1/60th of that amount, wouldn't it be
worth staying in touch via a local-call to a nearby Fidonet
system instead?  (Maybe right from our own system.)

Ken gains $1,000, we gain $59,000, we all stay in touch better than we
EVER have before, and the phone company doesn't get rich.

Ken could use the money for phone calls to pickup his feeds (although
several callers have already said they'd feed Ken echos for $0.),
hardware, phone lines, TrapDoor registration, etc.  Or whatever is
holding him back.

--632--
From: John Temple
Subj: Re: Ken Fidoing?

JT>        Brings me to another item - I got the 2.42 upgrade (downloaded the DMS
JT> file long distance), but after thrashing around a few days found I needed
JT> X/Ifido 2.41 to continue operations.  I still can't find X/Ifido 2.41, even on
JT> FutureWorld !!  This is why I am stuck on 2.28.  Is it me or is something
JT> wrong with this picture?  I am not complaining (really) but I am asking other
JT> Sysops if they have this same problem.
JT> * Origin: Bart's BBS - Seoul, Korea - The Mad Monk! at (6:760/3.0)

Looks like a bug at Ken's system, has accidently cleared-out the
DLs for the updates.  I don't know if Ken's master copies got deleted,
or what.  But he never bothered to place ANY release (old or new) back
online for DL.  It looks VERY bad when other callers have to call LD
to UL the latest release to the HQ BBS itself, just so others can DL
it.

With the importance of these updates, I would think Ken would keep
double and triple backup copies of everything.  And keep AT LEAST
the last *2-5* updates available for DL at all times.  (We could all
take what ever we needed.)

--633--
DS> SURE to backup your DATA before starting.  I have a reather small message
DS> area compaired to some of you and the saving in HD space was 6 Megs with
DS> the new 3.0 message format.  I couldn't believe how fast all the bugs was

Yikes.  What kind of savings can GIANT systems expect?
Since I don't know how big is 'rather small', what was your BEFORE and
AFTER msgbase space?
Are we talking 50-90% savings?
Bravo, Ken.

This is the kind of stuff Ken needs to mention A LOT in text that non-CNet
SysOps see, regarding CNet's features.  They'll hear about CNet's
large use of disk space, and will never know that this all changed
drastically as of v2.60.

--634--
AK> E>      The users should be able to handle a days wait while A-maint is
AK> E> checking the files.  Unless you guys are dealing with 0-day warez that
AK> E> your runners need to spread, then relax, cut the on-line checking and
AK> do
AK> E> it all at once off-line.
I was hoping I didn't spend a fortune in faster CPUs, faster modems,
faster HDs, faster controller cards, faster serial ports, faster protocols,
faster BBSes, multi-lines, in order to shave a few SECS or MINS off...

Just to turn around and tell everyone they "should be able to handle a
*DAYS* wait" for all their files.

AK> Nuff said!
Disabling a great feature entirely, is never a 'good solution' to
speeding things up.  If that was the case, let's turn EVERYTHING off
and things will really be great.

--635--

VOTE> When *MARKING* files for download, CNet should limit the number of
VOTE> files that you can MARK by:
VOTE>
VOTE> 1)  The maximum number you can DL during this call.
VOTE>     (If you can only download 2, you can only mark 2.  The other files
VOTE>     you wish to download can't be marked and won't appear as new
VOTE>     during your next call, so they can be marked then.)
VOTE>
VOTE> 2)  You can mark as many as you want, download some during this call,
VOTE>     others during future calls.
VOTE>
VOTE> In either case, the SysOp can limit the overall number of marked files.
VOTE> And your 'marked-list' will still be available on your next call.
VOTE>
VOTE> Users voting:  38.6 %
VOTE>      #:Possible answers                        : Votes:Percent
VOTE>      1:Limit file marking to DL limit          :    92: 23.8 %
VOTE>      2:Don't limited file marking to DL limit  :   294: 76.1 %

Can a few of the folks that prefer method #1, list a few reasons why?
I'm sure I'm missing something here and want to better understand things.

Even though it's a relatively small amount, 23% of you LIKE being able
to NOT mark files that you could DL on your next call?  Or after you UL?

CNet has 1 of the most sophisticated file-marking schemes I've seen.
1)  Marking and unmarking.
2)  Range marking and unmarking.
3)  Temporarily unmarking for this DL only.
4)  Saving markings from call to call.
5)  Mark while browsing.
6)  SysOp can limit max # of markings.
I know of NO other Amiga BBS software (of the 53 I've tried to look into)
that does all this.

And then, it's all crippled by this 1 limitation.
   You can only mark the # of files that you can DL:
      During this call.
      Today.
      That your file credits allows.

All of the great marking-features can't be used at all under these
circumstances.

--636--
BA> "Twit" filters like those available on big UNIX BBSes.
BA> (To skip stuff you don't care to read, or that is usually just too
BA> long to read.  Or you could even skip your own posts, since you
BA> already know what they say.)
BA>
BA> CNet> "EP"
BA> CNet> 15) Edit MACROS                16) Configure USER filters
BA>
BA> CNet> Enter upto 10 IDs each.
BA> CNet> [1] Skip items posted by user IDs    : 23,456,122,31,2
BA> CNet> [2] Skip files uploaded by user IDs  : 3,87,21
BA> CNet> [3] Skip responses posted by user IDs: 98,372,763,12

And maybe these too:
CNet> [4] These users can't send you email : 2,4,6,123,4
CNet> [5] These users can't OLM you        : 34,567,12

#4 might be the most important one of all.

#4-5 could automatically be overridden by anyone with 'sysop/maint access'.

--637--
CD> Well you can just use a simple modification of the program "docread".. it
CD> works wel on our system and We have a fake disk in memory the user can

This is true.  But I feel this is one of those features that should be
a part of the BBS itself, for several reasons:
1)  It would be very heavily used by many.
2)  We could count on it being available on EVERY CNet BBS we call.
3)  All the view/pack/test/extract strings that would be needed are
    already part of CNet's config.
    (Although it might be a good idea to have a separate EXTRACT string,
     for this use, separate from current "QWK EXTRACT" string.)
4)  Wouldn't have to worry about bugs/virus/back-doors running 3rd party stuff.
5)  The 4 functions needed (view/ask-user/extract/display-file) are already
    coded into CNet, for use at various other places.
    (So CNet's size/complexity wouldn't need to be expanded greatly.)
6)  You could still run an external "docread" prg, if you wanted to.

--638--

JS>   The only problem I see with a program like this is what happens to
JS> people who lose connection due to bad lines, noise, or modem
Jim, several of us spoke about this before.
My views were different than most:
1)  If the caller drops-carrier accidently, it's nobody's fault.
    (Line noise, a mistake, etc.)
2)  If the carrier is dropped due to a hardware/software problem, it's
    not necessarily the user's fault.
    (Modem problems, etc.)
3)  If the user drops the carrier deliberately, WHO CARES.  CNet is
    robust enough (many BBS aren't) to just go happily on working fine.
    (You can crash ANY Paragon/Starnet BBS in the world by doing this at
    certain places.)
    Users say "it's rude".  I don't know how you can be 'rude' to a
    machine.

I would like to see CNet keep track (either per-user or an overall-
total) of the *NUMBER* of times the carrier was dropped.  But NOT so I
could 'hate and punish' the user, but to monitor/fix his (or my)
problems.

To monitor it 'per-user', would take 2-bytes per user.
Well worth it, to know at any time:
CNet>  This user has dropped carrier 91 times.

To monitor this 'overall', would take just 2-bytes overall.
Well worth it to know at any time:
CNet>  385 users have dropped carrier.

A very well spent 2 bytes.

(Maybe a part of SAM?)

--639--
When we log-in and see 'v7.34G' in use (here, all the beta sites, all the
illegal sites, etc) we think 'IT'S BEEN RELEASED, YEAH'.

If we saw 'v7.34G-beta' we'd instantly know.

1)  Save many callers a fortune in LD phone bills.
2)  Stop much of the panic and bugging Ken, that occurs.

(Might even cut down slightly on the illegal distribution of beta-copies.
Many ULers and DLer of such, think they are getting non-beta releases,
and might not bother, if they knew they were only getting beta copies.)

Just with the simple addition of the letters b-e-t-a in the version #s.

 L> No, it mean its the RELEASE. It suggested somewhere on here that Ken
 L> should put a R there so the sysops would know if it's a Beta version or a
 L> actual release.
 So it now says "R".
 Ken, many beta-testers, and many illegal systems are running it.  It
 still isn't available.  How did the "R" marking help us?

 But if everything was marked "beta" until it was 100% released, we'd
 all know the exact status, at any time.

--640--
MM> We were beta testing the BETa 2.60, now we are beta testing the RELEASE to
MM> make sure all the bugs are out.
Are you saying there are beta and non-beta, very different releases,
each marked "v2.60"?  (I'll wait for your reply before I comment.)

--641--
SM> but who knows when..I constantly drop hints.. I think Ken may not reall
SM> want to use TrapDoor for personal reasons. :) But if we bug him enough
SM> he will either do it, tell us "never", or he will write his own mailer.

SM> not really want to use TrapDoor for personal reasons.
Can you list a few?  I'll even take 'guesses'.

SM> or he will write his own mailer.
A massive # of SysOps are in favor of this.  But the relatively few
SysOps that are AGAINST this, speak up louder.

If you EVER (this week or in yrs to come) want to see Ken do his
own custom CNet frontdoor, you better speak up.  Dial his
BBS at 313-981-6150 TODAY and let him know about it.  Even if it's
just a 1 line long msg.  I'd love to see the look on Ken's face if he
logged-in tomorrow and found 592 pieces of mail from users that
are in favor of this.

Instead, Ken is seeing about 5-10 users that HATE the idea (some even
hate the person that suggests it) of a CNet FD, and are saying so
LOUDLY.

--642--

With all the yanking going on, does anyone know if "CNet:yank-task"
is PURE and resident'able?

I can't find anything in the Read-me's (v2.08 12Feb92 through v2.60 Feb93)
that specifically states YES or NO.

If not, would it be possible, Ken?  Or maybe not, due to same reasons that
"xpr-task" can't be.

--643--
DP> It would be nice to at least have hotkey equivalents for each choice so
DP> that we could jump straight to a specific choice without banging on the
DP> arrow keys...
This is a GREAT idea.  Ken, would have to add another field onto
the VDEentry structs allowing us to specify the hot-key for that
item.  CNet could even automatically underline those chars in
the VDE display screen.

But I wouldn't want the cursor to just "jump" to that choice.
It should "jump" and activated it, too.  So we can immediately start
editing that item.  Hot-key should be 1 key, NOT key+RETURN.

--644--
Marking msgs works great.

But when I go to read them (RM), the following cmds aren't available
at the "Respond or Pass>" prompt.

They are (and more) available at the "Respond or Pass>" prompt for
"Read New", and other "Read" options prompt.

Download, Extract, Grab, Over, *, ATtribute, EDit, Kill, TEst, TRansform,
Validate, Write.

"ZG" is slick.  "RM" is slick.  But once you've done that, you DON'T
have ANY of the above 12 possibilities that could actually allow you
to *DO* something with the items you found.

--645--
Any plans on adding a "NOT" option to the read/scan/browse cmds.
Multiple combos of options would still be available.  "NOT" would
only effect the single option that followed it.

CNet prompt> READ NOT NEW
CNet prompt> READ NOT BRANDNEW
CNet prompt> READ NOT NEWRESP
I already read all the new stuff.  What did I miss BEFORE it?

CNet prompt> READ NOT TOME
I already read carbon-copies of the stuff written TO-ME when I logged
it.  So skip reading it again.

CNet prompt> READ NOT BYME
I wrote the stuff written BY-ME.  I know what I said.  So skip reading
it again.

CNet prompt> READ NOT PRIVATE
With my low access, I don't have private-read powers anyway.  So why
show me "This item is private" over and over again?

CNet prompt> READ NOT UNVAL
With my low access, can't do anything with unvalidated items anyway.  So why
show me "This item isn't validated"?

CNet prompt> READ NOT FREE
I wanted everything to be free in this sub.  Which items aren't?

CNet prompt> READ NOT 'foo'
CNet prompt> READ NOT FAVORITE
Etc, etc...

Are any of the above 10 possible, at all, without this "NOT" specifier?

("RA NOT BYME NOT BANNER" would be HEAVILY used by me.)

--646--
>Making CNet handling Faxes...

I'm against including ANY code in CNet *The BBS*, for sending or
receiving faxes.  I WOULD like to see CNet answer the phone and be
able to determine the difference between 1 (or more) of the following:

1)  BBS callers
2)  Inbound Faxes
3)  Inbound Fidonet
4)  Inbound UUCP
5)  Voice Callers (with the proper modem)
6)  Inbound file requests
7)  Custom, SysOp definable handshaking

And then call the external programs (Ken's or 3rd party stuff) that
handle things from there.  You could run 0 or more of them, and without
increasing the size of the CNet executable greatly.

(I'd use this feature heavily.  But my order of preference for seeing
it installed, would be 1-5-4-3-6-7-2.)

--647--

Software authors can do it several different ways:

1)  0 free months of usage.
    (You pay for software without ever seeing what it really can do.)

2)  3-12 free months of usage.
    (Whether you pay the small shareware fee or not.)

3)  3-12 free months of usage, but only if you later pay.

I've decided to go with #2, NOT #1 or #3.
Which of the 3 would you prefer?

CP> BA> It was definitely, definitely, definitely fully documented as such.

CP> Fully documented? No, there was a small line in there about it's
CP> destruction by X date, but that was all.

Other than mentioning the date.  And the fact that you could only
use it until that date.  And the fact that it would stop working
on that date.  I really didn't think there was much else to be said.
I considered that to be 100% fully documented as SHAREWARE and LIMITED
TIME OF USAGE.

I wish EVERY single piece of software EVER written for EVERY computer
also came as "demo for free for 3-6 months" preview.

But different people have different preferences:
1)  Love a chance to demo things.
2)  Don't care to demo things.
3)  Post insulting, vulgar, public msgs about the demo's author.
I'm #1, myself.  But, to each his own.

--648--
Ken, I don't know what your viewpoints are about writing a custom, simple,
external frontdoor for CNet.   (Now or in the near or distance future.)

Perhaps you would entertain the idea of at least having CNet *DETECT*
incoming Fidonet calls?  It could then execute Trapdoor, but only for
inbound Fidonet calls.  I realize this is exactly the opposite of the
way it currently works.  Don, is this feasible?

1) We wouldn't have to keep Trapdoor in run (and using memory) at all times.
2) Trapdoor would answer 0% of the calls, instead of its current 100%.
(I get 50x more human-users than I do Fidonet-connections.)

Hopefully this *detection-only* code would:
1) Be small and simple.
2) Would not be wasted if you later decided to write a FD.  (You'd need
it anyway.)

I can't imagine "detection-only" would take too much work to add
to CNet's code.  I'm guessing, but I thought it was as simple as:
1)  Check for certain return strings from the modem.
2)  Check for certain voice/fax/caller ID features of the modem.
3)  Check for the remote system sending certain codes that ID it as
    a Fidonet/UUCP/etc call.

If Ken doesn't want to write the "network detection code".  Maybe a
do this instead...

> CNet waits x secs for the caller to hit the x key.
(Both sysop configuratable.)
If this doesn't happen, a network-call is assumed, TrapDoor (or whatever my
string is set to) is spawned.

Ken wouldn't have to even do the "network detection code".

As always, thanks for allowing me to freely speak my mind here, today
and 1000s of times in the past.  It is greatly appeciated.

--649--
v2.60> (4) DOS program files>  NSAL
v2.60>
v2.60> 14 subboard(s) report new uploads since your last call.
v2.60> Quick-browse these new files now [Yes]? Yes

It then proceeded to list files from Dec92-Jan93.
I know I've been online since then.
So either the text stating "new uploads" is wrong, or "since your last
call" is wrong, or CNet isn't scanning true, new uploads.

Does anyone know which?  Or what I'm I doing wrong?

--- EOF ---

Saturday 06-Feb-93 03:50:02
Bill Allen Beogelein, 313-473-2020, 1:2410/207.


