
Sunday 04-Apr-93 05:16:56

--850--
Am I suppose to get a "System OLM" when someone sends me mail?
I thought I did in the past, but not any more.

--851--

As of 25-Sep-92 Ken was going to try to hit a 31-Dec-93 release for
a v3.0 manual.  I haven't heard much more about it, but *MY* best
guess would be July 1993.

If that happens, it'll still be about 12 months after this MUCH needed
piece of documentation should be been put into everyone's hands.

I can understand docs being released a few weeks (or even a few
months) behind the software, but it should never start to move into
its 2nd YEAR, of behind schedule!  And with the rate that CNet
advances, full-docs should never be more than a few DAYS behind the
software.  (If disk-based, fully possible with the dirt-cheap computer/
modem technology currently available.  Or print-versions with a dirt-
cheap bubble-jet printer.)

What about the 100s of people that buy CNet, open up the box and sit
there and think that they've accidently received a manual for some
other software?  The references in the manual are quickly becoming
something totally different from the software they are suppose to be
documenting.

--852--

I didn't see it mentioned in the v2.63 readme, but FIND's new
>Download, *, Examine, Grab, Quit, [Pass]
it VERY handy.

I'm not sure why [R]ead was left off, though.

If you want to read any responses to a file, it is back to:
"It's some place in sub "Foo Foo".  Go find it yourself."
just like the old FIND output.

And you have to resort to using a non-FIND, non-lightning fast 'BG'
cmd, or something.

If it is totally impossible for FIND to allow [R]eading, maybe allow
us to Q23, quitting (jumping) to the sub that contains file #23.

But [R]eading right from FIND's prompt would complete FIND's circle of power.
Lightning fast finds *AND* all Read/DL/*/E/G/Q/ powers.

I'm NOT sure why an entirely new FIND keyword was needed.  An optional FILE
range-modifier could been added instead, giving:
1) Usage with SG BG etc...
2) No new cmds to remember.
3) Would work like MESS, but only display files.
4) Would turn on FIND's fast index searches.
5) Consistent methodically.
6) Full Read/DL/*/E/G/Q/ powers.
7) Could be used alone or combo'ed with a dozen other existing range-modifier
   for super-power users.
8) Could still be aliased via BBSMENU into the "FIND" cmd, if you like.

--854--

JC>  between the two packages. Proteus is basically an ARexx host. It is quit
JC>  programmable ( in fact, by itself it won't do anything at all ).

What about the new breed of Super-BBSes like CNet:
1)  Incredible arexx port with host-commands up the kazoo.
2)  Incredible built-in features.
You could use #1 or #2, or both.

Not be limited just to #1.
(I'll admit, an entirely arexx-based BBS might be more extensive
in #1 (but not much), but you lose MUCH of #2.)

I'll gladly take a 5% loss in #1.
If given a 90% gain in #2.

If an arexx-BBS allows you to play with 50 built-in variables
And you have to add 250 more yourself...

I'd rather just start with 290 built-in variables.
And just have to add 10.
(But you can STILL add 100s more if you like, to either package.)

I guess it comes down to:
Would you like to "continue" constructing a skyscraper from its
existing 75th floor?  Going up from there.

Or start from the 10th floor?

As long as both allow 1000s of floors, why not start near the top?
Let the BBS author build those 1st (sometimes difficult) 75 floors.

That's a lot of work being handed to you on a silver platter.
Why refuse it?  Don't use the stuff you don't like.
Replace it with Arexx scripts.  But it's there for the asking, if
you choose to use it.

--855--

Shawn McNeece writes...
SM> I am beta-testing 2.63 now, and this will be the last
SM> public release before 3.0.

Even if there's a few bugs in v2.63?  No more updates until v3.0?

Also, I sure hope a v2.99 release is offered to the public before v3.0
goes into stores all over the country/world.  No?

500 people can beta-test better than 10 testers.
(This is NOT an attack on beta-testers, just a fact.)

DS> Bill it might be better but one programmer keeping up with 500 Beta
DS> Testers,
DS> I think not.

1)  10-beta testers get out 95% of the bugs
2)  Then it's released
3)  500 sysops get out the remaining 5% of the bugs
(Or whatever the exact #s are.)

I don't have a problem with that.

But why skip #3 by not releasing a v2.99 to the general public?

1-3 was done with MANY releases.  Why not continue?
v3.0 is the most important update of them all!

--856--

Now I'm starting to think maybe a larger OLM length might not be too bad.

Prior to last week, I had never used (nor been used by) it other than
for quick, little "Hey, want to chat?" or "Sorry, can't." type msgs.

Recently I *DID* have a need to OLM a user back&forth some longer
OLMs.  (And no need to wait in CHAT for replies that might take the
user several mins (each) to checking on.)

But I'm only in favor of it, if 1 concern is addressed...
How do I stop (without muffling 100%, which would defeat the whole
purpose) a user from dump 1000s of chars onto my screen, unexpectedly?

Maybe a new "max-len of OLMs received" variable that each user can set
himself.

Or instead, have CNet automatically limit the 1st OLM to 100 chars,
but if I OLM him back, then all future OLMs can be 1000?

Also, how do I send an OLM that lists a few items, 1 per line?
>1)  One
>2)  Two
>3)  Three
(Or course, as soon as you hit the 1st RETURN, the OLM gets sent.)

