Documentation

ALLFIX User Manual

Complete documentation for ALLFIX v6 — the most complete FileEcho utility available. Originally ALLFIX v6.00, updated for v6.1.x.

Table of Contents

1. Introduction

2. What is ALLFIX?

3. FidoNet Technology

4. Fileechos and Magic Files

5. FCOMP

6. ASETUP

7. ALLFIX

8. Cookies

9. FIXUTIL

10. HATCH

11. CRC32

12. Hints

13. Development

14. Credits

15. Technical Specs

1. Introduction

1.1 ALLFIX help and support

The ALLFIX_HELP echomail area is available on most fidonet backbones. The area is read and moderated by the author and it is the ideal place to ask questions concerning ALLFIX. Each registration site also carries the area.

It is also possible to receive support by sending mail to the following fidonet address:

1:218/720

or to the following Internet address:

ken@blkdoor.com

You can also find us on the Internet, at:

allfix.app

or

allfix.app

It is also possible to send questions and problem reports to the following postal address:

Ken Johnson Reno, NV USA

2. What is ALLFIX?

ALLFIX was born in 1991 when it introduced the FileFind concept which allows BBS users to search for files via echomail. As time progressed it slowly began to develop into a fileecho processor. A fileecho processor is a utility that distributes files between BBS systems. Files are actually sent and recieved by a fidonet style mailer. ALLFIX then places the received files into the proper BBS directories and sends the files to all of the downlinks who have subscribed to those file areas.

Today, ALLFIX is perhaps the most complete fileecho processor available. It can process .TIC files, hatch new files, generate new file reports based on newly received files and on uploaded files, process file requests, and, of course, process FileFind requests.

ALLFIX is accompanied by a very user friendly configuration program that makes the installation process a pleasure. The user interface is modelled after TosScan and Gecho, which many people have grown accustomed to.

This manual is for the following types of ALLFIX:

ALLFIX for DOS, ALLFIX! for WildCat, ALLFIX/2 for OS/2 Warp, and ALLFIX Universal

There are some important differences between these three different versions. The changes will be pointed out whenever necessary by refering to ALLFIX, ALLFIX!, ALLFIX/2, and ALLFIX/U for the four different types, respectively. Menu options that are specific to one or two versions of ALLFIX will contain those versions within parenthesis after the menu name. In the following example, the text (ALLFIX/2) indicates that the "New task" option is only available in the ALLFIX/2 for OS/2 version.

New Task (ALLFIX/2)

2.1 What is new in this version

In each ALLFIX release we try to solve as many bugs and other problems as possible. In addition to that, we also add new features requested by you and others who use ALLFIX. For a detailed list of what has been added, fixed, and changed in this version, please take a look at the UPDATE.LOG and the WHATSNEW.LOG files.

2.2 Features

This chapter contains a list of some of the features that ALLFIX offers.

  • ALLFIX has full support for RemoteAccess (1.xx and 2.xx), SuperBBS, QuickBBS, Ezycom, Maximus, ProBoard, PCBoard 15.xx and any conventional FILES.BBS style BBS. There is also limited support for SpitFire, Telegard, Renegade, TriBBS, TAG, TBBS, LoraBBS, Synchronet BBS, Concord BBS, ShotGun, Terminate BBS, Magic BBS, and PowerBBS.
  • ALLFIX! for WildCat! has full support for the WildCat! 4.xx file and message database.
  • Full support for Zones, and 4D points.
  • Support for domains (5D addressing)
  • Ability to disable sending a .TIC file.
  • Ability to pack all .TIC files with or without the accompanying file into one "TIC" archive.
  • ALLFIX supports the FrontDoor/RemoteAccess Hudson Message Base sharing specifications.
  • ALLFIX has direct support for the Hudson message base, JAM message base, *.MSG message base, Squish message base, the Ezycom message base, the PCBoard message base, and the .PKT interface.
  • ALLFIX! has full support for the WildCat! message base and for the .PKT interface.
  • ALLFIX has full support for the new FrontDoor Static Transmission Queue database, also known as STQ.
  • Support for multiple compression formats, such as ARC, ARJ, PAK, LZH, ZIP, SQZ, and up to 4 user definable compression programs.
  • User friendly ‘TosScan alike’ setup program. ALLFIX does not require any configuration files used by any other program.
  • Writes FrontDoor, D’Bridge, RemoteAccess, SuperBBS, BinkleyTerm, and Portal of Power compatible log file.
  • Full support for BinkleyTerm and Portal of Power.
  • Full support for D’Bridge queue files (D’Bridge versions 1.53 and higher).
  • Full support for T-Mail file boxes.
  • Very HIGH quality performance, very LOW registration fee.

2.3 System Hardware and Software Requirements

ALLFIX for DOS and for WildCat! have the following system requirements:

  • IBM PC, XT, AT or 100% compatible, with hard drive.
  • Microsoft MS-DOS or IBM PC-DOS 3.0 or higher.
  • At least "FILES=20" in the CONFIG.SYS

A lower value can cause an "Out of file handles" error.

A disk cache (especially one that can buffer disk writes, such as Norton Cache or HyperDisk) can improve performance, but, of course, it is not required. If a disk cache is not being used, then the line "BUFFERS=30" (or higher) should be added to the CONFIG.SYS to improve performance.

  • At least 460 KB of RAM available. It is also preferable to have at least 700KB of EMS available. ALLFIX uses EMS for two purposes. First, the overlay file can be loaded into EMS, and secondly, it swaps itself into EMS when calling other programs, such as PKZIP.
  • At least one of the supported BBS systems.
  • For ALLFIX!, WildCat! 4.xx.
  • At least one of the following compression utilities: PKZIP 1.10, LHA 2.13, PKPAK, ARC, PAK, ARJ 2.00, or SQZ 1.0.

ALLFIX for OS/2 has the following system requirements:

  • IBM 386 or higher, or 100% compatible, with hard drive.
  • IBM OS/2 version 2.1 or higher.
  • At least one of the supported BBS systems.
  • At least one of the following compression utilities: PKZIP 1.10, LHA 2.13, PKPAK, ARC, PAK, ARJ 2.00, SQZ 1.0, or any OS/2 equivalents.

ALLFIX Universal has the following system requirements:

  • IBM 386 or higher, or 100% compatible, with hard drive.
  • An operating system or memory manager which supports the DPMI 0.9 standard, such as one of the following:

Windows 3.1x, Windows 95, Windows NT, OS/2 Warp, Qualitas 386MAX and Quarterdeck QEMM-386

  • At least one of the supported BBS systems.
  • At least one of the following compression utilities: PKZIP 1.10, LHA 2.13, PKPAK, ARC, PAK, ARJ 2.00, SQZ 1.0, or any OS/2 equivalents.

2.4 License and Disclaimer

"ALLFIX" refers to all executables and documentation as distributed in the compressed file in which the package was released and on the installation disk.

  • ALLFIX is copyrighted material by Ken Johnson. It may only be used in agreement with the conditions set out in this license agreement.
  • ALLFIX is released as shareware.
  • The following applies to all persons who can afford to register ALLFIX: you may use ALLFIX for an evaluation period of one month. After this period you MUST either register ALLFIX or stop using it.
  • You must register ALLFIX if you wish to make use of the registered features which are denoted by a {+} in the configuration program.
  • ALLFIX may be distributed freely provided no money or any other compensation is asked or accepted without prior written permission from the author.
  • Although care has been taken to write and test a program that does what this document states, ALLFIX is provided as is, without warranty or guarantee of any kind, either expressed or implied, as to the fitness for a particular purpose or quality or performance of this program, except that ALLFIX will occupy disk space.
  • In no event shall Ken Johnson be liable to you or anyone else for any damages or cost, including, but not limited to, any lost profits, lost savings or lost income which may a result from the use or inability to use ALLFIX.
  • In no way is Harms Software Engineering obligated to you or anyone else to provide future versions of, or support for ALLFIX.
  • Harms Software Engineering reserves the right not to release future shareware versions of ALLFIX, but switch to a commercial "buy before you try" marketing concept.
  • Your use of ALLFIX constitutes your agreement to this license and disclaimer and your release of the author from any form of liability or litigation.
  • If you are currently using an unregistered version of ALLFIX, then you are asked to make a small advertisement for ALLFIX, in the login procedure for your BBS system.

The ALLFIX package represents over 70,000 lines of source code and countless hours of hard work.

ALLFIX is released under the shareware concept. This means that you are allowed to use ALLFIX for a trial period of 30 days. If you want to continue using ALLFIX after the 30 day trial period, you are required to register the program.

A number of features in ALLFIX only become available after you have registered the program. These features are identified with the string "{+}" after their help descriptions in ASETUP. This manual will also mention when an option is only available after registering.

To  register, file  request ALLFIX.REG  from the  registration site

nearest you. Fill out the form and send it back to the registration site along with the necessary payment. The file REGISTER.HOW contains more information about the registration process and a list of all the registration sites.

of the listings and a description was included.

3. FidoNet Technology

3.1 Network structure

FidoNet is the largest amateur network in the world. It was started in 1984 by Tom Jennings. Currently more than 35,000 nodes worldwide are connected. The network has a hierarchic tree (or star) topology:

+——————————+———————-> | | zone 1 zone 2 | | +—- -+ — – – — – – –+ +——–+——–+ | | | | | | region region region region region region | | | | | | +–+- – -+ | + -+ -+ + – —+—+ | +–+–+ | | | | | | | | | | | net net net net net net net net net net net | +—–+—–+ | | | node node node | +—+—+ | | point point

Zones are divided in Regions, which are divided in Nets. The Nets consist of Nodes, which are usually (but not necessarily) Bulletin Board Systems. Each node has a unique address which consists of four parts: Zone, Net, Node and Point, in text form expressed as "zone:net/node.point". Zone numbers 1 up to and including 6 are used by FidoNet:

1 = North America (United States of America and Canada) 2 = Europe and Commonwealth of Independent States 3 = Oceania (Australia and New Zealand) 4 = Latin America 5 = Africa

6 = Asia

There are several other networks that use FidoNet Technology and which occupy higher zone numbers (such as SIGnet, zones 24-29).

Many nodes have one or more points. A point is a user who gets mail from a node (its "boss") in compressed files. That way they can read and write messages offline, saving time and money. The point address of the boss is 0, but the ".0" is usually omitted from the address.

3.2 Mail transfer and the FileFind system

The FileFind system offers people the ability to search for files via echomail by writing messages addressed to the name "ALLFIX", without quotes. The files, file specifications, and keywords (preceded by a ‘/’) are placed on the subject line. The message body may be left empty.

ALLFIX will scan the configured message areas and process all FileFind requests. It will scan the BBS file areas and if any matches are found, it will write a reply in the appropriate area.

Since the FileFind requests are sent via echomail, one request may receive multiple replies. One problem with this system is that the flow of mail may easily get out of hand. ALLFIX has a number of features to reduce the amount of mail. First, no more than 15 files will be included in a reply. Second, it has the ability to ignore any local FileFind requests. Third, ALLFIX will not process FileFind requests that contain less than 4 non-wildcard characters (ie. characters other than the ‘?’ and ‘*’ wildcards). Lastly, ALLFIX has the ability to ignore FileFind requests that are older than the configured number of days.

To  facilitate searching for files,  ALLFIX supports two elementary

boolean operators; AND and OR. These operators may be used between filespecs and keywords.

Ex. /SOUND AND /32bit

In the previous example, ALLFIX will search for files that have both the keyword SOUND and the keyword 32bit in the description.

Ex. /SOUND AND /32bit OR /SOUNDBLASTER

In the previous example, ALLFIX will search for files with the keyword SOUND and the keyword 32bit in the description, or for any files with the keyword /SOUNDBLASTER in the description.

Sometimes a keyword may contain the special character "/". ALLFIX will normally interpret that as a special character signalling that the rest of the text entered is a keyword. In order to prevent ALLFIX from doing that, the keyword can be enclosed in double quotes. For example, when searching for the keyword OS/2,

it should be specified as "OS/2" and not as /OS/2 which may be interpreted incorrectly by ALLFIX.

previous chapter for more details).

There are two formats supported for the fileecho areas listing. The first format consists of a list of fileechos and the corresponding descriptions.

Example: [fileecho] [description]

The second format is the format used by the FILEBONE.NA file:

Example: Area [fileecho] [priv level] [locks] [description]

Following is a description of all the fields.

Uplink system

The network address of the uplink system.

AreaFix program

The name that ALLFIX should write the uplink request to. For example, the string "ALLFIX", without quotes, should be entered for uplink systems using ALLFIX.

Password

The password that ALLFIX should put on the subject line of the uplink request.

Add ‘+’ prefix

Should ALLFIX add a ‘+’ in front of fileecho tags. Most modern AreaMgr programs do not require a ‘+’, but including it should not cause any problems.

Authorized groups

The requesting node must have access to at least one of these groups.

Unconditional

Forward all requests to this uplink, as long as the requesting system has access to one of the groups. ALLFIX will first look in the Areas file (see next option). If the area is listed in that file, then ALLFIX will use the description from that area as the description for the new fileecho (please see the priorities concerning the new description, explained above). This option is only available in the registered version.

Areas filename

File   containing  a  list  of  the  fileecho  tags  that  are

available from this system.

File format

This is the type of fileecho areas listing that is being used. Please see the paragraph above for the supported formats. The fileecho areas listing must be stored in the directory configured in the Pathnames (part 2) menu (see section 6.3.3).

Origin address

The aka to use for any uplink requests. ALLFIX can not rely on AKA matching because fileechos from more than one zone may be received from one system and the AreaMgr requests may need to originate from different AKAs in order to signal the zone for the requested area.

Direct

Use the direct flag for uplink request messages.

4. Fileechos and Magic Files

4.1 Fileechos explained

The files that are received and sent along the network structure are organized in areas, called fileechos, much the same as messages are organized in echomail areas. Files are received by one system and "echoed" to other systems.

Each fileecho has a name, referred to as the "tag". Locally, a fileecho also has a large number of other options, such as the directory where files belonging to this fileecho are stored (think of messages areas for echomail areas).

Each file passed along in a fileecho is accompanied by a .TIC file. This is a small ASCII text file containing information about the associated file, such as the fileecho tag, the description, and the address where the file came from.

Following is a sample .TIC file:

Area FNEWS
Origin 1:218/720
From 1:218/720
To 1:140/0
Replaces FNEWS*.*
File FNEWS931.ZIP
Desc Fidonet Newsletter
Crc FE5B85F3
Created  by  ALLFIX/2+, v5.13.004  Copyright (C)  1992,99  by Harms

Software (1:218/720)

Path  1:218/720@Fidonet 926124765 FRI MAY 7  23:52:45 1999 UTC-0100

0EF0F39E

Seenby 1:218/720
Seenby 1:140/31
Seenby 1:140/32
Seenby 1:140/33
Seenby 1:140/34
Seenby 1:140/35
Seenby 1:140/36
Seenby 1:140/37
Seenby 1:140/38
Seenby 1:140/39
Pw WOW

The first word on each line in the .TIC file is called the verb. The meaning of the verbs will be explained in the next section.

4.1.1 TIC file verbs

Following is a description of what each TIC verb means.

Area

The fileecho tag.

Areadesc

The description for this particular fileecho. This particular verb is currently only supported by ALLFIX. When fileechos are automatically added, ALLFIX will use the description following this verb for the new fileecho.

Desc

The description of the file. Some other programs may add more than one description line to the .TIC file. ALLFIX will append any extra description lines to the first one.

Ldesc

The long description of the file. This particular command is currently only supported by ALLFIX and FileMgr. The long description is usually a more detailed version of the normal description and normally consists of several lines.

Origin

The network address of the system that hatched this file.

From

The system where this file was received from.

To

This field indicates who the .TIC file is for. This verb is currently only supported by ALLFIX. This verb is only included in the .TIC file when the file is being routed via another system. The presence of this verb prevents another ALLFIX from processing a .TIC file if it is destined for another system. Only if this verb is not present or if the address following it belongs to the current system, will the .TIC file be processed.

Crc

The 32-Bit Crc of the file. This field is used to check the integrity of the file. ALLFIX, by default, checks the Crc of all incoming files. The -NoCrc switch can be used on the commandline to force ALLFIX to not check the Crc.

Replaces

The file specification that this new file should replace. If enabled, ALLFIX will remove all the files that match the file specification before importing the current file. For example, if the .TIC file contains the following line:

Replaces NODEDIFF.A12

then ALLFIX will remove the file NODEDIFF.A12 from the file database and delete the actual file before importing the new file. This feature is handy for new software updates. Care should be taken since it possible to include wildcards. ALLFIX will, by default, ignore this verb, unless the option has been turned on in the fileecho configuration.

Magic

The magic name that should be updated in the mailer alias file. ALLFIX will add the current file with the magic name following this verb to the alias file to allow for file requests.

Created

This command is used to add information about which program created this TIC file.

Path

This extra line is added by each system that has processed this file. This line contains the unix date, a normal time and date stamp, and the address of the system that processed the file. The path lines can be used to determine how the file arrived its current destination.

Seenby

This line indicates that the corresponding system has ‘seen’ the associated file. A .TIC file usually contains several

Seenby  lines. ALLFIX  will not  forward  files to  any system

already in the seenby listing. ALLFIX will display a warning if a system in the systems list is already in the seenby list, making it easier to detect loops in file nets.

Pw

The password for this particular system. If the password is missing or incorrect, then ALLFIX will refuse to import the file.

4.1.2 TIC archive packages

Each time a file is forwarded in a fileecho, a new netmail message is created with the appropriate file attach. Large systems will

quickly have problems with too many netmail messages slowing the system down.

ALLFIX is capable of compressing all the forwarded files and/or the .TIC files for a system into one archive. The advantages are that only one file is sent to a system which means that only one netmail with a file attach is required.

Because TIC archive packages can grow to be quite large, ALLFIX has the ability to set the maximum size of such a package. When a TIC archive approaches this maximum size, ALLFIX will automatically create a new archive.

The naming convention that ALLFIX uses for TIC archive packages is as follows:

The first eight digits of the filename are used to code the destination system’s node number. ALLFIX can calculate a name based on the node number, but it is not possible to determine the system’s node number based on the filename of the TIC archive. The extension of the TIC archive filename always begins with the letter "C" and ends with two digits. The two digits are follow up numbers. In some situations, more than one TIC archive needs to be created per system. In that case, the follow up numbers are incremented. The system has an added benefit that if two identical TIC archives arrive at a system, the mailer may automatically increment the last character of the filename, in order to prevent the original file from being over-written. In the case of a TIC archive, following the ALLFIX naming convention, the follow up number is incremented, which does not affect ALLFIX in any way. If the filename was based on the older naming convention, one would end up with file names that were no longer recognized as TIC archives.

ALLFIX will also automatically unpack the file ALLTICS.xxx (where xxx is a number). This file contains .TIC files and is used in the Planet Connect file distribution network.

4.2 Magic filenames explained

The magic filename system is a powerful tool that allows the user to perform specific tasks when certain files are received in certain fileechos. ALLFIX has a large number of pre-configured tasks and one of them allows external DOS utilities to be executed, making it possible to do almost anything.

One example of a possible use for magic filenames is automatically processing new node editfiles or new nodelists. The magic filename system can be configured to call up batch file that will unpack the files and call up the nodelist processor each time one of those files is received.

All the different features are explained in the section about the magic filename manager.

5. FCOMP

FCOMP is a utility that compiles BBS file area configurations into a format that ALLFIX can read. FCOMP is not necessary for ALLFIX! for WildCat, since this type only supports one BBS. It was stated earlier that ALLFIX does not need configuration files from any other program. ALLFIX will function properly without the BBS file area information, however, a number of features are not available unless FCOMP has been run.

The BBS file area information is used for three things:

– FileFind replies require that the BBS file areas are scanned for files.

– New file reports for new files uploaded to your BBS require that the BBS file areas are scanned for new files.

– If the BBS system does not use a FILES.BBS file database system, then ALLFIX needs to be able to determine which file area needs to be updated when a file is being imported.

The advantage of using an external compiler is that support for other BBS programs can sometimes be added by simply making an update of FCOMP as opposed to releasing a new version of ALLFIX.

FCOMP creates a file called FILEAREA.FIX which is stored in the system directory. The information stored in FILEAREA.FIX needs to be updated when changes are made to the file area configuration in the BBS. Running FCOMP multiple times will not affect the ALLFIX configuration unless areas, needed by ALLFIX, are removed from the BBS configuration. Adding areas in the BBS configuration will not require any maintenance in the ALLFIX configuration.

5.1 Command line options

FCOMP requires two command line options.

The first option is the number associated with the BBS system used.

0 RemoteAccess 1.11 1 SuperBBS 2 QuickBBS 3 Maximus 2.0x 4 Ezycom 5 ProBoard 6 RemoteAccess 2.xx * 7 Renegade 4.16 8 PCBoard 15.xx * 9 SpitFire* 10 Telegard 2.17

* 11 TriBBS 12 EzyCom 1.10 13 Tag 14 v04-05 * Renegade 15 RemoteAccess

  • 2.5x/EleBBS

16 SearchLight

  • (Not available in ALLFIX/2)

17 TBBS (Specify path and filename of file area configuration file) * 18 LoraBBS 2.40 19 Telegard 3.0 * 20 TriBBS 10.x * SynchroNet BBS 2.x 22 Maximus 3.0x 23 Concord 0.01 gamma 3 24 QuickBBS 2.76 25 ShotGun Professional 1.38 26 Terminate BBS 27 Magic BBS 28 PowerBBS 29 AdeptXBBS 1.11+ (Only available in ALLFIX/2 and ALLFIX/U) * 30 BBBS (FCOMP will process all filedirg.??? files) 31 Tornado BBS 32 Telegard BBS 3.10

255 Scan fileechos

The second option that FCOMP needs is the path to the BBS configuration files. This second parameter is not necessary when you choose to scan the fileechos.

Example: FCOMP 0 C:\RA

* Note: ALLFIX only has support for the file systems for these BBS systems. There is no support for the message base systems.

Please consult the section 12.6 for information about how to use ALLFIX with a BBS system that is not supported.

It should be noted that ALLFIX can detect file sizes and file dates in text based file database files. For example, if a particular BBS uses standard FILES.BBS files, then the file size and the file date are not included in the FILES.BBS files. It could be possible that the system has a number of CD-ROMs online for which the FILES.BBS files use a different structure, namely one where the file size is included in the list. When reading a description from the FILES.BBS files, the file size would normally become part of the description since it was not expected. ALLFIX is capable of recognizing this and will skip the file size and the file data fields if they are present.

Special considerations for ProBoard:

If the BBS system used is ProBoard, ALLFIX will automatically update the UPLOAD.LOG file which is maintained by ProBoard. This file is located in the ProBoard system directory and contains a list of all of the uploaded files, who uploaded them, and when.

6. ASETUP

6.1 Installation

ALLFIX should be kept in a separate directory. In this manual, we will assume that ALLFIX is located in C:\ALLFIX.

It is recommended that the ALLFIX directory be included in the path statement.

Example: SET PATH=C:\FD;C:\GECHO;C:\RA;C:\ALLFIX

Using a path statement, ensures that the executables can be started up from anywhere in the system. In order for the executables to be able to find the configuration files, the following line should be added to the AUTOEXEC.BAT file, or the CONFIG.SYS file for OS/2 systems:

SET ALLFIX=C:\ALLFIX

Copy the following files from the distribution package to C:\ALLFIX.

ALLFIX.EXE, ALLFIX.OVR

The main program. It is responsible for processing FileFind requests, TIC files, and magic filenames. ALLFIX/2 for OS/2 and ALLFIX Universal do not have any .OVR files.

ASETUP.EXE, ASETUP.OVR

This is the program used to create and update the configuration files for ALLFIX.

BAKE.EXE

This is the program used to create new COOKIE files which can be used in the new file report system which will be explained later.

COOKIE.EXE

This is the program that generated a random cookie, from the COOKIE file.

HATCH.EXE

This is the external utility to hatch files.

SCRAMBLE.EXE

This is the utility to select random COOKIE files.

CRC32.EXE

This is a utility that can be used to calculate a 32 bit CRC for a file.

FCOMP.EXE

This is the utility for creating the BBS file area configuration file to be used with ALLFIX. This utility is only included with ALLFIX, ALLFIX/2, and ALLFIX/U. ALLFIX! does not need this utility.

FIXUTIL.EXE

This is the ALLFIX maintenance utility.

UPDATE.EXE

This is the update utility that can be used to update older versions of ALLFIX to the current version.

????????.SCS

The registered version of ALLFIX needs a valid key file. The keyfile contains information about every officially registered user.

