JP2002063145A - Parallel processing system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To maintain overall processing efficiency in a high level, regardless of an access state to a common procedure, in a parallel processing system constituted of plural sub-systems. SOLUTION: In a parallel processing system, in which mutually connected plural sub-systems are operated as a single system, the respective sub-systems are provided with various procedures to be prepared, used, updated, or deleted by a program which is being executed for realizing prescribed processing procedures, and a procedure managing part for performing individual state management for the respective procedures. Then, the procedure managing part is provided with a procedure use table for registering the procedure, which is actually used by the program which is being executed and a procedure update table for registering the procedure, which is actually prepared or updated by the program being executed.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a parallel processing system, and more particularly to a parallel processing system capable of creating, using, updating, and deleting a common procedure from each program being executed in parallel.

[0002]

2. Description of the Related Art Conventionally, among processes constituting various programs executed by one system, a routine process which is assumed to be necessary for executing a majority of programs, for example, a basic process is described. Generally, output processing, arithmetic processing, and the like are generally prepared in advance as common procedures in advance. Among these procedures, simultaneous use by multiple programs is permitted.

[0003] While being used by at least one program, any update or deletion by another program is prohibited.

During creation by one program, creation by another program is completely prohibited.

[0005] While updating by one program, use, updating, deletion, etc. by other programs are completely prohibited.

As a technique for managing procedures involving shared / exclusive control, there is a technique for centrally managing the state of all procedures in a system by a single procedure management unit. This conventional technique includes a “procedure in use state” indicating that a running program is using a procedure, and a “procedure updating state” indicating that a running program is creating or updating a procedure. The two types of state attributes are managed by one procedure management unit described above on one management table.

FIG. 8 is a diagram schematically showing an example of the configuration of a conventional parallel processing system. A plurality of subsystems are interconnected, and a specific subsystem (management subsystem) executes various procedures. State attributes are centrally managed. In the figure, for example, when the program 33 operating in the subsystem 30 uses a database search procedure, it passes necessary information such as a database name to be searched and a search key to the procedure execution unit 32 and requests the procedure. . In response, the procedure execution unit 32 inquires of the procedure management unit 14 of the management subsystem 10 about the state attribute of the corresponding database search procedure via the communication line 52. When the procedure management unit 14 notifies that the database search procedure can be used,
The procedure execution unit 32 executes the procedure. Thereafter, the procedure execution unit 32 passes the desired result obtained to the waiting program 33.

[0008]

As described above, when the state of all procedures in the parallel processing system is intensively managed by the procedure management unit 14 of the management subsystem 10, the management is performed from other subsystems. Requests for the creation / use / update / deletion of procedures are concentrated on the application subsystem. For this reason, the processing load is concentrated only on the management subsystem, and the execution processing of the programs in the other subsystems is stalled until the result of the above-described availability determination processing request is notified. However, it is difficult to maintain a high level of processing efficiency for the entire parallel processing system. In addition, since data communication between subsystems occurs in accordance with the above-described availability determination processing request, especially when executing a program that uses a procedure in which high responsiveness is regarded as important, the turnaround time is adversely affected. There was a problem that would. Further, when an operation failure occurs in the management subsystem and the procedure management unit stops functioning, there is a problem that the program operating in another subsystem cannot use the procedure due to the influence.

SUMMARY OF THE INVENTION Accordingly, an object of the present invention is to solve the above-mentioned problems and to prevent the concentration of a load on a specific subsystem and the influence on the turnaround time of a program using a procedure, thereby preventing the parallel processing system from processing. It is an object of the present invention to provide a parallel processing system that maintains the efficiency at a high level and does not spread its influence to the entire parallel processing system even if one subsystem stops functioning.

[0010]

In order to achieve the above object, a parallel processing system according to the present invention is a parallel processing system in which a plurality of interconnected subsystems are operated as one system. Is provided with various procedures that are to be created, used, updated, or deleted by a running program and that implements a predetermined processing procedure, and a procedure management unit that performs a unique state management for each of the procedures. It is. Further, the procedure management unit includes a procedure in-use table for registering a procedure currently used by the program being executed, and a procedure updating table for registering a procedure currently created or updated by the program being executed. It is provided with. As a result, the frequency of requesting permission / inhibition processing for other subsystems regarding the creation / use / update / deletion of procedures and the frequency of stagnation of program execution caused by waiting for the result are reduced, thereby concentrating load on a specific subsystem. And maintain the processing efficiency of the parallel processing system at a high level by preventing the effect on the turnaround time of programs using procedures.
It is possible to prevent the adverse effect caused by the stoppage of the function of one subsystem from spreading to the entire parallel processing system.

