--31--

Are there docs that list the line #s and their purpose in BBSTEXT?
A single missing line throws everything off by 1.

--32--

It might be tricky to do, but any plans on allowing swapping/moving
areas outside their current dir?

> ML 3 /
Move area #3 out of current dir, up 1 level.

--33--

I must be misunderstanding the way BBSMENU interprets things.
While trying to change some cmds around...

[E]xtract and [EX]it can't exists in the same area?

I thought [E] would always do #1.
[EX] would always do #2.
Significant to the first non-uppercase char.

--34--

Is there any way to make a YANK archive also include my custom
"BBS ad" file?  (So callers will know where they got the file from.)

And maybe add lines to BBSTEXT like:
> *** Top of YANKED file ***            (Intro)
> *** These msgs YANKED from %d %s ***  (%d=area #; %s=area name) 
> *** End of YANKED file ***            (Confirming fill wasn't chopped)
In case users need to call back and find the msg's area to
reply to something that they yanked earlier.

--35--

Could SAVE CONFIG from the control panel menu be made to also save/
load the position/size of a ZOOMED TO SMALL (wb2.0) window?  It
apparently saves/loads only the UNZOOMED window.  Users have to keep
positioning/sizing the ZOOMED window each time the BBS is rebooted.

--36--

Could the TO PRINTER pull-down menu be changed to pop-up a requester
with a string gadget?  By default it would be pre-loaded with "PRT:",
but could be altered to save to the quicker PAR: and well as any file
path/name too.

--37--

>                      Last   Setup  Period   Total Current
>Pfiles launched        1       7     125     125      -3
What's causing this "-3 current"?  (Seems to be there at all times,
regardless of whether a user is in a pfile or not.)

--38--

I notice the "O!" on some systems drops the carrier nearly immediately.
(The quicker, the better, for me.)
On others I see a delay, then +++, delay, ATH, delay, ATE0M1&H..., delay,
etc. before it disconnects.  The phone company has enough $$$.
(I assume this is something those SysOps have set-up in this manner.)

--39--

>(1) Browse (*, Read, Quit)
>Abort, Quit here, Skip dir, Post, [CONTINUE]:
Any plans on combining these 2 prompts into 1?

And a VERY welcome addition would be the ability to DROP this area
at that prompt also.

--40--

I notice C-net often looking for files such as:
> SysText:sys.info.-1
before successfully finding my:
> SysText:sys.info

Do I have something set wrong some place?

--41--

When I add a new base/udbase area is there anyway to NOT make
all users automatically JOINed?  I don't want to restrict it, just
let them decide to JOIN if they want to.

If I add a handful of new areas that WON'T be of interest to
90% of my users, I don't want to make 100% of them have to DROP
all those areas.

If I add a handful of new areas that WILL be of interest to
90% of my users, then I DO want it auto-joined.

>Auto-join (Yes/No)?: 

--42--

When editing FLAGS in a BASE, the default is still being reported as
the older "1;5;20;22" style instead of "1,5,20,22".
(This format isn't supported elsewhere.)

--43--

I had my paths set incorrectly.
C-net still continued to report all "Item filed." each time a msg was
'saved' to "Base0:r:OnDisk/post/44".  Of course, no msgs were ever
being saved anywhere.

Anyway to have Cnet respond with the correct:
>Item filed.
or
>Can't save to "Base0:r:OnDisk/post/44".
(Excellent debugging tool.)
(Maybe put it to the log also.)

--44--

How many people feel that ".R" from the editor should be a true
"as the msg will get posted" cmd?  Including area name/number, header
and signature.

I can't possibly remember which areas and which signatures I have/haven't
defined for every BBS I call.

Sometimes my signature is very inappropriate for my msg content.
Other times I end up signing a post, only to see it's already auto-
signatured.

--45--

Is there any reason why I wouldn't want to give TEST access to any/all
callers?  It just tests archive integity, right?  The SysOp wouldn't
have to do 100s of files, automaintenance wouldn't have to do it.

Seems likes an odd choice for a "SysOp only" cmd.  (Unless I'm missing
something here.)

--46--

Considering the dangerous possibilities of displaying files with MCI
expansion, could an option be added to the Arexx cmd 'sendfile' for
"expand" or "don't expand" MCI codes?

'sendfile' "FileName"         /* No expansion */
'sendfile' MCI "FileName"     /* With expansion */

I'd feel a lot better running 3rd party Arexx scripts knowing I could
do a quick "c:Seach #? MCI" and see all the MCI possibilities.
Better safe than sorry.

I'm not sure which other Arexx cmds do MCI codes, but some others might
need this safety-net also.  (query, sendmodem, sendstring, transmit)
(None of them mentioned in the manual state they expand MCI codes,
but some do.)

--47--

Are there any plans on allowing TERM and MONITOR to be executed from
the console?  (Or is it even possible?)  SysOp's could quickly look
what's happening on any other port without even opening the screen.
Do it all from a single local screen.  Keeping 5 screens closed would
save memory and I assume speed caller's screen updates and cut CPU
loads.

It would also be an excellent way to test/debug TERM/MONITOR.
Even 1-2 line systems could work with it.

--48--

>300   <-- Maximum number of messages to Yank at one time
When YANK is doing its gathering, could it check the file-size
of each msg?  Total these up as it runs, and allow the SysOp
to specify:
>120   <-- Maximum size of messages to Yank at one time (in K bytes)
instead of "msg count"?

After all, the whole point of that config variable is to avoid running
out of disk space.  Yanking 300 msgs of different types (Local/Fidonet/Usenet)
might be 1k/2k/4k each.  Making the bundle somewhere between 300k-
1.2megs.  Quite a "spread" to worry about when it comes to disk-space
full-up.

--49--

Who has a list of all the cmds available at the "login:" prompt?
Anyway to add/change these?
Perhaps a new "log-in" cmd group added to bbsMenu?
Or to avoid "cmd VS name" conflict, perhaps any log-in attempt that
starts with the "!" char is always considered a cmd and BBSMENU is
checked instead of the user-log.

--50--

Standard, official WB2.0 version-string specification is as:
>"$VER: v2.2a"      (Optional, a compile-date can be included too,)
Any executable (and even text/libs/devs/handlers) can quickly
have its version # located with the c:Version DOS cmd.

It should be present in ALL C-net stuff.

I've written an Arexx script that allows any callers to check any
version of any program anywhere on my HD.  Except all the ones
that don't follow this standard "$VER:" convention.  :-(

--51--

Any plans on changing the very non-mnemonic MORE prompt continuous-read
option?  To "C" instead of "=".

1)  More mnemonic
2)  Easier to reach (on the main keyboard)
3)  More commonly used on BBSes everywhere

--52--

> Charge item #  1
> Charge item #  2
> Charge item #  3
> ...
> Charge item #  32
> Charge item #  33
Is there a way to change these lines individually to reflect their
actually names as in bbsCharges?  I only see the 1 line "Charge item
#" in bbsText.  How do users know what these 33 items account for?
They are being charged upto 33 different ways.  What are they?
We ain't telling you.

And can unused item lines ($0.00) not be displayed at all?

Does amaint do anything with these totals?
(I need some big docs of EVERYTHING amaint does.)

-Bill Allen Beogelein, Amiga ShareWare HQ, 313-473-2020, 1:120/207