6.2 Starting the Program

ALLFIX needs to be configured using ASETUP before it can be used. ASETUP will look for the configuration files in the current directory. If the files do not exist in the current directory, then it will look for those files in the directory pointed to by the environment variable. The first time that ASETUP is run, none of the configuration files will be found. ASETUP will prompt the user if the files should be created. If the user selects ‘Yes’ then new configuration files will be generated with default settings for some of the options.

The directory where SETUP.FIX is found is considered the "system directory" where the rest of the configuration files will also be stored.

When ALLFIX, ASETUP, or HATCH run they create a semaphore file called ALLFIX.BSY which indicates that one of the three programs is busy. ALLFIX/2 does not make a physical file, but creates a named semaphore. Neither of these three programs will run if a semaphore exists. If ALLFIX, ALLFIX!, or ALLFIX/U crash during a session, it is possible that the sempahore remains on the harddrive. This means that the program will not start up again, until that file has been manually removed. ALLFIX/2 does not have

this problem since OS/2 will automatically remove the semaphore when the program ends.

6.2.1 Keys

ASETUP uses pop-up menus. The cursor up and down keys can be used to move the menu bar up and down. Menu items can be activated by pressing the Enter key. The Esc key will always return to the previous menu. In some situations ASETUP will first ask if the current changes should be saved before returning to the previous menu. In those situations, the F9 and F10 function keys can be used to abort the changes or save the changes, respectively, without prompting the user.

The last line on the screen will contain useful help about the use of the selected function or help on keys that can be used.

6.2.2 Selecting entries from a list

Many times a selection needs to be made from a list, for example, selecting a fileecho from a list of all the configured fileechos or selecting a template from the list of all available template files. In these situations, the Enter key can be used to make a selection and the Esc key can be used to abort the selection process. To search for an entry, simply enter a portion of the text to search for. After the first key letter has been entered, an edit field will appear at the bottom of the screen where the rest of the text to search for can be entered. Hitting return will cause ASETUP to search for the first entry containing the entered text. Hitting Ctrl-Return will instruct ASETUP to search for the first entry beginning with the entered text. The search routines are not case sensitive.

6.2.3 Online help

ASETUP contains context sensitive online help which can be activated by pressing the F1 function key.

ALLFIX, ALLFIX!, and ALLFIX/U:

ASETUP makes use of the ALLFIX.DOC documentation file and the AF_DOC.IDX file for the online help. ASETUP will display the appropriate section of the documentation when the help is activated. If there is no specific help for the currently selected option, then ASETUP will display the beginning of the documentation.

Once the help has been activated, the ‘F’ key can be used to search for a string in the documentation, and the F3 function key can be used to repeat the search. These keys are the same as for the program LIST, which is a well known program for viewing ASCII files.

ALLFIX/2:

ASETUP makes use of the ALLFIX.INF documentation file for the online help. ASETUP will display the appropriate section of the documentation when the help is activated. If there is no specific help for the currently selected option, then ASETUP will display the table of contents.

6.2.4 Selecting message areas

Message areas need to be selected in several portions of the configuration program. ALLFIX supports several different types of message bases. The type of message base can be selected by pressing Enter on the format field. Depending on the format, there will be either one or two other fields that need to be configured.

For each message base:

Hudson

A board number between 1 and 200 needs to be entered for the hudson message base. A value of zero will disable the option. Not available in ALLFIX!.

Pkt

An echotag has to be configured for the Pkt interface. ALLFIX will write the .PKT files in the directory configured in the pathnames (part 1) menu (section 6.3.2). An empty echotag will disable the option.

*.MSG

A path needs to be defined for the *.MSG message base. Please note that this refers to an echomail area and NOT to a netmail area!! The last option, which can be selected in some of the menus is Netmail, which does refer to the netmail folder. Not Available in ALLFIX!.

Ezycom

A board number between 1 and 1024 needs to be entered for the Ezycom message base. A value of zero will disable the option. Not available in ALLFIX!.

Squish

A name needs to be configured for the Squish message base. The name must include the path and name of the message base without the extension. An empty name will disable the option. If an echotag is included and the echotoss filename has been configured (see Filenames menu, section 6.3.4) then ALLFIX

will append an entry to the echotoss log when messages are written to this message base. Not available in ALLFIX!

JAM

A name needs to be configured for the JAM message base. The name must include the path and the name of the message base without the extension. An empty name will disable the option. If an echotag is included and the echotoss filename has been configured (see Filenames menu, section 6.3.4) then ALLFIX will append an entry to the echotoss log when messages are written to this message base. Not available in ALLFIX!.

PCBoard

A name needs to be configured for the PCBoard message base. The name must include the path and the name of the message base without the extension. An empty name will disable the option. Not available in ALLFIX!

Netmail

No extra options need to be configured if this option is selected. Please note that this option cannot be selected in every menu.

WildCat!

A conference number between 1 and 64000 needs to be entered. ALLFIX! is not capable of writing to conference number 0. ALLFIX! considers a 0 as an empty field, which effectively disables the option. This option is only available in ALLFIX!.

Internet

The email address to which the messages should be written. This feature is most usefull when using it in conjuntion with a list server to send, for example, new file reports to groups of people.

6.2.5 Selecting template files

The purpose of template files will be explained in section 6.14. In several menus a template file can or must be selected by pressing the Enter key on the desired template file. Template files can be viewed by hitting the ‘V’ key when the desired template is highlighted. A template file type must be selected before one can be viewed. Template files can be edited by pressing the ‘E’ key. If an external editor has been defined (See External programs menu), ASETUP will call up the external editor. You can still force ASETUP to call up the internal editor by hitting ALT- E. New template files can be added to the list by pressing the Ins

key and then entering the name of the new template file. Existing template files can be deleted by pressing the Del key.

6.2.6 Internal text editor

The editor is a simple ASCII file editor that supports most wordstar key sequences. The Esc key can be used to exit the editor. The F2 key can be used to display a list of commands that can be used in the template file. The F3 key can be used to import another text file. The F9 and F10 keys can be used to abort and save the changes, respectively.

In some of the fields in ASETUP, a filename can be entered. For those fields, it is possible to edit the filename, by pressin ALT- E. ASETUP will then, automatically, call up the editor.

6.2.7 Editing system lists

Downlink systems need to be selected in several portions of the configuration program. The Ins key can be used to add a system to the list and the Del key can be used to remove one. The menu to add or edit a system in the systems list contains the following fields:

Node Address

This field contains the network address of the system.

SysOp

This field contains the name of the SysOp of the above entered system. This option can also be used to select a system from the list of systems configured in the Node manager.

The following five fields are only available in the fileecho manager:

Send files

This field determines if this system should receive files.

Inactive

This field determines if this system is temporarily inactive or not, ie. whether or not it receives files if the above option is set to Yes.

Receive files

This field determines if this system is allowed to send files to the local system.

PreRelease

This field determines if this system should receive prereleased files before the official release date as specified in the external hatch manager.

Mandatory

This field determines if this system is allowed to disconnect this fileecho via the AreaMgr. If this field is turned on, ALLFIX will also not allow a node to set this area to inactive.

The following field is available in every systems list:

Msg status

This field determines the message status of all outgoing files. If the option "Setup" is selected, then the message status, as specified in the Node manager, is used. All the other options override the settings in the Node manager.

If you enter a system address that is not listed in the Node manager, ASETUP will ask you if you want to add that system to the node manager. By selecting the Yes option, you will be presented with an edit window, in which you can define the settings for the new node. When you exit and save these settings, this node will be added to the Node manager.

6.2.8 The managers

ASETUP contains a number of "managers", for example, the fileecho manager, where the fileechos can be defined. These managers have two different modes, namely, view mode and edit mode. In view mode, you can scroll through the different entries in the manager and in edit mode, you can edit the current entry.

The following keys are available in view mode:

ENTER

Edit the current entry.

ESC,F9,F10

Done, return to the previous menu.

F2

Global edit menu that allows multiple fileechos to be edited at once.

F3

Display and allow editing of the advanced options.

F4

Find an entry. For the fileecho manger, searching is based on the fileecho tag.

F5

This key can be used to active the browse mode. In Browse mode, all the entries are listed in a list, from which an entry can be selected by pressing the enter key.

F6

Copy the current record and enter edit mode.

The following keys are available in edit mode:

The cursor up and down keys can be used in to scroll through the menu items. The home and end keys can be used to jump to the first and last item, respectively.

ESC,F9,F10

Done, return to the previous menu. F9 closes edit mode without saving, F10 closes edit mode saving all of the changes, and ESC closes the edit mode presenting the user with a dialog box asking whether or not the changes should be saved.

The fileecho manager has two extra keys available in edit mode, namely the following:

F3

Display and allow editing of the advanced options.

F6

Select the destination directory from a list of BBS files areas.

6.2.9 Shell

ALLFIX and ALLFIX!:

It is possible to activate a dos shell from anywhere within the configuration program by simultaneously hitting the ALT and the ‘Z’ keys. ASETUP will alter the prompt to signal that the user is in a dos shell, if there is enough room left in the environment. When activating a dos shell, ASETUP will swap a portion of the memory in use to either XMS/EMS or to disk, thereby freeing up

more memory for the dos shell. Type "EXIT", without quotes, to return to ASETUP.

ALLFIX/2 and ALLFIX/U:

It is possible to activate a shell from anywhere within the configuration program by simultaneously hitting the ALT and the ‘Z’ keys. Type "EXIT", without quotes, to return to ASETUP.

6.2.10 Command line options.

ASETUP has several command line options and switches.

Commands

Index Rebuild index files Pack Pack data files

Switches

-Mono Force mono mode -Color Force color mode -SFI Force speech friendly interface

6.2.11 Index files

ALLFIX currently makes use of linear database files accompanied by linear, sorted index files. All data is stored in files ending with the extension .FIX and all index information is stored in files ending with the extension .IDX.

The index files conserve memory and enhance the performance of the program.

ASETUP will automatically remove old deleted entries from the database files, a process called "packing". However, it is sometimes necessary to manually "pack" the database files, which can be done using the Pack command.

Example: ASETUP Pack

If the index files are corrupt or have accidentally been deleted, then ASETUP will automatically regenerate them. This process can also be performed manually with the Index command.

Example: ASETUP Index

Repeated packing or regenerating of the index files will not destroy any data. However, it is not necessary to manually pack or regenerate the index files under normal conditions.

6.3 System data

6.3.1 Address maintenance

6.3.1.1 Network addresses

Each system is designated by a network address and sometimes with a number of alternate networks addresses (AKAs). The main address should be entered within this menu, along with up to 40 alternate addresses. To prevent confusion, it is recommended that the addresses be entered in the same order as they are configured in other programs, such as the mailer and the echomail processor.

Another option that can be configured within this menu is the fake point number. The fake point number is used when writing echomail messages to PKT files that have to be processed by your echomail tosser. ALLFIX will use the aka that you defined for the FileFind or New file report, and replace the point number with the Fake point. This will ensure that your mail tosser processes the PKT files, since most echomail tossers would otherwise ignore the PKT files, since they would otherwise contain an origin address equal to your address. You should use a point number that has a very low chance of being used for something else, such as the number 9999.

6.3.1.2 Site information

This menu contains information that can be used in the template file system. The registered version of ALLFIX also contains field to enter your registration key(s).

BBS name

The name of the BBS system.

Phone 1

The phone number of the BBS system.

Phone 2

The phone number of line 2 of the BBS system.

Phone 3

The phone number of line 3 of the BBS system.

Location

The city and country where the BBS system is located.

SysOp

The name of the system operator. This name should be identical to the name for which the registration key is made out to.

Max baud

The maximum baud rate supported by the BBS system.

Flags

The collection of nodelist flags defining the system’s capabilities. The local HOST or HUB system should be contacted if this information is not known.

Reg key

There are five different registration key fields for the four different types of ALLFIX. Fill your key(s) in the appropriate field(s).

6.3.1.3 AKA matching

ALLFIX will normally automatically determine which network address to use for a destination system. This process works by matching up the zone numbers. Within this menu it is possible to force ALLFIX to use a different matching procedure. The AKA to use can be entered for up to 20 zone/net combinations. If the net number is zero, then ALLFIX will match that particular AKA to all addresses in that zone. If the net number is not zero, then ALLFIX will only match that AKA to addresses in that zone and net. The order in which the entries are made is not important. ALLFIX will select the "best" match.

Example:

If the following two entries are made:

2:0 2:281/1000 2:281 2:281/1001

When selecting which AKA to use (ie. 2:281/1000 or 2:281/1001) for the system 2:231/1000, ALLFIX will select the first address. If an AKA needs to selected for the following address: 2:281/2000, then ALLFIX will select the second address. Please notice that ALLFIX selects the "best" match, and not the first specification that matches the given address.

If an address cannot be matched up, then ALLFIX will use the main address.

6.3.1.4 Domain names

A domain is a name that is given to a certain net or a portion thereof. Domain names cannot be selected freely. The ZC, of the

network in question, should be consulted when there is doubt about the domain name. Domain names are often referred to as the fifth dimension, however, the author doubts whether domain names have any functional value.

Domain names are put into any netmail or echomail messages. ALLFIX will put the domain names in both types of messages according to the FSC proposals. ALLFIX will only include the domain names if they have been configured for a certain net.

BinkleyTerm users can also use domain names for another purpose. It is possible to configure BinkleyTerm so that it will use directories, other than the standard outbound directory. The domain name signifies the name of the directory for a particular net. ALLFIX will use those directories for those zones that have an domain name. The zone number will automatically be appended to the directory name, and the standard outbound directory will be used for the zone corresponding to the main address.

Example:

standard outbound directory for zone 1:

E:\BINK\OUTBOUND.001

standard outbound directory for zone 2:

E:\BINK\OUTBOUND.002

standard outbound directory for zone 3, with domain name "Fidonet" :

E:\BINK\FIDONET.003

* Note: BinkleyTerm users: Please note that ALLFIX will use the domain named directories for all zones that have a domain name defined. If the normal naming procedure is required, the domain names should NOT be configured.

ALLFIX will not use the domain naming convention for the outbound directories for those people using Portal of Power, which uses BinkleyTerm style outbound directories but does not support the domain naming convention.

6.3.2 Pathnames (part 1)

This menu contains the first part of a large number of directories not all of which need to be configured in order for ALLFIX to perform correctly.

MSG path (not in ALLFIX!)

This is the directory where the Ezycom or Hudson message base is stored. If neither of those messages is needed, then this option does not need to be configured.

BBS path (ALLFIX!)

This is the directory where the WildCat! BBS configuration files are located.

Netmail

This is the directory where all incoming netmails (*.MSG files) are stored.

Netmail out

Some mailers support separate inbound and outbound netmail directories. If necessary, then this is where the outbound netmail directory can be configured. The only known mailer supporting this particular option is D’Bridge. If this option is not needed, then it should be left blank.

Inbound

This is the directory where the mailer receives all incoming files. It is possible that the mailer supports a normal and a secure inbound directory. In that case, this is where the normal inbound directory should be configured. The secure inbound directory can be configured in the next option.

Sec Inbound

If the mailer has support for a separate inbound directory for secure sessions, then this directory should be configured here. If the mailer does not support a secure inbound directory or that option is not being used, then this field should be left blank.

Outbound This field is used for three different things, depending on the type of mailer that you use. If you use BinkleyTerm, Portal of Power, or McMail, then this field is used to configure the outbound directory that ALLFIX should use. If you use D’Bridge 1.53 or higher, then this field is used to configure where the D’Bridge outbound queue should be stored. If you use T-Mail, then this field is used to define where the FileBox is stored. Lastly, if you use the FrontDoor STQ, then this field is used to define where the STQ is located (normally, the FrontDoor system directory).

PKT in

ALLFIX has the ability to write .PKT files, but it can also read them for FileFind requests. ALLFIX will scan the netmail directory for all arcmail packages addressed to the fake

address and stored in this directory. If the .PKT system is not required, then this option should be left blank.

PKT out

Any .PKT files that ALLFIX creates need to be processed by the echomail processor. If the .PKT system is required, then this is the directory where ALLFIX should create the .PKT files. Some echomail processors, like Gecho, support a secure .PKT directory. Any .PKT files processed from that directory will not be checked for appropriate addresses and passwords. If the echomail processor supports that option, it is highly recommended that it is used because it offers the ability to write messages in an echomail area without including that system in the export list for that area. This is very handy for echomail areas where ALLFIX writes new file reports because otherwise, any messages received in those areas will also be forwarded to ALLFIX, which is not necessary!

Tic path

This is the directory where ALLFIX stores outgoing .TIC files. This directory must be configured and it MUST be different from either of the inbound directories and the Queue directory explained below.

Queue path

This directory is used when pass through files are processed or when the "send original" option is being used for one or more fileechos. This directory is also used to store files that need to be released on a later date. More information about these options can be found in related sections. Any files stored in this directory that have been sent will be removed. It is VERY VERY important that this directory is used only by ALLFIX and that it does not contain ANY other files, because they WILL be deleted!

6.3.3 Pathnames (part 2)

List path (not in ALLFIX!)

The path where ALLFIX can find alternate FILES.xxx files for directories found on CD-Rom drives. ALLFIX will check this directory before checking the official directory. The name of the file must end in 3 digits. For example: the file for file area 1 would be named: FILES.001. This option is used in conjunction with the FileFind system for those BBS systems that make use of standard FILES.BBS files.

Rcvd path

If a directory is configured in this field, then ALLFIX will move any orphaned incoming files from the inbound directory

to this directory. Orphaned files are those that do not have an accompanying file attach message. Arcmail packages and routed .TIC files will not be moved.

Bad tics

If a directory is configured in this field, then ALLFIX will move any bad .TIC files and their associated files from the inbound directory to this directory. If this option is not defined, then ALLFIX will change the extension of all bad .TIC files to .BAD.

Dupe path

If a directory is configured in this field, then ALLFIX will move any duplicate files and their .TIC files from the inbound directory to this directory. If this field is not defined, then ALLFIX will move the files to the "Bad tics" directory or rename them to .BAD files, if the "Bad tics" field is not defined.

Tag path

Path   where  the  uplink  fileecho  area  listing  files  are

located. If this directory is left blank, then ALLFIX will assume that those files are stored in the system directory. An update fileecho area listing is usually a FILEBONE.?? file, which contains a list of all of the fileechos which are available on the backbone. A listing may also contain only a subset of the FILEBONE.?? file.

Tmp path

This is the directory that ALLFIX should use when creating temporary directories necessary for archive conversion. If a ram drive, with adequate space, is available, then it is recommended that it be used for increased performance. If a ram drive is used, then it is very important that it is large enough to handle large files because otherwise the conversion process will fail and the original archive will be imported as opposed to the converted archive.

Template

This is the directory where the template files (*.APL) are located. This field must be configured. It is recommended that a separate directory is used to store the template files, because it is possible to have a large number of templates files and keeping them in a separate directory makes finding them easier.

Billing

This is the directory where the billing information is stored. ALLFIX stores a different datafile for each node that

participates in cost sharing. These files are stored in this directory. The cost sharing features, explained in section 6.5, are only available in the registered version.

Old bills

This is the directory where old bills are stored. Each time that ALLFIX makes a bill, it will store a copy of it in this directory. Each bill has its own invoice number. The name of the bills stored in this directory will be named <invoice_nr>.TXT, for example, 950001.TXT. The file is plain ASCII text file. ALLFIX will not store any old invoice files if this field is left empty. For more information about the cost sharing features, see section 6.5.

6.3.4 Filenames

There are a number of files that ALLFIX needs.

Alias

Most mailer software packages have support for file requests.

File  requests can be  made by  giving a  specific filename, a

file specification, or by specifying an alias. The mailer then consults an "alias" file to determine which file should be sent when a request is done for a particular alias. It often occurs that files, which are available for file requesting, are periodically updated which means that the alias file needs to be updated.

ALLFIX is capable of updating the alias file. The format of most alias files is:

alias [drive]:\path\filename.ext

ALLFIX will update the alias file in two situations. The first situation is via the Magic filename manager, which will be explained in more detail in section 6.5.3. This particular method will scan through the alias file and replace any files that match the specification entered in the magic filename manager. This method will ONLY replace files that are in the destination directory for the fileecho in question and that do NOT contain any wildcards. The second method is easier. The "Magic" verb in the .TIC file specifies an alias name. If that verb is present in a .TIC file then ALLFIX will add or update all references to that alias in the alias file. In this case it does not matter where or what the filename is.

The alias file may also contain comments. Any text following a semicolon, ‘;’, will simply be skipped. ALLFIX will also do its best to maintain the format of the current alias file, when making any changes.

BinkleyTerm requires an ‘@’ symbol in front of the magic name and it also requires that all aliases should be placed before any reference to external alias files denoted with a ‘*’ character. ALLFIX will use the BinkleyTerm requirements if it selected as the mailer in use (see Global Options menu).

Portal of Power uses a binary alias datafile. ALLFIX will update that file if it is selected as the mailer in use (see Global Options menu). Even though the name of the alias file for Portal of Power is not configurable, ALLFIX does require that it is specified in its entirety.

Example: C:\POP\PORTAL.OKF

Log file

The [drive]:\path\filename.ext of the log file ALLFIX should write to. ALLFIX supports a number of log file styles which can selected in the Global Options menu.

Mgr log

The [drive]:\path\filename.ext of the log file ALLFIX should use for any AreaMgr activity. ALLFIX will use the normal log file if this entry is left blank. The log style will be in the same format as selected for the general log in the Global Options menu.

Rp log

The [drive]:\path\filename.ext of the log file that the request processor in ALLIFX should use. ALLFIX will use the normal log file if this entry is left blank. The log style will be in the same format as selected for the general log in the Global Options menu.

Fix log

The [drive]:\path\filename.ext of the log file that FIXUTIL should use. The log style will be in the same format as selected for the general log in the Global options menu.

Bad log

When bad .TIC files are received, ALLFIX will either rename them to .BAD or move them to the Bad Tics directory. ALLFIX will also create a small log file which lists the .TIC file, the associated archive, and the reason the file was rejected. In this field, the path and filename of that log file can be defined. If this field is left empty, then ALLFIX will create a file called "BADTICS.LOG" in the Bad Tics directory.

Dupe log

This field can be used to define the path ane filename of the log file that ALLFIX should use for duplicate files. Please see the description for the "Bad log" field for more details.

Echotoss

The squish echomail processor reads in an echotoss log file which contains a list of echomail tags for areas that contain new messages. By using this log file, squish can quickly determine which areas have new messages instead of scanning all the message bases which can be very time consuming. The path and filename of the log file can be entered in this field. The default name that squish uses is ECHOTOSS.LOG. Entries will be appended to this file only if the echotag for a particular message area has been defined. For more details please see the chapter on selecting message bases.

Many message base tossers for JAM also read an echotoss log file. The name of this file is ECHOMAIL.JAM. If you use a JAM message base, then enter the path and name of the ECHOMAIL.JAM file in this field.

Unwanted

This field can be used to specify the name of a pure ASCII text file that contains a list of files and file specifications that should be deleted from incoming archives. Many systems add a little information file to each archive they process and send to other systems. Entering the names of those files in this file will instruct ALLFIX to delete those files from the incoming archives. The unwanted file list may contain wildcards but may not contain any pathnames. This option is only available in the registered version.

Wanted

This field can be used to specify the name of a pure ASCII text file that contains a list of files and file specifications that should be added to incoming archives. All entries in this file should contain the complete path and filename. This option is only available in the registered version.

Semaphore

This field can be used to define the name and location of the semaphore file that ALLFIX should touch after it has created outbound mail. Two semaphores can be specified, one that should be made when netmail is written, and one that should be made when echomail is written. The following list contains the names of several mailer programs and the semaphore file that ALLFIX should create when netmail has been written:

Mailer Semaphore

FrontDoor FDRESCAN.NOW InterMail IMRESCAN.NOW D’Bridge DBRIDGE.RSN Dutchie NWMAIL00.FLG McMail MCSCAN.ALL

The normal log file, the AreaMgr log file, the Rp log file, and the semaphore file may contain the name of an environment variable enclosed with percent characters, ‘%’. ALLFIX will replace the name of the environment variable with its value, if it is defined.

Example:

suppose that the following environment variable is set:

SET NODE=1

If the string %NODE% is included in the name of the log file, then ALLFIX would replace it with the string "1", without the quotes.

C:\LOGS\ALLFIX.%NODE%

would be expanded to:

C:\LOGS\ALLFIX.1

This makes it possible to use separate log files for each node, the names of which will depend on the value of the specified environment variable.

6.3.5 Internet settings

Please note that our internet site contains a more detailed explanation of how you can use ALLFIX to send all your Fidonet files via the Internet. You can find our website at allfix.app.