Would anyone be in favor of having OLM end/send only on:
"Hit return on a blank line to send."
Lists, blank-lines, indentation, any formatting you specified, would
then be available.

This custom-formatting becomes more and more necessary if OLM start to
get longer and longer.

--857--

Monday 05-Apr-93 19:35:01 Uploaded:

installr.lzh               92897 ----rwed 05-Apr-93 17:01:59
: CBM's Point&Click Installer prg+docs v1.24

This is what Ken could use as a CNet installer or updater.
He'd only have to distribute the small, custom installer-script
with each update.  All the work of writing a full Intuition
Point & Click interface, is already done for you.

Its very extensive script-language covers everything that you'd
possible need to do during an install process.

Would anyone be willing to write a CNet install/updater script?

This was written/released by CBM and is freely distributable.

--858--
I too love doing quick cut/paste ASCII sends (not ASCII UL), and
sometimes got scrambled chars on the longer sends.
(I gave-up trying long ago, don't know if it's still occurring.)

JR> else to send a file description, cnet always screws it up... This happens
JR> not only on my bbs, but ANY cnet bbs I know of... now.. v32 ascii sends
JR> seem to be FINE. but when connected HST< and somoene (or me on ANOHER BBS)
JR> does an ascii send from their term program, cnet completelt screws up the

I would think it was CNet's input buffer (in the editor) not keeping up with
the feed of chars coming in.  If that's what is causing it, I think CNet's
buffering needs to be addressed.  It should buffer and be able to receive OK
at any speeds you throw at it.

Why are you reporting no problems at higher speeds, then?  How does 1200-2400
work for you?  Is the line-editor, but or worse than the fullscreen editor?

--859--
Just so that 100 people don't send Ken private mail about this,
I'll post it here publically...

CNet>  NOTE: can not find "SysText:menu/find" ...

Also, FW's system-clock needs to be increased 1 hr, as of last Sunday.
(Don't correct this while *I'm* online. :-))

--860--
2.63> The Mail-Read function has been upgraded considerably.  The biggest
2.63> change is that there is now only ONE mail-read prompt.  Previously,
2.63> there were two, one with the options "Quit, All, New, Old."  The new
2.63> system is considerably more powerful.

Now if we could just combined BROWSE's 2 prompts into 1:

CNet> (2) Browse (*, Download, Examine, Grab, Quit, Read)
CNet> Abort, Drop, Post, Quit here, Skip dir, [CONTINUE]:

Whenever I browse, I spend my life hitting:
[RETURN] [RETURN]
[RETURN] [RETURN]
[RETURN] [RETURN]
[RETURN] [RETURN]
[RETURN] [RETURN]

The only keystroke-conflict would be [D]rop. It would have to become
[DR]op.  (Which would make it consistant with the [J]oin/[DR]op that
is needed everywhere else, anyway.)

Like other prompts, this 1 prompt would NOT have to
list ALL the cmds available.  Just the basics...
CNet> *, Download, DRop, Examine, Read, Post, Skip, Quit, Abort:

(I only left out [G]rab, which would still be available, just not
shown.)

--861--

> Sub-op account #  1 : 34           Sub-op account #  4 : 234
> Sub-op account #  2 :  2           Sub-op account #  5 : 211
> Sub-op account #  3 : 65           Sub-op account #  6 : 0

Would anyone like to see the entire EL sub-menu that we have
to keep jumping in and out of, replaced with just:

> Sub-Op acct #s: 34,2,65,234,211

See/edit the whole list at a glance of EL's main-screen.

--862--

