Upon completion of this chapter, you should be able to

Thus far, we have seen that an OCCURS clause may be used as part of an input record to indicate the repeated occurrence of incoming fields. Similarly, an OCCURS clause may be used as part of an output record to define a series of fields. An OCCURS clause may be used to define fields either in the FILE SECTION or in WORKING-STORAGE.

Suppose, for example, that an input file contains transaction records:

Since there is no item that is repeated, we do not need to use the OCCURS clause within this input record. Suppose we wish to establish an array in WORKING-STORAGE that consists of 12 monthly totals for all transaction records.

We define 12 MONTH-TOTAL fields in WORKING-STORAGE to store the total of all transaction amounts for months 01–12, respectively. Each MONTHLY-TRANSACTION-RECORD read will include an AMOUNT-IN and a MONTH-IN number. The program adds the AMOUNT-IN to a MONTH-TOTAL field determined by the content of the MONTH-IN entered within DATE-OF-TRANSACTION-IN. If MONTH-IN = 2, for example, the program adds the AMOUNT-IN to the second MONTH-TOTAL, or MONTH-TOTAL (2).

Note that the MONTH-TOTAL fields must be initialized to zero at the beginning of the program before any AMOUNT-IN fields are added to them. If not, a decimal data error will occur when the program tries to add the AMOUNT-IN field to one of the MONTH-TOTAL elements in the array. There are several methods that can be used to initialize the 12 MONTH-TOTAL fields.

To initialize the 12 MONTH-TOTAL fields to zeros in the PROCEDURE-DIVISION, the following may be used:

The VALUE clause may be used in WORKING-STORAGE:

The following program excerpt illustrates how the total amounts for months 1–12 are accumulated.

A subscript called MONTH-IN determines to which MONTH-TOTAL element the content of the input field AMOUNT-IN is to be added. In this case, this subscript is also an input field. As noted previously, subscripts can be data-names defined in either the FILE SECTION or the WORKING-STORAGE SECTION. If MONTH-IN is 3, for example, the program adds AMOUNT-IN to the third MONTH-TOTAL element. Coding ADD AMOUNT-IN TO MONTH-TOTAL (MONTH-IN) will add an amount to the month total element indicated by the month number entered as input.

The LIKE clause may be used within an OCCURS clause to define an element of the array as having the same attributes as a field outside the array. Consider the following example.

In this example, MONTH-TOTAL, which occurs 12 times, is defined using the LIKE clause. The MONTH-TOTAL field is defined as LIKE AMOUNT-IN, that is, it takes on the same attributes as AMOUNT-IN. In addition, the use of (+2) makes the length of the field two digits longer. The array MONTHLY-TOTAL-ARRAY is 84 bytes long.

Let us consider another example where the LIKE clause is used to define a field that will take on the same attributes as a field within an array.

In this example, MONTH-OUT takes on the same attributes as MONTH-NAME in the MONTHLY-NAME-ARRAY. Thus, MONTH-OUT is defined as PIC X(9). The MONTH-TOTAL-RECORD is 13 bytes long.

You should use input fields as subscripts only if you are sure they have valid values. In this case, MONTH-IN should only vary from 1 to 12. If MONTH-IN were erroneously entered with a value that was less than 01 or greater than 12, the program will terminate abnormally. To minimize such errors, 200-PROCESS-RECORD-RTN could include a validity check:

From the program excerpt you can see that the module will read each record and, if it contains a valid MONTH-IN, the AMOUNT-IN will be added to the appropriate MONTH-TOTAL element. After all the input has been processed, control will return to the main module where the monthly totals are printed. The

monthly totals are to print in sequence from 1 to 12. The pseudocode for this entire program is shown in Figure 15.2. The program that uses a PERFORM 300-PRINT-RTN VARYING . . . statement, with a subscript varying from 1 to 12, to print the array is shown in Figure 15.3.

Figure 15.2. Pseudocode for program that accumulates and prints 12 month totals.

Thus, the WORKING-STORAGE array called MONTHLY-TOTAL-ARRAY is accessed in two ways:

Note that a control break procedure could be used in place of array processing if the data were entered in sequence by month number.

Figure 15.3. Program that accumulates and prints 12 monthly totals.

Thus far, we have focused on OCCURS clauses that define elementary items.

The 05-level item defined by an OCCURS clause has a PIC clause, making the 12 MONTH-TOTAL fields elementary items. Thus, MONTHLY-TOTAL-ARRAY is an 84-byte array (12 × 7) consisting of 12 elementary items:

The identifier used with an OCCURS clause may be a group item as well.

In this instance, CITY and TAX-RATE each occur 20 times within a group item called CITY-TAX:

Similarly, to print out 20 tax rates, we could have the following print record:

We want the decimal point to print, so we use .999 as the PIC clause for TAX-RATE-OUT. The blank field name that occurs 20 times will ensure that there are two spaces between each printed tax rate.

Example 1: Consider again the array consisting of monthly totals that was defined previously.

Suppose all the data has been read from the transaction records and added to the correct array element. Now we wish to write a routine to find the year-end final total, that is, the sum of all monthly totals. The structured pseudocode for this procedure is

Structured Pseudocode

The program excerpt for this procedure is

This procedure could also be written with a PERFORM . . . UNTIL or a PERFORM . . . TIMES. In all cases, an in-line PERFORM can be used as well.

Example 2: Using the same array, find the number of months in which the monthly total exceeded $10,000. The pseudocode and program excerpt for this procedure are

Structured Pseudocode

Program Excerpt

At the beginning of this chapter, we discussed a program that processed 24 hourly temperatures for a given city for a particular day. We used a PIC S9(3) clause with S, so any city's temperatures could be defined, even if the temperature fell below zero. The input record is defined as

We could have several such records, each containing temperatures for a different day. Suppose that we want to print out on one line the 24 hourly temperature values in each input record. We can also use the OCCURS clause in an output record, as illustrated in the following program excerpt.

TEMPERATURE-ENTRIES is a group field that consists of two elementary fields: TEMPERATURE-OUT and a 1-byte blank field. The second field is a separator, which is necessary so that there is a single blank between each temperature for readability. The layout for the print positions of TEMPERATURE-RECORD-OUT, then, is

The preceding is a program that reads records, each with 24 hourly temperatures, and prints all 24 temperatures for each record on a single line. The program has two arrays, one for storing 24 hourly temperatures per input record and one for storing the same temperatures along with separator fields in the output area.

Suppose we wish to read in the same series of 24 hourly temperatures and print the highest temperature for each day. The input would be the same. The TEMPERATURE-RECORD-OUT and description for HIGHEST-TEMPERATURE in WORKING-STORAGE would be

The MAIN-MODULE of the PROCEDURE DIVISION would be the same as the preceding. 200-PROCESS-RECORD-RTN and 220-MOVE-RTN would be

Note that this program handles temperatures that could fall below zero degrees because the PIC for the temperatures contains an S. We initialize

HIGHEST-TEMPERATURE at −999, a negative number so low that the first TEMPERATURE (SUB) will exceed it and be moved to it as the first "real" entry. Alternatively, we could MOVE TEMPERATURE (1) TO HIGHEST-TEMPERATURE initially and PERFORM 220-MOVE-RTN VARYING SUB FROM 2 BY 1 UNTIL SUB > 24. The edited field, HIGHEST-TEMPERATURE-OUT, contains a minus sign that will print only if HIGHEST-TEMPERATURE-OUT happens to be negative.

If we wanted to print the number of hours in a day when the temperature dipped below 40 degrees, we would write our TEMPERATURE-RECORD-OUT as

200-PROCESS-RECORD-RTN is the same, except that we INITIALIZE WS-COUNTER to zeros, not to HIGHEST-TEMPERATURE. 220-MOVE-RTN would be

Consider the TEMPERATURE-FILE described in the preceding section. Suppose we wish to print 24 lines of output, each with an hourly temperature.

The TEMPERATURE-RECORD-OUT would appear as

The routine for printing 24 lines would be as follows, using an in-line PERFORM:

Suppose, instead, that we want to print 12 lines of output, each with an A.M. temperature and a P.M. temperature.

The program excerpt is

Suppose we wish to print two lines of output, the first with 12 A.M. temperatures and the second with 12 P.M. temperatures. The sample output is shown here:

The program excerpt is shown below. SUB1, used for subscripting TEMPERATURE, varies from 1 to 24 within 420-PRINT-RTN, and SUB2, used for subscripting TEMPERATURE-OUT, varies from 1 to 12 within 420-PRINT-RTN, which is executed twice, once for each output line.

The full program for printing the previous three examples is shown in Figure 15.4.

Figure 15.4. Program CPCH15B that prints temperatures.

In this section, we focus on the OCCURS clause to store table data. As we will see, tables and arrays are stored in exactly the same way; they are, however, used for different purposes.

A table is a list of stored fields that are looked up or referenced by the program. Tables are used in conjunction with table look-ups, whereas a table look-up is a procedure that finds a specific entry in the table.

Thus, an array stores data or totals to be manipulated or outputted, whereas a table is used for looking up, or referencing, data.

Suppose that a mail-order company ships items to customers throughout the country. A program is required that (1) reads customer input data containing billing information and (2) produces output in the form of bills. Since each county within the United States has a different local tax structure, a procedure must be established for calculating sales tax. Two techniques may be employed:

This is a far more efficient and effective method for storing tax rate data than the first method. Input to the program would consist of two files. The table file with sales tax rates corresponding to each county is entered as the first file and stored in WORKING-STORAGE. Then the input transaction file is read; for each input transaction record, we would find or look up the sales tax rate in the table that corresponds to the county specified in the input record.

Suppose there are 1000 tax rates and 10,000 customer records. To include a sales tax rate in each input record would require 10,000 additional fields to be entered as input. It is better to (1) enter and store the 1000 sales tax rates as a table and (2) look up the appropriate rate in the table for each input customer record.

To store a table, we must associate a sales tax rate with each specific tax district. We may use the Zip Code to identify each tax district.

Assume that a sales tax rate for each Zip Code is stored in a sales tax table.

The sales tax file is read first, with Zip Codes and sales tax rates, and stored in WORKING-STORAGE. Then the input customer file is read. The Zip Code from each customer record is compared to the Zip Code in the table until a match is found. The sales tax rate corresponding to a specific Zip Code is used to calculate a total price to be printed:

The SALES-TAX-TABLE consists of table entries, where each table entry is a group item subdivided into a Zip Code field and its corresponding sales tax rate. The table argument is the table entry field that is used to locate the desired element. Here, the table argument is the table's Zip Code field. The element to be looked up is called the table function. In this case, the table function is the table's sales tax rate. The input field in each transaction record that is used for finding a match is called the search argument. We compare the search argument to the table argument to find the table function. Consider the following example.

In this example, a Zip Code of 12344 is in the input transaction record. This is the search argument. We use this search argument to find the corresponding table argument, which is the Zip Code of 12344 in the table. The table function is the sales tax rate corresponding to that Zip Code, which is 8%, or ˆ080.

After the table is read in, and stored in, WORKING-STORAGE, we enter input transaction records. For each transaction record, we search the table to find the table argument that matches the transaction record's Zip Code, or search argument. When a match is found between the input transaction Zip Code (the search argument) and the table's Zip Code (the table argument), we know the table function or sales tax rate is the corresponding table entry. That is, if the fifth table argument is a Zip Code of 12344, then the sales tax rate we want is also the fifth entry in the table.

The program to produce the desired customer bills may be divided into two basic modules: (1) reading and storing the table and (2) processing each input record, which includes a field that is used for a table look-up.

Suppose this transaction file has customers from 1000 Zip Code locations. We would have, then, 1000 table records on disk with the following format:

The pseudocode for this problem is shown in Figure 15.5.

Figure 15.5. Pseudocode for sample table-handling routine.

The TAX-FILE could be specified:

Note that we do not indicate in the DATA DIVISION the number of table records that will be processed. That is, we do not use an OCCURS clause to denote the repeated occurrence of 1000 table records. Instead, in the PROCEDURE DIVISION the program performs the 120-TABLE-ENTRY module 1000 times. During each perform of 120-TABLE-ENTRY, a record is read from the TAX-FILE and loaded into the table.

Since table data must be stored before processing of the input customer file begins, a WORKING-STORAGE area is needed to hold the 1000 table entries:

Because the word TABLE is a reserved word, it should not be used in a program as an identifier unless it has a prefix or suffix.

The WORKING-STORAGE table stores the 1000 entries:

The main input file will contain customer billing or transaction data used to produce an output file of bills.

000-MAIN-MODULE and 100-INITIALIZATION-RTN include references to both the 120-TABLE-ENTRY and 200-PROCESS-RECORD-RTN modules:

Consider the PERFORM 120-TABLE-ENTRY statement. When SUB exceeds 1000, that is, when it is 1001, 120-TABLE-ENTRY has been performed 1000

times, and control returns to the initialization module. Since SUB, as a subscript, will vary from 1 to 1001, it must be defined as a four-position numeric field.

A READ . . . INTO instruction is best suited for loading tables because it can take the place of a READ followed by multiple MOVEs.

An initial READ is not necessary for processing the TAX-FILE because we know precisely how many table records are to be read. Since 1000 table entries are to be read and stored, we execute the 120-TABLE-ENTRY routine 1000 times by varying the subscript from 1 to 1001.

Subscripts must be used when referencing the table entries WS-ZIPCODE and WS-TAX-RATE in the PROCEDURE DIVISION. Recall that WS-ZIPCODE will be the table argument and WS-TAX-RATE the table function. We use a subscript name of SUB here for reasons that will become clear in the next section.

For this program, 1000 table records are to be read and stored. If an error has occurred and there are fewer than 1000 table records, the AT END is executed and the run terminates. If an error has occurred and there are more than 1000 table records, we would only process the first 1000. For validating purposes, we may want to ensure that there are precisely 1000 table records. The following can be written.

The DISPLAY verb is used, as shown here, to display brief messages to the user.

Sometimes we have a variable number of table entries, but we know that the number will not exceed a specific value. If, in the preceding, there are at most

1000 table entries, but there could be fewer, we replace the first IF in 100-INITIALIZATION-RTN with

Then, when we process the table we use NUMBER-OF-ENTRIES, not 1000, to control the maximum number of times we access the table. Suppose we want to know the number of Zip Codes that have a tax rate of 10 percent. The following would be written.

After the table entries have been stored in WORKING-STORAGE, we read customer billing data and produce bills. To find the sales tax rate, or table function, for each Zip Code, however, we must look up the Zip Code in the table (table argument) until it matches the Zip Code in the customer record (search argument). When a match is found between the table argument and the search argument, the corresponding sales tax rate (the table function) with the same subscript as the table's Zip Code will be used for calculating the sales tax. In the next section, we discuss how a table is searched using a SEARCH verb. In Figure 15.6, we use a PERFORM . . . UNTIL to search the table. We are assuming that the table has precisely 1000 entries.

Figure 15.6. Using a PERFORM ... UNTIL to search a table.

With the SEARCH statement, the AT END clause specifies what should be done if the table has been completely searched and no match is found. That is, suppose the ZIP-IN field does not match any WS-ZIPCODE field in the table; such a condition will cause the AT END clause to be executed if it is specified. Since it is possible for input errors to occur, we strongly recommend that you always use this optional clause. Without it, the "no match" condition would simply cause

the program to continue with the next sentence. This could produce incorrect results or even cause a program to terminate abnormally.

To use a SEARCH statement, two additional entries are required: the INDEXED BY clause, along with OCCURS, and the SET statement in the PROCEDURE DIVISION.

When using a SEARCH statement, table entries must be specified with an index rather than a subscript. An index is similar to a subscript, but it is defined along with the table entries as part of the OCCURS description:

As noted, the index, SUB in this illustration, functions like a subscript. Note, however, that unlike a subscript, an index is not defined separately in WORKING-STORAGE. It is defined with an INDEXED BY clause along with the OCCURS. The compiler automatically provides an appropriate PICTURE clause, in this case 9(4), since there are 1000 entries in the table.

The SEARCH statement will perform a table look-up. TABLE-ENTRIES, the identifier used with the OCCURS and INDEXED BY clauses, is the item designated with the SEARCH as well. The 01-level entry, SALES-TAX-TABLE, could not be used with the SEARCH.

The table will be searched and the index automatically incremented until the condition specified in the WHEN clause is satisfied or until an AT END condition is met. The AT END indicates that the table has been completely searched without the condition being met; that is, no match has been found between an input field (search argument) and a table entry (table argument). Frequently, we specify the AT END as:

SEARCH . . .
AT END
PERFORM 250-ERROR-RTN
WHEN. . . .

Note that the software developer must initialize an index before each SEARCH to start a table look-up at the first entry.

The difference between a subscript and an index is worth noting because indexes are processed more efficiently than subscripts. As we have seen, a subscript is a field that refers to the number of the table entry we want to reference. Consider the following.

An index for MONTHLY-SALES can be established with an INDEXED BY clause on the OCCURS level. Like a subscript, the index will, in effect, vary from 1 to 12. Internally, however, the computer uses displacement values to actually access indexed table entries. The first table entry has a displacement of zero bytes

from the start of the table, the second has a displacement of 3 bytes from the start of the table, and so on, with the last table entry having a displacement of 33 bytes from the start of the table:

The displacement values used by an index depend on the number of bytes in each table entry, which is 3 in our example. To the software developer, it may not seem to make a difference whether we use a subscript or an index to access a table entry. The only difference is that a subscript is a separate WORKING-STORAGE entry, while the index is defined by an INDEXED BY clause on the OCCURS level. Both can have values from 1 to 12 in this example. An index, however, is processed more efficiently than a subscript. When you define an index, the computer sets up an internal storage area called an index register, which uses the displacement values determined by the index to access table addresses. This is faster than working with subscripts. We recommend, therefore, that you use indexes and SEARCH statements for table look-ups.

Because an index refers to a displacement and not just an occurrence value, its contents cannot be modified with a MOVE, ADD, or SUBTRACT like a subscript can. To change the contents of an index, then, we use either (1) a PERFORM . . . VARYING, which can vary the values in either subscripts or indexes, or (2) a SET statement, which can move, add, or subtract values in an index.

As you can see from the format for the SEARCH statement, multiple WHEN clauses are permitted. Let us consider an example.

Suppose the preceding INVENTORY-TABLE consists of 100 PARTS, where the PART-NUMBERs are in sequence but are not necessarily consecutive. That is, the first entry may be for PART-NUMBER 001, the second for PART-NUMBER 003, the third for PART-NUMBER 008, and so on. The PART-NUMBERs may not be consecutive because some parts may no longer be stocked, whereas newer ones with different numbers may have been added.

If we enter a PART-NUMBER-IN as input and wish to determine its UNIT-PRICE, we can write

Since the table is in sequence by PART-NUMBER, we could save computer time by exiting the SEARCH procedure as soon as a PART-NUMBER-IN > PART-NUMBER (SUB). Suppose PART-NUMBER-IN is 006, for example, and that PART-NUMBER (1) = 001, PART-NUMBER (2) = 003, and that PART-NUMBER (3) = 008. We would know after the third comparison that there is no match. Using the preceding routine, the program would search through all 100 entries before indicating 'NO MATCH.' For more efficient processing, we could use two WHEN clauses instead.

With two WHEN clauses, the program begins by performing the first comparison. Only if the condition in the first WHEN is not met does it test the second WHEN. That is, only if there is no match will a test be made to see if the search should be terminated and 'NO MATCH' displayed. There is no need for an AT END clause here because 'NO MATCH' will be displayed at some point. It will be displayed either when the end of the table is reached or as soon as a PART-NUMBER-IN is greater than some PART-NUMBER (SUB).