ALLFIX has the ability to send files via the Internet to all of your downlinks throughout the world. Instead of sending the files and the messages via your FidoNet mailer, ALLFIX creates SMTP or UUCP style email messages which can be send to your downlinks by your email client software. This means that if you use PostRoad mailer, for example, it will take over the function that a FrontDoor would, in a normal situation.

Instead of making .MSG files (FrontDoor style mailers) or adding files to .?LO files (BinkleyTerm style mailers), ALLFIX will create emails in the outgoing directory and it will scan all of the emails in the inbound directory.

Every message and file is encoded using a technology similar to UUENCODE. All messages and files larger than a certain size (see below) will be split up into smaller parts and then each part will

be sent to your downlink. The ALLFIX running at your downlink, will decode each part of a message or file, and when all of the parts have been received, it will rebuild the messages and the files.

When a part is received by ALLFIX, it will acknowledge that it has been received correctly. If the part contains an error, ALLFIX will request that it is resent, by sending an error message back to the sender. The sending ALLFIX will automatically resend a part whenever it has not been acknowledged within a specified number of days.

The system, therefore, is very secure. Parts cannot be lost, since they will be automatically resent if they are not received, or when something has gone wrong in the transmission. Secondly, everything is encoded, therefore, it is easy to determine if something went wrong in the transmission.

The only thing that you need to do to use this feature is fill in the fields below and enter an Internet address for your downlinks in the Node manager.

In this particular menu, the fields that are necessary for this feature in ALLFIX are explained:

Address

In this field, the Internet address to use needs to be defined.

Email client

In this field you can select the type of email client that you use. The selection you make will determine the other fields that also need to be filled in. Those fields that do not need to be filled in will be marked with the string "n/a" (Not Applicable). ALLFIX currently has support for the following email programs: PostRoad Mailer, Net-Tamer, PMMail, UUCP, Soup/Yarn, Eudora, KA9Q, MR/2 ICE, Pegasus Mail, and Outlook express.

In queue

In this field, the directory where incoming email messages are received needs to be defnied. If you use Outlook Express, as your email client, please read the Note below.

Out queue

In this field, the directory where outgoing email messages are stored needs to be defined. Some email clients do not have a seperate outgoing email directory. In that case, this field will be marked not applicable (n/a).

Sent queue

In this field, the directory where ALLFIX will store all sent SMTP email messages until they have been acknowledged needs to be defined. This directory must be different from the Out queue.

In SMTP ext

In this field, the extension of the incoming email messages needs to defined. This is normally the string POP. Please look at the messages that your email client makes to find out what the correct extension is.

Out SMTP ext

In this field, the extension of the outgoing email messages needs to be defined.

Resend retry

In this field the number of times ALLFIX should try to resend a message can be entered. The default value is 3 times.

Resend delay

In this field the number of days can be entered that ALLFIX should wait before automatically resending a message.

Message size

In this field the maximum size of a message or file part should be defined. The default value and maximum value is 16kb. The size entered here must be equal to or smaller than the maximum size of a package that the Internet connection can handle. Normally this is 16kb. If the size entered here is larger than the maximum possible value, then the messages created by ALLFIX will be split up by another program into smaller parts. If this happens, then the ALLFIX receiving those parts will be unable to rebuild the messages and the files attached to those messages.

Age of Spool

Since files and messages are sent in parts, these parts may not all be received at the same time. ALLFIX, therefore, stores all received parts in a special spool file. Sometimes, however, somethings goes wrong and parts remain in the spool file for a long time, waiting for other parts that may never come. This field can be used to determine how many days a part may remain in the spool file before being removed.

Scan netmail

ALLFIX has the ability to scan the netmail folder and re- route all netmail written to an Internet address via the

Internet. Toggling this feature to yes, will enable this feature.

Note:

If you are using Outlook Express, then it is necessary to also include the filename of the file that is used to stored the incoming and outgoing mail. In the "In queue" and "Out queue" fields, therefore, you need to enter the path and the filename of the respective files. However, you must NOT enter the extension of the file. If, for example, the name of the file is MAIL_OUT.MBX (and MAIL_OUT.IDX), then you should, for example, only enter the path and the filename as follows: C:\Program Files\Outlook Express\MAIL_OUT.

you should not only enter the path where the incoming and outgoing messages are stored in the In queue and Out queue fields, respectively.

Gateway functionality:

ALLFIX also has the ability to function as a gateway. This means that ALLFIX can re-route files on hold for a particular system via the Internet. ALLFIX can either send the messages to an Internet address or it can send the messages in a coded manner, as described above. The second type of functionality called a gateway. In this situation, ALLFIX uses the Internet to send messages to another Fido technology node. The first method, however, is also very useful. You can, by using this simple feature, send Notify messages, for example, to a person’s Internet address, while the file itself is put on hold for that system.

These features can be configured for each node individually, in the Internet submenu in the Node manager. Two of the fields in that menu will be discussed briefly in this section.

Send

This option determines what ALLFIX will send via the Internet for this node. It has five possible values:

Nothing Mail Files Mail and files Everything on Hold

The first four options are self-explanatory. The last option "Everything on hold" tells ALLFIX to re-route everything for this particular node via the Internet.

Two sub options, named Crash and Hold, can be used to determine if messages with those statuses should also be re- routed by ALLFIX.

Act as gateway

This option determins how ALLFIX will send things via the Internet. This option has four possible values:

No This means that ALLFIX will not act as a gateway, meaning that ALLFIX will not encode any mail, unless it concerns a file attach.

Local mail only

This means that ALLFIX will encode all local mail for this node. Once encoded, ALLFIX will send acknowledgements, etc. as explained above.

Re-routed mail only

This means that ALLFIX will encode all re-routed mail for this node.

Local and re-routed mail

This means that all mail will be encoded, meaning that ALLFIX will act as a gateway for all mail which is sent to this node.

Encode FREQs

Normally, when someone file requests a file via the Internet, it will be uuencoded and attached to an email. However, you may select to encode the file, which means that it iwll be split up into parts, encoded, and sent to the person who file requested the file. His or her ALLFIX will then have to decode the parts and put the file back together. This option is usefull since it can be used to guarantee that the files are being transferred correctly.

6.3.6 Origin lines

Origin  lines are strings  of up to  55 characters  followed by the

address of the current system, that are appended to the end of each echomail message. ALLFIX offers the ability to specify up to 20 separate origin lines. A selection can be made form the list in other sections of the configuration program. There is even the possibility to tell ALLFIX to select random origin lines.

6.3.7 External programs

There are two external program menus. The first one is used for defining DOS external programs and the later is used for defining OS/2 external programs. ALLFIX/U will use the DOS external programs when not running under OS/2.

ALLFIX has the ability to convert incoming archives to another format, to add banners to archives, and to pack outgoing .TIC files along with the associated files into one large TIC archive.

In order to do this, ALLFIX must have information about the available (de)compression programs.

A total of ten compression and decompression programs can be defined. The first 6 are defined for you, even though you can manually edit any of the features. The remaining four are empty, which you can use to define any compression and decompression programs you like. Please note that you need to be registered, in order to use those four user definable types.

The first three options are for the compression utility are:

Program file

The name of the compression program.

Switches

The commandline options necessary initiate compression which should not include any reference to any paths or filenames.

Banner

The commandline options necessary to add a banner to an archive. The name of the archive to be updated can be coded with the meta command @1 and the path and name of the banner file can be coded with the @2 meta command. Both meta commands will be expanded with their respective values before calling up the compression program.

The following options are for the associated decompression utility.

Program file

The name of the decompression program.

Switches

The commandline options necessary to initiate decompression which should not contain any reference to any paths or filenames.

No dirs

The commandline options necessary to initiate decompression of TIC archives and Arcmail. Sometimes people store pathnames in their TIC archives and Arcmail. If you normally want the compression program to retain these pathnames, then a problem will occur when unpacking TIC archives. For that reason, a seperate field has been introduced. If this field is not

used, then ALLFIX will automatically use the switches defined in the previous field.

Signature

The signature is a "finger print" for this archive type. The signature of a compression program can be found in the accompanying documentation. Up to 10 characters can be defined using their hexadecimal representation. Wildcard characters can be specified by entering two spaces.

Offset

The offset in the archive where the signature starts. This is usually 0, however, some archives store their signature further on in the archive headers.

Extension

This field defines the extension of archives of this format. ALLFIX needs this information in order to create archives of this format.

Sample configuration for the compression program RAR:

Program file RAR AASwitches a -std -y -r AABanner c @1 =@2

Program file RAR AASwitches x -std -y

Signature 52 61 72 21 1A 07 00 Extension RAR

Scan:

ALLFIX is also capable of calling up an antivirus program to scan incoming archives for viruses. The seventh menu item is where the antivirus program can be configured. The first field is the name of the executable and the second field is where the commandline options may be entered. ALLFIX does not pass any commandline options by itself. All the necessary commandline options MUST be specified by the user. There is one meta command that may be used: @1 is expanded to the complete path name without trailing backspace. This meta command may be used in the commandline options. For example, the following commandline options may be used with SCAN (where the @1 meta command is expanded to the temporary directory where ALLFIX unpacked the files:

@1\*.COM @1\*.EXE /NOMEM /NOBREAK /NOPAUSE /NOEXPIRE .

* Note: The period, ‘.’, in the previous line belongs to the commandline option and must be used, otherwise SCAN may not function correctly.)

Another example, the following commandline options may be used with OS2SCAN (the @1 meta command has the same meaning as in the above example):

@1\*.* /ALL /SUB

The virus checking feature is only available in the registered version of ALLFIX.

EAC:

The next item in this menu is for configuring an external archive conversion utility. The conversion routines supported directly in ALLFIX are very simple and many people will require extra functions. There are many External Archive Conversion (EAC) utilities available on the market, including: PalmScan, MTA, and TranScan. The first field is the name of the executable. The second field is where the commandline options may be configured. ALLFIX supports two meta commands for the commandline option: @1 is expanded to the name+extension of the file that needs to be converted, and @2 is expanded to the temporary path where ALLFIX placed the file that is currently being converted.

Gus:

The next menu item can be used to configure a general unarchiving tool. A popular unarchiving tool is GUS. ALLFIX will call up this program when it needs to unpack a file and can not determine what the archive format it. There are two meta commands that can be used for the commandline options: @1 is expanded to the path + filename, and @2 is expanded to the file specification that should be unpacked (Ex. *.*). The correct commandline options for the program GUS are:

@1 @2 /Q /R

Many people find it difficult to understand how the EAC utility should be configured. The author has made sure that everything works very logically and it should not present many problems. The first thing that ALLFIX does is create a temporary directory which is then made the current directory. Next, the file is placed in this temporary directory. The EAC utility is then called up with the configured commandline options and any meta commands are expanded with their respective values. The only thing that the EAC utility has to do is convert the archive, which is now stored in the current directory, to another format. If no error was encountered while calling up the EAC utility, then ALLFIX will search the current directory for a filename that resembles the original filename. There should only be one file in the current directory, and ALLFIX will continue importing that particular file. If an error was encountered while calling up the EAC

utility, or nothing was found in the temporary directory, then ALLFIX will continue with the original file, which is still located in the inbound directory.

It is easy to see that the external archive conversion procedure should not cause any problems. Most problems that do occur are the results of configuration mistakes in the EAC utilities. Sample configuration files for PalmScan and MTA are included in the SAMPLE.ZIP file.

When entering program names it is not necessary to include the extension. If an extension is added (.EXE, .COM, or .CMD) then ALLFIX will scan for the full name in the PATH. If no extension is included, then ALLFIX will add each extension, in the order listed above, and scan for the resulting program name, until it finds one, or until it has exhausted the possibilities.

If the program being called up is a batch file (.CMD), then ALLFIX will call up the program via the command interpreter. The disadvantage of using batch files is that the errorlevel of the program being called up is not passed on by the command interpreter and, hence, it is very difficult for ALLFIX to determine if something went wrong when calling up a batch file. Therefore, it is recommended, but not necessary, that normal executables are used, instead of batch files.

If the redirection symbol ‘<‘ is used in the commandline options for adding banners to archives which is necessary for some compression programs, then ALLFIX will also call up the command interpreter, since that is the only way to execute the redirection.

Extra notes for ALLFIX/2 for OS/2 and ALLFIX Universal:

ALLFIX/2 is capable of executing both DOS and OS/2 programs. There are, however, a few things that should be kept in mind. Using the redirection symbols in conjunction with DOS programs will not work properly. The problem is that the OS/2 shell in which ALLFIX is running will process the redirection symbol and not the virtual DOS window which is started for the DOS program. The result is that the DOS program will not "see" the redirection symbol and hence the program will not function as intended.

ALLFIX Universal will switch between the DOS and the OS/2 external programs depending on which operating system it is being run under. However, keep in mind that if you define DOS programs in the External programs for OS/2, then ALLFIX Universal will also behave exactly like ALLFIX/2 described above (when running under OS/2).

Ed:

ASETUP can use an external editor instead of the default internal editor. This editor is used for editing the template files. This

field can be used to define which editor ALLFIX should use. Simply enter the complete path and filename of the editor.

When an external editor has been defined, it is still possible to call up the internal editor, by pressing ALT-ENTER to edit the template in stead of pressing ENTER.

6.3.8 External program options

Within this menu are several options that have an effect on the way ALLFIX calls up external programs.

Swapping method (ALLFIX and ALLFIX!)

Whenever ALLFIX calls up an external program, referred to as a child process, it needs to make enough memory available for that program. The process of removing memory used by a program to make room for another program is called swapping. ALLFIX is capable of swapping almost all of itself out of conventional memory, thereby, making as much memory available for the child process, as possible.

The way that ALLFIX swaps can be configured with this option. Valid choices are:

None

Do not swap at all

Disk

Swap memory to disk

XMS/EMS

Swap memory to XMS or EMS, whichever is available. Priority is given to XMS, because it is faster.

XMS/EMS/DISK

This option is the same as above, except that ALLFIX will swap to Disk if there is not enough XMS or EMS available.

ALLFIX will not swap to XMS, EMS, or Disk if there is less than 128kb of free memory available. ALLFIX will only swap as much of itself out of conventional memory as there is space in the destination medium.

Redirect output

ALLFIX is capable of redirecting output of child processes to NUL, which makes the execution of ALLFIX "look" nicer, by "hiding" the execution of child processes. Only output written to standard output can be redirected. Please note

that this option should be turned off when problems are experienced while calling up child processes, because otherwise program errors will not be displayed on the screen. It is also important to note that only the output of OS/2 programs can be redirected. When a DOS program is executed, a virtual DOS windows is opened. It is not possible to "hide" this window.

No virus errorlevel

The antivirus program exits with a number of different errorlevels signalling different conditions or problems. Normally the first few errorlevels are used to signal execution problems, such as not enough memory. The first errorlevel that signals a virus should be entered in this field. If for example, errorlevel 1 means not enough memory, errorlevel 2 means invalid configuration file, and errorlevel 3 means one or more viruses found, then the value 3 should be entered in this field. Please note that the virus checking option is only available in the registered version.

Files to scan

A number of files do not need to be scanned by a virus checker, for example *.TXT files. ALLFIX will only call up the virus checker if there are one or more files matching the file specification selected with this field inside the archive that needs to be scanned.

(EAC) virus errorlevel

The EAC utilities can also be used to check for viruses during archive conversion. The minimum errorlevel returned by an EAC utility if a virus has been found should be entered in this field.

(EAC) error errorlevel

This is the minimum errorlevel returned by an EAC utility if a error occurred while converting the archive. ALLFIX will continue processing the original archive if the external conversion program reports an error.

6.3.9 Global options

This menu contains a large number of very important options that affect every process ALLFIX can perform.

Log style

The style of the log file to be used.

For ALLFIX and ALLFIX/2, the possible options include: FrontDoor, D’Bridge, RemoteAccess, SuperBBS, BinkleyTerm, and Portal of Power.

For ALLFIX!, the possible options include: FrontDoor, D’Bridge, WildCat!, BinkleyTerm, and Portal of Power.

Mailer mode

The type of mailer used. Please see the Outbound path, the DB queue, and the FileBox options in the pathnames menu (section 6.3.2), if BinkleyTerm, D’Bridge, or T-Mail is used, respectively.

There are two "FrontDoor" options in the list. The normal "FrontDoor" option should be used if you use FrontDoor without the the STQ feature (as of version 2.25) or if you specifically do not want to use the STQ feature. The "FrontDoor STQ" option should be used if you use FrontDoor 2.25 or newer and you also want to use the STQ feature. Please refer to the FrontDoor documentation for more information on what the STQ is.

If MainDoor is selected, ALLFIX has the added feature of automatically updating the TODAY.MD file which contains the file request statistics. This means that each time the request processor in ALLFIX process a file request, it will update the total number of kilobytes file requested from the system. In order to prevent the necessity of adding yet another path field to the Pathnames menus, this feature only works if the "MD" environment variable is set.

If you select BinkleyTerm, Portal of Power, or McMail, then please make sure fill in the Outbound directory in the Pathnames menu. Also, if you use T-Mail, then please make sure to enter the FileBox directory in the Outbound field in the Pathnames menu. If you use D’Bridge, you should enter the D’Bridge queue directory in the Outbound field, and lastly, if you use the FrontDoor STQ, then the FrontDoor system directory should be entered in the Outbound directory field.

Date format

The date format that should be used. The choices are:

dd-mm-yy European style date

mm-dd-yy American style date

yy-mm-dd Military style date

MSG compatibility

This field is used to define the .MSG compatibility. There are three options: The default is Fido style .MSG files; The

second option is Opus style .MSG files; and the third is None.

In the .MSG file header, there are two fields that can contain binary information. In Fido mode, these two fields contain the net and the node number. In Opus mode, they contain the date of the netmail, and in None mode, they are left empty.

Opus compatibility should be selected if FrontDoor 2.10 (or higher) or Opus is used.

Process local requests

The mailflow in FileFind message areas can quickly get out of hand. One way to reduce unnecessary messages is to ignore any FileFind requests that originate from the current system. A reply to those requests is generally not necessary because the files that are being looked for are obviously not on the current system, otherwise a request would not have been placed. This option should be turned on during testing phase, but turned off once it has been confirmed that everything is working properly.

Replace extension

Some people add extensions to the file specifications that are being searched for. ALLFIX has the ability to replace those extensions with a ‘*’ wildcard, if this option is enabled. For example, a request for AFIX430E.ZIP is almost futile, since many systems will convert the file to another format. If the file specification ends with a period (ie. AFIX430E.) then ALLFIX will not append the wildcard. This is necessary because some people want to search for files that do not have an extension and it is redundant to reply with a list of files that do.

Max age of requests

The fact that the message flow in FileFind areas can get out of hand really fast has been touched on in previous sections. Another method for reducing redundant replies is by ignoring all requests that are older than a certain number of days. The maximum age of a FileFind request, before it gets ignored, can be configured in this field. A value of zero (0) will disable the age checking. A value of 4 or 5 days is recommended.

Auto clean up

ALLFIX automatically scans the netmail folder and the outbound directories to determine what is still waiting to be sent. It may happen that ALLFIX finds a netmail to which one or more files are attached, but where one (or more) of those files is missing. In this case, ALLFIX will automatically

remove the netmail. This feature can be disabled by setting this option to "Yes".

ALLFIX priority (ALLFIX/2 and ALLFIX/U)

The priority at which an ALLFIX task should run. Valid values are -31 to +31, where -31 is the lowest and +31 is the highest priority. If you are using ALLFIX/U, then the session priority is only changed when you are running it under OS/2.

RP priority (ALLFIX/2 and ALLFIX/U)

The priority at which the request processor in ALLFIX should run. Valid values are -31 to +31, where -31 is the lowest and +31 is the highest priority. If you are using ALLFIX/U, then the session priority is only changed when you are running it under OS/2.

Number of systems

This option can be used to set the maximum number of systems that can entered in the system list in the fileecho and echomail managers. The maximum is, by default, set to 255 systems. ASETUP reserves space in each record for that many systems. Changing this limit to something less than 255 will reduce the size of the records. This will effectively speed up ALLFIX and free up more space on your harddisk.

Last hard drive

During a session, ALLFIX often changes the current directories on your hard drives. ALLFIX stores the current directories on all drives before it begins and will restore those directories when it finishes. This way, you will not notice that any of the current directories has changed. When storing the directories, ALLFIX runs through all of your drives, from A to Z. It will store the directory for each "hard drive", by attempting to detect which ones are floppy drives and which ones are CD-ROM drives. ALLFIX has trouble recognizing CD-ROM changers. This results in each of the CD- ROM drives on the chagner to be accessed each time ALLFIX starts up. This is obviously very annoying. This field can be used to identify the drive letter of the last harddrive. If you use a CD-ROM changer, then you will probably want to fill in this field. This field is currently not used for anything else.

Keep exported messages

ALLFIX can toggle the Kill/Sent flag on all generated netmail messages if this option is turned on. The effect of the Kill/Sent flag is that all the messages will be deleted by the mailer after they have been sent out.

Days to keep on hold

This is the number of days that ALLFIX should keep file attach messages on hold for downlinks. If a file attach message is found that is older than the value of this field, in number of days, then it will be deleted. A value of zero disables this option. This option is not available for BinkleyTerm, Portal of Power, and D’Bridge mailer systems.

Size of stat file

ALLFIX also maintains a statistics file that can be used by third party programs to derive statistical information about the flow of files. ALLFIX stores information about each file processed in this database. This option will set a limit to the size of the statistics file. A statistics file will not be maintained if a value of zero is entered. The name of the statistics file is STATFILE.FIX and the associated index file is STATFILE.IDX. The statistics file can be packed using FIXUTIL.

UTC offset

This field specifies the difference, in number of hours, between local time and Greenwich mean time (UTC). Values between -12 and +12 may be entered. Central European Time is, for example, +1 and Eastern Standard Time is -5.

This particular field is necessary to calculate the correct time stamp in the .TIC files and to determine the appropriate release date for pre-released software (explained later).

ALLFIX can also use the TZUTC environment variable to determine the UTC offset. If this environment variable is set, ALLFIX will use that instead, overwriting whatever value has been defined in ASETUP. The format of this environment variable can be seen in the following examples:

SET TZUTC=+0100 1 hour ahead of UTC SET TZUTC=-0500 5 hours behind UTC.

Lastly, if the TZUTC environment variable is not set, then ALLFIX will also check to see if the TZ environment variable is set. This variable can also be used to specify the number of hours before or ahead of UTC. The format of this environment variable (in simplified form) can be seen in the following examples:

SET TZ=CET+1 Time zone CET, one hour ahead of UTC. SET TZ=EST-6 Time zone EST, 6 hours before UTC.

Max Msg size

This field can be used to define the maximum size of any created messages. Many mail tossers can not handle messages

larger than 16kb. This field accepts values 0 and 4 to 64. The values entered are kilobytes. A 0 means that there is no limit to the maximum size. All messages will be split up into chunks that are approximately the size as specified here.

Next invoice number

This field represents the next invoice number that ALLFIX will use in the next bill. The invoice number can be placed in a bill using the @invoicenr macro (for more information on macro commands, see section 99). ALLFIX will automatically increment the invoice number each time a bill has been created.

Speech friendly

If this option is turned on (i.e. set to Yes), then ASETUP will use BIOS calls to write many of the things that it writes to the screen. The affect is that speech recognition software can "see" the text being written by ASETUP and "speak" it. This feature should be turned on for any visually impaired users who use a speech recognition system.

Disable auto clean up

Normally, ALLFIX will automatically delete a netmail if the associated file attach is missing. This option can be disabled using this field.

Add tear and origin (ALLFIX!)

This option determins whether or not ALLFIX! should add a tear line and an origin line to echomail messages.

Sort by groups

This feature tells ALLFIX to sort the fileechos and the echomail areas by the groups and then by the name instead of simply sorting the fileechos by the name. When changing this option, ASETUP will automatically re-index the fileechos.

Add NPD kludge

Add the Non-Proportional-Display (NPD) kludge to all netmail and echomail created by ALLFIX.

Add PGM kludge

Add the Program-Generated-Mail (PGM) kludge to all netmail and echomail created by ALLFIX.

6.3.10 Miscellaneous

6.3.10.1 Log options

This menu contains fields that control which activities are added to the log file and which are not.

Inbound activity

Inbound Fileecho and Magic filename activity.

Outbound activity

Outbound Fileecho and Magic filename activity.

Maintenance activity

Archive conversion and other maintenance activities.

Security violations

Security violations.

AreaMgr activity

AreaMgr activities.

Notify activity

Notify activities.

Move rcvd files