Has anyone been noticing wildly big/small "Best-CPS" displays in item
headers of smaller files?  Most likely due to startup/termination
times of the protocols themselves.  Might be worth not even displaying
a "Best-CPS" for files <1-2K, if it's going to be drastically wrong/
misleading anyway.  (NOT due to CNet's fault.)

Are callers wondering why they aren't getting the same 4000-CPS
transfers that others are "getting"?
(On already compressed .LHA files, no less.)

>file: MaintMenu.lha (1396 bytes, 0m 5s, 69 xfers, 124 cps best)
>file: NewsMaker1.0.LHA (1172 bytes, 0m 4s, 46 xfers, 148 cps best)
>file: BIG_CPS Speed.LHA (5052 bytes, 0m 23s, 72 xfers, 4028 cps best)

--863--

DM> systems I allow on my system to joinlink could intially call and set up
DM> this account and there after all they would have to do to initiate a

That would work.  1, not 2, sysops would need be present.  But I like 0
better.  (For 3am usage, etc.)

Even with special, passworded accts, how would you control things like:
1)  3-4 joinlinks taking up most/all of your lines at once.
2)  Which ports can/can't be used.  (For those 1-HST & 7-2400bps BBSes.)
3)  Offpeak hrs/days only.
4)  Limit to x mins.
I would have to be VERY careful which SysOps got these joinlink-accts.
(I'd rather allow ANYONE to joinlink.  But I control 1-4.)

And these special accts would still have to be pre-arranged.
(I'd rather allow ANYONE to joinlink.  But I control 1-4.)

I hope Ken doesn't make a half-way improvement, only to re-write it
all again when people start needed more control, more power.

Go the whole-ball-of-wax.  See response #1.

Given 1 of 2 choices, which would encourage greater JoinLink usage?
A)  You can control specifically which Systems can joinlink with you.
    (But you can't control anything they do, once JoinLink'ed.)

B)  You can welcome all/any Systems to JoinLink with you.
    (But you can control dates/times/lengths/which-lines/#-of-lines/etc.)
    (And if you want, even control "who", just like #A.)

(Pick #B, and it allows all #A and all #B powers.)

Maybe the acct-method would be better.

I guess I could always just have 1 acct with the name/password FREEJOINLINK to
welcome any/all SysOps to JL with me.  (That was my main concern.  Making 1st
time JoinLink sessions available to the massesg, cmd execution,
etc.  All those other acct-settings could track/control usage.

My other concern was regarding dialing out.  For true 100% 3am unattended JL
sessions.  What are your ideas on that?

>What is join-link?

o Have 1 BBS call another and all users currently on either systems
  can enter into a single join-group-chat session.  Each BBS can have
  2-24 lines, and upto 100 systems can be chained together in real-time
  over the phone lines.  1000s of users in 1 big group chat.

Chaining can be done in a star-pattern, linking all systems:
    *     *
     \   /
      \ /
*------*------*
      / \
     /   \
    *     *

Or in a linear-pattern:
*---*---*---*
             \
              \
               *---*---*---*---*

Or any combination of the two:
*---*       *---*
     \     /     \       *      *     *--*    *--*  *  *---*
 *    \   /       *      |       \   /      *     \ | /
 |     \ /               |        \ /       |      \|/
 *------*-------*---*----*---*     *------*-*-------*---*---*
       / \          |    |    \   / \     |        /|\
      /   \         |    *     \ /   \    *       / | \
     *     *     *--*--*        *     *       *--*  *  *---*


A VERY sophisticated feature!
(But very little used, in part, due to the way it has to be 'manually'
started each and every time.)

--864--

Ken, same scenario as before, but instead of using a callback in
a *PFILE* to immediately save an element back to disk, I need to do
it in an *AREXX* script.

I successfully use 'SetObject/PutUser' to change 1 of the variables
(FAVORITE FLAG) in 1 of my online files.  How do I force (with Arexx)
CNet to immediately save this change back to disk?

Am I missing something?
Aren't ALL SetObject/PutUser XT##### calls totally useless if I can't
force/guarantee ALL my changes are going to be preserved/changed?

Aren't ALL SetObject/PutUser XT##### calls just temporary changes
without some kind of an arexx "'SaveUser' XT#####" call?

I always 'bump my head' against things like this, bringing my
project to a screeching halt.

--865--

Ken, is there an arexx cmd similiar to 'SendFile' but WITHOUT MCI
expansion?  I've seen several arexx authors that use it freely, not
realizing it can be a very dangerous way to display files, unless
you know their contents.

Maybe:
1) 'DisplayFile' {p}   Without MCI expansion.
                       Use freely.

2) 'SendFile'    {p}   With MCI expansion.
                       Use cautiously.
(And encourage #1 use, more than #2.)

--866--
Every one of my last 100 posts got its 1st line chopped off, due to a bug in
CNet's zip xmodem-UL.

I had to fix them all by hand.

Did you see my Feb 1993 post about this?

(It would also be great to ZIP with the same protocol my acct is set
to.  I have to keep switching my term back and forth xmodem/zmodem/
xmodem/zmodem/xmodem/zmodem/etc.)

--867--

Uploaded Wednesday 07-Apr-93 20:27:21...

"Pfiles:CNetV.rexx" by Bill Beogelein
                       Box 530441
                       Livonia, MI 48153 USA
Amiga ShareWare HeadQuarters BBS
313-473-2020 2-line, USR HST-DS 14.4k

Ever wonder what versions a SysOp is running?

This program presents the user with a list of file-paths (SysOp's choice).
The caller can check the internal version #s of ALL the files,
executables, libraries, cmds, handlers, and devices within those paths.

New feature in release v1.3...
The setting in SysData:CNetV.cfg line #6 also allows users to see:
> Running CNet 2.61, Kickstart version 37.175, Workbench version 38.35
> Checking CNet:BBSconfig3  : Could not find version information
> Checking CNet:Fido/iFido  : CNet 2.60
> Checking CNet:Fido/xFido  : CNet 2.60
> Checking CNet:Control     : CNet 2.61
> Checking CNet:SetPass     : Could not find version information
> Checking CNet:Unlock      : CNet 2.60
> Checking CNet:Xpr-Task    : CNet 2.60
> Checking CNet:BBScontrol  : Could not find version information
> Checking CNet:Yank-Task   : CNet 2.61
> Checking CNet:BBS         : CNet 2.61
> Checking CNet:Big_Numbers : Could not find version information
> Checking CNet:Config      : CNet 2.61
> etc....
(As of v2.61 there are still a few missing version #s for certain CNet
executables.)

Separate 'success' and/or 'failure' logs will track CNetV usage.

--868--

>Needs a call-out door...

Specifically what would you need this door to do?

Have you looked into TermLink?  It still needs a few things...
1) Control which #s are allowed to be dialed.
2) Charge x cents per min for each phone #.
3) Limit length of calls to x mins for each phone #.
4) How many free lines most be open before term-link can be used to dial this
   #.