If there were 100 PART-NUMBERs and they varied consecutively from 1 to 100, the PART-NUMBER would not have to be stored. We would know, for example, that UNIT-PRICE (5) refers to PART-NUMBER 005. Likewise, we know that ITEM-DESCRIPTION (10) refers to the description for PART-NUMBER 10.

To determine the unit price for a PART-NUMBER, where the numbers vary from 1 to 100, we could write

MOVE UNIT-PRICE (PART-NUMBER-IN) TO DL-UNIT-PRICE.

We could use the PART-NUMBER-IN as a subscript and eliminate the need for a SEARCH entirely. This type of table is called a direct-referenced table. In this example, INVENTORY-TABLE could only be a direct-referenced table if PART-NUMBERs varied consecutively from 1 to 100.

Sometimes we may want to search for multiple matches in a table. In such instances, it is better to use a PERFORM, rather than a SEARCH, statement for processing the entire table, because we want to continue processing the table even after a match is found. The SEARCH . . . WHEN looks up data from the table until a match is found, at which point the program continues with the next sentence. A PERFORM . . . VARYING can be used to process an entire table even after a match is found. Suppose we want to know the item descriptions for all parts with a unit price greater than 100.00. We could write

Thus far, we have focused on tables that are inputted as data from disk before transaction records are entered. We read in tables in this way when their contents are likely to change periodically. When tables are stored on disk, their contents can be changed as the need arises without having to make modifications to the program accessing the table. Such tables are called external tables.

If the contents of a table is fixed, that is, not likely to change, we can define it with VALUE clauses directly in the WORKING-STORAGE section. In this way, we

need not read it in each time. Consider the MONTH-NAMES entry we defined previously.

The subscripted variables MONTH(1) through MONTH(12) can be used for accessing the month names JAN through DEC, respectively, without the need for loading a table with the 12 month names. This is called an internal table since it is actually part of the program. We store month names in an internal table because the values are not likely to change.

We have illustrated how to add values to an array and how to look up data in a table. In this section, we combine both techniques.

Suppose a store has 25 charge account customers, each with his or her own customer number (CUSTOMER-NUMBER). We want to read in transaction records and print the accumulated BALANCE-DUE for each customer. If the CUSTOMER-NUMBERs vary from 1 to 25, we need only store 25 BALANCE-DUEs in an array.

This would be another illustration of a direct-referenced array, where BALANCE-DUE(CUSTOMER-NUMBER-IN) can be used to access specific balances. The CUSTOMER-NUMBERs need not be stored because they vary from 1 to 25. The procedure to add to the appropriate BALANCE-DUE would be

CUSTOMER-ARRAY is a direct-referenced array because BALANCE-DUE (1) refers to the first CUSTOMER-NUMBER, BALANCE-DUE (2) refers to the second CUSTOMER-NUMBER, and so on. This type of direct-referenced array is valid only if CUSTOMER-NUMBERs vary consecutively from 1 to 25.

Suppose, however, that the CUSTOMER-NUMBERs for the 25 customers are not consecutive. For this situation, you need to store the CUSTOMER-NUMBERs as well as accumulate the total BALANCE-DUE for each customer. The 200-ADD-TO-BALANCE procedure could use a SEARCH to find a specific CUSTOMER-NUMBER and add to the corresponding BALANCE-DUE.

The SEARCH has two WHEN clauses. If a customer number already appears in the array, an existing T-CUSTOMER-NUMBER (SUB) will equal the CUSTOMER-NUMBER-IN. Then we simply add AMOUNT-IN to the corresponding T-BALANCE-DUE (SUB). If the CUSTOMER-NUMBER-IN does not match an existing T-CUSTOMER-NUMBER in the table, then the first T-CUSTOMER-NUMBER with a zero will be replaced with the CUSTOMER-NUMBER-IN and the AMOUNT-IN will become the T-BALANCE-DUE for that customer. If 25 customer numbers are

already stored in the array and a customer number is entered as input that does not match any of them, then an error message will be displayed.

This illustration shows how to process nonconsecutive customer numbers that must be stored along with the accumulated balances. It also shows how to use two separate WHEN clauses in a SEARCH.

