@comment Tell Emacs to use -*-texinfo-*- mode
@comment $Id: misc.tex,v 2.4 91/09/01 23:04:31 royce Exp $

@node Miscellaneous, Fnordadel Support, File Transfers, Top
@chapter Miscellaneous

Yup, this is the good old "miscellaneous" chapter, that place
where we put stuff which either didn't seem to fit into any other chapter,
or which we figured didn't deserve a chapter of its own.  So here we go.

@node Things to Make Fnordadel Work or Work Better, Logging and Debugging, Miscellaneous, Miscellaneous
@section Things to Make Fnordadel Work or Work Better
@cindex Speedups
@cindex Efficiency improvements

Most of the programs we mention in this section are available on RT and
secret.  If you can't find them anywhere else, phone one of our systems.
@xref{Fnordadel Support}.

Here are a few things you will @emph{absolutely need} to avoid trouble:

@itemize @bullet
@item
If you have a hard drive, @sc{tos} 1.4 (or greater, like @sc{tos} 1.6 in the
STE), or both, make sure you have @code{foldr100.prg} installed in your
AUTO boot folder.  You may not need @code{foldr100.prg} if you have access
to another program that does a similar function, for example
Revolver from Intersect Software or the hard drive boot handler
supplied with newer ICD host adaptor-based hard drives.  Both of
these products allow you to allocate buffers for extra folders,
a necessary thing due to bugs in @sc{tos}.  Even if you don't have a
hard drive, @sc{tos} 1.4 and 1.6 will need these extra buffers because of
bugs they have.

@item
If you have @sc{tos} 1.4 or greater, you must also have @code{poolfix3.prg}
installed in your @file{auto} boot folder.  These versions of @sc{tos} have
some bugs that are corrected by the @code{poolfix} program, so make sure
it is correctly installed before going any further.  We also include
@code{poolfix4}, which is a version of @code{poolfix3} with hacks to
permit it to run in any position in your auto folder.  (@code{poolfix3} likes
to be first, but so do some other auto programs.)  @code{poolfix4} is
@emph{NOT} from Atari; it was done by somebody else.  Therefore, use it at
your own risk.

@item
If you have @sc{tos} 1.4 or greater, and wish to run your system with a
high-speed modem, you will need to install @code{tos14fx2.prg} in your
AUTO folder.  This Atari fix solves a glitch with @sc{rts}/@sc{cts} flow
control, something fairly necessary at speeds of 9600 bps and higher.

@end itemize

Here are some things you will probably want, to make life nicer:

@itemize @bullet
@item
If you only have 512K of @sc{ram}, you might want to consider getting an
upgrade to 1MB, especially if you do not own a hard drive.  There
are a lot of things that can make running your system easier and
more enjoyable, such as @sc{ram}disks and command shells.  But they need
memory to run.  Pretty well all models of ST lose about 100K of
@sc{ram} to @sc{gem} and @sc{tos}.  Fnordadel itself needs another 200K or so.
On a machine with 512K tops, memory can disappear pretty quickly,
leaving little or no room for the niceties.

@item
No matter what model of ST you have, and whether you have a hard
drive or not, if you do not have a new version of @sc{tos} (1.4 or 1.6,
the latter available standard [and only] on the STE machines),
then we @emph{highly} recommend getting a @sc{tos} upgrade.  Disk performance is
@emph{much} improved under newer versions of @sc{tos}, although if you are
running on floppy disks you won't notice it much due to their
inherently slow access times and data transfers rates.  The new
versions of @sc{tos} also provide a lot of other enhancements and fixes
that are worth having, especially if you use the @sc{gem} desktop a lot.

@item
A display ``accelerator'', such as the excellent Quick ST, from
Branch Always Software, is a useful addition.  Early versions of
Quick ST are available
in the public domain, so try to get ahold of a copy and try it
out.  If you like it, you can pick up the commercial version for
about $20.  Quick ST provides a very nice speed-up to all screen
display operations used in Fnordadel, and many operations used
in @sc{gem}-based programs as well.
@end itemize

@node Logging and Debugging, Help Files, Things to Make Fnordadel Work or Work Better, Miscellaneous
@section Logging and Debugging
@cindex Logging

Fnordadel has various ways of logging its actions for your later
perusal.  They include the call-log and the net-log.  In addition, there
are both normal and network-specific debugging flags for still more useless
information.

@node The call-log, The Net-Log, Logging and Debugging, Logging and Debugging
@subsection The call-log
@cindex Caller activity log

