Beijing Paradise BBS Backup

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

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / ROMPR134.ZIP / ROMPROC.DOC < prev next >

Wrap

Text File | 1993-09-18 | 31.0 KB | 663 lines

┌────┐ │──═─│ │ ── │ ─────┐ ┌────┐ ROMProc Documentation Fil │ │ ROMProc │──═─│ Version 1.34 │ │ └────> │ ── │ (c) Copyright 1993 - Stacy Smith │ │ │ │ │ │ │ │ ─┴────┴─ ─┴────┴─ Courtesy of: The Bloom Beacon-Picayune BBS Node 1: (919) 557-3845 (USRobotics Courier Dual Standard) Node 2: (919) 557-0645 (USRobotics Courier V.32bis) Node 3: (919) 557-0745 (USRobotics Courier V.32bis) FidoNet 1:151/106 Intelec RoseNet (ID: BB-P) CompuLink Stacy Smith 305 Cottonwood Lane Holly Springs, NC 27540 ┌────────────────────┐ │ 1. Introduction: │ └────────────────────┘ ROMProc is a BBS download file preprocessor designed to make optimal use of CD-ROM and/or LAN BBS setups by copying the desired file(s) from the source drive into a work directory, commenting them, transferring them to the remote user with the desired protocol and cleaning up. ROMProc is different from other programs in which it performs all these functions automatically from a single program command line. By commenting files just prior to download, rather than commenting them when posted, you can save disk space and your files will always have up-to-date comments inserted. By stripping the comments from 200 megs of ZIP files on my system, I regained about 2 megs of disk space! ROMProc was developed primarily because I didn't like the current crop of CD-ROM and server file handlers. They were either complicated to install, didn't perform as desired, were designed as doors, memory hogs, ridiculously expensive or crippled. ┌───────────────────────────┐ │ 2. Features of ROMProc: │ └───────────────────────────┘ ∙ Handles the complete download process from a single command-line. ∙ Functions with any protocol, including single, batch and bi-directional protocols. ∙ May be installed in your BBS software as a batch file or a direct command-line. ∙ Automatically identifies ARC, ARJ, HYP, LZH, PAK, SQZ, ZIP and ZOO files, regardless of their file extensions (ideal for software distribution networks, like .SDN files), allowing commenting of these archivers that support archive comments (not all do). ∙ Automatically identifies ARJ, LZH, PAK, SQZ and ZIP self-extracting (SFX) archives. ∙ Comments all files prior to downloading, if desired. ∙ May be configured to insert a BBS ad file to the archives (ugh). ∙ Fully multinode compatible. ∙ Organizes the processing order to ensure sequential drive access. ∙ Locks slow drives to prevent drive thrashing due to multiple node accesses to the same physical drive. ∙ Outputs sysop-configurable prompts to the user for indication of process status. ROMProc supports IRQs 2-7 with any base address as well as FOSSIL drivers. ∙ Windowed full-screen interface. ∙ User-selectable disk error logging. ∙ Not crippled. ∙ Returns the errorlevel of the transfer protocol, making ROMProc completely transparent to the BBS software. ∙ Written completely in C for optimal speed, using Borland C++ 3.1. ∙ Lifetime registration; pay ONCE and your registration number will work on all future versions! ┌─────────────────────────────────────────────────────────┐ │ 3. Files Included in the ROMProc Distribution Archive │ └─────────────────────────────────────────────────────────┘ ROMPROC.EXE CD-ROM Download File Processor program ROMPROC.CFG Sample configuration file ROMPROC.DOC This file HISTORY.TXT ROMProc revision history in reverse order REGISTER.FRM Registration form for ROMProc COMMENT.TXT Sample comment file for inclusion in archives FILE_ID.DIZ Internal description file When you unzip the distribution archive, you should see my PKZIP authenticity verification stamp, and a '-AV' after every file in the archive: # SSU301 The Bloom Beacon-Picayune BBS If there are any files missing or added, or the -AV stamp is missing, the archive has been tampered with. It would be advisable to call my BBS (listed at the top of this document) for the latest version of ROMProc. ┌───────────────────────────┐ │ 4. Program Requirements │ └───────────────────────────┘ To the best of my knowledge, ROMProc will run on most any machine capable of running a BBS package. My BBS setup is PCBoard 15.0/10 beta running under DESQview on a LANtastic 5.00 network with 1 hard drive and 2 CD-ROMs, but other sysops that I have been in contact with have successfully implemented ROMProc on a wide variety of hardware. ROMProc requires DOS 3.x or later, as it uses DOS SHARE-compatible file reads and writes. ROMProc's memory requirements are very small (about 80K, plus whatever memory is required to invoke the transfer protocols), therefore it can be run in very low memory situations. ROMProc has been developed and tested using the following archiving and transfer protocols: ARJ 2.10 through 2.41 (by Robert Jung) LHA 2.13 (by Haruyasu Yoshizaki) PKZIP 1.10 through 2.04g (by PKWare) SQZ 1.08.2 (by Jonas Hammarberg) DSZ [various dates] (by Omen Technology) HS/Link 1.12 through 1.21B6 (by Sam Smith) ┌───────────────────┐ │ 5. Registration │ └───────────────────┘ ROMProc is not free; nor is ROMProc is crippled to force registration. ROMProc is fully functional, and will always remain so. The only variation with the registered copies is no time delay and beg message, and unregistered copies display the following to the user online at the beginning of execution: [ ROMProc 1.32 - Unregistered ] Why register? Besides a clean conscience, you will get a registration code that will work for all future versions of ROMProc, and will remove the delay and message displayed upon closing the door. The registration fee for your unique code is $10 for non-commercial BBSs (not too bad, eh?). The registration fee for commercial BBSs, defined if you run your BBS in the course of a commercial business or for profit, is $20. Other variations are available; refer to the file REGISTER.FRM for all registration options. Please print the file REGISTER.FRM and fill it out. You can print out the form by issuing the following command from the DOS prompt: TYPE REGISTER.FRM > PRN ┌───────────────────────────────────────┐ │ 6. License, Warranty and Disclaimer │ └───────────────────────────────────────┘ I'll keep this part short and sweet, and dispense with the legal-ese: License: You are allowed to use ROMProc for 30 days, after which you must either register ROMProc or stop using it completely. ROMProc registration is a license for your use of ROMProc; I retain ownership of the software. A single registration applies to a single BBS system, regardless of the number of computers used in the system. If you run two or more distinct BBS systems on the same computer(s) (with different names), you require two or more ROMProc registrations. Refer to the registration form for the currect pricing structure. Warranty: There isn't one. The only thing I'll guarantee is that ROMProc will take up disk space, and will disappear when deleted. Disclaimer: I'm not responsible for anything bad that happens. ROMProc works here, but I cannot be held responsible for it not working on your computer or doing any damage to hardware or software. If these aren't agreeable with you, then the best thing to do is delete ROMProc right now. I'll do my best to help any user (registered or not) that wants to use ROMProc, and I'll act on bug reports quickly, but I simply cannot and will not be responsible for anything bad, like lost data, disk crashes, or whatever else you can think of. ┌───────────────────┐ │ 7. Installation │ └───────────────────┘ GENERAL INSTALLATION: ───────────────────── Make a subdirectory on your hard drive. For the purposes of this document, we'll call it "C:\ROMPROC". Unarchive the ROMProc distribution archive into this subdirectory. You've more than likely already made it this far, if you're reading this file. <grin> The ROMProc system opens a few files simultaneously for various reasons. I would recommend that you have a minimum of FILES=30 per node in your system CONFIG.SYS file for a single-node system, since ROMProc is run in conjunction with your BBS software. If you are running under a network or a multitasking operating system, you should already have DOS's SHARE.EXE loaded. You must have SHARE loaded in order to take advantage of the file sharing and locking methods used by the ROMProc program to prevent data loss. (If you are running a single-node system without a multitasker, SHARE is not needed). Edit the configuration file to suit your needs. Proper configuration will require you to refer to this section, the previous section and the section titled "Configuration", which has an in-depth explanation of each configuration parameter and its function. Note that for the ROMProc program, you can obtain a limited program syntax screen simply by executing the program name "ROMPROC". GENERIC INSTALLATION INTO YOUR BBS SOFTWARE: ──────────────────────────────────────────── The premise behind ROMProc is that instead of invoking your transfer protocol as usual when sending files to remote, you invoke ROMProc instead. ROMProc will copy all files the remote user requested, process them as configured and invoke the desired protocol. Note that only the sending (remote download) protocol is changed; the receiving (remote upload) procotol is not changed. Upon completion of the transfer, ROMProc will return the errorlevel returned by the protocol, ensuring ROMProc's transparency to the BBS software. ROMProc must be run from the BBS node subdirectory; this is required to prevent conflicts when multiple copies of ROMProc are run simultaneously. At the bare minimum, three command-line parameters are required for ROMProc: c:\romproc\romproc -Cc:\romproc\romproc.cfg -Ffile.ext -Tz where -C defines the full path and filename of the configuration file for ROMProc and -F is the complete path and filename of the file (or batch list file) to be sent to remote; this parameter is almost always passed by the BBS software. Also, the required -T parameter defines to ROMProc which protocol to invoke by letter. When run in a multinode environment, you must also pass the BBS node number (via the -N command-line switch) to prevent collisions during simultaneous downloads (if no node number is defined, 0 is used by default): c:\romproc\romproc -Cc:\romproc\romproc.cfg -Ffile.ext -Tz -N2 In many installations, the node number is or can be defined as an environment variable. For example, PCBoard sysops use the environment variable PCBNODE to use in batch files for external utilities. c:\romproc\romproc -Cc:\romproc\romproc.cfg -Ffile.ext -Tz -N%PCBNODE% All BBS software passes the port number and computer-to-modem speed (DTE), and many also pass modem-to-modem carrier speed (DCE). These are passed on to ROMProc via the -P, -S and -E command-line switches, respectively. BBS software that supports bi-directional protocols will also pass the upload directory for the protocol to place any unexpected uploads from remote. This is passed to ROMProc using the -U command-line switch. * NOTE: In order for ROMProc to send status information to the online user, you MUST define the -P and -S parameters for direct I/O, or the -X parameter for FOSSIL I/O. (For direct I/O, the -P may be omitted from the command line in favor of the DSZPORT environment variable). * NOTE: If you are using a non-standard COM port for direct I/O, define the COM port IRQ and base address on the command line. For example, if COM3 (a non-standard port for IBM PCs) is used with 3e8 is the base address and 5 is the assigned IRQ, the -P parameter would be "-P3e8,5" (no quotes). * NOTE: For FOSSIL I/O implementations, the FOSSIL port parameter (-X) must be specified instead of the COM port parameter (-P). Most of the switches are self-explanatory. To be safe, if your BBS system is capable of passing a parameter, pass it on to ROMProc using the appropriate command-line switch. It can't hurt... PCBOARD INSTALLATION: ───────────────────── Installation in PCBoard is very easy. PCBoard uses two batch files for each protocol, named PCBR?.BAT and PCBS?.BAT, where ? is the protocol letter. The PCBR?.BAT (receive) batch files do not need to be changed for ROMProc, however, the PCBS?.BAT batch file does. Below are sample Zmodem and HS/Link send (and receive, for reference) batch files from my multinode system: PCBSZ.BAT: @Echo off if exist pcberr.fil del pcberr.fil if exist pcbdsz.log del pcbdsz.log c:\romproc\romproc -Cc:\romproc\romproc.cfg -Tz -N%PCBNODE% -F%3 -P%1 -S%2 -E%5 PCBRZ.BAT: @Echo off if exist pcberr.fil del pcberr.fil if exist pcbdsz.log del pcbdsz.log dsz port %1 speed %2 ha cts est 0 %5 pB4096 pr1 rz %3 PCBSH.BAT: @Echo off if exist pcberr.fil del pcberr.fil if exist pcbdsz.log del pcbdsz.log c:\romproc\romproc -Cc:\romproc\romproc.cfg -Th -N%PCBNODE% -F%3 -P%1 -S%2 -E%5 -U%6 PCBRH.BAT: @Echo off if exist pcberr.fil del pcberr.fil if exist pcbdsz.log del pcbdsz.log hslink -b%2 -p%1 -e%5 -u%6 -noc:\pcb\gen\dlpath.lst With the exception of the -T parameter, all of your PCBS?.BAT files should be identical; change the -T parameter to reflect the appropriate protocol letter. For bi-directional protocols, such as HS/Link and BiModem, add the -U%6 command switch. If you wish full implementation of ROMProc, all protocols have to be shelled instead of using the internal Xmodem and Ymodem protocols. Fortunately, DSZ is capable of all variations of Xmodem and Ymodem as well as Zmodem. The following is a screen snapshot of my PCBPROT.DAT file from PCBSETUP, with all protocols running through ROMProc: Port Lock Use Type Size MNP Open Lines Protocol Description ═══ ════ ════ ═══ ════ ═════ ═══════════════════════════════════════ A I 128 N N N ASCII (text files only) X S 128 N N Y Xmodem C S 128 N N Y Xmodem-CRC O S 1024 N N Y 1K-Xmodem F S 1024 Y N Y 1K-Xmodem/G Y D 1024 N N Y Ymodem [Batch] G D 1024 Y N Y Ymodem/G [Batch] Z D 1024 N N Y Zmodem [Batch] M D 1024 N N Y Zmodem MobyTurbo [Batch] H B 2048 N N Y HS/Link (bi-directional) [Batch] N I 0 N N N None (ask each transfer) Note the type for the Xmodem and Ymodem transfer protocols is now (S)helled or (D)SZLOG batch, instead of (I)nternal. OTHER BBS INSTALLATION: ─────────────────────── * NOTE: As my BBS is PCBoard, I have written the PCBoard-specific instructions. I would greatly appreciate some feedback from other BBS software users regarding ROMProc installation specifics. APPLICATION NOTES: ────────────────── PKZIP: PKZIP 2.04 uses direct-video output by default that will make the processing window look rather ugly when executed. To remedy this, set the PKNOFASTCHAR environment variable which will revert PKZIP 2.04 to the older 1.10-style video output. (It doesn't matter what your set the variable to, PKZIP just looks for its existence). SQZ: SQZ also uses direct-video output, but unlike PKZIP 2.04, it cannot be defeated. The processing window may look odd, but rest assured it is operating correctly. DSZ: In many cases, the use of DSZPORT environment variable is more desirable than passing the COM port information. This allows easier definition of non-standard COM ports addresses. For example, if you are using COM2 for a BBS node, add: SET DSZPORT=2 to your node batch file. If you are running a non-standard COM port, define the base address and IRQ on the command line. For example, if COM3 (a non-standard port for IBM PCs) is used with 3e8 is the base address and 5 is the assigned IRQ, the setting would be: SET DSZPORT=3e8,5 If you elect to use the DSZPORT environment variable, it is no longer necessary to pass the -P command-line switch or to add the "port @PORT@" parameter to the DSZ command lines for Xmodem, Ymodem, and Zmodem transfers in the ROMProc configuration file. In addition, ROMProc will search the environment for the DSZPORT variable and use it for the com port definitions for it's user status output. HS/Link: The HS/Link command-line can include the -NF switch to turn off HS/Link's full-screen display, allowing it to run in ROMProc's transfer protocol window. Otherwise, ROMProc's local display will be overwritten by HS/Link's display. ┌────────────────────┐ │ 8. Configuration │ └────────────────────┘ The sample configuration file included in the distribution archive is heavily commented, but some additional information is provided below: GENERAL PARAMETERS: ─────────────────── REG_CODE The registration code EXACTLY as provided to you on your registration letter. If this is an unregistered version, comment out this line. Note that this is case-sensitive, as the serial number, BBS name and sysop name are all encrypted into this code. BBS_NAME The BBS name EXACTLY as provided to you on your registration letter. If this is an unregistered version, comment out this lines. Note that this is case-sensitive! SYSOP_NAME The sysop name EXACTLY as provided to you on your registration letter. If this is an unregistered version, comment out this line. You get the picture by now... WORK_DIR The full path for the specific subdirectory for ROMProc to store file(s) to be downloaded. This must include the trailing backslash (ROMProc will add it if necessary)! If this directory does not exist at runtime, ROMProc will attempt to create it. This can be set to a RAM disk for greater speed, since ROMProc will detect an out of disk space condition and allow the download to continue from the original file. An environment variable may also be entered using the standard %VARIABLE% notation DOS uses; note that the environment variable definition must adhere to the same requirements as specifying a work directory. For example, the following are both valid: WORK_DIR c:\work\ WORK_DIR %TEMP% where %TEMP% is defined as "c:\work\" in your AUTOEXEC.BAT file. DISK_BUFFER The size of the disk I/O buffer you wish to allocate in bytes (valid values are between 2048 bytes and 16384 bytes). Optimal performance is obtained with a value that is a multiple of 2048 bytes, since this is the size of a typical hard disk cluster. 4096 seems to be a good number for me, although a larger size will improve performance somewhat. If you find yourself running out of memory when executing archivers or protocols, reduce this number to increase your available memory. If no value is specified, the disk buffer will default to 4096 bytes. LOG_FILE The complete path and filename of the log file for ROMProc to record errors. Comment the line out if you don't want any disk error logging. LOCK_LINES If you want ROMProc to preserve two lines at the top or bottom of the local display, enter TOP or BOTTOM as desired, otherwise, enter NONE or comment the line out. BBS_AD_FILE The directory path and filename for your BBS ad to be inserted into each and every archive processed by ROMProc. Note that you must provide a path, or it will not be copied. I STRONGLY recommend against them; BBS ads are aggravating to other sysops, so please be considerate and use the archive comment instead. BBS ad files are the scourge of the BBS world. This parameter is commented out by default. COMMENT_ARC If you want ROMProc to comment archives (if supported by the archive format) enter YES. If not, enter NO or comment the line out. This is much more desirable than inserting BBS ads. DRIVE PROCESSING DEFINITIONS: ───────────────────────────── PROC_DRIVE Specify the drive letters for file preprocessing (BBS ad insertion and/or commenting). Any file requested from a non-specified drive will still be tranmitted (unmodified) from the original location. This allows preprocessing of certain drives (e.g. CD-ROMs), but not all. Drives may be specified in ranges, seperated by a hyphen, and/or individual drives may be seperated by spaces, commas or semi-colons. The following examples are all valid, and will select drives letters C through J: PROC_DRIVE C-J PROC_DRIVE C D E F G H I J PROC_DRIVE C-F G H-J PROC_DRIVE C-F,G-I,J LOCK_DRIVE Specify the drive letters for locking, by entering the individual drives to be locked, one physical drive per line. Ranges may be seperated by a hyphen, and/or individual drives may be seperated by spaces, commas or semi-colons. Note that you normally lock by physical drive; if you have multiple logical drives per physical drive (e.g. a partitioned hard disk or CD-ROM changer), list all the logical drive letters on the same LOCK_DRIVE command line. Each LOCK_DRIVE line constitutes a single drive unit as far as ROMProc is concerned. It is not required that all drives defined to be processed be locked. In this example, drive D will be locked if accessed by ROMProc and drives E-J will be locked if ROMProc accesses any drive from E to J. LOCK_DRIVE D LOCK_DRIVE E-J DELAY_TIME This is the amount of time (in seconds) that ROMProc will wait for a drive to unlock before displaying the text indicated by DELAY_PROMPT. I would recommend a value of 5 to 10 seconds. If commented out, ROMProc will default to 5 seconds. ABORT_TIME This is the amount of time (in seconds) that ROMProc will wait for a drive to unlock. If this time is exceeded, ROMProc will abort the transfer. I suggest that at least 10 seconds be given, more if you are using CD-ROM changers and/or slow networks. If commented out, it will default to 30 seconds. COMMUNICATION DEFINITIONS: ────────────────────────── COMM_IO If you want ROMProc to output status information to the user on-line, enter YES; if you do not want ROMProc to output information, enter NO or comment the line out. Note that the -P and -S command line switches must be passed for user status information to be generated by ROMProc. The output looks similar to the following, depending upon the prompts selected: Please wait while preparing your files for download... FILE1.ZIP... FILE2.ZIP... [ etc. ] Preparation complete. Begin your download now... PROC_PROMPT This line of text will be displayed to the user upon the start of download file processing. It should be used to inform the user that it may take a few moments to get the files ready. If more than a 80 character message is desired, an external ASCII text file may be defined by setting this parameter to a filespec preceeded by a '%' character. For example: PROC_PROMPT %c:\romproc\prompt.txt DL_PROMPT This line of text will be displayed to the user upon the start of the transfer protocol. It should be used to inform the user to start the download on their end. If more than a 80 character message is desired, an external ASCII text file may be defined by setting this parameter to a filespec preceeded by a '%' character. DELAY_PROMPT This line of text will be displayed to the user if ROMProc waits for a locked drive to unlock for the specified amount of time defined by DELAY_TIME. An ASCII text file may also be defined for this parameter. ABORT_PROMPT This text will be displayed to the user if ROMProc waits for a locked drive to unlock for the amount of time specified by ABORT_TIME, and the transfer will be aborted at that time. An ASCII text file may be defined for this parameter. ARCHIVER DEFINITIONS: ───────────────────── Each archiver, is denoted by ARCHIVER x, where x is a sequential number. Up to 10 archivers can be executed by ROMproc. ROMProc is capable of automatically detecting ARC, ARJ, HYP, LZH, PAK, SQZ, ZIP and ZOO archives. The next 4 keywords are required after the ARCHIVER statement; do not comment any of them out or insert other parameters or comments between them. I would also advise against changing the command options I have set, unless you have need to do so. Any other archiver can be added, if desired; the only requirement is that the archiver must return a DOS errorlevel so that ULP can determine if it ran properly. If you do not explicitly define the path to your archiver(s), it must in a directory included in the DOS PATH environment variable. ARCHIVER = denotes a new archiver definition. ARC_EXT = the extension for this particular archiving format. ARC_ADD = the command line to add files to an archive, including all command-line switches desired. Place the variable @ARCHIVE@ where the filename is to be inserted in the command line and @FILE@ where the filespec is to be inserted. ARC_COMMENT = the command line to comment archives, including all command- line switches desired. Place the variable @ARCHIVE@ where the filename is to be inserted in the command line. If the archive utility does not support commenting, leave this line blank. ARC_ERR = the errorlevel that the archiver returns upon success. This information should be available in the program's documentation. PROTOCOL DEFINITIONS: ───────────────────── Each protocol, is denoted by PROTOCOL x, where x is the letter designating the protocol. Up to 15 protocols can be executed by ROMproc. The next keyword is required after the PROTOCOL statement; do not comment it out or insert other parameters or comments between them. I have configured most of the popular protocols, using the PCBoard default lettering scheme. If you do not explicitly define the path to your archiver(s), it must in a directory included in the DOS PATH environment variable. PROTOCOL = denotes a new protocol definition PROT_SEND = the command line to transmit the file(s) to remote, including all command-line switches desired. Place the following variables as needed for ROMProc to properly invoke the protocol. @PORT@ COM or FOSSIL port to be used by the protocol @SPEED@ COM port computer-to-modem speed (DTE) @CARRIER@ modem-to-modem carrier speed (DCE) @FILE@ File (or batch list file) to be downloaded @ULDIR@ path to upload directory for bi-directional protocols. * NOTE: For reference, the ROMProc command line parameters are mapped to the protocol command line variables *exactly* as follows: ROMProc Command Line Parameter Protocol Command Line Varable -P @PORT@ -X @PORT@ -S @SPEED@ -E @CARRIER@ -F @FILE@ -U @ULDIR@ ┌──────────────┐ │ 9. Support │ └──────────────┘ If you require support for ROMProc, I can be contacted by any of the following means: ∙ Fidonet netmail (node: 1:151/106) ∙ Intelec BBS Doors conferences ∙ RoseNet routed mail (system ID: BB-P) ∙ The ULP Support conference (#42) on Salt Air (PCBoard support BBS) ∙ The Support conference (#2) on my BBS (listed at the top of this document). ┌─────────────────────────────┐ │ 10. The Future of ROMProc │ └─────────────────────────────┘ ROMProc will be supported as long as I'm in the BBSing business (which will be quite a while...once it's in your blood, you can never shake it <g>). The ROMProc system will be continually expanding it's features, so get your comments in now! Some current plans: ∙ Add code enabling ROMProc to output status information to the remote user for long batch processing on slow systems. ∙ Any ideas from you guys? Thanks! <g> If you have any other suggestions, contact me by U.S. snail-mail or on my BBS at the number at the top of this document. Thanks for giving ROMProc a try! ┌────────────────────────────────┐ │ Appendix A: DOS Errorlevels │ └────────────────────────────────┘ The following is a list of the errorlevels than can be returned by ROMProc. The reason the successful execution errorlevel may not be zero is because ROMProc, upon error-free completion, returns the errorlevel of protocol, which makes ROMProc completely transparent to the BBS software. 0 Successful execution (usually, depends on the protocol) 99 Help screen (executing a program with no or an insufficient number of arguments) 100 Could not close all open files 101 Invalid command-line parameter 102 Configuration file not found 103 No download file (or batch list file) specified 104 No transfer protocol specified 108 Invalid configuration file format (archiver definitions) 109 Invalid configuration file format (protocol definitions) 110 Unable to allocate heap memory 112 Invalid registration code 117 Invalid node number 120 Archiver BBS advertisement insertion error 121 Archiver commenting error 122 Time out waiting for a slow drive to unlock 125 Communication system for online status failure 200 Undefined error (internal to ROMProc program)