Figure 15.7 illustrates the full program. Note that the program will not print CUSTOMER-NUMBERs in sequence unless they were entered in sequence.

Figure 15.7. COBOL program CPCH15D, which uses two WHEN statements.

The following is an alternative way of processing tables. If the customer numbers were not consecutive but we knew in advance what they were, we could store them in a separate table.

Then we can store the balances due in a separate array.

These would be parallel tables with the CUSTOMER-NUMBER-TABLE storing 25 customer numbers and the CUSTOMER-BALANCE-ARRAY storing the corresponding BALANCE-DUE for each:

When the program reads CUSTOMER-NUMBER-IN, it searches CUSTOMER-NUMBER-TABLE to determine which entry to add to in CUSTOMER-BALANCE-ARRAY. We can use the SEARCH . . . VARYING option for processing parallel arrays.

This technique enables us to enter CUSTOMER-NUMBERs into one table and store BALANCE-DUEs in a corresponding parallel table. Since the CUSTOMER-NUMBERs are not consecutive, a direct-referenced CUSTOMER-ARRAY cannot be used. Note, too, that the output report would be in sequence only if the CUSTOMER-NUMBERs entered as input are in sequence.

We use SUB1, the index of the parallel table, in the SEARCH . . . VARYING, not the index of CUSTOMER-NUMBER-TABLE. The SEARCH . . . VARYING has the following format.

Instruction Format

* The NEXT SENTENCE clause is not permitted with the END-SEARCH.

Thus far, we have discussed the method of table look-up called a serial search.

A sequential or serial search, as described here, is best used when either

In many instances the table entries are arranged in some numeric sequence. In a DISCOUNT-TABLE, for example, the table entries are apt to be in ascending sequence by customer number:

DISCOUNT-TABLE

The table contains the discount percentage to which each customer is entitled. Note that although the customer numbers are in sequence, they are not necessarily consecutive, so we must store the T-CUSTOMER-NUMBER as well as the T-DISCOUNT-PCT.

We could write the table as

In this table, a discount of 2.0 percent, for example, is stored as ˆ020.

In cases where the entries in a table are in some sequence, a serial search may be inefficient. For example, it would be time-consuming to begin at the first table entry when searching for the T-DISCOUNT-PCT for customer number 9000. Since the table is in sequence, we know that customer number 9000 is somewhere near the end of the table; hence, beginning with the first entry and proceeding in sequence would waste time.

When table entries are arranged in sequence by some field, such as T-CUSTOMER-NUMBER, the most efficient type of look-up is a binary search. Following is the way the computer performs a binary search.

On average, a binary search on a table that is in sequence by some field takes fewer comparisons to find a match than does a serial search.

Example

Suppose CUSTOMER-NUMBER-IN = 5000

CUSTOMER-NUMBER-IN matches T-CUSTOMER-NUMBER when the thirty-fourth entry of the table is compared. If a serial search were used, 34 comparisons would be required. The binary search method, however, requires only four comparisons in this instance. In general, for tables with 50 or more entries in sequence by some field, a binary search will save time.

This alternative method for table look-ups is called a binary search because each comparison eliminates one-half the entries under consideration; that is, each comparison reduces the entries to be searched by a factor of two.

A binary search is preferable to a serial search:

For small tables or those in which entries are not arranged in a sequence, the standard serial search look-up method previously described is used. For large tables in which entries are arranged in a specific sequence, the binary search is most efficient. It is difficult to define a "large" table explicitly, but let us say that any table containing more than 50 entries that are in some sequence could benefit from the use of a binary search.

The SEARCH ALL statement is used to perform a binary search. The format of the SEARCH ALL is very similar to that of the SEARCH.

Basic Format

*NEXT SENTENCE cannot be used with END-SEARCH.

A SET statement is not necessary with the SEARCH ALL, since the computer sets the index to the appropriate point initially when each binary search begins. Consider the following example.

