Upon completion of this chapter, you should be able to

In this chapter we expand on the description of display files given in Chapter 14, "Interactive Processing." As you recall, record formats are defined in a display file to define an entire screen or a portion of a screen. One of the most common types of record formats used in interactive applications is the list screen, or work with screen, shown in Figure 17.1.

Figure 17.1. A list, or work with, screen that displays all customers with a particular last name.

The list screen, or work with screen, provides a method of processing a block of records that are read from and written to a screen. The block of records processed with a list screen is contained in a subfile. A subfile is a collection or

subset of records from a data file that is processed as a unit using a list screen. A subfile can be specified in the DDS for a display file to allow a program to handle multiple records of the same type on a screen. This allows a software developer to narrowly define a subset of records from a file that can be processed as a group or used to find a specific record in the file.

In a typical subfile application, the program reads records from a database file, loads the records into a subfile, and writes a block of records from the subfile to the screen.

For example, consider what happens when you go into your bank to conduct a transaction and you forget your account number. The teller enters your last name into the data entry screen in Figure 17.2. The program uses the name entered to search the database file for records containing the same last name. Each time the program finds a record with the same last name, it adds the record to the subfile. The program then uses the subfile list screen in Figure 17.1 to display the block of records to the teller.

If your last name happens to be Jones or some other common last name, there could be many records in the subfile. If you have a last name that is not as common, the subfile would contain fewer records. Regardless, this list contains a subset of the records from the account file that the teller can use to narrow down the search for your account number. From here, the teller will be able to find your account number by using your address or other identification. Next to each item displayed on the screen could be an Option area that allows the teller to select the customer record for further processing.

Figure 17.2. Entry screen requesting the customer's last name.

Subfile record formats are best illustrated using a practical example. In this case problem, the store managers of the Best Deal Stores Company want an interactive application to display all employees by individual store. Since each store can employ any number of employees, an interactive subfile query program would work best for this application. The program prompts the user for a store number, retrieves employee records from the Employee Pay File for the requested store number, and displays the employee information on the screen. Figure 17.3 illustrates the systems flowchart for this case problem.

Systems flowchart

Figure 17.3. System flowchart for interactive subfile program.

When the interactive subfile program is executed, the user is presented with the initial data entry screen in Figure 17.4. This screen allows the user to enter a store number.

Figure 17.4. Data entry screen that accepts the store number.

The program uses the store number entered by the user to retrieves all the records with the same store number from the employee pay file. The employee pay file is shown in Figure 17.5.

Figure 17.5. Data description specifications (DDS) for the EMPPAYPF physical file

Since employee number is the key field in the employee pay file, the program uses the logical file in Figure 17.6 to sequence the records in store number order. The fields STORENO, DEPARTMENT, and, EMPLOYEENO are the key fields in the logical file. Although we need to access the logical file by the store number field alone, we specify the STORENO, DEPARTMENT, and EMPLOYEENO fields as key fields, so records are retrieved and displayed on the screen in a more logical sequence.

Figure 17.6. Data description specifications (DDS) for the EMPPAYL17A logical file

The program builds a subfile containing employee records for the specified store number. The first page of the subfile is then displayed using the list screen in Figure 17.7. If there are no records in the file for the store number requested, the program displays the message "store not found" on the message line of the data entry screen in Figure 17.4 to notify the user that no records were found in the file.

The subfile program allows the user to page up and page down to view records from the subfile. The user signals the end of job by pressing F3 (Exit), at which time the program is terminated.

Figure 17.7. Subfile display of employee records for the specified store.

Before programming a subfile application, the software developer must design the record formats that are used for communication between the user and the subfile program. Data description specifications (DDS) are used to describe a subfile display file.

The DDS for a subfile application contains several record formats. Let us consider each of the record formats for our case problem.

The prompt screen SFLPROMPT is shown in Figure 17.4, and the DDS entries are shown in Figure 17.8. This record format, SFLPROMPT, is an enter format that prompts the user for a store number, so the corresponding records can be retrieved from the file.