The call-log is kept in the file @file{calllog.sys}, which is
stored in your @code{#auditdir}.  It records information about callers,
@vindex auditdir
file downloads that may occur, and system up/down times.  It can
be defined to document any or all of these things; see @file{ctdlcnfg.doc}
for precise directions on how.  Suffice it to say that if you
define the @file{ctdlcnfg.sys} variable @code{call-log} to be @samp{1}, it will
@vindex call-log
cause a call-log to be kept, documenting system up/down times as
well as caller information, but not file downloads.

When the system is brought up, a line of the form

@example
System brought up @var{<date>} @@ @var{<time>}
@end example

@noindent
will be written to @file{calllog.sys}.  When the system is taken down,

@example
System brought down <@var{date}> @@ <@var{time}>
@end example

@noindent
will be written.  And when a user has called, you'll see a line
of this form:

@example
<@var{username}>          :  <@var{date}> <@var{in}> - <@var{out}> (<@var{baud}>) [@var{flags}]    
@end example

@noindent
The meanings are as follows:

@table @var
@item username
is the name of the user;
@item date
is the date on which he/she called;
@item in
is the user's login time;
@item out
is the user's termination time;
@item baud
is the baud rate at which the call was made, or
``console'' if the login was from the Console;
@item flags
@cindex Caller activity flags
documents anything unusual about the call.  The
following flags are defined:
@table @code
@item +
New user.
@item R
User was denied access to the system due
to a login restriction (@pxref{Login restrictions}).
@item P
The user was punted off by the use of the
@code{[P]oll} command from the Sysop's Net menu.
@item e
An event punted the user off (@pxref{Events}).
@item t
The user timed out (meaning that he went
for about 3 minutes without hitting a key).
@item k
The user was Killed while online (see @code{[K]ill user} in
@ref{User Status Commands}).
@item p
The user did a @code{.T(erminate) P(unt)}, which
restores all of his non-vital settings to
their pre-call state.
@item s
The user did a @code{.T(erminate) S(tay)}.  This
means that he logged off without hanging
up; this is a good clue as to the identity
of the next person to login.
@item G
A user on the Console was kicked off when
carrier was detected; this happens if
you're on the Console and you use @samp{^L M} instead
of @code{[T]erminate}.
@item D
The user unceremoniously disconnected
without using @code{[T]erminate}.  This doesn't
hurt anything, but it's bad style.
@item E
The user was an ``EVILE'' user; he entered
more than a tolerable number of consecutive
bad commands, meaning that either
@enumerate
@item
he's @emph{really} clueless, or
@item
he had extreme line noise problems.
@end enumerate
@item r
The user was punted by having the modem
reinitialised on him; this is accomplished
by using @code{[R]einitialise} from the Sysop menu.
@item c
The user called, but was denied access to
the system due to exceeding the @code{maxcalls}
limit; see @ref{Calls per day}.
@item T
The user was denied access due to having
exceeded the @code{maxtime} limit; see @ref{Connect time per day}.
@item C
The user was denied access due to having
exceeded the @code{maxclosecalls} limit; see @ref{Close calls per day}.
@end table
@end table

The call-log is one of the few things in Fnordadel that
are not self-maintaining; it will continue to grow indefinitely,
so it needs to be periodically deleted.  You may wish to use the
utility program @code{callstat} to process your call-log and
@pindex callstat
generate some statistics about your system's usage.  See
@file{callstat.man} for details.

@node The file-log
@subsection The file-log
@cindex File transfer logging

If you have the @file{ctdlcnfg.sys} variable
@vindex audit-files
@code{audit-files} set
to @samp{1}, the system will keep a log of user file downloads
from your system.  The log is kept in a file called @file{filelog.sys},
located in your @code{#auditdir}.

@node The net-log, Debugging, The Call-Log, Logging and Debugging
@subsection The net-log
@cindex Network logging

If you have the @file{ctdlcnfg.sys} variable @code{netlog} defined,
@vindex netlog
or if you invoke @code{citadel} with @samp{+netlog} on the command line,
@pindex +netlog (citadel)
Fnordadel will keep a log of all network activity in a file
called @file{netlog.sys}, located in your @code{#auditdir}.  Most of the
@vindex auditdir
junk that gets printed to the screen during any networking is
written to this file, so you'll have a pretty good idea of what
your system's been up to.  If you do any long-distance networking,
it's probably a good idea to watch this file regularly to keep
tabs on mail transfers, failed calls, and anything else that
costs you money.

As with the call-log, the net-log can get quite large
quite quickly, so keep an eye on it and nuke it every now and
then.  If you find yourself never looking at it, you may simply
wish to stop telling Fnordadel to keep it.  If you're not
running with a hard drive, you probably won't have room for
this file.

@node Debugging, Crashes, The Net-Log, Logging and Debugging
@subsection Debugging
@cindex Debugging

Ah yes, debugging---we know it's our favourite!
Fnordadel has a couple of debugging options which can be
specified on the command line to @code{citadel} or can be defined
in @file{ctdlcnfg.sys} (as with @code{netlog} above).  They are @code{debug}
and @code{netdebug}.
@pindex +debug (citadel)
@pindex +netdebug (citadel)
@vindex debug
@vindex netdebug

@code{debug} causes seemingly random debugging stuff to be
printed out at seemingly random times; it won't affect the
operation of the board at all, though.

@code{netdebug} operates on network things; you'll notice that
still more junk will get printed on the screen (and written to
@file{netlog.sys} during networking when you have this turned on.

In general, you shouldn't have to worry about stuff like
this, but if you're having a problem and we tell you to turn
debugging on to help track it down, you'll know what to do.

@node Crashes,  , Debugging, Logging and Debugging
@subsection Crashes
@cindex Crashes

Sadly, your Fnordadel will probably crash on you at
some point.  You'll come up to the system, switch on the monitor,
and see the screen come to life showing the @sc{gem} desktop or your
favorite command shell, not your Fnordadel!  Aie!  What to do?

Happily, most crashes encountered by Fnordadel can be
semi-gracefully handled.  This means that the system is able to
write out the @file{ctdltabl.sys} file and prevent you from having to
reconfigure your system.  You should be able to start right
back up if you see that @file{ctdltabl.sys} is there.

Just to be on the safe side, though, Fnordadel will
stick a message about the crash in a file called -- oddly --
@file{crash}.  This file lives in the same directory as @file{ctdltabl.sys},
so look for it and read it if it's there.  There's an outside
chance it might tell you something useful.  If your system
crashes and you can't find a crash file, that means the crash
was a bad one.  @file{ctdltabl.sys} probably won't be there either, so
you'll have to reconfigure things.  It would probably be in
your best interest to reboot your system as well.

@node Help Files, Curious Feeps, Logging and Debugging, Miscellaneous
@section Help Files
@cindex Help files

One of the standard system directories defined in @file{ctdlcnfg.sys} is
@code{#helpdir}; it's where the help files, menus and
@vindex helpdir
``blurbs'' go.  These files
are all just standard @sc{ascii} text, and are therefore freely editable by
the Sysop.  We think the set provided with Fnordadel is pretty good,
but nothing is above improvement.

In general, the files ending in @samp{.mnu} (the menus) and @samp{.blb} (the
``blurbs'') should not be deleted or renamed, because Fnordadel looks for
them specifically.  Most of the files ending in @samp{.hlp}, however, are not
bound by any such restriction, and may be renamed or disposed of at will.
Exceptions are:

@table @file
@item dohelp.hlp
general novice help; called by @code{[H]elp}
@item policy.hlp
system policy; force-fed to new users on their first call
@item summary.hlp
extended command summary; called by @samp{.?}
@item topics.hlp
the main hot-helps menu; called by @code{.H(elp) ?}
@end table

In order to customize your system, you may create any number of @samp{.hlp}
files, and integrate them with the online help system
(@pxref{Hot-help system}).  You will also want to edit some of the other help
files provided.  In particular, most of the @samp{.blb} files should be
looked at and changed as required, and @file{policy.hlp} and
@file{localbbs.hlp} should be modified.  The @samp{.mnu} files should never
need any modifications.

@node Hot-help system, BLurB files, Help Files, Help Files
@subsection The hot-help system
@cindex Hot-help system

Any text file you like can be displayed by the @code{.H(elp)} command
if it is in the @code{#helpdir} directory, ends with the extension @samp{.hlp},
@vindex helpdir
and your users can find out its name.  However, if your help files
contain special codes,
they can be made to point to other (hopefully related) help files.
This is encoded in a help file by placing lines of this form in it:

@example
%@var{topic}<tab>@var{Description}
@end example

The name @var{topic} must correspond to a help file ending in @samp{.hlp},
i.e. @file{topic.hlp}.  All @code{%} lines in a file
will be assigned a letter, and when the help file has finished printing
out, the user will be prompted to enter a letter corresponding to
the further help file he wishes to read.  Don't put too many @code{%} lines
in any given file, though, or the first few will scroll off the top
of the screen before the prompt appears.
 
Another thing you can do in the @samp{.hlp} files is specify
lines of the form

@example
%%Some text of your choice
@end example

@noindent
to give the help system the cue that @samp{Some text of your choice}
should be displayed while and @emph{only} while it is processing the
@samp{.hlp} file in hot-help mode.  Some @samp{.hlp} files (e.g. @file{policy.hlp} and
@file{summary.hlp}) are called up both in the hot-help system and somewhere
else, where the menu-handling procedure is not done.  The @code{%%}
lines, which you can use as headings or what have you, will thus
appear when the file is being used as a menu, and disappear when it
is being used as a one-shot display of information.

An example will make this easier to figure out.  Suppose
that we have a help file called @file{society.hlp} (let's say we run a
non-profit organisation@dots{})  This file might say something like
this:
@example
The Foobar Non-Profit Society Creed:
We are dedicated to being our society.

%%For more information on the Non-Profit Society, see:

%MEETINGS       Times and locations of upcoming meetings.
%MEMBERS        The most recent membership list.
%GOSSIP         Neat new gossip from our members.
@end example
@noindent
When the user types
@example
.H(elp) society
@end example
@noindent
he or she will see:
@example
The Foobar Non-Profit Society Creed:
We are dedicated to being our society.

For more information on the Non-Profit Society, see:

[A] MEETINGS    Times and locations of upcoming meetings.
[B] MEMBERS     The most recent membership list.
[C] GOSSIP      Neat new gossip from our members.

Select [A-C] or [RETURN] to exit:
@end example
@noindent
If, for some reason, the file @file{society.hlp} was ever
displayed to the user by one of the other help mechanisms in the code
he or she would see the following:

@example
The Foobar Non-Profit Society Creedo:
We are dedicated to being our society.
@end example

At this point the user will do as instructed, we hope.
Using the hot-help system carefully allows you to construct a
hierarchical sort of help system; see the distribution help file
set for an example of this.

@node BLurB files, MeNU files, Hot-help system, Help Files
@subsection BLurB files
@cindex .blb files
@cindex Blurb files

The following @samp{.blb} files are referenced by Fnordadel.
If they aren't present, your users will probably see a little
error message which says @samp{No help file @var{<whatever>}}.
Or we may have had the foresight to build in a hard-wired message
that actually means something sensible.

@table @file
@item banner.blb
The opening banner; spit out to users when
they first connect with your system.
@item banner.@var{n}
The optional rotating banner files, @file{banner.1} through
@file{banner.@var{n}}.
@item deny.blb
Used only if you're running a closed
system (@code{loginok} is @samp{0}).  It is shown to
new users; it should say something about
how new users need to leave the Sysop
mail to get an account.
@item entry.blb
This is printed for non-Expert users when
they are about to enter a message; it should
say stuff about how the formatter works
and so on.
@item fakeerr.blb
This is displayed to remote users when the Sysop hits the
@samp{^E} command on the console.  Say what you like, but
if you're courteous, you'll put something in that's
suitably apologetic for your cavalier butchering of the
user's login session.
@item logout.blb
A message printed after a user @code{.T(erminate)}s
from the system, just before carrier is lost.
@item maxcalls.blb
A message given to users who are denied
system access due to exceeding the @code{maxcalls}
limit; see @ref{Calls per day}.
@item maxclose.blb
This message is given to users who are denied
system access due to exceeding the
@code{maxclosecalls} limit; see @ref{Close calls per day}.
@item maxmsg.blb
A message given to users who try to enter
more messages in a room than allowed by the
@code{msgenter} or @code{mailenter} limits; see
@ref{Messages per room per call},
and @ref{Mail messages per call}.
@item maxtime.blb
A message given to users who are denied
system access due to exceeding the @code{maxtime}
limit; see @ref{Connect time per day}.
@item newroom.blb
Printed whenever a non-Expert enters a new
room.
@item nochat.blb
This is shown to any user who asks for a
Chat while you have chat mode turned off.
@item notice.blb
After a user logs in but before he reaches
the room prompt, he will be shown this file.
@item password.blb
This blurb is shown to new users just before
they select a password; it should say
something about picking something not easily
guessed.
@item restrict.blb
A ``we're closed, call back later'' message
used when a login restriction results in a
user being barred from using the system.
@end table

@node MeNU files,  , BLurB files, Help Files
@subsection MeNU files
@cindex .mnu files
@cindex Menu files

The following @samp{.mnu} files are referenced by Fnordadel.
They are printed out whenever a user hits a question mark at various
points.  There should never be any need to change them; they may be
updated by us as new features are added to Fnordadel.  As with
@samp{.blb} files, if they aren't present, your users will probably see
a little error message which says ``No help file <@var{whatever}>''.

@table @file
@item aide.mnu
@code{.A(ide) ?}
@item aideedit.mnu
@samp{?} from the @code{.A(ide) E(dit)} menu, where the
user logged in is only an Aide and not the Sysop or a Co-Sysop
@item aideflr.mnu
@code{;A(ide) ?}
@item browser.mnu
@samp{?} from the browser prompt
@item config.mnu
@samp{?} from the @code{.E(nter) C(onfiguration)} prompt
@item ctdllist.mnu
@samp{?} from the purge or restrict prompts
@item ctdlopt.mnu
@samp{?} from the main Sysop menu (@samp{^L})
@item ctdlstat.mnu
@samp{?} from the user status menu (@samp{^L U})
@item edit_inf.mnu
@samp{?} from the room info editor
@item edit_msg.mnu
@samp{?} from the message editor
@item entopt.mnu
@code{.E(nter) ?}
@item floor.mnu
@samp{;?}
@item known.mnu
@code{.K(nown) ?}
@item lobbedit.mnu
@samp{?} from the @code{.A(ide) E(dit)} menu, where
the user logged in has Sysop or Co-Sysop status and
the room being edited is @code{Lobby>}
@item logout.mnu
@code{.T(erminate) ?}
@item mainopt.mnu
@samp{?} from the room prompt
@item more.mnu
@samp{?} from a @code{.R(ead) M(ore)} prompt (@samp{More? })
@item netedit.mnu
@samp{?} from the net node edit menu (@samp{^L N E})
@item netopt.mnu
@samp{?} from the net menu (@samp{^L N})
@item readopt.mnu
@code{.R(ead) ?}
@item roomedit.mnu
@samp{?} from the @code{.A(ide) E(dit)} menu, where
the user logged in has Sysop or Co-Sysop status
@item specedit.mnu
@samp{?} from the @code{.A(ide) E(dit)} menu, where
the user logged in has Sysop or Co-Sysop status and
the room being edited is @code{Aide>}
@end table

@node Curious Feeps, File Locations, Help Files, Miscellaneous
@section Curious Feeps
@cindex Feeping creatures

This is the @emph{really} miscellaneous section---a place for stuff
so miscellaneous, it doesn't even deserve a section of its own.

@node Uppercase elimination, <fnord>s, Curious Feeps, Curious Feeps
@subsection Uppercase elimination
@cindex Uppercase, elimination thereof

The system converts messages from upper-case-only folks to
lower-case, then does a simple capitalization algorithm.  This is
lots easier on the eyes of those who actually read messages.  This
feature does, however, trip up people who actually @emph{intended} a
message to be all upper-case.

If you include even one lower-case
character in a message, the conversion and capitalisation thing will
not be done, so a standard trick is to put a lower-case L (@samp{l}) in
place of a @samp{1} somewhere.  I've seen people do this l0 times,
just to be sure!  (Credit where credit is due -- we didn't
put this one in, it came with STadel, but was probably put in by
Hue, Jr. in Citadel-86, or even CrT in the original CP/M Citadel.)

@node <fnord>s, User timeouts, Uppercase elimination, Curious Feeps
@subsection <fnord>s
@cindex Fnords
@cindex Subliminal <fnord><vote Rhino> messages

Fnordadel is a somewhat whimsical piece of software.  Some of
its features have been hacked in on the spur of the moment; others just
seemed to materialise.  The authors' primary reason for working on the
software at all is just ``because it's neat''.  So, we occasionally break
from ``serious hacken'' and put in bits of silliness or weirdness.  The
<fnord> feature is one such bit.

<fnord> is a subliminal trigger word, and since @sc{bbs}es are
the ideal forum for perpetuating subliminal messages, we've
thoughtfully bound the @samp{P} key (at the room prompt level) to
the <fnord>s.

Simply put a file called @file{fnord.sys} in your @code{#sysdir}.  It
@vindex sysdir
should contain a list of silly sayings, one per line, which will be chosen
from at random and spit at the user when he (always mistakenly) hits @samp{P}.  The size of @file{fnord.sys} is practically unlimited, but it is all loaded
into @sc{RAM} when Fnordadel starts, so be very careful.
Anyway, say your @file{fnord.sys} has the following lines:

@example
send money
read my lips
no newt axes!
the Sysop's a babe
@end example

Depending on the state of some random bits inside the machine, a
user hitting @samp{P} might see

@example
<fnord><no newt axes!>
@end example

@noindent
and will suddenly begin to wonder whether Mr Bush ever said
anything about ``Taxes''.  Or he might see

@example
<fnord><the Sysop's a babe>
@end example

@noindent
in which case you can expect a proposition in @code{Mail>}.  Or, best of
all, he might see

@example
<fnord><send money>
@end example

@noindent
and, if you've thoughtfully put your mailing address in, say, a
help file (or perhaps in another <fnord>), the money will roll in.
Neat, huh?

To disable <fnord>s, if you don't like 'em, just get rid
of the @file{fnord.sys} file.

@node User timeouts, New user message viewing, <fnord>s, Curious Feeps
@subsection User timeouts
@cindex Idleness, user timeouts because of
@cindex Timeouts due to user idleness
@cindex User timeouts due to idleness

It's an annoying thing to have users monopolize your system
for large chunks of time, but it would be even more annoying if they
did so by spending long minutes idly sitting at a command prompt
somewhere.  To prevent this, Fnordadel has a timeout feature that
it inherited from STadel: if a user's session is idle (i.e. no screen
or keyboard activity) for 3 minutes or so, the system will print a
cutesy message and log him/her off.  This timeout can also apply to
console users such as the Sysop, if you wish it.  See the @code{sysopsleep}
@vindex sysopsleep
parameter in @file{ctdlcnfg.doc}.

@node New user message viewing
@subsection New user message viewing
@cindex New users, message reading by

Another annoying thing is having a new user call in (at 300
baud, too, wouldn't you know it!) and read every message in every room
on your system.  Argh!  Well, there is a @file{ctdlcnfg.sys} parameter called
@vindex newusermsgs
@code{newusermsgs} which lets you set how many messages the system will
think are new to each new user calling in.  It defaults to @samp{50} if you
don't set it otherwise.  If you set it to @samp{0}, all messages will be new.
This variable helps the user's first call to get him/her the gist of what's
being discussed, without swamping her/him with an overload of info, or
crippling your system with massive connect times.  Of course, it
doesn't help on subsequent calls@dots{}

@node User configuration defaults
@subsection User configuration defaults
@cindex User configuration, defaults
@cindex Defaults for user configuration

We had a request to allow the Sysop to set default values for some of
the user configuration values that new users aren't asked about if
they claim not to be Citadel experts.  To that end, there are currently
several @file{ctdlcnfg.sys} flags that you can diddle to give your novice users
the ``correct'' combination of features: @code{defshowtime}, @code{deflastold},
@code{deffloormode}, @code{defreadmore}, @code{defnumleft} and
@code{defautonew}.  See
@vindex defshowtime
@vindex deflastold
@vindex deffloormode
@vindex defreadmore
@vindex defnumleft
@vindex defautonew
@file{ctdlcnfg.doc} for more.

@node Status line
@subsection Status line
@cindex Status line

@pindex citadel
@pindex +line (citadel)
One of the most popular additions orc made to STadel was the status line, an
inverse mode, non-scrolling line of user information placed at the bottom
of the console screen.  It is activated by invoking @code{citadel} with
the @code{+line} option.  This gets you at-a-glance information about an
online user, including user name, current room, time of login, current
time, and some flags.

@cindex Status line flags
The flags consist of @samp{R}, which indicates a Sysop console request is
pending (@pxref{Special keys}); @samp{T}, which indicates the current user
is a twit (@pxref{Special keys}, @pxref{Your Callers}); @samp{C}, which
indicates chat mode is currently enabled (@pxref{Sysop Special Functions});
and @samp{*}, which indicates that the user has an unanswered chat request
outstanding.

If the status line is not active, Fnordadel will display some information
about the user just before each room prompt as the user moves about the
system.  This information is shown only on the console.

@node Rotating banners
@subsection Rotating banners
@cindex Rotating banners
@cindex Banners, rotating
We received several requests to implement @dfn{rotating banners}, something
Hue, Jr. recently put into his Citadel-86.  Figuring we'd already blown any
possible reputation for seriousness, we figured ``what the heck'', and here
they are.

To use rotating banners on your system, create a number of files called
@file{banner.1}, @file{banner.2}, @file{banner.3}, etc. in your
@vindex helpdir
@code{#helpdir} directory.  Leave the existing @file{banner.blb} file there.
Then define the @file{ctdlcnfg.sys} parameter
@vindex numbanners
@code{#numbanners} to be the number of banners you want to rotate through.
You can set the parameter
@vindex bannerblb
@code{#bannerblb} to @samp{1} if you want the system to display
@file{banner.blb} following the rotating banner it picks at random, or to
@samp{0} if the rotating banner files should stand alone.

@node File Locations, Multitasking and Fnordadel, Curious Feeps, Miscellaneous
@section File Locations
@cindex System files
@cindex Files, where they all live

The following is a more-or-less complete list of where Fnordadel
expects to find which files (or where you can find files that Fnordadel
deposits).  Don't shoot us if we've missed one, though.

@table @code
@item #auditdir
@vindex auditdir
@table @file
@item calllog.sys
The call-log
@item filelog.sys
The user file transfer log
@item netlog.sys
The network activity log
@item debuglog.sys
The debugging log
@item chat.rec
Text from captured Chat sessions
@item sysop.msg
Where archived Sysop mail goes (if enabled)
@item callstat.sys
Useful statistics written by @code{callstat}
@pindex callstat
@item callbaud.sys
Supplementary useful statistics from @code{callstat}
@end table

@item #helpdir
@vindex helpdir
@table @code
@item *.hlp
Help files
@item *.mnu
Menus
@item *.blb
``Blurbs''
@end table

@item #holddir
@vindex holddir
@table @file
@item hold@var{nnnn}
Held message for user #@var{nnnn}
@end table

@item #msgdir
@vindex msgdir
@table @file
@item ctdlmsg.sys
The message base
@end table

@item #netdir
@vindex netdir
@table @file
@item ctdlnet.sys
The net-list
@item ctdlloop.zap
The loop-zapper database
@item ctdlpath.sys
Path alias definitions
@item dial_@var{n}.prg
External dialer programs
@item @var{n}.ml
Semi-temporary files for net-mail to node #@var{n}
@item @var{n}.nfs
Semi-temporary files for file sends/requests for node #@var{n}
@item @var{n}.fwd
Semi-temporary files for mail forwarding to node #@var{n}
@item @var{xxxxxxx}.dis
Discard message files
@end table

@item #roomdir
@vindex roomdir
@table @file
@item room@var{nnnn}.sys
The room files (where @var{nnnn} = 0000 to (@code{maxrooms} - 1))
@item room@var{nnnn}.inf
The optional room info files (where @var{nnnn} = 0000 to (@code{maxrooms} - 1))
@end table

@item #sysdir
@vindex sysdir
@table @file
@item citadel.lck
Lockfile used by @code{citadel} and many others; helps
prevent dangerous collisions when using doors or a
multi-tasking system.
@item ctdllog.sys
The user log
@item ctdlflr.sys
The floors file
@item ctdldoor.sys
Door definitions
@item ctdlarch.sys
Room archiving information
@item alias.sys
Shared room aliasing definitions
@item purge.sys
List of users to whom the purge feature will apply
@item restrict.sys
List of users to restrict login to
@item fnord.sys
Silly sayings for the @samp{P} key
@item calldata.sys
Cumulative data maintained by @code{callstat}
@pindex callstat
@item checkpt.sys
Checkpoint file for @code{configur}
@end table

@end table

In addition, a few files are expected to live in Fnordadel's home
directory (i.e., the directory in which Fnordadel is run).  These are:

@table @file
@item ctdltabl.sys
The system tables file; needed by almost everything,
including @code{citadel}.  Regenerated by @code{configur}.
@item crash
If there's been a crash and Fnordadel saw it coming,
this is where it puts a report.
@end table

@node Multitasking and Fnordadel, Fnordadel vs. STadel, File Locations, Miscellaneous
@section Multitasking and Fnordadel
@cindex Multitasking

Some time before orc ceased work on STadel, he made some modifications
to it to make it operate a little nicer in a multi-tasking environment on the
Atari ST.  The multi-tasker he specifically tested was AMULTI, but MX2, MiNT
and Multi-GEM are three others we know of as of this writing.  The first three
are public domain,
all four should be used only if you know what you're doing, and none of them
is guaranteed to work properly or reliably with Fnordadel, since we've
never done a lick of work to make sure Fnordadel will live properly with
them.  However, it's on our list of things to do when we get time, so don't
hesitate to send reports of your experiences with Fnordadel and
multitasking.  Any information we can get from out there will make us that much
better prepared to tackle any problems there may be.

@pindex citadel
@pindex +multi (citadel)
@cindex Background process, Fnordadel as a
To activate Fnordadel for use in a multi-tasking environment, as a background
process, invoke @code{citadel} with the option @samp{+multi}, and using
whatever mechanism your multitasker needs to indicate a background process.
(See the options section of @file{citadel.man}.)  At this point in time, all
this option does is basically shut off Fnordadel's screen output so that the
display doesn't get messed up while you're doing other things, and make the
system ignore keyboard input from the console.  All other activities continue
as normal, including networking.

@cindex Foreground, bringing Fnordadel to
Once Fnordadel is running in the background, you will probably want to
bring it to the foreground at some point.  At the very least, you will
have to do this when you want to shut Fnordadel down, since the only way
to properly take the system down is using the @samp{^LQ} command.  To
reconnect Fnordadel to the console, run the utility
@pindex sysop
@code{sysop}, which tells the system to listen up.  Fnordadel
will once again display things on your monitor and listen to the keyboard.
See @file{sysop.man}.

To send the system back into the background again, you can hit @samp{^Z}
at the console.  Fnordadel will stop displaying to the screen and taking
input from the console keyboard.  Make sure you're logged out and the
system is back in modem mode when you do this!  @xref{Special keys}, for
more info about @samp{^Z}.  Also see @ref{Special net keys}.

@cindex Multitasking lock file
@cindex Lock file
Most Fnordadel utility programs that need to update @file{ctdltabl.sys}, or
other system files, will check for the existence of the @file{citadel.lck}
file that was mentioned briefly in the last section.  If the file is present,
the utility will abort, otherwise it will go ahead and do its thing.
@emph{Be warned}, however, that there may be a utility or three that doesn't
behave properly in this regard.  Thus if you are running Fnordadel in the
background, be very careful to avoid clobbering something by running Fnordadel
updating utilities at the same time.

@node Fnordadel vs. STadel, Compatibilities, Multitasking and Fnordadel, Miscellaneous
@section Fnordadel vs. STadel
@cindex STadel vs. Fnordadel

This section is for those of you who are converting up from STadel.
If you aren't converting, you can read it for trivia, or ignore it.  We have
developed a converter program to take STadel 3.3d systems to the current
version of Fnordadel, hopefully preserving all important system files.  See
the @file{conv33d.doc} document for details on conversion.

Since Fnordadel is directly descended from STadel 3.3b, with many
pieces borrowed from STadel 3.4a (which never got released, that we know of),
most of the things you liked about STadel will still be here.  We added this
section mainly because many of you who convert will probably notice right
away that some things, such as running @code{configur} or saving messages, seem
slower with Fnordadel.  You're not imagining things, and before you get
homicidal or erase Fnordadel from your system, we want to explain.

Some of you may have noticed that the slow-down seems related to room-oriented
operations.  If so, you hit the nail on the head.  From the conversion
process, you'll know there is a big difference in how rooms are done.  This is
what causes the speed difference as well, and is the only aspect in which
Fnordadel is slower than STadel.  Hopefully we can temper the shock with
good reasons for the change.

STadel (and other Cits) use a single file to store rooms, called
@file{ctdlroom.sys}.  The file is opened once when the system starts, and closed once
when it exits.  All rooms occupy a fixed-size record in @file{ctdlroom.sys}, and
accessing the records requires seeking to the record, followed by one read or
write operation to transfer all the room's data.

Some time ago, we got sick and tired of the 58 messages per room limit,
along with all the other limits (64 rooms per system, 16 shared rooms per net
node, etc.)  We got rid of them all in a similar fashion to Hue, Jr.'s method
of eliminating the limits in Citadel-86, by allowing the Sysop to define the
limits himself in @file{ctdlcnfg.sys}, and alter them on the fly with various
utility programs.  With the messages per room limit, however, we chose a
different approach.

Any fixed number of messages per room, we reasoned, will be inefficient
since there will rarely-approaching-never be exactly that number of messages
in any room.  If there are too few messages, the extra space in the room
record will be wasted, while if there are too many messages, they can't all
fit and thus you'll have space in @file{ctdlmsg.sys} wasted by messages that
nobody can ever see.

We therefore decided to make the room records vary in size so they are
always exactly as big as required to fit the number of messages really in each
room.  No more wasted space in the room records, and no more wasted space in
the message file.  Unfortunately, we could no longer store the room records in
one file, since their varying size would be practically impossible to deal
with in the confines of a single file.

Consequently, we broke the room file up into one file per room, each
now able to be whatever size required to store the number of messages in it.
This gave us the desired space efficiency.  It also improved damage control;
with STadel, a bad sector or corrupted room record would wipe out the whole
@file{ctdlroom.sys} file.  Since the file can't be regenerated by
@code{configur}, the
effect was to lose your entire message base even though the @file{ctdlmsg.sys} file
was perfectly intact!  Now with Fnordadel, a bad sector or corrupted room
record causes the loss of only one room, not the entire message base.

Sadly, the improved space efficiency and security has a price.  No
longer do we have the single room file, which is opened once, closed once and
accessed via one read or write operation per room.  Now, with one file per
room, each file must be opened and closed each time it is accessed (we can't
have them all open at once; @sc{tos} has limits on this kind of thing).  This
opening and closing takes time.  Also, we can't use a single read or write to
access the room record, since it varies in size.  We first read or write the
fixed-size part of the record (name, status flags, etc.), then the variable-sized
part (message pointers).  This double read/write also takes extra time.

The net result is a common one: to improve efficiency, you sacrifice
speed, and vice versa.  We're working on ways to get every extra jot of speed
out of the new code, but it will probably always be slower than the older
method.  One thing that will help speed it up is to throw the @code{#roomdir}
@vindex roomdir
directory onto a small @sc{ram} disk.  If you do this, make sure you back up
the directory to disk regularly, either manually or using a command shell and
automated scripts.  If you choose not use the @sc{ram} disk, take some comfort
in knowing that the slower room access times are not for nothing, they are
buying you much increased space efficiency and system reliability.

@node Compatibilities, Beta Releases of Fnordadel, Fnordadel vs. STadel, Miscellaneous
@section Compatibilities, Incompatibilities, and Fixes

This section is for miscellaneous facts we've come across that could
affect your Fnordadel due to other products' behavior.

@itemize @bullet
@item
Turbo ST, a commercial display accelerator, causes the Fnordadel
status line to freak out.  We don't know of any version of Turbo
ST that works properly.  Our advice is to get ahold of a program
called Quick ST, by Branch Always Software.  It's what we use, and
it works great.  (@xref{Things to Make Fnordadel Work or Work Better}.)

@item
We've heard a lot of reports about various doors (usually games)
that do not work properly, but we're usually unable to discover
any particular problems since we don't run many doors ourselves.
If you have trouble with a door that is publicly available, the
best approach is to send us a copy of it along with detailed
instructions on how to duplicate your troubles.  Then we'll see
if we can fix things.  If you can't send us the door for some
reason, send us a detailed description of your problem, and we
might be able to figure out what's going on anyway.  If you're
writing your own doors and run into trouble, send us your code
(if you're programming in C), or your executable program (if
you're programming in anything else), and we'll look into it.

@item
As reported by kbad@@Virtuality, Fnordadel appears to work like
a charm on the Atari TT030.  So if your ego requires you to have
the hottest Fnordadel this side of Virtuality, run out and buy a
TT for yourself.

@item
So-called ``packer'' programs are popular here and there, especially
with users running without the Amazing Benefits of a hard drive.
These packers compress other executable programs just like archiving
programs such as LHarc, Arc and Zoo.  The difference is that the
compressed programs can still be run as before, with the nicety that
they take much less disk space to store.  The only cost is that they
take slightly more time to load and execute, since they must
uncompress themselves on the fly.

For users running on floppy drive(s), and finding that space is a
problem, we have two comments.  First, space is always a problem,
even with a hard drive.  Second, get ahold of a packer
program from your favorite Atari ST file transfer board, and try it
out on the Fnordadel programs and utilities.  We don't guarantee
that they will pack, or run properly if packed, but it's worth a try.
@end itemize

@node Beta Releases of Fnordadel,  , Compatibilities, Miscellaneous
@section Beta Releases of Fnordadel
@cindex Beta releases of Fnordadel

We put Fnordadel out in ``releases'', rather than small, random
upgrades to different programs.  However, the large majority of the
releases are ``beta'', i.e. they have some deficiency, and we don't
necessarily want everybody under the sun to take that version and start
running it.  Normally, beta releases are sent to a select few ``beta
sites'', run by Sysops who understand and accept the risks involved with
running beta software that might have problems.  They have agreed to
actively help us solve any problems that come up in the code they run,
and we fully expect them to give us detailed bug descriptions (not ``It
doesn't work!''), try out new things we've put in to see if they work,
and give us general feed-back whether we ask for it or not.

Up until now, we have been pretty slack about who gets the beta
releases.  We have a small number of beta sites that we deal directly with,
but if other people really want to run the beta versions, they can do so,
providing they can get ahold of them somewhere.  Anybody who gives out a
beta release to a non-beta site is expected to clearly communicate that the
software is @emph{not} of public, production quality, and also that the manuals
frequently have not been updated to reflect all changes.  We do not make
any kind of guarantees to anybody who runs a beta release that they got
from somebody besides us.