Note that there are a number of limitations placed on the use of a binary search using a SEARCH ALL statement. First, binary searches can be used only with WHEN clauses that test for equal conditions between a table argument and a search argument. That is, the syntax for a SEARCH ALL requires the WHEN to use = (not <, >, <=, or >=) as the relational test.

This means that you must use a serial search when the look-up checks for a range of entries rather than a single match, even if the table is in sequence. Suppose we want to find a UNIT-PRICE that is <= 100.00, where table entries are in sequence by UNIT-PRICE.

Using a serial search, the first entry would be <= 100.00 and the search would be completed. If a binary search were permitted, the middle entry, 25, meets the condition (e.g., UNIT-PRICE (25) < 100.00), so the search would be completed after the first test. A binary search, then, would produce a different match than a serial search.

Because we are using a less-than (<) test, going to the midpoint of the table with a SEARCH ALL statement does not really help. It tells us that UNIT-PRICE (25) < 100.00, but UNIT-PRICE (1) could also be < 100.00, as could UNIT-PRICE (2), and so on. Note, then, that a binary search cannot be used for anything but tests for equality (e.g., WHEN search argument = table argument).

The following summarizes the major limitations to a SEARCH ALL.

To use the SEARCH ALL statement, we must indicate which table entry will serve as the key field. That is, we specify the table entry that will be in sequence so that the binary search can be used to compare against that field. We must indicate whether that KEY is ASCENDING or DESCENDING.

The ASCENDING or DESCENDING KEY is specified along with the OCCURS and INDEXED BY clauses of a table entry when a SEARCH ALL is to be used, as shown in the following example.

The identifier used in the ASCENDING KEY clause must be an entry within the table. If entries in the table decrease in value, then DESCENDING KEY would be used. In either case, the ASCENDING or DESCENDING KEY clause must be included and it must appear before the INDEXED BY clause.

In this example, T-CUSTOMER-NUMBER increases in value as we move through the table; hence, T-CUSTOMER-NUMBER is used with an ASCENDING KEY clause.

For best results, the KEY entries or table arguments should be unique; that is, no two table arguments (such as T-CUSTOMER-NUMBER) should have the same value. If it happens, however, that two table arguments defined in an ASCENDING or DESCENDING KEY clause have identical values and one of them is to be accessed, it is difficult to predict which one the computer will use for the look-up with a SEARCH ALL. With a serial SEARCH, the first entry will be the one that is designated as a match.

Differences Between the SEARCH and the SEARCH ALL

This will cause two syntax errors on lines 22 and 24. Find and correct these errors.

The personnel department at a university wishes to print a report identifying each employee's full title, department name, and campus name, not just the codes. The program will use table look-ups to find the appropriate items from separate title, department, and campus tables.

Suppose the university has five campuses identified as

Since the five campuses and their codes are not likely to change, we can store them as an internal table, that is, entered with VALUEs rather than as variable data. Since the campus codes vary consecutively from 1 to 5, we need not store the codes themselves in the internal table, which can be a direct-referenced table:

Department codes have changed over time so that, while there are 25 departments, they range in number from 01–96. The numbers are not consecutive, so we cannot establish this as a direct-referenced table. Moreover, since department names and department numbers change, we need to create a DEPARTMENT-TABLE as an external table:

We will enter data into DEPARTMENT-TABLE using a PERFORM . . . VARYING. We will use a SEARCH to determine department names, since our table is really too small to benefit from a SEARCH ALL, even if the data is in sequence by T-DEPARTMENT-NUMBER.

There are 50 TITLE codes ranging from 001–986. They are not consecutive, so we establish a table that stores the TITLE-NUMBER along with the TITLE-NAME. The table will be accessed with a SEARCH ALL because we will enter the data in

TITLE-CODE sequence and the table is large enough to benefit from a binary search.

In this program, then, we will use three different methods for establishing tables and looking up data from them. The following is the pseudocode for the problem.

Structured Pseudocode

Example: A student currently has a 3.0 GPA with 90 credits. This semester, the student took four courses and received two As, one B, and one C:

Divide 309 by total credits taken (102) = 3.03

The new GPA displayed for this student should thus be 3.03.