5) Which lines can be used for termlink purposes.
6) How many term-link calls can be made.

A phone-format similar to sys.avalid could be used for #1, but with new fields
for the other variables.

How many SysOps are going to allow Term-Link powers to callers if they can
currently call Nome, Alaska, 20 times, for 120 mins, when all my lines are in
use, tying-up my only 2 hi-speed lines?

(They could even make voice-calls to harass people with my phone, at my
expense.)

If Ken doesn't want to build all (or any) (we need at least #1) maybe he could
add a few Term-Link Arexx cmds.  We could throw #1-6 together ourselves.

--869--

> Skip posts by item #s that you specify.  ('ForgetItem'-cmd)...
I love it!  I'd use it A LOT!

The suggestion was made ages ago.
(Not saying that it shouldn't be mentioned again.)
No response from Ken, yet.

Large UNIX BBSes have a "FORGET" cmd that does exactly this.
("REMEMBER" will un-FORGET items.)

See my suggestion #126 from July 1992.
Or #228 from Sept 1992.

                      ======================

1) Skip posts by certain callers. ('TwitFilter'-cmd)
2) Skip posts by item #s that you specify.  ('ForgetItem'-cmd)

#1 would most likely be easier for Ken to do.
(I wouldn't use it much.  Even 'twits', aren't twits, 50% of the time.)

#1 sounds like "use out of bitterness".
#2 sounds like, a genuine, "this item's topic doesn't interest me".

Both are very good ideas.

(I hope #1, if implemented, won't allow callers to filter-out all
posts made by SysOps/SubOps, too.)

If [F]ORGETing items will be too costly in terms of disk space and
memory consumption, maybe Ken could allow each user to [F]ORGET a
maximum of 25 items.  (or 50, or 100, or a SysOps settable CONFIG
value.)  Or maybe a max of x items per sub.

CONFIG> Number of items each user can [F]ORGET:
(SysOps not liking/needing this feature could set it to 0.)

I can't imagine each [F]ORGET costing more than a few bytes if disk space
or memory.

Heck, I'd like to [F]ORGET even 10 items, instead of the current "0".

Maybe we could also find a need for allowing each user to mark
his own "FAVOR" items, too.

TB> > When is it my turn again?
TB> > Adding a simple twit-filter to CNet would kill this issue forever.
TB> But Bill, no one would ever see any of your messages again..

I wouldn't mind.  I'd never even know about it.  No one would.  

"Children" could co-exist online, totally transparent from each other.  I
don't who would "filter-out" whom, but it would be VERY nice to read msgs and
say to myself, "Look, 1 user said this, and so-and-so acted like an adult for
a change and didn't jump down his throat."  (But, of course, it would be the
twit-filter at work skipping over so-and-so's insulting/rude/vular/childish
attacks.)

It would help the readers, as well as the writers, (making "children" appear
like adults.)

No names, please.
      
BA> "Children" could co-exist online, totally transparent from each other. 
BA> I don't know who would "filter-out" whom, but it would be VERY nice ...
TB> Geeesh.. lighten up..

That wasn't meant to be as heavy-handed as it sounded.  There genuinely are a
handful of "kids" online that others might want to skip-over.  Whether you get
filtered or I get filtered, or you do the filtering, or I do the filtering, it
doesn't matter.  It would be more peace for everyone.

TB> But, alas Bill, I wouldn't filter you out.  Your too much fun.

Fun?  Me?  Have you been talking to my ex-wife?

--870--

> CNet is getting too complex...

When a user asks for a new configuration variable to be added to the
BBS, I think it is important to also discuss:

A)  Disk space used
B)  Memory used
C)  Ease/speed/convenience/complexity of setting it.

The results can be drastically different, if the new variable pertains
to something that is based:
1)  One global setting in CONFIG (1)
2)  Per access group (24)
3)  Per sub (50)
4)  Per item (500)
5)  Per user (1000)
6)  Per response (5000)

