FairCom RTG COBOL Edition User's Guide

<filepool>

Enables and disables support for file pooling.

Description

In COBOL applications it is common practice to close and re-open files when entering procedures. This can cause unnecessary overhead and performance issues in FairCom RTG.

The filepool feature introduces support for file pooling to keep files open when the COBOL application requests to close them. This allows the file handle to be returned immediately when the COBOL application requests to re-open it.

The <filepool> global configuration keyword enables and disables support for file pooling and optionally Sets the size of the file pool with attribute <filepool size> where size is the maximum number of files to keep in the pool.

Accepted Values

Value	Effect	Synonyms
yes	Enables file pooling to keep files open so the file handle can be returned immediately when the application requests to re-open it.	y, true, on, 1
no		n, false, off, 0

Attributes

Value	Effect	Synonyms
size	Optionally sets the maximum number of files to keep in the pool.

A configuration keyword <inpool> defines if a file can be included in the file pool.

Consideratrions

1. <filepool> is client-specific and not shared among clients. Consider user A adds a file to a filepool and user B attempts to operate on that file with ctutil -copy. This fails with error 12 (-8). Automatic removal from a pool during the copy can only be done for the user that requested the pool.
2. Because the file remains physically open, other clients that expect the file to be closed (for example, when they attempt to open the file exclusively) get an error such as c-tree uerr_cod = 12 sysiocod = -8, which indicates the file is open by another client. This may be confusing as the file is logically closed by all clients.

   Currently there is no way for other clients to detect that the file is physically open by the <filepool> or request that the file is physically closed and removed from the <filepool> list.

3. <filepool> was introduced to increase the performance of applications that continuously close and re-open the same file in a short amount of time. It has been designed assuming that only the files that are frequently closed and re-opened are included in the pool. Files that are not frequently closed and re-opened should not be marked as <inpool>. It does not make sense to put many files in the pool as there are side-effects to keep the files physically open (conflicts, consume of both memory and file handles, etc.). In addition, searching for entries in a larger pool is slower and could frustrate the attempt to speed up the file open.

   <filepool size> indicates the number of data files and it is recommended to keep it as low as possible.

See also:

• <inpool>