[0011]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments of the parallel processing system of the present invention will be described below in detail with reference to the drawings. FIG. 1 is a block diagram showing a main part of a basic configuration of a parallel processing system according to an embodiment of the present invention. The same components as those of the conventional parallel processing system shown in FIG. . That is, 10a, 20a, 30a, 40a are subsystems, 11, 21, 31, 41 are procedures, 1
2, 22, 32, and 42 are procedure execution units;
Reference numerals 3 and 43 denote programs, 14, 24, 34, and 44 denote procedure management units, and 51a, 52a, 53a, and 54a denote communication lines.
Subsystem 10a, 2 provided with 22, 32, 42
0a, 30a, and 40a are connected to communication lines 51a, 52a, and 53, respectively.
a and 54a are connected equally. In FIG. 1, for example, when the program 33 operating in the subsystem 30a uses a database search procedure, the procedure execution unit 32 passes necessary information such as a database name to be searched and a search key to request the procedure. . In response to this, the procedure execution unit 32 inquires of the procedure management unit 34 in the same subsystem 30a about the state attribute of the corresponding database search procedure. Then, when the procedure management unit 34 is notified that the database search procedure can be used, the procedure execution unit 32 causes the procedure to be executed. Thereafter, the procedure execution unit 32
The desired result obtained is passed to the waiting program 33. In the above case, the subsystems 10a, 20a, 30
a, 40a are all unique procedure management units 14, 24,
34, 44, and these procedure management units 14,
24, 34, and 44 independently manage the state attributes of the procedures. That is, the inquiry about the state attribute of the procedure by the procedure execution unit is not performed to the procedure management unit in another subsystem as in the related art described with reference to FIG. 8, but is performed in the same subsystem. Performed for the Procedure Management Department.

FIG. 2 is a block diagram specifically showing the configuration of an embodiment of a parallel processing system according to the present invention. The parallel processing system has a configuration in which a plurality of systems which can be operated independently are interconnected as subsystems. 1 shows a system. In the figure, 101 is a parallel processing system, 102, 103, 10
4 is a communication line, 105 is a data management information storage unit, 20
1, 301, 401 are subsystems, 211, 311,
411 is an operating system, 221, 321,
421 is a database management system (DBMS), 23
1,331,431 are programs, 241,341,4
41 is a data search system, 251, 351, 451 are procedure execution units, 261, 361, 461 are procedure management units, 271, 371, 471 are procedures, 281, 38
Reference numeral 1481 denotes a disk device. The communication lines 102, 103, and 104 in FIG. 2 correspond to the communication lines 51 in FIG.
a, 52a, 53a, and 54a, and subsystems 201, 301, and 401 in FIG.
a, 20a, 30a, and 40a, the program 2 in FIG.
31, 331 and 431 are programs 13 and 2 in FIG.
3, 33, and 43, the procedure execution units 251 and 35 in FIG.
1, 451 are the procedure execution units 12, 22, 32,
42, the procedure management units 261, 361, 461 in FIG.
1 corresponds to the procedure management units 12, 22, 32 and 42 in FIG. 1, and the procedures 271 and 371 and 471 in FIG. 2 correspond to the procedures 11, 21, 31 and 41 in FIG.

In FIG. 2 described above, the parallel processing system 101 includes three subsystems 201, 301, and 401.
Are connected to each other by connecting means 102, 103 and 104. DB operating on the subsystem 201
MS 221, DBMS operating on subsystem 301
321, a DBMS 42 operating on the subsystem 401
By specifying a predetermined connection in advance for each of the above-mentioned DBMSs 221 and 32,
1, 421 can be operated as a virtual parallel database management system operating on the parallel processing system 101. Each of the DBMSs 221, 321, and 421 has a disk device 281, 381, which stores the data itself and a basic procedure for accessing the data.
481 are provided respectively, and this disk device 2
Various information necessary for management of 81, 381, 481 are collectively held as data management information 105. The data management information 105 is information used for integrated management of the virtual parallel database management system obtained by the above-described connection designation, and when the DBMS 221, 321, 421 shares the data management information 105, data access is performed. And procedures for that purpose can be used mutually.

