Simtel MSDOS 1992 June

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

/ Simtel MSDOS 1992 June / SIMTEL_0692.cdr / msdos / bbsdoors / zdoor206.arc / ZDOOR.DOC < prev next >

Wrap

Text File | 1988-03-25 | 54.4 KB | 1,393 lines

ZDoor (C) Copyright 1987, 1988 by R. P. Byrne March 25, 1988 1 I. Licensing Information ZDoor is provided for private, personal use. You may distribute the Zdoor program so long as the following conditions are satisfied: * The program is supplied in its original, unmodified form, including this documentation. * No fee is charged for the distribution of ZDoor. * The program may not be distributed as part of any other application or service without the written consent of the author ZDoor is being distributed as a ShareWare product (sort of...). If you like the program then send the author a check for whatever you feel the program is worth. If you are running your bbs for profit, or as part of a business or government operation, then you are required to remit $25.00 to the author for each copy of PCBoard under which the ZDoor program will be run. Send checks to: Mr. Richard P. Byrne 5 Twin Elm Terrace Sparta, NJ 07871 * * * DISCLAIMER * * * Unfortunately, I cannot and do not claim that the ZDoor program is good for anything! If YOU think it is, that's great, but it is up to you to decide. If you lose a million dollars because ZDoor messes up, I refuse to be held responsible...it is you that is out the million, not me! 2 II. Program Overview ZDoor is a program for use with PCBoard version 12.1 that facilitates the use of Chuck Forsberg's DSZ program (Copyright 1987 by OMEN Technology Inc.) to provide PCBoard callers with the ability to upload and download files using the ZModem file transfer protocol. By installing ZDoor on your system, you will be providing your callers with all of the advantages of ZModem including enhanced error correction/detection, enhanced throughput for callers using packet networks, the ability to resume an aborted transfer, batch mode transfers, and much, much more. For those of you operating your boards with modems that provide hardware error-checking, ZDoor provides your callers with a YModem-G alternative to the ZModem protocol for even faster throughput. And finally, for callers who simply refuse to become acquainted with the ZModem protocol, a true YModem protocol is available for batch transfers. In addition to facilitating file transfers, ZDoor also functions as an ARC file processing door. Verbose listings of ARC file contents are provided as well as the ability to display any file contained in an ARChive (including those compressed with Phil Katz's "squash" algorithm). Starting with version 2.06, an ARC Extraction facility is available which allows callers to extract selected files from an ARC file. The extracted ARC members are placed into a temporary ARChive for downloading. For the caller's convenience, all of Pcboard's file-related functions are provided by ZDoor. These include N)ew file scans, L)ocate file, Z)ippy Directory scans, listing of DIR files, Conference J)oin and A)bandon, etc. The syntax for these functions duplicates that used within PCBoard itself. Several utility commands are also available to the caller such as O)perator Page, V)iew Statistics, M)ode, T)ransfer Protocol, and X)pert Mode Toggle. ZDoor handles all of the various record keeping tasks required by a door of this type. The caller's daily time limit is closely monitored, his upload/download counts are kept up-to-date, time remaining is automatically adjusted for time spent uploading files, etc. There are many other features of ZDoor that could be described here, however the best way to understand the program is to run it and watch... 3 III. Installation Installation of ZDoor is a simple process. What little information the program cannot obtain from PCBoard's own setup files (pcboard.dat, cnames, etc.), is provided by the sysop in a configuration file. Once a configuration file has been built, a batch file is created to invoke the door program. This batch file serves to set various environment variables, invoke the door program, and return to PCBoard after the door program has been terminated. Finally, entries are made into PCBoard's Doors.Dat file(s) to inform the board software that a new door is available to callers. 1. Configuration File(s) Setup The environment under which ZDoor will operate must be described in a configuration file. There is no magic associated with this file, so you can use your favorite editor (Edlin?) to put one together or make changes to the samples provided. There are only 2 rules to follow: * Put each entry on a line by itself * Don't put any comments on lines 8 through 13 NOTE: A separate configuration file needs to be created for each node of a multi-node system. Several sample configuration files are provided in the ZDoor ARChive. These should be used as templates for creating your own configuration files. ZDoor.Cfg - Sample config. for single node system ZDoor1.Cfg - Sample config. for 1st node of a two-node system ZDoor2.Cfg - Sample config. for 2nd node of a two-node system Pretty simple, eh? Ok, lets begin with a description of what is specified on each line in the file. Line 1: Full Path and Filename for an Opening Message File This line specifies the "base" name of a text file that will be shown to the caller when the door is first opened. If the caller is NOT in graphics mode when the door is opened, ZDoor will look for a file with the same name specified here. If the caller IS in graphics mode, ZDoor will append a 'G' to this filename and attempt to display it. Should this fail, ZDoor will fall back to displaying 4 the file with the exact name specified here. If this too fails, no opening message will be displayed, and processing will continue normally. The contents of this file will NOT be paginated for the caller, so keep it short. Line 2: Full Path and Filename for a News File This line specifies the base name of a text file that will be displayed to the caller following the Opening Message File. As with the opening message file, a graphic version may be created. Append a 'G' to the name of the graphic version filename, and ZDoor will automatically display it if the caller is in Graphics mode. Similarly, if the graphic version cannot be found by ZDoor, the Non-Graphic news file is displayed. If neither is found, processing continues normally. The contents of this file will be paginated, so feel free to make it as long as you need it to be. Line 3: Full Path and Filename for a Logoff Message File This line specifies the name of a text file that will be displayed to the caller after the G)oodbye command is issued (before carrier is dropped). As with the Opening Message and News files, a graphic version may be created for callers in color graphics mode. The contents of this file will NOT be paginated, so keep it short. Your existing Script0 file can be used, however the semicolons are not parsed out prior to display. It is suggested, therefore, that you copy Script0 to another name and then edit out the semicolons. Line 4: Full Path and Filename for a Help File This line specifies the base name of a text file that will be displayed to the caller if the H)elp command (or it's synonym '?') is selected from one of ZDoor's menus. 5 As with the Opening Message and News files, a graphic version may be created for callers in color graphics mode. The contents of this file will be paginated, so feel free to make it as long as you need it to be. NOTE: The first four lines of the configuration file MUST contain valid DOS file specifications. The files do not need to actually exist, but valid filespecs must be provided. Line 5: Full Path and Filename of the PCBoard.Sys file This line tells the door where to find the PCBoard.Sys file that is generated by PCBoard whenever a caller enters a door. Line 6: Full Path and Filename of the PCBoard.Dat file This line tells the door where to find the PCBoard.Dat file that contains the setup information for PCBoard. Line 7: Full Path and Filename of the DSZ program This line tells the door where to find the DSZ program. Note that the filename extension must be specified as part of the filename e.g. C:\UTIL\DSZ.COM Line 8: DSZ Command Line for Sending a File with ZModem This line is used to specify any DSZ "sender" options that may be required for your system. I would strongly urge that you not fool too much with this line unless you have a good understanding of how the ZModem protocol is implemented in DSZ. Line 9: DSZ Command Line for Receiving a File with ZModem This line is used to specify any DSZ "receiver" options that may be required for your system. As with line 8 (sender options), I would strongly urge that you not fool too much with this line unless you know what you are doing. Do not specify the -p option on this line. This 6 option is automatically supplied by ZDoor. If you are using a modem that supports hardware error-correction (eg. MNP) and you have that feature enabled, add "handshake both" to your send and receive command lines at the very beginning. This enables both XON/XOFF and CTS/RTS flow control. eg. Line 8: handshake both pB6144 sz Line 9: handshake both pB6144 rz If you are using a high speed modem and have chosen *NOT* to autobaud (ie. it is locked in at 19.2 or 9.6 kbps at all times), some additional parameters are needed by DSZ to improve flow control and error recovery when sending files. For example, your command lines might be: Line 8: handshake both pB6144 z pb1 pw2048 sz Line 9: handshake both pB6144 rz These command lines are consistent with the current settings of the PCBMODEM program for high speed modems running at a fixed baud rate. They should only be used in that configuration as they will decrease Zmodem's efficiency in all other setups. Line 10: DSZ Command Line for Sending a file with YModem This line specifies any YModem Sender options that may be required for your system. Note that no handshake is required for YModem, as the constant ACK/NAK sequences generated by the protocol will serve the same purpose as XON/XOFF or RTS/CTS handshakes. Line 11: DSZ Command Line for Receiving a file with YModem This line specifies any YModem Receiver options that may be required for your system. As with Line 10, no handshake parameters are required here. Line 12: DSZ Command Line for Sending a file with YModem-G This line specifies any YModem-G sender options that may be required by your system. As with the ZModem command lines and depending on your modem type, a handshake parameter and possibly other options may be required here. 7 Line 13: DSZ Command Line for Receiving a file with YModem-G This line specifies any YModem-G receiver options that may be required by your system. As with the ZModem command lines and depending on your modem type, a handshake parameter and possibly other options may be required here. One parameter that MUST be specified on this line is '-g', as without this, DSZ will fall back to regular YModem. Line 14: Additional Time (in minutes) granted for Uploads The Sysop may specify an additional time credit for uploads. For each file uploaded, the caller will be granted additional time on the system as specified on this line. A value of zero on this line means that no "additional" time will be granted for uploads, but that time spent uploading files will not be charged against the caller. Line 15: Minimum Security Level Required for Batch Downloads The Sysop may choose to restrict the availability of Batch mode file transfers based on the caller's security level. Callers with a security level that is greater than or equal to the number on this line will be granted access to the Batch Download features of ZDoor and DSZ. Those callers with a lower security level will be allowed single file downloads only. Line 16: Minimum Security Level Required for Batch Uploads Callers with a security level that is greater than or equal to the number on this line will be granted access to the Batch Upload features of ZDoor and DSZ. Those callers with a lower security level will be allowed single file uploads only. Line 17: Full path and filename of Temporary ARC file This line specifies the name of the ARC file created by the 'E)xtract files to Temp ARC' command (in the File & ARChive submenu). Since this file must be available for download, specify a subdirectory that is currently part of 8 your download path. e.g. D:\DL1\ZTemp.ARC The filename entered here MUST be different for each node of a multi-node system. Line 18: Minimum Security Level required for ARC Extract This line specifies a minimum security level for the 'E)xtract files to Temp ARC' command. Callers with a security level less than this value will be denied the use of the E)xtract command. 2. Environment Variables The DSZ program uses environment variables to determine certain characteristics of the system on which it is to be run. These variables may be populated in either your AutoExec.Bat file or in the batch file that invokes the ZDoor program. The DOS syntax for setting an environment variable is as follows: SET VARNAME=VALUE Where VARNAME is the name of the variable, and VALUE to be assigned that variable. Consult your DOS manual for further information regarding the SET command. a) DSZPORT This variable tells DSZ which communications port to use. The value assigned must be an integer in the range 1 through 8 (the maximum number of com ports supported by DSZ). e.g. SET DSZPORT=1 b) DSZLOG This variable specifies the full path and filename of a file to be used by DSZ to record the results of file transfers. This variable MUST be set if batch transfers are desired. If this variable is not set, or if it does not contain a valid DOS file specification, all batch mode transfers will be disabled (ie. callers will be granted single file transfers only). The file specification provided in this variable MUST be 9 different for each node of a multi-node system. e.g. SET DSZLOG=E:\WORK\NODE1.LOG 3. Batch File Setup A batch file needs to be created to invoke the ZDoor program. This batch file will be renamed to door.bat and executed by PCBoard when the door is selected. The only difference between a "real" batch file and a "door" batch file is the filename extension. While DOS expects the extension to be '.BAT', PCBoard expects no filename extension at all. e.g. "ZModem.Bat" is no good, but "ZModem" is fine. Assuming that all ZDoor files are kept in the same subdirectory (namely, c:\doors), that PCBoard runs on COM1:, and that the name of the ZDoor configuration file is ZDOOR.CFG, then the following door batch file should suffice: SET DSZPORT=1 SET DSZLOG=C:\DOORS\DSZ.LOG CD \DOORS ZDOOR ZDOOR.CFG CD \PCB BOARD If you run a multi-node system, then you will need separate batch files for each node. For instance: Node 1 Node 2 ============================ ============================ SET DSZPORT=1 SET DSZPORT=2 SET DSZLOG=C:\DOORS\DSZ1.LOG SET DSZLOG=C:\DOORS\DSZ2.LOG CD \DOORS CD \DOORS ZDOOR ZDOOR1.CFG ZDOOR ZDOOR2.CFG CD \PCB1 CD \PCB2 BOARD1 BOARD2 Some sample batch files are provided in the ZDoor ARChive file. These may be used as templates for building your own batch file(s). ZModem - Batch file for use on single node system ZModem1 - Batch file for node 1 of a two node system ZModem2 - Batch file for node 2 of a two node system NOTE: If your DOORS.DAT is shared between nodes, you would rename both ZMODEM1 and ZMODEM2 to ZMODEM, but place the appropriate one in the "\PCB" subdirectory for each node. 10 4. Doors.Dat File Entry The final step for installing ZDoor is to create an entry in your board's DOORS.DAT file. This file describes all available doors to PCBoard and instructs PCBoard as to the name of the batch file to be invoked when a particular door is selected by the caller. Consult your PCBoard documentation for setup instructions for this file. A sample entry in DOORS.DAT might be: ZMODEM,,43 which means no password is required, and any caller with a security level of 43 or higher may open Zdoor. 5. "Mini-BBS" Conference Setup If you have any conferences that have been configured in "mini-bbs" mode (via PCBSetup), the DOORS.DAT file for each of them will need an entry for the ZDoor. Since ZDoor automatically supports all conference file security features of PCBoard, the entry may point to the same batch file that was specified in the DOORS.DAT file for the main board. 11 IV. Commands 1. Sysop Commands When a remote caller has entered the door from PCBoard, both the caller's keyboard and the sysop's keyboard may be used to enter commands. In this way, a sysop can help a new user by actually showing him how to use the door. This feature is only enabled when the sysop's local display is enabled. a) Display Toggle The local display can be enabled or disabled by the sysop. When disabled, nothing will be echoed to the screen by the door. The F9 key on the sysop's keyboard toggles the display on/off. On entry, the PCBOARD.SYS file is examined to determine if the display was active prior to the door being invoked. If so, the display is automatically enabled for the door. If the display was disabled in PCBoard, it will remain disabled when the door program is loaded. The state of the display is maintained on return to PCBoard. That is, if the display is on when ZDoor terminates, then it will be on when PCBoard reloads itself and visa-versa. b) Other Sysop Functions Many functions are available to the sysop via the local console. When the display is enabled, a "PCBoard-like" status line will be displayed. Press the HOME key to change this status line to show the available sysop keys and the functions they provide. The END key may also be used and will change the status line to display the caller's registration information. One function that is not displayed on the local status line when the HOME key is pressed is the ability to dynamically alter the caller's time remaining. The UP ARROW key, when pressed, will add 5 minutes to the time allowed for the current call. Similarly, the DOWN ARROW key will reduce the caller's time allowed for the current call by 5 minutes. c) Local Testing The ZDoor may be run locally to test the configuration and setup. Log onto the board locally, and invoke the ZDoor just as you would if you were calling from remote. The only functions of the door that will not operate properly 12 are the U)pload and D)ownload options (although a simulated file transfer will take place, the door will normally consider the transfers to have failed). Time remaining in Zdoor is always 99 minutes during local testing. 2. Main Menu Commands ZDoor's menus are not shown to Expert callers. On entry, the caller's USERS file entry is examined to determine the state of the Expert flag and the door's menus are shown/not shown as appropriate. The display of the program's menus may be toggled on/off regardless of the caller's Expert mode status via the X)pert command. This has no effect on the caller's Expert status in PCBoard. The ZDoor main menu appears as follows: ┌─────────────────┬─────────────────────┐ │ ZDoor Main Menu │ H)elp with commands │ ├─────────────────┴─────────────────────┴──────────────────────┐ │ U)pload a file L)ocate a file X)pert mode │ │ D)ownload a file N)ew file scan G)oodbye(Hangup) │ │ T)ransfer Protocol Z)ippy file scan Q)uit ZDoor │ │ F)ile & ARC submenu V)iew Statistics O)perator Page │ │ J)oin Conference A)bandon Conference M)ode (Graphics) │ └──────────────────────────────────────────────────────────────┘ Each option from this menu is described below: U)pload a file -------------- This command allows the caller to send files to the PCBoard system. The caller is prompted to enter the name of the file he/she wishes to upload. The name entered is checked for duplication elsewhere on the board and for a matching UPSEC file entry. If the file is not a duplicate and if there is no UPSEC security applicable, then a prompt for a file description is displayed. The caller MUST enter a description of at least 10 characters before the description will be accepted. Entering no description at all aborts the upload and returns the caller to the Main Menu. Note that callers having Sysop Privileges (ie. a security level at or above 100) will be allowed to upload duplicate files. When this occurs, the caller is told that the file is a duplicate and is asked if the existing file should be 13 overwritten. If the caller answers YES to this prompt, the board's copy of the file is erased and the transfer will proceed. Should the answer be NO, that particular file will not be accepted for upload and the board's copy of the file will remain intact. If batch mode is enabled, more than one file may be sent at a time (up to a maximum of 20) by entering several filenames (each separated from the others by a space) in response to the "filename(s) for upload" prompt. The implementation of batch uploads to PCBoard is not without it's quirks, however. Please read the section of this document entitled "Some Notes on Batch Uploads" for the details behind ZDoor's implementation of this option. Once all filenames entered have been verified and descriptions entered, a final prompt is issued. This prompt allows the caller to abort the transfer, change the currently selected transfer protocol, logoff when the transfer is completed, or continue with the transfer. If A)bort is selected, the caller is returned to the menu from which the transfer was requested. If T)ransfer Protocol is selected, the caller may select a new protocol for the transfer. If the caller simply presses ENTER, the transfer is begun immediately. If the L)ogoff after transfer option is selected, the transfer will proceed as if the ENTER key had been pressed, but 10 seconds after the completion of the file transfer, he will be logged off the system automatically. During the 10 seconds following the transfer, the caller may enter a ^K or ^X to abort the logoff. Following a successful transfer, the caller's USERS file entry is updated by incrementing the "files uploaded" field and the elapsed time of the transfer is added back into the caller's daily time limit to insure that he/she will not be penalized for time spent uploading files. If an additional upload time credit is specified on line 9 of the configuration file, it too is added to the caller's daily time limit. File descriptions are placed in either the upload DIR or the PRIVATE file depending on the Private Uploads setting in PCBoard.Dat and on the first character of the file description (ie. "/" as 1st char. makes the upload private). One additional prompt may be shown the user during the upload process if he/she has joined a conference. That prompt allows the caller to specify the placement of the uploaded file(s) to be either inside or outside the conference. If the CNAMES entry for that conference specifies that ALL uploads are to remain inside the conference, then this prompt is not displayed to the user and all of the uploads will be placed 14 into conference directories. File transfers are disabled if the PCBoard.Sys file indicates that the caller has connected using 7 data bits and even parity. New in the 2.06 release of ZDoor is the ability to resume an aborted upload. Following an aborted upload, a check is made to determine if more than 0 bytes have been transferred. If so, the caller will be given the opportunity to resume the transfer where it left off. Since only the ZModem protocol allows for this function, the caller will be told to switch to ZModem before beginning the resumed upload. If the caller had originally selected the L)ogoff after transfer option, he will have 10 seconds to abort the logoff at which time the opportunity to resume the aborted transfer will be offered. If the logoff is not aborted, the partial upload will be erased. Note that when resuming an aborted upload, only 1 file may be transferred (ie. you cannot "resume" a batch upload!). D)ownload a file ---------------- This command allows the caller to download files from the PCBoard system. If batch mode is enabled, more than one file may be downloaded at a time by entering several filenames (each separated from the others by a space) in response to the "filename(s) to download" prompt. Unlike batch uploads which places an arbitrary limit of 20 on the number of files that can be "batched", the download routine is limited only by the total length of the command line that is generated for invoking the DSZ program. The absolute limit on the length of that command line is 127 characters. Out of that 127 characters comes the drive/path/name of the DSZ program, whatever command line parameters have been specified in line 7 of the configuration file, and the drive/path/name of each file requested for download. The filename(s) entered are checked for existence and for FSEC file security constraints before the transfer is begun. In addition, an elapsed time for the transfer is calculated (based on transfer efficiency of 95%) and is compared with the caller's time remaining to be sure that the caller's daily time limit will not be exceeded. 15 Finally, after all of the above is checked, the total size of each file is checked against the caller's daily download byte limit to insure that the download will not cause this limit to be exceeded. Assuming all of the above checks out, the caller will be issued the same "last chance" prompt described for the U)pload command. Following a successful download, the caller's USERS file entry is updated by incrementing his/her download count. The total size of all downloaded files is then summed and written to USERS. File transfers are disabled if the PCBoard.Sys file indicates that the caller has connected using 7 data bits and even parity. T)ransfer Protocol ------------------ This command allows the user to select a file transfer protocol for use in subsequent uploads and/or downloads. The caller may select either ZModem or YModem, both of which are batch protocols. Additionally, if the caller has achieved a Reliable Connection using an error correcting modem, YModem-G will be offered as an alternative to ZModem and YModem. When a caller first enters the door, ZModem is automatically selected by default. F)ile & ARC submenu ------------------- Entering this command causes a submenu to be displayed. See the description of the File & ARC submenu below. L)ocate a file -------------- Selecting this option will prompt the user for a file specification (wildcards are accepted here) to be located and for the directories to be searched. The syntax is exactly the same as the syntax for the Locate command in PCBoard. 16 N)ew file scan -------------- This option works in exactly the same way as the PCBoard option of the same name. The user is prompted to enter the date from which to search (or may accept the default date shown), and to enter which directories are to be scanned. The shorthand notations N S U and N S A are also accepted. Z)ippy file scan ---------------- This option provides the same function and follows the same syntax as the Zippy search command of PCBoard. The caller is prompted for a string to be found and the directories to be searched. A case-insensitive search of the selected directories is then performed. V)iew Statistics ---------------- This option allows the caller to obtain a display of various PCBoard statistics relating to his board activity. Among the statistics displayed are upload and download counts, security level, last time on, last DIR scan date, and more. In addition to historical information, the caller is also shown statistics accumulated during the current call including bytes downloaded and bytes still available for download. X)pert mode ----------- This option toggles the display of ZDoor menus on/off. H and ? are considered synonyms and will perform the same function. G)oodbye (Hang up) ------------------ Choosing this option causes ZDoor to update all relevant USERS file statistics for the caller, write logoff information to the CALLER log, display the Logoff Message file, and drop carrier on the caller. Q)uit ZDoor ----------- Selecting this option returns the caller to PCBoard. 17 O)perator Page -------------- This option allows the caller to page the sysop. The page bell will be sounded at the local console only if it has been enabled by the sysop. The sysop may respond to a page with either the spacebar or with the F10 key. Chat mode can be terminated using the ESCape key. M)ode (graphics) ---------------- This command toggles the caller into and out of color graphics mode. Graphics mode will be denied to callers showing a connection using 7 data bits and even parity. J)oin Conference ---------------- After selecting J)oin, the user will be displayed a menu of conferences from which to choose and will be prompted for the number of the conference to join. The caller must be registered in the conference selected or access to that conference will be denied. Once Joined, all conference file directories become available to the caller. A)bandon Conference ------------------- This command simply revokes access to any currently active conference file directories (ie. returns the caller to the "main board"). 18 3. Files/ARChive Submenu Commands When the F)iles & ARC submenu command is issued from ZDoor's main menu, the following menu is displayed to the caller: ┌──────────────────────────────┬─────────────────────┐ │ ZDoor File Dir & Arc Submenu │ H)elp with commands │ ├──────────────────────────────┴─────────────────────┤ │ D)ownload a file <cr> Back to Main Menu │ │ # = view DIRectory # L)ist file directories │ │ X)pert mode (menu toggle) │ │ ───────────────( ARC Functions )──────────────── │ │ E)xtract files to Temp ARC V)erbose ARC listing │ │ R)ead file in selected ARC D)ownload selected ARC │ │ S)elect (new) ARC │ └────────────────────────────────────────────────────┘ Note that this menu is logically divided into 2 portions. The top portion deals with PCBoard DIRectories, while the bottom contains options specific to ARC file handling. To understand the actions behind each of these submenu options, it is important to understand the concept of a "selected" ARChive file. An ARChive file is "selected" by entering a valid ARC filename in response to the prompt after issuing any of the commands S, V, E, or R. Once selected, subsequent invocations of V, R, or D commands will operate ONLY on the selected ARChive file. This selection remains in effect until the caller returns to the main menu or issues a S)elect new ARChive command. D)ownload a file ---------------- The D)ownload command (when no ARC file is selected) functions exactly like the main menu D)ownload command with the exception that following the file transfer, the user is returned to the Files & ARC submenu rather than the main menu. L)ist file DIRectories ---------------------- Selecting this option will display your board's main DIR file (ie. your directory of directories). <#> = view DIRectory # ---------------------- Entering a valid directory number displays that directory. 19 Any number entered that is outside the range of available directories will result in an error message to the caller. S)elect (new) ARC ----------------- This option allows "selection" of an ARC file for processing. The caller will be prompted to enter the name of an ARC file (if no extension is entered, .ARC is assumed). If the .ARC file can be found, a verbose listing of it's contents is displayed to the caller. Subsequent V, R, and D commands will apply ONLY to the selected ARC file until the caller either selects another ARC file for processing or returns to ZDoor's main menu. V)erbose ARC listing -------------------- This option produces a standard verbose ARC contents display that is similar to PCBoard's F V display with the exception that ZDoor also shows CRC values for each file included in the archive. The caller will be prompted for the name of an ARC file if no ARC file is currently selected for processing when the command is issued. The ARC file entered then becomes selected. R)ead file in selected ARC -------------------------- This command allows the caller to display the contents of files contained in an ARChive. The caller is prompted for a file specification (wildcards allowed) for files within the selected ARChive to be displayed. The selected ARC is then searched for files that match the caller's specification. When a match is found, that file's contents are displayed. The caller will be prompted for the name of an ARC file if no ARC file is currently selected for processing when the command is issued. The ARC file entered then becomes selected. E)xtract files to Temp ARC -------------------------- This command allows the caller to extract selected files from one ARC file and place those extracted files into a Temporary ARC file for downloading. The caller may enter up to 5 file specifications (wildcards are allowed) to specify which files 20 will be extracted. The name of the Temporary ARC file created by this command is specified in the ZDoor configuration file on line 17. Line 18 of the ZDoor configuration file specifies a minimum security level for this command. If the caller's security is less than this value, this function will be disallowed for that caller. D)ownload selected ARC ---------------------- Issuing the D)ownload command after an ARC file has been selected for processing causes the selected file to be downloaded without further prompting. 21 V. Some Notes on Batch Uploads The implementation of Batch uploads using DSZ poses a few fairly sticky problems. There are basically three methods one can use to implement Batch uploads: 1. Have the caller specify each file to be sent and have the door place the names of the files entered on the DSZ command line. 2. Do not require the caller to specify which files will be uploaded. Use the -p option of DSZ to prevent overwriting existing files in the target directory. 3. Have the caller specify each file to be sent, but don't put the names on the DSZ command line...instead, use the -p option of DSZ to prevent overwriting existing files in the target directory. Method 1 sounds extremely reasonable and was the first method attempted during the development of ZDoor. A problem arises, however when the caller says "I'm uploading File1.Arc, File2.Arc, and File3.Arc", but then proceeds to upload the files in reverse order (ie. caller sends File3.Arc, then sends File2.Arc, and finally sends File1.Arc). In this situation, File1.Arc and File3.Arc will be misnamed on the target system. Method 2 poses the problem of files uploaded duplicating files elsewhere on the system. It also requires that file descriptions be entered AFTER the transfer has completed. Method 3 offers a compromise and is the method used by ZDoor. The caller is prompted for the names of the files to be sent. These names are checked for duplication elsewhere on the board and either accepted or rejected. Descriptions for each filename entered are collected BEFORE the transfer begins. DSZ is then called without placing these filenames on the command line, but using the -p option to prevent any files already in the upload directory from being overwritten. After the transfer has completed, DSZ's log file is examined to determine which files "made it" to the target system. Those that did "make it", are posted in the upload dir. Even Method 3 poses a problem. That is, since no filenames are placed on the DSZ command line, the caller will not be restricted to sending just the files that were specified, checked, and described! Should this happen, ZDoor renames the unchecked upload to a filename of the form ZDRnnnnn.EXT where nnnnn is some number (eg. 00001, 00002, etc) and where EXT is the original extension of the file that was uploaded. The renamed file is then posted in the sysop's PRIVATE directory with a description that shows what the original filename was AND who uploaded it. 22 VI. Acknowledgements At this point in the documentation, I would normally list the names of all of the people who helped in one way or another with the development of the program. Unfortunately, a list such as that would probably go on for several pages. Suffice it to say that I have received assistance, advice, and support from many many people. I would like to thank all those involved in the development and testing of ZDoor and all who have contributed ideas, suggestions, and even money to help make ZDoor the premier ZModem file transfer door available for PCBoard. Without the assistance of all of these dedicated people, I would have given up long ago. Special thanks to Robert Blacher and Richard Driggers for their assistance in converting the original ZDoor into a door compatible with PCBoard 12.0 and to Paul Kopit without whom the original ZDoor would never have been created. Special credit must go to Bob Blacher for his thoughts on how to implement the resumption of aborted uploads. Thanks Bob! Thanks also to Phil Burns for publishing a wonderfully useful set of communications routines and to Chuck Forsberg (of course) for creating and releasing the DSZ program. Sysops please note: For those of you that install this door along with Chuck Forsberg's DSZ program, I urge you to comply with Chuck's request that you make his programs available to your callers for downloading. It ain't much to ask, and the addition of Zmodem Batch to your board's available file transfer protocols is well worth the disk space required. I would also ask that you urge your callers to support the continued development of DSZ by registering their copy with Omen Technologies. At $20.00, it's one of the best PC Software bargains around. See DSZ's documentation for information on use and registration of DSZ by Sysops of "qualified" bulletin boards. 23 VII. Feedback Please report any problems or difficulties in the use of this program to me. I will attempt to resolve any and all trouble reports. I can be reached on any of the fine bulletin boards listed below: Software Society Sparta PCBoard Sysop: Paul Kopit Sysop: Richard Driggers (201) 729-7410 (201) 729-5377 Computer Connections PC-Rockland Sysop: Robert Blacher Sysop: Charlie Innusa (202) 547-2008 (914) 353-2176 Northern Lights Tamiami Sysop: Jack Kilday Sysop: Gerhard Barth (207) 766-2467 (813) 793-2392 Chuck's Attempt Sysop: Chuck Ammann (201) 729-2602 rpb 24