On an average sized BBS, the actual # of variables is shown in
parenthesis.  (Also a good indicator on the amount of diskspace/
memory/difficulty/complexity it adds to the BBS.)

I think #1-2 should be added freely.
(Does it really matter if we waste 1-50 bytes of memory on a few 'one-
shot, set-and-forget' variables?)

#5-6 should be much more carefully weighed/considered.
(Hours setting variables 1-by-1, memory costs, etc.  It starts to add
up if too many of these types of variables are added.)

--871--

A> TRY the 'UM *' Command into your login macro...

That checks for ALL users on ALL ports, not 'a user by name'.

UM is an odd cmd.
If I want to use it to see if/when a certain caller logs-in (A VERY common,
need, I would think), that user already has to be online, before I can watch
for him.  ???

Ken, I would love to write a UNIX-like "WATCH" pfile.  Each user could feed it
a list of user names or #s, it would send an OLM whenever those users logged
in or out.

How do I get CNet to send a msg to my pfile when a certain event occurs?
(In this case, "new caller logged in".)
I do NOT want to do the busy-loop check method.

--872--

> Missing VDE (Visual Data Editor) docs...

I hear you.

> 0 = UBYTE 0/1
> 1 = ULONG BIT 0/1
> 2 = Text
> 3 = BYTE numeric
> 4 = short numeric
> 5 = USHORT numeric
> 6 = long numeric

Does anyone have any more 'types' that VDE.c forgot?

Ken, do you keep all this info in your head?
It must be written down in a file or on a scrap of paper some place.
Can we get that info so we can write some VDE's too?


TB> And why haven't _YOU_ written any?  You make it sound like you're
TB> dissapointed in everyone else for not supplying _you_ with other VDE
TB> alternatives.

I need a list of all the TYPE values.  (and other related VDE and non-VDE
docs.)

It would cut 90% off my coding time.

I'm currently doing all my pfiles like this:
1) Struggle for 2-3 days trying to figure some undocumented thing, myself.
2) Give-up and mail ken or someone a question about it.
3) Retrieve my answer a couple of days later.
4) Repeat 1-3 20 times.
5) Release my pfile.

I'd much rather code the way I always have in the past:
1) Read the docs and do it.
2) Release my pfile.

--873--

I thought Ken was going to try and hit an approximate:
1)  6-week new-features update period
2)  1-2 week bug-release update period

It's been 8 (and counting) weeks without either.

If it's going to be 2 more weeks then....

I can understand #1 getting delayed 4 weeks beyond the 6-week mark.
(Time flies.  It happens.  Things come up.)

I can't understand #2 getting delayed 8-9 weeks beyond the 1-2 week mark.
(Bug-fix releases, to help out the MANY v2.61 systems, are VERY important.)

--874--
JR> other.. the problem?? heh.. well.. When your in a hurry... you sometimes
JR> tend to use 'hang-up' instead of 'chat mode'.. heeh thefore booting the

Maybe a few menus with text like "-----------------" to help separate things.

--875--

Pam, how does this work now?

A user with 5 mins remaining can UL for 5 hrs?

How "should" it work?
The user won't even be able to start an UL if 'too close' to his time limit?
(Define 'too close'.)

A user shouldn't be able to start an UL if CNet determines that UL's length
will exceed the user's time?
(Great for protocols, like Zmodem, that can allow this.  But Xmodem and
others, can't.)  (And what if line quality changes and CPS increases/decreases
that would change the time length of the UL?)

A user should be cut-off when his time-limit is reached.
(Zmodem can be resumed.  Others can't.)

Keep in mind, that most sysops BEG for ULs.

--876--

CR> least 3 prompts to d-load a file.. Why cant all thos option be placed on 1
CR> menu line??  All those options could be placed at the same prompt.

What would this prompt look like?

I would like to see these 2, made into 1:
> Use your default protocol Zmodem [Yes]?
> Logoff upon completion, Abort, [Begin]:

> [P]rotocol, [L]ogoff, [A]bort, [Begin]:

Do callers really change their protocol enough to warrant asking them if they
wish to change it before EVERY download?

And of course, new users probably can't find out how they undo [L]ogoff.
So maybe, the prompt could toggle between both:
> [P]rotocol, [L]ogoff, [A]bort, [Begin]:
> [P]rotocol, Don't [L]ogoff, [A]bort, [Begin]:

I've already mentioned all of the above to Ken, long ago.

--877--

Ken, please consider squeezing another flag into each item's struct.

>                       // 0==Not-Checked
> BYTE VirusChecked;    // 1==Checked/OK
>                       // 2==Checked/infected
>                       // 3==Checked/infected/fixed

CNet wouldn't have to do anything with this flag.  Pfiles and arexx
scripts could check for viruses, and check or set this flag.

But the "virus-status" could then always "follow" the file through its
movement, renaming, manual-deleting, auto-purging, ULer name, etc.

Well worth the 1-BYTE investment.

--878--

I'm not Pete Baker... but I can answer a couple of your questions

PB> CR> Why is it impossible to upload to a udbase located in ram.
PB> Because you can not upload to a FULL directory and RAM: is always full!

You could try uploading to RAD:, instead.  It has just a few advantages over
ram:...
1) Works with term ULs.
2) Not always showing 100% full
3) Faster than ram: devices
4) Can be made FFS (and REALLY flies)
5) Can be resized to your specs, as needed.
6) Preserves all your files through a warm-reboot, lock-up, or GURU.
7) You can even boot off of it.

