GEMini Atari

home *** CD-ROM | disk | FTP | other *** search

/ GEMini Atari / GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso / files / bbs / fn132bin / fdman / chapter.13 < prev next >

Wrap

Text File | 1991-09-03 | 46KB | 1,133 lines

Chapter 13: Miscellaneous 151 13 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. 13.1 Things to Make Fnordadel Work or Work Better 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. See Appendix A [Fnordadel Support], page 170. Here are a few things you will *absolutely need* to avoid trouble: o If you have a hard drive, TOS 1.4 (or greater, like TOS 1.6 in the STE), or both, make sure you have foldr100.prg installed in your AUTO boot folder. You may not need 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 TOS. Even if you don't have a hard drive, TOS 1.4 and 1.6 will need these extra buffers because of bugs they have. o If you have TOS 1.4 or greater, you must also have poolfix3.prg installed in your `auto' boot folder. These versions of TOS have some bugs that are corrected by the poolfix program, so make sure it is correctly installed before going any further. We also include poolfix4, which is a version of poolfix3 with hacks to permit it to run in any position in your auto folder. (poolfix3 likes to be first, but so do some other auto programs.) poolfix4 is *NOT* from Atari; it was done by somebody else. Therefore, use it at your own risk. o If you have TOS 1.4 or greater, and wish to run your system with a high-speed modem, you will need to install tos14fx2.prg in your AUTO folder. This Atari fix solves a glitch with RTS/CTS flow control, something fairly necessary at speeds of 9600 bps and higher. Here are some things you will probably want, to make life nicer: o If you only have 512K of 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 RAMdisks and command shells. But they need memory to run. Pretty well all models of ST lose about 100K of RAM to GEM and 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. o 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 TOS (1.4 or 1.6, the latter available standard [and only] on the STE machines), then we *highly* recommend getting a TOS upgrade. Disk performance is *much* improved Chapter 13: Miscellaneous 152 under newer versions of 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 TOS also provide a lot of other enhancements and fixes that are worth having, especially if you use the GEM desktop a lot. o 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 GEM-based programs as well. 13.2 Logging and Debugging 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. 13.2.1 The call-log The call-log is kept in the file `calllog.sys', which is stored in your #auditdir. It records information about callers, file downloads that may occur, and system up/down times. It can be defined to document any or all of these things; see `ctdlcnfg.doc' for precise directions on how. Suffice it to say that if you define the `ctdlcnfg.sys' variable call-log to be `1', it will 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 System brought up <date> @ <time> will be written to `calllog.sys'. When the system is taken down, System brought down <date> @ <time> will be written. And when a user has called, you'll see a line of this form: <username> : <date> <in> - <out> (<baud>) [flags] The meanings are as follows: username is the name of the user; date is the date on which he/she called; in is the user's login time; out is the user's termination time; Chapter 13: Miscellaneous 153 baud is the baud rate at which the call was made, or ``console'' if the login was from the Console; flags documents anything unusual about the call. The following flags are defined: + New user. R User was denied access to the system due to a login restriction (see Section 10.2.11 [Login restrictions], page 139). P The user was punted off by the use of the [P]oll command from the Sysop's Net menu. e An event punted the user off (see Chapter 7 [Events], page 93). t The user timed out (meaning that he went for about 3 minutes without hitting a key). k The user was Killed while online (see [K]ill user in Section 5.2 [User Status Commands], page 80). p The user did a .T(erminate) P(unt), which restores all of his non-vital settings to their pre-call state. s The user did a .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. G A user on the Console was kicked off when carrier was detected; this happens if you're on the Console and you use `^L M' instead of [T]erminate. D The user unceremoniously disconnected without using [T]erminate. This doesn't hurt anything, but it's bad style. E The user was an ``EVILE'' user; he entered more than a tolerable number of consecutive bad commands, meaning that either 1. he's *really* clueless, or 2. he had extreme line noise problems. r The user was punted by having the modem reinitialised on him; this is accomplished by using [R]einitialise from the Sysop menu. c The user called, but was denied access to the system due to exceeding the maxcalls limit; see Section 10.2.4 [Calls per day], page 135. Chapter 13: Miscellaneous 154 T The user was denied access due to having exceeded the maxtime limit; see Section 10.2.5 [Connect time per day], page 135. C The user was denied access due to having exceeded the maxclosecalls limit; see Section 10.2.6 [Close calls per day], page 136. 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 callstat to process your call-log and generate some statistics about your system's usage. See `callstat.man' for details. 13.2.2 The file-log If you have the `ctdlcnfg.sys' variable audit-files set to `1', the system will keep a log of user file downloads from your system. The log is kept in a file called `filelog.sys', located in your #auditdir. 13.2.3 The net-log If you have the `ctdlcnfg.sys' variable netlog defined, or if you invoke citadel with `+netlog' on the command line, Fnordadel will keep a log of all network activity in a file called `netlog.sys', located in your #auditdir. Most of the 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. 13.2.4 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 citadel or can be defined in `ctdlcnfg.sys' (as with netlog above). They are debug and netdebug. 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. netdebug operates on network things; you'll notice that still more junk will get printed on the screen (and written to `netlog.sys' during networking when you have this turned on. Chapter 13: Miscellaneous 155 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. 13.2.5 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 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 `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 `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 -- `crash'. This file lives in the same directory as `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. `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. 13.3 Help Files One of the standard system directories defined in `ctdlcnfg.sys' is #helpdir; it's where the help files, menus and ``blurbs'' go. These files are all just standard 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 `.mnu' (the menus) and `.blb' (the ``blurbs'') should not be deleted or renamed, because Fnordadel looks for them specifically. Most of the files ending in `.hlp', however, are not bound by any such restriction, and may be renamed or disposed of at will. Exceptions are: `dohelp.hlp' general novice help; called by [H]elp `policy.hlp' system policy; force-fed to new users on their first call `summary.hlp' extended command summary; called by `.?' Chapter 13: Miscellaneous 156 `topics.hlp' the main hot-helps menu; called by .H(elp) ? In order to customize your system, you may create any number of `.hlp' files, and integrate them with the online help system (see Section 13.3.1 [Hot-help system], page 156). You will also want to edit some of the other help files provided. In particular, most of the `.blb' files should be looked at and changed as required, and `policy.hlp' and `localbbs.hlp' should be modified. The `.mnu' files should never need any modifications. 13.3.1 The hot-help system Any text file you like can be displayed by the .H(elp) command if it is in the #helpdir directory, ends with the extension `.hlp', 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: %topic<tab>Description The name topic must correspond to a help file ending in `.hlp', i.e. `topic.hlp'. All % 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 % 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 `.hlp' files is specify lines of the form %%Some text of your choice to give the help system the cue that `Some text of your choice' should be displayed while and *only* while it is processing the `.hlp' file in hot-help mode. Some `.hlp' files (e.g. `policy.hlp' and `summary.hlp') are called up both in the hot-help system and somewhere else, where the menu-handling procedure is not done. The %% 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 `society.hlp' (let's say we run a non-profit organisation...) This file might say something like this: 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. When the user types Chapter 13: Miscellaneous 157 .H(elp) society he or she will see: 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: If, for some reason, the 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: The Foobar Non-Profit Society Creedo: We are dedicated to being our society. 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. 13.3.2 BLurB files The following `.blb' files are referenced by Fnordadel. If they aren't present, your users will probably see a little error message which says `No help file <whatever>'. Or we may have had the foresight to build in a hard-wired message that actually means something sensible. `banner.blb' The opening banner; spit out to users when they first connect with your system. `banner.n' The optional rotating banner files, `banner.1' through `banner.n'. `deny.blb' Used only if you're running a closed system (loginok is `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. `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. Chapter 13: Miscellaneous 158 `fakeerr.blb' This is displayed to remote users when the Sysop hits the `^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. `logout.blb' A message printed after a user .T(erminate)s from the system, just before carrier is lost. `maxcalls.blb' A message given to users who are denied system access due to exceeding the maxcalls limit; see Section 10.2.4 [Calls per day], page 135. `maxclose.blb' This message is given to users who are denied system access due to exceeding the maxclosecalls limit; see Section 10.2.6 [Close calls per day], page 136. `maxmsg.blb' A message given to users who try to enter more messages in a room than allowed by the msgenter or mailenter limits; see Section 10.2.2 [Messages per room per call], page 134, and Section 10.2.3 [Mail messages per call], page 135. `maxtime.blb' A message given to users who are denied system access due to exceeding the maxtime limit; see Section 10.2.5 [Connect time per day], page 135. `newroom.blb' Printed whenever a non-Expert enters a new room. `nochat.blb' This is shown to any user who asks for a Chat while you have chat mode turned off. `notice.blb' After a user logs in but before he reaches the room prompt, he will be shown this file. `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. `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. Chapter 13: Miscellaneous 159 13.3.3 MeNU files The following `.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 `.blb' files, if they aren't present, your users will probably see a little error message which says ``No help file <whatever>''. `aide.mnu' .A(ide) ? `aideedit.mnu' `?' from the .A(ide) E(dit) menu, where the user logged in is only an Aide and not the Sysop or a Co-Sysop `aideflr.mnu' ;A(ide) ? `browser.mnu' `?' from the browser prompt `config.mnu' `?' from the .E(nter) C(onfiguration) prompt `ctdllist.mnu' `?' from the purge or restrict prompts `ctdlopt.mnu' `?' from the main Sysop menu (`^L') `ctdlstat.mnu' `?' from the user status menu (`^L U') `edit_inf.mnu' `?' from the room info editor `edit_msg.mnu' `?' from the message editor `entopt.mnu' .E(nter) ? `floor.mnu' `;?' `known.mnu' .K(nown) ? `lobbedit.mnu' `?' from the .A(ide) E(dit) menu, where the user logged in has Sysop or Co-Sysop status and the room being edited is Lobby> `logout.mnu' .T(erminate) ? Chapter 13: Miscellaneous 160 `mainopt.mnu' `?' from the room prompt `more.mnu' `?' from a .R(ead) M(ore) prompt (`More? ') `netedit.mnu' `?' from the net node edit menu (`^L N E') `netopt.mnu' `?' from the net menu (`^L N') `readopt.mnu' .R(ead) ? `roomedit.mnu' `?' from the .A(ide) E(dit) menu, where the user logged in has Sysop or Co-Sysop status `specedit.mnu' `?' from the .A(ide) E(dit) menu, where the user logged in has Sysop or Co-Sysop status and the room being edited is Aide> 13.4 Curious Feeps This is the *really* miscellaneous section---a place for stuff so miscellaneous, it doesn't even deserve a section of its own. 13.4.1 Uppercase elimination 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 *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 (`l') in place of a `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.) 13.4.2 <fnord>s 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. Chapter 13: Miscellaneous 161 <fnord> is a subliminal trigger word, and since BBSes are the ideal forum for perpetuating subliminal messages, we've thoughtfully bound the `P' key (at the room prompt level) to the <fnord>s. Simply put a file called `fnord.sys' in your #sysdir. It 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 `P'. The size of `fnord.sys' is practically unlimited, but it is all loaded into RAM when Fnordadel starts, so be very careful. Anyway, say your `fnord.sys' has the following lines: send money read my lips no newt axes! the Sysop's a babe Depending on the state of some random bits inside the machine, a user hitting `P' might see <fnord><no newt axes!> and will suddenly begin to wonder whether Mr Bush ever said anything about ``Taxes''. Or he might see <fnord><the Sysop's a babe> in which case you can expect a proposition in Mail>. Or, best of all, he might see <fnord><send money> 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 `fnord.sys' file. 13.4.3 User timeouts 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 sysopsleep parameter in `ctdlcnfg.doc'. Chapter 13: Miscellaneous 162 13.4.4 New user message viewing 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 `ctdlcnfg.sys' parameter called newusermsgs which lets you set how many messages the system will think are new to each new user calling in. It defaults to `50' if you don't set it otherwise. If you set it to `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... 13.4.5 User configuration defaults 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 `ctdlcnfg.sys' flags that you can diddle to give your novice users the ``correct'' combination of features: defshowtime, deflastold, deffloormode, defreadmore, defnumleft and defautonew. See `ctdlcnfg.doc' for more. 13.4.6 Status line 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 citadel with the +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. The flags consist of `R', which indicates a Sysop console request is pending (see Section 5.3.1 [Special keys], page 83); `T', which indicates the current user is a twit (see Section 5.3.1 [Special keys], page 83, see Section 2.1 [Your Callers], page 14); `C', which indicates chat mode is currently enabled (see Section 5.1 [Sysop Special Functions], page 75); and `*', 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. Chapter 13: Miscellaneous 163 13.4.7 Rotating banners We received several requests to implement __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 `banner.1', `banner.2', `banner.3', etc. in your #helpdir directory. Leave the existing `banner.blb' file there. Then define the `ctdlcnfg.sys' parameter #numbanners to be the number of banners you want to rotate through. You can set the parameter #bannerblb to `1' if you want the system to display `banner.blb' following the rotating banner it picks at random, or to `0' if the rotating banner files should stand alone. 13.5 File Locations 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. #auditdir `calllog.sys' The call-log `filelog.sys' The user file transfer log `netlog.sys' The network activity log `debuglog.sys' The debugging log `chat.rec' Text from captured Chat sessions `sysop.msg' Where archived Sysop mail goes (if enabled) `callstat.sys' Useful statistics written by callstat `callbaud.sys' Supplementary useful statistics from callstat #helpdir *.hlp Help files *.mnu Menus *.blb ``Blurbs'' Chapter 13: Miscellaneous 164 #holddir `holdnnnn' Held message for user #nnnn #msgdir `ctdlmsg.sys' The message base #netdir `ctdlnet.sys' The net-list `ctdlloop.zap' The loop-zapper database `ctdlpath.sys' Path alias definitions `dial_n.prg' External dialer programs `n.ml' Semi-temporary files for net-mail to node #n `n.nfs' Semi-temporary files for file sends/requests for node #n `n.fwd' Semi-temporary files for mail forwarding to node #n `xxxxxxx.dis' Discard message files #roomdir `roomnnnn.sys' The room files (where nnnn = 0000 to (maxrooms - 1)) `roomnnnn.inf' The optional room info files (where nnnn = 0000 to (maxrooms - 1)) #sysdir `citadel.lck' Lockfile used by citadel and many others; helps prevent dangerous collisions when using doors or a multi-tasking system. `ctdllog.sys' The user log `ctdlflr.sys' The floors file Chapter 13: Miscellaneous 165 `ctdldoor.sys' Door definitions `ctdlarch.sys' Room archiving information `alias.sys' Shared room aliasing definitions `purge.sys' List of users to whom the purge feature will apply `restrict.sys' List of users to restrict login to `fnord.sys' Silly sayings for the `P' key `calldata.sys' Cumulative data maintained by callstat `checkpt.sys' Checkpoint file for configur 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: `ctdltabl.sys' The system tables file; needed by almost everything, including citadel. Regenerated by configur. `crash' If there's been a crash and Fnordadel saw it coming, this is where it puts a report. 13.6 Multitasking and Fnordadel 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. To activate Fnordadel for use in a multi-tasking environment, as a background process, invoke citadel with the option `+multi', and using whatever mechanism your multitasker needs to indicate a background process. (See the options section of `citadel.man'.) At this point in time, all this option does is basically shut off Fnordadel's screen output so that Chapter 13: Miscellaneous 166 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. 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 `^LQ' command. To reconnect Fnordadel to the console, run the utility sysop, which tells the system to listen up. Fnordadel will once again display things on your monitor and listen to the keyboard. See `sysop.man'. To send the system back into the background again, you can hit `^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! See Section 5.3.1 [Special keys], page 83, for more info about `^Z'. Also see Section 8.1.3.4 [Special net keys], page 103. Most Fnordadel utility programs that need to update `ctdltabl.sys', or other system files, will check for the existence of the `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. *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. 13.7 Fnordadel vs. STadel 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 `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 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 `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 Chapter 13: Miscellaneous 167 `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 `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 `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 `ctdlroom.sys' file. Since the file can't be regenerated by configur, the effect was to lose your entire message base even though the `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; 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 #roomdir directory onto a small 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 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. Chapter 13: Miscellaneous 168 13.8 Compatibilities, Incompatibilities, and Fixes This section is for miscellaneous facts we've come across that could affect your Fnordadel due to other products' behavior. o 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. (See Section 13.1 [Things to Make Fnordadel Work or Work Better], page 151.) o 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. o 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. o 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. 13.9 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 Chapter 13: Miscellaneous 169 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 *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.