The program 231 operates on the subsystem 201, the program 331 operates on the subsystem 301, and the program 431 operates on the subsystem 401. Both programs use the above-described procedures regardless of the operating subsystem. In addition, data managed by the virtual parallel database management system can be accessed. When a procedure used by a program in this way is first used from a certain program, it is loaded into a memory (not shown) in the DBMS so that it can be used simultaneously by another program. Be managed. The procedure management unit manages the state of a procedure in accordance with a procedure described later so that another program does not delete or change the procedure while another program is using the procedure.

For example, a case in which the program 231 running in the subsystem 201 attempts to access desired data using the procedure 271 will be described. DB
The MS 221 first inquires of the procedure management unit 261 about a state attribute such as whether or not the procedure 271 is usable. If it is available and has already been loaded into the memory, access to the desired data is started using the procedure 271 in the memory as it is. When the disk is usable but not loaded in the memory, the data search system 241 refers to the data management information 105 to obtain a disk storing the corresponding procedure.
The procedure 271 is extracted from 81. Procedure management unit 261
Loads the retrieved procedure 271 into memory,
Thereafter, the procedure execution unit 251 starts accessing desired data using the procedure 271 loaded as described above. If the procedure 271 is in an unusable state, an error message or the like notifying the fact is returned to the requesting program 231.

In the parallel processing system of this embodiment, the DB
Since the MSs 221, 321, and 421 are operating in parallel, the same procedure is used to create, use, update,
Various processing requests for deletion may occur at the same time. For this reason, it is required to ensure the consistency of the procedure so that the same result of accessing data is obtained regardless of which DBMS uses the same procedure. Therefore, the procedure management units 261, 361, and 461 in each of the DBMSs 221, 321, and 421 need to have a function of reliably obtaining the state attribute of each procedure at any time.

FIG. 3 is a block diagram showing a detailed configuration of the procedure management unit shown in the parallel processing system of the present embodiment, where 262, 362, and 462 are a procedure management table,
263, 363, 463 are tables in use of procedures, 26
Reference numeral 4,364,464 denotes a procedure updating table. The same components as those in FIG. 2 are denoted by the same reference numerals, and description thereof will be omitted. In FIG. 3, a procedure management unit manages state attributes of various procedures prepared in the parallel processing system, and determines whether or not various processes such as creation, use, update, and deletion of procedures are possible. Hereinafter, D of the same configuration
Of BMS 221, 321 and 421, mainly DBM
The procedure management unit 261 will be described using S221 as an example.

The procedure management section 261 has a procedure management table 262 for managing the current state attributes of various procedures. The procedure management table 262 is composed of two types of tables: a procedure in-use table 263 for managing a procedure in use, and a procedure updating table 264 for managing a procedure in a creation process or an update process. In the procedure in use table 263, a procedure name unique to the procedure currently used in the DBMS 221 is registered. The procedure updating table 264 includes all DBMS 221 and 3
In steps 21 and 421, a procedure name unique to the procedure being created or updated is registered. That is, in FIG.
The procedure management unit 261 of the MS 221 determines that the procedure name A and the procedure name B in the DBMS 221 are in use from the procedure in use table 263 and the procedure updating table 264 is in use.
From the procedure name D in the entire parallel processing system
It is possible to know that the update process is being performed.

The determination as to whether a procedure can be used is made according to whether the procedure is currently being created or updated. Therefore, when using a procedure, it is necessary to refer to the procedure updating table in the own DBMS to confirm whether a procedure name unique to the procedure is registered. For example, in the case of the DBMS 221 shown in FIG. 3, the procedure name C not registered in the procedure updating table 264 may be usable, but the procedure name D registered in the procedure updating table 264 is not usable. There must be.