The program reads the SFLPROMPT record format and uses the store number to access the requested records from the EMPPAYL17A logical file. If, however, the user wishes to terminate the program, F3 (Exit) is pressed.

The keyword REF (reference) is used at the file level to indicate that there are fields in this display file, which are defined in a file called EMPPAYPF. In addition to the physical file name, the library where the referenced file is located is specified. In this case, the system will search the library list (*LIBL) for the first occurrence of the EMPPAYPF file.

If records are found in the employee pay file for the specified store number, the subfile is loaded with the records, and the first block of records from the subfile is displayed on the screen as shown in Figure 17.6. Once the user is finished viewing the information on the subfile screen, he or she presses the Enter key, F3 (Exit), or F12 (Cancel). When the Enter key or F12 is pressed, format SFLPROMPT is again displayed, so that the user can select another store number to view. In this example, pressing Enter or F12 will accomplish the same thing; that is, display SFLPROMPT again. If the user presses F3, the program terminates.

Figure 17.8. DDS for record format SFLPROMPT.

To use a subfile, two record formats are defined in the DDS: a subfile control-record format and a subfile record format. The subfile record format is defined first and defines the first line of one or more identical lines to be displayed on the screen. The subfile control-record format defines the attributes of the subfile and controls the processing of the subfile record. So it is the combination of the subfile record format and the subfile control-record format working together that allows subfile processing within the program. The display file CPCH17ADF defines two record formats, SFLRECORD and SFLCONTROL.

The DDS for the subfile record format in Figure 17.9 contains the field descriptions for the first record in the subfile. This record format is identified by the DDS keyword SFL (subfile) on line 34.00.

Figure 17.9. (DDS) for the subfile record format SFLRECORD.

The subfile control-record format actually tells the system how many record (lines) will be in the subfile and how many will appear on the screen at one time.

A subfile record format is unlike any other display file record we have previously encountered. Normally, a WRITE statement will cause a record format to be displayed on the screen; however, a WRITE to a subfile record format moves information into one of the identical lines that will eventually be displayed. In order for the lines to actually be displayed, a WRITE of the subfile control record format, SFLCONTROL in our example, must be done.

Line 34.00: The SFL keyword identifies the record format SFLRECORD as a subfile.

Line 35.00–41.00: These lines define the fields contained in the first record (line) of the subfile that are to be displayed on the screen. The field names are left-justified in the Name field (positions 19–28). The line (Line field) and position (Pos field) entries define the location of the fields on the display.

Notice that there is no entry in the Length field for the data fields. The R in the Reference (position 29) field is associated with the REF keyword in the file level area of the display file. It tells the system to refer to EMPPAYPF for the attributes of each field. These attributes include the field's data type, length, decimal positions, and keyword attributes.

The O in the Usage field (position 38) indicates that the fields are output fields. That is, the fields can only be displayed on the screen. The user will not be able to enter data (input) into them.

Each field has an alternative name (ALIAS keyword) assigned to it.

The EDTWRD keyword specifies the desired editing for output field SFL-EMPLOYEE-NUMBER. EDTCDE(3) indicates that the field SFL-HOURLY-RATE is to be printed with commas, a decimal point, and no sign. Also, a zero balance will be printed, and leading zeros will be suppressed. Remember, the use of edit codes and edit words makes the field longer when displayed on the screen.

The subfile control-record format in Figure 17.10 must immediately follow the subfile record format. This record format identified by the DDS keyword SFLCTL, line 45, uses record-level keywords to control the subfile record format. In addition to the control information, the subfile control-record format defines the constants and fields that are displayed on the screen above the subfile record format.