I'm not sure why ANYONE would use ram: instead of rad: for ANY reasons.
Can someone list a few, that I must be overlooking?

> Switching from ram -> rad -> FFS rad...
I'm not talking about a small 5%-10% speed increase, here.

When I personally switched from using a "non-FFS rad:" to a "FFS rad:"
the benchmark tests I ran clearly showed a 500%-700% speed increase!

(This is NOT including any ADDITIONAL increases you gain going from
"ram:" to "non-FFS rad:", first.)

These are NOT rumored-results.  These are taken from my actual experiences.

Your results my differ.  But even if you get only 1/4 the improvements
that I did, a 125%-175% speed increase is nothing to sneeze at.

If you think ram: is already VERY fast.
Imagine how fast rad: is.
Now imagine a 500-700% speed increase over that.

If you use ANY ram:disk device, CHECK INTO A FFS RAD:!!!!

Major, Major, MAJOR, speed difference.  I was shocked.

--879--

H> instead of one of the Beta Testers and we all know how Ken hates even
H> using CNets News option to let us know whats going on.

I don't think Ken 'hates using News' or is deliberately keep us in the dark.

I think he's just very busy.  (But it would just take 5 secs to add a gfile,
and he wouldn't need to do anything else.  Other than write the ReadMe, which
he's already doing.)

I don't think he sees the power/handiness of this.
We could all view the ReadMe, 1 sec after he adds info about the new feature
he just installed.

--880--

I never have, nor never will be a big IBM fan, but...

I can't be too hard on IBMers for overlooking the Amiga.

The Amiga probably only makes up 1% of the total overall computers out there.
And probably 1/10th of 1% of the BBSes.
And CNet probably 1/100th of 1%.
(I'm guessing.  If anyone has the exact #s, please post them.)

Would *YOU* take such a small group of BBSes serious?
Would *YOU* even know they exist?
Chances are, you'd never even accidently stumble on the "Amiga
needle-in-a-hay-stack" BBS.

But, you don't need to be big to be the best.
You don't need to be popular to be the best.

When I see statements like:
"We just purchased our 18th computer.  How we can run 18 lines!!!"

I'd think to myself.  By the time I had to purchase my *10th*
computer, I'd be saying "Maybe I should check into some m-u-l-t-i-t-a-
s-k-i-n-g hardware/software before I have to by 8 more computers to do
this."

What is considered today's state-of-the-art IBM/Apple/MAC/UNIX/Atari BBS
software?  I'd really like to give it a call and see how it compares to CNET.
(But I think it won't be a contest.)

It just goes to show you, 120,000,000 people *CAN* be wrong.

--881--

Maybe CNet needs to make the current EL flag tri-state:
> Amaint adopt orphs:
ADOPT
NONE
DELETE

(Avoiding an entirely separate additional element to the VDE.)

Would this cover everything?

Or better yet, do it completely, once and for all:
1) If files are found on the HD, not listed online, adopt them.
2) If files are found on the HD, not listed online, ignore them.
3) If files are listed online, but not on the HD, delete the listing.
4) If files are listed online, but not on the HD, ignore them.

(I think that covers all 4 possibilities.)

--882--

KEN> SAS v6.2 stack setting info request...

Ken, everything I know on the subject (not much) is posted under
item "4 30-Mar  19 -cfistq".

I'm not sure, but it looks like we are faced with some very
unfortunate (almost unbelieve) restrictions:

You can't set the stack-size without running the task in the
background.  (Whether you want to or not.  Whether your user-IO
routines are designed to accept this or not.)

You can't set the stack-size if you want keep the executable
resident'able.  (In 1 paragraph the SAS manual says you can, then it
says you can't.)

You can't set the stack-size without a new startup module replacement.
(sc LINK STARTUP=cback stackTest.c)

You can't view the status of these executables with simple, "c:Status"
type cmds.  (There are some 3rd party shareware prgs (somewhere) that
can look at them.)

You can't play with the priority settings with simple,
"c:ChangeTaskPri" type cmds.  (There are some 3rd party shareware prgs
(somewhere) that can change them.)

A prg that sets it's own stack size is VERY desirable.  But why
all the drawbacks?

(Feel free the correct any of my above errors.)

It would be great to receive the Amiga programmer's Fidonet echo, or
better yet, the programmer's Usenet NewGroup here at FW.  With the
latter, chances are, you could probably talk directly to the team that
WROTE/DESIGNED cback.o, SAS, c:Status, c:ChangeTaskPri, the docs, the
Amiga's OS, etc, etc, etc.

