Controlling File Access OPENing up your files with SPECIAL INPUT
From "VS Workshop",  Access 88, April 1988
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

Next to sports statistics, complaining about the SHARER is the likeliest topic when technical VS users gather. Widely viewed as the culprit for many system performance problems, the SHARER is almost universally used for data processing applications to provide multiple users with simultaneous read and update capability.

While Wang has announced that future operating systems will incorporate a new file access method to replace the SHARER, this is years away in a practical sense since existing applications will probably need to be rewritten. In the meanwhile, I offer some of my experiences using a little-known alternative: SPECIAL INPUT.

Let's begin with a quick review of the standard file OPEN modes on the VS.

OPEN modes on the VS

Control of file access is one of the fundamental services offered by an operating system. The operating system must ensure that users are provided appropriate access for their use, that no two users simultaneously update the same record, and that each task waits it's turn. All of these operations must be performed quickly and efficiently.

Other file modes - INPUT, OUTPUT, I/O, EXTEND - are incorporated into the operating system itself. SHARED mode, on the other hand, is controlled by a background task - an application - and thus not as efficient as other modes.

The three most likely open modes for data processing applications are INPUT, I/O and SHARED. A review of the use of these modes and their related limitations is shown in Figure 1, below.

The SHARER controls access to a file used by many users. It works by assuming ownership to the file, then allowing each user to access that file. Technically, the file is OPENed I/O (used exclusively by the SHARER) with the SHARER allowing tasks access to the file. Requests for all access to that file are funneled through the SHARER, which processes each in the order received. If more than one file is opened SHARED (a typical situation), each request for each file must wait it's turn to use the SHARER.

Until recently, there was only one path through the SHARER, so file access had to wait until it was through processing the last request. In response to user demands, Wang has added a four-path SHARER to recent operating systems, but a single path is still used for each file; thus, multiple paths have had little effect on system performance in most situations.

Application design considerations

VS applications typically open existing production files in one of three modes: INPUT, I/O or SHARED. The use of these modes is largely dependent on the needs of the application.

INPUT mode allows fast retrieval of the data by many simultaneous users, but restricts ALL access to the file to INPUT mode (no updates). I/O mode allows update, but only one user may access the file. SHARED mode allows both inquiry and update, but penalizes everyone by adding additional system overhead. In desperation, most application designers use I/O mode for critical updates where no other users may be present, and SHARED mode for everything else. In short, there is little practical alternative to using SHARED file access in data processing applications. We hate it, but we use it.

Using SPECIAL open modes

With the release of the 6.40 operating system in 1985, Wang made two new file opening modes available: SPECIAL INPUT and SPECIAL I/O. Both were intended to overcome very real performance problems using SHARED files. Although some application designers take advantage of these new modes, there seems to be a curious lack of interest from the programming community.

Until recently, the only way to use the SPECIAL modes was to call the Assembler subroutine SPECIO, passing the address information of the file to be opened. Release 5.10 of the COBOL compiler now incorporates SPECIAL INPUT directly into the language; thus, it seems fitting to dust off some of my files and introduce the use of SPECIAL modes.

I will concentrate on SPECIAL INPUT, since it fills the likeliest need for performance improvement - faster reporting from SHARED files. The update functions supported by SPECIAL I/O can also be accommodated using SHARED mode.

Use of SPECIAL INPUT and SPECIAL I/O modes are subject to several important qualifications:

1. The system configuration must be changed to allow SPECIAL (For an example of this, see the VS RELEASE 6.40 SOFTWARE BULLETIN, publication 715-0118A; page 3-16.

2. SPECIAL modes may only be used with indexed or alternate-indexed files.

3. File access must only be along the primary key path. Alternate key access is not allowed.

4. The file must be OPENed for SEQUENTIAL access when using COBOL's new SPECIAL-INPUT mode. (DYNAMIC and RANDOM access are still available through the SPECIO subroutine.)

5. Access must be at the RECORD level. PAM (Physical Access Method) and BAM (Block Access Method) approaches are out.

6. Buffer pooling and large buffer strategies are not allowed.

7. Record locking is not supported. The HOLD modifier will be treated as a comment.

8. If using the SPECIO subroutine (not SPECIAL-INPUT from COBOL 5.10), the language used must allow the User File Block (UFB) address to be passed to the Assembler subroutine that actually OPENs the file.

9. SPECIAL modes cannot be used on the VS 50, VS 60, or VS 80. (Sorry.)

In addition, there are several design considerations in the use of the SPECIAL modes:

1. You must be aware that recent revisions to the file will not be shown. (This is primarily a problem in on-line systems, not reports.)

2. The program will not pass file location information to the SPECIO subroutine; thus, a procedure must be used to run the program and suppress the GETPARM screen that will appear requesting that file information.

3. If using the SPECIO subroutine, the program must be properly linked to the subroutine. This must be done carefully, since (as written) the subroutine's file name is not the same as the entry points used. (I found this confusing and rewrote SPECIO into two subroutines - OPSPIN and OPSPIO - that handle each situation individually. OPSPIN is shown in Figure 7, below.)

4. If you are writing programs that may be used on older VS models, it would be prudent to extract the processor type and operating system release level before attempting to use SPECIAL INPUT. Operating systems before 6.40 will not support the SPECIAL modes.

Application example: a report using SPECIAL INPUT

To test the performance times of SHARED versus SPECIAL INPUT, I created a COBOL report program that could switch modes under procedure control. This program read sequentially through a large alternate-indexed file (over 250,000 records), selecting items for further reporting. The environment was a heavily-loaded VS 100 under the 6.40 operating system with many SHARED applications running. I ran this program in both modes several times over the course of a day, each time capturing thea run statistics with the TRACER procedure (see ACCESS, January 1987; page 18). The results are shown in Figure 6, below. This test yielded an eight-fold improvement in clock time, with CPU time about 60% of that under SHARED access.

Other tests I attempted:

1. Comparison of SPECIAL INPUT and INPUT modes: times for INPUT and SPECIAL INPUT were virtually identical, with slightly more time required to OPEN the file under SPECIAL INPUT.

2. Lightly-loaded VS 100 running 6.43: a lightly-loaded system with no simultaneous SHARED access to the file showed only a two-fold improvement in clock time and CPU time improvements similar to the heavily-loaded system.

4. VS 300 under 7.13: the multi-threaded SHARER used in the 7.13 operating system had no perceivable effect - again, with few other applications running SHARED.

In conclusion, it seems likely that the SHARER will be with us for some time to come - if only because of the need to revise existing applications to take advantage of a future replacement of the SHARER's function. If you are developing programs and working in a SHARED environment, SPECIAL INPUT is a viable means of improving performance.

References

• VS Release 6.40 Software Bulletin, publication 715-0118A; May 1985; pages 2-12 through 2-14; page 3-16
  
  Discusses the use of the SPECIAL modes, including legal operations, record locking, and some application considerations. The GENEDIT option to allow SPECIAL modes is also illustrated.

• Software Maintenance Bulletin, December 1986; page 9
  
  A response to a user question notes that the SPECIAL modes are only available in VS Assembly language.

Figure 1: Comparison of OPEN Modes

Mode	Read	Write	Multiple users	Compatible with
INPUT	Yes	No	Yes	INPUT
I/O	Yes	Yes	No	(exclusive)
SHARED	Yes	Yes	Yes	SHARED SPECIAL INPUT SPECIAL I/O
OUTPUT	No	Yes	No	(exclusive)
EXTEND	Yes	Yes	Yes	(exclusive)
SPECIAL INPUT	Yes	No	Yes	SHARED SPECIAL INPUT SPECIAL I/O
SPECIAL I/O	Yes	Yes	Yes	SHARED SPECIAL INPUT SPECIAL I/O