The control-record format defines the number of records that can be written to the subfile (DDS keyword SFLSIZ, line 47) and how many of them will be displayed on the screen at any one time (DDS keyword SFLPAG, line 48). With subfile programming, the subfile record format defines the DDS for one of these eight identical records, and the subfile control-record format indicates that this record be duplicated eight times. The program does not have to keep track of which records of the subfile are currently being displayed. When the program opens the display file CPCH17ADF, the subfile control record tells the system to allocate space for eight subfile records, defined by the subfile record format.

The subfile control-record format defines the attributes of the subfile and the constants. The keywords used indicate the following.

The SFLCTL (Subfile Control) keyword identifies this record format as a subfile control record and names the associated subfile record (SFLRECORD).

The SFLSIZ (Subfile Size) keyword indicates the number of records to be included in the subfile. In Figure 17.10, the SFLSIZ keyword indicates that the subfile size is 32 records. If the software developer underestimates the size of the subfile and the program tries to WRITE more records to the subfile than have

been defined in the SFLSIZ keyword, the system will send a file status 9M error to the program. Since a file status error beginning with 9 is a severe error that will cause the program to terminate, a procedure must be added to the program to prevent this error. In our program examples, we specify the PROCESS FS9MTO0M statement as the first statement in the program. This statement changes the file status 9M return code to 0M (File Status 9M TO 0M). See Appendix D for more information on the PROCESS statement. Changing the file status prevents a program interrupt and also allows the subfile to grow dynamically. When the program tries to write more records to the subfile than are specified in the SFLSIZ keyword, the subfile will automatically be extended to make room for any additional records. Remember, however, that the PROCESS FS9MTO0M statement must be specified to prevent the program interrupt and allow the subfile to grow dynamically.

Figure 17.10. (DDS) for the subfile control-record format SFLCONTROL.

The SFLPAG (Subfile Page) keyword indicates the number of records in a page, that is, the number of records that will be retrieved from the subfile and displayed on the screen at one time. The SFLPAG keyword in Figure 17.10 indicates that eight records are displayed on the screen at one time. The number 8 in parentheses follows the keyword SFLPAG. There is no space between the keyword and the number. The page number is determined by the number of available lines on the screen after all other lines have been defined.

The SFLDSP (Subfile Display) keyword indicates when to display the subfile. An indicator usually controls this keyword to tell the system when the subfile is displayed. Thus, in our example, if the SFLDSP keyword is active (i.e., indicator 50 is off) when the control-record format is written to the workstation, the subfile is also displayed.

The SFLDSPCTL (Subfile Display Control) keyword controls the display of any output fields or constants defined in the control-record format. Since the

headings defined in the control-record format are for the subfile, this keyword is usually controlled by the same indicator as the SFLDSP keyword.

The SFLCLR (Subfile Clear) keyword indicates when the subfile should be cleared. An indicator also controls this keyword. If the SFLCLR keyword is active (i.e., indicator 22 on) when the subfile control-record format is written to the workstation, the subfile is cleared of records. If an indicator did not condition this keyword, the system would clear the subfile every time a WRITE operation was performed on the control record.

Normally, the indicator used to condition the SFLCLR keyword is the opposite condition of the indicator used for the SFLDSP and SFLDSPCTL keywords. This allows the program to clear the subfile in one WRITE operation and display the subfile and control-record information with a different WRITE operation. Thus, in our example in Figure 17.10, when indicator 50 is on, a WRITE operation to the control-record format will clear the subfile. When indicator 50 is off, a WRITE operation will display both the subfile record format and the subfile control-record format. In addition to controlling the subfile record format, the subfile control-record format includes the headings and fields (if specified) for the subfile.

The complete DDS for the CPCH17ADF display file is shown in Figure 17.11.

Notice that we have added a fourth record format: SFLFOOTER. This record format contains the function key list that is active when the subfile is displayed on the screen. We put the function key list in a separate record format from the control-record format because the control-record format cannot overlay the subfile record format. This means that the control-record format cannot reference lines that are above the subfile record format and lines that are below the subfile record format. If SFLFOOTER and SFLCONTROL were combined, the combined record format would reference the first three lines of the screen (headings) that are above the subfile record format and also reference lines 20–23 that are below the subfile record format. This is not allowed.