--883--

R>  Any idea about keeping the temp files in the users home dir tho?

Which 'temp files' are these?

R>  That would be a better solution as it would need NO overhead.

I wouldn't call it 'NO overhead'.
Each 40 byte file still uses a full 2 blocks of disk space.

1) 500 of these tiny, individual 40 byte files uses 1000 blocks.

2) But if the current 960 byte CNet user structures are each expanded 40
bytes, 10,000 such accts would use an additional 781 blocks.

So you'd still save disk space even if you didn't use 9500 (95%) of these
'sysop-usage' variables.

#1 and #2 both use more disk space than CNet does now, but #2 is A LOT better
way to do it.

(If Ken goes with method #2, SysOps could still use #1, (if they wanted to
waste the extra disk space.)  If Ken goes with method #1 (the big disk
waster), SysOps can NOT use method #2, even if they wanted to.)

CNet current does #1.

I wouldn't suggestion just a 40-byte block be added.
Maybe something like:
LONG User1;
LONG User2;
LONG User3;
BYTE User4[10];
BYTE User5[10];
BYTE User6[10];
(But I'd settle for ANYTHING, even 5 bytes of user-definable space.)

The only rule Ken would have to set down, would be:
"If any pfiles care to use any of these 6 variables for their own purposes,
that pfile must allow the SysOp to decide which bytes are used."

That rule would avoid ALL conflicts of pfiles.
You, of course, couldn't run more pfiles than you had variables left open.
(42 in this case.)

--884--

> changing * to Mark?

I would NOT want to see it CHANGED from "*" into "mark".

I would like to see BOTH made available.

Did you see my suggestions in KEN.LHA that would allow each user himself to
alias any cmd into another one?  You could let your users decide whether they
wanted "*" or "MARK" or "SELECT" or "PICK" or "CHOOSE" or "WANT" or anything
else.  Each user could have whatever he was comfortable with.

If a user's alias-cmd-list said:
>alias MARK *

Each time CNet saw MARK, it would do a "*", instead.

You could tell all your users:
"Make any cmd anything you want.  It's a CNet BBS."

--885--

> View inside of archive pfiles...

R>  What other stuff does your do?

1)  List the files inside archives.
2)  Extract files inside archives.
3)  Read text-files inside archives.
4)  Check version #s of executables, libraries, handlers, devices,
    of files within archives.
5)  D/L just 1 (or more) files within archives.
6)  Search for a certain word/phrase inside text files, inside archives.
7)  View ANSI representations of IFF picture files stored within archives.
8)  Re-pack your extracted files.  (From the same or different archives.)
9)  Configuartion file allows all past, present, future packing
    methods, including DMS-types.
(Please list anything else you can think of.)

R>  And of course if this was part of
R>  cnet like the "E" command, we wouldn't be having this discussion. :)

All Ken would really need to add to Cnet would be 2 things.
A)  The user could extract any file from any archive.
    (The info is already in CNet's CONFIG.)

B)  The user would be shown a list of SysOp executables:
    More
    Type
    Version
    IFF2ANSI
    Search
The user's choice from #B, would be placed in front of the extracted
filename and whatever output was generated would be shown it the user.
    c:More ReadMe
    c:Type ReadMe.doc
    c:Version IFF.library
    c:IFF2ANSI MyPicture.IFF

--886--

Maybe Ken could also add 1 more flag so we could quickly tell which
mail is expecting a reply?

Maybe have "r" turn into "R"?
r = The user requests a return receipt.
R = You already replied to this one.

(Of course, with your idea, these could be 'words' instead of just 1-char
markers.)

--887--


>202. When Killing items, you are given separate options to remove the
>  post and to kill the file.  This gives you the flexibility to keep
>  the description and responses that were made to a file while still
>  deleting the file.

That is a great new feature of v2.63!  But how do I use it?

I have kill-access on certain BBSes but only get:
1> Remove this post [No]?

I have kill-access on other BBSes but get:
2> Remove this post [No]?
2> Remove this file too [No]?

I need to give EVERYONE access like #2.

Does a user have to have 'kill-access' in addition to another flag?
(I hope not.)

--888--

The width of the VDE 'click-area' is still off slightly:

1> Handle              : SysOp
1>  ^                    ^
1>  |                    |

2> Handle              : SysOp
2> ^                     ^
2> |                     |

#1 (the current method) prevents the user from rolling the mouse to
the far left and doing a click-select.

#2 would be better.

Actually #3 would be GREAT!
3> Handle              : SysOp
3> ^                         ^
3> |                         |


--889--

D> The XSCRIPTS directory is just a storage location for the xscripts. I
D> don't believe there's ANY instance where cnet checks this directory. Place
D> the files individually in the S: directory. No modding is necessary to
D> your startup files.

