Year 2000


About Us  .   Our Products  .   Support Options  .   Buy our Products    

Frequently Asked Questions

Contents and Organization of this FAQ

Section One - Contacting Us

Section Two - BLAST Product and Media Codes

Section Three - Scripting Questions

Section Four - File Transfer Protocols

Section Five - File Transfer Protocols - The Nuts and Bolts

Section Six - Flow Control

Section Seven - DOS Professional Issues

Section Eight - MacBLAST Professional Issues

Section Nine - Unix Professional Issues

Section Ten - Miscellaneous Issues

Section One - Contacting Us

Q. Who do I contact concerning BLAST products?

  • Phone Numbers:
    • +44 (0)1728 832712 - Sales or Tech Support
    • +44 (0)1728 830196 - Fax

  • Mailing Address:
    Open Communications International Ltd
    Colonial House
    Leiston, Suffolk
    IP16 4JD

  • E-Mail Addresses:

  • World Wide Web Address:

Section Two - BLAST Product and Media Codes

Q. How do I interpret the product description? (see Media Codes and Pricing)

A. 3/486PRO-UNX/XEN-S-10.7, for example, is interpreted as follows:

	3/486PRO (386/486 Professional) = Hardware/Product Name
	UNX/XEN (UNIX/XENIX) = Operating System
	S (3.5" diskette) = Media Code
	10.7 = Version

Q. How do I interpret product media codes

A. MEDIA CODES (see Product Description and Pricing)

	C = QIC tape
	D = 4mm DAT/DDS tape
	H = 1600 bpi tape/9 track tape
	S = 3.5" diskette
	T = 5.25" diskette
	E = 150 MB cartridge
	K = TK50 tape cartridge
	D/S = 4mm DAT/DDS tape & 3.5" diskette

Section Three - Scripting Questions

Q. What is BLASTscript?

A. BLASTscript is a programming language designed to automate communications tasks. BLASTscript allows:

  • Automation of regularly performed file transfer tasks
  • Unattended polling of remote sites through the supplied Autopoll script.
  • Automated modem initialization and dialing through the modems.scr script.
  • Automated logon procedures for many multi-user systems through the systems.scr script.

BLASTscript provides a variety of commands for tasks like sending and capturing characters, manipulating files, sending and receiving files, parsing, executing local and remote system commands, logging, branching and conditional execution.

BLASTscript also provides a variety of reserved variables to allow monitoring of the status of script execution and to change parameters of a scripting session.

Q. I'd like to write a script to automate a communications task. How do I start?

A. Begin by practicing the steps manually a few times to familiarize yourself thoroughly with the task. Then place BLAST in Learn mode and repeat the task again. While in Learn mode, BLAST will create a script from the actions you take.

Think of this as a rough draft; you will need to add your own comments and scripting code to handle communications errors and other exceptions.

Q. What are modems.scr and systems.scr?

A. Modems.scr and systems.scr are special scripts that automate the logon and dial-out processes in BLAST. For example, if you enter Unix as the system type and HAYES as the modem type in a BLAST setup, BLAST will automatically know how to dial out on your HAYES modem and logon to the remote Unix system. These scripts are automatically installed by BLAST. They are updated periodically and the latest version is always available on Blaster and the BLAST anonymous FTP site. There are specific modems.scr scripts for Unix, DOS, and BHOST, named, modems.scr.uni, modems.scr.dos, and modems.scr.bho.

Q. How do I obtain the latest modems.scr and systems.scr?

A. The latest modems.scr and systems.scr scripts are kept on the BLAST anonymous FTP site. The script can be found in the pub/ directory on the anonymous FTP site. On the Blaster demo line the scripts are in the scripts/ directory.

Q. What is Autopoll?

A. Autopoll is a data collection and distribution script designed to dial from one to thousands of sites and perform reliable, automated transfer of data.

  • Autopoll is easy to modify. Autopoll can be used out of the box or as a template to build a customized polling system. It is written in BLAST's scripting language and is fully commented.
  • Autopoll is designed for hands-off operation. It requires no operator intervention.
  • Autopoll is easy to configure. An Autopoll network can be configured by creating just two text files: a site file and a transfer command file. A site file contains connection information for sites to be dialed. The transfer command file instructs BLAST on actions to be taken during a connection.
  • Autopoll checks for errors while polling. If a problem occurs during a communication session, Autopoll will automatically schedule to redial the problem site.
  • Autopoll creates an audit trail of transfers. If problems occur in the polling process, staff can easily determine where the problem occurred.
  • Autopoll is supplied with all supported BLAST products.

Q. How do I configure Autopoll?

A. Check out the autodocs.txt file supplied with autopoll. It is also available on the BLAST anonymous FTP site.

Q. How do I obtain the latest Autopoll?

A. The latest autopoll scripts are kept on the BLAST anonymous FTP site. The autopoll scripts can be found in the dist/scripts/autopoll/ directory on the anonymous FTP site. On the Blaster demo line the scripts are in the scripts/autopoll directory.

Section Four - File Transfer Protocols

Q. What is the BLAST Protocol?

A. Development of the BLAST protocol began in the mid 1970s. The BLAST protocol is sliding window protocol. It is designed to work over 7-bit and 8-bit connections and provide complete transparency for control characters. Therefore, it is compatible with both software and hardware flow control. The BLAST protocol uses a 16-bit CRC for error detection. Packet sizes can be set by the user from 84 bytes to 4084 bytes to maximize performance.

The BLAST protocol is more than a file transfer protocol. The BLAST protocol should be considered an error-free session protocol. BLAST is capable of transferring files and manipulating files on the remote machine. All file operations occur within the error-free BLAST session. It is not necessary to know the specific instructions for a particular operating system. BLAST automatically translates commands into the appropriate instruction for the remote system.

File Transfer Features:

  • Send Files
  • Receive Files
  • Send and Receive files simultaneously
  • Set file permissions and ownership during file transfer
  • Restart an interrupted file transfer from the point-of-interruption
  • Multiple levels of file compression during transfer
  • Text translation between systems
  • File overwrite
  • File append

File Manipulation Features:

  • Remote file rename
  • Remote file delete
  • Remote file printing
  • Remote change directory
  • Remote file listing

Tunable parameters

Q. What is the XMODEM Protocol?

A. The XMODEM protocol was developed in 1978 by Ward Christensen. The XMODEM protocol detects errors in transmission through use of either a checksum on old implementations or through a cyclical redundancy check (CRC) in later implementations. XMODEM uses a fixed packet size of 128 bytes and falls into the general category of Half-Duplex ACK/NAK protocols. It must pause after the transmission of every packet until it receives either an ACK or a NAK from the remote system. XMODEM has some significant limitations. For one, XMODEM only works on 8-bit connections. If you must make connections to devices that have 7-bit data paths, XMODEM will not work. Secondly, XMODEM must be run with either no flow control or hardware (RTS/CTS) flow control. If you attempt to run with software (XON/XOFF) flow control, your connection will hang. Thirdly, XMODEM provides no encoding or transparency for control characters. Thus if you attempt to transmit a binary file using XMODEM, the transmission is likely to hang if there are any XOFF characters in the data. Fourthly, XMODEM has no facility for transmitting the name of the file. You must enter the file name on the receiver side of the transmission. Finally, XMODEM was written to take advantage of the 128 byte CP/M file system. XMODEM pads files out to the nearest 128 bytes during transmission. Thus, it is impossible to retain the original file sizes using XMODEM.

Q. What is the KERMIT Protocol?

A. The KERMIT protocol was developed in 1981 at Columbia University and named after Kermit the Frog of the Muppet show. KERMIT runs over both 7-bit and 8-bit connections and is transparent to control characters. Due to its ability to run over both 7 and 8 bit connections and transparency, KERMIT is a more flexible and reliable protocol than XMODEM. However, additional overhead makes KERMIT slower than XMODEM. The original KERMIT is an ACK/NAK protocol using small but variable length packet sizes. Newer implementation of KERMIT support a sliding window protocol and are faster than the original KERMIT.

Q. What is the YMODEM Protocol?

A. The YMODEM protocol was developed in the early 1980's by Chuck Forsberg of Omen Technologies. The original intent was to make some simple extensions to the XMODEM protocol to improve performance. YMODEM uses a fixed packet size of 1024 bytes - 8 times the size of XMODEM. Even though it is a half-duplex ACK/NAK protocol, it is significantly faster. Because it uses larger packets, YMODEM spends much less time waiting for a response from the receiver than XMODEM. YMODEM also transmits the file name as part of the file transfer so that it is not necessary to enter a file name of the receiver end of the transmission. Unlike, XMODEM, YMODEM is capable of transmitting the exact file size. Otherwise, YMODEM has same limitations as XMODEM.

Q. What is the YMODEM-G Protocol?

A. YMODEM-G is a variant of YMODEM. YMODEM-G was designed to provide maximum performance over half-duplex modems that guaranteed error-free connections. Old, half-duplex modems were highly efficient at transmitting data in one direction. However, when they had to "turn-around" the direction of data transmission efficiency was lost. Thus, ACK/NAK protocols like XMODEM, YMODEM and KERMIT were very slow. YMODEM-G was designed to get around the limitations of old modems. It does not wait to receive ACKs or NAKs from the remote system. It streams packets of data constantly and assumes everything is received correctly. If an error occurs, the receiver sends an error signal which causes the entire file transfer to abort. As long as no errors occur in a YMODEM-G transfer there are few file transfer protocols with better performance. However, modern full-duplex modems do not suffer the same performance limitations of old half duplex modems and problems often do occur in filetransfers. Therefore, there is little advantage to using it.

Q. What is the ZMODEM Protocol?

A. ZMODEM was designed by Chuck Forsberg of Omen Technologies in the late 1980s. ZMODEM is a Sliding window protocol that uses variable packet sizes. ZMODEM works over both 7-bit and 8-bit connections. ZMODEM works with both software (XON/XOFF) flow control and hardware (RTS/CTS) flow control. ZMODEM also has the capability of restarting a file transmission from the point of interruption.

Q. What is FTP?

FTP stands for "File Transfer Protocol." Since its origination in the early 1970's, FTP has become the de facto standard for file transmission on TCP networks. FTP was designed to promote sharing of files across networks while shielding users from variations in how files are accessed and stored on different computers systems.

Like other file transfer protocols, FTP operates in a client/host fashion. FTP Client software is used to make a connection to an FTP Server. FTP client software generally has a user interface designed to facilitate file transfers and information requests like directory listings. There is no user interface to the FTP Server. It simply waits for a client to make a connection, presents a login prompt and fills requests for file transfers and information. On Unix machines, FTP server software is known as the FTP daemon or simply FTPd. On NT, an FTP server is called the FTP Service.

The FTP specification provides for many powerful features. For example, FTP can provide restart from the point of interruption, compression, and a variety of text translation functions. Unfortunately, few servers implement the complete FTP specification. So, while FTP is a powerful multi-platform file transfer tool, there are several shortcomings with most implementations of the protocol.

Most FTP clients and servers, including those found in BLAST products, provide only the "stream transmission mode." When transferring files in stream mode, the FTP specification requires that the FTP server close the data connection to indicate the end of file has been reached. Unfortunately, the FTP client has no way to differentiate between an actual loss of the network connection during a file transfer and the close of the connection after a successful transfer. According to the FTP specification - RFC959:

"The stream transfer mode is inherently unreliable, since one can not determine if the connection closed prematurely or not."
Therefore, some independent means of ascertaining that a file has been completely transferred must be used. There are various methods of determining if the file was completely transferred. If files are being transferred interactively, one usually notices that the transfer seemed rather quick or that the file is rather small. For automated transfers, packages such as Mirror get a file list from the FTP server. Then using the scripting capabilities of PERL, Mirror parses the file sizes out of the listing and compares it to the number of bytes actually received. If the sizes match, Mirror assumes the transmission was complete.

Secondly, provisions exist in the FTP specification for restarting a file transfer from the point of interruption. Few FTP servers and clients, however, actually implement this feature.

Finally, the FTP specification also has provisions for compressing files. Once again, however, few FTP servers and clients actually implement this feature.

Because so few FTP servers implement restart of file transfer from point of interruption and compression, BLAST's FTP clients do not support these capabilities.

Section Five - File Transfer Protocols - The Nuts and Bolts

Q. What is a Half-Duplex ACK/NAK Protocol?

A. A half duplex, or ACK/NAK, protocol sends a packet of data and then waits until it receives a response from the remote computer. The receiving computer will either send an acknowledgement (ACK) that the data was received correctly. Or the receiver will send a non-acknowledgment (NAK) if the data was corrupted. Performance of ACK/NAK protocols suffers due to the fact that they wait for a response from the remote computer prior to sending the next data packet. XMODEM and the original KERMIT protocols are examples of Half-Duplex ACK/NAK protocols.

ACK/NAK protocols should be avoided for use over packet switched networks. The propagation delays inherent in packet switched networks will cause extreme performance problems.

Q. What is a Streaming Protocol?

A. A streaming protocol sends a continuous stream of packets without waiting for a response. Because there is no waiting for the remote system to respond, the performance of a streaming protocol is better than an ACK/NAK protocol. Streaming protocols have no means of retransmitting corrupted data. They simply abort the transfer if any data is corrupted. An example of a streaming protocol is YMODEM-G.

Q. What is a Sliding Window Protocol?

A. A sliding window protocol is a special type of streaming protocol. Like a streaming protocol, a sliding window protocol sends a continuous stream of packets. Unlike a streaming protocol, a sliding window protocol expects to receive ACKs and NAKS from the receiving system. If the receiver sends a NAK, the sender will back up and resend the corrupted packet. A sliding window protocol will provide higher performance than an ACK/NAK protocol. The BLAST protocol and ZMODEM are examples of sliding windows protocols.

Q. What are checksums and CRCs?

A. All file transfer protocols must contain a method for determining if the data has been corrupted in transmission. Checksums and Cyclical Redundancy Checks (CRC) are mathematical checks for ensuring the integrity of data.

A file transfer protocol appends some type of check to the end of each packet of data. The receiver computes the same check on the received data. If the checks match, the data is accepted. Otherwise it must be retransmitted.

A checksum basically adds the values of each byte of data in a packet. Checksums are only considered reliable with very small packet sizes. As packet sizes increase, the probability increases that multiple errors can occur and not be detected.

A CRC is a more complicated calculation. Fortunately, calculating a CRC is not particularly computationally intensive and CRCs are much more reliable than checksums. The probability of multiple errors being undetected is practically zero. The ITU (which used to be known as the CCITT) recommends use of a 16-bit CRC for file transfer error-detection. BLAST uses a 16-bit CRC. Explaining how a CRC is calculated is beyond the scope of this FAQ. However, many lucid and understandable explanations of the mathematics and how to code CRCs are available in computer science and other programming texts.

Q. What is a packet?

A. All file transfer protocols break a file into pieces of a set length that are then transmitted to the remote system. These pieces of data along with some housekeeping information are known as packets. A packet usually has some header information like a sequence number. Following the header is the actual data being transmitted. At the end of the packet will be some type of checksum or CRC used by the remote end to validate the contents of the packet.

Different protocols use different packet sizes. For example, XMODEM uses a packet length of 128 characters. YMODEM uses a packet length of 1024 characters. The BLAST protocol allows the user to set the packet lengths from 84 characters up to 4084 characters.

Q. Does packet length matter?

A. Packet length will influence file transfer speed. The process of packetizing data increases the total amount of data to be transferred. Thus, larger packet sizes will reduce the total amount of overhead for any given file to be transferred.

Additionally, ACK/NAK protocols will have to wait for fewer ACKs and NAKs to be sent by the receiver if the packet size is larger. YMODEM achieves speed advantages over XMODEM by using a larger packet size.

In some cases, however, you will actually be better off with smaller packet sizes. For example, if a data packet is corrupted it must be retransmitted. If many packets are being corrupted due to a bad phone line or improper flow control, you will be better off using a smaller packet size. The BLAST protocol allows the user to set the packet size in order to tune the protocol for maximum performance. This is useful in situations where you may regularly have a large number of corrupted packets when transmitting files to a particular machine. You should set the packet size as small as possible when communicating with that site. Packet size should be set as large as possible when transferring files to machines that experience little data corruption.

For transmitting data over packet switched networks like X.25 and X.29 it is important to tune packet size to the network configuration in order to maximize performance and minimize overhead and cost of using the network. A BLAST technical note is available to guide you in setting the tunable parameters of the BLAST protocol for use over packet switched networks.

Q. What does window size mean?

A. The number of packets a sliding window protocol can transmit before it must stop and wait for acknowledgments is known as the window size.

Adjustable window sizes makes a sliding window protocol more flexible. For example, when other types of flow control are not available, it is sometimes useful to make a sliding window protocol work like an ACK/NAK protocol. This can be done with the the BLAST protocol by setting the Window Size to 1 and ACK request frequency to 1 in the BLAST protocol submenu.

Q. What is ACK request frequency?

A. The BLAST protocol packetizes ACK and NAK responses from the receiving system. This guarantees the integrity of the response from the remote system at the cost of a small amount of additional overhead resulting from the packetizing process. Overhead can be reduced by putting many responses into one packet. The number of responses per ACK packet is controlled by the ACK request frequency in the BLAST protocol submenu. The ACK request frequency can be set from 1 to the window size.

Section Six - Flow Control

Q. What is flow control?

A. Both serial ports and modems have data buffers. When data is received too quickly, these buffers get overrun causing data corruption. Flow control paces the data stream to prevent the loss of characters. It is crucial to have flow control properly set to maximize file transfer and terminal scrolling speeds. There are two types of flow control. One is Hardware, or RTS/CTS, flow control. The second is Software, or XON/XOFF, flow control.

Q. What is Hardware or RTS/CTS flow control?

A. Hardware or RTS/CTS flow control uses the RS-232 Request-To-Send (RTS) and Clear-To-Send (CTS) signals to pace the data stream. To successfully use RTS/CTS flow control, you must have the following: a modem cable with full modem controls, a correctly configured modem and some help from the operating system. In general, you should never attempt to use RTS/CTS flow control with a hardwired connection unless you have a special cable.

RTS/CTS flow control is very reliable, if your equipment and operating system support it correctly. Most DOS/Windows machines do a good job of supporting hardware flow control. Some Unix machines are capable of supporting it while others are not. To work correctly, the serial port device driver must raise the RTS signal when it is ready to receive data. The modem must only transmit data to the serial port when the RTS signal is high. The modem must raise the CTS signal when it is ready to transmit data to the remote modem. The serial port device driver must only transmit data to the modem when the CTS signal is high.

If you experience problems with RTS/CTS flow control on a Unix machine, it is likely the serial port device drivers do not support bi-directional flow control as described above. Some Unix device drivers are designed to raise the RTS signal when the serial port is ready to transmit data. The device driver then expects the modem to raise the CTS signal when it is ready to receive the data from the computer. In other words, RTS/CTS flow control is uni-directional. There is no provision for controlling the flow of data from the modem to the computer. Some modems can be configured for this type of RTS/CTS flow control. As long as the modems are not run at high speeds it will probably work acceptably. However, we recommend you use XON/XOFF flow control if your Unix machine does not support bi-directional RTS/CTS pacing.

Q. What is Software or XON/XOFF flow control?

A. Software or XON/XOFF flow control is based on use of the ASCII DC1 (XON) and DC3 (XOFF) characters. To start the flow of data an XON is inserted into the data stream. To stop the flow of data an XOFF is inserted into the data stream. The process is analogous to starting and stopping terminal scrolling by pressing the CTRL-S (XOFF) and CTRL-Q (XON) keys.

XON/XOFF flow control is very widely used and is quite reliable. However, there are some potential problems with it.

  • The file transfer protocol must not use the DC1 and DC3 characters to transmit data. If the file transfer protocol does not filter out DC1 and DC3 characters from the data, transmissions will hang because the modem will halt the flow of data upon receipt of an XOFF character. XMODEM and YMODEM can not be used with XON/XOFF flow control for this reason.
  • Starting and stopping of data does not happen in real time. XON/XOFF characters are inserted into the data stream and there may be a substantial delay between when they are issued and when they are received by the other device. This can cause data loss if the buffers are overrun in the meantime.
  • If the XON character is lost in transmission, the file transfer protocol must implement a procedure to restart transmission after some reasonable delay or the transfer will be irrevocably halted. The BLAST protocol, for example, will reset the device driver to begin transmitting data if it does not receive an XON within 30 seconds of receiving an XOFF character.
  • In complex communications environments, it is possible to have many different pieces of equipment attempting to control data flow. For example, the device driver for the serial port, modems, terminal server, and X.25 PADs can all be configured to assert flow control.

XON/XOFF flow control works successfully in one of two ways. In a simple environment a local flow control loop works best. In a more complex environment an end-to-end flow control loop is most likely to work. A local flow control loop is established when each modem is configured to act on the XON/XOFF characters sent by the attached computer. In this environment, the serial port device driver will issue an XOFF when its data buffers are full. In response to the XOFF character, the modem will halt the flow of data to the computer. The modem will resume transmission when it receives an XON from the computer. Likewise, the modem will issue an XOFF to the serial port when its buffers are full.

The modems must be configured to act on the flow control characters but not allow them to pass to the remote machine. No other devices should be configured to assert flow control. For best results, the modems should have an error-detecting connection established. With this type of connection, the modems will control the flow of data between themselves. BLAST does not recommend using a local flow control loop unless an error-detecting connection exists between the modems. By default this is the type of flow control loop BLAST establishes when XON/XOFF pacing is enabled.

In a more complex environment, or if error-detecting modems are not available, end-to-end XON/XOFF flow control should be used. In an end-to-end environment, the device driver will issue an XOFF when the serial port's data buffers are full. The XOFF character will pass through all devices to the remote computer, which will stop data transmission. When the buffers are empty, an XON will be issued to cause the remote machine to restart the flow of data. In similar fashion, if the remote machines's serial port data buffers fill up, it will issue an XOFF that causes the local machine to halt data transmission until an XON is received.

In this environment, all flow control should be disabled in the modems and all other equipment. You must manually configure the modems to do this or write your own script in modems.scr.

Section Seven - DOS Professional Issues

Q. I am using a PC with DOS and I have configured my modem for COM3. How do I initialize BLAST to work on these ports?

A. An important fact to keep in mind when setting up your modem is that names like COM1: and COM2: are just names for a CPU interrupt request number (IRQ) and a hardware base address. Fortunately, most of the world agrees that COM1: represents IRQ 4 and base address 3F8. COM2: represents IRQ 3 and base address 2F8.

There is no such agreement about what any other COM port represents. So, your correct IRQ and Base Address must be obtained by studying the documentation for your hardware. Diagnostics such as MSD or serial port settings in the control panel may also be useful.

To tell BLAST where to find the IRQ and Base Address for a serial port, edit the BLAST.OPT file in the directory where blast.exe is located. You can use any ASCII text editor like edit.exe or notepad.exe to edit the file. You may have to create a BLAST.OPT file if one does not already exist in the BLAST directory.

The format of the COMMPORT setting in BLAST.OPT is:

	COMMPORT=Label, IRQ, Base Address

Where Label is the name of the port, IRQ is the interrupt request number and Base Address is the hexadecimal hardware address of the serial port.

For BLAST to recognize a modem as COM3: at IRQ 5 and base address 3E8, place the following line in your BLAST.OPT file:


In addition, check that no other device or software attempts to share the IRQ used by your modem.

Below are some examples of BLAST.OPT settings for common COM3: and COM4:


You may notice that COM1: and COM3: apparently both use IRQ 4 and COM2: and COM4: both use IRQ 3. This is not a misprint and may lead the unaware to believe it is possible for two serial ports to share an interrupt. To guarantee error-free transmission of data, BLAST is unable to share interrupts. So, be certain your serial ports are configured to use unique IRQs.

Q. I am using the DOS version of BLAST under Windows. What can I do to optimize BLAST's performance in a DOS window?

A. When you install BLAST, the installation program asks if you are going to use BLAST under Windows. If you say yes, a line is added to your APPS.INF file. You may later create a BLAST.PIF file that has appropriate settings for running BLAST under Windows. Call BLAST Technical Support for further information on using BLAST under Windows.

Section Eight - MacBLAST Professional Issues

Q. Is MacBLAST Professional backwards compatible?

A. MacBLAST Professional will operate under Macintosh System 6 and 7. You can use scripts and setups created previously with MacBLAST 8.4; however, new commands and variables are supported in MacBLAST Professional and you may want to revise your scripts to take advantage of these new features. MacBLAST Professional resolves problems that MacBLAST 8.4 had under System 7.

Q. Can I use previously created keyboard maps with MacBLAST Professional?

A. The current version of the MacBLAST Utilities creates keyboard maps in a slightly different way in order to take advantage of the new format for Softkeys. You should create new keyboard maps for MacBLAST Professional using the current version of the MacBLAST Utilities rather than putting old maps into MacBLAST Professional.

Q. Does MacBLAST Professional still use keyboard shortcuts and Softkeys?

A. The keyboard shortcuts have been improved; you should look closely at the menu for changes in, and additions to, the shortcuts. Softkeys have also been made easier to use.

Q. Is there a special installation procedure for MacBLAST Professional?

A. Simply drag the MacBLAST folder from the original floppy diskette onto your hard drive. The first time that you launch MacBLAST Professional you will need to enter the serial number printed on the package and the diskette label. Be sure to keep the original MacBLAST Professional diskette write-protected and stored in a safe place. DO NOT run MacBLAST from the original diskette.

Q. Can MacBLAST Professional remote control a DOS PC?

A. No. MacBLAST has no remote control capabilities.

Section Nine - Unix Issues

Q. How does BLAST use device drivers on Unix systems?

A. Under Unix, BLAST does not manipulate the communications hardware directly. Instead, BLAST communicates with either a device driver for a serial port or the telnet daemon for network connections.

The serial port device driver negotiates all interaction with the hardware. For example, if you specify hardware flow control in the BLAST setup, BLAST attempts to set the device driver to use hardware flow control. BLAST has no control how hardware flow control is actually implemented in the device driver.

Q. How does BLAST make network connections?

A. BLAST makes network connections using your system's telnet program. Networking services must be correctly configured on your system for BLAST to make a successful connection. Proper configuration includes having the host name in /etc/hosts or using Domain Name Services. Connecting to a specific port number requires the port number be found in the /etc/services file. For more information on these configuration files, consult the hosts and services manual pages. For example to connect to a modem on port 3001 of a terminal server called ts01, the name ts01 must be resolvable via either the hosts file or Domain Name Services while the port is found in the services file. You can telnet to modem via BLAST by entering:

	ts01 3001

in the Connection field of the BLAST setup.

Q. How are serial ports controlled on SVR3 Unix systems?

A. On older SVR3 Unix systems, serial ports are handled by the system programs: init; getty; and login; and the inittab configuration file. These system programs form a tight init-getty-login-shell (IGLS) loop. In general, any attempt to control a serial port outside the IGLS cycle breaks the system's control of the resource and violates the Unix design philosophy. In other words, there is no provision within SVR3 Unix system to handle anything other than terminals attached either directly to a serial port or a terminal dialing into a modem attached to a serial port! You can attach a modem to a serial port to use for dial out purposes. However, if you want to use the same modem to dial out that Unix wants to control via the IGLS cycle you are violating the design of the Unix system. The implications of the IGLS design philosophy are profound for users and software developers.

The init process, process number 0, runs all the time. Every so often it reads the file /etc/inittab to see if there is anything to do. For example, if there is a line in inittab like:

	tty0:23:respawn:/etc/getty /dev/tty0

init will start a getty process on the serial port /dev/tty0 as long as the current run level of the Unix system is either 2 or 3. The first field in the above line, tty0 is just a user defined tag that init uses as an index into the inittab file. It must be unique and hopefully will convey some information to humans reading the inittab file.

The getty process is a simple-minded task. It reads /etc/gettydefs to find out how to set the port for data bits, parity, flow control, etc. and then waits patiently for some sign of life on the port. As soon as some sign of life, like a carriage return, is seen, getty starts a login process and exits.

The login process does exactly what you expect. It prompts the user for a valid login id and password combination. It then consults the /etc/gettydefs file to see how the port should be set at login time. Then it spawns a shell and exits.

The shell program (sh, ksh, csh, bash, etc.) is the command line interpreter that all Unix users know and love. When the user finishes using the shell by exiting or sending an EOT (^D) character, the shell exits.

The Unix kernel then notices the shell has died and knows the terminal on which the shell was running is no longer in use. The kernel sends a message to init telling it that the terminal has been released by the shell. init reads /etc/inittab to find out what to do on the port and the process starts over again.

Q. How does BLAST control a serial port on an SVR3 Unix systems?

A. Within the IGLS scheme, there is no provision for initiating an outbound connection. Even programs like uucp (Unix-to-Unix-Copy) and cu (Call Unix) must either break the IGLS cycle or use a serial port not controlled by the IGLS cycle to initiate an outbound call. Taking a serial port outside the IGLS cycle and dedicating it to outbound calling is the most reliable means of having in-bound and out-bound lines. Unfortunately, this approach requires multiple modems and phone lines to implement. Alternately, it is possible to share a port for dial-in and dial-out processes. The IGLS cycle can be disabled on a port by making a simple change in inittab:

   tty0:23:off:/etc/getty /dev/tty0

Changing respawn to off tells init to shut down the getty process and not to restart it.

Some Unix systems even provide a command to disable the getty. On SCO Unix, for example the command:

	disable tty0

will make the appropriate changes in the /etc/inittab file. To reenable the getty you would type:

	enable tty0

Your mileage may vary so check your system documentation and man pages.

As appealing as this approach may seem, there are some drawbacks. Allowing users and applications to modify a system file like /etc/inittab poses a threat to the integrity of the system. For a user or application to be able to modify /etc/inittab requires write permission for the file which means it can become corrupted. If the file becomes corrupted, your multi-user system will slowly become a single and ultimately a no user system.

A number of mechanisms like uugetty and lock files have been tried to solve this problem. None of them have been wholly satisfactory or particularly reliable.

When BLAST accesses a serial port Unix system it does three things. First, BLAST attempts to disable any getty running on the serial port by setting the appropriate line to "off" in the /etc/inittab file. Next BLAST creates a lock file in the appropriate directory or directories. When this is done it attempts to set the serial port as specified in the setup file and open it.

Q. What is uugetty?

A. uugetty is a variant of getty that tries to distinguish between in-bound and out-bound calls and set the serial port appropriately. It is our experience that uugetty is difficult to configure and not very reliable.

Q. What are lock files?

A. A lock is a file placed in a special directory that should prevent other applications from using a serial port or other resource. The concept is that applications wishing to use a serial port should check for the existence of a lock file prior to opening the port. Unfortunately, there is no standard for where locks should be written and what they should contain. Therefore, some applications do not check for the existence of a lock while others misinterpret what locks they do happen to find. For example, on SCO Unix, neither getty nor login create a lock file when a user dials in on a port. The uucp program writes a lock file in directory /usr/spool/uucp. Other applications write their locks in /usr/spool/locks.

BLAST puts locks in the most common places for locks to be found on any given Unix operating system. Common directories for locks are /usr/spool/uucp, /usr/spool/locks/, /var/spool/locks, /var/spool/uucp and /etc/locks.

Q. I am installing BLAST on my Intel-based Unix system and I only have a 5.25" drive. The diskette shipped to me is 3.5". What can I do?

A. Call BLAST for a 5.25" diskette for installation.

Section Ten - Miscellaneous Issues

Q. Does BLAST have to be installed at both ends of the connection?

A. The answer to this question depends on what you want to do. If you want to do:

	Error-free file transfer with the BLAST Protocol - Yes
	File Transfer using XMODEM, YMODEM, ZMODEM, or KERMIT - No
	Terminal Emulation - No
	Remote Control - Yes


A. Receiving this error when entering transfer mode with the BLAST Session protocol means that both copies of BLAST have the same serial numbers. BLAST is serial-number protected; each system must have a separate, licensed copy of BLAST with a unique serial number.

In our Professional DOS and Professional Unix product we provide the user with a separate BHOST diskette containing a copy of BHOST with a unique serial number. This copy can be installed on a separate DOS-PC machine for two-way communications.

Q. How does data get corrupted during a file transfer?

A. In general, there are two sources of data corruption during file transfers. One source is bad telephone connections. The other is improper flow control.

Modern error-detecting modems practically eliminate bad telephone connections as a source of data corruption. All of those MNP, V.whatever and LAP-M designations on your modem means that data will be delivered error-free from your modem. With a bad connection, the modems may have to do a lot of re-transmission of data which will slow down throughput. Rest assured though, that bad phone line are rarely a cause of data corruption as long as an error-free connection is established by the modems.

If your modems are having to do a great deal of re-transmission of data you may be able to achieve faster transfers by turning error-detection off. Some modems attempt to retrain each time a they detect data corruption. With some modems it can take several seconds to retrain. By turning error-detection in the modems off, you can avoid the retraining process. The file transfer protocol will accomplish the same error-detection without the re-training down-time. To achieve the greatest throughput, use the smallest packet size possible.

In our experience, improper flow control is the single greatest factor contributing to data corruption. When you are making a high speed connection it is imperative that flow control is correctly set. Otherwise, modem and serial port buffers will be overrun and data will be corrupted.

Q. What is Packet Switching?

A. A packet switched network is a communications service offered by phone companies that transmits data between computers in the form of packets. Packet switching is also known by the X.25 and X.29 protocols used in the networks. Packet switching networks are usually used to provide long distance networking capabilities to users who do not have extensive enough needs to justify leased lines. Although billing methods vary, packet switched networks usually charge for the number of packets transmitted over the network instead of the amount of time connected to the network. Thus, packet switching allows full-time connectivity to a remote computer at a fraction of the cost of dial-up or leased lines charges. For example, many banks use packet switching networks to connect terminals in branch offices to their host machine in the home office.

Due to the packetizing process, packet switched networks introduce significant delays into data transmission. In general, a packet switched network attempts to fill packets before transmission. If a packet remains unfilled for too long, the network will timeout and transmit the partially filled packet. Since packet switched networks charge by the number of packet transmitted, it is preferable to transmit full packets. However, waiting for too long to transmit a packet will cause intolerable delays for interactive users. The packetizing process will also slow down file transfers particularly if you are using an ACK/NAK protocol. Performance of ACK/NAK protocols suffer because they have to wait to send a packet until a response is received from the remote system. The transmission of the ACK or NAK is delayed until the packet switching network times out and sends the mostly empty packet containing the ACK or NAK. To achieve maximum efficiency of a packet switched network it is necessary to tune the packet size of the file transfer protocol to the packet size of the network. If the packet sizes do not match you will be sending partial packets which waste money And force the network to time out prior to sending the packets. Most ACK/NAK protocols used fixed packet sizes that may or may not match the packet sizes used by the network. Sliding window protocols like BLAST with tunable packet sizes are more well suited for use with packet switched networks. File transfer performance does not suffer since the protocol is not forced to wait for a response after packet is sent. Additionally, the protocol's packet size can be tuned to match the network's packet size to maximize efficiency. Furthermore, BLAST can bundle multiple ACKs into one acknowledgement. This reduces the number of network packets that must be transmitted to acknowledge file transfer protocol packets. Check the BLAST Technical Note on setting up the BLAST protocol over packet switched networks.

Open Communications International
Colonial House
Suffolk, IP16 4JD

+44 (0) 1728 832 712
+44 (0) 1728 830 196

For more information please E-mail info@opencomm.co.uk
Copyright 1999 Open Access Technologies Group