The OVERLAY keyword is specified with the subfile control-record format so the SFLFOOTER record format can be displayed and the subfile record format under control of the subfile control-record format can be displayed over the SFLFOOTER record format. Notice, however, that there is no overlap of lines between the two record formats being written to the screen.

Before the program can use a display file, it must be compiled into an object. Entering the CRTDSPF command or entering 14 in the Option field beside the source member name on the Work with Members Using PDM can do this. In either case, the DDS will be compiled. If the compilation is successful, a spool file is created containing the compile-listing, and the display file object is created. If the compilation is not successful, no object is created and a diagnostic report is included with the spool file compile-listing.

Figure 17.11. DDS for display file CPCH17ADF.

To load records into a subfile, records are written to the subfile record format. They are actually written as if the program were writing to a data file. The subfile in effect is a file, and it resides in memory. Writing records to the subfile

record format is known as loading the subfile. There are three ways to load a subfile:

In this chapter, we discuss the three methods of loading a subfile. In addition, we use the load-all method to demonstrate how subfiles are used.

The first method of loading a subfile is to read all of the required records from the data file and load all of these records into the subfile at one time. After the load step is complete, the subfile is displayed. The user can use the page-up and page-down keys to access the subfile records. Since all of the records are loaded into the subfile, the subfile controls paging up and down through the subfile records. The subfile never has to turn control back to the program. Figure 17.12 shows how the load-all method works.

Every record that is to be displayed is loaded into the subfile before displaying the subfile. Sometimes, only a few records are loaded into the subfile; other times, hundreds of records may be loaded into the subfile. But for the load-all method, every record is loaded before the subfile is displayed.

Figure 17.12. Load-all subfile method for loading a subfile.

Loading the subfile is accomplished by writing the subfile records to the subfile record format. Once every record has been loaded, one page of the subfile is displayed by writing the subfile control format as shown in Figure 17.13.

In Figure 17.13, two subfile records are being displayed on the screen at one time. The subfile page size is set to 2, which means subfile page one consists of subfile records 1 and 2. Subfile page two consists of subfile records 3 and 4, and so on.

The user can scroll through the subfile by pressing the page-up and -down keys. The subfile itself handles the paging, and there is no programming required in either the program or the DDS specifications for the display file.

Figure 17.13. Displaying the first screen of records from a load-all subfile.

If the user presses the page-down key, the subfile displays the second subfile page in Figure 17.14 containing subfile records 3 and 4.

Figure 17.14. Displaying the second screen of records from a load-all subfile.

With the load-all method, the user can continue to page through the subfile to view records. When finished, the user presses F3 to terminate the program.

The interactive subfile program CPCH17A is illustrated in Figure 17.17. This program reads records from the logical file EMPPAYL17A that is built over the employee pay file EMPPAYPF. The logical file EMPPAYL17A is a keyed file that is accessed both randomly (START) and sequentially (READ . . . NEXT RECORD) by program CPCH17A. Since the key for this file is the store number, we specify the WITH DUPLICATES clause in the SELECT statement to allow several records with the same store number.

The subfile size (SFLSIZ) has been defined to hold the maximum number of records expected from any one request. The program loads all the records that match the store number into the subfile before any records are displayed. This is called loading the entire subfile. Depending on the number of records that are to be loaded into the subfile, this method can result in slow initial response time while the subfile is being loaded. However, once the subfile is loaded, paging through the subfile is fast, because all of the records are already in the subfile.

In addition to the employee pay file, program CPCH17A defines a TRANSACTION file called DISPLAY-FILE.

The SELECT statement for the TRANSACTION file in our case problem is

The ACCESS IS DYNAMIC clause is used to tell the program how the TRANSACTION file is being accessed. A subfile transaction file is accessed dynamically. Dynamic access allows a program to read records to and write records from a display file sequentially or randomly. Subfiles are the only TRANSACTION files that can be accessed randomly.