Move rcvd file activities.

Move bad TIC files

Move bad TIC file activities.

FileFind rejected

Rejected FileFind messages.

FileFind created

Created FileFind replies.

New file reports

The creation of new file reports.

External Hatch

External Hatch activities.

Path statements

The path statements in the .TIC files.

Debug

All of the above.

6.3.10.2 AreaMgr options

This menu contains a number of options that control the behavior of the AreaMgr.

Allow %+ALL

Should a system be able to use the %+ALL command to connect all available areas.

Allow %NOTIFY

Should a system be able to use the %NOTIFY command to toggle the notify option.

Allow %PASSWORD

Should a system be able to use the %PASSWORD command to change the areamgr password.

Allow %ECHOPASSWORD

Should a system be able to use the %ECHOPASSWORD command to change the fileecho password.

Allow %MESSAGE

Should a system be able to use the %MESSAGE command to toggle the netmail announcement feature.

Allow %COMPRESSION

Should a system be able to use the %COMPRESSION command to change the archiver for the TicPack options.

Allow %TICK

Should a system be able to use the %TICK command to toggle the Tic file option.

Allow %PAUSE

Should a system be able to use the %PAUSE command to temporarily turn off all the areas. If this is set to ‘No’ then ALLFIX will also prevent the system from using the %RESUME command.

Allow %PACK

Should a system be able to use the %PACK command to change the packing mode for his/her system.

Allow %RESEND

Should a system be able to use the %RESEND command to request that certain files be sent to the system again.

Keep requests

Should ALLFIX keep or delete AreaMgr requests after processing them.

Keep receipts

Should ALLFIX toggle the KILL flag for any AreaMgr receipts.

Auto-add nodes

If this option is turned on, then ALLFIX will automatically add unknown systems (who sent an AreaMgr request) to the node manager. Automatically added systems receive access to the public groups defined below. This option is only available in the registered version.

Public groups

This is a list of groups that ALL nodes in the node manager have access to!

AreaMgr recognition string

These five fields are available for defining alternative names that the AreaMgr will respond to. ALLFIX automatically responds to the name "ALLFIX". Other possible names could include "RAID" or "FILEMGR", without the quotes.

6.3.10.3 Edit days

This menu contains fields where the names of the days of a week can be entered in the local language.

6.3.10.4 Edit months

This menu contains fields where the names of the months of the year can be entered in the local language.

6.3.10.5 Exclude files

Within this menu it is possible to define up to 20 file specifications that should not be included in any new file reports.

Any DOS wildcard is allowed, as well as the following special wildcards:

@ Any alphabetical character, including extended ASCII characters.

# Any numerical character.

For example: Files like NODEDIFF.A11 will be excluded from the new file reports if the file specification NODEDIFF.A## is included in this list, but NODEDIFF.ARJ would, in this case, be included.

6.3.10.6 ASETUP colors

This menu contains one menu to customize the colors used in ASETUP, four preselected schemes that match up with some popular programs, and one monochrome color scheme. The customized menu also contains the ability to define the background character.

6.4 FileFind areas

This menu is where the message areas that ALLFIX is allowed to scan for FileFind requests has to be configured. Up to 255 message areas may be defined.

The message area configuration is stored in the AREAS.FIX file. Index information is stored in AREAS.IDX.

Following is a description of all the fields in this menu.

Comment

This field offers the user the ability to enter a comment or description of the current area. The comment is completely ignored by ALLFIX, except for the fact that it is used to sort the areas.

Scan

This field designates the message area that ALLFIX should scan for FileFind requests. This entry must be filled in.

Reply

This field designates the message area that ALLFIX should write the replies in. If this field is left empty then ALLFIX will write the replies in the same message area as configured in the previous field. The netmail folder can be selected as a destination message base.

Fileareas

Within this menu, the file areas, that ALLFIX is allowed to scan for this FileFind message area, can be configured.

ALLFIX can handle up to 64000 file areas. The up and down arrow keys can be used to scroll through the list of file areas.

The following other keys are available:

ENTER, SPACE

The enter key or the space bar can be used to turn an area on or off.

F2

Turn all the areas on or off. If one area is on, then the rest will be turned on. If all the areas are on, then they will all be turned off.

Origin

This field designates the origin line that ALLFIX should append to FileFind replies created in this area.

Use Aka

This field designates the aka that ALLFIX should use for this echomail area.

Template

This field designates the template file that ALLFIX should use when generating replies in this area. If this field is left empty, then ALLFIX will automatically use the standard FILEFIND template, which is delivered with ALLFIX in the TEMPLATE.ZIP archive.

Files

This field determines how many files are allowed to be included in a reply message to a FileFind request. A value of zero means that the default value of 15 files per reply should be used. The maximum value that can be entered in this field is 99.

Inactive

This field determines whether ALLFIX will process this area. A value of Yes will temporarily disable this FileFind area.

6.5 Fileecho system

6.5.1 Fileecho manager

Within this menu up to 32000 fileecho areas can be defined.

The fileecho area configuration is stored within the file FAREAS.FIX. The index information is stored in FAREAS.IDX.

The following is a description of the fields in this menu.

Tag

This field contains fileecho tag, which may be up to 40 characters long. Any spaces entered in this field are automatically converted to underscores.

Desc

This field contains the description of the fileecho. The description is used in AreaMgr replies and in new file reports.

Dest

This field contains the directory where files belonging to this fileecho are stored. It is recommended that absolute pathnames are used (ie. paths starting with a drive letter). ALLFIX does not have a problem with relative pathnames, however, if ALLFIX is started up from another drive, then a large number of problems can occur because ALLFIX will not be able to find those directories. The destination directory is highlighted in a different color if it is not listed in the BBS file area configuration. This is only done if the Use FDB switch is set to Yes.

Use FDB (not ALLFIX!)

This option tells ALLFIX if it should update the BBS specific, usually binary, file database. This option is only visible for those BBS systems where it is necessary. Those system that use a FILES.BBS file will not see this feature.

Use FBBS (not ALLFIX!)

This option determins if ALLFIX should update the FILES.BBS files. This option is independant of the Use FDB option. If the Use FDB option is also turned on, ALLFIX will update both types of file databases. Please note that this feature is only visible if the "Use FDB" option is visible, and that it is limited to the registered version of ALLFIX.

Group

This field contains the group to which this fileecho belongs. Groups are used to categorize fileechos and to designate which downlinks have access to which fileechos.

Keep #

This field contains a value that tells ALLFIX how to import the files into the file database.

A value of -1 will tell ALLFIX to append the entry to the end of the file database.

A value of 0 will tell ALLFIX to attempt to insert sort the new file.

A value of 1-99 will tell ALLFIX to insert sort the new file and to remove all but that number of files with similar file specifications. ALLFIX will sort all the files matching the file specification and delete the oldest files. The file specification is determined by replacing every alphanumerical character with the ‘?’ wildcard. For example, if a value of 5 is entered, and the NODEDIFF.A12 is being imported, then ALLFIX will make sure that there are not more than 5 NODEDIFF.A?? files in the filearea after importing the current file.

Insert sorting means that ALLFIX will attempt to place the file in the file database in lexicographical order. This is accomplished by comparing filenames. If a suitable position can not be found, then ALLFIX will append an entry to the end of the file database. ALLFIX will only perform the insert sort for BBS systems that use a text file system for the file database. The new file information will be appended to the end of the file database for all other BBS systems.

If a file is already in the file database, then ALLFIX will replace that entry, regardless of whether an insert sort is being performed or not.

Template

This field contains the name of the template file to send along with all forwarded files in this fileecho. The template file will be included as text in the associated file attach message, if appropriate, otherwise a new netmail message will be created. ALLFIX will only send the template files for those systems that have the Template option turned on in the Node manager (section 6.10).

Banner

This field contains the name of the template file to use when adding banners to archives.

Use aka

This field contains the aka that should be used for this area. It is recommended that aka matching be selected.

LongDesc

This field tells ALLFIX what kind of description to use for files processed in this fileecho. There are three different types of interrelated descriptions. The first type is the normal description that is stored in the .TIC file. The second type of description is the long description stored in the .TIC files. The last type is the FILE_ID.DIZ description file that is frequently included within the file archives. This option is used to define priority levels for each type of description. If the first one is not available, then the second one will be used. For example: if FILE_ID.DIZ/LDESC is selected, then ALLFIX will first attempt to import the FILE_ID.DIZ description file. If that description is not available, then ALLFIX will use long description included in the .TIC file. As a last resort, ALLFIX will use the normal description included in the .TIC file.

When ALLFIX tries to import the FILE_ID.DIZ file, and it does not exist, ALLFIX will create one and add it to the archive.

Cost

This menu item contains several fields that determine the cost of files processed in this area. Each system, if participating in the cost sharing, has to share the cost the file. The cost of a file can be assigned to a file using the options in this menu. Incoming files may already have a cost, which is specified in the .TIC file. The "Inc cost" (include cost) option can be used to determine if the cost in the .TIC file should be added to the cost for the downlinks. ALLFIX will add the "Add perc." percentage to the cost of the incoming file before adding the "Unit cost". The "Add perc." option can be used to compensate for currency exchange rates. The unit cost depends on the "Unit size". Valid options for the unit size are 100kb, 1024kb, or the entire file.

After the cost of the file has been calculated, it will be divided among the downlinks depending on the setting of the "Div cost" option. If the "Div cost" option is set to "C/S nodes" then the cost will be divided among all the nodes in the system list that participate in the cost sharing (ie. have their "Billing" option set to "Yes"). If the "Div cost" option is set to "All nodes" then the cost will be divided among all the nodes in the system list. If the "Div cost" option is set to "No" then the cost will not be divided and each node will be charged the calculated cost. If the setting of the "Div cost" option is "C/S nodes" or "All nodes" then ALLFIX will add one to the number of systems by which it has to divide the cost unless the file is being hatched or this fileecho is a pass through fileecho. This ensures that the cost is also shared by the local system.

ALLFIX will also use these cost variables when processing a %RESEND AreaMgr command (see section 7.4). The cost that is

charged to the system requesting a resend is the unit cost, again divided by the number of downlinks.

RAID

RAID, a program that has AreaMgr functionality which can be used in conjunction with TICK has set a number of standards concerning how the FILEBONE.?? files are setup. These files contain lists of all of the fileechos that are available on the backbone. The settings in this menu are primarily used for generating FILEBONE.?? files. How to do this, is explained later on in this manual. Two of the settings in this menu "Hatching" and "Return channel" are used by the AreaMgr to determine the access level to assign to the new node. If "Hatching" is set to "Anyone may hatch" then the Receive from status is turned on for the node, and if the "Return channel" option is set to "No", then the Sent to status is turned on for the node. For a more complete explanation of these settings, please see the chapter on how to generate FILEBONE.?? files.

Max days

The maximum number of days a file is allowed to reside in this fileecho.

Max size

The maximum number of kilobytes that are allowed to reside in this fileecho.

Max file

The maximum number of files that are allowed to reside in this fileecho.

Systems

Within this menu it is possible to define up to 255 downlink systems from which files are received.

6.5.1.1 Advanced options

The following options can be found within the Advanced sub-menu:

Convert

This field is used to select an archive format that ALLFIX should convert incoming archives to. If this feature is being used, then ALLFIX will attempt to create the new archive in the destination directory, so that it does not have to be copied afterwards, which will enhance the performance.

Convert all

This field is used to tell ALLFIX to convert archives that are already of the same type as in the above configured field. For example: If ZIP is selected as Convert type and this field is set to "No", then ALLFIX will not convert *.ZIP files. However, if this field is set to "Yes", then ALLFIX will also convert *.ZIP files.

Convert inc

This field is used to tell ALLFIX if it should also convert archives within archives. If this field is set to Yes, ALLFIX will convert archive within an archive to the specified compression format.

Comp unknown

This field tells ALLFIX if it should compress unknown files. If this field is set to Yes, it will compress any unknown archives to the specified format. For example, if the file EXAMPLE.TXT is received, ALLFIX would compress it in a file called EXAMPLE.ZIP. This feature is only available in the registered version of ALLFIX.

Pass through

This field is used to tell ALLFIX NOT to import the file. This field is necessary for fileechos that are passed on to others, but are not desired for the local system. All files received in this fileecho will be copied to the queue directory from where they will be forwarded to the downlink systems. The files will be deleted from the queue directory after each downlink system has received the file.

When you turn a Passthru fileecho off, and no destination directory has been defined for this fileecho, ASETUP will automatically calculate a destination directory for you. It will determine the destination directory based on the group and the settings for that group.

Allow replace

This field tells ALLFIX if it should honor the Replaces verb (section 4.1.1) in the .TIC files for this fileecho.

Announce

This field tells ALLFIX if files received in this area should be appended to the new file report database. Files added to this database can later be announced in echomail areas or via netmail with the "Announce" command.

Add FILE_ID

This field tells ALLFIX if it should add a FILE_ID.DIZ file to an archive that does not contain one. This option can also be set to "Always", in which case, ALLFIX will always replace (or add) a FILE_ID.DIZ file to the archive. In both situations, the description is taken from the .TIC file. If the .TIC file has a long description (see Ldesc verb), then that will be used. If it does not, then the normal one line description will be used.

Virus scan

This field tells ALLFIX if incoming files should be scanned for viruses. If the Convert option is being used, then ALLFIX will scan the files during archive conversion.

Dupe check

This field tells ALLFIX if files processed in this fileecho should be checked for duplicates.

Visible

Normally, only fileechos that a system has access to are included in AreaMgr replies (section 7.4). Sometimes it is desirable to include a number of areas that the person does not have access to, a sort of advertisement, so that the system knows what other areas are available. This field tells ALLFIX that this fileecho may be included in the AreaMgr replies. The actual purpose of this field is a bit outdated with the new macro language. Please consult the chapter on the macro language for more details.

Tiny SB

This field tells ALLFIX to strip everyone from the seenby listing that is not connected to the local system. The purpose of this option is to strip away unnecessary systems from the seenby listings. This option is not necessary for most situations.

No Touch

This field tells ALLFIX if it should update the file database for this particular fileecho. If this field is set to "No", then ALLFIX WILL update the file database (ie. No No Touch = Yes Touch). If this field is set to "Yes", then ALLFIX WILL NOT update the file database for this fileecho (ie. Yes No Touch = No Touch).

Security

This field tells ALLFIX is it should check incoming files to make sure that they come from a system in the systems list with the appropriate status. ALLFIX will ALWAYS require systems, from whom files are received to be configured in the

Node manager. If this option is set to "Yes" then ALLFIX will also require that the system is listed in the Systems list with the correct status.

Send original

This field tells ALLFIX that each file processed in this fileecho should be copied to the queue directory, from which it will be forwarded to the downlinks. A copy of the file will be imported in the configured directory. If the Convert option is being used, then the original file will be copied to the queue directory and the converted file will be placed in the destination directory. With this option, changes can be made to imported files after ALLFIX has processed them without jeopardizing the outbound files.

Add pic specs

This field tells ALLFIX to append the GIF or JPG file specifications to the beginning of the description of any incoming .GIF or .JPG files. The format of the specifications is as follows:

("width"x"height"x"number of colors")

The picture specifications will ONLY be appended if ALLFIX does not detect any specifications already present in the description. In other words, the description will be left in its original form if it already contains the specifications.

Update magic

This field tells ALLFIX if it should update the alias file for this fileecho when it encounters .TIC files containing the Magic verb (section 4.1.1).

Touch AV

If this field is set to Yes, ALLFIX will not convert or update AV protected archive files.

No Hold dir

In the Node manager, it is possible to assign a holding directory to a particular node. This means that all files will be copied to that directory instead of being sent via the normal method (being a netmail file attach, or via the Internet). With this option, this particular feature can be disabled for a particular fileecho. That means that if a system has a holding directory, the files received and forwarded in this particular fileecho, will not be copied into that holding directory, but sent via a normal file attach.

6.5.1.2 Global editing

Using the global edit functions, you can make changes to more than one fileecho at the same time. Using the global edit function is very intuitive. By pressing F2 you are presented with a menu containing important fileecho options. Select the option that you wish to change, enter the change, and then press ESC. You will then be presented with a list of groups. After selecting the groups that need to be changed, you will be able to select or remove other individual fileechos. Press ESC after selecting the fileechos to change and ASETUP will make the changes to those fileechos.

You can use the global edit routines to add, remove, or change systems in the system lists. You can change the address or the status of a system. There are two ways to set the status of a system when changing the status or adding a new system to the system lists. When adding a system or changing the status, you can set the status fields to the desired value. All fields are blank, by default. Blanks means "leave this field as is", which is, obviously, only applicable when changing the status because when adding a new system, all fields are set to No. If all of the status fields are left blank, then ASETUP will use the RAID settings for each respective fileecho to determine what the status settings should be. If you make extensive use of the RAID settings, then this is the preferred feature to use. If you do not use the RAID settings, then you should select the status fields as desired.

6.5.1.3 Fileecho options

This menu contains a number of options that are related to the fileecho system.

Keep original file date

When ALLFIX imports files in the BBS, it will reset the file date and time. BBS systems that do not store this information in the file database, such as any system using FILES.BBS files, determine if a file is new (for a user) by looking at the file date. In such situations it is almost a necessity that the date and time of a file be reset when it is imported. Other BBS systems store this information in the file database. These systems do not require that the actual file date be altered. This option should be set to "Yes" for systems in the later category.

Download counters

The download counters that ALLFIX should append before a file description when importing the file. Leaving this option blank disables this feature.

Update DESCRIPT.ION

4DOS has the ability to store descriptions of files in a file called DESCRIPT.ION, which is stored in each directory. ALLFIX can update that particular file, when importing files, if this option is turned on.

Inv. .?LO file ext.

This feature, only available when using a BinkleyTerm style mailer, identifies the extension of an invalidated flow file, for example "N?O".

Dupe checking

Duplicate file checking may be necessary in certain situations. ALLFIX is capable of storing information about an almost unlimited number of files for duplicate file checking, without compromising performance. This option can be used to specify what ALLFIX should check, when it is checking for duplicate files.

Min HD space to import

When importing a file, ALLFIX will check the amount of available space on the destination drive. If this amount minus the size of the current file is less than the in this field configured value, then ALLFIX will not import the file. If the value zero is entered, then ALLFIX will only check to see if there is enough space available to import the current file. The value entered in this field represents the minimum number of kilobytes that must be available on the destination drive. The value must be either 0 or be between 100 and 65535.

Max TIC archive size

This option sets a limit to the size of a TIC archive. TIC archives contain .TIC files and/or files destined for a particular system. Files that are larger than the maximum size will not be added to a TIC archive. ALLFIX will create a new TIC archive with a different name each time the addition of a file, whose size is less than the maximum size, would result in a TIC archive whose size is larger than the maximum size entered in this field. Each time ALLFIX has to add a file to a TIC archive, it will search for the first one, destined to that system, that has enough room left for the current file.

If a value of zero is entered in this field, then there is no limit on the maximum size of a TIC archive.

A unique name is calculated for each system, based on the network address. The extension of the archive is determined by the number of TIC archives waiting to be picked up by that system and the archive type. For example, the first TIC

archive for a system has the extension .C00, the second one, .C01.

Max sizes to pack

This option sets a limit to the size of the files that are included in the TIC archives. If the size of a file is larger than the value entered in this field, then it will not be added to the TIC archive and a normal file attach message will be created instead. A value of zero disables this feature.

TIC archive specs

This field can be used to define file specs that identify TIC archives. Some fileecho processors use different naming conventions for TIC archives than ALLFIX. If you have an uplink who uses such a tool, it may be necessary to enter the filespec here, so that ALLFIX will automatically recognize and unpack the TIC archive. You can enter multiple filespecs, seperating them with commas.

Del empty lines

This option will remove empty lines from a long description.

Filter ANSI (not ALLFIX!)

This option will remove any ANSI codes from a long description.

Filter LongDesc (not ALLFIX!)

This option has three different functions. First, it can be used to strip all the higher ASCII characters from a long description. Second, it can be used to strip the higher ASCII characters and the carriage returns, and third, it can be used to just strip the carriage returns from a long description.

Long descriptions frequently contain high ASCII characters. If new file reports are generated, then those high ASCII characters must be stripped from the description. This particular function will be performed when this option has been turned on. ALLFIX will, in the process, attempt to format the resulting description by converting any TAB characters to a single space and removing any extra spaces between text and borders created with high ASCII characters. The ability to strip the carriage returns will further ensure that the description is formatted correctly after stripping the higher ascii characters.

Add tag to desc

ALLFIX can place the fileecho tag before or after the file description. The fileecho tag is added as follows: (AREA:{fileecho tag}). You the options "Before+CR" and "CR+After" will add a carriage return after or before the tag, respectively, there by placing the tag on a seperate line.

Set uploader to

This feature is only available to people who use a BBS system that has a specific field for the uploader name in the file database files. The valid options are setting the uploader name to the name "ALLFIX", the name of the SysOp, or the name of the current fileecho.

Filter strings

There are three fields available where the user can define special strings that should be stripped from the long descriptions. These strings can contain special characters such as wildcards or sets in to order to build specific masks which can be used to remove BBS specific color codes and other information from a long description.

The wildcard ‘*’ means one or more and the wildcat ‘?’ means exactly one. A wildcard can be used as many times as necessary in specifying a mask. The wildcard ‘*’ can also be used to indicate one or more occurances of the symbol preceeding it.

A set is defined by enclosing the characters to search for within square brackets. For example, matching any letter ‘A’ to ‘Z’ can be specified as: [A..Z]. Matching the letters A, C, and E can be specified as: [A,C,E].

A ‘^’ character can be used to indicate that a particular string should not be in a mask. For example, the following mask could be used to match anything that begins with a capital letter ‘A’:

^A[A..Z]*

The following example removes all occurances of strings that begin with and end with a ‘@’ character and contain uppercase letters between the two ‘@’ characters:

@[A..Z]*@

The above example can be read as a string starting with the character ‘@’ followed by one or more letters in the range ‘A’ to ‘Z’ and terminated with a ‘@’ character.

6.5.1.4 LongDesc options

This menu contains the options that affect the way a Long Description is imported into a text based file database system. The last menu item in this menu, with the name "Show example" can be used to preview the way that ALLFIX would import a file with a long description into the BBS system that you use (as defined with FCOMP).

LongDesc character (not ALLFIX!)

This field defines the character ALLFIX should place before multiline descriptions to signal to the BBS that the following text belongs to the description of the previous file. This particular field is only necessary for BBS systems that store the file directory information in text files (for example, SuperBBS, PCBoard, Spitfire etc).

Below is a list of BBS types and the correct LongDesc character:

PCBoard |

RemoteAccess 1.xx +

SpitFire J

SuperBBS >

TBBS !

PowerBBS [space]

The description will be placed immediately after the LongDesc character, except for PCBoard systems, in which case the LongDesc character will be followed by ONE space which will then be followed by the description itself.

Before (not ALLFIX!)

This option specifies the number of spaces that ALLFIX should place before the LongDesc character. Normally, the LongDesc character should start on the second column, which means that there should be one space placed before the character. Below are the settings for some BBS programs:

PCBoard 31 SpitFire 0 TBBS 0 PowerBBS 32

After (not ALLFIX!)

This option specifies the number of spaces that ALLFIX should place after the LongDesc character. This value should be set to 0 for most BBS programs. PCBoard systems should set this value to 1.

LongDesc width (not ALLFIX!)

This option can be used to define the length of the description in the file database. Please note that this field is only necessary for BBS systems that use text based file database files (such as .DIR files for PCBoard and FILES.BBS files for RemoteAccess). If a value of 0 is inserted here, ALLFIX will use the default value of 45.

One line LongDesc (not ALLFIX!)

ALLFIX will place the entire long description on one line, if this option is turned on. Due to a limitation in the Turbo Pascal programming language, the length of a line of text can not be longer than 255 characters. Therefore, if the description is longer than 255 characters, the rest will be removed. Only text based filebase systems (such as the FILES.BBS system) are affected by this limitation.

Max length of LongDesc

Long descriptions do not have a maximum to the number of lines they may contain. This particular field controls the number of lines that ALLFIX will process. Any more lines will be ignored. A value of zero ignores the length of the long description and it will therefore be imported in its entirety. RemoteAccess 2.xx is known to have problems with descriptions that are too long. Therefore, it is recommended that no more than 10 lines be processed, if that BBS system is used.

6.5.2 Hatch manager

According to the Webster’s New World Dictionary, the term "hatch" means to bring into existence. Hatching, in the context of fileechos, means introducing files into a fileecho, much like writing a new message in a message echo.

