home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / zpars106.zip / ZPARSE.DOC < prev    next >
Text File  |  1996-03-03  |  35KB  |  727 lines
  1.                                                                ZPARSE 1.05
  2.                                                                USER MANUAL
  3.                                                                Aug,1995.
  4.  
  5. Section 1: Introduction to Zparse
  6.         1.1     Description
  7.         1.2     Legal stuff
  8.         1.3     System Requirements
  9.         1.4     Advantages of Zparse
  10.         1.5     Contacting the Author
  11.  
  12. Section 2: Zdiff - the Zparse nodediff compiler
  13.         2.1     Use of Zdiff
  14.  
  15. Section 3: Zparse operation
  16.         3.1     Installing Zparse
  17.         3.2     Using Zparse
  18.         3.3     Points
  19.         3.4     Modem Translation
  20.  
  21. Section 4: Configuration statements.
  22.  
  23.                 ******          SECTION ONE             *******
  24.  
  25. 1.1    Description of Zparse
  26.  
  27.         Zparse is a nodelist compiler, producing the various files
  28. required for type 7 nodelist files, required by many of the
  29. popular mailers in use today. It produces the standard NODEX.DAT,
  30. NODEX.NDX and SYSOP.NDX files (or similar) from a single nodelist, or 
  31. from nodelists of multiple networks. Zparse does not create version 6
  32. nodelist files, nor any other format of nodelist compilation.
  33.         The features of Zparse are at the very least what sysops would expect
  34. of a fully-fledged nodelist compiler, and include:
  35.  
  36.         o       Multiple Network support
  37.         o       Modem translation logic
  38.         o       4D or 'fakenet' point support
  39.         o       Session Level Passwords
  40.         o       Fully configurable dial and cost translation
  41.         o       User-selectable inclusion/exclusion of Zones and Nets
  42.         o       Multiple AKA addresses
  43.         o       User-selectable Hubrouting options
  44.         o       greater optimization of index files
  45.         o       Incredible speed (See section 1.4)
  46.  
  47. Throughout this manual, it is assumed that the reader is somewhat
  48. literate in the ways of networking (mail sharing with other nodes and BBS
  49. systems), and possesses a functional knowledge of computer operation, and at
  50. least a rudimentary of the mechanics of mailers.   
  51.  
  52.         The development and optimization of Zparse is an ongoing process. New
  53. versions are available for FileRequest under the magic name of ZPBETA from
  54. the following sites, at all hours save Zone 1 ZMH (0900-1000 UTC)
  55.  
  56.  Fidonet  1:340/303(v.Everything) 
  57.           1:340/302(v.fc)
  58.  ibmNET  40:6481/1
  59.  
  60.  
  61. 1.2     Legal Stuff
  62.  
  63.                   S.C.S.Inc. License Agreement for Software Tools
  64.        -----------------------------------------------------------------
  65.  
  66.        IF YOU DOWNLOAD OR USE THIS PROGRAM YOU AGREE TO THESE TERMS.
  67.  
  68.         SpyderNet Communications Systems Incorporated grants you a license
  69. to use Zparse (hereafter termed "the Program") during its initial trial
  70. period. The Program is copyrighted and licensed (not sold). We do not
  71. transfer title to the Program to you. You obtain no rights other than
  72. those granted you under this license.
  73.  
  74.         Under this license, you may:
  75.  
  76.         1. use the Program on one or more machines at a time;
  77.         2. make copies of the Program for use or backup purposes within
  78.            your Enterprise;
  79.         3. make copies of the original file you downloaded and distribute
  80.            it, provided that you transfer a copy of this license to the
  81.            other party. The other party agrees to these terms by its
  82.            first use of the Program.
  83.  
  84.         You must reproduce the copyright notice and any other legend of
  85. ownership on each copy or partial copy, of the Program.
  86.  
  87.         You may NOT:
  88.  
  89.         1. sublicence, rent, lease, or assign the Program; and
  90.         2. reverse assemble, reverse compile, or otherwise translate the
  91.            Program.
  92.  
  93.        We do not warrant that the Program is free from claims by a third
  94. party of copyright, patent, trademark, trade secret, or any other
  95. intellectual property infringement.
  96.  
  97.        Under no circumstances are we liable for any of the following:
  98.  
  99.        1. third-party claims against you for losses or damages;
  100.        2. loss of, or damage to, your records or data; or
  101.        3. economic consequential damages (including lost profits or
  102.           savings) or incidental damages, even if we are informed of
  103.           their possibility.
  104.  
  105.        Some jurisdictions do not allow these limitations or exclusions, so
  106. they may not apply to you.
  107.  
  108.        We do not warrant uninterrupted or error free operation of the
  109. Program. We have no obligation to provide service, defect correction, or
  110. any maintenance for the Program. We have no obligation to supply any
  111. Program updates or enhancements to you even if such are or later become
  112. available.
  113.  
  114.        IF YOU DOWNLOAD OR USE THIS PROGRAM YOU AGREE TO THESE TERMS.
  115.  
  116.        THERE ARE NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING THE
  117.        IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
  118.        PARTICULAR PURPOSE.
  119.  
  120.        Some jurisdictions do not allow the exclusion of implied warranties,
  121. so the above exclusion may not apply to you.
  122.  
  123.        You may terminate this license at any time. We may terminate this     
  124. licence if you fail to comply with any of its terms. In either event, you
  125. must destroy all your copies of the Program.
  126.  
  127.        You are responsible for the payment of any taxes resulting from
  128. this license.
  129.  
  130.        You may not sell, transfer, assign, or subcontract any of your      
  131. rights or obligations under this license. Any attempt to do so is void.
  132.  
  133.        Neither of us may bring a legal action more than two years after      
  134. the cause of action arose.
  135.  
  136.        In Canada, this license is governed by the laws of the Province of       
  137. British Columbia. Otherwise, this license is governed by the laws of the
  138. country in which you acquired the Program.
  139.  
  140.  
  141. 1.3     System Requirements
  142.  
  143.         Zparse 1.05 is an OS/2 program, and has been tested under a variety
  144. of OS/2 2.xx and OS/2 Warp systems.  If your system can run either version
  145. 2.0, 2.1 2.11 or 3.0 (Warp) of OS/2, your system should be perfectly fine
  146. for Zparse. It is strongly suggested that at least 5-10 Megabytes of free
  147. hard drive space be available for nodediff processing, and for the
  148. creation of the *.DAT and *.NDX files. Minimum memory requirement is
  149. assumed to be 4Mb.
  150.         Zparse will recognize both FAT (File Allocation Table) and HPFS
  151. (High-Performance File System) types of hard-drive file storage. Zparse will
  152. run on either 386 or 486 processors - again, if your system can run OS/2, it
  153. can run Zparse.
  154.  
  155. 1.4     Advantages of Zparse.
  156.  
  157.         The main advantages of using Zparse over any other version 7
  158. nodelist compiler are configurability, and most of all  SPEED. Zparse
  159. radically reduces the time required to compile a nodelist. Its time to
  160. compile a full nodelist on a 386dx40, OS/2 3.0, 8Mb Ram, and a 13ms IDE
  161. drive on an HPFS partition is  a shade under 50 seconds: 42 to be 
  162. precise. Compare this with another common (yet un-named) OS/2 native
  163. nodelist utility that on the same machine and configuration took vastly
  164. longer - 8:49 to produce the same files. Note the following:
  165.  
  166. Directory of ZPARSE:
  167.  7-20-95   7:08p   3329680           0  nodelist.202
  168.  7-24-95   6:30p   2455078           0  NODEX.DAT
  169.  7-24-95   6:30p    587776           0  NODEX.NDX
  170.  7-24-95   6:31p    811008           0  SYSOP.NDX
  171.         Size of created files:  3,853,862 bytes
  172.  
  173. Directory of other utility:
  174.  7-20-95   7:08p   3329680           0  nodelist.202
  175.  7-24-95   6:26p   2455558           0  nodex.dat
  176.  7-24-95   6:26p    863744           0  nodex.ndx
  177.  7-24-95   6:26p   1102336           0  sysop.ndx
  178.         Size of created files: 4,421,638 bytes
  179.  
  180.         Note that there is a net difference of 567,776 bytes between the
  181. two results. The main difference lies in the two index files - the files
  182. your mailer and BBS software are most likely to use. Result: increased
  183. efficiency.
  184.  
  185. 1.5     Contacting the Author
  186.  
  187.         The author may be contacted through netmail to FidoNet address
  188. 1:340/303[v.Everything], or 1:340/302[v.Fc], or through IBMnet address
  189. 40:648/1.
  190.         Internet email to lwiddif@spydernet.com             
  191.         Inquiries through postal channels:
  192.                         S.C.S.Inc.
  193.                         Attn: Lionel Widdifield
  194.                         P.O. Box 8406
  195.                         Victoria B.C. V8W-3S1
  196.                         Canada
  197.    
  198.         If you have any comments about ZParse, I would like to hear them.
  199.  
  200.                 ******          SECTION TWO             *******
  201.            
  202. 2.1     Using Zdiff
  203.  
  204.         Given that the creation of a nodelist usually is accompanied with
  205. the arrival of a nodediff file a companion program to Zparse has been
  206. included in the Zparse archive for compiling nodediff files.
  207.         In order for Zdiff to run, the module Spectre0.DLL must either be
  208. in the current directory from which Zdiff is called, or in a directory
  209. specified a the "LIBPATH=." entry in your CONFIG.SYS.
  210.         The use of Zdiff is simple:
  211.  
  212.        zdiff [-v] <nodelist> <nodediff>
  213.  
  214.         Where <nodelist> is the path and filename (without extension) of
  215. the raw (unarchived) nodelist, and <nodediff> is the path and filename 
  216. (without extension) of the new (unarchived) nodediff file. At this time,
  217. Zparse does not handle the logic of de-archiving the inbound nodediff
  218. files - it is assumed that a few simple batchfile (*.CMD) or REXX scripts
  219. can achieve the same
  220. results.
  221.         If more than one valid nodediff file matching the filename stem 
  222. is found by Zdiff, then it shall appy all valid nodediffs to create a new
  223. nodelist.
  224.         Should a more detailed output of the Zdiff
  225. process be desired, the 
  226. optional -v (-Verbose) switch may be included at the command line.
  227.  
  228.                 ******          SECTION THREE            *******
  229.  
  230. 3.1     Installing Zparse
  231.  
  232.         In order to install Zparse, it is necessary only to de-archive the
  233. files where required. Configuring for use, however, shall take some time,
  234. and shall require a text editor.
  235.          Included with Zparse is a sample configuration file, ZPARSE.CFG,
  236. along with ZDIAL.CFG, ZPARSE.PTS, and ZPARSE.PWD. As they are sent, ZDIAL
  237. is a sample of a dial translation table, and will likely require editing
  238. with your favorite text editor to be suitable for your area. ZPARSE.PTS is
  239. a sample points file, and ZPARSE.PWD is a sample file for use of creating
  240. passwords for password-protected sessions.
  241.         Included with the archive is a DLL runtime module. This module
  242. (Spectre0.dll) must remain either in the directory from which Zparse is
  243. called, or be present on a path specified in the "LIBPATH=." environment
  244. variable. (Utility freaks may wish to create a separate dll-storage 
  245. directory and place it on their path for ease of use.)
  246.  
  247. 3.2     Using Zparse
  248.         
  249.         Zparse has the following command switch alternatives:
  250.         Switch          Function
  251.         -v              Display version information
  252.         -vc             Parse configuration file(s) for errors.
  253.         -C<file>        Use configuration file <file> where <file>
  254.                          is a full path and name.
  255.         -N<nodelist>    Use nodelist file specified in the path
  256.                          <nodelist>, but without the nodelist extention.
  257.                          (ie: Zparse -Nd:\nodelist\nodelist)
  258.  
  259.         Zparse invoked without the command switches produces a normal
  260. compile, and shall search the current directory for a configuation file,
  261. ZPARSE.CFG upon loading. If this file is not in the same directory as the
  262. Zparse executables, the program will terminate.
  263.         Zparse will exit on a successul compile with an errorlevel=0,
  264. allowing batchfiles and REXX scripts to catch processing errors by
  265. trapping non-zero errorlevel exits.
  266.         When Zparse begins running, it will display an information
  267. screen, and then proceed to display a running list of nodes its seeking. 
  268. Once it has read information, it shell begin compiling. At this point, 
  269. Zparse will begin writing to disk as it works on the indexes the screen
  270. with the lower "oooo" being an activity bar, (similar to LH32(os/2) or
  271. LHA(dos) de-archiving an LZH archive.) Here is an example of how the 
  272. screen looks as it nears the end of completion:
  273.  
  274. Working on: nodelist.202
  275. At: 6:760/0                     CRC Recorded:23197, Calc:23197
  276. Parsing Completed
  277. Compiling Indices...
  278. Building Indices
  279. ooooooooooooooo
  280.        
  281.  3.3     Points
  282.  
  283.         Zparse will handle points through standard 4D (z:xxx/yyy.ppp)
  284. addressing.  The simplest way to deal with this is to edit the points file
  285. included with Zparse to meet the specifications of your points. It is 
  286. assumed that very few persons actually run 'fakenet' points,  due to the
  287. fact that most mailer software nowadays handles 4D addressing: however, a
  288. way to gain fakenet addressing for points will be demonstrated. In any 
  289. case, these commands cannot appear in the main configuration file, but 
  290. must be retained in a seperate file noted by the POINTS verb.
  291.         The flavor of the a point inclusion statement runs along the following
  292. lines:
  293.  
  294. BOSS,1:124/567
  295. POINT,1,First_System,Location,User_Name,1-xxx-yyy-zzzz,9600,v32b,v42b,MO
  296. POINT,32,Next_System,Location,User_Name,1-zzz-yyy-xxxx,2400
  297.  
  298.         Note that all standard flags are supported.
  299.         
  300.         If the "NodesAllowed" verb is present in Zparse.cfg, this
  301. mechanism may also be used to include unlisted nodes in the compiled
  302. nodelist. In this manner, the "Boss" statement will cause the node
  303. z:xxx/yyy to be treated as the hub for the nodes listed afterwards.
  304.  
  305. Example:
  306.  
  307. Boss,1:123/567
  308. ,890,Name,Location,User,1-xxx-yyy-zzzz,9600,v32b,v42b,H14,CM,XA
  309. ,892,Next,Location,User_Name,1-zzz-xxx-yyyyy,2400,Mnp,MO
  310.  
  311.         This would create (if not in the nodelist) an entry for nodes
  312. 1:123/890 and 1:123/892. They would be treated as if they were nodes for
  313. which 1:123/567 was the hub of those nodes.
  314.  
  315.         A "fakenet" is required when dealing with older software that 
  316. doesn't understand the four-dimensional (Zone:Net/Node.Point) method of
  317. addressing. In this case, a fake 'nodelist' must be created, with a
  318. non-existent net entry, called a 'fakenet.'  The points are then treated
  319. as discrete nodes in that non-existent net. Mail handling software must 
  320. be set up to deal with the fakenet adequately, and given the problems 
  321. that this can pose, it is best to place the fakenet in the same zone as
  322. the boss entry in the nodelist. Thus, assuming a zone one boss:
  323.      
  324. Zone,1,North_America,Location,Name,9600,v32b,v42b,XA,CM
  325. Host,22222,Your_System,Location,Your_Name,9600,v32b,v42b,XA,CM
  326. POINT,1,First_System,Location,User_Name,1-xxx-yyy-zzzz,9600,v32b,v42b,MO
  327. POINT,32,Next_System,Location,User_Name,1-zzz-yyy-xxxx,2400
  328. ....
  329.  
  330.         Create this as a discrete file called, for example, "Fakelist.123",
  331. and then in ZParse.cfg, place an "addlist fakelist" statement. Points will
  332. then be treated as discrete nodes (1:22222/1, 1:22222/32) in the non-
  333. existent net 22222. Be aware, however, that the best way to deal with
  334. points is through 4D addressing.
  335.  
  336. 3.4     Modem Translation
  337.  
  338.         In order to explain exactly what modem translation is, and how to
  339. obtain it, it is probably simplest to explain why it was needed in the first
  340. place.
  341.         Way back when in the dark ages of modem technology, when most 
  342. systems were running on Apple ][ and Commodore 64 computers, modems came 
  343. in about four flavors: 115, 300, 1200, and 2400 bps. With the advent of 
  344. higher-speed modems, and different protocols, a number of problems arose,
  345. mostly with regards to the HST protocols produced in USR products (but 
  346. not restricted to them) that delivered high-speed connections. Many of 
  347. these early HST modems were 9600 HST, or 2400bps.
  348.         When, for example, an HST dual-standard (Either HST 14.4kbs or
  349. 14.4kbps v32b,v42b) modem was used to call out to another modem, it was
  350. important for the originator to know what modem was on the other end. If
  351. the receiving modem was an older HST, the best procedure was to call out
  352. with HST on. If this was not done, a 2400bps connection would likely
  353. result because the HST would not be able to negotiate a v32b, v42b 
  354. connection. If, however, the modem was not an HST device then it would 
  355. be best to call out and attempt to connect with v32b,v42b to gain the 
  356. full 14.4kbps connection.
  357.         With this in mind, a procedure was developed to take the nodelist
  358. flags and use them to determine what adjustments should be made to the 
  359. dialing strings in order to manipulate the modem to achieve the best 
  360. connection for what was available. The way to do this was to include for 
  361. some mailers (specifically binkleyterm) to read an additional byte in the
  362. nodelist indexes. This one byte, the modem  translation byte, is
  363. manipulated by the nodelist processor based on the flags of the nodelist
  364. - and then read by the mailer so that it can make user-defined
  365. adjustments.
  366.         The way the modem translation is done is to read the flags, and 
  367. select options based on the result. Generally speaking, one selects from 
  368. one of eight different options (one for each bit of the byte) and the 
  369. resultant byte is read by the mailer (usually binkleyterm.) The byte is 
  370. read as a sum of the decimal value of the bits - which is best explained 
  371. by the illustration below:
  372.  
  373.         [  0  .  1  .  2  .  3  .  4  .  5  .  6  .  7  ]    Bit
  374.         |  1  .  2  .  4  .  8  .  16 .  32 .  64 . 128]   Value (base2] 
  375.         
  376.         If bits 5 and 2 are set, the modem translation result is 32+4=36.
  377. Obviously, bits 1,2 and 3, if set, produce a result of 2+4+8=14.
  378.         Here, for example, is a binkleyterm configuration segment, 
  379. showing how the modemtrans statement is used to configure an 16.8kbps HST
  380. dual standard for optimal dialout based on the nature of the receiving 
  381. modem:
  382.  
  383. ;Modemtrans  #  Prefix/Suffix
  384. ModemTrans  15 ATDT/&M4B1        ; HST/v32b/{v42|MNP} 1+2+4+8
  385. ModemTrans  11 ATDT/&M4B1        ; HST/v32/{v42|MNP}  1+2+8
  386. ModemTrans  9  ATDT/&M4B1        ; HST/{v42|MNP}      1+8
  387. ModemTrans  1  ATDT/&M4B1        ; HST                1
  388. ModemTrans  14 ATDT/&M4B0        ; v32b/{v42|MNP}     2+4+8
  389. ModemTrans  10 ATDT/&M4B0        ; v32/{v42|MNP}      2+8
  390. ModemTrans  6  ATDT/&M4B0        ; {v32|v32b}         2+4
  391. ModemTrans  2  ATDT/&M4B0        ; v32                2
  392. ModemTrans  8  ATDT/&M4B0        ; {MNP|v42|v42b}     8
  393. ModemTrans  0  ATDT/&M0&N3B0     ; 2400 No {MNP|v42|v42b}
  394.  
  395.         The above can be obtained through Zparse by a series of modem
  396. translation commands, such as:
  397.  
  398. Modem   HST     1
  399. Modem   v32     2
  400. modem   v32b    2
  401. modem   v42b    3
  402. modem   v42     3
  403. modem   MNP     3
  404.  
  405.         In the above, the presence of any one of "MNP", "V42" or "V42b" 
  406. will set the third bit (decimal value = 8) to 1.
  407.  
  408.         With Zparse, the option remains to perform modem translation 
  409. either by manipulating the bits of the modem translation byte, or by 
  410. setting a decimal value for the byte. When setting decimal values, the
  411. desired decimal number must  proceeded with a number/pound (#) symbol, to
  412. denote the decimal-translation option. Note too that the translation is
  413. heirarchal - that is, Zparse will set the modem translation byte to the
  414. highest value  in the field, regardless of the order presented. Take the
  415. following example:
  416.  
  417. modem  v34    #34
  418. modem  vFC    #33
  419. modem  v32    #32
  420. Modem  H16    #30
  421. modem  H14    #30
  422. modem  v42b   #25
  423. modem  v42    #25
  424. modem  V32b   #20
  425. modem  V32    #20
  426. modem  ZYX    #25         ; V32b/V42b
  427.  
  428.         If an entry contains say ,CM,V32b,v42b,H16,V34,VFC, then Zparse
  429. will take the _first_ flag in the field, and compare it to the MODEM 
  430. statements. First off:
  431.         V32b seen, set to 20.
  432.         v42b seen, set to 25.
  433.         H16 seen, set to 30.
  434.         V34 seen, byte set to 34.
  435.         VFC seen - but is *after* the entry for V34, and therefore 
  436.                      remains unchanged.
  437.  
  438.         Using the modem translation logic in Zparse, (and binkley), a
  439. total of 256 combinations can be achieved. In practice, the number needed
  440. is usually far, far less.  Using the "Modemtrans" statement in
  441. Binkleyterm, it is now possible to alter the modem's configuration at the
  442. time of dialing to ensure that the modem is set to make the best possible
  443. connections. It  is, of course, beyond the scope of this document to
  444. provide example configurations for every possible modem. (It should be
  445. noted that one of the most useful applications for  the modemtrans
  446. statement is in the case of multiple mailers for a multi-node system,
  447. where the modems used by each are of different configurations.)
  448.  
  449.         As an aside - if your modem is a generic 14.4kbps 
  450. (9600,v32b,v42b), then you simply can comment out any and all MODEM 
  451. statements in the zparse.cfg, as your modem will make the best connect it
  452. can with what it finds on the other end.
  453.  
  454.                 ******          SECTION FOUR             *******
  455.  
  456. 4.1     Zparse Configuration File Statements.
  457.  
  458.         The heart of Zparse is its configuration file. The following is a
  459. list of all the possible statements in the Zparse.cfg, and the syntax for
  460. each.  While listed here in uppercase for convenience, all ZParse 
  461. configuration statements are case insensitive. A semicolon (;) is used 
  462. as a comment character: After a semicolon, Zparse will stop reading that 
  463. line, and proceed to the next.
  464.  
  465. ADDLIST <nodelist stem>
  466.         Instructs Zparse to include the nodelist specified by 
  467.         the path and filename <nodelist stem>. DO NOT INCLUDE FILENAME
  468.         EXTENSIONS. 
  469.         (Examples: for fidonet, the nodelist is called nodelist.xxx.
  470.         Including fido  would require:
  471.         ADDLIST c:\nodelist\NODELIST 
  472.         whereas with a net called "othernet" with a nodelist called
  473.         "nudder.212" the inclusion command would read
  474.         ADDLIST c:\othernet\NUDDER)
  475.  
  476. ADDRESS <Address>
  477.         Used to give a full 4D address of the system's addresses and 
  478.         AKAs. For each different AKA, a single ADDRESS statement is
  479.         used. (Example: ADDRESS 1:340/303.0)
  480.  
  481. ADDZONES <Zone>:<Net> [<Zone>:<Net> or <Zone>:]
  482.         Instructs Zparse to include the specified Zone(s) and Net(s) in 
  483.         processing, used in conjunction with a DEFAULT NOZONES statement
  484.         to produce a customized nodelist. (Examples:
  485.         ADDZONES 1:340          ;Create a list of net 1:340 only.
  486.         ADDZONES 2: 1:340       ;Create a list of zone 2, and net 1:340
  487.         ADDZONES 1:  2:          ;Create a list of Zones 1, and 2)
  488.  
  489. ALLSYSOPS
  490.         Placing this verb in Zparse.cfg will cause Zparse to create a 
  491.         file SYSOP.NDX, used by some readers such as TimEd, as well as by
  492.         some BBS message editors.
  493.  
  494. COST <national> <international>
  495.         This verb is obsolete, but included for backwards compatibility. 
  496.         It sets the default cost for national and international calls. It
  497.         has been replaced by the DEFAULT COST statement.
  498.         (Example:       Cost 50 150
  499.          Would set national calls at cost=50, international at cost=150.)
  500.  
  501. COUNTRY <code>
  502.         Sets the Country code for your area. This is the prefix set in 
  503.         your nodelist entry. It is usually either 1- (North America) or
  504.         11- (Europe). It is important to note the hyphen, as 
  505.         this statement is used to strip the long-distance codes from
  506.         numbers local to your system.
  507.         (Example, for Canada/US: COUNTRY 1-)
  508.  
  509. DEFAULT NOZONES
  510.         Instructs Zparse to not process any Zones or Nets. Used in 
  511.         conjunction with the ADDZONES command to produce a partial index
  512.         of a nodelist.
  513.  
  514. DEFAULT COST [NATIONAL/INTL] <cost> <fee>
  515.         Sets the cost/fee of a call. The first field must be either 
  516.         "National" or "Intl." (without quotes) The cost field is usually 
  517.         some approximation of the per-minute cost of the call, and is 
  518.         used to configure events so that direct mail is delivered at the
  519.         time of the least-expensive rates. (In conjunction with local 
  520.         dial translations to set local calls to Zero costs. See "DIAL"
  521.         verb for more. The <FEE> field is an arbitrary accounting number 
  522.         usually used to deduct <fee> from a user's BBS Credits.
  523.         (Example: Default Cost National 50 20, sets 'cost' at 50, and 
  524.         sets any non-local national call to deduct 20 units from a BBS
  525.         call, if the BBS software is set up to perform this task.)
  526.  
  527. DELZONES <Zone>:<net> [<Zone>:<Net> or <Zone>:]
  528.         Instructs Zparse not to include the specified Zones/nets in 
  529.         processing. (Examples:
  530.         DELZONES 6:             ;Do not include Zone 6
  531.         DELZONES 1:3404         ;Do not include Net 1:3404
  532.         DELZONES 2: 3: 1:3404   ;Do not include 1:3404 or Zones 2 and 3.)
  533.  
  534. DIAL <Prefix>/<Suffix> <Prefix>/<Suffix>
  535.         The DIAL verb begins the dialing and cost translation table, 
  536.         which then continues until an END verb is encountered. The first
  537.         entry of the dialing table contains the modifications to be made
  538.         to domestic and then international calls. The backslashes are NOT
  539.         optional. If no modifications are to be done to either prefix or
  540.         suffix, leave the entries blank. For Zone one entries, the
  541.         domestic prefix need not be modified, so the table would begin 
  542.         as: (Example:
  543.               ;domestic   international
  544.         DIAL    /       011-/          ;  )
  545.         
  546.         The above creates a 011- prefix for all international calls. This
  547.         is linked to the COUNTRY statement, which sets what prefix is
  548.         'domestic'.
  549.         
  550.         The rest of the dialing table follows the general syntax
  551.         <pattern> [Prefix]/[Suffix] <Callcost> <Fee>
  552.         <pattern> is the portion of the phone number string to be 
  553.         modified, [Prefix] is the (optional) prefix to be used, [Suffix]
  554.         the optional suffix.  If The backslash (/) is omitted, then the 
  555.         entry shall be treated as a definition of cost/fee. <callcost> is
  556.         the cost assessed to a call made by the mailer, <fee> the number
  557.         to be deducted from BBS user's netmail credits.
  558.          (Example:
  559.                 1-604-360-      360-/   0       0       ;Local
  560.                 1-604-         1-604-/  20      20      ;Regional.
  561.                 1-                    1-/  50      20      ;Non-regional
  562.                 1-800                      0        0       ;Tollfree)
  563.  
  564.         Please see the included dialing translation table for more of an 
  565.         idea of the logic used. Also see DEFAULT COST statement for the 
  566.         setting of default costs and fees for national and international
  567.         calls. 
  568.  
  569. END
  570.         Terminates the dial translation table. (See: DIAL]
  571.  
  572. HUBMODE <n>
  573.         Configures the nature in which Zparse will handle nodes for which
  574.         there is no number (unpublished, private, etc.)  Zparse goes to
  575.         great lengths to determine a hub for such 'undialable' nodes,
  576.         assuming that applicable local hubs will be able to deliver their
  577.         mail. <n> is either 0, 1, or 2. They configure the following:
  578.                 0: Attempt to find hub for "undialable" systems. 
  579.                 1: "Undialable" numbers shall be hub-routed, UNLESS they 
  580.                    are in the same net as specified in an "ADDRESS"
  581.                    statement. This allows for routing to other 
  582.                    non-hub systems serving to deliver mail, or for
  583.                    insertion of a phone number through the PHONE
  584.                    statement.
  585.                 2: Disables all-remapping of undialables.            
  586.         (Example:  HUBMODE 1)
  587.  
  588. INCLUDE <Filename>
  589.         Instructs Zparse to also use the filename specified by 
  590.         <filename>, where <filename> is a fully qualified path and name 
  591.         of a text-file. This file cannot contain anything other than
  592.         Zparse-readable configuation verbs or comment delimiters (;).
  593.         INCLUDE statements are useful for keeping password files, or 
  594.         dialing tables in a discrete file for easier editing.
  595.         (Example: INCLUDE d:\zparse\password.txt)
  596.  
  597. INTERNAL N<number>
  598.         WARNING: Be careful with this statement. It over-rides the 
  599.         default Zparse process table size. Currently, the internal 
  600.         size defaults to 45000. The statement is included so as to enable
  601.         compilation of multiple nodelists, or for compilation of larger
  602.         nodelists than currently available.  IF this number is set to TOO
  603.         great a number, it will access available memory - which could 
  604.         also be virtual memory.   Setting a statement like "Internal
  605.         N1000000" could (would) allocate wadloads of memory depending on
  606.         the nature of the nodelist entries, Therefore, use this command
  607.         with some caution. At time of writing, there are but 35,000
  608.         nodes in  fidonet. Even if this doubles, a buffer setting of
  609.         "internal N70000" is sufficient. It is wise not to include this
  610.         statement unless certain it is required. 
  611.         (Example:  INTERNAL N55000)
  612.  
  613. LOGFILE <pathname\filename>
  614.         Sets the location and name of the Zparse activity log.
  615.         (Example: LOGFILE c:\logs\zparse.log)
  616.  
  617. MAXBAUD <baud>
  618.         Set this to the maximum speed of your modem, as per your nodelist
  619.         entry. (Current Fido nodelists still use the archaic 9600bps for 
  620.         every modem that is above 2400/mnp5.)
  621.         (Example: MAXBAUD 9600)
  622.  
  623. MINCOST <Speed> <Cost>
  624.         Sets a minimum cost <cost) for connections of a given connect 
  625.         speed <Speed.> Thus, (Example: MINCOST 2400 20) would set a cost
  626.         of a 2400 bps connection at a minimum of 20, overriding any lower
  627.         cost setting commands.
  628.  
  629. MODEM <flag> <bit> (<bit>,...)
  630.         Sets the modem translation byte depending on the flags of the 
  631.         nodelist entry. (See section 3.4 for an explanation of modem
  632.         translation.) The <flag> is the field in the nodelist flags to 
  633.         search for, the <bit> is the bit that shall be set high if that
  634.         flag is present. More than one bit may be set high per entry.
  635.         (Example: MODEM HST 1)
  636.  
  637. MODEM <flag> # <decimal>
  638.         Sets the modem translation byte to the decimal value specified in 
  639.         <decimal> if the nodelist entry contains the field <flag>. Note 
  640.         that unlike setting the bits, decimal entries are heirarchal: 
  641.         the result of the modemtrans byte will depend upon the order 
  642.         listed in the config file with the first entries overiding those 
  643.         listed after.
  644.  
  645. MODEM$ <type> <cost> <newtype> <newcost>
  646.         Alters a modem's type (see MODEM command) and cost to <newtype> 
  647.         and <newcost>. Will replace any node that matches both <type> and
  648.         <cost> and replace the entry with <newtype> and <newcost> for 
  649.         that node.  This is primarily of use for multi-node systems, with
  650.         different modems on each mailer. Local calls (with <cost>=0) 
  651.         could have the modem type (ie: the modem translation byte) 
  652.         modified so as to allow connections from a less-efficient modem, 
  653.         such as, for example, an HST 14.4kbps connect instead of a Vfc
  654.         connect: Since the cost is zero.....
  655.         [Example: MODEM$ 14 0 10 0)
  656.  
  657. NODESALLOWED
  658.         This allows full-fledged node entries to be created as nodes under
  659.         a specific hub, usually in a secondary pointslist. (See section 
  660.         3.3 for a specific example of how this actually done.)
  661.  
  662. NOREDIR
  663.         Identical to including the configuation statement HUBMODE 2.
  664.         Disables re-direction of unpublished/private nodes through hubs.
  665.  
  666. OVERRIDE <address> <cost> [<Fee> <modemtype>]]
  667.         Used to over-ride the cost, or modem translation byte of a 
  668.         specific node. Here, <address> is the address of the 
  669.         nodelist entry to be modified. <cost> is the call cost to used by
  670.         the mailer. <fee> is the fee to be used by the BBS (for netmail
  671.         credits), and <modemtype> sets the modemtype to be used for this
  672.         node.  (Examples: 
  673.         OVERRIDE 1:234/444 57
  674.         OVERRIDE 1:340/303 0 0 12)
  675.  
  676. PASSWORD <Address><Password>
  677.         This is an alternate way of creating session-level passwords, 
  678.         included for compatibility. <Address> is a full 4D network 
  679.         address, and <password> is the password to be applied to that 
  680.         number. 
  681.         (Example: PASSWORD 1:23/456 MyPass) 
  682.  
  683. PHONE <Address> <number>
  684.         Allows one to change/insert phone number data for a specific 
  685.         node.  <Address> is a full 4D node, where <number> is the full, 
  686.         untranslated number to be inserted for that node.  Zparse will 
  687.         strip any required prefixes for <number> based on the dialing
  688.         translation tables. [Example: 1:234/45 1-234-555-6666]
  689.  
  690. POINTS <filename>
  691.         Specifies a point list format file to be included for processing.
  692.         This may only be used for points, or (as outlined in section 3.3)
  693.         to include nodes not listed in the nodelist.  (Example:
  694.         POINTS ZPARSE.PTS)
  695.  
  696. SET <Address>,<Password>,<Phone>,<speed>,<flags>[,<flag2>,<flag3>,...]
  697.         Used to alter nodelist entries, or to establish passwords for use
  698.         in session-level password protection. (Password sets may also be
  699.         used with the PASSWORD verb.) It is useful for giving phone 
  700.         numbers to -unlisted- entries, and so on. The commas are NOT 
  701.         optional, but need not be placed if no data is following. 
  702.         (Examples:
  703.         SET 1:234/567,Mypassword
  704.         SET 1:234/56,,1-235-234-4567
  705.         SET 1:234/5,,,,VFC,CM)
  706.  
  707. STRIPDASH
  708.         Removes dashes (-) from phone numbers. This is primarily
  709.         for those whose modems/mailers may not handle the dash properly. 
  710.  
  711. USERFLAGS
  712.         Instructs Zparse to process user flags (usually following
  713.         standard nodelist flags) as modem flags.  This is useful
  714.         in situations where modem flags are not yet 'approved', yet user
  715.         flags can be used for better determination of connections. Using 
  716.         this verb will only instruct Zparse to search for user flags. 
  717.         Thus, a match could be made against a UVFC flag, providing that a
  718.         MODEM statement (for example) specified an action for a UVFC flag
  719.         if found.
  720.  
  721.  
  722. VERSION7
  723.         Included for future compatibility. Commenting this verb out will
  724.         have no effect.
  725.  
  726. 
  727.