The RELATIVE KEY clause must be specified when using a subfile transaction file. This clause identifies a relative key data field, WS-SUBFILE-RECORD-RRN in our example that will represent a subfile record's relative record number. Relative record number refers to the location of the record within the file relative to the beginning of the file. Thus, the first record in the file is relative record number 1, the second record is relative record number 2, and so on. A relative record number field must be specified when using a subfile because the subfile program writes records to, and reads records from, the subfile, based on a value in the relative record number field. When used in the program, the WS-SUBFILE-RECORD-RRN indicates to which record in the subfile an I/O operation is referring. The value of WS-SUBFILE-RECORD-RRN is updated to reflect the relative record number of the record made available to the program.

The CONTROL-AREA clause defines the storage area used for the specific information that is transmitted during input-output operations for TRANSACTION file. The CONTROL-AREA clause in the WORKING-STORAGE SECTION is with the following format.

Level-88 condition-name entries are assigned to the conditional variable WS-FUNCTION-KEY. WS-FUNCTION-KEY-03 and WS-FUNCTION-KEY-12 are condition-names.

The FILE STATUS clause provides feedback on the status of input-output to a TRANSACTION file. In actual practice, it is common to define a FILE STATUS clause in the SELECT statement. The FILE STATUS clause refers to a 2-byte alphanumeric variable that will contain the return code from an I/O operation

on the TRANSACTION file. The return code value indicates the status of the execution of the I/O statement. In general, it is a good coding practice to check this return code after each I/O operation; although, for simplicity sake, in this example, no such code exists. The first byte of the return code indicates the general result of an I/O operation, whereas the second byte provides further information on the first byte. A successful I/O operation has a "0" in the first byte. When an unsuccessful I/O operation occurs, a "9" is placed in the first byte. If there is no further information, the second byte will also be "0."

When a WRITE to the subfile occurs and the subfile already contains the number of records indicated in the SFLSIZ keyword, a program interrupt occurs and the file status 9M is returned to the program. We can prevent this from happening by using the PROCESS statement at the beginning of the program. The PROCESS FS9MTO0M statement changes the file status return code from 9M to 0M, a warning-level status code. Instead of causing the program to terminate, the warning is ignored, and the subfile is allowed to dynamically increase in size.

Since the file-level keyword INDARA is specified in the DDS for the display file (see Figure 17.11), all indicators defined in the display file are passed to and from the program in a separate area. They are not defined as part of the record formats.

The group item WS-INDICATOR-LIST, shown in Figure 17.15, defines data description entries in the WORKING-STORAGE SECTION for all indicators used in the display file. Meaningful descriptions are assigned to each condition with Level-88 condition-names.

Figure 17.15 also illustrates the INDICATORS phase that is used in READ and WRITE statements when it is necessary to send the indicator values to the screen. When it is necessary to clear the subfile, the SET CLEAR-SUBFILE TO TRUE statement is used to move the Boolean value B'1' to IN50 (indicator 50). In Figure 17.11, indicator 50 is specified on the SFLCLR line, telling the system to clear the subfile when the SFLCONTROL record format is written to the display file.

Figure 17.15. Using indicators defined in a separate indicator area.

The function key returned by the program is stored in WS-FUNCTION-KEY, which is a separate area in WS-CONTROL. WS-CONTROL is identified as the CONTROL-AREA in the SELECT statement, as shown in Figure 17.16. When a record format is sent to the program, the first two bytes of the CONTROL-AREA, WS-FUNCTION-KEY in this example, contain the indicator number, if an indicator was pressed. If no indicator was pressed, WS-CONTROL contains zeroes.

Figure 17.16. Defining function key as part of the CONTROL-AREA field.

If the same field name is used to define fields in different records or group items, you must indicate which record or group item is to be accessed by qualifying the identifier with the word OF or IN. Consider the field name COMPANY-NAME described below in the COMPANY-RECORD-IN record description and COMPANY-NAME in the DETAIL-LINE group item:

