home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Simtel MSDOS 1992 December
/
simtel1292_SIMTEL_1292_Walnut_Creek.iso
/
msdos
/
bbsdoors
/
zdoor206.arc
/
ZDOOR.DOC
< prev
next >
Wrap
Text File
|
1988-03-25
|
56KB
|
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
