Limitations Under the UNIX Operating System

Networks

PRO/5 expects that file access will be the same on a local system as on a networked system.

In particular, the lockf(2), locking(2), or fcntl(2) calls should operate on a network file in exactly the same manner as on a local file. Additionally, as PRO/5 uses information returned by the stat(2) system call, it is important that the format of the information remain the same and that file uniqueness be maintained across the network.

Data Server

BASIS offers another PRO/5 product, the PRO/5 Data Server, to handle networked files more efficiently. The Data Server is available on many of the platforms where PRO/5 is available. It resides on one of the networked systems, and handles requests for data from the client PRO/5s on other networked systems. All file manipulation is identical across the network, and network traffic is reduced because a single request to the Data Server replaces the multiple requests required over a transparent network filesystem. The Data Server eliminates or minimizes most of the problems involved in handling files across networks.

File READ vs. READ RECORD

Whenever possible, use a READ RECORD operation rather than a READ operation. The READ RECORD command specifies a buffer and PRO/5 will read the entire buffer in one operation. The READ command specifies that PRO/5 is to read the input one character at a time until the input runs out of data or a field terminator appears in the input stream.

The READ RECORD command will almost always out perform the READ command.

UNIX Operating System Parameters

There are several UNIX configuration parameters, which can affect your PRO/5 installation. These deal with system limits affecting: the maximum size of files, the maximum number of files that can be opened at one time, the maximum number of locks that can be active at one time, and the amount of system memory allocated to disk buffers. These parameters must be set properly in order for your system to function in an efficient manner. What follows is a brief discussion of these parameters. Their names and the methods of setting them vary from system to system. Please consult your UNIX manuals for the correct names and procedures for your system.

ULIMIT

Determines the maximum number of blocks that can be written to a file. On most systems this parameter can be set in your login profile. Check with your systems administrator for the settings on your system. This number should be set large enough to handle the largest files you expect to write. If ULIMIT is not set high enough you could experience PRO/5 !ERROR=2s or !ERROR=15s on writing to large files.

A special program, pro5run, is supplied with PRO/5 for most UNIX operating systems. This program will attempt to set ULIMIT to a very large value for your system before overlaying itself with PRO/5. This may be necessary on some systems where the ULIMIT is not easily changed by a user. ULIMIT can be set as a system parameter in most systems. It can usually be set as well by an individual process.

NFILES

Sets the total number of file handles that can be OPENed at any one time on the system. This should be set to at least the average number of files used per task, times the number of tasks you are running. If you are using FCBCACHE, this number should be increased to reflect the number of active files as well as the number of cached files. If this number is set too low, PRO/5 !ERROR=16s may occur on the system. If it is set too high, system performance can suffer because system memory is being tied up for files tables that are not being used. NFILES is usually set as a system parameter.

LOCKS

Sets the total number of locks that can be active at anyone time. PRO/5 uses locks to arbitrate record usage. A rule of thumb to follow in setting this parameter is to allow one lock per open PRO/5 file plus one per PRO/5 task, plus any other locks required by other tasks. If a PRO/5 task requests a lock and none are available, an !ERROR=0 could be generated. In some cases that task requesting the lock can hang. In most cases, system performance will be noticeably affected.

NBUF

Sets the number of memory blocks allocated to disk buffers. System performance is greatly dependent on this parameter. If it is set too low, the system has to access the disk more often, slowing the system down. If it is set too high, time could be wasted searching in memory for disk blocks that have not been read. A rule of thumb is to allow approximately 25% of the system memory for buffers.

Terminations

A hangup signal in the UNIX operating system (SIGHUP) will cause an orderly shutdown of PRO/5. Pending terminal output and pending terminal reset operations are terminated. An illegal instruction signal (SIGILL) will be treated the same as an interrupt character (SIGINT) and (SET ESCAPE), even when PRO/5 is not running on a terminal.

User Limits and User Numbers

PRO/5 products are licensed on the basis of the number of foreground users they will support. A foreground user is any process started executing PRO/5, whether attached to a terminal or not.

PRO/5 may, however, start a process not attached to a terminal using the BACKGROUND or SELECT commands. These are referred to as "background users." Each PRO/5 and PRO/5 Data Server product will support eight times as many background users as foreground users. For example, an 8-user PRO/5 will simultaneously accommodate up to 8 foreground users and 64 background users.

PRO/5 does this by maintaining two pools of user "slots". Each time a foreground or background user requires the services of the PRO/5 product, a slot is used. When all the slots are used, the next request is denied until a slot becomes available. PRO/5 will print an error and refuse to start; the PRO/5 Data Server will refuse a connection.

These slots are not only important in counting users. They are an essential element in the PRO/5 file and record locking scheme. Because each user has a unique slot, the number of that slot is used to lock part or all of a file. Other processes acknowledge that they do not own the lock, because their slot number is different. This provides a simple and quick method of locking files and records.

In some network environments, this method is not foolproof. Processes on different machines may happen to share the same slot number because the slots are from different pools. To allow for these cases, a "Network Lock" scheme can be enabled via the SETOPTS verb, which is described in the Commands Manual section of the documentation.

With the INFO() function, it is possible to determine the total number of each type of slot that a given PRO/5 can support, as well as the number of remaining free slots.

The slot pools are implemented using the UNIX operating system IPC (Interprocess Communication) mechanisms, requiring one semaphore vector and one shared memory segment. Removing or tampering with these IPC's is likely to cause locking conflicts, and will also have more serious side effects.