In this example, the MOVE operation cannot be specified as MOVE COMPANY-NAME TO COMPANY-NAME, since COMPANY-NAME is the name of two different fields and it is unclear which field is which. Instead, the word OF or IN is used to distinguish one field from another, as shown in the example above. When more than one field in storage has the same name, we qualify the name in the PROCEDURE DIVISION as follows.

Instruction Format

The words OF and IN may be used interchangeably to qualify a name. A field name may be qualified by using OF or IN with the name of either a record or group item of which the field is a part.

Specifying the same identifier to define several fields in separate records is frequently considered a useful programming tool. Many people believe that qualification of names makes PROCEDURE DIVISION entries easier to understand for someone reading the program and easier to debug.

On the other hand, many installations prefer software developers to use unique names with descriptive prefixes or suffixes to define data. To say, for example, MOVE COMPANY-NAME-IN TO COMPANY-NAME-OUT, where COMPANY-NAME-IN is an input field and COMPANY-NAME-OUT is an output field, is often considered better than coding MOVE COMPANY-NAME OF COMPANY-RECORD-IN TO COMPANY-NAME OF DETAIL-RECORD.

In display files, the same field name is used to define fields that are used in a record format as input and output. The OF or IN identifiers are used to distinguish the input field from the output field. In Figure 17.17, we use the OF qualifier when moving data to the display file.

The WRITE SUBFILE statement is used to write a record to the subfile TRANSACTION file. The WRITE SUBFILE statement is specified as

The program CPCH17A in Figure 17.17 writes a subfile record in 225-READ-EMPLOYEE-RECORD-RTN. Notice that the syntax of the WRITE statement includes the SUBFILE keyword. This tells the system that the program is writing to a subfile record, that is, it is moving information into one of the identical lines. The question now is, Which one of the identical lines? The SELECT statement for the display file specifies DYNAMIC access as well as a RELATIVE KEY, WS-SUBFILE-RECORD-RRN. It is the relative record key field that determines from which, or to which, the subfile record is read or written.

Figure 17.17. Interactive load-all subfile inquiry program CPCH17A.

The expanding subfile method is the second method that can be used to load a subfile. With the expanding subfile method, a specific number of records are initially loaded into the subfile. Then, the subfile is allowed to grow or expand to accommodate additional records, when requested by the user.

Once the initial records are loaded into the subfile, the subfile is displayed to the user. If the information the user needs is not currently loaded into the subfile, the subfile is expanded and the program loads more subfile records behind those already loaded. This technique is known as an expanding subfile.

Figure 17.18 illustrates an expanding subfile in which the program starts by first loading a fixed number of records. In this example, the program initially loads four records into the subfile.

Figure 17.18. Loading the initial records into an expanding subfile.

The program then displays the subfile to the user. By default, the subfile displays the first subfile page in Figure 17.19.

Figure 17.19. Displaying the first page of records from an expanding subfile.

If the user presses the page-down key, the subfile automatically displays page two of the subfile as shown in Figure 17.20. In this situation, records 3 and 4 are already loaded in the subfile. Since the records are in the subfile, the subfile handles the paging and does not have to return to the program.

Figure 17.20. Displaying the second screen of records from an expanding subfile.

If the user attempts to page down past the second page, the subfile determines that there are no more records in the subfile to display and returns control back to the program. The program expands the subfile and loads four more records, as shown in Figure 17.21.

Figure 17.21. Loading more records into an expanding subfile.

Once the subfile has been expanded with more records, the program displays the third page of records, as shown in Figure 17.22.

Figure 17.22. Displaying the third screen of records from an expanding subfile.

This is the concept behind the expanding load method. A fixed number of records is loaded into the subfile. If the information the user needs is not in the subfile, the program loads another fixed number of records. The program continues with this process until the user finds the information he or she is looking for, or there are no more records to load.