I wish Ken WOULD have a specific scripts-dir recognized by CNet.
For transform scripts and all my other CNet scripts.
Currently your choices are 1 extreme or the other.
1)  Dump a ton of CNet-specific scripts into my already over-crowded s: dir.
    (358 non-CNet scripts and growing quickly.  I had to rename some of them  
    that conflicted with CNet's.)

2)  Place 50 copies of them 1-by-1 into 50 subs.
    (I don't use the sometimes handy "per-sub scripts" at all, so this is a   
    waste for me.)
 
--890--

DS>  It has only been implamented with about 25% of what needs to be done.

I was guessing more like 50%.  Until it gets up in the >70% range,
100s of SysOp are going to buy other software.  (Even at the cost of
forfeiting many of the other GREAT non-network features/powers that only CNet
has.)

I feel Ken has grossly underestimated the need/importance of Fido/UUCP.

CNet could easily take a large part of the current *3000* Amiga BBSes that are
currently running other software.  But NOT with 25% (your #, not mine) of
networking implemented.  And not with more (but no one knows how much)
networking support coming soon (but no one knows when).

CNet could easily become the only BBS anyone ever need run.

DS>    Trapdoor is so easy to setup.  It does everything and MUCH more then
DS> you
DS> will ever need.  I suggest that you set down and RTFM at least twice and I
DS> mean every word, it's so easy.

I'm still trying to read through some (not all) of TrapDoor's 7,300+
lines of docs.  (That does NOT include TrapToss's docs and the other
things I'm going to need to read, too.)

Read it twice?  14,600 lines?  I wonder how much the novice Fidonet
SysOp will get out of this enormous reading assignment.

Is this part of the "it's so easy" part?

--891--

What happens if you start to send an OLM and the user logs off?
The OLM is lost.

I'd like to see all 'undeliverable' OLMs just go into that person's
mailbox instead going to NIL.

--892--

> FIND: Download, *, Examine, Grab, Quit, [Pass]

After we do some DL'ing, *'ing, Examine'ing, and Grab'ing is there
a quick way to see the screen-full list of files again?

Maybe...
> FIND: [D]ownload, [*], [E]xamine, [G]rab, [Q]uit, [L]ist, [Pass]

--893--

> pw.c: Error 35 in cnet.h line 82: closing brace expected...

Try adding the following line BEFORE you try and include cnet.h:

> #include <exec/types.h>

Ken, please consider adding that line at the top of cnet.h.
It is needed by a couple HUNDRED references to BYTE/LONG/SHORT inside cnet.h.
Some pfiles may or may not be including "exec/types.h".  But since it is
needed by cnet.h 100% of the time, it probably wouldn't hurt to include it, by
default.  (No harm occurs if it accidently gets included twice.)

Also, ALL the cnet header files are in need of the standard:

> #ifndef    XPROTO_H
> #define    XPROTO_H
> // The code ///
> #endif // !XPROTO_H

to prevent (no matter how likely or unlikely) their being accidentally
include'ing twice.

--894--
 
 I'd like to state I'm against any new TERM features in *A BBS*.
 
 No bbs-term could equal all the slick features of a state of the art term.
 
 It takes just a second to take a node down and run your favorite term.
 (If it allows for shared-ports/resources, you don't even have to take the CNet
 node down at all.)
 
 O> much larger could it possibly make the program? 75-100k? Man if your
 O> hurting for 
 O> 75-100k on your hd; Its time for another one... Yes a Phonebook with a
 O> password bank
 
 A 100K (your #, not mine) increase would be a whopping 42% overall size
 increase.
  
--895--

Try the following from the sub-prompt:
> BG
> BROWSE: Download, *, Examine, Grab, Quit, Read, [Pass]: R1-

You can't [Q]uit or abort.  Ever.

--896--

The following line needlessly appears twice in cnetfunc.h
> void ExitSubboard( UBYTE quiet );

--897--

If IFIDO hits a sub that doesn't have a "Unique dirname" (or matching
"data" dir within it) on your HD, it enters an endless-loop constantly
looking for it.

Could IFIDO be made to any 1 (or more) of the following?
1)  Create the missing dir.
2)  Abort & report the dir's full path/name as "missing".
3)  Try x times, then give up.

Preferably, "Try x times", "Create the dir", "report full pathname".
ANYTHING is better than an endless-loop.

--898--

>ML x y   :  Exchange two subboards on the list of subboards.

Has anyone gotten "ML" to actually *EXCHANGE* subboards?
I can MOVE x into y's position.
But y doesn't move into x's old position.

I'm trying to *EXCHANGE* 1 and 30, like the docs say.

--899--

If you are going through the responses in an item, 1-by-1 and you
decide to kill 1 response, afterwards CNet skips to the last response.

Shouldn't it continue at your last-read-response?

(So you can continue reading/killing from that point.)

--EOF--

Sunday 25-Apr-93 04:05:33

-Bill "Mr. BBS" Beogelein, 313-473-2020, 2-line HST 14.4k USR DS, 1:2410/207