The Hatch manager is used to tell ALLFIX which files should be hatched on a regular basis. File specifications can be entered. Each time files matching the file specification exist, they will automatically be hatched into the fileecho.

The hatch manager configuration is stored in the file called HATCH.FIX. Index information is stored in HATCH.IDX.

The following is a description of the fields in this menu:

Area

This field contains the name of the fileecho in which the to be configured file specification should be hatched.

Spec

This field contains the file specification that should be hatched. This field should contain the complete path and any necessary DOS wildcards. Please see the Hints chapter (section 12.3) about hatching files that are already located in the destination directory of the fileecho.

Desc

This field contains the description of the file. There are several meta commands that can be used to customize the description for each file hatched.

/GET

Get the description from the file database.

/REMOVE

Remove the description from the file database.

%xx

Echo the character at position xx. This meta command is useful to echo version numbers and dates into the description. For example: The combination %11%12 for the file NODEDIFF.A12 would be converted to the string "12". Values for %xx must be between 1 and 12.

Please note that these macros will not work for the external HATCH program (HATCH.EXE).

Days

This field is used to configure the days on which this file should be hatched.

Repl

This field contains the file specification that the newly hatched file should replace. The file specification entered in this field will be removed from the file database. It will also be included in the .TIC file and it will be deleted from the file databases of the downlink systems. This particular option is useful to replace old programs versions with new ones.

If the file specification entered in this field does not contain wildcards, then ALLFIX will automatically enter the name of the current file being hatched in this field. That means that the next time a file is hatched, the replace field will contain the name of the previously hatched file.

Mgic

This field contains the magic name that should be added to the alias file. The string entered here will also be included in the .TIC file and it will be added to the alias files for all the downlink systems, if the option is enabled at those systems.

Always

Sometimes it is necessary to hatch a certain file periodically. If the file has the same name, ALLFIX will reject it the second time as a duplicate. In this situation, this field can be set to Yes, which will tell ALLFIX to process the file regardless of whether it is a duplicate or not.

Copy This option tells ALLFIX to copy the file to the Fileecho destination directory instead of moving it, as it normally does. When using this feature, ALLFIX will turn off archive file attribute so that it knows that the file has already been hatched.

Inactive When set to Yes, this option tells ALLFIX to temporarily ignore this particular entry.

6.5.3 Magic filenames manager

The Magic filename manager offers the ability to perform certain functions when special files are received in a certain fileecho.

Up to 255 entries may be made.

The magic file configuration is stored in the file called MGICFILE.FIX. Index information is stored in MGICFILE.IDX.

There are fourteen different functions that the Magic filename manager can perform. Each function requires different information, therefore the menu will change depending upon the selected function, here after referred to as the type of magic filename.

More than one entry can be made for the same filemask and the same fileecho. Each magic filename configuration will be executed. However, ALLFIX does not always execute the magic filenames in the same order as they are configured in this menu. Some magic filename types are executed before ALLFIX begins processing .TIC files. Others are executed before processing a particular file, and the rest are processed after the file has been imported. It is not important to know which types are executed when, as long as none of the configured types are dependant on the order in which they are executed.

Each different Magic filename type has different options that need to be configured. The following two options are the same for every type, except for the PickUpFile and the ServiceReq option:

File mask

This field contains the file specification that will trigger this function.

From area

This field contains the fileecho where ALLFIX should look for the above configured file mask.

The following is a list of the different types and the rest of the options that need to be defined.

AdoptFile

This function can be used to copy a file into another fileecho. The effect is such that the file will be imported into the appropriate fileecho and then it will also be imported into the new fileecho, specified with this function.

To area

This field contains the fileecho into which ALLFIX should copy the above configured file mask.

CopyFile

This function can be used to copy a file into another directory.

Directory

This field contains the directory to which the above configured file mask should be copied.

DeleteFile

This function can be used to delete an incoming file mask, which means that it will not be forwarded nor imported into the file database. This type does not have any other options.

ExecCommand

This function can be used to execute a number of DOS commands.

Command

This field contains the DOS command that should be executed. Multiple dos commands should be separated with

a semicolon, ‘;’. The following meta commands may be used in this field.

%F The complete path and filename of the imported file.

%P The complete path without the trailing backslash, ‘\’.

%N The complete name of the file, not including the extension.

%E The complete extension of the file, not including the dot, ‘.’

%D The day number, 1-365.

%A The fileecho tag.

New task (ALLFIX/2)

This field determines if ALLFIX should start up a new process for executing these commands. If the value of this field is set to Foreground or Background, then a new process will be started and ALLFIX will continue as either a foreground or background process, respectively. If this field is set to None, then ALLFIX will execute the commands and wait until they are finished, before continuing.

ForwardTo

This function can be used to forward an incoming file to a number of systems that are not listed in the systems list for the respective fileecho.

Export

This field contains a list of systems to which the above configured file mask should be sent, along with a .TIC file.

HatchNew

This function can be used to hatch new files from the destination directory of the configured fileecho. Each time any new files exist in the destination directory, they will automatically be hatched. The file descriptions will be taken from the file database.

Days

This field contains the days on which ALLFIX should check the destination directory of this fileecho for new files.

KeepNum

This function can used to change the Keep # value of a particular file mask. The Keep # feature is explained in the previous chapter on the fileecho manager (section 6.5.1).

Keep #

This field contains the new value for the Keep # field.

MoveToArea

This function can be used to move a file from one fileecho into another one. Any file coming in the specified fileecho will be moved into the new fileecho. Please note that it will NOT be processed in its original fileecho.

To area

This field contains the fileecho into which ALLFIX should move the above configured file mask.

NoForward

This function can be used to prevent ALLFIX from forwarding a particular file mask. This type does not have any other options.

OtherPath

This function can be used to import a file into a directory, other than the normal destination directory for that particular fileecho.

Directory

This field contains the alternative directory where ALLFIX should import this file to. ALLFIX will update the appropriate file database that belongs to the new directory.

PassThruFile

This function can be used to process certain file masks as pass through files, which means that they will not be imported into the file database. This type does not have any other options.

PickUpFile

This function can be used to automatically forward a file mask to a list of systems without hatching it into a fileecho. This means that a .TIC file will not be included with the forwarded files.

Directory

This field contains the directory where ALLFIX should look for the above file mask.

Export

This field contains a list of systems to which this file mask should be forwarded.

SendOnFreq

This function can be used to automatically send files or messages with a file request. You can enter the filemask that ALLFIX should match.

Template

The template to send with the file request. The template is expanded before sending it to the requesting system.

File

The file(s) to send with the file requets. Please enter the complete name and filename or file specification.

Example, if you enter NODEDIFF.* and someone file requests NODEDIFF.A12, then ALLFIX would send the file(s) and/or the template configured here.

ServiceReq

This feature is only available in registered mode.

This function can be used to execute a specific program when a magic filename is requested. This feature could be used, for example, to allow a registration site to file request a new key for a new user. A service request is given a magic name, which can be defined in this menu. Each service request has a password, which the user must also provide. The program that has to be executed can also be defined. It is possible that the program needs a number of command line options which may need to be provided by the user. This can be using an at symbol, ‘@’. For each ‘@’ character, that ALLFIX encounters in the command line, ALLFIX will use the next string entered by the user. For example, let us assume that the following has been entered as the command to execute:

D:\REG\KEYGEN %s %a @ @

In the above example, the two ‘@’ characters are expanded to the two strings which were file requested by the system. In order to execute this service request, the user would have to "file request" the service request name, password, and also two other "magic names" which are password on to the KEYGEN program by ALLFIX.

For example:

FREQ: KEYGEN !PASSWORD Harald Harms

In the above example, the service request "KEYGEN" is executed. Since the command line for the program to execute contains two ‘@’ characters, the next two "magic names" which are "requested" are passed to the KEYGEN program as command line options.

Below is a list of the options in this menu:

Alias

The name of this service request. In the example above, the Alias is "KEYGEN".

Password

The password required to execute this service request. In the example above, the password is "PASSWORD".

Command

The command to execute for this service request. In the example above, the command is "D:\REG\KEYGEN %s %a @ @". The %s and %a macros are expanded to the requesting sysop name and aka, respectively.

Directory

After the command has been executed, ALLFIX will scan this directory for any files. ALLFIX will send whatever is contained in this directory to the requesting system. The files will be deleted after they are sent! In the above example, the program KEYGEN may place a new key file in this directory. This means that when someone request a key, they automatically get a new keyfile.

UnpackFile

This function can be used to unpack a file mask into a special directory.

Directory

This field contains the directory to which the files matching the file mask should be unpacked.

UpdateAlias

This function can be used to update the alias file with the currently imported file. ALLFIX will search the alias file for any files with the same directory as the destination directory of the currently selected fileecho and a filename that matches the in the next field configured filemask. Any files that meet both requirements will be updated. This type does not have any other options.

6.5.4 Group manager

Each time that a new fileecho is automatically added by ALLFIX or a new entry is made in the fileecho manager, ALLFIX and ASETUP have the ability to use default settings which can be defined per group within this menu.

Whenever a new fileecho is received, ALLFIX will select a group, based on the fileecho tag, and use the settings defined in that group for the new fileecho.

Whenever a new entry is made in the fileecho manager, ASETUP will prompt the user for a group. When a group is selected, the default options belonging to that group will be used for the new fileecho. The default settings, defined in the fileecho manager, will be used if no group is selected.

The group manager looks a lot like the fileecho manager. There are three options specific to the group, the rest of the options are default fileecho settings.

The following is a explanation of the six options for the groups. An explanation for the rest of the options can be found in the chapter discussing the fileecho manager (section 6.5.1).

Group

This field designates the group. An undefined group must be selected from the list of possible groups (0-255).

Name

This field contains the name of the group. An example of a group name might be "WINNET file distribution".

Mask

This field contains a mask, which is similar to a file specification used to determine which group an automatically added fileecho should belong to. The mask may contain the

wildcards ‘*’ and ‘?’. ALLFIX will try select the group with the best match.

For example: Consider the following two masks: "TIC*" and "TIC*ST". ALLFIX will select the group with the second mask if a new fileecho is automatically added with the name "TICTEST".

It is possible to enter more than one mask, by seperating the values with a semi-colon or a comma. For example, for the mask "WIN*,OS2", ALLFIX will add all fileechos starting with the string "WIN" or the string "OS2" to that group.

Uplink

This field defines which uplink files should come from in order to auto-add them to this group. It is possible to select "Anyone" or to select one of the uplinks defined in the uplink systems menu (see below).

Unique

This field determines if a new directory is made for each fileecho auto-added to this group. If this field is set to Yes, then ALLFIX will make a new directory under the destination directory entered for this group. If this field is set to No, then the destination directory for all auto- added fileechos will be the same as the destination directory for this group.

Add BBS

This determins if ALLFIX should automatically add a new file area to the BBS whenever it auto-adds a new fileecho. This particular feature is currently available for the following BBS types:

RemoteAccess, Maximus, Concord, PCBoard, Renegade, ProBoard, TriBBS, SpitFire, TAG, ShotGun, QuickBBS, and SearchLight

Please note that this feature is only available in the registered version of ALLFIX.

BBS Mask

If the "Add BBS" option turned on, ALLFIX uses this field to determine which BBS file area it should use for the default values of the new file area. All of the options that ALLFIX does not know, will be copied from this particular file area. Please note that the number of the file area must be entered in this field. ALLFIX will read through the BBS file area configuration and it will only add a new area if an area does not already exist pointing the the destination directory for the new fileecho.

If a value of 0 is entered in this field, ALLFIX will not use another BBS area as the template for the new area.

For those people who use TAG, please enter a value that is one larger than the actual file area number, as defined in the BBS. This is necessary because TAG starts counting the file areas at 0. ALLFIX assumes that 0 means that this option is disabled. Therefore, file area 0 should be entered into this field as file area one. All other area numbers should also be incremented with 1.

It should be mentioned that the "Systems" field, can be used to specify the people that should automatically be connected to a fileecho when auto-adding a fileecho which has been selected for this group. The "Systems" list in, in this context, is not used as a list where the possible uplinks are defined.

6.5.5 Uplink manager

New fileechos can be requested with the help of the AreaMgr. If an unknown area is requested, ALLFIX can automatically request that area from one of the available uplink systems (ie. one of the systems where files are received from). Those uplink systems can be configured within this menu.

The uplink system is very easy to use. When an unknown area is requested, ALLFIX will select a system defined in the uplink manager to request the new area from. ALLFIX will only send an uplink request for a new area if the requesting node has the "forward requests" option set to "Yes". If that option is not set to yes, then ALLFIX will tell the node that the area is unknown. Whenever an area is successfully requested, then ALLFIX will inform the user that the area has been requested from the uplink system.

The selection process is a bit complex. A fileecho areas list can be defined for each uplink system. ALLFIX will scan through those lists until it finds the requested area. The person requesting the new area must have access to at least one of the groups defined for the uplink system, otherwise ALLFIX will skip that uplink system. If the requested area is found in one of the fileecho areas listings, then the area will be requested. If the area is not found, then ALLFIX will request the new fileecho area from the first uplink system that has the unconditional flag turned on and at least one group to which the requesting system has access.

Information about the requesting system will be stored in the ALLFIX.DAT file. When the first files are received in the new fileecho area, ALLFIX will automatically add the new fileecho area to the configuration and add the requesting system(s) (since more than one system may request the new area before the first files have been received) to the systems list. ALLFIX will determine the group and the default fileecho settings by selecting a group from the group manager. More details about the group manager and how groups are chosen can be found in section 6.5.4. The fileecho description used in the new fileecho is selected in the following order:

6.5.6 Uplink options

When the AreaMgr requests new fileechos from your uplink(s), these requests are stored in the ALLFIX.DAT file. They will remain in that file until the first files for those fileechos are received. Sometimes it happens that the uplink also does not have the fileecho. In this menu there are two options that determine after how many days ALLFIX should automatically re-request the fileecho and how many times a fileecho should be re-requested before being removed from the ALLFIX.DAT database. These two options are:

Re-request rate

The number of days to wait before re-requesting a fileecho that has not been received yet.

Re-request times

The number of times to re-request a fileecho, before deleting the request. A value of 0 means that ALLFIX will re-request this fileecho indefinately, until it has been manually deleted from the list (section 6.11.4).

This menu also contains the following options:

Auto remove passthru echos

When a system removes him/herself from a passthru fileecho using the AreaMgr, and this system was the last system that received files from this fileecho, then ALLFIX can automatically disconnect this fileecho. This is usefull since no one receives these files anymore, not even yourself since it concerns passthru fileechos. ALLFIX disconnects the fileecho by sending an AreaMgr request to your uplink, and by deleting the fileecho in your configuration.

Auto-add delay

This feature has to do with the previous option. When a fileecho has been automatically removed since the last node disconnected him/herself, it is possible that there are still some files "in the pipeline" which your system will receive before your uplink has disconnected this fileecho. Normally, ALLFIX would then automatically auto-add the fileecho, which is obviously not desired. This field can be used to indicate how long ALLFIX should wait before it may auto-add the automatically deleted fileechos. If for example, you set the delay to 7 days, then ALLFIX will not auto-add a deleted fileecho, until 7 days have passed. ALLFIX will automatically re-request the fileecho when a different node requests the fileecho. When files are received as a result of the request, ALLFIX will automatically add the fileecho, regardless of the delay entered in this field.

6.6 New file reports

New file reports are message that contain a list of new files processed by a system. The Announce feature was encountered in the fileecho manager (section 6.5.1) and again in the group manager (section 6.5.4). This option determined whether files should be included the new file reports defined in this menu.

New file reports are defined by selecting one or more groups of fileechos that should be included in the report. Up to 255 new file reports may be defined.