The third method of loading a subfile is known as single-page loading. In this process, the program only loads the number of subfile records that can be displayed on the screen at one time. If the information the user needs is not in the subfile, then the existing subfile records are cleared, and another page of subfile records is loaded.

Figure 17.23 illustrates the single-page load method. In this example, the subfile page value is set to four.

Figure 17.23. Loading the first page of records into a single-page subfile.

In the single-page load method, the program loads only one page of records into the subfile. In this case, it loaded four records. The program then displays the subfile records, as shown in Figure 17.24.

Figure 17.24. Displaying a page of records from a single page subfile.

If the information that the user wants to see is not on this page of subfile records, then the program just cannot add more records to the subfile, as in the expanding subfile method. The program must first clear the existing records in the subfile, as shown in Figure 17.25.

Figure 17.25. Clearing a single page subfile for the next page of records.

The next page of records is loaded into the subfile, as shown in Figure 17.26. Notice that these records are numbers 1–4. Since the subfile only contains four records at a time and the subfile was cleared in the previous step, the next group of records would be the first four records in the subfile.

Figure 17.26. Loading the next page of records into a single-page subfile.

Once the next single page is loaded, it is displayed to the user, as shown in Figure 17.27.

Figure 17.27. Displaying a page of records from a single page subfile.

In this case problem, we discuss how a simple update procedure can be performed using interactive subfile programming techniques. As a review, the DDS for the employee pay file EMPPAYPF is shown in Figure 17.28. This program uses the same logical file as program CPCH17A in case problem #1. The logical file is shown in Figure 17.29.

Figure 17.28. Data description specifications (DDS) for the EMPPAYPF physical file

Figure 17.29. Data description specifications (DDS) for the EMPPAYL17A logical file

Similar to the CPCH17A inquiry program, the prompt screen in Figure 17.30 is used to accept the store number for the group of records that the user wishes to view and change. The program retrieves the group of records from the file, calculates the employee's commission based on 6 percent of sales, and loads the subfile. The subfile is then displayed, as shown in Figure 17.31. In this application, the user is allowed to update the sales field. When the user presses the Enter key, the program reads only those records from the subfile that have been modified. The program retrieves the matching records from the employee pay file and updates the records with the new data. It then calculates the new commission, updates the subfile records, and writes the records back to the subfile. Once the modified records have been updated, the subfile is rewritten to the workstation, so the user can verify the changes made.

The DDS for the display file is shown in Figure 17.32. The program solution to this case problem is illustrated in Figure 17.33.

Figure 17.30. Screen format that accepts the store number.

Figure 17.31. Subfile display of employee records for the specified store.

Figure 17.32. Data description specifications for CPCH17BDF.

To access subfile records in a display file, the program must specify the SUBFILE phrase with the input/output operation. Valid subfile operations are

Subfiles can be processed sequentially with the READ SUBFILE NEXT MODIFIED RECORD statement, or processed randomly by specifying a relative key value. A relative key is an unsigned number that can be used directly by the system to locate a record in a file.

The READ SUBFILE DISPLAY-FILE NEXT MODIFIED RECORD statement reads the next record from the subfile that was modified. That is, it reads only those records the user modified by entering a new sales amount. If NEXT MODIFIED is specified and there are no further user-modified records in the subfile, the AT END condition exists. When a modified record has been read from the subfile, the program:

When the subfile record is updated, the REWRITE SUBFILE DISPLAY-FILE statement is used. When the update is performed, the program uses the relative record number stored from the READ operation to locate the record in the subfile.

The entire subfile program is shown in Figure 17.33.

Figure 17.33. Interactive load-all subfile update program CPCH17B.

For this assignment, complete all phases for the creation of the display file and coding of the program. Note that a part could be stored at several different warehouses.

Record description layout for part master file

Record description layout for part description file

Format SFLPROMPT (prompt user for part number)

Subfile to view part information