The determination of whether or not the procedure can be created and the determination of whether or not the procedure can be updated are performed depending on whether the procedure is currently being used or whether the procedure is currently being created or updated. . Therefore, when a procedure is created or updated, it is checked whether a procedure name unique to the procedure is registered by referring to the procedure in-use table in all DBMSs, and the procedure is prepared. It is necessary to refer to the procedure updating table in the DBMS to check whether a procedure name unique to the procedure is registered. For example, when an update process is to be performed on the procedure with the procedure name C in the DBMS 221 shown in FIG. 3, the procedure in use table 263 in the DBMS 221 and the procedure in progress update table 264 in the DBMS 221 will be described.
And the procedure in use table 363 in the DBMS 321
And the in-procedure table 463 in the DBMS 421 are referred to. As a result, the procedure in-use table 363 is used.
Since it is known that the procedure name C is registered in the procedures 463 and 463, the process of updating the procedure of the procedure name C in the DBMS 221 must be disabled.

The determination as to whether or not a procedure can be deleted is made according to whether or not the procedure is currently being used, or whether or not the procedure is currently being created or updated. Therefore, when deleting a procedure,
It is necessary to refer to the procedure-in-use table and the procedure-updating table in all DBMSs to check whether a procedure name unique to the procedure is registered. For example, in the case of the DBMSs 221, 321 and 421 shown in FIG. 3, the procedure names A, B, C, and D are registered in any of the tables. Must also make the deletion process impossible.

Hereinafter, various types of determination processing of creation / use / update / deletion of procedures, which have been described above, will be described with reference to FIGS.

FIG. 4 is a diagram showing a procedure of a procedure creation / update availability determination process in the parallel processing system of the present embodiment. In the figure, the procedure management table in the own DBMS is locked first so that access from another process is not accepted (step 501). Next, own DB
A search is made as to whether a procedure name to be created or updated is registered in a procedure updating table in the MS (step 502). As a result of the search, if the corresponding procedure name has been registered (step 503 = YES), the procedure name has already been created or updated by another program. The procedure management table is released (step 512), and it is determined that the procedure cannot be created or updated for the corresponding procedure name (step 514). In addition, own DBMS creates procedure,
If the above-described procedure creation / update permission / inhibition determination is in response to a request from the DBMS of another subsystem (step 513 = NO), not the request source of the update processing, the DBMS of the request source subsystem is sent to the DBMS of the request source subsystem. On the other hand, for the corresponding procedure name, a determination that the procedure cannot be created or updated is notified (step 515), and the availability determination processing ends.

As a result of the search in step 502, if the corresponding procedure name is not registered (step 503 = N
O) Further, a search is made as to whether the procedure name is registered in the procedure busy table in the own DBMS (step 504). As a result of this search, if the corresponding procedure name is registered (step 505 = YES), since the procedure is currently in use, the procedure management table in the own DBMS locked first is released (step 512). It is determined that the procedure cannot be created or updated for the corresponding procedure name (step 514). If the own DBMS is not the request source of the procedure creation / update processing and the above-described procedure creation / update availability determination is in response to a request from the DBMS of another subsystem (step 513 = NO), The DBMS of the requesting subsystem is notified of the procedure creation / update refusal decision for the corresponding procedure name (step 515), and the availability determination processing ends.

As a result of the search in step 504, if the corresponding procedure name is not registered (step 505 = N
O) The name of the procedure to be created or updated
Register in the procedure updating table in S (step 50)
6), the procedure creation / update permission is determined for the procedure name. Here, the procedure management table in the own DBMS locked first is released (step 507). If the own DBMS is not the request source of the procedure creation / update processing and the above-described procedure creation / update availability determination is in response to a request from the DBMS of another subsystem (step 508 = NO), D of the requesting subsystem
The BMS is notified of the determination of the procedure creation / update permission for the corresponding procedure name (step 516), and the availability determination processing ends.

If the own DBMS is the request source of the procedure creation / update processing, and the above-described procedure creation / update permission / inhibition determination is started by the own DBMS (step 5).
08 = YES), DBMS of all other subsystems
(Step 509). If all of the notifications returned from the DBMSs of the other subsystems are permitted to create / update the procedure for the corresponding procedure name (step 510 = YES), finally the procedure name to be created or updated is finally determined. The procedure creation / update permission is determined (step 511). On the other hand, even if one of the notifications returned from the DBMSs of the other subsystems cannot be created / updated for the corresponding procedure name (step 510 = NO), the own DBMS
Delete and register the corresponding procedure name in the procedure updating table in (step 517), and create and create a procedure for that procedure name in the DBMS of all other subsystems.
After requesting the update registration cancellation process (step 51
8) Finally, it is determined that the procedure name to be created or updated cannot be created or updated (step 51).
9).

