Version 2.51
NODELIST Generator Program
by Ben Baker
Copyright 1987-1992 -- All Rights Reserved
FidoNet, a trade mark of Tom Jennings, was the name of the first amateur electronic mail program. There are now several mail server programs that support FidoNet protocols. Many amateur networks, large and small, are using one or more of these mail servers to communicate regularly.
The glue that holds an amateur network together is its nodelist, a document that describes the nodes in the network, and the relationship between them. To be effective, this document must use a consistent format, so that programs may process its information automatically. The FidoNet Technical Standards Committee maintains, among others, a document called FTS-0005.TXT that defines the format for a FidoNet compatible nodelist. A copy of that document is included in this distribution.
Furthermore, a nodelist must be accurate and current. An out-of-date phone number, for example, is useless. It must be updated regularly, and most networks publish a new nodelist each week. This is an enormous task in any network of more than a few dozen nodes. No one person can do it. But division of labor adds complexity.
Obviously, we need a tool that can help verify consistency, maximize accuracy and currency, minimize effort, and minimize cost. MakeNL is such a tool.
MakeNL supports the multilevel nodelist generation techniques presently in use in several FidoNet compatible electronic mail networks. It helps maintain nodelist segments at any level from Hub through Network, Region and Zone to the composite distribution nodelist.
MakeNL's main purpose for being is to create a "submittal file" (see definitions - section 3 on page 14) containing your nodelist update, and to send it to your coordinator. It can do this automatically, if you set up its control file properly. It is a complex program and looks intimidating, but it is not really difficult.
MakeNL has features to help in nodelist preparation at any level, but it is also adaptable. Features you don't need you may safely ignore, and MakeNL will not complain.
Section 2 is a tutorial on setting up and operating MakeNL. It starts with the simplest case -- the lowest level of nodelist maintenance -- and expands in steps to Zone Coordinator.
Sections 3 through 8 contain detailed reference information. Section 2 necessarily refers to information contained in later sections. The early paragraphs of section 2 contain frequent forward references to assist the reader.
I recommend you read the entire document through once. Pay particular attention to those parts of section 2 that pertain to you, but at least skim the rest. Familiarize yourself with the layout and content of the various sections, but do not read for thorough understanding on your first pass.
Carefully study section 2 a second time. Refer to other sections for clarification of terms as necessary.
Select the sample control file that best represents your particular needs. Edit it to fit your particular environment, as indicated in section 2 and the comments in the control file.
Make copies of your master data files in a safe place (floppy diskette, or a directory tucked away in a far corner of your hard disk).
Familiarize yourself with MakeNL by actually running it, in both test and process mode. During this phase, I suggest you comment out any "Submit" or "Notify" statements in your control file to avoid generating spurious messages.
Introduce data errors to see how MakeNL handles them. Make sure you're comfortable with it before you put it on line.
When you're satisfied, delete all "test case" files. Copy your master files to your master directory. Make the necessary changes to enable your mail server's "external event" for MakeNL and you're up.
MakeNL simplifies your life. It looks imposing, but it's really not very difficult.
Test Mode Directory Process Mode
+------------------+
+----------| |----------+
| | UPLOADS | |
| +-----| |-----+ |
| | +------------------+ | |
| | | |
| | +------------------+ | |
| | /---| |---\ | |
| |< | MAILFILES | >| |
| | \---| |---/ | |
| | +------------------+ | |
| | | |
| | +------------------+ | |
| +---\ | |---\ | |
Received | >| UPDATE | >| |
Update +--------/ | |---/ | |
Files +------------------+ | |
- - - - - - - - - - - - - - - - - - - - - - - | | - - - - - -
Master +------------------+ | |
Files | | /---+ |
| MASTER |< |
| | \--------+
+------------------+
| |
| +-------\ OUTPUT
| >
+------------/ FILES
Figure 1. Data Flow - Test Mode vs. Process ModeMakeNL operates in two distinct modes, test mode and process mode. The mode of operation is controlled by the "PROcess" statement in your control file (see section 6.1.4 on page 23), or by the "/T" and "/P" command line switches (see sections 4.2 and 4.3 on page 17).
In test mode your personal nodelist segment, the part of the nodelist you maintain, and any update segments you have received from others are tested for errors. Submitters of any received files are notified as indicated by the NOTify statements in the control file, and their files are moved to the UPDate directory. (See section 5 on page 20 for a description of MakeNL's directories.)
In process mode your MASter directory is updated by any files received since the last time MakeNL was executed in process mode. Master data files are used to produce your submittal and/or distribution files.
In general, MakeNL should be run in process mode once and only once each week. Ideally, this will be done by an "external event" from your mail server. It is then automatic, and one less thing you have to worry about.
It may be run in test mode as often as desired to test received files or changes in your own data.
MakeNL uses several directories to store data. Section 5 describes them in detail. Figure 1 illustrates the data flow from directory to directory in the two modes of operation. Above the dashed line, the data flow all deals with files received from others -- perhaps from your Hubs if you are a Network Host, or from Network Hosts if you are a Regional Coordinator. It is clear from this picture that if you do not receive nodelist updates from others (and many of you don't), you have no use for three of MakeNL's data directories, and a good deal of MakeNL's complexity disappears.
The following paragraphs give recommended set-up and operating procedures for various types of coordinators.
Here is where the nodelist update process begins. You have a small nodelist segment that you maintain. You do not receive any update files from anyone else. If you are a Network Coordinator and your network has Hubs, YOU maintain their data -- they just forward the mail. Yours is the easiest task, so your set-up for MakeNL is the simplest for you.
Figure 2 shows two variations of a MakeNL control file tailored to your needs. You may maintain your nodelist segment as a separate file, or you may embed your data in your MakeNL control file. (I prefer the latter method, but it is a matter of taste.) If you wish to maintain your data in a separate file, refer to the top half of Figure 2 (a facsimile of file HUB.CTL in your distribution package). If you want to keep your data in your control file, refer to the bottom half of Figure 2 (a facsimile of file NET-S.CTL in your distribution package). Refer to sections 5 and 6 as you study these files.
In either case, some minor editing of the control file you chose as indicated by comments in the file will have you nearly ready to go. When you have edited the control file to your liking, rename it MAKENL.CTL and move it to your mail server's home directory.
+---------------------------------------------------------------+
| ; This variation uses a "master data file" for input and |
| ; sends output to the same file name. |
| |
| make hub <100> <hub.100> ; note explicit name of file |
| ; simplifies processing |
| outfile <hub.100> ; master and output files have SAME |
| ; name |
| |
| submit <host's address> ; where you send updates, CRASH |
| ; and/or HOLD optional |
| netaddress <your address> ; your network address here |
| messages <directory> ; path name to mail server's |
| ; mail area |
| |
| ; No other options are needed. Master directory and output |
| ; directory will default to the current directory. |
+---------------------------------------------------------------+
| ; This variation uses "internal" data at the bottom of the |
| ; control file. |
| |
| make network <nbr> ; No "master data file" input data |
| ; is below. |
| outfile <explicit name> ; output file |
| |
| submit <RC's address> ; where you send updates, CRASH |
| ; and/or HOLD optional |
| netaddress <your address> ; your network address here |
| messages <directory> ; path name to mail server's |
| ; mail area |
| |
| ; No other options are needed. Master directory and output |
| ; directory will default to the current directory. |
| |
| data |
| |
| ; Your source data goes here. The advantage of this over |
| ; the version above is that MAKENL will not reformat or change|
| ; your source data, even if you have errors. |
+---------------------------------------------------------------+
Figure 2. Sample control files for Hubs and small NetsSince you don't have many files to keep track of, you will execute MakeNL from your mail server's home directory, and let your MASter directory default to this directory as well.
Set up an external event in your mail server to execute once a week at a day and time early enough to meet the deadline set by your coordinator, but not much earlier than that. The batch file
fragment corresponding to this external event will execute the statement:
MAKENLYou will normally ignore MakeNL. It will take care of itself. When a change occurs in your data, edit your file using your favorite editor. After editing, execute the following DOS command:
MAKENL /Tjust to be sure there are no errors. If MakeNL reports an error, repeat the above steps until you've got it right.
If you have added new nodes to your list, and wish to inform them of their node number assignments immediately, you need to get your changes into your mail server's nodelist. MakeNL can perform the first step for you if you execute the DOS command:
MAKENL /T /M[[=<path>\]<filename>]The /M switch tells MakeNL to merge your data with an existing distribution nodelist into a temporary nodelist with an extension of ".999". To do this, MakeNL must find a distribution list not more than two weeks old. If /M is used by itself, MakeNL will look for NODELIST.htu (see section 3.2 on page 14 for a description of this notation) in the current directory. If either the directory or the stem generic name are different, they must be given as a value in the /M switch.
Examples
MAKENL /T /M ; use NODELIST in current
MAKENL /T /M=\BBS\NODELIST ; use NODELIST in \BBS\
MAKENL /T /M=R10-LIST ; use R10-LIST in currentWhen the external event triggers MakeNL in process mode (you are in bed, sound asleep) It will create a new copy of your master file, compare it to the old copy, and if nothing has changed, it will simply delete the new copy. If the file has changed, it will update your master file and create a submittal message to send it to your coordinator.
That's all there is to it! MakeNL will take care of getting your nodelist changes in on time if and when they occur.
Your life is a little more complicated than above. You assemble your submittal segment from your own file plus files received from your Hubs. Not only do you need to figure out this section. You need to understand the forgoing one too, so that you may render assistance to your Hubs if necessary. But cheer up, it's not too bad!
+---------------------------------------------------------------+
| |
| make network <nbr> ; No "master data file" input data |
| ; is below. |
| |
| outfile <explicit name> ; use generic name if output file |
| ; is very large |
| |
| process Wednesday ; Set this day to meet deadline RC |
| ; gives you |
| |
| master <directory> ; where master files reside |
| ; (default - current) |
| update <directory> ; where to save received files |
| ; 'till processing |
| mailfiles <directory> ; where mail server places received |
| ; files |
| uploads <directory> ; where BBS places uploaded files |
| ; (if needed) |
| badfiles <directory> ; optional "waste can" for files |
| ; with fatal errors |
| |
| notify receipt ; notify both receipt and errors |
| ; CRASH and/or HOLD optional |
| submit <RC's address> ; where you send updates, CRASH |
| ; and/or HOLD optional |
| netaddress <your address> ; your network address here |
| messages <directory> ; path name to mail server's |
| ; mail area |
| |
| ; No other options are needed. |
| |
| data |
| |
| ; Your source data goes here. |
| |
| files |
| |
| Hub <nbr> <file name> ; either generic or explicit file |
| ; name, but must match convention |
| Hub <nbr> <file name> ; used by Hub. |
| Hub <nbr> <file name> <notification address>; if not "net/hub"|
| Hub <nbr> <file name> |
| ; etc. |
+---------------------------------------------------------------+
Figure 3. Sample control file for large NetsRefer to the figure 3 (a facsimile of file NET-L.CTL in your distribution package).
The submittal file for most local networks will be less than five kilobytes in size. For files this small, there is no advantage in using a generic output file name (see section 3.2 on page 14). Your Regional Coordinator will probably tell you to use an explicit file name. There is certainly no reason for you to require your Hubs to use generic submittal file names. Notice that the OUTFile statement in figure 3 indicates the use of an explicit name.
Rename NET-L.CTL to MAKENL.CTL and move it to the directory you wish to use as the current directory when you execute MakeNL. Usually, this will be your mail server's home directory. Edit the file as indicated in the comments in NET-L.CTL. If you only have two or three hubs, you may wish to comment out the MASter directory statement and let it default to the current directory.
Copy your own source data, the part you maintain which contains the "Host" statement into the control file between the DATa and FILes statements. Following the FILes statement, edit the HUB definition statements to match the Hubs who submit update files to you. Make sure the directories exist for all path names, that they are all distinct directories, and if you used relative path names, that they are relative to the directory from which you will execute MakeNL. Make sure the process statement names the right day so that you can meet your RC's submittal deadline. That should get your control file in order.
Move your current copies of your Hubs' segment files to the directory defined as MASter in your control file.
Set up an external event in your mail server to execute daily at a time early enough that, on your process day, you will meet the deadline set by your Regional Coordinator, but not much earlier than that. The batch file fragment corresponding to this external event will execute the statement:
MAKENL
or if you want to keep a log of activity
MAKENL >>MAKENL.LOGMakeNL is now set up to pretty well take care of itself. On nonprocess days the external event will execute MakeNL in test mode. It will scan the UPLoads and MAIlfiles directories for received files, test them for errors, send out notifications and move the files to the UPDate directory.
On the process day MakeNL will be executed in process mode. It will scan the UPLoads and MAIlfiles directories for late files, the UPDate directory for files received earlier in the week, and the MASter directory for files not updated this week.
+---------------------------------------------------------------+
| make region <nbr> ; No "master data file" input data |
| ; is below. |
| |
| outfile <generic name> ; use generic name for output file |
| |
| process Thursday ; Set this day to meet deadline ZC |
| ; gives you |
| |
| arc 5 ; force ARC 6 or 7 to generate level 5 archives |
| ; DO NOT use ARC5 with ARC versions earlier than 6 |
| |
| master <directory> ; where master files reside |
| ; (default - current) |
| update <directory> ; where to save received files |
| ; 'till processing |
| mailfiles <directory> ; where mail server places received |
| ; files |
| uploads <directory> ; where BBS places uploaded files |
| ; (if needed) |
| badfiles <directory> ; optional "waste can" for files |
| ; with fatal errors |
| |
| notify errors CRASH ; notify of errors (CRASH and/or |
| ; HOLD optional) |
| notify receipt ; use either of these or both with |
| ; different attributes. |
| |
| submit <ZC's address> ; where you send updates, CRASH |
| ; and/or HOLD optional |
| netaddress <your address> ; your network address here |
| messages <directory> ; path name to mail server's |
| ; mail area |
| |
| data |
| |
| ; Your region source data goes here. |
| |
| files |
| |
| Net <nbr> <file name> ; either generic or explicit file |
| Net <nbr> <file name> ; name, but must match convention |
| ; used by Net. |
| Net <nbr> <file name> <notification address> ; if not "net/0" |
| Net <nbr> <file name> |
+---------------------------------------------------------------+
Figure 4. Sample control file for Regional CoordinatorAll files will be tested (again) for errors, and sent to your master output file. Your master copies of your Hubs' files will be updated as necessary.
If (and only if) this week's output is changed from last week's, your submittal file will be created in the current directory, and a "file attach" message will be generated to send it to your Regional Coordinator. All untouched by human hands!
When the data changes in your own nodelist segment, edit your data file (usually your control file) and execute the DOS command:
MAKENL /T
or
MAKENL /T /M ; see discussion in the previous sectionGiven a chance, MakeNL will do the right things at the right times. You worry about other things, like "Why can't Hub 999 send me a file without errors? I gotta get him to use MakeNL!"
For the most part, section 2.3 applies to you too, but there are some differences.
Figure 4 is a facsimile of REGION.CTL, the prototype control file you will use.
You have enough files you will want to get them out of the clutter of your mail server's home directory. You will set up a separate MASter directory (see section 5.1 on page 20).
Your output file is probably large enough that you will want to take advantage of the benefits of using a generic output file name. In fact, your ZC may require it.
If your region file is larger than 10 kilobytes, MakeNL will create a compressed archive by executing the program ARC. If you have version 6 or 7 of ARC and your ZC does not, you may want to force ARC to produce level-5 compatible archives.
Other than that, substitute Network for Hub, Region for Network and Zone for Region, and follow the procedures in 2.3 using the file REGION.CTL from your distribution package.
Life gets still more complicated, but is still manageable.
Preparing a zone segment is much the same as preparing the region segments of which it is made. Refer to sections 2.3 and 2.4 above, figure 5 (a facsimile of the file ZONE.CTL from your distribution package).
+---------------------------------------------------------------+
| make zone <nbr> ; No "master data file" input data |
| ; is below. |
| outfile <explicit name> ; use generic name for output file |
| ; if very large |
| process Thursday ; Set this day to meet deadline ITC |
| ; gives you or Friday after |
| ; cut-over to zone based nodelist |
| arc 5 ; force ARC 6 or 7 to generate level 5 archives |
| ; DO NOT use ARC5 with ARC versions earlier than 6 |
| |
| master <directory> ; where master files reside |
| ; (default - current) |
| update <directory> ; where to save received files |
| ; 'till processing |
| mailfiles <directory> ; where mail server places received |
| ; files |
| uploads <directory> ; where BBS places uploaded files |
| ; (if needed) |
| badfiles <directory> ; optional "waste can" for files |
| ; with fatal errors |
| notify errors CRASH ; notify of errors (CRASH optional) |
| ; Errors should not occur at this |
| ; level, but. . . |
| submit 1:1/0 ; where you send updates, CRASH |
| ; and/or HOLD optional |
| netaddress <your address> ; your network address here |
| messages <directory> ; path name to mail server's |
| ; mail area |
| |
| data |
| |
| ; Your zone source data goes here. Note that first |
| ; non-comment statement must begin with the keyword "Zone" |
| ; not "Region" |
| |
| files |
| |
| Region <nbr> <generic name> |
| Region <nbr> <generic name> |
| Region <nbr> <generic name> <notification address> ; if not |
| ; "region/0" |
| Region <nbr> <generic name> |
| ; etc. |
+---------------------------------------------------------------+
Figure 5. Sample control file for Zone CoordinatorsOn your process day, after generating your zone segment, you will execute MakeNL a second time with a special control file to create your zone's version of the distribution nodelist. Section
+---------------------------------------------------------------+
| make composite |
| name <network name> ; eg. FidoNet or AlterNet or EGGnet |
| |
| threshold 0 -1 ; force ARC -- no submittal difference file |
| |
| arc 5 ; force ARC 6 or 7 to generate level 5 archives |
| ; DO NOT use ARC5 with ARC versions earlier than 6 |
| |
| outfile <generic name> ; recommended names: |
| ; NODELIST - complete composite list |
| ; Zn-LIST - zone distribution list |
| ; Rnn-LIST - region distribution list |
| ; NnnnLIST - network distribution list|
| |
| outdiff <generic name> ; recommended names: |
| ; NODEDIFF - complete composite list |
| ; Zn-DIFF - zone distribution list |
| ; Rnn-DIFF - region distribution list |
| ; NnnnDIFF - network distribution list|
| |
| master <directory> ; same as OUTPath or MASter in |
| ; previous run |
| outpath . ; put <name>.nnn in current directory |
| |
| copyright <cpy-dist.txt>; if these three files are not path- |
| prolog <file name> ; qualified, they are lodated in the |
| epilog <file name> ; master directory |
| |
| files |
| |
| Network <nbr> <explicit name> ; must match OUTFile name of |
| ; previous run |
| ; or |
| Region <nbr> <generic name> ; must match OUTFile name |
| ; or |
| Zone <nbr> <generic name> ; must match OUTFile name |
| Zone <nbr> <generic name> ; file(s) received from |
| ; etc. . . ; other ZC(s) |
+---------------------------------------------------------------+
Figure 6, Sample control file for distribution lists(?) deals with distribution lists. The only difference for ZCs is that they will need to define the MAIlfiles path to pick up the files from the other ZCs.
There are several advantages to "zone specific" distribution NODELISTs. Prologue and epilogue comments may be "zone localized." The local zone may be placed first in the list, a significant convenience to the nodes in your zone. There will probably be quicker and better NODELIST availability.
Distribution lists (see section 3.7 on page 15) may be prepared at any level except Hub, though it is not recommended below Region. In theory, a distribution list may be prepared at the same time your submittal file is prepared (MakeNL will support this method). In practice, it is better to make a distribution list in a separate run of MakeNL so that the distribution list may have a distinct file name, and different copyright notices and comments.
Refer to figure 6 (a facsimile of the file DISTRIB.CTL in your distribution package). Now that you thoroughly understand all of the forgoing (you do, don't you?), this file is fairly selfexplanatory. After you edit it to fit your specific needs, your MakeNL external event can use it to create your distribution files. If your MakeNL external event executes once a week, the batch file fragment is trivial:
MAKENL
MAKENL DISTRIBIf your MakeNL external event is a daily event then:
MAKENL
IF ERRORLEVEL 3 GOTO LOOP
MAKENL DISTRIBHere you make use of the fact that a return code of 3, 4 or 5 means that MakeNL was executed in test mode. That means it was not your normal process day, so the batch file simply restarts your mail server after testing any received files. On process day you will "drop through" and create distribution files.
Before we proceed further, we need to define some terms in use throughout this document.
The composite nodelist is defined, for our purposes, as the complete list of all nodes in the network. It includes all Zones, all Regions and all local nets.
To MakeNL, a generic file name is one which does not have a file type (or file extension). For example, NODELIST and FILES1 are generic file names. MakeNL does special processing on files when you specify them by generic names. It creates file types for them based on publication date and contents of the files.
The publication date is translated into a 3-digit day-of-year, represented here as "htu" where "h" is the hundreds digit, "t" is the tens digit and "u" is the units digit of day-of-year. MakeNL recognizes and/or creates the following file types for files with generic names:
.htu - Master files, uncompressed submittal and distribution
files, distribution difference files
.Atu - Archived submittal and distribution files, archived
distribution difference files
.Dtu - Submittal difference files
.ADu - Archived submittal difference filesAn explicit file name, on the other hand, has a specified file type. PROLOG.TXT is an example. When data files are specified this way, MakeNL does only limited processing on them, specifically checking them for errors and copying them from directory to directory. It makes no attempt to deal with archives or difference files.
An archive file is a compressed file created by the ARC program from System Enhancement Associates. You must have a copy of this program in your current directory or on your DOS path (see "PATH" command in your DOS manual) to make use of this capability of MakeNL.
The ARC program, version 6 and later, has the ability to create archives compatible with earlier versions of ARC. MakeNL provides a configuration verb to permit the use of this capability. (See section 6.3.4 on page 30)
A difference file is a file which defines the differences between an older version of a file and a newly created one. In fact, the difference file (sometimes called a "diff" file from the NODEDIFF naming convention) contains a simple editing language. With a copy of the old file and the difference file, MakeNL can accurately recreate the new version of file.
A submittal file is one which you will send forward up the ladder to be merged with other files from your level. A Hub sends his submittal file to his network host. The host sends his submittal file to his regional coordinator, etc.. MakeNL will create your submittal file for you each week, and can even create the "file attach" message to send the file over the network.
Distribution files, on the other hand go the other way. They are meant for distribution down the ladder. NODELIST.htu and NODEDIFF.htu are well known examples, but let's say you are a regional coordinator, and some of the nodes in your region have no interest in communicating with nodes outside the region. To conserve valuable disk space, they might wish to use a nodelist which only contains your region. MakeNL can create such files. They differ from submittal files only in the naming conventions they observe.
An absolute path name is one specified from the disk's root directory. It will always begin with a back-slant () or a drive specifier followed by a back-slant (C:) C:and are examples of absolute path names.
A relative path name is one specified as a subdirectory from the current working directory, without specifying what that is. It never begins with a back-slant. FILESand D:OPUS are examples of relative path names. In the latter case the path is relative to the current directory of the D drive.
See your DOS manual for additional information on path names.
The "publication date" is the date of the next publication of the composite nodelist. It is always the same day of the week. It is usually a Friday, but can be any day of the week.
The publication date is specifically, the next occurring publication day (today, if this is your publication day).
NOTE: Most FidoNet compatible networks publish their nodelist on Friday, but a few publish on other days. A special verb is provided to control publication day. (See section 6.1.3 on page 22.)
MakeNL is invoked with the following command line:
MakeNL [<control_file_name>] [/PROCESS | /TEST]
[/MERGE[=<list_name>] [/NAME=<composite_name>]The switch names may be spelled out (/TEST), or abbreviated to as few as one letter (/T).
By default, MakeNL expects to find a control file named MAKENL.CTL in the current directory. This can be overridden by placing the name (optionally qualified with a path) on the command line. The control file may have any file extension, but if none is given .CTL is assumed. For example:
MakeNL ZONE1causes MakeNL to use ZONE1.CTL in the current directory, and:
MakeNL MASTER\NET100.CFGcauses MakeNL to use NET100.CFG in the subdirectory named MASTER as its control file.
MakeNL must have a control file and will abort if it can find none. See section 6 on page 21 for the contents of the control file.
In operation, MakeNL writes a number of progress messages to "standard output." By default, DOS sends these messages to your screen, but you may redirect them to a file to retain a log of MakeNL's activity:
MAKENL >MAKENL.LOG
MAKENL >>MAKENL.LOGIn the first case, the log file is recreated fresh each time MakeNL is executed. In the second case, MakeNL appends the results of each execution to the end of the log file.
The optional "/TEST" switch, if given, will force MakeNL to operate in test mode, even on the normal process day.
The optional "/PROCESS" switch, if given, will force MakeNL to operate in process mode, overriding the effect of a PROcess statement in the control file.
The optional "/MERGE" switch, if given, will cause MakeNL to merge your updated nodelist segment with an existing distribution nodelist to produce a temporary nodelist containing your updates.
If <list_name> is given, it must have the form:
/M=[path\]<generic_name>See discussion of MERge control file verb on page 24 for more details.
The optional /NAME switch is a specialized cosmetic switch. When you MAKe a composite list (see section 6.1.1 on page 21), the generated list begins, by default, with the line " Nodelist for. . ."
The /NAME switch may be used to insert a network name in front of the first word in that line. If the specified replacement name contains spaces, the entire parameter must be enclosed in quotes.
For example, the coordinator for a network operated by the US Parks Service might use:
MAKENL "/N=Parks Service"The first line of his generated list would read "Parks Service Nodelist for. . ." Note that to the right of the equal sign case is significant. Any capitalization present will be preserved.
A FidoNet ZC might use:
MAKNL /N=FidoNetIf the MAKe statement in your control file (see page 21) is not "MAKE COMPOSITE" the /NAME switch will have no effect.
See also the NAMe verb in section (?), page (?).
MakeNL terminates with ERRORLEVEL (see your DOS manual) set to one of the following values:
0 = Process mode - no errors encountered
1 = Process mode - no fatal errors encountered
2 = Process mode - one or more fatal errors encountered
3 = Test mode - no errors encountered
4 = Test mode - no fatal errors encountered
5 = Test mode - one or more fatal errors encountered
254 = MakeNL aborted - I/O error
255 = MakeNL aborted - Control file errorMakeNL uses several disk directories in the performance of its tasks. Some are required -- others are needed only to make use of special features. In this text, MakeNL's directories will be referred to by the following names.
The master directory is where MakeNL stores all of its master files. Received files will migrate to this directory. MakeNL requires a master directory.
The update directory provides interim storage for received files. It is needed only if you process files received from others, and notify them on receipt or when errors occur. It prevents multiple notification.
The mailfiles directory is the directory in which your mail server receives files. It is required if you receive nodelist segments from others via the network.
The upload directory is the directory in which your BBS stores uploaded files. It is required if others upload nodelist segments to your BBS.
Depending on the options selected in the control file, MakeNL may need access to other directories.
If MakeNL will be generating network messages it must be told in which directory your mail server expects to find these messages.
By default, MakeNL places the master copy of its output file in the directory with your other master files. You can, however, define another directory to receive output files.
When a received file has a "fatal error," one which renders the entire file unusable, MakeNL must get it out of the way to prevent further attempts to process it. By default, it simply deletes the offending file, but you may define a "bad files" directory and MakeNL will move such files there.
The "current directory" when MakeNL is invoked is the default directory for MakeNL's control file.
MakeNL requires a control file to define its operating parameters. By default, this file is named MAKENL.CTL, but you may specify another control file name on the command line.
The contents of the control file is a series of statements which tell MakeNL what it is to do, and how it is to do it. Each statement begins with a verb, and may have as many as three additional arguments.
MakeNL is not sensitive to "case" of characters in the control file. Upper, lower or mixed case may be used. In the discussion of the control verbs below, upper case is used to indicate the minimum abbreviation required.
The definitions of the control file verbs are grouped by type for clarity. Except for DATA and FILES, they may appear in your control file in any order.
The following statements control the overall operation of MakeNL.
A MAKe statement is required in every control file. It tells MakeNL what type of nodelist segment it is to produce and what kind of input to expect.
<segment_type> is one of HUB, NETwork, REGion, ZONe or COMposite.
<number> is shown above as "optional." This isn't strictly correct. For all segment types except COMposite, it is required. It must NOT be used for COMposite. <number> is the network address number associated with the segment being made.
Even if you are a Zone Coordinator, there is a part of the nodelist segment you prepare which you, yourself maintain -- the list of nodes associated directly with your segment heading. In the case of a ZONe segment type, this includes the "zone gate" nodes. In the case of an RC it is the list of "independent" nodes in your region. There are two ways to input your sub-segment into MakeNL. One is through the use of the DATa statement (see section (?) on page (?). The other is by specifying a source file in the MAKe statement.
<source_file> must be an explicit file name without a path qualifier. The named file must exist in the directory named as your master directory. The first non-comment statement in the file must match the MAKe statement in <segment_type> and <number>.
Examples:
MAKE COMPOSITE ; make a complete nodelist
MAKE NET 100 MASTER.DAT ; input data from "master"
MAKE REGION 10 ; use DATA statementWhen you MAKe a composite list (see section 6.1.1), the generated list begins, by default, with the line " Nodelist for. . ."
With the NAMe verb, you can define a <network_name> that will be inserted in front of the first word of that line. <network_name> is the only parameter in your control file that is case-sensitive. It will appear in the list exactly the way it appears in your control file. This verb is almost identical to the /NAME switch (see section 4.5 on page 18).
There are two restrictions imposed by the NAMe verb that do not apply to the /NAME switch. <network_name> can be no more than 15 characters long, and can not contain any spaces or tabs.
If you use both the NAMe verb in the control file and the /NAME switch on the command line, the command line switch will override.
Most FidoNet compatible networks publish their nodelists each Friday. For that reason, MakeNL assumes a Friday publication day.
As noted earlier, the file extensions MakeNL computes for generic file names are determined by publication date, which is defined as the next occurrence of your publication day, expressed as day of year. Obviously, your next publication date if different if you publish on Saturday, than if you publish on Friday.
The PUBlish statement let's you inform MakeNL that you publish your list on some day other than Friday, and he will adjust his generic file name extensions accordingly. The <day_of_week> may be a full day name, or may be abbreviated to as few as three characters.
Example:
PUBLISH SUNDAY ; sets file extensions according to
; Sunday's dateCAUTION: Some nodelist processors may fail to operate correctly with file name extensions keyed to a day of week other than Friday. For example, versions of EditNL earlier than 4.20 will never find such files. On the other hand, XLATLIST handles all such extensions, but has a problem with the first list of a new year if you don't delete the list(s) from the previous year first.
MakeNL has two fundamental modes of operation, "test" and "process."
In test mode, it scans input data and checks it for errors and it moves received update files to the update directory. Unless the MERge statement or the /M command line switch is used, it does not produce any output.
In process mode MakeNL produces an updated master file for your nodelist segment and any required submittal or distribution files. Normally you will do this once each week.
If no PROcess statement is present, MakeNL will operate in process mode unless the /T command line switch is used. If the PROcess statement is present, it controls MakeNL's mode of operation. Except on the day specified in this statement, MakeNL will operate in test mode. When MakeNL is executed on the defined process day, it operates in process mode.
This statement is most useful to coordinators who receive update files from others. It permits them to operate MakeNL daily in an "external event" of their mail server. It error checks received files and sends back notification on a daily basis as files are received, but only on the appropriate day does it create a submittal file and forward it up the ladder.
The <day_of_week> may be a full day name, or may be abbreviated to as few as three characters. It should be chosen so that you may meet the submittal deadline set by the next higher coordinator.
Example:
PROCESS THURSDAYWhen you add new nodes (or nets, as the case may be) to your list, you might like to notify them immediately that their applications have been acted upon. This is complicated by the fact that your mail server needs to know about these new nodes (or nets), and that information comes from the distribution nodelist. It may be several days before you receive the updated version of the distribution nodelist containing the new listing.
The MERge statement tells MakeNL to merge your updated segment into an existing distribution nodelist to create a temporary nodelist your mail server can use. This action will occur even if MakeNL is operating in test mode.
By default, MakeNL will search for NODELIST.htu not more than two weeks old in the current directory, create a temporary list named NODELIST.999, copy from the distribution list to the temporary list until it finds your segment in the distribution list, generate an updated version of your segment in the temporary list and finally, copy the remainder of the distribution list to the temporary list.
In order to find your segment in the distribution list, MakeNL uses information from the MAKe and NETaddress statements in your control file.
If you are MAKing a HUB, NETaddress must provide the net number. If no NETaddress is given, the MERge command will be canceled.
If you are MAKing anything other than a ZONE, and if the distribution list is a zone-based list, the zone number from the NETaddress command is used to place your segment in the correct zone. If no zone number is given, MakeNL assumes that your segment goes in the first zone it encounters in the distribution list.
If present, <nodelist_name> must be a generic file name, but may be qualified by a path name. It overrides the name and location of the distribution list, but the rest of the actions are the same. The temporary list is placed in the same directory as the distribution list being merged.
If the MERge statement is used in your control file, it will ALWAYS be executed. If you prefer to "merge on demand" use the /M command line switch instead. It is exactly equivalent to the MERge statement. (See section 4.4 on page 18.)
Example:
MERGE \BBS\NODELISTPrivate nodes (identified by the PVT keyword in the nodelist) are not universally permitted by all networks. In a commercial network, for example, a node with no phone number listing is not particularly useful. By default, MakeNL will accept these node entries contrary to a network coordinator's intentions.
The PRIvate statement permits you to define other dispositions for such entries. <disposition> must be one of OK, NONE, ZONE, REGION, HOST or HUB.
"PRIvate OK" is equivalent to the default action -- private nodes are permitted (but, of course, only within nets).
NONE says they are not permitted. The PVT keyword will be treated as an error, with a note that "Private nodes are not permitted in this network."
If <disposition> is any of the hierarchical keywords, a private node will be transformed into an "open" node by removing the PVT keyword and substituting a known phone number in the phone number field. The number used is that of the nearest node at least as high in the hierarchy as the keyword specified. For instance, if "PRIvate HOST" is given, a private node will become a normal node with the phone number of the most recently encountered Host, Region or Zone statement. Even if the previous entry were a Hub, his phone number would not be used unless "PRIvate HUB" had been given.
For fairly obvious reasons, if you are MAKing a NETwork and enter the statement "PRIvate ZONE," MakeNL will abort with a control file error. It must be able to find at least one phone number to make the substitution, and your file can't have any zones or regions in it! The hierarchical level of <disposition> must be equal to or lower than the level you are MAKing. In the case you MAKe COMPosite, MakeNL will take your word for anything your PRIvate statement tells it, but if no matching phone number has been found before it encounters a private node, the private node will be treated as though the statement were "PRIvate NONE," and will generate an error.
The sixth field of a nodelist entry is the phone number field. MakeNL insures that it meets certain minimum standards. It must begin and end with a digit. It must contain only digits and hyphens. There must not be two hyphens in a row.
Phone numbers usually consist of several parts, separated by hyphens. For example, a number might have a country code, and area code, an exchange code and a line number. To MakeNL, a phone number is a phone number. It attaches no special meaning the number's various parts.
Some nodelist processing programs do attach meaning to the parts of a phone number, and complain if they are not there! For this reason MakeNL will enforce an additional constraint, if told to do so. It will insure that every phone number has a certain minimum number of parts.
Example:
MINPHONE 4This statement in a control file instructs MakeNL to reject any entry with a phone number that does not have at least four parts. The number "123-4567" would not be valid and would cause an error message to be issued.
In a large hierarchical network of international scope, the MINphone verb should only be used at the lower levels. Hubs and Hosts may expect all phone numbers to fit some standard format. Except in North America, regional coordinators are likely to find variability in phone number format from country to country. A zone coordinator will certainly encounter such variability. Attempts to enforce a standard number of parts in a phone number at these levels will not be very successful.
This is not a serious constraint on the use of MINphone. The files received by RCs and ZCs have already been processed at least once by MakeNL at a lower level where format can be enforced. There should be no need to do it again.
The seventh field of a nodelist entry is the baud rate field. MakeNL checks the value in this field against a table of valid baud rates. Experience has shown this to be necessary. Certain types of errors can cause a part of the phone number to appear to be in the baud rate field. Without a validity check, these errors could go undetected. By default, the valid rates are 300, 1200, 2400, 4800, and 9600.
To accommodate future growth, the "valid baud rate" table is configurable through the use of the BAUdrate verb. The <valid_baud_rates> parameter is a list of up to twelve (12) valid baud rates (numeric strings) separated by commas. It may contain no spaces of tabs. It must be the complete list, and will replace MakeNL's internal table.
For example:
BAUDRATE 1200,2400,4800,9600This statement would effectively eliminate 300 baud nodes from your list, while:
BAUDRATE 300,1200,2400,4800,9600,14400would permit nodes to use 14400 baud in their entries. A caveat in this case. Any new values must be authorized from the top down. If you used this statement and submitted a list with 14400 baud nodes, the first coordinator who did not have a similar BAUdrate statement would reject those nodes as having invalid baud rates.
In general, you can be more restrictive than the coordinator(s) above you, but you cannot be more liberal!
MakeNL uses several directories for various purposes for storage of nodelist segment data. The following statements are used to define to MakeNL where these directories are located. They all have the same format:
<verb> <directory_path_name><verb> is one of MASter, UPDate, MAIlfiles, UPLoads or BADfiles as defined below.
<directory_path_name> is a relative or absolute directory path name, with or without a disk specifier.
This is the directory in which MakeNL keeps all its "master" files. This includes the master copy of your submittal file, master copies of nodelist segments received from others, your input source file, if used, and the three "comments" text files, if used. In addition, for each segment given a generic name, week-old copies are kept here and used create and/or apply difference files.
MakeNL always uses a master directory. If this statement is absent, the current directory is used as the master directory.
If others upload update files to your BBS, this statement tells MakeNL where to look for them. Only one upload directory may be named. If your BBS supports more than one, you need to inform your submitters how to upload their updates so that they wind up in the right directory.
If you don't receive update files via upload, omit this statement and MakeNL will ignore it.
If you receive update files from others via network mail, this statement tells MakeNL where your file server will put the files.
If you don't receive update files via network mail, omit this statement and MakeNL will ignore it.
If you receive update files from others by any means, this statement defines a temporary holding directory for them. When MakeNL is operated in test mode, files it finds in the UPLoads or MAIlfiles directories are moved to this directory. If you use notification (and you should use at least error notification), MakeNL will generate a notification message each time it finds a submitter's update file in one of those directories. Moving received files to the update directory prevents multiple notification.
If received files were moved to the master directory in test mode, and if a subsequent difference file were received from one of your submitters, you might have already lost the file MakeNL needs to apply the difference file against!
When MakeNL operates in process mode, it moves files found in any of these directories to the master directory as part of its update process.
If you don't receive update files from others, omit this statement and MakeNL will ignore it.
When a received file generates a fatal error, MakeNL refuses to process it further. By default, it simply deletes the offending file, but if this directory is defined, MakeNL will move files with fatal errors here. This gives you a chance (if you feel so inclined) to edit the file to correct the error, then move it back to say the MAIlfiles directory and process it again.
If you don't receive update files from others or don't want to correct their errors for them, omit this statement and MakeNL will ignore it.
The following statements tell MakeNL what output to generate and how to generate it. They only have effect when MakeNL operates in process mode.
This statement is required in your control file. It defines the name of your master and submittal files. These are the same file unless MakeNL creates an archive or a difference file. These files are placed in your OUTFile directory, or if it is not defined, your MASter directory.
<filename> may be either explicit or generic, but the choice carries some implications with it. Using an explicit output file name inhibits some of MakeNL's features, but if your output file is small they may not be of interest to you. Specifically, MakeNL will create neither an archive file nor a difference file for explicitly named files. The reason is that to do so, MakeNL must have the freedom to manipulate file extensions, but it cannot do that if you give it an explicit file extension.
By default, MakeNL keeps all of its output (except a merge file) in the MASter directory. This includes the output master file, the submittal file (if different), and distribution files. The OUTPath statement, if present, tells MakeNL to keep its output in a different directory.
When you use a generic output file name, MakeNL will do its best to insure that your submittal file is small enough to send to your coordinator in a one-minute phone call. It has two ways to compress a file.
First, it can create an archive file, using the ARC program. This will typically achieve about 40% reduction in size.
Second, it can create a difference file. This is a file which contains only the differences between your new output file and your previous one. This technique can achieve dramatic file size reduction, but is not as safe as the former. It assumes that your coordinator has a copy of your previous file (usually a safe assumption). With it and the new difference file he can reconstruct your new output file.
At 2400 baud, you can transmit a file about 10000 characters long in a one-minute phone call. If an archive file is at least 40% smaller than its uncompressed version, a file of up to 16666 characters can be archived and transmitted in a minute. These are the two default thresholds MakeNL uses to determine what to do with your submittal file. The THReshold statement can override these defaults.
If your submittal file is larger than <arc_size> (in bytes), MakeNL will use ARC to create an archive of it, and submit the archive file.
If your submittal file is greater than <diff_size>, MakeNL will create a difference file and submit it. If a difference file is still larger than <arc_size>, MakeNL will create an archive of the difference file and submit that, but that is the best it can do.
If <diff_size> is given, it must be greater than or equal to <arc_size>. If <diff_size> is not given it is calculated by MakeNL as 5/3 * <arc_size>.
Examples:
THRESHOLD 5000 ; recommended value for 1200 baud
THR 0 ; always create an archived diff file
THR 0 -1 ; always archive -- no diff
THR -1 -1 ; turn compression offMakeNL creates compressed archive files by executing the program ARC by System Enhancement Associates.
ARC will, by default, produce the maximum compression of which it is capable. This may not always be desirable. If you have version 6 or 7 of ARC, and the recipient of your archived file does not, he will be unable to unpack your archives.
The ARC <n> verb will force these versions to create level-5 or level-6 compatible archives, thus insuring compatibility. The parameter <n> must be either "5" or "6."
Do not use ARC <n> if you have ARC version 5 or earlier. It will cause errors, as will the use of "ARC 6" with version 6! The compatibility level must always be LOWER that your version level.
MakeNL's primary mission is to gather segments of the nodelist and assemble larger segments for submittal to the next higher coordinator, until finally all the segments have been assembled and the result is the network's distribution nodelist. However, if desired, distribution lists may be created at any step along the way.
Distribution lists are actually created in pairs. A familiar pair is NODELIST.htu and NODEDIFF.htu, the files which define the Public FidoNet Network.
There is no reason why a node must use the full network list if a smaller list will suit his needs. Indeed, programs such as PRUNE are based on this philosophy.
When the OUTDiff statement appears in your control file, MakeNL will produce a pair of distribution files. OUTFile and OUTDiff must specify distinct generic names, and they will become the "stem" names of your distribution files.
Distribution files differ from submittal files in the naming conventions used to determine file extensions. For example, assume:
OUTFILE REGION10
OUTDIFF R10-DIFFThen the following table defines the file names of generated submittal and distribution files:
Compression Submittal Distribution
None REGION10.htu REGION10.htu
Archive REGION10.Atu REGION10.Atu
Difference REGION10.Dtu R10-DIFF.htu
Both REGION10.ADu R10-DIFF.AtuNote that the full list and its archive bear the same name in both columns. Indeed, they are the same files. But submittal files use the same filename stem for all types of files, while distribution difference files have unique filename stems. The reason for this is to support the traditional names NODELIST and NODEDIFF as painlessly as possible.
Distribution files, as with submittal files, are placed in the OUTPath directory. Once created, these files are ignored by MakeNL, unless explicitly told to clean up its old files (see the CLEanup command below).
The following control file fragment would create NODELIST distribution files for the Public FidoNet Network.
Example:
MAKE COMPOSITE
THRESHOLD 0 -1 ; force archiving -- no submittal diff
OUTPATH . ; master list to current directory
OUTFILE NODELIST ; create NODELIST.Atu
OUTDIFF NODEDIFF ; create NODEDIFF.AtuWhen MakeNL has finished, three files are left in the current directory; NODELIST.htu, NODELIST.Atu and NODEDIFF.Atu. Note that with "THRESHOLD 0 0," NODELIST.ADu would be created with contents identical to NODEDIFF.Atu.
If you use a generic OUTFILE name, and if you create difference and/or archive files, they tend to accumulate in your OUTPATH directory over time. By default, MakeNL ignores them completely. This is done so that OUTPATH can point to a "download" directory where several editions might be made available to users.
When MakeNL operates in process mode and CLEanup (no arguments) appears in the control file, after all other processing is done, it searches the OUTPATH directory for old difference and/or archive files and deletes any it finds.
CLEanup has no effect on current files or the handling of output master files. It has no effect whatever when MakeNL is operated in test mode.
MakeNL can generate two kinds of network messages, notification messages and submittal messages.
Notification messages are addressed to submitters to notify them of receipt of and/or errors in their submittal files.
A submittal message is addressed to your coordinator, and has your submittal file attached.
Messages created by MakeNL are compatible with SEAdog by System Enhancement Associates. Except for CRASH and HOLD attribute flags, they are compatible with Fido v11, and (I think) Fido v12 by Tom Jennings. They are probably compatible with other mail servers, but I cannot guarantee it.
The following statements control the generation of these messages.
This statement is used to tell MakeNL what your network address is. MakeNL must know your network address in order to generate the "From:" field in submittal or notification messages. If MakeNL must create inter-zone messages, it needs to know your zone number. In addition, your zone number, and if you are MAKing a HUB, your net number may be needed to properly perform a MERge operation.
If your control file does not contain a NETaddress statement, MakeNL will try to guess you network address from your MAKe statement. If you are MAKing a ZONE, your default network address is <nbr>:<nbr>/0. If you are MAKing a REGION or NETWORK, your default network address is 0:<nbr>/0. If you are MAKing a HUB, MakeNL hasn't a clue!
If the default network address MakeNL selects for you is satisfactory, you don't need a NETaddress statement, but it is recommended that you include one to remove all doubt.
Examples:
NETADDRESS 100/76
NETADDRESS 1:1/0This statement is required if MakeNL is to generate ANY outgoing messages. It tells MakeNL the name of the directory used by your mail server for network mail messages.
Example:
MESSAGES D:\BBS\MAILThe SUBmit statement tells MakeNL that in process mode it is to create a "file attach" message to send your submittal file to your coordinator. <address> is his network address.
Optional <flags> may be any or all of CRASH, HOLD or INTL. These should not be used unless your mail server supports them.
Example:
SUBMIT 13/0 CRASHThe INTL flag is a special case. It forces MakeNL to add the "^AINTL: <from> <to>" extended address line to all messages it creates, even if they are not leaving your zone. Indiscriminate use of this flag is not recommended. You should use it only if your mail server needs all messages to contain the expanded address.
NOTE: If you don't know what I'm talking about, don't use the INTL flag. It may cause you trouble. Consult your mail server's documentation for guidance. Most mail servers do not require this feature and many consider these messages malformed. Two which may need the INTL flag are D'Bridge and FrontDoor.
If the NOTify statement is used, when MakeNL finds a received update file in either the UPLoads or MAIlfiles directory, it will notify the submitter that the file was received and/or that the file contained errors.
Optional <flags> may be any or all of CRASH, HOLD or INTL. These should not be used unless your mail server supports them. (INTL need only be specified once, and it applies to all messages.)
<type> is one of RECeipt, ERRors or SELF.
RECeipt and ERRors control notification of nodes submitting files to you. If only NOTIFY RECEIPT is used, all notification messages will have the same attributes, as defined by <flags>. If only NOTIFY ERRORS is used, the submitter is NOT notified unless his update file has errors. NOTIFY RECEIPT and NOTIFY ERRORS may both be used with different message attribute flags, if desired. In other words, normal receipt notification may be sent "regular" mail, while error messages are sent "CRASH."
Unless you execute MakeNL with the "/T" switch, NOTIFY SELF instructs MakeNL to enter a message to you if it encounters any errors in your input data. If you edit your master file without testing it and you goof (shame), the error could go unnoticed for some time. When MakeNL is executed by your external event, the error will cause a message to you to appear in you network mail area.
MakeNL uses a number of special files in the performance of its duties. The statements in this section provide the means to define these files and/or alter defaults.
When MakeNL processes nodelist segment data, it ignores comments embedded in the data files. These comments are assumed to be your notes to yourself. They might be anything -- voice phone numbers, suspense dates when "down" nodes are expected to come back on line, etc..
Comments may be placed in submittal files to communicate information to your coordinator, or in distribution files to communicate information to your users, but not by embedding them in your data.
Instead, comments are placed in your output files by creating and maintaining three special text files in your MASter directory. In process mode, MakeNL searches for these files and, if they exist, copies them into your submittal file. It is not an error if any of them does not exist. Missing comments are simply ignored.
When MakeNL copies any of these files to the output file, it examines the first character of each line to see if it contains a "comments flag," a semicolon (;) character. Any line beginning with a semicolon is copied as is to the output file. MakeNL inserts ";S " at the beginning of any line which does not begin with a semicolon.
By default, MakeNL looks for a file named CPYRIGHT.TXT in the MASter directory. If it exists, it is assumed to be a copyright notice, and is copied into the output file immediately under the identification header line.
The copyright file gets a special treatment the other comments files do not get. If a string of four pound signs (####) is found in the first line, it is replaced with the current year. Thus "Copyright ####" becomes "Copyright 1987" automatically. You don't have to remember to edit your copyright notice in January.
The COPyright statement lets you override the default name "CPYRIGHT.TXT" with any other explicit name. You might need to do this if, for example, you are a Regional Coordinator and use two different control files to create your submittal file and distribution files. You may use the same MASter directory for both and have different copyright notices on each. In fact, you might name a nonexistent file when generating your submittal file, thus eliminating the notice.
Examples:
COPYRIGHT CPY-DIST.TXT
COPYRIGHT NONE ; file "NONE" does not existBy default, MakeNL looks for a file named PROLOG.TXT in the MASter directory. If it exists, it is copied into the output file immediately under any copyright notice.
The PROlog statement allows you to override the default filename, "PROLOG.TXT" with any explicit file name. If the named file does not exist in the MASter directory, the effect is to turn off prologue comments.
By default, MakeNL looks for a file named EPILOG.TXT in the MASter directory. If it exists, it is copied into the output file following all nodelist segment data.
The EPIlog statement allows you to override the default filename, "EPILOG.TXT" with any explicit file name. If the named file does not exist in the MASter directory, the effect is to turn off epilogue comments.
As stated earlier, comments in nodelist segment data files are NOT copied into output files. But comments in your received files are probably there to communicate information to YOU. Like the old dairy cream separator, MakeNL can separate comments from received files out into their own file.
When the COMments statement appears in your control file, it tells MakeNL to write the name of each input file to the named comments file, followed by any comments statements that appear in that file.
The file name MUST be explicit, but may have a path name. The comments file will appear in the current directory if no path is given.
If the COMments statement is omitted, comments in received files are ignored by MakeNL.
The DATa statement is used as an alternative method of entering your nodelist segment (see MAKe on page 21). If used, the DATa statement MUST follow all control statements except FILes.
The DATa statement actually causes MakeNL to shift gears. It has been processing control information. After the DATa statement, it begins processing nodelist data, which immediately follows it in your control file. The format and rules for this data are the same as for any nodelist data.
The first non-comment statement encountered must match the MAKe statement in <segment_type> and <number>, or a fatal error will occur.
If you receive segment updates from others, you must use the FILes statement to define the files you receive and process. If you furnish all the input data yourself, you will not use a FILes statement.
When used, the FILes statement MUST be the last control statement in the control file. It is followed by a list of file entry statements in the following format:
<segment_type> <number> <filename> [<notify>]<segment_type> is one of HUB, NETwork, REGion or ZONe, but it must be hierarchically lower than the MAKe <segment_type>. In other words, if MAKing a region segment, <segment_type> must be either NETwork or HUB -- it may not be REGion or higher.
<number> is, of course the network address number associated with the segment.
<filename> is used by MakeNL to search through the various directories for the file defining this segment. You and your submitter must agree on this filename. His MakeNL must generate what your MakeNL will look for. <filename> may be either explicit or generic, but it must be defined the same by both you and your submitter.
The first non-comment statement in an input segment file must match <segment_type> and <number>, or a fatal error occurs.
When you use notification, MakeNL will calculate a network address for notification messages. If you are MAKing a network segment for, say net 107, and receiving update segments from your Hubs, notification messages will be sent to 107/<number>. In all other cases, MakeNL sends notification messages to <number>/0 by default.
The optional argument <notify> is the network address MakeNL should use for notification messages and will override the calculated address.
Examples:
REGION 14 REGION14 14/61
NETWORK 100 NETWORK.100If you do not use archiving compression, MakeNL should execute satisfactorily in about 160 kilobytes. If you are using archiving, you should have about 290 kilobytes of memory. IF YOU ATTEMPT TO EXECUTE ARC WITH TOO LITTLE MEMORY, YOU MAY LOSE FILES!
MakeNL is not as extravagant with disk space as it sounds, but if you are a Regional or Zone Coordinator, you should do a little planning.
Your MASter directory will hold one copy of each .TXT comments file you use (plus backups if your editor creates them), one copy of each data file with an explicit name, two copies of each data file with a generic name, and, if you use it, one copy of your master input file. MakeNL automatically manages the data files in the MASter directory so that this is true. Obviously, there can only be one copy of a file with an explicit name in any directory. Generically named data files more that two weeks old are automatically deleted. (The most current file is always kept, no matter how old it is.)
Your OUTPath directory (usually the same as your MASter) will hold one copy of your output master file if it is explicitly named, and two copies if it is generically named. In addition, when MakeNL executes in process mode, it creates a temporary new output master file, and the OUTPath directory must have room to hold it. At least one of these copies (and occasionally two, if there were no changes) will be deleted before MakeNL attempts to do anything with or about your submittal file.
If your submittal file is to be compressed, the compressed copy will also be placed in the OUTPath directory. On completion, there will be only one submittal file, but if, for example, an archived diff file is being produced, there must be space enough for both until ARC completes. Then the diff file will be deleted.
It is conceivable (though most unlikely) that you could have a copy of each of your data files in each of the subdirectories UPLoads, MAIlfiles and UPDate. It is probable that by the end of each process cycle you will have at least one copy of at least half of these files in one of these directories. When a file is received in compressed form, MakeNL decompresses it in the directory that received it, and the compressed version is deleted. When files are moved from one directory to another on the same drive, they are moved by renaming them. No additional space is required for this operation.
"So how much !@#$%^ space do I need!?" If you are a Hub or network coordinator, not much. Here is a guide I would suggest for Regional or Zone coordinators. Make sure you have three times the space required for one set of your generically named files plus two times the space required for one set of your explicitly named files.
With experience, you'll get a better feel for how much space you need to operate MakeNL. Before cutting yourself too fine, remember that MakeNL needs some temporary working space while executing.
The MakeNL distribution package consists of the following files:
MAKENL.EXE The MakeNL program
MAKENL.PRN This documentation file
HUB.CTL Sample control file for Hub Coordinators
NET-S.CTL Sample control file for Network Coordinators
NET-L.CTL Sample control file for Network Coordinators
REGION.CTL Sample control file for Regional Coordinators
ZONE.CTL Sample control file for Zone Coordinators
DISTRIB.CTL Sample control file for Distribution Lists
CPYRIGHT.TXT Sample copyright notice
PROLOG.TXT Sample prologue file
EPILOG.TXT Sample epilogue file
FTS-0005.TXT Nodelist Format SpecificationsMakeNL is distributed under the "shareware" concept. It may be freely copied and distributed provided all the files listed in section 8 are included in the distribution. But MakeNL is NOT FREE.
If you are a non-commercial user of MakeNL, you are asked to support its development and maintenance both with your suggestions and bug reports and with your dollars. No particular fee is set for non-commercial use. Let your conscience be your guide.
Commercial users, and users participating in a commercial network are required to pay a license fee of twenty five (25) U. S. dollars for each computer on which MakeNL is installed for use.
The Coordinator of a commercial network may obtain a network license for a one-time fee of $1,500 US. This will license all current and future nodes of the network for the use of MakeNL. MakeNL and EditNL may be licensed as a set for a one-time fee of $2,250.
Please address all correspondence to:
Ben Baker
Baker & Associates
One Mark Twain Plaza, Ste 325G
Edwardsville, IL 62025
(618) 656-8850