DP Tool Club 8

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

/ DP Tool Club 8 / CDASC08.ISO / VRAC / SDPD101D.ZIP / SDPD.DOC < prev next >

Wrap

Text File | 1993-08-06 | 71.1 KB | 1,649 lines

Streamline Design Protocol Module Version 1.01 (DIGIBoard Version) CopyRight (C) 1993 Streamline Design (984502 Ontario Inc.) All Rights Reserved Voice: (416)790-1997 10:00am to 6:00pm BBS : (416)793-1411 24 Hours a Day Table of Contents 1 - Introduction 2 - Liscencing 3 - Future Plans 4 - Quick Reference 5 - ASCII 6 - XModem 7 - YModem 8 - ZModem 9 - Kermit 10 - General 11 - Flip Screens 12 - Additional Programs 13 - Registration 1 - Introduction The Streamline Design Protocol Module, aka SDPD, was designed to allow the transfer of data from various platforms. It will work in DOS, PS2, OS2, Windows, Networked, and any of the previous emulated environments. The goal of SDPD is to make it easy to transfer data with a great amount of flexibility and ease of use. SDPD supports the following protocols: ASCII XModem XModem Relaxed XModem/CRC XModem/CRC Relaxed XModem-1k XModem-1k Relaxed XModem-1kG XModem-1kG Relaxed Ymodem YModem Relaxed YModemG YModemG Relaxed YModem-128 YModem-128 Relaxed ZModem ZModem-8k Kermit If you have any comments or suggestions about this product we would be glad to hear from you about them. The following is a list of machines and environments this product has been tested on: Environments - DOS - Lantastic - MS Windows 3.xx - Novell Hardware - Phillips 486/25 EISA - Phillips 386/33 ISA with Phoenix BIOS - Intel 386/33 ISA with AMI BIOS - Intel 9600EX Modem - USR Robotics 19200 Modem - Generic 2400 Modem 2 - Liscencing This program is NOT public domain and is (c)Copyrighted 1993 by Thomas S. Thayer with all rights reserved. It may not be distributed for personal gain under any circumstances. The SDPDxxx.ZIP file in its original form may be copied or distributed thru Bulletin Board systems provided no fee is charged for its distribution and no modifications are made to the program files contained therein. User Supported Software is a way for you to review a program on a trial basis and test its operation on your system prior to purchasing it. Under this type of distribution system, you are insured that the program meets your needs and requirements. You may review this program for a period of 30 days, free of charge, after which, you must either order a copy or remove it from your system. This software is provided on an "As Is" basis without warranty either implied or expressed of any kind. Thomas S. Thayer, the author and sole owner of this software, takes no responsibility for loss of data or damage to equipment thru the use of this software. Should the software prove defective the entire burden of any and all repairs and replacements and/or data restoration rests with the user. In no event will the author be liable for any costs and/or losses either tangible or intangible arising from the use of this software. 3 - Future Plans In future updates we plan to implement as many suggestions and enhancements as is possible. The following is a list of future enhancements already planned: - Multi port operation. Currently working with an eight port DIGI board. - Background Transfers - Sealink - Telink - BPlus - Bi-directional operation 4 - Quick Reference A command that accepts an argument will always have a '=' preceding the argument. ##### - Numeric Value $$$$$ - ASCII Numeric Value CCCCC - Character or String Value ????? - Boolean Value (On/Off) ASCII Commands Command Description Args Default ------- ---------------------------------------------------- ----- ------- sa Sends a file using the ASCII protocol N/A N/A ra Receives a file using the ASCII protocol N/A N/A acl The amount of time to pause, (in milliseconds), ##### 0 between lines acd The amount of time to pause, (in milliseconds), ##### 500 between characters ae Sets the character used to mark the end of a line $$$$$ 13 (CR) az Specifys whether to suppress the Ctrl Z when ????? False/Off transferring files XModem Commands Command Description Args Default ------- ---------------------------------------------------- ----- ------- xrx Use XModem in the relaxed state N/A N/A sx Send a file using XModem N/A N/A sxc Send a file using XModem/CRC N/A N/A sxk Send a file using XModem-1k N/A N/A sxg Send a file using XModem-1kG N/A N/A rx Receive a file using XModem N/A N/A rxc Receive a file using XModem/CRC N/A N/A rxk Receive a file using XModem-1k N/A N/A rxg Receive a file using XModem-1kG N/A N/A YModem Commands Command Description Args Default ------- ---------------------------------------------------- ----- ------- sy Send a file using YModem N/A N/A syg Send a file using YModemG N/A N/A ry Receive a file using YModem N/A N/A ryg Receive a file using YModemG N/A N/A n1k Do not use 1k, (1024 byte), blocks ????? false/off nrx Do not use YModem in the relaxed state ????? false/off ZModem Commands Command Description Args Default ------- ---------------------------------------------------- ----- ------- sz Send a file using ZModem N/A N/A rz Receive a file using ZModem N/A N/A rzr Set up ZModem to allow file recovery ????? false/off zf1 Overwrite the existing file if the incoming file ????? false/off is newer or longer than the existing file zf2 Currently acts the same as zf4 ????? false/off zf3 Write the transmitted file no matter what ????? false/off zf4 If the file is new write it, otherwise append it to ????? false/off the end of the existing file zf5 Write the file if it is new, or newer than the ????? false/off existing file. zf6 Write the file if it is new, or if its date or size ????? false/off is different from the existing file zf7 Write the file only if it is new ????? true/on z8k Use large, (8k/8192 byte), with ZModem ????? false/off zov When receiving a file ignore the transmitting ????? false/off systems file management options and use the receiving systems file management options skn Skip all incoming files that don't already exist on ????? false/off the receiving system Kermit Commands Command Description Args Default ------- ---------------------------------------------------- ----- ------- sk Send file using Kermit N/A N/A rk Receive a file using Kermit N/A N/A kpl Set the maximum length of the data field ##### 80 mto Set the maximum time out between characters in secs. ##### 5 kpc Set the number of pad characters before packets ##### 0 kpk Set the pad character $$$$$ 0 (NULL) ktm Set the packet terminator $$$$$ 13 (CR) kcp Set the control character prefix $$$$$ 35 (#) khp Set the 7bit quoting prefix $$$$$ 89 (Y) kch Set the check method $$$$$ 49 (1) krp Set the repeat prefix $$$$$ 126 (~) kml Set the maximum length for a long packet ##### 0 kws Set the Kermit window size ##### 0 ktd Set the turn around delay for Kermit ##### 1000 kns Do not strip names in kermit ????? false/off General Commands Command Description Args Default ------- ---------------------------------------------------- ----- ------- gid Include directory with file names ????? false/off ghd Honor directory in file names ????? false/off grl Lower RTS during disk writes ????? false/off dhw The amount of time, (in clock tics), to wait ##### 182/10 sec before retrying a handshake signal dhr The maximum number time to retry before aborting ##### 10 transfer dtt The number of tics to wait for a receiver flow ##### 1092 control release dsi The amount of time to wait between updates to the ##### 91/5 secs status screen in tics bfc The fill character for partial protocol blocks $$$$$ 26 (^Z) gho The hour offset to correspond the GMT ##### 0 td Set the Telix delay, (in tics),will usually never ##### 9 need this. dd Set the destination directory for received files CCCCC blank fln Set the name for the file log CCCCC blank oh Set the number of bytes per block ##### N/A std Set the time, (in milliseconds), that it takes the ##### N/A block to get to the remote, for the remote to acknowledge and for that acknowledgement to reach us fs Force the Status updates ????? True/On si The amount of time to wait between updates to the ##### 91/5 secs status screen in tics sab Set the actual BPS (needed only if modem differs ##### N/A from port) soo Set option for what to do when the destination file ##### 1 already exists ugd Use the graphical/Color status screen rather than the ????? false/off ASCII screen @fl The path and name to the list of files you wish to CCCCC blank transfer com The comport to use with this session ##### 1 bd Override the baudrate with this value ##### N/A irq Define Non-Standard IRQs and/or base address CCCCC N/A fnm Name for file to be transferred or received CCCCC blank inb Set the size of the input buffer ##### 4096 otb Set the size of the output buffer ##### 4096 par Override the parity type CCCCC N/A stb Override the Stop Bits ##### N/A dtb Override the data bits ##### N/A hud Use DTR for Receive Flow Control ????? false/off hur Use RTS for Receive Flow Control ????? true/On hrd Require DSR before transmitting ????? false/Off hrc Require CTS before transmitting ????? true/on hdl Make DTR Active Low ????? false/off hrl Make RTS Active Low ????? false/off hsl Make DSR Active Low ????? false/off hcl Make CTS Active Low ????? false/off rpg Return partial strings from the input buffer ????? true/on rd Return the delimiter character from the input buffer ????? true/on epp Execute partial puts to the output buffer ????? true/on idc Ignore the case justification on delimiter chars ????? false/off roc Restore the UART when ending a session ????? false/off dmc Hangup the modem when finished with session ????? false/off rmo Raise the DTR and RTS signals when SDPD is started ????? true/on idt Do not initialize port with DTR low ????? false/off irt Do not initialize port with RTS low ????? false/off pcb Display PCBoard Users name in Info screen ????? false/off dsz Adhere to DSZ standards ????? false/off 5 - ASCII The term ASCII is a bit of a misnomer. In an ASCII transfer neither side adheres to any agreed upon rules for data transfer. An ASCII protocol is really just a convenient way of transferring a text or ASCII file. A good example of a situation where you may use an ASCII protocol is when the machine you are linked with doesn't support any type of protocol. One such situation would be the need to transfer a text file to a minicomputer that does not have protocol ability. To solve this issue you would connect your PC to the mini as a terminal, start up the minicomputers editor, open a new text file, and start an ASCII transfer of the file you wished on the mini. The mini would see the characters being transmitted as keystrokes and input and input them to the editor. You would then finish the transfer by saving the contents in the editor to a file on the mini. SDPD provides options that will allow the user to tailor the transfer of data so it matches the receiving machines speed. Such options are, delays between transmitted characters and lines. In the above example you may need to set these type of delays in order to stop the overflow of the editors keystroke buffer. When receiving data using an ASCII protocol it is difficult to know when the transfer is finished. This is because there is no agreed upon method for telling the receiver when the transfer is complete. SDPD will terminate the transfer when it receives one of the following three conditions: when it receives a ^Z, (This can be suppressed, or changed), when it times out waiting for data, or when the user aborts the protocol. The ASCII protocol does not support batch transfers. Options sa - This command has no arguments and simply starts the transfer of the file specified by the fnm command. ie: SDPD sa fnm=c:\SDPD\test.txt The above would transfer/Upload a file named test.txt from a directory named SDPD on the C drive. ra - This command has no arguments and simply receives data and stores it to the file specified by the fnm command. ie: SDPD ra fnm=c:\SDPD\test.txt The above would receive/download to a file named test.txt in a directory named SDPD on the C drive. acl - This command accepts numeric argument that specifies the amount of time, (in milliseconds), to wait between sending lines of data. The default is 0. This means it will just send line after line without any pause whatsoever. ie: SDPD sa acl=500 fnm=c:\SDPD\test.txt The above would transfer/Upload a file named test.txt from a directory named SDPD on the C drive and wait 500 milliseconds between each line transferred. acd - This command accepts a numeric argument that specifies the of time, (in milliseconds), to wait between sending characters. the default is 500. This means that the system will wait 500 milliseconds between transferring characters. ie: SDPD sa acd=0 fnm=c:\SDPD\test.txt The above would transfer/upload a file named test.txt from a directory named SDPD on the C drive and would not wait between characters transferred. ae - This command accepts a numeric value that represents the ASCII value of the character you wish to use for a EOL, (End of Line), signal. The default is a carriage return, (13). This character is assumed to mark the end of a line. ie: SDPD sa ae=26 fnm=c:\SDPD\test.txt The above would transfer/upload a file named test.txt from a directory named SDPD on the C drive and would assume the end of a line everytime a ^Z was received. az - This command has no arguments and simply specifies whether you wish to suppress the ^Z that signifies the end of a file. ie: SDPD sa az fnm=c:\SDPD\test.txt The above would transfer/upload a file named test.txt from a directory named SDPD on the C drive and would not send a ^Z when the transfer is finished. 6 - XModem XModem is the oldest protocol supported by SDPD. It was first developed by Ward Christensen in 1977 and then placed in the public domain. It became a very popular protocol and is still in wide use. However, it's use has diminished over the years as faster and more efficient protocols arrived. XModem is also the simplest, and perhaps the slowest, protocol supported by SDPD. XModem uses 128 bytes blocks, requires an acknowledgement of each block, and uses only a simple checksum for data integrity. SDPD provides a few options for better speed and flexibility when using XModem. Such options are 1024 byte(1k) blocks, CRC checks, G Mode, and relaxed mode. The XModem protocol does not support batch transfers. Options xrx - This command has no arguments and simply puts the XModem transfer into relaxed mode. Relaxed mode simply sets the time out for XModem to 10 seconds rather than the default of 5 seconds. ie: SDPD rx xrx fnm=c:\SDPD\test.txt The above would receive/download to a file named test.txt in a directory named SDPD on the C drive. It would also set the XModem timeout to 10 seconds. sx - This command has no arguments and simply starts the transfer a file specified by the fnm command using XModem. ie: SDPD sx fnm=c:\SDPD\test.txt The above would transfer/Upload a file named test.txt from a directory named SDPD on the C drive. sxc - This command has no arguments and simply starts the transfer a file specified by the fnm command using XModem/CRC. XModem/CRC is an improvement on the original XModem. It provides a 16 bit CRC (cyclic redundancy check) block check for the original checksum. This gives you a higher level of data integrity. ie: SDPD sxc fnm=c:\SDPD\test.txt The above would transfer/Upload a file named test.txt from a directory named SDPD on the C drive. sxk - This command has no arguments and simply starts the transfer a file specified by the fnm command using XModem-1k. XModem-1k is an improvement on the original XModem. It provides a 16 bit CRC (cyclic redundancy check) block check for the original checksum as well as using 1024 byte blocks rather than the original 128 byte blocks. This gives you a higher level of data integrity and a faster transfer. ie: SDPD sxk fnm=c:\SDPD\test.txt The above would transfer/Upload a file named test.txt from a directory named SDPD on the C drive. sxg - This command has no arguments and simply starts the transfer a file specified by the fnm command using XModem-1kG. XModem-1kG is an improvement on the original XModem. It provides a 16 bit CRC (cyclic redundancy check) block check for the original checksum, uses 1024 byte blocks rather than the original 128 byte blocks, and performs a streaming transfer. A streaming transfer means that the transmitter continuously transfers blocks without waiting for acknowledgements. This gives you a higher level of data integrity and a faster transfer, but it should never be used with non error correcting modems. If you are using a non error correcting modem, and the receiver receives a bad block, the transfer will be aborted. ie: SDPD sxg fnm=c:\SDPD\test.txt The above would transfer/Upload a file named test.txt from a directory named SDPD on the C drive. rx - This command has no arguments and receives data and stores it to a file specified by the fnm command using XModem. ie: SDPD sx fnm=c:\SDPD\test.txt The above would receive/download to a file named test.txt in a directory named SDPD on the C drive. rxc - This command has no arguments and receives data and stores it to a file specified by the fnm command using XModem/CRC. XModem/CRC is an improvement on the original XModem. It provides a 16 bit CRC (cyclic redundancy check) block check for the original checksum. This gives you a higher level of data integrity. ie: SDPD rxc fnm=c:\SDPD\test.txt The above would receive/download to a file named test.txt in a directory named SDPD on the C drive. sxk - This command has no arguments and receives data and stores it to a file specified by the fnm command using XModem-1k. XModem-1k is an improvement on the original XModem. It provides a 16 bit CRC (cyclic redundancy check) block check for the original checksum as well as using 1024 byte blocks rather than the original 128 byte blocks. This gives you a higher level of data integrity and a faster transfer. ie: SDPD rxk fnm=c:\SDPD\test.txt The above would receive/download to a file named test.txt from a directory named SDPD on the C drive. rxg - This command has no arguments and receives data and stores it to a file specified by the fnm command using XModem-1kG. XModem-1kG is an improvement on the original XModem. It provides a 16 bit CRC (cyclic redundancy check) block check for the original checksum, uses 1024 byte blocks rather than the original 128 byte blocks, and performs a streaming transfer. A streaming transfer means that the transmitter continuously transfers blocks without waiting for acknowledgements. This gives you a higher level of data integrity and a faster transfer, but it should never be used with non error correcting modems. If you are using a non error correcting modem, and the receiver receives a bad block, the transfer will be aborted. ie: SDPD rxg fnm=c:\SDPD\test.txt The above would receive/download to a file named test.txt in a directory named SDPD on the C drive. 7 - YModem Ymodem is basically the same as XModem-1k with batch file transfer ability. This means a single YModem transfer can transfer as many files as you wish. It also provides the receiver with information about the incoming files such as: file name, size, date. Options sy - This command has no arguments and starts a transfer of a file specified by the fnm command, or the @fl command, using YModem. ie: SDPD sy fnm=c:\SDPD\test.txt The above would transfer/upload a file named test.txt from a directory named SDPD on the C drive. syg - This command has no arguments and starts a transfer of a file specified by the fnm command, or the @fl command, using YModemG. YModemG is a streaming protocol. A streaming protocol means that the transmitter continuously transfers blocks without waiting for acknowledgements. This gives you a faster transfer, but it should never be used with non error correcting modems. If you are using a non error correcting modem, and the receiver receives a bad block, the transfer will be aborted. ie: SDPD syg fnm=c:\SDPD\test.txt The above would transfer/upload a file named test.txt from a directory named SDPD on the C drive. ry - This command has no arguments and receives data and stores it to a file specified by the fnm command using YModem. If the fnm command is not specified you could use the dd command to specify the destination directory and the protocol would use the incoming filename and store it in that directory. Without the dd command and the fnm command YModem will simply store the file, using the incoming name, to the current directory. ie: SDPD ry The above would receive/download a file using the incoming name into the current directory. ryg - This command has no arguments and receives data and stores it to a file specified by the fnm command using YModemG. YModemG is a streaming protocol. A streaming protocol means that the transmitter continuously transfers blocks without waiting for acknowledgements. This gives you a faster transfer, but it should never be used with non error correcting modems. If you are using a non error correcting modem, and the receiver receives a bad block, the transfer will be aborted. ie: SDPD ryg fnm=c:\SDPD\test.txt The above would receive/download a file named test.txt in a directory named SDPD on the C drive. n1k - This command has no arguments and simply tells SDPD to use 128 byte blocks rather than 1024 byte blocks. ie: SDPD ry n1k dd=c:\SDPD The above would receive data in 128 byte blocks and store it to a file, using the incoming name, in a directory named SDPD on the C drive. nrx - This command has no arguments and simply tells SDPD not to use the the relaxed state for the transfer. By default, YModem uses a XModem relaxed state. Using this option tells YModem to implement 5 second timeouts rather than 10 second timeouts. ie: SDPD ry n1k nrx The above would receive data in 128 byte blocks, use 5 second timeouts, and store it to a file, using the incoming name, in a directory named SDPD on the C drive. 8 - ZModem Zmodem was developed by Chuck Forsberg under contract to Telenet. It was developed for the public domain and its purpose was to provide a durable protocol with strong error recovery features and good performance over a variety of network types (satellite, switched, etc.). For the most part is has achieved these goals and is by far the best choice overall. ZModem offers the best overall mix of speed, features, and tolerance for errors. This protocol has lots of room for growth, and many options. Unlike XModem and YModem, Zmodem employs headers, data subpackets, and frames. This allows ZModem to implement many features that other protocols simply cannot achieve. ZModem will do its best to correct errors in the transmission. It does this by a variety of ways. It will use file recovery if the transfer was aborted and it will also increment and decrement block sizes to compensate for errors. For instance, if you are using the 8k option with ZModem and you get a noisy line ZModem will drop to 1k blocks and if the errors still occur will then try 512 byte blocks. If the errors still persist it will try 256 byte blocks as a last resort. After it has tried the 256 byte blocks, if the errors still persist, it will abort the transfer. ZModem offers batch transfers. Options sz - This command has no arguments and simply transmits a file specified by either the fnm command or the @fl command. ie: SDPD com=2 ugd sz fnm=c:\SDPD\test.txt The above would transmit/upload a file named test.txt in a directory named SDPD on the C drive. It also uses COM 2 and provides graphical display. rz - This command has no arguments and simply receives a file specified by either the fnm command or the @fl command or the incoming name is used. The destination directory of the file can be specified by the dd command. ie: SDPD rz dd=c:\SDPD The above would receive/download a file using the incoming name to a directory named SDPD on the C drive. It defaults to COM1. rzr - This command has no arguments and simply instructs ZModem to use the file recovery option. File recovery allows you to resume a transfer at the point it left off. The following will explain a little better: Suppose you are doing a batch transfer of three files. To simplify things the files are named A, B, and C. File A = 12000 bytes File B = 14000 bytes File C = 25000 bytes You start the transfer and File A is completed but when you are at byte 7000 of file B the transfer aborts. If you implemented the file recovery option the following would occur: File A would not be transferred since it already exists on the remote system. File B would start off at byte 7000 File C would be transferred completely. All 3 files would be in the exact shape you wish them to be on the remote system. ZModem offers several file management routines. These are simple rule that tell ZModem to accept a file or not. As a general rule all file management specifications are defined by the transmitter. However, SDPD implements an option that allows the receiver to override this functionality. The following is a list of file management options. Only one option can be specified at a time. zf1 - This command has no arguments and instructs ZModem to transfer the file and overwrite the existing file only if the file being transferred is newer or longer than the existing file. zf2 - This command accepts no arguments and acts the same as zf4. Refer to the command zf4 for more information. zf3 - This command has no arguments and instructs ZModem to transfer the file and overwrite the existing file regardless of anything. zf4 - This command has no arguments and instructs ZModem to transfer the file and overwrite the existing file only if it is new. Otherwise, it will append to the existing file. zf5 - This command has no arguments and instructs ZModem to transfer the file and overwrite the existing file only if it is new or newer than the existing file. zf6 - This command has no arguments and instructs ZModem to transfer the file and overwrite the existing file only if it is new or its date or size if different from the existing file. zf7 - This command has no arguments and instructs ZModem to transfer the file only if the file does not exist. z8k - This command has no arguments and simply tells ZModem to implement large subpackets. This sets the subpacket size to 8k, (8192 bytes). This provides a faster transfer as a general rule. zov - This command has no arguments and simply tells ZModem to ignore the transmitting systems filemanagement options and implement those specified on this end of the transfer. skn - This command has no arguments and simply tells ZModem not to receive files that do not already exist. 9 - Kermit This protocol was developed to enable transfers in environments that other protocols cannot handle. Examples of these environments are links that only pass 7 data bits, links that can't handle control characters, computer systems that can't handle large blocks, and other specialized links such as a PC and a mainframe. This protocol was developed for the public domain at Columbia University in New York City. The name Kermit actually refers to Kermit the Frog from The Muppet Show. To receive the complete description of this protocol write to Columbia University, Kermit Distribution, Department OP, 612 West 115th Street, NY, NY,10025. Options sk - This command has no arguments and simply transmits/uploads a file specified by either the fnm command or the @fl command. ie: SDPD sk fnm=c:\SDPD\test.txt The above transmits/uploads a file named test.txt in a directory named SDPD on the C drive using Kermit. rk - This command has no arguments and simply receives/downloads a file specified by either the fnm command or uses the incoming file name. If using the incoming file name you can specify the destination directory by using the dd command. ie: SDPD rk dd=c:\SDPD The above receives downloads a file(s), using the incoming name(s) to a directory named SDPD on the C drive using Kermit. kpl - This command accepts a numeric argument that specifies the maximum length of the data field for kermit. ie: SDPD rk kpl=80 The above would receive/download a file(s), using the incoming name(s), to the current directory and set the data fields length to 80 characters. mto - This command accepts a numeric argument that specifies the maximum time out between characters in seconds. ie: SDPD rk mto=10 The above would receive/download a file(s), using the incoming name(s), to the current directory and tell Kermit to issue a timeout after a delay of 10 seconds. kpc - This command accepts a numeric argument that specifies the number of pad characters that will be transmitted before a packet. The usual reason for implementing pad characters is that the remote system is slow in switching from receive mode to transmit mode and visa-versa. ie: SDPD rk kpc=10 kpk=13 The above would receive/download a file(s), using the incoming name(s), to the current directory and tell Kermit to transmit 10 carriage returns between each packet. kpk - This command accepts a numeric ASCII representation argument that specifies the character to use to pad transmissions. This command must be used in conjunction with the kpc command. ie: SDPD rk kpc=10 kpk=13 The above would receive/download a file(s), using the incoming name(s), to the current directory and tell Kermit to transmit 10 carriage returns at then beginning of each packet. ktm - This command accepts a numeric ASCII representation argument that specifies the character to use for an EOL, End of Line, character. This command should rarely be changed. It is only required by systems that need some sort of EOL character before they can start processing. ie: SDPD rk ktm=13 The above would receive/download a file(s), using the incoming name(s), to the current directory and tell Kermit to send a carriage return at the end of each packet. kcp - This command accepts a numeric ASCII representation argument that specifies the prefix character Kermit uses when quoting control characters. ie: SDPD rk ktm=13 The above would receive/download a file(s), using the incoming name(s), to the current directory and tell Kermit to use a carriage return as the control prefix. khp - This command accepts a numeric ASCII representation argument that specifies whether Kermit will use high bit prefixing or not. There two valid arguments for this command they are 89, (Y), and 78, (N). Kermit defaults to 89, (Y). ie: SDPD rk khp=78 The above would receive/download a file(s), using the incoming name(s), to the current directory and tell Kermit not to use high bit prefixing. kch - This command accepts a numeric argument that specifies the check method that Kermit will utilize. 1 is a one byte checksum, 2 is a two byte checksum, and 3 is a three byte CRC. Kermit defaults to 1. ie: SDPD rk kch=3 The above would receive/download a file(s), using the incoming name(s), to the current directory and tell Kermit to verify the integrity of each packet by using a three byte CRC. krp - This command accepts a numeric ASCII representation argument that specifies the repeat prefix character that will be used when Kermit compresses repeat strings of characters. Kermit defaults to 126, (~). ie: SDPD rk krp=13 The above would receive/download a file(s), using the incoming name(s), to the current directory and tell Kermit to use a carriage return as the repeat prefix character. kml - This command accepts a numeric argument that specifies the length for a long packet. A long packet is an extension to standard Kermit that permits data packets of up to 1024 bytes. Long packets can substantially improve protocol throughput on relatively clean connections that have small turnaround delays. To keep within the design intentions for long packets as expressed in the Kermit Protocol Manual, long packet support is turned off by default and must be specifically enabled. In most cases it will probably be turned off at the remote end as well. Kermit defaults to this option being set off. ie: SDPD rk kml=1024 The above would receive/download a file(s), using the incoming name(s), to the current directory and tell Kermit to use a packet length of 1024 bytes. kws - This command accepts a numeric argument that specifies the size of the sliding windows you will be using. Sliding Windows Control, also called "SuperKermit.", provides a send-ahead facility that can dramatically improve protocol throughput under conditions where turnaround delays tend to be large, such as across satellite links. "Send-ahead" means that the transmitter sends many blocks at once, without waiting for an acknowledgement for each block. It collects acknowledgements when they eventually arrive and marks the previously transmitted blocks as acknowledged. This minimizes turnaround delay (the time it takes the receiver to send an acknowledgement) to zero -- significantly improving throughput. SWC works by keeping a circular table of transmitted packets -- the maximum number of packets in this table is called the "window size." The window size is selected at runtime and must be between 0 and 31 (0 meaning no sliding window support). If the transmitter and receiver specify different window sizes the smaller of the two will be used. As each packet is transmitted it is added to the table. When an acknowledgment is eventually received for that packet the table is rotated (i.e. the oldest acknowledged packet is discarded). If the table fills the transmitter won't send any more packets until it receives acknowledgements for one or more existing packets. SDPD doesn't allow mixing of long packets and SWC. While it's theoretically possible to do so (and the Kermit Protocol specification allows it) the memory required would excessive. Since we expect the majority of Kermit implementations to be aimed at BBS and general-purpose communications use, where the link is usually PC-to-PC and turnaround delays are small, SDPD will always choose long packets over SWC. By default SWC is off. ie: SDPD rk kws=10 The above would receive/download a file(s), using the incoming name(s), to the current directory and tell Kermit to use a sliding window size of 10. ktd - This command accepts a numeric argument that specifies the turn around delay, in tics, when using Sliding Windows Control. Kermit defaults this to 1000. ie: SDPD rk ktd=2000 The above would receive/download a file(s), using the incoming name(s), to the current directory and tell Kermit to set the sliding window turn around delay to 2000 tics. kns - This command has no arguments and simply specifies whether Kermit will strip the directory information from file names before sending the file name packet. Kermit defaults this to off. ie: SDPD rk kns The above would receive/download a file(s), using the incoming name(s), to the current directory and tell Kermit to strip directory information from file names before sending the file name packet. 10 - General These options allow you to use SDPD in a myriad of ways and in many environments. These control things such as DTR, RTS, CTS, DSR, graphical displays, destination directories, etc. Options gid - This command has no arguments and simply tells SDPD to include directory names in the file information packet when transmitting files. Not all protocols support file information packets. ie: SDPD sz gid fnm=c:\SDPD\test.txt The above would transmit/upload a file named test.txt from a directory named SDPD on the C drive. It would also include c:\SDPD\test.txt in the file info packet as opposed to test.txt. ghd - This command has no arguments and simply tells SDPD to try and honor the incoming directory names. This does not mean that it will create directories. If the path does not exist it will save the file in the current directory or the directory specified by the dd command. This is not supported by ASCII and all XModem protocols. SDPD defaults this to off. ie: SDPD rz ghd dd=c:\SDPD The above would receive/download a file(s) using the incoming name(s). SDPD will check the pathing of each file being received and if the path exists will store the file in that directory. If the path does not exist, it will store it in the specified by the dd command. grl - This command has no arguments and all SDPD protocols will force RTS off while writing received data to disk (temporarily preventing the modem from sending additional data). RTS is turned back on as soon as the disk write is finished. This option might be required when running SDPD under some multi-tasking operating systems or in network environments that leave interrupts disabled while writing to network devices. SDPD defaults this to off. ie: SDPD rz grl The above would receive/download a file(s) into the current directory using COM 1 and using the incoming file names. It would also lower the RTS signal every time the data was written to disk. dhw - This command accepts a numeric argument that specifies the amount of time, (in tics), to wait before retrying a handshake signal. Note: ASCII does not use handshaking and the ZModem default is 60 seconds/1092 tics as opposed to the 10 second/182 tic default for all other protocols. This will usually be used in conjunction with the dhr command. ie: SDPD rz dhw=120 dhr=20 The above would receive/download a file(s) using ZModem, COM1, the current directory as the destination, incoming file name(s), and would set the handshake to a 120 second/1092 tic timeout with 20 retries. dhr - This command accepts a numeric argument that specifies the maximum number times to retry a handshake before aborting the protocol. This will usually be used in conjunction with the dhw command. ie: SDPD rz dhw=120 dhr=20 The above would receive/download a file(s) using ZModem, COM1, the current directory as the destination, incoming file name(s), and would set the handshake to a 120 second/1092 tic timeout with 20 retries. dtt - This command accepts a numeric argument that specifies the number of tics to wait for a receiver flow control release. SDPD defaults this to 1092 ie: SDPD rz dtt=182 The above would receive/download a file(s) using COM1, ZModem, the current directory as the destination, and set the timeout for a receiver flow control release to 182 tics/10 seconds. dsi - This command accepts a numeric argument that specifies the amount of time to wait between updates to the status screen in tics. SDPD defaults this to 91 tics/5 seconds ie: SDPD rz dsi=182 The above would receive/download a file(s) using COM1, ZModem, the current directory as the destination, and set the status screen update interval 10 182 tics/10 seconds. This may improve throughput but it will rarely be noticed. bfc - This command accepts a numeric ASCII representation argument that specifies the fill character for partial protocol blocks. A block fill character is used to fill the last block transmitted by a protocol that doesn't keep track of the file size. SDPD defaults this to 26/^Z ie: SDPD rx bfc=13 The above would receive/download a file(s) using COM1, XModem, the current directory as the destination, and set the block fill character to a carriage return. gho - This command accepts a numeric argument that specifies the difference, in hours, between the current time zone and the Greenwich Meridian Time (GMT). The specifications for YModem and ZModem state the file creation date stamp should be referenced to GMT. In order to meet this specification both the receiver and transmitter must adjust the time stamp by the difference between the current time zone and the GMT time zone. In practice, most YModem and ZModem implementations ignore this. SDPD defaults this to 0. ie: SDPD rz gho=1 The above would receive/download a file(s) using COM1, ZModem, the current directory as the destination, and set the GMT offset to 1 hour. td - This command accepts a numeric argument that specifies the Telix delay, (in tics). You will usually never need this. SDPD defaults this to 9 ie: SDPD rz td=12 The above would receive/download a file(s) using COM1, ZModem, the current directory as the destination, and set the Telix delay to 12 tics. dd - This command accepts a character string argument that specifies the destination directory for received files. This option will be used depending on other options selected. SDPD defaults this to a blank, meaning the current directory. ie: SDPD rz ghd dd=c:\SDPD The above would receive/download a file(s) using the incoming name(s). SDPD will check the pathing of each file being received and if the path exists will store the file in that directory. If the path does not exist, it will store it in the specified by the dd command. fln - This command accepts a character string argument that specifies the path and name for the file log. The file log will log information about your transfers. The logging capabilities are only activated if a name and path are specified. Otherwise SDPD will not log transfer information. This file is an ASCII text file. SDPD defaults this to blank, meaning no logging capabilities. ie: SDPD rz fln=c:\SDPD\SDPD.log The above would receive/download a file(s) using COM1, ZModem, the current directory as the destination, and saves transfer information in a file named SDPD.log in a directory named SDPD on the C drive. oh - This command accepts a numeric argument that specifies the number of overhead bytes per block. This does not affect the block sizes for the protocols. It is simply a modification procedure for efficiency calculations on the status screen. This could be handy when using directly linked PCs. ie: SDPD rz oh=256 std=500 The above would receive/download a file(s) using COM1, ZModem, the current directory as the destination, set the overhead block size to 256, and set the turn around delay to 500. std - This command accepts a numeric argument that specifies the turn the time, (in milliseconds), that it takes the block to get to the remote, for the remote to acknowledge and for that acknowledgement to reach us. It is simply a modification procedure for efficiency calculations on the status screen. This could be handy when using directly linked PCs. ie: SDPD rz oh=256 std=500 The above would receive/download a file(s) using COM1, ZModem, the current directory as the destination, set the overhead block size to 256, and set the turn around delay to 500. fs - This command has no arguments and simply tells SDPD to always update the status screen. si - This command acts the same as the dsi command. sab - This command accepts a numeric argument that sets the actual BPS (needed only if modem differs from port). This routine may be used in cases such as the following: - Two machines are communicating at 9600 BPS via MNP or v.32 modems - Both modems are using their built in data compression facilities to increase the effective BPS rate - The machines are communicating at a rate of 19200 baud to insure that the modem doesn't have to waste time waiting for data to send, and they are using hardware flow control to pace the flow of data between the modems and machines In such a case the protocol will base any transfer rate calculations on a BPS rate of 19200, the rate at which the data is being sent to the modem, and it will under estimate the efficiency of the transmission, since the data isn't actually being sent to the remote at that rate. To get more accurate calculations in this case you would set the actual BPS to 9600, the rate at which the data is being sent to the remotes modem. The calculations will be slightly inaccurate but will better reflect the actual efficiency. ie: SDPD rz sab=9600 The above would receive/download a file(s) using COM1, ZModem, the current directory as the destination, and set the actual BPS to 9600 soo - This command accepts a numeric argument in the range of 1 to 3. It sets option for what to do when the destination file already exists. The following is a list of actions SDPD will take when using this option: 1 - Will abort the transfer 2 - Will rename the incoming file and write to that name 3 - Will overwrite the file SDPD defaults this to 1 ie: SDPD rz soo=2 The above would receive/download a file(s) using COM1, ZModem, the current directory as the destination, and would rename the incoming file(s) if they already exist. ugd - This command has no arguments and simply tells SDPD to use the graphical display as opposed to the ASCII display. The graphical display looks best on machines with color monitors and offers more statistical information. @fl - This command accepts a character string argument that specifies the path and name to the list of files you wish to transfer. This file is an ASCII text file with each file/path on a separate line. This will allow you to set up batch transfers easily and quickly. com - This command accepts a numeric argument between 1 and 36. It specifies the comport you wish to use. 1 = COM1, 2 = COM2, etc.. ie: SDPD rz com=2 The above would receive/download a file(s) using COM2, ZModem, the current directory as the destination, and would rename the incoming file(s) if they already exist. bd - This command accepts a numeric argument that specifies the baud rate, that is different from the current port, you wish to use. This should rarely be used. ie: SDPD rz com=2 bd=2400 The above would receive/download a file(s) using COM2, ZModem, the current directory as the destination, would rename the incoming file(s) if they already exist, set the baud rate to 2400. irq - This option accepts a character string argument that equates to Non-Standard IRQs and/or base addresses. This is accomplished by the following rules: 1 - Irq value must be in the range of 0 and 15. 2 - Base Address is Hexadecimal string. 3 - The irq value must be specified first, then a /, the the hexadecimal base address string. ie: SDPD rz com=2 bd=2400 irq= 7/02E8 The above would receive/download a file(s) using ZModem, the current directory as the destination, would rename the incoming file(s) if they already exist, set the baud rate to 2400, and define COM2 as using interrupt 7 and address 2E8. fnm - This command accepts a character string argument which specifies the name/path for a file to be transferred or received. ie: SDPD rz com=2 bd=2400 irq= 7/02E8 fnm=c:\SDPD\test.txt The above would receive/download a file(s) using ZModem, the current directory as the destination, would rename the incoming file(s) if they already exist, set the baud rate to 2400, define COM2 as using interrupt 7 and address 2E8, and receive a file named test.txt to a directory named SDPD on the C drive. inb - This command accepts a numeric argument that defines the size of the input buffer. SDPD defaults this to 4096 ie: SDPD rz com=2 bd=2400 irq= 7/02E8 fnm=c:\SDPD\test.txt inb=1024 The above would receive/download a file(s) using ZModem, the current directory as the destination, would rename the incoming file(s) if they already exist, set the baud rate to 2400, define COM2 as using interrupt 7 and address 2E8, receives a file named test.txt to a directory named SDPD on the C drive, and sets the input buffer to 1024 bytes. otb - This command accepts a numeric argument that defines the size of the output buffer. SDPD defaults this to 4096 ie: SDPD rz com=2 bd=2400 irq= 7/02E8 fnm=c:\SDPD\test.txt otb=1024 The above would receive/download a file(s) using ZModem, the current directory as the destination, would rename the incoming file(s) if they already exist, set the baud rate to 2400, define COM2 as using interrupt 7 and address 2E8, receives a file named test.txt to a directory named SDPD on the C drive, and sets the output buffer to 1024 bytes. par - This command accepts a character string argument that changes the current parity type. Valid arguments are as follows: NoParity OddParity EvenParity MarkParity SpaceParity ie: SDPD rz par=NoParity The above would receive/download a file(s) using ZModem, the current directory as the destination, COM1, and set the parity to None. stb - This command accepts a numeric argument that overrides the current stop Bit value. Valid range is 1 to 2. ie: SDPD rz par=NoParity stb=2 The above would receive/download a file(s) using ZModem, the current directory as the destination, COM1, sets the parity to None, and sets the stop bits to 2. dtb - This command accepts a numeric argument that overrides the current data bit value. Valid range is 5 to 8. ie: SDPD rz par=NoParity stb=2 dtb=6 The above would receive/download a file(s) using ZModem, the current directory as the destination, COM1, sets the parity to None, sets the stop bits to 2, and sets the data bits to 6. hud - This command has no arguments and simply tells to utilize DTR for Receive Flow Control ie: SDPD rz hud The above would receive/download a file(s) using ZModem, the current directory as the destination, COM1, and implement a DTR hardware flow control method. hur - This command has no arguments and simply tells to utilize RTS for Receive Flow Control ie: SDPD rz hur The above would receive/download a file(s) using ZModem, the current directory as the destination, COM1, and implement a RTS hardware flow control method. hrd - This command accepts no arguments and simply tells SDPD to require a DSR signal before transmitting ie: SDPD rz hrd The above would receive/download a file(s) using ZModem, the current directory as the destination, COM1, and would require a DSR signal before transmitting. hrc - This command accepts no arguments and simply tells SDPD to require a CTS signal before transmitting ie: SDPD rz hrc The above would receive/download a file(s) using ZModem, the current directory as the destination, COM1, and would require a CTS signal before transmitting. hdl - This command has no arguments and simply tells SDPD to set the DTR signal low. ie: SDPD rz hdl The above would receive/download a file(s) using ZModem, the current directory as the destination, COM1, and would set the DTR signal low. hrl - This command has no arguments and simply tells SDPD to set the RTS signal low. ie: SDPD rz hrl The above would receive/download a file(s) using ZModem, the current directory as the destination, COM1, and would set the RTS signal low. hsl - This command has no arguments and simply tells SDPD to set the DSR signal low. ie: SDPD rz hsl The above would receive/download a file(s) using ZModem, the current directory as the destination, COM1, and would set the DSR signal low. hcl - This command has no arguments and simply tells SDPD to set the CTS signal low. ie: SDPD rz hcl The above would receive/download a file(s) using ZModem, the current directory as the destination, COM1, and would set the CTS signal low. rpg - This command accepts no arguments and tells SDPD to return whatever exists in the input buffer if it is a partial block. rd - This command accepts no arguments and tells SDPD to return the delimiter character used as well as the string it delimits. epp - This command accepts no arguments and tells SDPD to store as much data as possible, in the output buffer, if there is not enough room to store the whole block. idc - This command has no arguments and tells SDPD to treat characters in a delimited set with case sensitivity. roc - This command has no arguments and simply tells SDPD to restore the UART to its original state when the session is completed. dmc - This command has no arguments and simply tells SDPD to hangup the modem when the session is completed. rmo - This command accepts no arguments and tells SDPD to raise the DTR and RTS signals when the session is started. idt - This command has no arguments and tells SDPD not to initialize the port with DTR low. irt - This command has no arguments and tells SDPD not to initialize then port with RTS low. pcb - This command has no arguments and tells SDPD to display the current users name, in PCBoard, inside the information screen. dsz - This command has no arguments and tells SDPD to adhere to DSZ standards. This will allow you to setup SDPD as a DSZ protocol inside PCBoard. 11 - Flip Screens SDPD has 2 flip screens that allow you to access information about protocols and settings while the transfer is progressing. F1 give you information on protocols and port setup. F2 gives you information on the general options. This is only available in graphics mode. 12 - Additional Programs With the SDPD bundle you will receive four programs designed to help you define various values for the commands specified in this manual. SEC2TIC.EXE - This program will allow you to find out what the proper tic value is for a value in seconds. These conversions depend on your system so be sure to run it at least once. TIC2SEC.EXE - This program will allow you to find out what the proper second value is for the tics specified. These conversions depend on your system so be sure to run it at least once. MILL2SEC.EXE - This program will tell you what the specified millisecond value equates to in seconds. SEC2MILL.EXE - This program will tell you what the specified second value equates to in milliseconds. 13 - Registration Upon Registering SDPD you will receive a serialized copy of SDPD that will allow you to access many other features. Pricing and taxation is based upon the shipping point. You can order SDPD online at Streamline Design or The Support Group using a VISA or Mastercard. You can also order over the phone using VISA or Mastercard. ------------------------------------------------------------------------------- Order Form ------------------------------------------------------------------------------- Addressing Information Billing Address Shipping Address Name : ________________________ Name : ________________________ Company : ________________________ Company : ________________________ Department : ________________________ Department : ________________________ Address : ________________________ Address : ________________________ : ________________________ : ________________________ : ________________________ : ________________________ Prov/State : ________________________ Prov/State : ________________________ City : ________________________ : ________________________ Country : ________________________ Country : ________________________ Postal/ZIP : ________________________ Postal/ZIP : ________________________ Phone 1 : ________________________ Phone 1 : ________________________ Phone 2 : ________________________ Phone 2 : ________________________ Product Information - Please Ship [ ] Will Download [ ] Please allow 3 to 4 business days upon receipt for processing. Shipping Media 3 1/2 inch, 720 Diskette [ ] 3 1/2 inch, 1.44 Diskette [ ] 5 1/4 inch, 360 Diskette [ ] 5 1/4 inch, 1.2 Diskette [ ] Download Media ZIP File Format Ver 1.02 [ ] LHARC File Format Ver 1.13 [ ] ARJ File Format Ver 2.22 [ ] PKPAK File Format Ver 3.61 [ ] Quantity 1 to 9 : ____________ x 35.00 = Subtotal: ________________ Quantity 10 to 24 : ____________ x 32.00 = Subtotal: ________________ Quantity 25 to 49 : ____________ x 28.00 = Subtotal: ________________ Quantity 50 to 99 : ____________ x 20.00 = Subtotal: ________________ Quantity 100 and above, please call. Ontario Residents add 7% Sales Tax Taxation: ________________ and 8% GST The Rest of Canada add 8% GST Add 5.00 for Shipping and handling Shipping: ________________ Total : ________________ Credit Card Information Name on Card : _________________ Card Type: VISA [ ] MasterCard [ ] Credit Card # : _________________ Expiry : _______ Thank You for using The Streamline Design Protocol Module