FIG. 5 is a diagram showing the procedure of procedure creation / update registration cancellation processing in the parallel processing system of this embodiment. In the figure, when a procedure creation / update registration cancellation processing request is received from a DBMS of another subsystem, a search is made as to whether or not the procedure name of the corresponding cancellation request is registered in a procedure updating table in the own DBMS ( Step 521). If the corresponding procedure name is registered in the procedure updating table (step 522 = YES), the procedure name is deleted and registered (step 524). With the above processing, it is possible to determine whether or not a procedure can be created / updated for any procedure, and to manage the state of the procedure being created or updated.

FIG. 6 is a diagram showing a procedure of a procedure availability determination process in the parallel processing system of the present embodiment. In the figure, the procedure management table in the own DBMS is locked first so that access from another process is not accepted (step 601). Next, own DBMS
A search is made as to whether or not the procedure name to be used is registered in the procedure in use table in (step 602).
As a result of the search, if the corresponding procedure name is registered in the procedure busy table (step 603 = YES), the procedure management table is released because the procedure is already permitted to be used by another program (step 603). (Step 607), permission to use the corresponding procedure is determined (Step 608). As a result of the search in step 602, if the procedure name to be used is not registered in the procedure busy table (step 603 = NO), then the own DBM
A search is made as to whether the procedure name is registered in the procedure updating table in S (step 605). As a result of this search, if the corresponding procedure name is registered in the procedure updating table (step 605 = YES), the procedure has already been created or updated by another program, so the procedure management table Is released (step 609), and it is determined that the corresponding procedure cannot be used (step 610). As a result of the search in step 605, if the corresponding procedure name is not registered in the procedure updating table (step 605 = NO), the procedure name to be used is registered in the procedure in use table (step 6).
06), the procedure management table is released (step 60).
7), permission to use the corresponding procedure is determined (step 608). With the above-described processing, it is possible to determine whether the procedure is usable or not, and to manage the state of the procedure being used.

FIG. 7 is a diagram showing a procedure of a procedure deletion determination process in the parallel processing system of the present embodiment. When deleting a procedure, exclusive control of the data management information storage section in which information on all procedures is stored,
Since the creation, use, and updating of procedures are not performed at the same time, there is no need to lock the procedure management table. Therefore, first, it is searched whether or not the procedure name to be deleted is registered in the procedure updating table in the own DBMS (step 701). As a result of the search,
If the corresponding procedure name is registered (step 702)
= YES), the procedure name is already subject to creation or update processing by another program, so it is determined that the procedure name cannot be deleted (step 71).
0). If the own DBMS is not the request source of the procedure deletion process and the above-described procedure deletion availability determination is in response to a request from the DBMS of another subsystem (step 709 = NO), System DBMS
Is notified of the determination that the procedure cannot be deleted for the corresponding procedure name (step 711), and the availability determination processing ends.

As a result of the search in step 701, if the corresponding procedure name is not registered (step 702 = N
O) Further, a search is made as to whether the procedure name is registered in the procedure-in-use table in the own DBMS (step 703). As a result of this search, if the corresponding procedure name is registered (step 704 = YES), it is determined that the procedure cannot be deleted because the procedure is currently in use (step 710). In addition, own DB
If the MS is not the request source of the procedure deletion processing and the above-described procedure deletion availability determination is in response to a request from the DBMS of another subsystem (step 709 = N
O), the DBMS of the requesting subsystem is notified of the determination that the corresponding procedure name cannot be deleted (step 711), and the availability determination processing ends.