The information concerning the files that need to be announced is stored in the TOBEREP.FIX and TOBEREP.IDX files. The database is capable of storing up to 8000 files, no new files will be added to the database once it is full. When the Announce command is given (see chapter concerning the ALLFIX commandline options (section 7), ALLFIX will announce all the new files according to the new file reports configured here. After the new file reports have been written, the database is emptied. Files belonging to groups that are not defined in a new file report, will be removed from the database. This means that the configuration should be double checked, because otherwise valuable information may be lost.

The new file reports configuration is stored within the file called REPORTS.FIX. Index information is stored in REPORTS.IDX.

The following is a description of the fields in this menu:

Groups

This field contains a list of the groups that should be included in this new file report.

Msg area

This field contains the message area in which this new file report should be written. The message area may be disabled. If it is, then ALLFIX will only send the new file reports to the nodes included in the systems list.

Use Aka

This field contains the aka that should be used.

Origin

This field contains the origin line that should be used.

Template

This field contains the template file that should be used.

From

This field contains the name that this new file report should be "from".

To

This field contains the name that this new file report should be addressed to.

Subject

This field contains the subject of this new file report.

Inactive

This field can be used to temporarily disable this new file report. If the value of this field is Yes, then ALLFIX will not process this new file report.

Systems

This field contains a list of systems that should receive netmail copies of this new file report. This field may be left empty.

6.7 BBS new file dirs

Besides being able to announce files received in fileechos, ALLFIX is also capable of announcing new files that are uploaded to the BBS. ALLFIX stores information, in each filearea, about the files contained in that directory. All new files, for the file areas defined in this menu, are added to the new file reports database. Then, when running ALLFIX with the Announce command, these new files will also be reported in the new file reports.

Up to 1024 entries can be made within this menu.

The BBS new file dirs configurations is stored in the file called NEWFILES.FIX. Index information is stored in NEWFILES.IDX.

The following is a description of the fields in this menu.

Group

This field contains the group that this entry belongs to.

Comment

This field contains a comment for this entry.

File areas

This field contains the file areas that belong to this entry.

6.8 Allfiles lists

FIXUTIL is capable of generating Allfiles listings or Newfiles listings. An Allfiles list is a complete or partial list of the files on the BBS. A Newfiles listing is the same as an Allfiles listing, except that only the files of the last xxx number of days are included in the list, where xxx is a value between 1 and 365.

An Allfiles list has a Tag, which identies the entry in the database. FIXUTIL can be called up with the name of the Tag to generate the Allfiles or Newfiles listing.

Up to 1024 entries can be made within this menu.

The Allfiles configurations is stored in the file called ALLFILES.FIX. Index information is stored in ALLFILES.IDX.

The following is a description of the fields in this menu.

Tag

This field contains the Tag which identifies the entry in the database. A tag can contain any type of string, for example, "ALLFILES", or "ALLPICTURES". The Tag is used later to tell FIXUTIL which allfiles listing to generate.

File name

This field contains the name of the file that should be created by FIXUTIL. The path of to the filename to create should be included. For example, the following filename could be entered: C:\FILES\TEXT\ALLFILES.TXT.

Template

This field contains the name of the template that FIXUTIL should use to generate the Allfiles or Newfiles listing. Please see the sample ALLFILES.APL and NEWFILES.APL included in the TEMPLATE.ZIP archive for an example.

Age

This field determines whether an Allfiles listing or a Newfiles listing will be created. Enter a value of 0 means that an Allfiles listing will be made, in other words, all of the files will be included in the list. Entering a value between 1 and 365 means that only those files that are newer than the value entered will be included. For example, if a list of all of the files received in the 30 days is required, then the value 30 should be entered.

File areas

This submenu can be used to select which file areas should be included in the Allfiles or Newfiles listing. This field makes it possible to make listings of certain subsets of the file areas available in the BBS. ALLFIX can handle up to 64000 file areas. The up and down arrow keys can be used to scroll through the list of file areas.

The following other keys are available:

ENTER, SPACE

The enter key or the space bar can be used to turn an area on or off.

F2

Turn all the areas on or off. If one area is on, then the rest will be turned on. If all the areas are on, then they will all be turned off.

6.9 Request Processor

ALLFIX contains a fully functional request processor. A request processor is a program that handles file requests for a mailer. Normally, a mailer is capable of handling file requests, however, external utilities often offer more features.

The request processor in ALLFIX is fully integrated with the other features in ALLFIX. This means that when someone file requests a file from your system, ALLFIX will send the person a .TIC file if the system is listed in the Node manager, and ALLFIX will send the file description of the file regardless of the type of BBS you use, as long as it is supported by ALLFIX.

Please note that the request processor only works if you are a registered ALLFIX user.

In this particular menu, there are a number of fields that control how ALLFIX works.

Active

This field determines whether or not the request processor is active. If you want to be able to use the ALLFIX request processor, then this field must be set to "Yes".

Report

This field can be used to define the template that is used sent to a system after processing a file request. Please see the sample RPREPORT template for more details.

  • note: The standard RPREPORT template reports why a file request failed. For example, it will indicate that the file was missing or that the password was wrong. For security reasons, you may wish to change the template to only indicate that something went wrong, without specifying what.

Flag mode

This field determins the types of flags ALLFIX will use in the response file which is returned to the mailer. The options are Default, Cantaloup, InterMail, or BBBS.

CC sysop

This field determins if ALLFIX should send a carbon copy (CC) of all file request reports to the SysOp. The CC, which is a netmail, will be written to a .PKT file which the mailer tosser will toss to the netmail folder. ALLFIX does not make a netmail message directly, since it is not officially allowed, according to the specifications for external request processors. This field has three different options, namely, No, Always, and On error. When "On error" is selected, ALLFIX will only send CC of the file request report if one or more of the files requested was not matched.

There are three different groups that contain the same options. These groups are unlisted, unsecure, and secure. These are three different types of mail sessions that could occur. An unlisted session is one when the requesting node is not listed in the nodelist. An unsecure session is one where there is no password setup for the requesting node. A secure session is one where there is a password setup for the requesting system. Everyone has access to the settings for unlisted sessions. If a session is unsecure, then it also has access to those settings. When a session is secure, the settings for secure sessions is also available. The options for each of the sessions are:

Alias

This field defines the alias file that is used for this type of session. This alias file must have the following format if you want to use the request processor in ALLFIX:

[magicname] [file 1] [file 2] … [file n] [/password]

For example:

ALLFIX D:\AREA1\AFIX440.ZIP D:\AREA1\ALLFIX.REG BETA D:\AREA2\AFB_B004.ZIP /PASSWORD

In the above example, when someone file requests magic name ALLFIX they will receive the AFIX440.ZIP archive and the ALLFIX.REG form. In order to file request the latest ALLFIX beta they have to file request magic name BETA with the password "PASSWORD".

Please note that ALLFIX will use the above format for the alias file if the request processor has been active, by setting the active field in this menu to "Yes".

Groups

This field defines the groups that are available in this type of session.

List

This field defines the directories that are available in an unsecure mailer session. The format of this file is very simple. It must be a plain text file. Comments, designated with a semi-colon, ‘;’, are allowed. It is also possible to define passwords per directory by placing the password behind a directory, preceeded with a front slash, ‘/’. For example:

D:\AREA1 D:\AREA2 /PASSWORD

In the above example, people can file request files from the directory D:\BBS\FILES\AREA2 if they use the correct file request password.

Max files

This field can be used to define the maximum number of files to send per session.

Max size

This field can be used to define the maximum number of kilobytes te send per session.

Max time

This field can be used to define the maximum number of minutes a file request session may last.

The ALLFIX request processor is very easy to install in your mailer. ALLFIX expects the following command line options, in this order:

Aka

Requesting system’s aka.

Sysop

Requesting systems sysop name.

Type of session

The string "SECURE" for secure sessions, "UNSECURE" for unsecure sessions. If anothe string is received, then it is assumed that the system is unlisted.

Response file name

The name of the response file which is returned the mailer after processing a file request. The name of this file is provided by the mailer.

List of requested files

The name of the file containing the file requests. This file is provided by the mailer.

ALLFIX should be installed as follows in FrontDoor and MainDoor:

D:\ALLFIX\ALLFIX.EXE Rp =A =O =B =X =T =R

ALLFIX should be installed as follows for InterMail:

D:\ALLFIX\ALLFIX.EXE RP %A %O %B %X %F

Please note that for InterMail, the response filename is identical to the request file name. Therefore, only the request filename is specified on the commandline.

ALLFIX is also capable of working with SRIF files. These files are created by some of mailers and effectively contain all the information that ALLFIX may need. When using ALLFIX with a mailer that supports SRIF files, you must specify the -SRIF command line option and the name of the SRIF file on the commandline. Example:

D:\ALLFIX\ALLFIX.EXE Rp -SRIF [name of SRIF file]

Most mailers should have a macro which will expand to the name of the SRIF file. Some mailers do not have a macro, and will automatically append the name of the SRIF file to the end of the command line. In that case, simply specifying "Rp -SRIF" on the command line is enough.

The commandline to use for Argus mailer is:

D:\ALLFIX\ALLFIX.EXE Rp -SRIF %SRIF%

An example commandline to use for T-Mail is:

Process FREQ Allfix Rp -SRIF C:\Files\Flags\Busy%TASKNO%.T-M

In the above example, the path is the T-Mail Flag_dir as configured in the T-MAIL.CTL file. The name of the SRIF file is the Flag_Session as defined in that same file.

The commandline to use for SGMail is:

\ALLFIX\ALLFIX.EXE Rp -SRIF %1

where %1 will be filled in by SGMail with the name of the SRIF file.

It is possible to file request "AreaMgr" services. The following services are available for file requesting:

%LIST, %QUERY, %STATUS, and

%UNLISTED, %HELP.

As mentioned before, ALLFIX is also capable of processing file requests via the Internet. For the Internet, the Max files and the Max size can also be defined. In addition, a seperate report template can also be defined. ALLFIX will try to determine who the requesting system is, by comparing email addresses with those in the Node manager. Based on this, ALLFIX will determine if the system is unlisted or not. Based on the whether it can find the system or not, it will use the appropriate access criteria.

To  file request a  file via the  Internet, the  email message must

contain the word "FREQ" in the subject line and in the body contain one or more lines containing the files or magic names to be file requested, preceeded with the text "FREQ:". For example:

From: Harald Harms <ken@blkdoor.com> To: John Doe <ken@blkdoor.com> Subject: FREQ

FREQ:ALLFIX FREQ:ALLFILES

Please note that requesting the AreaMgr services can also be done via the Internet! For example, add "FREQ:%LIST" to the example above, and ALLFIX will also send a %LIST report back via the Internet!

6.10 Node manager

Each system, from which files are received, must be defined in the node manager for security reasons. The node manager is also used to configure special options for each downlink system. Please note that not every downlink has to be configured in the node manager. ALLFIX will use the default settings, which can also be configured in this menu, for those systems that are not configured here.

Up to 2048 systems can be configured in this menu.

The node manager configuration is stored in the file called NODEFILE.FIX. Index information is stored in NODEFILE.IDX.

It is possible to add the current system (being viewed or edited) to fileechos from within the Node manager, by pressing the F7 key. After pressing this key, you will be presented with a list of the fileechos. Each fileecho that the system is connected to will be marked with a check-mark. You can edit the way the system is connected up to a fileecho, by simply pressing the Enter key. You can disconnect a system by simply pressing the Delete key.

The following is a description of the fields in this menu.

System

This field contains the address of the system.

Sysop

This field contains the name of the SysOp for the above configured system.

Holding directory

This field contains the name of the directory where ALLFIX should place files for this system. If this option is defined, then ALLFIX will NOT write any netmail file attaches nor update any .?LO or queue files. The purpose of this option is to make it possible to send files via medium other than a mailer. An excellent example is sending the files via a tape. ALLFIX will place all the outgoing files, including .TIC files, in this directory. It is up to the user to delete the files at the appropriate time.

Route via

This field contains the address of the system through which all files and messages for system this should be routed. If this field is used, then the TIC file mode MUST be set to "Advanced TIC file". ALLFIX will add one extra field to the .TIC file, so that the nodes through which any files for this system are routed know that the files are not for them. Furthermore, ALLFIX will send the files to the system specified in this field. That system will have to make sure that the files are then sent to the correct destination system.

Authorized groups

This field contains a list of groups that this system has access to. This system will be able to add any fileechos belonging these groups with the use of the AreaMgr. Please note that the system also has access to the public groups defined in the AreaMgr options menu!

Fileecho password

This field contains the password that will be included in each .TIC file. This system must define the same password in their node manager.

AreaMgr password

This field contains the password used for to access the AreaMgr. The node is required to use this password in order to make use of the AreaMgr features.

PKT password

This field contains the password that will be used in .PKT files. This was primarily added for BinkleyTerm mailers where PKT passwords are almost always required, even for file request reports. If you do not think you need this field, then it is best not to use it.

Use aka

This field contains the aka that should be used when sending messages or files to this system. The options "Setup/Aka matching" means that ALLFIX will use the aka defined in the fileecho manager, or use aka matching if no specific aka is forced in the fileecho configuration.

File attach status

This field determines the status of file attach messages, .?LO files for BinkleyTerm and Portal of Power, and the queue files for D’Bridge created for this system.

Other mail status

This field determines the status of all other messages created for this system. "Other mail" includes such items as Notify messages, new file reports, new fileecho announcements, and netmail FileFind requests.

TIC file mode

This field determines what type of .TIC file, if any, should be sent to this system. The available options are:

None

Do not include a .TIC file.

Normal TIC file

Include a normal .TIC file.

Advanced TIC file

Include an advanced .TIC file. The advanced .TIC files contain the "AreaDesc" verb, the "To" verb, the "Cost" verb (not yet used by ALLFIX), and the "Ldesc" verb. The "To" verb is necessary for routing files via other systems.

Packing mode

This field determines if forwarded files for this system should be compressed into a TIC archive. The available options are:

No packing

Do not pack any files.

Pack TIC files

Pack all the .TIC files into a TIC archive.

Pack ALL files

Pack all the forwarded files including the .TIC files into a TIC archive.

Pack TIC+file

This option, also referred to as the "Mini tic archive", will pack ONE .TIC file along with its associated archive into one TIC archive. This means that one TIC archive is created for each TIC – file pair.

TIC archives, with the exception of the TIC+file tic archive, are compressed at the end of a session. This means that all files to be compressed are stored in a "list" file. After all files have been processed, ALLFIX will run through all list files and create all of the TIC archives. The mini tick archives are created on the fly, for technical reasons. It is also important to note that incase something goes wrong and ALLFIX crashes during a session, before it has a change to create all of the TIC archives, it will simply continue where it left off the next time it is started up.

The packing options, unfortunately, do not yet work in conjunction with the Holding directory option (see above).

Compression type

This field determines which compression type should be used when creating TIC archives and ArcMail for this system.

6.10.1 Internet options

This menu contains the Internet settings for this particular system. Please consult section 6.3.5 for an explanation of these options.

6.10.2 Advanced options

This menu contains the following advanced options:

Inactive

This field determines if this system is inactive or not. This field can be controlled by the node via the %PAUSE and %RESUME AreaMgr commands. If this field is set to Yes, then

this node will not receive any files nor will it receive any notify messages.

Copy other files

When a holding directory is used (see above), this option can be used to tell ALLFIX to move other files for this system to the holding directory as well. If turned on, ALLFIX will move all other files that are on hold for this particular system including the netmail messages to the holding directory. Netmail messages will be stored in the form of a .PKT file, which the destination system can unpack. If the "delete when sent" option is toggled for a particular netmail with a file attach, then ALLFIX will move the actual file to the holding directory. In other situations, it will only copy the file. If the "truncate when sent" option is toggled for a particular netmail with a file attach, then ALLFIX will copy the file to the holding directory and truncate the original to 0 bytes.

Include template file

This field determines whether or not ALLFIX should send a netmail announcement to this system with each forwarded file in those fileechos for which a template was defined.

Send notify list

This field determines if this system should receive a notify message when the generic notify command is given. For more details, please consult the chapter concerning the Notify function (section 7.5).

Notify new fileechos

This field determins if this sytem should receive a notification whenever a new fileecho has been auto-added and to which he was automatically connected.

Forward requests

This field determines whether or not ALLFIX should forward requests for unknown areas, made by this system via the AreaMgr, to an uplink.

Allow Auto-add

This option determines whether or not ALLFIX should automatically add new fileechos coming from this system. This option is only available in the registered version.

Remote maintenance

This option determines whether or not this system is allowed to perform remote maintenance for another system by using the

%FROM AreaMgr command. This option is only available in the registered version.

Send .TIC with FREQ

This option determins whether or not ALLFIX should send a .TIC file with the files that are file requested by this system. Please note that this feature is only relevant if the request processor is active.

6.10.3 Cost sharing

Billing

This field determines if this node should participate in cost sharing. Valid options are "No", "Yes", and "Membership". Nodes for which the "Membership" style billing is turned on are not considered cost sharing nodes when calculating the cost of files tossed in fileechos. These nodes are charged the "Membership fee" on a periodic basis determined by the "Send day" and "Send Bill" options.

Bill groups

This field contains the list of groups for which this node should participate in the cost sharing.

Credit

This field contains this node’s credit level.

Warn level

This field contains the credit level at which ALLFIX should send the node a warning that the credit level is getting low. ALLFIX will only send the warning when this level is passed. ALLFIX will use the WARNING template file for the warnings.

Stop level

This field contains the credit level at which ALLFIX should stop sending files to this node. ALLFIX will send the node a message announcing the status of the credit level. ALLFIX will use the STOP template for these announcements.

Send on

This field determines the day that a bill (or invoice) should be sent. Values 0 to 28 can be entered. The entered value represents the day of the month or week to send the file (see next option). If the "Send Bill" feature is set to Yearly, then this value represents the month when the bill will be sent.

Send bill

This field determines when a bill (or invoice) should be sent. Possible options are: Direct, after each event; Weekly, once a week on the day of the week specified in the previous field (1 – Sunday; 7 – Saturday); Monthly, once a month on the day of the month specified in the previous field; or Yearly, on the first day of the month specified in the previous field.

Add %

This field defines the extra percentage to add to the total price of the bill. This field can be used to define the extra VAT taxes, for example.

Membership fee

This field determines the membership fee for membership style billing. A node’s credit level is reduced by this fee each time a bill is generated.

6.11 Utilities

6.11.1 Template editor

This menu offers the ability to view, edit, create, and delete template files.

Pressing the ENTER key will call up the editor. If a external editor has been defined in the "External programs" menu, then this program will be called up. Pressing ALT-ENTER will over-ride that setting and call up the internal editor.

6.11.2 Export data

This menu contains a number of menu items that can be used to export portions of the configuration to plain ASCII files.

Export everything Export main configuration Export FileFind areas Export new file reports Export fileecho areas Export hatch configuration Export magic filenames Export group configuration Export BBS file areas Export ALLFILES Export Request processor Export node configuration

The above configurations are exported using INIUTIL. The text files can be edited manually and imported back into ASETUP via the corresponding option in the Import data menu.

Create fileecho list

Generate a list of fileechos and their descriptions. The format of the ASCII file is:

<area> <description>

Create tag list

Generate a list of the fileechos. The format of the ASCII file is:

<area>

Cross check FILEBONE.xx

Generate a list of all the fileechos that are not listed in any of the known FILEBONE.xx and TAG files. ASETUP will scan all of the FILEBONE.xx and TAG files which are linked to Uplink systems, and generate a list of all of the fileechos that are not listed in those lists.

Nodes I0 Echos breakdown

Generate a list of the systems defined in the node manager and all the fileechos that those systems are connected to.

Export fileecho dest dirs

Generate a list of the destination directories.

6.11.3 Import data

This menu has a number of functions that can be used to import the fileecho and node configuration from other programs when converting to ALLFIX. Only new unknown fileechos and systems will be added.

Import main configuration Import FileFind areas Import new file reports Import fileecho areas Import hatch configuration Import magic filenames Import group configuration Import BBS file areas Import ALLFILES Import Request processor Import node configuration

For the above options, ASETUP will use INIUTIL to import the text configuration files. These text files can be generated using the associated option in the Export data menu.

TICK configuration

Import the fileecho and system information from the TICK configuration file, TIC.CFG.

FILEBONE.NA/NO

Import the fileechos from the FILEBONE.NA or FILEBONE.NO files. Since these files only contain the fileecho tag and their descriptions, ALLFIX will use the "Masks" defined in the Group manager to determine all the settings for the new fileechos. If a matching group can not be found, ALLFIX will use the default fileecho settings.

FileMgr fileechos

Import the fileecho configuration from the FileMgr 0.70 beta AREAFILE.FM file.

FileMgr systems

Import the system configuration from the FileMgr 0.70 beta NODEFILE.FM file.

James fileechos

Import the fileecho configuration from the James 2.21 JAMES.ARE file.

James systems

Import the systems configuration from the James 2.21 JAMES.NDE file.

6.11.4 Uplink requests

When people use the AreaMgr to request a fileecho which is not known on your system, ALLFIX will automatically request that fileecho from your uplink. In doing so, it will store some information about the request in the ALLFIX.DAT file. This menu will present you with a list of of the requested fileechos, who requested them, from which uplink ALLFIX requested the echo, and the date that the request was done. It is also possible to delete entries in the list.

6.12 Information

This menu contains some information concerning ALLFIX and ASETUP.

6.13 Exit program

This menu item is used to exit the configuration program. ASETUP will prompt the user if any changes have been made.

6.14 Template files

ALLFIX contains an easy to use and dynamic macro language called APL (ALLFIX template Programming Language). Template files end with the extension .APL. All template files can make use of the macro language, however, not all the different key words can be used in every template file.

Template files are plain ASCII text files that contain special keywords that will be replaced with their respective values. All keywords must be preceded by a ‘@’ character, however, the use of an ‘@’ character does not mean that the following word is a keyword. Strings containing an ‘@’ character will only be expanded if it is a keyword or function. Sometimes it may be necessary to prevent ALLFIX from parsing a string containing an @ symbol, for example, in email addresses. In this case, the @ symbol can be "escaped" by preceding it with another @ symbol. ALLFIX will recognize the double @ symbols, remove one, and leave the rest of the string alone.

Template languages can contain a number of different types of loops each ending with a special @end keyword. Sometimes mistakes in the definition of these loops can cause ALLFIX to end up in an endless loop. In order to help protect against these situations, ALLFIX will perform a simple syntax check of the template. At this point, it simply checks to see if the loops are properly ended with the @end keywords. If there is an error, ALLFIX will not process the macro file.

There are four types of template files:

1 Notify/AreaMgr templates 2 Netmail announcement templates 3 Report/FileFind/Bill/Request templates 4 Archive banner templates 5 Request report specific macros

6.14.1 Standard template files

There are a number of standard template files that ALLFIX uses. The names of these template files can not be changed.

ALLFILES

This template can be used for generating allfiles or newfiles listings. This template was developed by Felix Mueller. It

has been included in the release package in the un-modified form.

AREAMGR

This template is used for the %HELP AreaMgr command.

BILL

This template is used for the billing system.

FILEFIND

This template is used for the FileFind replies. The name of this template can be configured in the FileFind menu, however, if no other name is specified, then this file will be used.

LIST

This template is used for the %LIST AreaMgr command.

NOTIFY

This template is used to send Notify messages.

PAUSE

This template is used for the %PAUSE AreaMgr command.

QUERY

This template is used for the %QUERY AreaMgr command.

RESUME

This template is used for the %RESUME AreaMgr command.

STATUS

This template is used for the %STATUS AreaMgr command.

STOP

This template is used to notify a node that he will no longer receive any files because his credit level is to low.

UNLINKED

This template is used for the %UNLINKED AreaMgr command.

WARNING

This template is used to notify a node that his credit level is approaching the stop level.

6.14.2 Key words

The following is a list of keywords, the type of templates for which they can be used, and a short description:

@msgto

type: 1,2,3

To whom this message is addressed.

@msgtoaka

type: 1,2,3

Address to which this message is addressed.

@msgfrom

type: 1,2,3

From whom this message is sent.

@msgsubject

type: 1,2,3

Subject of this message.

@akatouse

type: <all>

Aka to use for this report.

@systemname

type: <all>

System name.

@sysopname

type: <all>

Sysop name.

@phoneline1, @phoneline2, @phoneline3

type: <all>

Phone numbers, as defined in Site information menu.

@location

type: <all>

Location.

@flags

type: <all>

Flags.

@baud

type: <all>

Baud.

@prgname

type: <all>

The name of the ALLFIX program (i.e. ALLFIX, ALLFIX/2, or ALLFIX!).

@prgversion

type: <all>

ALLFIX program version. (Ex. 4.30)

@daynr, @day, @dayofyear, @monthnr, @month, @year

type: <all>

Various date values.

@hour @min

type: <all>

Various time values.

@cookie

type: <all>

Fortune cookie. This option only works if a compiled COOKIE.DAT file is stored in the system directory.

@filename

type: 2,3,4

File name.

@filedesc

type: 2,3,4

File description.

@filesize

type: 2,3,4

File size.

@filesizekb

type: 2,3,4

File size in kilobytes.

@filecost

type: 2,3,4

File cost.

@filedate, @fileyear, @filemonth, @fileday

type: 2,3,4

Various date statistics of the file.

@filetime, @filehour, @filemin

type: 2,3,4

Various time statistics of the file.

@fileage

type: 2,3,4

The age of a file, in number of days.

@fileorigin

type: 2,3,4

Origin of this file.

@filefrom

type: 2,3,4

Where this file was received from.

@filecrc

type: 3,4

Crc of the file.

@filereplace

type: 2,3,4

File(spec) this file replaces.

@filemagic

type: 2,3,4

Magic name for this file.

@fileecho

type: <all>

Fileecho tag or BBS file area name.

@destdir

type: 1

Fileecho destination directory.

@areanr

type: 3 (only FileFind replies)

The BBS file area number.

@raidlevel

type: 1

Level, as defined in the RAID menu (fileecho manager).

@raidflags

type: 1

Flags (as in FILEBONE.NA file) based on the settings in the RAID menu (fileecho manager).

@passthru

type: 1

This macro returns "Yes" if the fileecho is pass through. Otherwise, it will return the value "No".

@group type: <all>

Group this fileecho or BBS file area belongs to.

@groupname

type: <all>

Name of the group this fileecho or BBS file area belongs to.

@echodesc

type: <all>

Fileecho or file area description.

@systems

type: 1

Return a list of all of the systems that a connected to this fileecho. The list has the following format:

2:281/415, 2:281/416, 2:281/417, …

@unitcost

type: <all>

Unit cost of files forwarded in this fileecho.

@unitsize

type: <all>

Size of one unit, in this fileecho.

@invoicenr

type: 3

Invoice number for current bill.

@blockbytes

type: 3

Total number of bytes in current block.

@blockkb

type: 3

Total number of Kb’s in current block.

@blockfiles

type: 3

Total number of files in current block.

@totalbytes

type: 3

Total number of bytes in current report.

@totalkb

type: 3

Total number of Kb’s in current report.

@totalfiles

type: 3

Total number of files in current report.

@billsubtotal

type: 3

Total cost exc. percentage to add to bill.

@billaddperc

type: 3

Percentage add to bill.

@billtotal

type: 3

Total cost inc. percentage to add to bill.

@echostat

type: 1

A character designating the type of access a system has to the current fileecho.

+

The system is connected to the current fileecho and only receives files.

*

The system is connected to the current fileecho and sends files.

&

The system is connected to the current fileecho and both sends and receives files.

The system is does not have access to the current fileecho.

[space]

The system is not connected to the current fileecho.

@avgfiles

type: 1

Average number of files in this fileecho per month.

@avgkb

type: 1

Average number of kb in this fileecho per month.

@echopassword

type: 1

Fileecho password for this system.

@mgrpassword

type: 1

AreaMgr password for this system.

@availgroups

type: 1

Groups this system has access to.

@filestat

type: 1

Message status to use for all file attach messages to this system.

@mailstat

type: 1

Message status for all non-fileattach messages to this system.

@ticmode

type: 1

TIC file mode for this system.

@packmode

type: 1

Packing mode for this system.

@systemstatus

type: 1

Returns "inactive" if the inactive option is turned on for this node. Otherwise, it will return the value "active".

@template

type: 1

Include template files for this system.

@notify

type: 1

Send notify messages to this system.

@forward

type: 1

Forward requests to uplink.

@autoadd

type: 1

Allow auto add for this system.

@remote

type: 1

Allow remote maintenance.

@compression

type: 1

Compression type for this system.

@billing

type: 1

Billing status for this system.

@billgroups

type: 1

Groups for which this system should be billed.

@credit

type: 1

Credit this system has left.

@warnlevel

type: 1

Credit level at which a credit low warning message will be sent to the system.

@stoplevel

type: 1

Credit level at which the system will stop receiving files.

@addpercentage

type: 1

Percentage to add to the node’s bill.

@membership

type: 1

The membership fee that this person should pay.

@pfileecho

type: 1

The name of the pending (i.e. requested from uplink by this system) fileecho.

@pdesc

type: 1

The description of the pending fileecho.

@pdate

type: 1

The date that this pending fileecho was requested from the uplink.

@requestname

type: 5

The magic name that was file requested but could not be found.

@requesterr

type: 3

The reason why the magic name could not be found. Possible reasons are "Password error", "File exceeds size limit", "File exceeds number of files limit", and "File not found".

@remotemailer, @remoteserial, @remoteversion

type: 5

The remote mailer name, serial number, and version number for this file request, respectively.

@sessiontype

type: 5

The type of file request session (unlisted/unsecure/secure).

@connectspeed

type: 5

The connect speed of this file request.

@freqfrom, @freqfromaka

type: 5

The name of the sysop performing the file request and the aka of his or her system, respectively.

@rpflimit, @rpslimit, @rptlimit

type: 5

The maximum number of files, size, and time limit, respectively, for this file request session.

@downtime

type: 3

This function predicts the download time for a file based on the connection speed of the system performing the file request.

@requestbegin

type: 5

Begin a request block, used for displaying the filenames and magic file names that were not found.

@groupbegin

type: 1,3

Begin a group block.

@filebegin

type: 3

Begin a file block.

@areabegin

type: 1,3

Begin a fileecho block.

@billbegin

type: 3

Begin a bill block.

@pendingbegin

type: 1

Begin a pending fileecho block.

@end

type: 1,3

End the last block that has been opened with a begin command. The block commands will be explained in the next section.

@allowbreak

type: 1,2,3

Signal that a page break may occur here, if the length of the current page is almost at the maximum size.

@forcebreak

type: 1,2,3

Force a page break to occur at this point.

6.14.3 Blocks

It is possible to define a loop using the block commands. Every block must be terminated with a @end command and blocks may be nested within each other, however a block may not contain a nested block of the same type.

Everything that is contained within a block will be output as many times as the block is repeated.

The best way to explain how a block works is to give an example. The following template outputs a list of all the fileechos:

@areabegin @fileecho @end

The block is started with the values for the first fileecho. Each time the end of the block is reached, the macro interpreter will jump back to the beginning, with the values for the next fileecho, until there are no more fileechos left.

The other blocks works exactly the same as the previous example, except that they act on different variables.

6.14.4 Functions

The macro language also contains a variety of functions that can be used to manipulate the values returned by the keywords.

In the following statement: 2 + 3, the function plus (denoted by a ‘+’ character) returns the value of 2 added to 3. The values 2 and 3 are the input variables and the value 5 is the result returned by the function plus.

A function such as the plus in the previous example is called an infix function because the function is between the two input values. Another possibility is postfix, where the function is listed behind the input values. The last possibility is prefix, where the function is listed before the input values.

The postfix format of the previous example is: (2,3)+ . Here the function is clearly listed after both inputs have been defined.

The prefix format of the previous example is: +(2,3). Here the function is listed before both inputs.

APL uses the prefix format for all the functions. Some of the functions need variables and others do not. It is important to point out that keywords are in principle also functions without any variables since they return a constant value that does not depend on any input variables. This is very important because keywords and functions can be used interchangeably as inputs for functions. There are a number of exceptions to this rule, which will be explained later.

Before listing and explaining each function in APL, it is necessary to introduce a few notation rules.

1. [X|Y]

Means either X or Y. The separator | means ‘or’. Any number of options may be listed between the square brackets and any one of them may be selected, but no more than one. Whenever such a selection is possible, each character will have a certain meaning. For example: [L|R] might mean left or right.

2. "string"

A string is any sequence of characters enclosed by double quotes. An empty string is denoted by two double quotes: "".

3. [,option]

Any option enclosed by two brackets and containing a comma within the brackets denotes an optional parameter that may be left out. Some functions have more than one optional parameter. Optional parameters may be left out, but they may not be skipped ie. if the second optional parameter is necessary then the first one must also be specified, but a third one may be left out.

4. =

This character symbol means equal to.

5. <>

This character symbol means not equal to.

6. @id

This character symbol stands for the term identifier which refers to keywords, functions, or variables (to be explained later). Any one of the previous three identifiers may be used in place of the @id character symbol.

7. @const

This character symbol stands for the term constant which refers to a numerical constant or a string, which must be enclosed with quotes.

8. @var

This character symbol stands for the term variable which can be assigned values and used as any other identifier.

The following is a list of list of all the functions:

@just(@id, [L|R], Size [,PadChar] [,R])

This function justifies the value of an identifier left or right in a field of length designated by size and filled up with characters designated by padchar. If the R, for Raw mode, is used then the string will be cut off if it is to long, otherwise APL will attempt to trim off the last word by searching for the first space at the end of the string. The default value of the padchar is a space.

@center(@id,Size [,PadChar] [,R])

This function centers the value of an identifier in a field of length designated by size and filled up with the characters designated by padchar. If the R, for Raw mode, is used then the string will be cut off if it is to long, otherwise APL will attempt to trim off the last word by searching for the first space at the end of the string. The default value of the padchar is a space.

@copy(@id, begin [,num] [,R])

This function is used to copy a portion from the value of an identifier. The position to start copying is specified with the begin option and the number of characters is specified with the num option. If the R, for Raw mode, is used then the string will be cut off where specified, otherwise APL will attempt to copy until the last word that would otherwise get cut off.

@overflow

This function repeats the previous @just, @center, or @copy command with the rest of the string that did not fit in the field or was not copied from the value of the identifier. This command will be repeated as many times as necessary until the entire result has been output.

@clearoverflow

When there is "overflow", this text will not be removed from the buffer until the next function that causes overflow. Sometimes, it is necessary to empty the overflow buffer. This function can be used for that purpose.

@setoflimit(Size)

This function can be used to set a limit to the number of times an overflow function is repeated for a particular field. If the value of Size is 5, for example, no more than 5 overflow lines will be written, even if the overflow buffer is not yet empty. This function can, therefore, be used to reduce the size of a new file report, for example, by limiting the length of a long description to.

@test(@id,[=|<>],[@id|@const]) {block} @else {block} @end

This function compares the value of an identifier with another identifier or constant. If the test returns true, then the block following the @test will be executed, till the @end or @else keyword. If the @else command is used, then the block following that keyword will be executed if the test returns false. The @else keyword does not have to be specified. The @else was not included in the list of keywords because it only has one function and that is in conjunction with the @test function.

@assign(@var,[@id|@const])

This function assigns the value of an identifier or constant to a variable name. Up to 20 distinct variable names may be defined.

@add(@var,[@id|@const])

This function adds the value of an identifier or constant to the value of the variable. If one of the two values is a string, then both values will be treated as strings and the new value of the variable will be the two strings concatenated together. If both values are numbers, then the value of the variable will be the two numbers added together.

@sub(@var,[@id|@const])

This function subtracts the value of an identifier or constant from the value of a variable. This function only works when both values are numbers.

@include([d:]\path\filename.ext)

This function will import a standard text file into the output. APL does not scan the text for any macro commands.

Example:

@test(@daynr,=,24) @test(@monthnr,=,12) @include(c:\christmas.txt) @end @end

@includeapl([d:]\path\template.apl)

This function will import a template file into the current template. APL will process all of the macros that this file contains.

Example:

@test(@daynr,=,24) @test(@monthnr,=,12) @includeapl(c:\christmas.apl) @end @end

@filterdesc

This function will filter any ASCII characters outside the range [32..127] from the file description. This function must be included inside the file block.

@filtercr

This function will filter any carriage returns from the file description. This function must be included within the file block.

@filteransi

This function will filter any ANSI sequence codes from the file description. This function must be included within the file block.

@pos(@id,[@id|"string"])

This function returns the position of the value of the second identifier in the value of the first identifier. The result of this function is the logical position minus 1 (ie. first position is 0 etc) or the value NIL if the second value does not occur in the first value. This function is not case sensitive.

@len(@id)

This function returns the length of the value of an identifier.

@uppercase(@id) @lowercase(@id) @capitalize(@id)

These three functions turn the value of @id into upper case characters, lower case characters, or all lower case characters with the first character in uppercase, respectively.

@nomsgoutput

This function will abort message output. If it is used, anywhere within the template file, no message will be generated. This function is not available for type 4 templates.

@openoutput([@id|@const],[rewrite|append])

This function will attempt to open a file for output designated by the value of an identifier or constant. The rewrite directive will create a new file. The append directive will attempt to append the output to the file if it exists, otherwise a new file will be created.

@closeoutput

This function will close the file opened by the @openoutput function.

7. ALLFIX

ALLFIX is the actual fileecho utility. If ALLFIX is run without any commandline options, then the following help screen is displayed:

——– – – —- – — – – – – —————————————- Usage: ALLFIX <commands> [switches]

Commands:

Announce Generate new file reports Scan Scan message base for file information requests

File             Process inbound TIC files and create new file

announcements Mgr Process AreaMgr requests Notify Send notify lists to all your up and downlinks Bill Send out all pending bills FakeReq Process a fake AreaMgr request Credit Increase or decrease a node’s credit ReRequest Re-send uplink request messages ReLink Re-link all fileechos from uplinks Rp External request processor

Switches

-Crash,-Hold Set crash or hold bit on all netmail -NoCrc Do not perform a CRC check on all incoming files -NoSize Do not perform a Size check on all incoming files -NoNew Do not scan the BBS file areas for new files -NoDupe Skip dupe checking when importing/hatching files -NoKill Do not delete any old .TIC and queue files -TossBad Process files in bad tic directory -File Used to specify an alternative template for the Notify command -Groups Used to specify the groups to include in a Notify message

-NoSpaceChk Do not check for sufficient disk space -NoMagic Do not process any Magic filename entries -SRIF Used with the Rp command to signal that the next option passed on the commandline is an SRIF file.

—— — – ——- — – —————————————–

The commands and switches can be in any order. The first letter of the command may also be used instead of the command.

Example: ALLFIX F A

instead of: ALLFIX File Announce

7.1 Announce

The new file reports database is stored in the files TOBEREP.FIX and TOBEREP.IDX. If there are any files in the database that have not yet been reported, then this command will tell ALLFIX to generate the necessary new file reports.

ALLFIX can store up to 8000 files in the new file reports database. ALLFIX will announce all of the files in the database each time that the Announce command is given. The database files will be truncated to 0 bytes when ALLFIX has announced all of the files.

7.2 Scan

This command tells ALLFIX to scan the message base for FileFind requests. ALLFIX will scan the BBS file areas for any file specifications and/or keywords requested. If any matching files are found, then appropriate replies will be generated.

7.3 File

This command tells ALLFIX to process incoming .TIC files, process magic filenames, process AreaMgr requests and scan the BBS file areas for new files.

The following switches can be used with this command:

-Crash,-Hold Force the crash or hold bit on all generated outbound mail.

-NoCrc Force ALLFIX to skip the CRC check for each incoming file.

-NoSize Force ALLFIX to skip the File size check for each incoming file. ALLFIX checks the file size by comparing it with the size listed in the .TIC file (if one is listed). T-Mail marks files that have

not been transferred completely by making them Hidden. If you use T-Mail, then ALLFIX will also check the status of the Hidden flag. This switch will disable that check as well.

-NoNew Force ALLFIX to skip the search for new files in the BBS file areas.

-NoDupe Force ALLFIX to skip the duplicate file checking for those fileechos where that option has been enabled. ALLFIX will write a warning to the log file when processing duplicate files.

-NoKill Force ALLFIX to not delete any old .TIC and queue files. Normally ALLFIX will delete all the .TIC and queue files that have been sent. This switch can be used to disable that feature.

-TossBad Force ALLFIX to process files in the bad tics and duplicate files directories. When processing .TIC files in those two directories, ALLFIX will also look in the inbound directories and in the received file directory for the associated files. This is necessary when the .TIC files are received before the actual files. The actual files can then still be located in the inbound directories or they may have been moved to the received files directory.

ALLFIX uses intelligent searching techniques to make sure that the correct files are processed. It often happens that a file transfer session is aborted, due to a bad connection. When the session is restarted, the mailer sometimes does not realize that the file being received was aborted. Therefore, it will automatically rename the incoming file. Usually the last letter of the extension of the file is changed to a number, ranging from 1 to 9. In order to make sure that ALLFIX proesses the correct file, it will look for these renamed archives. The last one it finds should be the correct one, and it will then process that file. The following example will help clarify this:

Let’s assume that a file is being sent with the name FILE.ZIP. During the transmission, something goes wrong and the session is aborted. Your system re-asserts the connection and your mailer starts receiving the same file again. Your mailer will rename the file to FILE.ZI1. When you run ALLFIX, it will look for FILE.ZIP, since that is the filename in the .TIC file. However, ALLFIX is now smart enough to also find FILE.ZI1.

When ALLFIX has found an alternative file (i.e. FILE.ZI1 in the above example) then it will swap the file names. In terms of our example above, FILE.ZIP will become FILE.ZI1 and FILE.ZI1 will become FILE.ZIP.

7.4 Mgr

This command tells ALLFIX to process AreaMgr requests.

The AreaMgr allows systems to connect and disconnect themselves from fileechos to which they have access.

ALLFIX will also process AreaMgr requests when the File command is used.

ALLFIX processes messages to ‘ALLFIX’ or any of the file ‘AreaMgr recognition strings’ defined in the AreaMgr options menu. Messages should originate from an address in the Node manager. The AreaMgr password should be placed on the Subject line, and should match the AreaMgr password in the Node manager. The body of message should contain at least one of the following commands.

+<areaname> To connect to an area -<areaname> To disconnect from an area %H[ELP] To request the help screen %L[IST] To request a list of areas available to you %Q[UERY] To request a list of areas for which you are connected %U[NLINKED] To request a list of areas available to you, to which you are not already connected. %P[ASSWORD] To change your AreaMgr password %-[ALL] To disconnect from all areas %+[ALL] To connect to all areas %+[GROUP] To connect to a group of fileechos %-[GROUP] To disconnect a group of fileechos %C[OMPRESSION]= Choose the compression type (ARC,ARJ,LZH,PAK,ZIP, and SQZ) %NOTIFY=[On/Off]

To turn the notify function on/off for your system

%MESSAGE=[On/Off]

To turn the message function on/off for your system

%TICK=[On/Off] To turn the TICK file option on/off for your system %STATUS To request a status report (notify, message etc) %RESEND [fileecho]:[filename]

To  request that ALLFIX  resend a certain  file in a

specific fileecho. Wildcards may be used. %PAUSE To temporarily turn off all areas that are not mandatory. %RESUME To turn any inactive areas back on %FROM [address] Remote maintenance. [—] Everything below the tear line is ignored

Systems can only add areas in groups for which they have authorization as defined in the Node manager. The following commands may be used on the same line, but AFTER the password: -Q, -L, -H, or -U, which stand for %QUERY, %LIST, %HELP, %UNLINKED, respectively.

Example:

By: Harald Harms To: ALLFIX, 1:218/720 Re: <password> St: Pvt Local Kill —– — – – — – – — – ——————————– +SYSOPS -GENERAL %QUERY %LIST %PASSWORD MYPWORD

7.5 Notify

The Notify command is used to send notification messages to one or more systems. The accepted format is:

ALLFIX Notify <address> <-File [template]> <-Groups [groups]>

If no address is given, then ALLFIX will send the notify message to all the systems in the Node manager that have the Notify option enabled. If an address is specified, then ALLFIX will send a notify message to that system, assuming it is defined in the Node manager, regardless of the Notify setting for that system. The address may also contain the wildcard ‘*’. The address specification 2:* means everything in zone 2. 2:*/2 means every node 2 in zone 2. It is possible to send a notify message to someone who is not listed in the Node manager, but may be connected to one or more fileechos.

The -File option is optional. It tells ALLFIX which template file should be used in the notification message. The NOTIFY template file is used when no other is specified. The extension of the template file should not be included.

The -Groups option can be used to specify the groups that should be included in the notify message. Multiple groups can be specified using commas to seperate the groups and two periods, "..", to indicate a range.

Example:

ALLFIX Notify 1:218/720 -File MYNOTIFY -Groups 2,5,36..58

The address specification, the -File, and the -Groups options are only available in the registered version of ALLFIX.

7.6 Bill

The Bill command can be used to force ALLFIX to send out all pending bills. The command works in the same way as the Notify command explained in section 7.5.

7.7 FakeReq

The FakeReq command can be used to simulate an AreaMgr request from the command line. This command can be used to add people to fileechos, request that certain files are resent, or for performing any other AreaMgr function. This command requires an address and at least one AreaMgr command:

ALLFIX FakeReq <address> <AreaMgr cmd, AreaMgr cmd, …>

Example: ALLFIX FakeReq 1:218/720 +ALLFIX %LIST

The above example has the same affect as if node 2:281/415 would send an AreaMgr request in which he requested to be added to the fileecho "ALLFIX" and also requested a list of the connected fileechos.

* note: People who use 4DOS or 4OS2 need to use two % characters whenever one would normally be used. This is necessary because 4DOS and 4OS2 use the % character for a special purpose. Using two signals to 4DOS or 4OS2 that it should not interpret the second % as a special character and leave it in the command line. When using 4DOS and 4OS2, the above example should read:

ALLFIX FakeReq 1:218/720 +ALLFIX %%LIST

7.8 Credit

The Credit command can be used to increase or decrease a node’s credit from the command line. This command requires an address specification and the number of units (dollars, guilders, marks, etc) to add or subtract, from the node’s current credit.

ALLFIX Credit <address_spec> <value>

Example: ALLFIX Credit 1:218/720 +25

ALLFIX Credit 2:* -10

7.9 ReRequest

This command tells ALLFIX to re-request all of the requested areas from the uplink. Unknown areas that are requested from the uplink are put into a special database. After 30 days, they are automatically removed. This command can be used to re-request those areas if they have not been received yet. Please note, the date will be reset, so that the areas will remain in the database for another 30 days after invoking this command.

7.10 ReLink

This command tells ALLFIX to re-link all of the fileechos with the uplinks. When invoked, ALLFIX will write uplink request messages for all of the fileechos to which any of the uplinks in the Uplink menu are connected. This option is usefull when the configuration is lost due to a system crash, for example.

7.11 Rp

For an explanation of the Request Processor, please refer to section 6.9.

7.12 Log file

ALLFIX will log its activity if a log file has been specified. The log file contains information about what ALLFIX did in a particular session. The style of the log file can be changed in the global options menu.

7.13 Errorlevels

ALLFIX will exit with one of the following errorlevels depending on the type of activity that was performed.

254 An unrecoverable error occurred.

processed.

7.14 ALLFIX semaphore file

ALLFIX, ASETUP, and HATCH use the ALLFIX.BSY semaphore file to make sure that only one of the previous tasks is active at any one time.

A semaphore file is nothing more than a method to send a message to another process. One of the three above mentioned processes will open the semaphore file when it starts. If the file is already open, then the process will abort because that means that there is already another process using the configuration files.

The reason this protection routine has been built is to prevent file sharing conflicts which frequently affect the integrity of the configuration files.

8. Cookies

ALLFIX supports the concept of cookies, introduced by a program called FileFix. The name cookie comes from the idea of fortune cookies. Today a cookie can be any small text usually not consisting of more than a few lines. Cookies, as they are called in this documentation, can be included in messages with the appropriate template keyword. The cookies are selected at random from the collection of cookies stored in the COOKIE.DAT file.

8.1 BAKE

Bake is a utility that converts a standard ASCII text file into a cookie data file that can be used by ALLFIX.

Usage: BAKE [d:]path\input.ext [d:]path\output.ext

The input file must be a pure ASCII text file. Each cookie must be separated with one or more blank lines. Please note: cookies that have blank line within them will be interpreted as multiple cookies.

The output file is a cookie data file.

Included in the distribution archive is a example of a cookie file. The name of the file is COOKIE.TXT. This text file needs to be baked into a COOKIE.DAT file, stored in the system directory, before ALLFIX can use the cookie database.

8.2 SCRAMBLE

Scramble is a utility to randomly select a different cookie data file. It randomly selects on of the COOKIExx.DAT files in the current directory where "xx" is a number, from 00 to 99, and copies that file over the COOKIE.DAT file.

8.3 COOKIE

Cookie is a utility that will randomly select a cookie from the COOKIE.DAT file and display it to the standard output.

9. FIXUTIL

FIXUTIL is a general maintenance utility to be used with ALLFIX.

Usage:

FIXUTIL <commands> [parameters]

Commands:

Allfiles Create an ALLFILES listings.

Pack

Pack history or statistics file.

Describe

Import fileecho descriptions from FILEBONE.RA.

Stat

Display fileecho statistics.

UpdateCrc

Update the CRCs in the .TIC files.

BuildDataBase

Build files database for new file report scanning.

Purge

Purge fileechos.

SortFILES.BBS (not ALLFIX!)

Sort FILES.BBS files for all BBS file areas.

CompileRequestIdx

Compile a list of all of the files available for file requesting into one data file called REQUEST.IDX.

ProcessTemplate

Process a template file and write output to a text file.

9.1 Allfiles

The Allfiles command has one paramter, namely, the name, also referred to as the "tag", of the allfiles definition in ASETUP.

Example:

FIXUTIL Allfiles ALLFILES

Where the tag "ALLFILES" is the name of an Allfiles entry in ASETUP. It is also possible to generate all allfiles defined in ASETUP, at once. In order to do that, simply do not include a tag on the command line. For example, simply calling up "FIXUTIL Allfiles" will generate all of the allfiles listings.

9.2 Pack

The Pack command has one parameter.

-StatFile

Packing the statistics file trims the file to the maximum size, as specified in the Global options menu. The statistics information is stored in the file called STATFILE.FIX and STATFILE.IDX.

9.3 Describe

The Describe command can be used to update the fileecho descriptions with the standard descriptions as specified in the FILEBONE.NA file. FIXUTIL can also import the fileecho descriptions from the echolist file that can be created with ASETUP.

The format of the FILEBONE.NA file is as follows:

Area [fileecho]   [priv level]   [locks]   [description]

Example of FILEBONE.NA file:

Area BACKBONE  0      !     National:  Area  Lists  of FidoNet

BackBone

Area SERVICES  0    !   FDN:  File Distribution Networks Joint

Letter

The privilege levels and locks are not used by ALLFIX, and will be ignored by FIXUTIL.

The format of the echolist file is as follows:

[fileecho] [description]

Example of an echolist file:

BACKBONE National: Area Lists of FidoNet BackBone SERVICES FDN: File Distribution Networks Joint Letter

FIXUTIL, by default, expects a FILEBONE.NA file. The -EchoList switch must be used on the commandline when an echolist file is being used. FIXUTIL supports two other commandline switches: – RemoveGroup; The fileecho descriptions in a FILEBONE.NA file

contain the name of the group to which that fileecho belongs. This switch tells FIXUTIL to remove the groupname from the description; -NotOverWrite; This switch tells FIXUTIL to only update fileechos that do not have a description. Normally, FIXUTIL will update all the descriptions, replacing those that are already defined.

9.4 Stat

The Stat command tells FIXUTIL to generate some fileecho statistics. The statistics information is read from the STATFILE.FIX and STATFILE.IDX files.

FIXUTIL can create .ANS and .ASC files if a filename is supplied on the commandline. The filename may contain paths, but can not contain any extensions as those will added automatically.

Example: FIXUTIL Stat C:\RA\TEXT\AFIXSTAT

The above example will create two files, AFIXSTAT.ANS and AFIXSTAT.ASC in the directory C:\RA\TEXT.

9.5 UpdateCrc

The UpdateCrc command will recalculate the CRCs for the files still waiting to be sent out. This option only works for .TIC files that have not been compressed into TIC archives.

9.6 BuildDataBase

The BuildDataBase command tells FIXUTIL to generate the FILES.FIX database files in each of the BBS file areas configured in the BBS new file dirs menu and in any of the directories in which the HatchNew magic filename function is being used.

The FILES.FIX files are bayer tree files that contain information about each file in the directory. When a new file is uploaded or placed in the directory by the SysOp, ALLFIX will be able to tell that it is new by checking to see if it is in the database.

Bayer trees are extremely fast database structures and this method is only a little bit slower than scanning the file dates, as previous versions of ALLFIX did, but it is a lot more reliable.

Sometimes it is not desirable to rebuild all of the FILES.FIX files. For large systems, this process could take quite some time. In those situations, the -CreateMissing switch can be used to only build those FILES.FIX files that are missing.

9.7 Purge

The Purge command can be used to maintain the fileecho destination directories. In the fileecho manager, there are three options that can be used to determine the maximum number of files, the maximum number of kilobytes, and the maximum age of files in a destination directory. Running FIXUTIL Purge will remove all the necessary files from the destination directories so that the above requirements are met. For example, if the maximum number of files in a destination directory is set to 500, and there are currently 510, running the Purge command will delete the 10 oldest files.

9.8 SortFILES.BBS

The SortFILES.BBS command tells FIXUTIL to sort the FILES.BBS files in each of the BBS filearea directories. FIXUTIL takes extended descriptions and comments into consideration when sorting the files. Each list of files separated by empty lines or comments is treated as a block and sorted independent of the rest of the file. This sort routine also takes extended descriptions into consideration when sorting the files.

This command supports one switch, namely the -UpdateCounters switch which tells FIXUTIL to format the download counters in the FILES.BBS files according to the download counter configured in ASETUP. Download counters which are smaller (ie. contain less digits) than the one in defined in ASETUP will be expanded, and those that are larger (ie. contain more digits) will be shortened. All download counters will begin on column 14 and the description will begin one space after the download counter. New download counters are added to any files that do not yet have one.

FIXUTIL will ONLY update the download counters if one has been defined in ASETUP. This means that the download counters will NOT be removed if one has not been defined in ASETUP. This is a safety feature to prevent unnecessary problems.

9.9 CompileRequestIdx

The CompileRequestIdx command tells FIXUTIL to compile all of the files that are available for file requests into one datafile with the REQUEST.IDX. This file is used by the rqeuest processor to find the files faster. If a REQUEST.IDX file is present, the request processor will use the file instead of actually scanning all of the file areas or the list directories. Because this file is not automatically updated when new files are received, it is very important that the REQUEST.IDX be updated on a periodic basis, for example, once a day, in order to remain up to date.

If the request processor has problems finding files that are on the BBS and in the correct areas, the first thing to do is to delete the REQUEST.IDX file. Without that file, ALLFIX will scan each directory at the moment it is processing a file request. If it finds the files, then that means that the REQUEST.IDX file was not up to date. Running FIXUTIL with this command should update

the file and the request processor should work fine from that point on.

9.10 ProcessTemplate

The ProcessTemplate command can be used to process a template and store the output in a text file. The command uses two parameters, namely the name of the template and the name of the text file to create.

All AreaMgr and Notify type of templates can be used. The templates can, obviously, not contain any of Node (those in the Node manager) specific macros. The templates can also not (yet) contain macros that pertain to individual files in the fileechos.

Example:

FIXUTIL FILEBONE FILEBONE.NA

Where FILEBONE is the name of a template, and FILEBONE.NA is the name of the text file to create.

10. HATCH

HATCH is an external hatching utility. HATCH does not actually "hatch" files, rather, it creates a fake .TIC file, in your inbound directory that tells ALLFIX which files it should hatch.

HATCH has two modes: commandline mode and interactive mode.

10.1 Command line mode

The command line mode offers the ability hatch files from the dos prompt or in batch files.

Usage: HATCH Area [areaname] File [filename.ext] Desc [description] Replace [filename.ext] Magic [magic name] [Copy]

Commands:

Area

[areaname] must be a valid fileecho tag. This command must always be used.

Desc

[description] is the description of the file to be hatched. Enclose the description in quotes if it is contains more than one word. If this command is not used, then HATCH will attempt to take the description from the file database. The

Fdb command must be used if the BBS system does not make use of the standard FILES.BBS files.

File

[filename.ext] must be a filename or file specification. Paths may be included. This command must always be used. If a file specification is used, then HATCH will attempt to take the description from the file database. The Fdb command must be used if the BBS system does not make use of the standard FILES.BBS files.

Replace

[filename.ext] is the file specification that this new file should replace.

Magic

[magic name] is the magic name ALLFIX should update in the alias file.

Release

[dd-mm-yy] is the date on which a file should be released. All systems, that have the prerelease switch turned on in this fileecho will receive the file immediately. Systems that do not have that switch turned on, will receive the file on the date entered in this field.

[Copy]

this optional command tells ALLFIX to copy the file to the destination directory instead of moving it.

Example:

HATCH Area ALLFIX File AFIX_430.ZIP Desc "This is the latest release of ALLFIX"

HATCH Area PDNPASCAL File \PASCAL\TP*.* Release 01-02-1996

10.2 Interactive mode

The interactive mode presents the user with a menu from which files can be hatched.

The following keys are available in interactive mode:

ESC,F10

Exit and hatch the file.

F9

Abort the hatching the file.

The following is a description of the fields.

Area

The fileecho that this file needs to be hatched into.

File

The file that needs to be hatched.

Copy

This optional command tells ALLFIX to copy the file to the destination directory instead of moving it.

Desc

The description of this file. HATCH will automatically try to read the file description from the file database, when a file name is entered in the File field. The imported description can be edited or replaced.

Magic

The magic name for this file, which will be added to the alias file.

Replace

The filespec that this file should replace.

Release

The date the file should be released. All systems, that have the prerelease switch turned on in this fileecho will receive the file immediately. Systems that do not have that switch turned on, will receive the file on the date entered in this field.

There is an added ability to fill some of the fields with values from the command line. This option is very handy for people who use FEBBS or similar programs. FEBBS can call up HATCH and pass along the filename and description. Those two fields will be filled in and all the user needs to fill in is the Area field and possibly a few other fields. In order to use this feature, simply add the commandline options, explained in the previous section to the commandline. If the "Area" command is used the file will automatically be hatched if the "File" command is also used. Therefore, use all of the commands except the "Area" command, or use all of the commands except the ‘File’.

Example: HATCH File TEST.ZIP Desc "Testing the external Hatch program"

In this example, HATCH will jump to interactive mode, with the file and description fields already filled in.

11. CRC32

CRC32 is small utility that is designed to calculate the 32 bit CRC for a file. A Cyclic Redundancy Check, or CRC, is a easy and very fast method to check whether a file has been damaged or changed. A CRC is a unique signature, belonging to only one file. Many programs check the CRC with the calculated CRC to make sure that the file has not been damaged or tampered with.

CRC32 is very easy to use. Simply type CRC32 followed by the name of the file. The CRC value returned, as it is stored in the .TIC files, in hexadecimal format.

12. Hints

12.1 Sample template files

The TEMPLATE.ZIP file contains several sample template files. The purpose of most of the files has already been explained in section 6.14. The following list explains the purpose of the other template files:

BANNER

This is a Banner template used to create a banner for archives.

MESSAGE

This is a netmail announcement template used to write messages to accompany forwarded files.

REPORTS

This is a New file report template used to generate new file reports.

12.2 EAC utilities

The SAMPLE.ZIP file contains a sample configuration file (PALMSCAN.CFG) for PalmScan.

12.3 Hatching files without moving them

When files are hatched, they are normally moved from an origin directory to a destination directory. ALLFIX will hatch a file each time the file specification entered in the Hatch manager exists in the configured origin directory.

Sometimes it is necessary to hatch files that are already in the destination directory.

When this occurs, ALLFIX will turn off the archive bit in order to signal that the file has been hatched. Otherwise, ALLFIX will hatch the files over and over again.

It is extremely important that no other program turns the archive bit back on, unless the file has to be hatched again.

It is known that this system is not entirely fool proof. There are many other programs, namely backup software, that make use of the archive bit. However, at the moment it is the most efficient way to handle this problem. Even though it has a number of disadvantages, it does offer the ability to easily re-hatch a file, by simply turning the archive bit back on.

The magic filename manager offers another way to hatch files with the Hatchnew option. The Hatchnew option is more dependable and, therefore, recommended above this particular method.

12.4 Errorlevels

ALLFIX reports the errorlevels of child processes with the statement errorlevel [xx] from <program> The meaning of the errorlevel depends on the process and is totally independent of ALLFIX.

The following is a list of error levels for PKZIP/UNZIP and ARJ. For a list of the errorlevels for other programs, please consult the accompanying documentation.

Errorlevels for PKZIP and PKUNZIP:

PKZIP: 0 No error. 1 Bad file name or file specification. 2,3 Error in ZIP file. 4-11 Insufficient Memory. 12 No files were found to add to the ZIP file, or no files were specified for deletion. 13 File not found. The specified ZIP file or list file was not found. 14 Disk full. 15 ZIP file is read-only and can not be modified. 16 Bad or illegal parameters specified. 17 Too many files. 18 Could not open file 19-23,

29 Insufficient Memory 26 DOS 3.2 or later needed to span disks 28 Destination for .ZIP is same as temporary file or Source and destination is the same 255 User pressed control-c or control-break

PKUNZIP: 0 No error. 1 Warning error (such as failed CRC check). 2,3 Error in ZIP file. 4-8 Insufficient Memory. 9 File not found. No ZIP files found. 10 Bad or illegal parameters specified. 11 No files found to extract/view etc. 50 Disk Full. 51 Unexpected EOF in ZIP file.

Errorlevels for ARJ:

0 No error. 1 warning (specified file to add to archive not found, specified file to list, extract, etc., not found, or answering negatively to "OK to proceed to next volume…" prompt) 2 fatal error 3 CRC error (header or file CRC error) 4 ARJ-SECURITY error or attempt to update an ARJ- SECURED archive 5 disk full or write error 6 can’t open archive or file 7 simple user error (bad parameters) 8 not enough memory

12.4.1 Common errorlevels

The most common errorlevels are ones dealing with not enough memory. For PKZIP that means levels 4-11, for PKUNZIP levels 4-8, and for ARJ level 8. ALLFIX is capable of swapping the program memory to XMS, EMS, or Disk, and it is recommended that option is used when memory problems occur.

Another common errorlevel occurs when ALLFIX attempts to extract a FILE_ID.DIZ file from an archive. ALLFIX is not capable of looking inside an archive to determine if it contains a FILE_ID.DIZ file. Therefore, it simply attempts to unpack it from the archive. The decompression program will exit with an error if the FILE_ID.DIZ file is not contained in the archive. This error is very normal and should not cause any alarm.

First consult the appropriate documentation about errorlevel before approaching the author.

12.5 Common errors while importing files

Following is a list of common errors that occur when importing files:

Invalid destination drive: ‘<drive>’

This error occurs when the drive on which the destination directory, for this fileecho, is located does not exist. The files for this fileecho will be moved to the bad tics directory. After the problem has been corrected, they can be reprocessed using the -Tossbad switch.

Invalid destination directory: ‘<directory>’

This error occurs when the destination directory of a fileecho does not exist. The files for this fileecho will be moved to the bad tics directory. After the problem has been corrected, they can be reprocessed using the -Tossbad switch.

Insufficient disk space on the destination drive: ‘<drive>’

This error means that the file being imported does not fit on the destination drive or that the space left on the destination drive after importing this file would be less than the minimum space required, as configured in the Global Options menu.

Duplicate file: ‘<filename>’

This error means that the file being processed has already been processed. The criteria used to determine if a file is a duplicate can be configured in the Global Options menu. Less stringent criteria should be used if there are too many problems with duplicate files or based on the needs of the system.

CRC check failed: ‘<filename>’

This error means that the file being processed has failed the integrity check. There are several possible explanations for this problem. The most likely explanation is that the file was damaged during transmission. Another likely possibility is that the CRC stored in the .TIC file was calculated wrong. Do not use the -Crc switch in order to process files with a CRC error.

Invalid password ‘<password>’ from <node>

This error means that this node is using the wrong password when sending files to this system. Change the configuration for this node in the Node manager or contact this node and correct the problem.

Node is not allowed to send files in this fileecho: <node>

This error means that this node is not allowed to send files to this system. The configuration for this node in the systems list, for this fileecho, specifies that no files are to be received from this node. Update the configuration or contact this node to determine why it is sending files to this system.

File missing: '<filename>'

This error means that the file referred to in the .TIC file does not exist.

Undefined area: ‘<fileecho tag>’

This error means that the fileecho referred to in the .TIC file does not exist. ALLFIX, when configured, can automatically add new fileechos, in which case this error will not occur.

Undefined node: <node>

This error means that this node is not listed in the Node manager. ALLFIX requires that each node, that files are received from, must be configured in the Node manager.

No Queue directory defined for pass through areas

This error means that the queue directory, used to store files for pass through areas, is not defined. The consequence is that ALLFIX is not able to process the pass through files. They will be moved to the bad tics directory.

Can not auto-add new fileecho: No matching Mask found in group manager

This error is reported when ALLFIX can not find a group in the group manager with a mask that matches the name of this fileecho. ALLFIX uses the masks in the group manager to determine which group defaults should be used for the new fileechos. Please see section [xx] for more details.

Unable to update file database!

This particular error is reported when ALLFIX is not able to open the BBS specific file database files. This problem is often encountered when changes have been made to the BBS file area configuration without running FCOMP afterwards to signal the changes to ALLFIX. If running FCOMP does not solve the problem, then make sure that the destination directory of the fileecho is defined exactly the same way as the associated file area directory in the BBS configuration. ALLFIX uses the directory names to find out which filearea it should use.

Skipping <filename.TIC> not for us (node)

This error means that the .TIC file contains a To verb, which is used to specify the destination system for that particular file. If the destination address following the To verb is not one of the AKAs of this system, then ALLFIX will give this particular error. It is possible that the To verb is left in the .TIC file by another type of fileecho processor. In this case, simply remove that line in the .TIC file with a standard ASCII text editor and execute the File command again.

Skipping <filname.TIC> file (<filename.ext>) is not complete

This error means that the file transfer is not complete. A possible cause is that the mail session was prematurely aborted. Another cause is that the file size listed in the .TIC file is not correct. It is possible to force ALLFIX to process this file, by using the -NoSize switch, which turns of the file size check.

Unable to initialize B-Tree Filer, error 10310

This error sometimes occurs when running ALLFIX! for WildCat! under Windows 95/98. There is no real solution for this problem, however, a work-around has been developed. Add the following environment variable (in AUTOEXEC.BAT, for example):

SET NONET=TRUE

If ALLFIX detects this environment variable, it will initialize the B-Tree Filer as if the "Network" option in MAKEWILD was set to "No network".

12.6 Using ALLFIX without a compatible (or no) BBS

This section does not pertain to those people using ALLFIX! for WildCat! since it is not possible to use that type of ALLFIX without a BBS system.

Most of the features in ALLFIX can be used without having a BBS. However, of the features, such as the FileFind feature and the Allfiles listings (FIXUTIL) can only be used when you have a BBS.

In order to make it possible for those people not using a BBS to also make use of these types of features, FCOMP has the ability to scan the fileechos instead of the fileareas. Everywhere, where people running a BBS would see their BBS file areas, you will see your fileechos. Simply run FCOMP with the parameter 255.

ALLFIX will, by default, create FILES.BBS files in each of the fileecho destination directories. If this is not required, simply toggle the No Touch switch in each of the fileechos and those files will not be created.

12.7 Creating a FILEBONE.?? file

FIXUTIL can be used to generate a FILEBONE.NA style file. A sample template has been included with ALLFIX. This template, however, is not the only thing one will need to generate a real FILEBONE.NA file.

The template, FILEBONE.APL, will generate a list of fileechos conform the standard of the FILEBONE.NA file.

A real FILEBONE.NA file has a textual description of each group of fileechos in the list. In order to include descriptions of each group in the generated FILEBONE.NA file, comment out the following lines in the FILEBONE.APL file:

@assign(@tmp,’C:\ALLFIX\TEMPLATES\GROUP.’) @add(@tmp,@group) @include(@tmp)

This section in the template is used to include text files into the template output. The name of the include files are GROUP.XXX where XXX is the number of the group. If you make such a file for each group, in the Group manager, then you can generate a real FILEBONE.NA file using this template.

If you require headers and footers in the output, simply add @include() macros to the beginning and end of the template.

12.8 Frequently asked questions

This section contains a number of frequenly asked questions. Some of these questions and answers have been put together by dedicated beta team members.

Question ALLFIX/2 aborts with a runtime error when I use the File command.

Answer ALLFIX/2 may abort with a runtime error if the FILEDUPE.FIX file or the ALLFIX.DAT files are corrupt. Therefore, move the FILEDUPE.FIX file to another directory, to see if that solves the problem. If that does not solve the problem, then move the ALLFIX.DAT file. If this does not solve the problem either, then please contact the author.

Question My BBS software is not supported by ALLFIX, what I do about it?

Answer

Section 12.3 in the documentation explains how to use ALLFIX with a non-supported BBS. However, due to the rapid development in ALLFIX, there is a good chance that ALLFIX will support your BBS within the near future.

Question Some of my downlinks are complaining about the file transfer rate when they receive lots of new files. It is way below the normal performance. Is there anything that I can do about this?

Answer Yes there is. The reduction in transfer rate is caused by the numerous .TIC files. These files are generally to small to accomplish a good transfer rate when sending them via a modem. In the node manager, there is an option called "Packing mode". By setting this option to "Pack .TIC files" or to "Pack ALL files", the transfer rate will increase since only larger files are being sent.

Question I have a downlink who is interested in receiving files from one or more of the file distribution networks available on my system, but he does not want to receive the acompanying .TIC files. Is this possible?

Answer Sure, just set up your downlink as you would setup any normal downlink in the Node manager. If you set the "Tic file mode" option for this downlink to "None", then ALLFIX will not send this node any .TIC files.

Question Some of my downlinks take part of a cost sharing system. I have dfined the fileechos as Cost sharing echos (by setting the Div costs option to C/S nodes), still I can’t seem to force ALLFIX to send them any bills. How come?

Answer You probably failed to define your downlinks as participating in the cost sharing system. Go to the Node manager in ASETUP and for every node that should participate in the cost sharing, set the Billing option to Yes.

Question ALLFIX does not seem to be passing the costs of files on to my downlinks. Why is this happening?

Answer The Cost verb, used in the .TIC files to define the cost of the file, is only used in Advanced .TIC files. You should setup all your cost sharing nodes to use Advanced

.TIC files. The option to toggle is called "Tic file mode".

Question What is the difference between "Add %" in the fileecho manager and "Add %" in the node manager?

Answer The "Add %" found in the fileecho manager is the percentage value that you can add to the cost of all incoming files. This value can be used to compensate for currency exchange rates. The "Add %" in the node manager is the percentage value that you can add to the total bill for a node. This value can be used to add the local VAT to the bill, for example.

Question I have a downlink that is interested in some particular files in a fileecho, but not in the rest of the files. Is there a way to only send those files to that system. For example, only send the NODEDIFF.* files and not the NODELIST.* files?

Answer Yes, this is possible. You need to make a new Magic filename entry in the Magic filename manager. Select as type "ForwardTo". In the From Area field select the fileecho in question. In the Spec field, select the file specification, such as NODEDIFF.*. In the systems list you can enter the node numbers of all the people that should receive this file.

Question How can I quickly create an "UNWANTED" file?

Answer If you use TranScan, you can simply use your TS5.DEL file.

Question What good is the "Update DESCRIPT.ION" file option, if I do not use 4DOS?

Answer The DESCRIPT.ION file is a FILES.BBS file that contains the filename and the associated description. Such a file can be very usefull to find out what each file is in a directory. So even if you do not use 4DOS, you may find this feature usefull.

Question ALLFIX is not reporting newly uploaded files on my BBS. What am I doing wrong?

Answer

There are two things that can be wrong. First, you may need to run FIXUTIL -BuildDataBase, to rebuild the FILES.FIX in each of the BBS new file dirs directories. All new files uploaded, after FIXUTIL has been run, will be reported. The second source of the problem may be that you need to run FCOMP again. If you have made any changes to your BBS file areas, then run FCOMP and double check your BBS new file dirs configuration.

Question Why is ALLFIX not writing to my file database as it is supposed to do?

Answer In order to write to your specific BBS file database, you must turn the "Use FDB" option on for each fileecho associated with a BBS file area. You must also make sure to run FCOMP periodically, especially after making any changes to your BBS file areas.

Question Why is ALLFIX is not responding to any FileFind requests I enter on my own system?

Answer In the "Global options" menu, there is an option that tells ALLFIX whether or not is should process local requests. If this option is turned on, ALLFIX will respond to local requests. If this option is turned off, which is the default value, it will not. The name of this option is "Process local requests".

Question I am running Xenia as my mailer. What type of mailer should I select in ALLFIX?

Answer If you have the statement "NODOMHOLD" active in Xenia, then use "Portal of Power" or "BinkleyTerm" without any domain names defined in ALLFIX. If you do not hae that statement active in Xenia, then use "BinkleyTerm" and in that case you are able to use domain names in ALLFIX.

Question How should I setup the file descriptions for ProBoard?

Answer LongDesc character + One line LongDesc No LongDesc width 0 Max len of LongDesc 0 Spaces to indent 1

Question How should I setup the file descriptions for Maximus?

Answer

LongDesc character One line LongDesc No LongDesc width 0 Max len of LongDesc 0 Spaces to indent 31 (if no DL counter is used) 36 (if a 2 digit DL counter is used)

Question I am trying to add an area to the "BBS new file dirs" menu, but ASETUP complains that the area is a duplicate area, even though I am certain that it is not.

Answer Running ASETUP Pack will solve the problem. This problem occurs periodically and is caused by changes in your BBS file area configuration. In order to make ALLFIX aware of those changes, you need to run ASETUP Pack.

Question How do I setup various virus scanners in ALLFIX?

Answer F-Prot : SCAN F-PROT.EXE @1\*.* /COMMAN /NOMEM /NOBOOT AVP (lite) : SCAN AVPLITE @1\*.* /M /P /B McAfee (OS2): SCAN OS2SCAN @1\*.* /ALL /SUB

Question ALLFIX only shows 4 lines of a file description in new file report or in a FileFind report.

Answer Check the announcement or FileFind template for the statement "setoflimit(x)", where x is a number. Increase the number x to the desired value.

Question Where can I find information about the structures of the ALLFIX configuration files, so that I can write my own utilities for ALLFIX?

Answer The structures are contained in the DEVELOP.ZIP archive which is included with each release of ALLFIX.

Question ALLFIX is not placing new files for new auto-added fileechos in the auto-add directory. Earlier versions did do that.

Answer As of ALLFIX 4.32, new fileechos are added to specific groups which can be defined in the group manager. ALLFIX will select a group that has the best matching "mask". A mask is nothing more than a specification such as WIN* or just the string *. A destination directory can be defined for each group. It is also possible to have

ALLFIX automatically create unique directories within that directory for each new fileecho added to that group.

Question Sometimes when I enter ASETUP, the menu is flashing. The only way I have been able to solve that problem is by rebooting.

Answer One possible solution to this problem is to exit ASETUP and then type MODE CO80 on the command line.

Question How do I set up the request processor in ALLFIX for my mailer?

Answer Below is a list of the command line parameters that you need to use for the following mailers:

FrontDoor : Rp =A =O =X =T =R InterMail : Rp %a %n %x %f MainDoor : Rp =A =O =X =T =R Xenia : Rp -SRIF McMail : Rp -SRIF

Question When converting files from the .RAR format, RAR sometimes asks for a password and waits until the user has entered one. This affectively stops my system until I notice this and enter a fake password, to get RAR to continue. Is there a work-around for this problem?

Answer The way to solve this problem is to pass a bogus parameter to RAR. In the External program menu, add the following parameter to the decompression command line options for RAR: -pp The -p switch tells RAR that the password is, in this case, the letter p. RAR will ignore this switch when a password is not necessary. When one is necessary, it will use the given password (letter p) and most likely exit with an error, since the password is wrong. But this is not a problem, since ALLFIX can continue.

Question Is ALLFIX forwarding files but they are not turning up in your netmail folder attached to netmails (or in your Binkley style outbound directory) ?

Answer The problem might be that you have the "Holding" directory option turned on for your downlinks. The

Holding directory specifies a special directory where all outbound files for a particular system are stored. If you use the Holding directory, ALLFIX will NOT send the files via the mailer. In other words, ALLFIX will not make any netmail file attaches or update any .?LO files (for Binkley style mailers).

Question RAR files sometimes contain passwords. When ALLFIX tries to convert such a RAR file, RAR will wait for the user to enter the password. How can this be prevented?

Answer The -pp parameter can be used for RAR, which will instruct RAR to try the password "p" for a file. If the file contains a password, this password will most likely not be correct, which causes RAR to report an error and it will then exist. The end result is that ALLFIX will not convert the file.

Question I use QEMM and I have the problem that ALLFIX Universal does not run. Instead of starting up it either hangs my system or crashes in the active DESQview window.

Answer The problem may be related to the Stacks verb in your CONFIG.SYS file. The following settings have proven to help with this problem: stacks=9,256

Question ALLFIX often reports "You are using an illegal key", even though I am a registered user. Why?

Answer There are two error messages that ALLFIX can generate, one is that you are using an invalid key and one that says you are using an illegal key. ALLFIX will report that you are using an invalid key if the key does not match the sysop name in ASETUP. ALLFIX will report that you are using an illegal key if your key is not in the keyfile. The problem is, therefore, that the keyfile is either out of date, corrupt, or missing. The solution is to pickup a new keyfile from your registration site.

Question How should I setup the file descriptions for BBBS.

Answer The only thing that you need to do to use ALLFIX with BBBS is run FCOMP with the correct parameters and turn the "One line LongDesc" option on. Lastly, it is important that the "Use FDB" option is turned on for each fileecho.

13. Development

Harms Software Engineering has NO plans to stop developing ALLFIX. Future versions will see more options, better performance, and who knows what else!

Registered users have the privilege of applying for a position on the official beta team. The beta team is managed by Harald Harms and Bob Seaborn. Anyone interested in applying for the team, should fill out the AFIXBETA.FRM included in the package and contact Harald Harms at 1:218/720 or Bob Seaborn at 1:140/12.

All registered users may use special Gamma versions of ALLFIX. The Gamma versions are pre-release version designed to test new features. Anyone interested in using the Gamma versions should contact their registration site.

14. Credits

Many thanks to the registered users and beta testers in all of the following countries:

Argentina, Austria, Australia, Belgium, Canada, Czech republic, Denmark, France, Finland, Germany, Great Britain, Greece, Holland, Hong Kong, Israel, Italy, Japan, Philippines, Poland, Russia, Singapore, South Africa, Spain, Sweden, Switzerland, Taiwan, and the United States of America.

Thank you for your registrations and for testing the program, helping me with new suggestions, and holding in there when things got rough. I would like to specially thank all the members of the registration team and the dedicated people on the beta team. The beta team currently consists of +/- 100 people who test new betas of ALLFIX on a weekly basis. Without these dedicated people, ALLFIX would not be what it is today!

All brand and product names are Copyrighted (C) material, Trademarks ™ or Registered (R) Trademarks of their respective holders:

Fido, FidoNet

Tom Jennings and Fido Software

FrontDoor, TosScan

Joaquim Homrighausen, Definite Solutions

RemoteAccess

Bruce Morse

Gecho

Gerard J. van der Land

PKZIP

PKWARE, Inc.

LHA

Haruyasu Yoshizaki

PAK

NoGate Consulting ARJ Robert K. Jung

ARC, ARCmail

Systems Enhancements Associates

SQZ J. I. Hammarberg

Ezycom

Peter Davies

SuperBBS

Risto Virkkala and Aki Antman

QuickBBS

Benjamin Schollnick / Matrix Technologies

QEMM, DESQview

Quarterdeck Office Systems, Inc.

Microsoft, MS-DOS,Windows

Microsoft Corporation

IBM, PC-DOS, OS/2

International Business Machines Corp.

FEBBS, Browse

Fenris Ulven Data & Patrik Sjoberg

BinkleyTerm

Bit Bucket Software

D’Bridge

Mosaic Press

Portal of Power

The Portal Team

FileMgr

Ron Huiskes

PalmScan

Steven Hendriks

MTA

Robert van Hoeven

List

Vernon D. Beurg

Renegade

Cott Lang

FidoBill

Craig Steiner

JAM(mbp)

Joaquim Homrighausen, Andrew Milner, Mats Birch, Mats Wallin.

MainDoor

Francisco Sedano Crippa

Concord BBS

Pasi Talliniemi

AdeptXBBS

Nitin Chandra

Maximus BBS

Scott Dudley

ProBoard

Philippe Leybaert

PCBoard

Clark Development

Telegard

Tim Strike

TriBBS

Freejack’s Software

TBBS

eSoft

LoraBBS

Marco Maccaferri

SynchroNet

Digital Dynamics

ShotGun

Brent Shellenberg

15. Technical Specs

  • ALLFIX is fully zone and point aware.
  • The main packets created by ALLFIX are fully FTS-0001 and FSC-0039 compatible, using the Type 2+ header and the Capability Word.
  • The product code for ALLFIX is 0xEB.
  • To detect duplicates, ALLFIX stores the 32 bit CRC of up to 1000 files in the FILEDUPE.FIX file. ALLFIX checks each inbound file against the list to determine if it is a duplicate or not.
  • ALLFIX can touch the mailer semaphore files for each of the supported mailer programs whenever any netmail is created.
  • ALLFIX supports semaphore files for FrontDoor, InterMail, D’Bridge, and Dutchie.
  • ALLFIX supports the RemoteAccess/FrontDoor Hudson Message Base filesharing specification.
  • ALLFIX for DOS was developed using Turbo Pascal, version 7.00.
  • ALLFIX/2 for OS/2 was developed using Virtual Pascal, version 1.10.
  • ALLFIX Universal was developed using Virtual Pascal, version 1.10 and LSxPower.