AS/400-iSeries Starter Kit

As the father of two young children (ages 4 and 9), I have learned that to maintain peace in the house, my wife and I must either teach our children to share or buy two of everything. Those of you who can identify with this predicament know that in reality peace occurs only when you do a little of both -- sometimes you teach, and sometimes you buy.

The AS/400 inherited a performance-related virtue from the S/38 that lets you "teach" your programs to share file resources. I call it a performance-related virtue because the benefit of teaching your programs to share boosts performance for many applications. However, as is the case with children, there will be times when sharing doesn't provide any benefits and, in fact, is more trouble than it's worth. In this chapter, as we continue to examine files on the AS/400, we will focus on the SHARE (Share Open Data Path) attribute and how you can use it effectively in your applications.

You may already be familiar with the general concept of file sharing, a common feature for many operating systems that lets more than one program open the same file. When each program opens the file, a unique set of resources is established to prevent conflict between programs. This type of file sharing is automatic on the AS/400 unless you specifically prevent it by allocating a file for exclusive operations (using the ALCOBJ (Allocate Object) command). The SHARE attribute does not control this automatic function.

On the AS/400, SHARE is a file attribute. It goes beyond normal file sharing to let programs within the same job share the open data path (ODP) established when the file was originally opened in the job. This means that programs share the file status information (i.e., the general and file-dependent I/O feedback areas), as well as the file pointer (i.e., a program's current record position in a file). As we further examine the SHARE attribute, you will see that this type of sharing enhances modular programming performance, but that you must manage it effectively to prevent conflicts between programs.

The SHARE attribute is valid for database, source, device, distributed data management, and save files. You can establish the SHARE attribute or modify it for a file using any of the CRTxxxF (Create File), CHGxxxF (Change File), or OVRxxxF (Override with File) commands. The valid values are *YES and *NO. If SHARE(*NO) is specified for a file, each program operating on that file in the same job must establish a unique ODP.

Sharing Fundamentals

While sharing ODPs can be a window to enhancing performance, doing so can also generate programming errors if you try to share without understanding a few simple fundamentals. The first fundamental pertains to open options that programs establish.

When a program opens a file, the options specified on the OPNDBF (Open Data Base File) command or by the high-level language definition of the file determine the open options. The open options are *INP (input only), *OUT (output only), and *ALL (input, output, update, and delete operations). These options are significant when you use shared ODPs. If you specify SHARE(*YES) for a file, the initial program's open of the file must use all the open options required for any subsequent programs in the same job. For example, if PGMA opens file TEST (specified with SHARE(*YES)) with the open option *INP (for input only), and then PGMB, which requires the open option *ALL (for an update or delete function) is called, PGMB will fail.

Besides sharing open options, programs also share the file pointer, a capability that is both powerful and problematic. Figure 23.1 displays the eight records that exist in file TEST. In Figures 23.2a and 23.2b are RPG programs TESTRPG1 and TESTRPG2, respectively, which alternately read a record in file TEST. After TESTRPG1 reads a record, it calls TESTRPG2, which then reads a record in file TEST. TESTRPG2 calls TESTRPG1, which reads another record, and so on. Both programs use print device file QPRINT to generate a list of the records read.

When the SHARE attribute for both file TEST and file QPRINT is SHARE(*NO), the output generated appears as displayed in Figure 23.3. Each program reads all eight records because each program uses a unique ODP. If you change file TEST or override it to specify SHARE(*YES), the programs generate the lists displayed in Figure 23.4. Each program reads only four records, because the programs share the same ODP. Finally, if you also change or override the attribute of file QPRINT to be SHARE(*YES), the output appears as shown in Figure 23.5. Both programs share print file QPRINT and, while each program reads only four records, the output is combined in a single output file.

One common misconception is that using SHARE(*YES) alters the way in which the database manager performs record locking -- a conclusion you could easily reach if you confuse record locking with file locking. It is true that when you specify SHARE(*YES), file locking is handled differently than when you specify SHARE(*NO); when you specify SHARE(*YES), the first open establishes the open options. Thus, if the first open of a file with SHARE(*YES) uses option *ALL, every program using that file obtains a SHRUPD (Shared Update) lock on that file. This lock occurs even when a particular program normally opens the file with *INP open options.

Record locking, on the other hand, is not controlled by the open options, but by the RPG compiler. The program compiler determines which locks are needed for any input operations in the program and creates the object code to make them happen during program execution. Thus, programs perform record locking on files with SHARE(*YES) the same way they perform record locking on files with SHARE(*NO). Let me stress that this fact alone does not prevent the problems you must address when you write multiple programs to perform with files having SHARE(*YES) in an on-line update environment. But record locking, in and of itself, is not a serious concern. The real hazard is that because SHARE(*YES) lets programs share the file pointer, programs can easily become confused about which record is actually being retrieved, updated, or output if you fail to write the programs so they recognize and manage the shared pointer.

The following example illustrates this potential problem. PGMA first reads file TEST for update purposes. Then PGMA calls PGMB, which also reads file TEST for update. If PGMB ends before performing the update, the file pointer remains positioned at the record read by PGMB. If PGMA then performs an update, PGMA updates the values of the current record variables (from the first read in PGMA) into the record PGMB read because that is where the file pointer is currently positioned. While you would never purposely code this badly, you might accidentally cause the same problem in your application if you fit program modules together without considering the current value of the SHARE attribute on the files.

The moral of the story is this: When calling programs that use the same file, always reposition the file pointer after the called program ends, unless you are specifically coding to take advantage of file pointer positioning within those applications.

Sharing Examples

The most popular use of the SHARE attribute is to open files at the menu level when users frequently enter and exit applications on that menu. Figure 23.6 illustrates a simple order-entry menu with five options, each of which represents a program that uses one or more of the described files. If SHARE(*NO) is defined for each file, then each time one of these programs is called, an ODP is created for each program file. If users frequently switch between menu options, they experience delays each time a file is opened.

The coding example in Figure 23.7 provides a solution to this problem. First, the OVRDBF (Override with Database File) command specifies SHARE(*YES) for each file identified. Then, OPNDBF opens each file with the maximum open options required for the various applications. The overhead required to open the files affects the menu program only. When users select an option on the menu, the respective program need not open the file, and thus the programs are initiated more quickly. Remember, however, to plan carefully when using SHARE to open files, keeping in mind the above-mentioned guidelines about placing the file pointer.

The SHARE attribute also comes in handy when you write applications that provide on-line inquiries into related files. Figure 23.8 outlines an order-entry program that opens several files and that lets the end user call a customer inquiry program or item master inquiry program to look up specific customers or items. Either program uses a file already opened by the initial program. By including the statements in Figure 23.9 in a CL program that calls the order-entry program, you can ensure that the ODP for these files is shared, reducing the time needed to access the two inquiry programs.

There is no doubt that SHARE is a powerful attribute. Unfortunately, the power it provides can introduce errors (specifically, the wrong selection of records due to file pointer position) unless you understand it and use it carefully. SHARE(*YES) can shorten program initiation steps and can let programs share vital I/O feedback information. If you're using batch programs that typically open files, process the records, and then remain idle until the next night, SHARE(*YES) will buy you nothing. But if you're considering highly modular programming designs, SHARE(*YES) is a must. For more information about SHARE, see IBM's Programming: Data Base Guide (SC41-9659) and Programming: Control Language Reference (SC41-0030).