As a result of the search in step 703, if the corresponding procedure name is not registered (step 704 =
NO), the own DBMS is not the request source of the procedure deletion processing,
The above-mentioned procedure deletion propriety judgment is DB of another subsystem
If it is in response to a request from the MS (step 705)
= NO), and notifies the DBMS of the requesting subsystem of the determination of the procedure deletion permission for the corresponding procedure name (step 712), and terminates the availability determination processing. If the own DBMS is the request source of the procedure deletion processing and the above-described procedure deletion permission / inhibition determination is activated by the own DBMS (step 705 = YES), the same is applied to the DBMSs of all other subsystems. A request is made to determine whether a procedure can be deleted for the procedure name (step 706).
If all of the notifications returned from the DBMSs of the other subsystems are permitted to delete the procedure for the corresponding procedure name (step 707 = YES), finally, the procedure deletion permission is granted for the procedure name to be deleted. A decision is made (step 708). On the other hand, the other subsystem D
If even one of the notifications returned from the BMS has a procedure name that cannot be deleted (step 707 = NO), it is finally determined that the procedure name to be deleted cannot be deleted (step 707). 71
3). With the above processing, it is possible to determine whether or not any procedure can be deleted.

By using the above-described parallel processing system of the present embodiment, the process of determining whether to create, use, update, and delete a procedure is executed in parallel for each subsystem.
Waiting for exclusive control of the procedure management table is distributed to each subsystem. As a result, the frequency of requests for availability judgment processing for other subsystems and the frequency of program execution stagnation due to waiting for the result are reduced, thereby concentrating the load on specific subsystems and affecting the turnaround time of programs using procedures. And the processing efficiency of the parallel processing system can be maintained at a high level.
In particular, when determining whether a procedure can be used, the communication cost for other subsystems can be eliminated. At the same time, it is possible to prevent the adverse effect due to the suspension of the function of one subsystem from spreading to the entire parallel processing system.

[0033]

As described above in detail, according to the parallel processing system of the present invention, the creation, use, update,
In order to reduce the frequency of requests for availability judgment processing for other subsystems for deletion and the frequency of program execution stagnation caused by waiting for the result, concentration of load on specific subsystems and turnaround time of programs using procedures And maintain the processing efficiency of the parallel processing system at a high level, and also prevent the ill effect of the suspension of one subsystem from spreading to the entire parallel processing system.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a main part of a basic configuration of an embodiment of a parallel processing system of the present invention.

FIG. 2 is a block diagram specifically showing a configuration of an embodiment of a parallel processing system of the present invention.

FIG. 3 is a block diagram showing a detailed configuration of a procedure management unit shown in the parallel processing system of the embodiment.

FIG. 4 is a diagram showing a procedure of a procedure creation / update availability determination process in the parallel processing system of the embodiment.

FIG. 5 is a diagram showing a procedure of procedure creation / update registration cancellation processing in the parallel processing system of the embodiment.

FIG. 6 is a diagram showing a procedure of a procedure availability determination process in the parallel processing system of the embodiment.

FIG. 7 is a diagram showing a procedure of a procedure deleteability determination process in the parallel processing system of the embodiment.

FIG. 8 is a diagram schematically showing an example of a configuration of a conventional parallel processing system.

[Explanation of symbols]

 10a, 20a, 30a, 40a Subsystem 11, 21, 31, 41 Procedure 12, 22, 32, 42 Procedure execution unit 13, 23, 33, 43 Program 14, 24, 34, 44 Procedure management unit 51a, 52a, 53a , 54a Communication line 101 Parallel processing system 102, 103, 104 Communication line 105 Data management information storage unit 201, 301, 401 Subsystem 211, 311, 411 Operating system 221, 321, 421 Database management system 231, 331, 431 Program 241 , 341,441 Data search system 251,351,451 Procedure execution unit 261,361,461 Procedure management unit 262,362,462 Procedure management table 263,363,463 Procedure in use table 264 64,464 procedures updated in the table 271,371,471 281,381,481 procedure disk device

Continued on the front page (72) Inventor Masako Kamejo 5030 Totsukacho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture F-term in the Software Development Division, Hitachi, Ltd. F-term (reference) 5B045 BB42 CC07 DD18 GG06 5B082 FA17

Claims (1)

[Claims] 1. A system comprising: a plurality of interconnected subsystems;
In a parallel processing system operated as one system, each of the subsystems is an object to be created, used, updated, or deleted by a running program and implements a predetermined processing procedure, and each of the procedures A parallel processing system comprising: a procedure management unit that performs a unique state management of the program.