JP2002342138A - System and method for controlling on-line transaction - Google Patents

Abstract

PROBLEM TO BE SOLVED: To realize various processings while securing responsiveness of on-line processing. SOLUTION: A system is provided with an on-line responding part 10 for processing a business processing request inputted from terminals 1A and 1B, etc., an on-line transaction according to a message inputted from a message inputting means 8 and also controls to output the processing results as a response to the terminals. An operating means 4 is provided with a derived transaction managing part 12 for managing a derived transaction that processes auxiliary business related to a derived start transaction subjected to a start request as a portion of performance processing of the derived start transaction being an on-line transaction or a prescribed derived transaction. The derived transaction managing part 12 commits the derived start transaction without waiting for the derived transaction to be committed.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] The present invention relates to an online transaction control system and method.

[0002]

2. Description of the Related Art Conventionally, transaction processing has been used as a technique for realizing processing that is accurate, consistent, and can reliably recover from a failure in a large-scale database. A transaction is used as a unit of processing for a database (DB). The transaction makes one or more updates to the DB. At this time, the nature of the transaction guarantees that it either succeeds as a whole or fails as a whole. If all updates to the DB are successful, the transaction reaches a syncpoint. That is, the transaction commits. In a general transaction management system, updates by transactions that have reached a synchronization point are recorded in a log, and updates to this DB are durable against failures (Durabili
ty).

On the other hand, if at least one of the processes included in a transaction does not hold, the transaction is aborted. When a transaction is aborted, all updates made by that transaction are undone. That is, when a transaction is aborted, the transaction management system
Roll back all updates performed up to that point. For this reason, a transaction executes one or more programs and performs multiple updates, and either executes all updates normally and commits, or does not process anything by rollback It is. Since a transaction is the smallest unit of processing for an application, this is called the atomicity of the transaction.

[0004] Since transactions have atomicity,
When updating the DB, the programmer must
nsistency). A programmer of an application program (application, APPL) performs a process of calculating intermediate data that should not be referred to by another transaction and a process of converting or relating the intermediate data to normal data. By encapsulating as one transaction, it is possible to maintain the consistency of the DB and the consistency of the data. Since the commit is performed on condition that the data is converted to normal data, the data is stored in the DB in an intermediate data state, and the intermediate data is not referred to by other transactions. on the other hand,
If the data is not converted to normal data, the transaction is aborted, and the calculation and update of intermediate data are also canceled by rollback.

[0005] For example, account transfer (fund transfer) is a process comprising subtraction of a numerical value from one account A (withdrawal) and addition of a numerical value to another account B (payment). The intermediate data is, for example, the subtraction of a numerical value from a certain account A. By enclosing the subtraction process and the addition process of this numerical value as one transaction, it is guaranteed that the account transfer is either successful or failed. In this case, only the subtraction or the addition of the numerical values is not performed. That is, if the dispensing and the deposit are processed as one transaction, only the dispensing is performed and the situation that the deposit is not made does not occur.

In addition, by keeping the context between transactions clear and preventing other transactions from referring to the data being processed, a plurality of transactions can be processed in parallel.
As described above, in order to perform parallel processing and distributed processing, data handled between transactions is isolated from each other (Isolatio
n) Must do. A lock is effective for isolating (separating) this data. If the transaction accesses the data with the possibility of updating, the transaction locks the data item, makes the necessary updates, and then releases the lock. When a transaction attempts to access locked data, it waits until the lock is released by another transaction. As a result, the seriality of the transaction is secured, the transaction is isolated, and the transaction can be processed in parallel and distributed.

By using a lock, parallel processing can be performed while maintaining the seriality of a transaction. However, when the granularity of the lock (contention unit) is large, the frequency of waiting for the release of the lock increases. , And the waiting time tends to be longer. Also, in the example using locks,
Depending on the reading order of DB of each transaction,
Deadlock occurs. For example, when there are DBx and DBy, it is assumed that the transaction T1 reads DBx and then tries to read DBy, and this DBy is locked by the transaction T2. In this case, the transaction T1 waits until the lock on DBy is released with the lock on DBx. If the transaction T2 tries to read DBx after reading DBy, a deadlock occurs. Thus, the transaction T1 waits for the completion of the processing of T2,
Deadlock occurs when the transaction T2 waits for the completion of the processing of T1. Deadlock can be avoided by making the reading order of the DB the same in all transactions.

[0008] Now, transactions have ACID properties of atomicity, consistency, isolation and durability. By using the transaction processing based on this characteristic, a strict and robust system can be constructed. Therefore, the transaction processing system is used in a wide range of fields, such as an accounting system in a financial institution, a management system for operation and ticketing of aircraft, a manufacturing system management system in various industries, and a communication control system. I have. Such a system performs online processing and batch processing. For example, in a conventional accounting system, during the daytime, business processing requests from terminals such as ATMs and branch office terminals are processed as online transactions, and bank transfers and the like are processed in batches from the night when online was stopped until early in the morning. I was However, today, there is a demand for minimizing batch processing and performing continuous operation for 24 hours.

The tasks that can be executed by a transaction having ACID characteristics have been limited to relatively simple processing.
This is because if one transaction attempts to execute a complicated process, many locks are generated and the responsiveness of the online process is deteriorated. In addition, there is an amount of data that cannot be processed by one transaction. In conventional transaction processing, it is generally programmed to receive an online business processing request, immediately execute the request, and immediately commit.

If the locking for managing the seriality between transactions is not performed, the responsiveness is improved.
On the other hand, the DB consistency cannot be strictly managed. Although good design involves wisdom-based compromises, various attempts have been made in recent years to achieve both on-line responsiveness and more complex processing. This conflict is related to how to balance transaction parallelism with strict atomicity. If the parallel processing can function effectively, the responsiveness of the online transaction can be ensured well.

Some approaches to this problem are described in, for example, "Introduction to Transaction Processing Systems," by Philip A. Bernstein and Eric Newcomer, published by Nikkei BP (Principles of Transaction Processing,
Philip Bernstein, Eric Newcomer) and "CORB
A, Enterprise Transactions by Encina, "Ian Gorton, Pearson Education (Enterprise Transaction Processing Systems:
Putting the CORBA OTS, Encina ++ and OrbixOTM to W
ork, Ian Gorton).

As a technique that goes beyond simple transaction management based on ACID characteristics, save poi
nt). This is to save the state of all resources during the execution of a transaction. As a result, when a failure occurs, it is possible to restart the transaction from the middle. Persistent savepoints provide durability by eliminating the atomicity of transactions. As a result, a transaction that requires a long time for processing can be restarted from the middle instead of being aborted. A method using save points is disclosed in, for example, Japanese Patent Application Laid-Open No. 2000-10810. In general, even if a save point is used, data being handled by a transaction at the time of the save point is isolated from other transactions, so that lock contention cannot be reduced.

As a method of relating a plurality of transactions, there are a nested transaction (for example, Encina TP monitor of Transarc) and a chained transaction (for example, MQ series of IBM). Nested transactions give a transaction a parent-child relationship,
Allows another transaction to be called during transaction execution. The transaction started first becomes the parent transaction. The transaction called by this parent transaction becomes a sub-transaction. The sub-transaction has an ACID property for the parent transaction, but is not durable for other transactions. The sub-transaction commits eventually when the parent transaction commits. A subtransaction is atomic with respect to other subtransactions with the same parent,
It is isolated from other transactions and sub-transactions having the same parent.

Using this nested transaction model, a parent transaction called a transfer process can start a sub-transaction called a pay-out process and a sub-transaction called a deposit process. When the sub-transaction of the payment processing is committed, the result can be referred to from the payment processing. On the other hand, by committing the sub-transaction that is the payment processing, the administrator of the lock moves to the parent transaction. Therefore, until the parent transaction commits, transactions other than the sub-transaction cannot refer to the result of the payment processing. Therefore, if the payment processing is aborted for any reason, the parent transaction is aborted, and the payment processing can also be rolled back. This nested transaction model is said to be compatible with object-oriented programming.

When the nested transaction model is used, a complex data structure and processing can be defined in a class hierarchy, and a system can be developed by defining the message and behavior of an object. Locks can grow because they are not durable until the transaction commits. That is, in the nested transaction model, a large transaction including a sub-transaction is executed, and the global transaction has ACID characteristics with respect to other transactions. Thus, nested transactions are useful in increasing program reusability, but do not reduce lock contention on a parent transaction basis.

The term "chain" is used in various contexts. In Japanese Patent Application Laid-Open No. H10-69418, a chained transaction is described in paragraph 0060 and subsequent paragraphs. According to this, in the chained transaction model, a member transaction T3 activates another member transaction T4. The activation process of the member transaction T4 is wrapped in the atomicity of the activation member transaction T3. Therefore, another member transaction T4 is started only when the starting member transaction T3 commits. The abort of the activated member transaction T4 does not extend to the transaction T3.

The handling of the restart by the chained transaction method is executed by re-establishing the commit state of the recently committed member transaction. In this chained transaction model, the transaction T3 can be committed earlier. That is, the transaction T3 can commit without waiting for the commit of the transaction T4. Therefore, the lock of the transaction T3 is released before the commit of the transaction T4. Therefore, the responsiveness of the transaction T3 can be improved. On the other hand, in the chained transaction model, global transactions do not have ACID characteristics. Therefore, atomicity is not strict in the chained transaction model.

As a technique for improving the processing speed including securing online responsiveness, a fast path (Fast Path,
FP) method. For example, Japanese Patent Application Laid-Open No. HEI 6-195250 discloses a system in which a high-speed path system is mounted on an IMS of IBM, in order to continuously maintain an active database copy in a backup system for recovery from a failure. Is disclosed. FP is used to improve responsiveness especially in online systems at financial institutions, and for the purpose of improving processing speed,
There are various restrictions on resources. For example, F
P does not use a look-aside database buffer, which is a temporary storage area generally used in an IMS database, and also limits the number of database buffers that can be used in one transaction. Furthermore, in IMS, messages that are business processing requests are stored in a message queue, whereas in FP, this queuing system is bypassed and transactions are made from terminals via simpler queues (which are not recoverable). Can be sent to the program. These enhance online responsiveness.

[0019]

In recent online systems, continuous operation is required for 24 hours and 365 days. Therefore, it is desired to perform batch processing in parallel with online processing. That is, it is required to reconstruct a conventional batch process as an online process. In general, batch processing is executed on the premise of the static state of the DB, so that the batch processing itself cannot be executed while the contents of the DB are being changed by an online response. If a process that assumes a static state is to be executed in a dynamic state, a situation similar to a chain abort may occur.

A cascading abort is an adverse effect when transaction consistency and seriality are lost. For example, it is assumed that after the value of the DB is updated from x to y, a plurality of transactions are executed based on the updated value y. Then, from x to y
Suppose the update to was canceled. Alternatively, it is assumed that y has been updated to z. Then, all transactions established on the premise of y must be canceled and re-executed. When a transaction is aborted, the next transaction is aborted. Such a situation must be avoided. However, if batch processing is to be performed during the day in parallel with online processing, a situation similar to such a chained abort may occur. For example, if the account transfer performed based on the final balance of the previous day is processed during the day of the previous day, the final balance of the previous day may change. If there is a change in the account balance after the account transfer processing, it may seem at first glance that the situation is similar to a situation where a chained abort occurs.

As described above, when trying to execute batch processing as online processing during the day, it is necessary to perform various processing in a state where the DB is not stationary, and it is necessary to strictly manage consistency and seriality. Occurs. This problem is a common problem in the development of trying to execute batch processing as daytime online processing in various application fields as well as in account transfer.

In the chained transaction model, a process for responding to a terminal can be committed, and then another transaction can be executed. Therefore, both online responsiveness and realization of a complicated process can be achieved. However, in terms of bringing the batch processing online, it is necessary to take a countermeasure when the processing requests are concentrated and a countermeasure against the above-mentioned situation that can be a chained abort. In addition, the chained transaction model is not standardized and cannot be used in all transaction management systems.

In the above-mentioned Japanese Patent Application Laid-Open No. 10-69418,
It discloses that the global transaction is provided with an ACID characteristic while using the chained transaction model in a hierarchical manner, but does not disclose the relationship between the abort of the member transaction and the atomicity of the global transaction.

In order to ensure online responsiveness, it is desirable to employ a high-speed path (FP) or the like. However, F
If P is used, the number of buffers in the database is limited, and there is a certain limit such as the inability to recover from the queue. For example, the processing amount that can be processed by one transaction having ACID characteristics is limited. . For example, as with the nested transaction, as for a linked transaction that links a plurality of processes in one transaction, when the FP is adopted, there is a limit to the number of linked operations that can be executed in one transaction.

[0025]

SUMMARY OF THE INVENTION It is an object of the present invention to provide an online transaction control system and method which can solve the inconveniences of the prior art and, in particular, can realize various processes while ensuring the responsiveness of the online process. And its purpose.

[0026]

SUMMARY OF THE INVENTION The present invention uses a derived transaction model. Derived transactions are:
Perform tasks associated with the main transaction. By preparing a transaction model for processing the incidental tasks, the application programmer can execute the task processing (main task).
A program can be constructed as a transaction having ordinary ACID characteristics excluding ancillary business unrelated to the online response, and an ancillary business accompanying the main business can be constructed as a derived transaction. Then, the transaction for executing the business process returns a response to the terminal without waiting for the completion of the processing of the derived transaction after requesting a start request of the derived transaction during the execution.

According to the present invention, a receiving means for receiving a business processing request input from a terminal or the like via a network, an arithmetic means for processing the business processing request received by the receiving means, and a business processing by the arithmetic means And a file for recording a processing result of the request. And the calculating means is:
An online response unit that controls a business process request input from the terminal or the like as an online transaction and outputs the processing result as a response to the terminal; and a derivative activation transaction that is the online transaction or a predetermined derivative transaction. And a derived transaction management unit that manages a derived transaction that processes a related business related to a business process by the derived start transaction that is requested to be started as a part of the execution process of the derived transaction. Furthermore, the derived transaction management unit is configured to have a derived activation management function of committing the derived activation transaction without waiting for the derivation transaction to commit. This aims to solve the above-mentioned problem.

The online response section processes the business processing request as an online transaction and outputs the response to the terminal. The online transaction may be the processing of a business processing request generated by operating a terminal used by a customer, or may be a business processing request corresponding to processing that has been performed internally in conventional batch processing. “Outputting the processing result as a response to the terminal” means that when the output to the terminal (or pseudo terminal) is requested as a part of the execution of the online transaction, the response is output to the terminal. Therefore, not all transactions return a response to the terminal.

The derived transaction processes ancillary business related to business processing by an online transaction. Ancillary business is a business that does not require an online response to an online transaction, and is generally a business that accompanies the main business. is there. A derived transaction is activated by a program during the execution of an online transaction. Further, the derived transaction may start another derived transaction. The derived activation management function commits the derived activation transaction without waiting for the commit of the derived transaction. That is, the business process is completed without waiting for the completion of the associated business. Even if the derived transaction aborts, the derived start transaction is not canceled.

As described above, in the present invention, the chained transaction model is applied to the distinction between the main business process and the auxiliary business process. As a result, the processing required for the online response is processed by the online transaction, and the accompanying processing not required for the online response is processed as the derived transaction, so that the online transaction can be committed early. That is, by processing only ancillary tasks as derived transactions afterwards while securing online responsiveness, complex processing can be performed as a whole.

Also, in some situations, a derived transaction can be a derived activation transaction. In this case, the subsidiary business is executed in a repetition of the derived transaction without being processed in one transaction. In the example in which the derived transaction is repeatedly started and executed, each derived transaction commits individually, so that the processing amount processed by one transaction is relatively small, and the lock is released once by the commit. For this reason, there is no high load on the system while performing complicated incidental tasks.

The process consisting of the derived start transaction and the derived transaction (derived use transaction) does not satisfy the ACID characteristic. That is, there may be situations where the derived activation transaction has committed but the derived transaction has been aborted. On the other hand, if the derived start transaction does not commit, the derived transaction is not executed. In other words, although the business process itself that requires ancillary business has not been established,
We do not establish only the incidental work. When the business process is established and the associated business is not established, the derived transaction for processing the associated business is restarted. In order to realize these mechanisms, in a preferred embodiment, the derived transaction management unit stores the derived activation information related to the activation request of the derived transaction in the file and then commits the derived activation transaction. A control function; a serialization management function for controlling not starting or committing the derived transaction when the derived transaction is aborted; and a derivation when the derived transaction aborts after the derived transaction is committed. A derived restart control function for restarting the derived transaction based on the start information.

When there is a derived transaction activation request, the derived activation information storage control function uses the derived activation transaction making the activation request and data passed from the derived activation transaction to the derived transaction as derived activation information. Store it in a file. This derived activation information is not used in normal processing, but is used when the derived transaction aborts and only the derived transaction is restarted. That is, the derived restart control function restarts the derived transaction based on the derived start information when the derived transaction aborts after the derived started transaction commits.

The present invention having the function of controlling the storage of the derived activation information has a function of controlling the restart of the derived transaction, in addition to the restart processing when the transaction is aborted due to the occurrence of a general failure. This is because the derived transaction does not have an ACID characteristic when the derived transaction and the derived transaction are considered as one, so that the derived transaction is more strictly handled when aborting. The derived transaction is activated based on the derived activation information. Therefore, if the derived activation information is stored in a file in a durable state, the derived transaction can be restarted completely in the same state as at the time of initial activation. In addition, compared to the queuing model and log-based restart, it is easier to find the target of the restart process, and even if an abort is caused by a bug in the application of a derived transaction, the restart after the application program is modified Handling can be flexibly determined, such as execution is possible. In addition, since the derived transaction processes the associated business, it may be assumed that the restart is unnecessary depending on the situation. Even when the operator determines whether or not such a restart is necessary, by including various information related to the start of the derived transaction in the derived start information, the operator's terminal can be used when determining whether or not the restart is necessary. Processing such as display can be performed.

In the derived transaction model, online responsiveness is ensured by permitting the occurrence of a situation in which the derived activation transaction commits and the derived transaction is aborted. Therefore, the ability to strictly manage the restart of the derived transaction contributes to the stability of the system operation.

[0036] In the present invention, the calculation means may include a total amount control unit for restricting activation of the derived transaction in accordance with the total amount of transactions whose execution is managed by the online response unit and the derived transaction management unit. good. This prevents an online transaction requiring an online response from being delayed due to the stagnation of a derived transaction. "Restriction on activation of derived transaction" means, for example, that among business processing requests that are derived activation transactions, the input of an internal business processing request is waited for,
This includes processing to stop the activation of the derived transaction while executing the business processing request, and further to make the execution of the derived activation transaction an error. The derived transaction whose activation has been canceled can be restarted at a stage where the load on the system is reduced, such as a reduction in transaction stagnation.

In the derived transaction model, a subsidiary transaction that does not make an immediate online response is executed as a derived transaction.
Compared to online transactions, the time that execution can wait is longer. Therefore, when the total amount of executed transactions is large, the total amount control unit performs a process of restricting the activation of the derived transaction. This gives priority to the processing of an online transaction that requires an online response. In the embodiment having the total amount control unit, by limiting the invocation of the derived transaction for processing the ancillary business, online responsiveness can be ensured while maximizing the capacity of the system and executing complicated processing. it can. As a result, the daytime processing of the batch processing can be stably and strictly realized.

[0038]

Embodiments of the present invention will be described below with reference to the drawings. The present invention has three embodiments. The first embodiment discloses the structure and usage of a derived transaction model. The second embodiment discloses a technique for realizing the characteristics of a derived transaction using a lock on a DB. In the third embodiment, a method for avoiding an exceptional deadlock in the second embodiment will be disclosed.

[0039]

FIG. 1 is a block diagram showing the configuration of an online transaction control system according to a first embodiment. In the example illustrated in FIG. 1, the online transaction control system includes a receiving unit 2 that receives a business processing request input from a terminal 1A or 1B via a network 3, and a business processing request received by the receiving unit 2. It comprises an arithmetic means 4 for processing and a file 6 for recording the processing result of the business processing request by the arithmetic means 4. The terminal 1A is, for example, a terminal used by a customer, such as an ATM or a personal computer. The terminal 1B is a terminal used by an internal operator, and is called, for example, a branch office terminal. The console terminal 2A is a terminal for inputting a command for instructing operation management of the system or input of a business process request. The business process request is input from the terminal 1A, 1B or 2A. In the example shown in FIG. 1, the business process request received by the receiving unit 2 is transmitted to the arithmetic unit 4 via the message input unit 8.
Is input to The message input means 8 may include a queue for temporarily storing a message as a business process request. In the example shown in FIG. 1, the message input by the message input unit 8 is in a format that can be interpreted by the arithmetic unit 4 even if the business process request adopts various formats according to the communication standard and the like. Message input means 8
, A plurality of messages may be blocked and a batch input may be performed.

The arithmetic means 4 is provided with the terminals 1A, 1B
An online response unit 10 is provided to process a business process request input from the terminal as an online transaction in accordance with a message input from the message input unit 8 and to output the processing result as a response to the terminal. Further, the calculation means 4 is a derived transaction management unit that manages a derived transaction that is requested to be started as a part of the execution process of an online transaction or a derived startup transaction that is a predetermined derived transaction and that processes an associated task related to the derived startup transaction. 12 are provided. Calculation means 4
Has a transaction execution unit 16 for executing an online transaction, a derived transaction, or a batch process. Transaction execution unit 16
Performs operations on various DBs stored in the file 6.

Deposit of cash input from the terminal 1A, registration of information related to financing input from the terminal 1B, etc.
Processed as an online transaction. Here, the batch processing executed in parallel with the execution of the online transaction is also called an online transaction. For example, an account transfer process during online operation is an online transaction. A transaction that is not an online transaction is, for example, a nightly batch.

The derived transaction is requested not to be a business process request from the terminal but to be started by a program of another transaction. A transaction requesting a start request for a derived transaction in accordance with the execution of the program is referred to as a derived start transaction herein. Then, the derived transaction (T1) activated by the derived activation transaction may activate another derived transaction (T2). In this case, the derived transaction (T1) is a derived activation transaction.

The online transaction performs processing necessary for an online response, determines the necessity of ancillary processing, and requests an activation request for a derived transaction when the ancillary processing is required. When there is a request to start a derived transaction, the derived start managing function 20 of the derived transaction management unit 12 commits the derived started transaction without waiting for the commit of the derived transaction. Derived launch management function,
In order to commit the derived start transaction without waiting for the completion of the derived transaction, the online transaction is completed early, prompting the release of the lock, and maintaining good online responsiveness. That is, the terminals 1A and 1B that have requested the business processing request can obtain the processing result of the online transaction without waiting for the completion of the associated processing. Since the derived activation management function 20 commits the derived activation transaction without waiting for the commit of the derived transaction, the derived transaction may be aborted after the commit of the derived activation transaction. In the present embodiment, by providing a function for controlling the restart when the derived transaction is aborted, the actual atomicity and the special seriality of the process having the derived start transaction and the derived transaction are ensured. are doing.

Referring to FIG. 1, the derived transaction management unit 12 stores a derived activation information associated with the activation request of the derived transaction in the file, and then commits the derived activation transaction, and then controls the derived activation information storage control function 22. A serialization management function 24 for controlling not to start or commit the derived transaction when the derived start transaction is aborted.
And a derived restart control function 25 for restarting the derived transaction based on the derived start information when the derived transaction aborts after the derived started transaction commits.

The derived start information includes data passed from the derived start transaction, the type of ancillary work, the storage location of the derived start information in a file, and the start time (entry time) of the derived transaction. This is information necessary for management. A derived message for executing the derived transaction is created based on the derived activation information or each data as a source thereof. The properties and execution of the derived transaction are managed by the derived transaction management unit 12. The derived activation information stored in the file 6 is used for restarting when the derived transaction is aborted.

The derivation start information storage control function 22 is used to reliably and easily restart the derivation transaction.
Stores derived activation information. The seriality management function 24 prevents a situation in which a derived transaction is started or executed when the derived start transaction is aborted. Since the derived transaction is started or executed when the derived start transaction commits, when the derived transaction is aborted, the derived start transaction has already committed. Therefore, only the derived transaction need be restarted without having to restart the derived start transaction. The derivation restart control function 25 restarts the derivation transaction based on the derivation start information stored in the file 6 when receiving a derivation request for restarting the derivation transaction.

As described above, in the present embodiment, the derived activation transaction and the derived transaction are defined as follows. (1) Individual ACID The derived activation transaction and the derived transaction each satisfy the ACID characteristics. A derived transaction can also start another derived transaction as a derived start transaction. (2) Extended seriality The derived transaction commits only when the derived activation transaction commits. The operation of the derived transaction may start when the derived activation transaction commits. (3) Extended atomicity Aborting a derived transaction does not extend to a derived activation transaction. According to (2) and (3), the property of one-way atomicity becomes apparent. One of the conditions for committing the derived transaction is to commit the derived start transaction. On the other hand, the derived start transaction commits regardless of the fate of the derived transaction. Considering a derived use transaction that combines a derived start transaction and a derived transaction, the derived use transaction is not atomic. (3) The advantage of the extended atomicity is that the derived start transaction is committed early, its lock is released, and the responsiveness of the derived start transaction is improved. Because the derived transaction can be executed in near real time, the process that was conventionally performed in batch processing is slightly delayed as a derived transaction to online response,
But at about the same time, they can be run in parallel with other online transactions. (4) Extended isolation The data handled by the derived activation transaction and the result can be passed to the derived transaction. This depends on how the derived transaction is started. The derived transaction does not wait for the result of the derived transaction. Data passed from a derived transaction to a derived transaction is isolated from other transactions. On the other hand, the commit of the derived start transaction makes the resource accessible from other transactions including the derived transaction. (5) Extended Consistency (Optional) Since the derived activation transaction satisfies the ACID characteristics, the transaction brings the contents of the database into a consistent state for the application. However, in the derived transaction model, this consistency is system-level consistency and need not be business-level consistency. In other words, in the derived transaction model, consistency at the business level may be ensured by executing a derived transaction for processing the associated business. An example of the use of derived transactions is data that records intermediate data at the business level in a durable state so that consistency lost at the business level is strictly consistent at the system level. Structures can be used. For example, if there is data necessary for online response to the terminal and data that should be organized or optimized after a few seconds or by the next day as a result of processing the online transaction, the derivative activation transaction is The data required for online response is updated, and the data required by the next day is stored durably as intermediate data that lacks consistency at the business level. Then, the derived activation transaction commits at the stage of storing the intermediate data. Data that needs to be organized by the next day can be processed after completion of the online response using the derived transaction.

FIG. 2 is an explanatory diagram for explaining the nature of the derived transaction. FIG. 2A is a diagram showing an example in which a derived transaction activation request is issued from the derived activation transaction. As shown in FIG. 2A, when there is a business process request, the online transaction is executed as a derived activation transaction S1, and the derived transaction is requested to be derived and then committed C1. Thereafter, the derived transaction S2 is executed, and the commit C2 is performed.

A method of managing a derived transaction using the online transaction control system includes a step of executing a business processing request input from a terminal or the like as an online transaction (S1A, online response unit 10), and a step of executing this online transaction execution processing. A step (S1B, derived activation information storage control function 22) of storing, in a file 6, derived activation information necessary for activating the derived transaction when the activation of the derived transaction is requested. Furthermore, the derived transaction management method includes a step of committing the online transaction that has started the derived transaction without waiting for the execution start or commit of the derived transaction (C1, the derived activation management function 20), and a method of performing the process when the online transaction is aborted. (S2A, serialization management function 24) for controlling not to start or commit the derived transaction.

FIG. 2B is a diagram showing a case where the derived activation transaction is a linked transaction. 1
A mechanism for executing a plurality of tasks in one transaction is referred to herein as interlocking. Since the linked startup task S3A and the linked passive task S3B are executed as one transaction, the atomicity of whether or not both are successful is guaranteed. Taking the accounting system as an example, the linked startup business S3A
Is, for example, a withdrawal of an electricity fee. In this case, the interlocked passive business S3B is a withdrawal from an ordinary deposit. Since the linked transaction is executed as one transaction, the payment of the electricity bill is successful, but there is no inconsistent state that the amount is not withdrawn from the savings account. In the example shown in FIG. 2B, the linked start operation S3A
Requests the withdrawal of the ordinary deposit from the interlocking passive business S3B. When the withdrawal is performed in the interlocking passive business S3B, the process returns to the interlocking activation business S3A. Upon receiving the interlock return, the interlock start operation S3A
Commit after doing other processing. Then, when there is a change in the account balance of the ordinary deposit, if there is an accompanying task that does not require an immediate online response, the linked passive task S3B activates the derived transaction S4.

FIG. 2C is a diagram showing an example in which a derived transaction requests activation as a derived transaction. In this embodiment, the derived transaction itself can be a derived activation transaction. The derived transaction can also start the derived start transaction as a derived transaction. In the example shown in FIG. 2, when the derived transaction is aborted after the commit of the derived activation transaction, the derived transaction is restarted based on the derived activation information. By combining and using the respective modes shown in FIG. 2, business processes having various characteristics can be realized.

The configuration shown in FIG. 1 and the mechanism shown in FIG.
This can be realized by executing a predetermined program by the arithmetic means. The calculation means 4 includes a CPU that performs various calculations according to a predetermined program (command). C
The PU schedules (routes) an online transaction according to a business process request (message), and controls online transactions such as a command for returning the execution result to the terminals 1A and 1B and a command for managing the nature of the derived transaction. By executing the application program, the online response unit 10 shown in FIG.
Also, it operates as the derived transaction management unit 12.
These programs are stored in a program storage unit provided with the CPU. In addition, an operating system that performs basic input / output, and a group of programs that perform management of a database and restoration by logs, management of general transactions, locking of a DB, and the like are also stored in the program storage unit. .

Such an online transaction control program includes a command for operating a CPU (arithmetic means). For example, the online transaction control program includes a command to execute a business process request input from a terminal or the like as an online transaction,
When the activation of a derived transaction is requested as a part of the execution processing of the online transaction, a command to store the derived activation information necessary for the activation of the derived transaction in the file and wait for the execution start or commit of the derived transaction There is provided a command to commit the online transaction that has started the derived transaction without performing the command, and a command to start or to not commit the derived transaction when the online transaction is aborted. The arithmetic unit 4 operates as a derivative activation management function 20 and a derivative activation information storage control function 22 by executing these commands. Further, the online transaction control program includes a command to restart the derived transaction based on the derived activation information when the derived transaction is aborted after the derived activation transaction commits. In addition, the CPU operates as the arithmetic unit 4 having various functions by providing the online transaction control system, each unit to be realized by the online system, each unit or each function, and instructions according to each step of the flowchart. .

The online transaction control program is stored in a recording medium 1 such as a magnetic tape (MT) or a disk.
1A, transported, and read by the medium reading unit 11. The online transaction control program stored in the recording medium is read by the medium reading unit 11 and then stored in the program storage unit. Also, a program can be provided from another host device to the program storage unit via a communication line.

About the program, CPU (arithmetic means)
Is referred to as a "command to operate".
The command includes one or both of a command for operating the PU and a command for operating the CPU depending on another program such as an operating system stored in the program storage unit in advance. Here, “operating system” is interpreted in a broad sense. Includes transaction manager, database manager, etc. Therefore, I
MS, FP, SAIL, etc. are also considered OS for convenience.

The derivative activation information storage control command may be only a command for transferring the storage destination of the derivative activation information to the operating system. As described above, the recording medium 11A for storing the online transaction control program, which is used for transporting the program to the user, includes, for example, a "command to transfer the storage destination of the derived activation information to the operating system". Only stored,
Actual storage of data and the like may be performed by the operating system. This is determined by the relationship with the operating system of the computer to be operated. In this regard, program (command) via communication line
The same applies to the case of providing

The description of the program, the system or method, the transport medium, etc. is the same in the embodiments described later. In particular, functions, processes,
The point that each command corresponds is the same in each embodiment. For example, in order to implement the derived activation information storage control function, the online transaction control program includes a derived activation information storage control command for implementing the function.

Next, how to use the derived transaction in the online system will be described. FIG. 3A is an explanatory diagram for explaining a terminal response and the like according to the usage of the derived transaction. The terminal 1 (1 </ b> A or 1 </ b> B) inputs a task processing request to the arithmetic unit 4. In the derived transaction model, the main business is the online transaction S1
1 and the associated business is derived transaction S1
Run as 2. That is, the transaction execution unit 16 executes the associated business related to the business process request as the derived transaction. In the example shown in FIG. 3A, the main task is a derivative start transaction (derivative start T) because the subsidiary task is derived and started. Commit the derived startup transaction and the derived transaction separately. The derived start transaction returns a response to the terminal 1 without waiting for the completion of the associated task.

Taking the accounting system as an example, FIG.
Is a name identification process when an account is newly established. In the case where the account system adopts an account system in units of customers, and when a customer who has an account in the branch 201 also newly establishes an account in the branch 202, a merging process for associating the two accounts is performed. The name identification process is performed, for example, when the same name and the same address are used. Therefore, when a new account is opened, it is necessary to search for an account having the same name as the account name from all accounts at all business offices. The opening of the account itself can be completed without performing the name identification process. For this reason, the account opening process is constructed as an online transaction, and the name identification process is constructed as a task associated with the account opening process. As a result, it is possible to perform the merging process without using the batch process while committing the account opening early.

As another use method shown in FIG. 3A, there is a process of duplicating data according to the use. For example, it is assumed that information on financing is stored in the financing master DB in units of borrower numbers, which are serial numbers of all business offices. In the loan master DB, a reservation segment is created in units of a borrower number by a reservation operation specifying a scheduled loan execution date. If the approval of the headquarters is required to execute the loan, a request for approval is created by the request for approval request creation operation and sent to the headquarters. At the headquarters, an approval or denial operation is performed depending on the content of the loan. At the sales office, on the scheduled execution date of the loan, the loan execution operation is performed together with the case approved by the headquarters, and the loan is paid to the account of the borrower identified by the borrower number. At the sales office, it is necessary to inquire the list of projects to be executed on that day in order to perform the operation of financing execution. Therefore, all lenders must be searched, and in this case, processing time in minutes is required. Therefore, by making a separate approval DB different from the loan master DB for inquiries at the branch office, the reservation segments and the like are duplicated. The decision-making DB has a data structure in which reserved segments are stored in order of scheduled execution dates for each branch number of each branch, so that inquiries by store can be performed in a short time. Registration of a reserved segment in the decision making DB is completed in a short time because there are many segments below the store number and the location to be added depends on the scheduled execution date and is not always the final position. Do not mean. On the other hand, we want to finish the reservation operation, which is the main task, in a short time. For this reason, in the present embodiment, the main operation is a reservation operation and the like.
Then, the registration of the reservation segment in the Decision DB is executed as a subsidiary business in a derived transaction. In the example shown in FIG. 3A, a reservation operation for registering a reservation segment in the loan master DB is executed in step S11, and the associated business is changed to a derivative transaction S12.
Start as The derivative activation transaction S11 that executes the reservation operation commits without waiting for the commit of the associated task S12. Thereby, the reservation operation is completed in a short time. In the incidental task S12, registration processing of the reservation segment in the approval request DB is performed slightly after the reservation operation.

FIG. 3B is an explanatory diagram showing an example of executing the cancellation / recut main in the future-end completion processing system as an incidental task. The future completion processing system is a method for processing settlements such as fund transfers that were conventionally performed in batch processing as online transactions during the day,
The details have been separately filed by the same applicant. Here, the outline will be described. Account processing such as fund transfer,
Have an account date. In the future-end completion processing system, account processing is performed on account days on and after the next business day (future date) based on the current balance, and the balance on that account day is calculated.
For this reason, the future-end completion processing system holds the balance on the calculation day and the balance on the future account date. For example, there is a balance of 30,000 on the 10th, an electricity charge withdrawal of 10,000 on the 10th is executed on the 10th, and the balance on the 10th is kept at 30,000 for 11th ( The balance of the future date) is 20,000. If there is an account processing request (business processing request) such as cash withdrawal on the 10th, the balance on the 10th is 30,000. On the other hand, if the date is changed, the balance on the 11th is referred to. Since the balance on the eleventh day has already been deducted from the electricity charge, there is no need to perform any processing when the date is changed. For this reason, the future date completion processing is completed when the account transfer and the like are processed on the future date.

Now, it is assumed that the account balance has been changed on the 10th after the payment of the electricity charge has been processed on the previous date. For example, 2
Suppose you have 5,000 withdrawals. The balance on the 10th is 30,
Since it is 000, withdrawal is possible, and after withdrawal, it becomes 5,000. For the balance on the 11th, from 20,000 to 25,
Subtracting 000 results in minus 5,000. Unless the balance is negative, unless it is based on a contract such as automatic financing,
Since it is impossible for business, the balance on the 11th must be deducted and the withdrawal of electricity charges canceled. Withdrawing the electricity bill, the balance on the 11th will be 5,000. Subsequently, when there is a deduction of the unsettled electricity charge, for example, if there is a deposit of 6,000 with the 10th as an account date,
The balance on the 11th will be 11,000, and electricity charges can be deducted. In this case, the debit of the electric charge is re-executed (re-cut) according to the contract of transferring the electric charge from the balance on the account date.

As described above, in the future completion processing, the future settlement is executed when the account balance is set as the final balance. If there is a change in the account, the future payment will be adjusted again. As a result, a night batch of settlement such as account transfer can be processed during the day. The daytime processing of the account transfer is also referred to as a center batch processing herein. The center batch process is not a batch process but an online process started by a command input from the console terminal 2A.

[0086] If the transfer of the account balance on the day due to the online transaction and the cancellation and re-cut caused by the transfer are to be executed in one transaction, various adverse effects occur. First, since the execution time of one transaction becomes longer, online responsiveness deteriorates. Second, since the number of account processing requests to be canceled or recut cannot be predicted, there is a possibility that the processing cannot be actually performed due to, for example, a limitation on the number of interlocking operations. For this reason, it is desirable to adopt a derived transaction model in the future completion processing.

As mentioned above, the derived transaction model allows for enhanced consistency. Since the derived start transaction satisfies the ACID property,
The transaction brings the contents of the database into a consistent state for the application. However, this consistency is system-level consistency,
It does not need to be business-level consistency.

Data that is inconsistent at the business level is
For example, it has a data structure that allows minus of the withdrawable amount on the future date. If the amount that can be withdrawn is negative,
Eventually, it will only need to be resolved before the negative accounting date is reached (actually, the derived transaction will clear the negative state within seconds). Figure 3 shows how to use the derived transaction model in future completion processing
It is shown in (B). In the above example, if there is a 25,000 withdrawal request on the 10th, the main business (online transaction) S17A refers to the balance on the 10th and makes a 25,000 withdrawal, and the balance on the 10th and 11th. Update your daily balance.
The balance on the 11th will be minus 5,000. Then, since a change has occurred in the account balance, the cancellation re-cut main is started as a derived transaction. Minus 5,000
Is stored in a file, and the re-cancel main S18A is started as a derived transaction. Since the subsequent processing is not related to the online response, the main business S17A
Commits and completes the withdrawal process. That is, the cash dispensing process is committed without waiting for the completion of the cancellation / recut main. The re-adjustment of the future settlement is handled in a derivative transaction as an additional business to the main business of transferring the account balance.

In the cancellation re-cut main S18A, the account processing to be canceled is specified based on the balance of minus 5,000 on the 11th. If the account processing established on the 11th is only electricity charge withdrawal, the cancellation recut main (derivation T) starts the cancellation of electricity charge withdrawal as a derivative transaction. In step S17B, the electricity charge withdrawal is canceled, and the balance on the 11th is updated. In the electricity charge withdrawal cancellation process S17B, the account is changed, so the cancellation / recut main S18B is started again as a derived transaction. Cancel re-cut main S18B is 11
Since the day's account balance has become positive, it is determined that there is no cancellation target, and the processing is completed because there are no uncompleted transactions.

In the future-end completion processing system, a derived transaction model is adopted. An account processing request on the day is processed as an online transaction, and a derived transaction is used to adjust future-day account processing accompanying an account transfer. As a result, daytime processing such as fund transfer is realized while ensuring good online responsiveness. This future-end completion processing system performs cancellation re-cutting in accordance with the priority between account processings, utilizing the fact that the settlement of the future date has no settlement completion (cancellation is possible until the account date is reached). This allows account processing to be sorted according to priority.

FIG. 4 is an explanatory diagram showing the configuration of a cancel / recut main that exchanges account processing according to priority. The details of the technique shown in FIG. 4 are described in the specification and drawings of “A system and a method for completion of a future date” of Japanese Patent Application No. 2001-078306 filed by the same applicant. Here, the outline will be described. Referring to FIG. 3, the cancel recut main activates the main task, and the main task activates the cancel recut main. Processing by repeatedly invoking this derived transaction is called spiral processing. Since each of the cancellation / recut mains S18A and S18B is an independent transaction that satisfies the ACID characteristic, continuous processing cannot be realized by repetition using internal information. Therefore, in the spiral processing, a derivation management flag for maintaining the continuity of the determination and the processing of the cancellation / recut main is used.

Referring to FIG. 4, the derivative activation transaction utilizes a linked transaction as shown in FIG. 2 (B). In the linked start-up process, the account process is canceled or cut again. In conjunction with the cancellation of the account processing, the linked passive processing side deposits and withdraws money from the ordinary deposit. For example, in S31, the withdrawal of the electricity charge is canceled, and the fact that settlement is impossible is stored in the DB that manages the automatic transfer. Then, in the interlocking passive processing, the cancellation amount is deposited in the balance of the ordinary deposit on the account day. Since the cancellation of the withdrawal of electricity charges and the payment of the cancellation amount to the ordinary deposit are linked, they are executed as one transaction. Therefore, cancellations and deposits are atomic. The linked start processing S31 and the linked passive processing S32 reach the synchronization point when the linked passive processing is established and the processing corresponding to the establishment is completed on the start processing side (C35).

The cancellation re-cut main refers to a segment such as a derivation management flag, a balance statement of a future date that allows minus, a transaction statement that records a completed transaction, and a remaining shortage statement that records an unsuccessful transaction. To determine what action should be taken to optimize the account (or restore business consistency),
Invoke cancellation processing, modified recut processing, and recut processing as derived transactions. The cancellation re-cut main first determines whether or not the withdrawable amount is negative on the account date of the future date. If it is negative (branch B1), a cancellation process for canceling the account processing request with the lowest priority on the negative account date is started as a derived transaction. When the cancellation process is derived and started, the cancellation re-cut main reaches the synchronization point (C31) and ends.

The linked start process S31 and the linked passive process S3
After the cancellation is performed by the interlocking of 2 and the account balance is updated by the amount of the cancellation, the cancellation recut main again checks the amount that can be withdrawn, and if it is negative, the account with the lowest priority at this time Derived start of process request cancellation process,
After that, commit (C31). This repetition of the cancellation process is herein referred to as a cancellation spiral SP1. The cancellation spiral SP1 ends when there is no longer a minus in the withdrawable amount (branch B2).

When the account balance is increased or when the possible amount of withdrawal is no longer negative (branch B2), it is determined whether or not a re-cut is necessary. Correction re-cut is a process in which the account processing to be completed on that account date is in a predetermined priority order by exchanging the completed account processing and the uncompleted account processing for the future date. It is. Specifically, the highest priority account processing request among the uncompleted account processing requests is regarded as the highest account processing request,
The corrected withdrawal amount is calculated by summing up the withdrawal amounts used in the established account processing requests having a lower priority than the account processing request and adding the balance. If the highest account processing request is smaller than the corrected withdrawable amount (Branch B
3), a correction re-cut of the highest account processing request is executed (S34). When the re-cut is performed, the balance on that account day becomes negative. Accordingly, in the cancellation re-cut main to be started next, the account processing requests that have been satisfied are canceled in the order of lower priority until the possible withdrawal amount becomes positive.

When the correction re-cut is repeated, the priority of the account processing requests stored in the transaction details becomes higher than the priority of the group of account processing requests stored in the remaining shortage details. In this state, the corrected withdrawal amount cannot be calculated,
It is determined that the correction re-cut is unnecessary (branch B4).

An account processing request that cannot be corrected and recut is
It will not be recut. In the determination of re-cut, re-cut of an account processing request that is not a target of the correction re-cut is considered. For example, since re-cutting is premised on cancellation, re-cutting of account processing requests on the day without canceling account processing or re-cutting of low-priority account processing requests determined not to perform re-cutting Is determined.
The re-cut is performed based on the transaction amount (withdrawal amount) of the account processing request having the highest priority among the uncompleted account processing requests whose account date is the account date to be processed (for example, the calculation date) and the target account sunrise. Compare with possible amount of money. If the transaction amount is smaller than the possible withdrawal amount, the recut is possible, so the recut of the account processing request is started as a derived transaction and committed (C33).

Synchronized start processing S37 and interlocked passive processing S3
8 performs the re-cutting process in conjunction with it, and after reaching the synchronization point, the cancellation re-cut main is activated again. If there is no minus in the possible withdrawal amount, the modified recut is completed, and there is no recut target, the cancellation recut main completes the processing. Generally, when the balance decreases, the cancellation spiral SP1 operates, and when the balance increases, the modified recut and recut spiral SP2 operate. Since the cancellation recut main performs the optimization of the account processing sequentially using the derived transaction, it is possible to strictly execute the future completion processing assuming the occurrence of the cancellation at the future date, and furthermore, Complex processing of settlement by priority can be stably realized, and since the processing is completed at a future date, continuous operation can be performed for 24 hours while performing processing based on priority. Furthermore, since the cancellation re-cut main performs optimization based on the priority of the account processing request each time the account balance changes, the execution order of the account processing request is limited compared to the batch processing. Disappears.

The reordering of the account processing and the daytime processing of the night batch using the future date can be used in various online systems regardless of the accounting system. For example, reflection of priorities regarding reservations of tickets and accommodation facilities, changes in selling prices and commodities when selling commodities via the Internet or the like, and updating of various kinds of information when an order is placed are made. In a system in which sales, inventory management, demand forecasting, and ordering are related, sales and inventory management are executed as linked online transactions, and processing required for ordering is started as a derived transaction.
Since the presence or absence of an order is not related to the sale, the online transaction commits when the sale is recorded with reference to the stock. The derived transaction determines the presence or absence of an order according to the stock quantity or demand forecast. In this case, sales and inventory management are business processes (main business), and ordering is an incidental process (auxiliary business). In addition, delivery and billing arrangements are required depending on the sale. Arrangement of delivery or billing triggered by sales can also be a trigger of a derived transaction. As described above, when the responsiveness, the automation of complicated processing, and the strictness of processing are to be simultaneously achieved in the online system, the derived transaction model according to the present embodiment can be used.

When the derived transaction model according to the present embodiment is used, if the execution of the derived startup transaction generates intermediate data regarding business consistency, the intermediate data has durability with respect to the file. 6 to determine and execute the derivative transaction to eliminate an intermediate state relating to business consistency caused by execution of the business processing request and to maintain business consistency. This allows
It is possible to achieve both improved online responsiveness and strict execution of complicated processing.

FIG. 5 is an explanatory diagram showing an example in which a derived transaction is used in the terminal return continuous processing. Derived transactions are used for processing related services. As a special example of the incidental work, there is a terminal return continuous processing. The terminal return continuous processing is related to processing that is not completed unless the processing of a transaction input from the terminal is repeated by transmitting and receiving data to and from the terminal due to various restrictions of the system.
When transmitting / receiving data to / from a terminal, the communication speed is generally slower than the calculation speed, and the CPU must wait for communication.

For example, in withdrawal processing at the time of funding regular,
In some cases, the number of payable items may increase, for example, 120 items can be paid for in 0 years. In this case, due to the restrictions on system resources, not all transactions can be processed in one transaction. Therefore, for example, five items are processed in one transaction. A dummy response is transmitted to the terminal every time the processing of the five details is completed, and when the continuation processing request is received from the terminal, the processing of the five details is repeated. However, data transmission / reception between a terminal and a host generally requires about 2 seconds.
40 seconds (2 seconds x 20 times) are required. The time required for the CPU to process the five specifications is about 0.1 second, excluding transmission and reception of messages.

For this reason, in the example shown in FIG. 5, when the business process request that is the terminal return continuous process is the main business, the actual calculation of the payment contents including the interest is considered as the incidental business.
By using the repetition of the derived transaction, deterioration of the response due to communication with the terminal is prevented. That is, in the terminal return continuous processing, the associated task performs the actual processing, and the main task takes charge of the terminal response. In the example shown in FIG. 5, when receiving the withdrawal request for the funding period, the main business S13
A specifies a statement to be paid and performs payment processing on the first five statements. Then, the main business S13A registers the payment contents including the interest in the transaction statement of the file 6 as the transaction statement. The main task S13A further turns on the processing flag in the terminal control DB shown in FIG. And the main business S1
3A activates payment processing S14A as a derived transaction. A dummy response in which information that processing is still being performed is transmitted to the terminal. Here, the main task S13A reaches the synchronization point.

In the payment process S14A, the payment process for five items is performed based on the key of the item to be paid passed from the main business S13A. The details of payment, including interest, will be recorded and updated in the above statement. Then, the payment processing S14B for performing the same processing is started. In step S14B, similar to step S14A, the payment processing of the following five items is performed based on the key of the item to be paid passed from payment process S14A. This is repeated, and when the payment process is completed in the payment process S15, the processing flag in the terminal control DB 7 is turned off.

The payment process has been repeatedly invoked as a derived transaction having ACID characteristics. Separately, when a status confirmation is received from the terminal, the main task S13B
Checks the terminal control DB7. If the processing flag in the terminal control DB 7 is ON, a dummy response is transmitted to the terminal. Further, when the status confirmation request is received and the processing flag in the terminal control DB 7 is OFF, the main task S
Reference numeral 16 creates and transmits print data to the payment slip from the transaction details.

As described above, in the terminal return continuous processing,
The transaction execution unit 16 activates the derived transaction when the main business transaction that processes the business processing request activates the derived transaction (S13A), and repeatedly activates the derived transaction until there is no more processing target (S14A, S14B, S14C, S14D, S1).
5). On the other hand, the main business transaction repeats a dummy response to the terminal until the processing is completed by repeatedly invoking the derivative transaction (step S13).
B). The main business transaction returns a response to the terminal after the process to be processed is completed by repeatedly invoking the derived transaction (payment process).

In the example shown in FIG. 5, for example, the derived transaction is executed 19 times in 100 items, and the required time is 1.9 seconds (0.1 seconds × 19 times). All payment processing is completed within 2 seconds until the request (status confirmation) is received, and the overall response time is 4 seconds. This is 1/10 of the case of responding to the terminal.

When performing a large number of continuous processes,
By using derived transactions, operations can be simplified and overall processing speed can be improved. For example, there are tasks that require the approval of an administrator to actually execute a certain process. For example, suppose that the administrator needs to approve the exchange transfer processing. In this case, the contents of the process are registered in the message DB, and the actual transfer is performed at the stage when the approval of the administrator is obtained. If the individual is notified that the approval has been obtained, it is necessary to perform operations for the number of transfers and transmit and receive data to and from the terminal. On the other hand, if it is attempted to execute the entire transfer in one transaction, the processing time becomes longer, and there is a possibility that the resources of the system become insufficient. Therefore, use a derived transaction.

Upon receiving a transfer request form from the customer, the operator performs a transfer content registration operation based on the transfer request form. At this point, no actual transfer is performed. The contents of the transfer content registration are printed on a slip. When the number of registered transfer details has reached a certain level, the operator requests approval from the administrator. The administrator confirms that the transfer request form matches the print content of the slip, and stamps the slip. When the slip is stamped, the operator performs approval notification processing. The transfer processing is executed by this approval notification processing. In the approval notification processing, a maximum of 22 transfers are processed in one operation by inputting the first message number and the number of cases.

In the approval notification process, first, as an online transaction, the message DB is read with the first message number input, and if valid, a deposit process is performed.
Set the next message number and start the approval notification process as a derived transaction. In the derived transaction that is derived, the same processing is performed based on the message number passed from the preprocessing, the next message number is set, and the derived transaction is started. By repeating the derived transactions as shown in FIG. 2C until the number of cases is reached, a maximum of 22 transactions are executed in one operation. This makes it possible to reduce the system load while omitting a terminal response.

As described above, in the present embodiment, the following two methods are used for the “derived transaction”.
(1) The online transaction is a directly requested task, and it is not necessary to respond at the time of the online transaction, but the task processing that must be processed according to the processing result of the online transaction is processed as a derived transaction. In (1), online responsiveness is ensured by executing, as a derived transaction, processing that has conventionally been performed in batch processing or processing that is required by bringing the batch processing online. (2) In order to reduce the communication time between the terminal and the CPU, the main task is processed by repeating derived transactions without processing the online response itself. This (2) corresponds to a terminal return continuous process, an approval notification process, and the like.

Next, in the derived transaction model,
A method for restricting the execution of the derived transaction according to the load on the CPU will be described. Derived transactions do not need to be executed synchronously with derived start transactions. For this reason, it is also possible to commit only the online transaction which is a derived start transaction, and to abort the execution of the derived transaction. When the execution of the derived transaction is stopped, the CPU
Is reduced, and the responsiveness of online processing can be maintained satisfactorily. The suspended derived transaction may be restarted while the load on the CPU is reduced. Further, when there is a possibility that a derivative transaction such as a central batch process may be activated, and for internal processing, the input may be interrupted when the CPU load is heavy. As described above, in the present embodiment, a complicated task is executed while maximally preventing a situation in which the online response is deteriorated by the accompanying task.

Referring again to FIG. 1, the calculating means 4 includes a total amount control unit 14 for restricting the activation of the derived transaction according to the total amount of transactions whose execution is managed by the online response unit 10 and the derived transaction management unit 12. It has. The restriction on the activation of the derived transaction is, for example, to suspend (interrupt) the input of the internal business processing request among the business processing requests to be the derived activation transaction, or to execute the derived transaction while executing the business processing request. This includes a process for stopping the activation of the application, and a process for causing the execution of the derived activation transaction to be an error.

In this example, the total amount control unit 14 has an execution status monitoring function 26 for monitoring the total number of transactions waiting for execution, and the number of transactions waiting for execution is predetermined by the execution status monitoring function 26. A derivation start transaction input interruption control function 28 for interrupting the input of a business process request as a derivation start transaction when it is determined that the number of the first level has been exceeded is provided. When the execution status monitoring function 26 determines that the number of transactions waiting to be executed has exceeded a predetermined second-level number, the total amount control unit 14 registers the derivative activation information in a file. A derivative activation suspension control function 30 for suspending the activation of the derivative transaction in the state may be provided.

In the example shown in FIG. 1, the total amount is controlled based on the number of transactions (request messages of business processing requests) waiting to be executed. The number of business processing requests is, for example, the number of request messages stored in the queue. Here, the first to promote the reduction of the invocation of derived transactions
And a second level for immediately stopping the derivation start. When the number of waiting transactions exceeds the first level, the derived activation transaction input interruption control function 28 interrupts the input of a business processing request for requesting the central batch processing in, for example, the future completion processing system. The derived activation suspension control function 30 suspends the execution start of the derived transaction requested to be activated from the running derived activation transaction when the second level is exceeded. This prevents the responsiveness of the online transaction from deteriorating even when the load on the CPU increases.

FIG. 6 is a flowchart showing the configuration of the total amount control process for performing the total amount control in two stages. Here, the first
Level <second level. First, the stagnation or execution status of the transaction is checked (step S41).
The total number of transactions stored in the queue etc. is the first
If the level exceeds the level, the input of the derived activation transaction is interrupted (step S42). further,
If there is a stay exceeding the second level, the activation of a new derived transaction by the currently executing derived activation transaction is stopped. This is preferably performed by storing the derived activation information in the file 6 and not outputting the derived activation message.

On the other hand, if the number of business process requests registered in the queue is smaller than the first level (step S4).
6) If the suspension and suspension of the derived transaction are ongoing (step S47), it is checked whether the number of stays is 0. It controls input restart and re-execution of the derived transaction (step S48). In step S48, a message indicating that restart (re-execution) has become possible may be displayed on the terminal to prompt the user to input a command for re-start (re-execution). The resumption (re-execution) control may be automatically performed with the passage of time as a trigger.

In this embodiment, even when the activation of the derived transaction is stopped, the restart is managed based on the derived activation information stored in the file 6, so that the restart of the derived transaction is reliable and easy. It is. As described above, in the present embodiment, by making the associated transaction a derived transaction, the online transaction, which is a derived startup transaction, is brought to the synchronization point early, thereby directly maintaining good online responsiveness. When the number of stagnated transactions increases due to the processing capacity of the online transaction, the input of the internal derived transaction is interrupted, and the activation of the derived transaction is stopped to indirectly respond to the online transaction. To prevent deterioration. By this. Even when there is an unpredictable concentration of business processing requests or on various business concentration days, online responsiveness can be automatically maintained at a certain level.

As described above, according to the present embodiment, by utilizing the derived transaction model, the derived activation transaction can be committed early, and the restart can be reliably controlled even if the derived transaction is aborted. Because stability can be provided, complicated processing can be realized while maintaining good online response. In addition, in the case of controlling the total amount, indirect execution is performed by limiting the number of executions of the derived transaction according to the capacity of the CPU. Responsiveness of the online transaction can be ensured. This makes it possible to reconstruct, for example, daytime batch processing, which was conventionally performed in nighttime batch processing. In most aspects, derived transactions allow for near real-time online processing. For example, in the case of an accounting system, it is assumed that payment is made at an ATM when there is an unsatisfied account process due to a shortage of funds. Since the deposit processing is a derivative activation transaction, commit early and record the balance of the deposit in the passbook. While this passbook entry is being made, the re-cut of the unsettled account processing by the derived transaction is completed. Therefore, the balance after the re-cut can be continuously printed on the passbook.

As described above, the derived transaction is usually processed in a state close to online / real time. On the other hand, when the processing is exceptionally long or when the load on the CPU is large, it is processed after several tens of seconds. In addition, even when an error occurs due to a problem with the application of the associated business, the application can be corrected while completing the online response, and only the associated business can be re-executed afterwards. As described above, in the derived transaction model, the programmer and the system can be freed from the adverse effects of performing a large number of processes in one transaction. System development becomes possible.

[0099]

Second Embodiment As disclosed in the first embodiment, the derived transaction model provides excellent harmony between online responsiveness and realization of complicated business processing. But,
Since the derived transaction model and the chained transaction model are not standardized, the mechanism is not provided depending on the transaction management system (TP monitor, transaction manager) used. However, the characteristics of the derived transaction can be secured by using a lock mechanism for the DB. The second embodiment discloses an example in which two databases are used to manage the characteristics of the derived transaction. By applying the second embodiment, the ACID characteristics of a normal transaction can be managed. In other words, a derived transaction model can be constructed as long as the system can secure seriality by locking the DB. There are various reasons for using the two databases in the second embodiment. One of the reasons is that the two DBs do not need to be reorganized. Therefore, two DBs
Is used, the load on system management does not increase.

<Derived Transaction Management> FIG. 7 is a block diagram showing an outline of the configuration of an online transaction management system (or online system) constituting the accounting system according to the present embodiment. The online system includes a receiving means 2 for receiving a business processing request input from terminals 1A, 1B,..., 1G via the networks 3A, 3B, Means 4; The receiving means 2 is the communication control device 52 in the example shown in FIG.

The communication control device 52 is connected to the internal (in-line) network 3A and the external network 3B. Each of the networks 3A and 3B may include a large number of networks physically and logically. The communication control device 52 includes, via the internal network 3A, a CD / ATM 1A used for online transactions with a customer, a sales office terminal 1B located in a sales office and operated by a sales representative, and a telephone call from the customer. Is connected to a telephone banking center 1C for carrying out transactions by.

The communication control unit 52 performs a Zengin Center 1D for controlling communication such as exchange with another financial institution via the external network 3B, another external center 1E, and performs firm banking and internet banking. It is connected to a customer PC 1F such as a customer personal computer and a customer portable terminal 1G such as a mobile phone.

Each terminal 1A, 1B, 1C, 1F, 1G,
C from the centers 1D, 1E, etc. via the communication control device 52
A request for deposit or withdrawal is input to the PU. Further, the communication control device 52 is connected to a console terminal 2A for inputting a command for requesting the start of the central batch processing (business processing request) and a command for requesting the restart of the aborted derived transaction. Zengin Center 1D is a center of the national bank data communication system. It is connected to a personal information center and another-line computer center. A request command (telegram) for performing exchange transactions such as transfer and remittance is transmitted and received.

The external center 1E includes various networks (ACS of regional banks, BANCS of city banks, and MICS of nationwide cash services) constructed according to the type of business of the financial institution.
Etc.), a firm bank (FB), an electronic banking (EB), a center for transmitting and receiving data necessary for telephone banking (for example, ANSER), a POS system of a store, and a credit card settlement system. It is a center (for example, CAFIS or DCS) for communicating with terminals. From this external center, a request command (telegram) for performing various transactions that can be made at a financial institution window, such as notification, inquiry, and fund transfer, is input.

The communication control device 52 receives the request command according to each protocol, and
Input to PU. The CPU converts a request command input in each form from each terminal into an account processing request in a predetermined format and delivers the account processing request to a program for performing account processing.

In addition, transfer of utility charges (external self-oscillation)
It is carried by the carry-in medium 54. The CPU generates a business processing request using the external self-oscillation original data read by the medium reading unit 56 and another database (DB). In the example illustrated in FIG. 7, the accounting system includes a self-vibration-related DB 5 that records data read from the carry-in medium 54 and data about a pre-registered self-financing contract, loan repayment, and the like.
0, a self-oscillation input file generating means 60 for generating a self-oscillation input file, which is a group of business processing requests, for performing an automatic transfer such as an account transfer based on the data stored in the self-oscillation-related DB, A center cut message input means 62 for inputting a center cut message, which is a self-oscillation input file generated by the input file generating means 60, to the transaction management unit 64 in accordance with the operation of the console terminal 2A. The center cut message is a message instructing the batch processing of the center, and is a message in which a plurality of self-oscillation processing requests are blocked. 5 processing requests for self-oscillation
In the case of blocking, the transaction by this center cut message processes five automatic transfers.

In the example shown in FIG. 7, the file 6 includes a derivation management DB 70 for recording derivation start information of a derivation transaction for each derivation management serial number, and a derivation management DB for each derivation management serial number serving as a key of the derivation management DB 70. A derived index DB 68 for recording index information indicating whether or not it is in use. File 6 is
A system status DB 83 is provided for recording bits indicating the status of the system corresponding to the stagnation of the transaction (such as a derivation start transaction interruption bit). In the present embodiment, the derivation activation information is stored in the derivation management DB 70. Then, the characteristics of the derived transaction are managed using the behavior of the derived activation information.

The derived activation transaction stores derived activation information. However, when the derived activation transaction is aborted, it is determined that the derived activation information has not been updated by rollback. Therefore, the derived transaction can read whether the derived activation transaction has committed or aborted by reading the derived activation information immediately after starting the activation. For example, in the example where the in-use flag is included in the derived activation information, if the derived activation transaction commits, the in-use flag is “in use” (for example, “1” of the character). On the other hand, when aborted, even if the in-use flag is updated to “in use” by the derived activation transaction, the update is rolled back. Therefore, in the derived transaction, the in-use flag of the derived activation information is “usable” (for example, “0” of the character).
If so, it can be determined that the derived activation transaction has been aborted. This satisfies the condition that the derived transaction commits only when the derived activation transaction commits.

Further, the derived transaction is requested to be activated during the execution of the derived activation transaction. Therefore, before the derived activation transaction is committed, the derived transaction may be scheduled and start processing. To prevent this, the derived transaction goes to read the derived activation information immediately after its start. Until the derived startup transaction commits,
Since the derived activation information is locked, the derived transaction waits until the lock is released.
That is, the derived transaction reads the derived activation information at the time of its start, and waits for the derived activation transaction to commit. This manages the seriality between the derived start transaction and the derived transaction.

As described above, the derived activation transaction stores the derived activation information as a part thereof, and the derived transaction reads the derived activation information at the start of processing, thereby realizing the characteristic of the derived transaction of extended seriality. be able to.

It is also possible not to use the derivation index DB 68 only as the derivation management DB 70,
If the derived index DB 68 is used, the derived management DB 7
Zero reorganization is not required, and the system can be operated continuously for 24 hours without performing maintenance such as deletion of data.
The derivative index DB 68 manages the state of the derivative management serial number (in use or available). When the transaction management unit 64 uses the available derivation management serial number, it deletes the derivation activation information that is no longer required due to the normal commit of the derivation transaction, and records new derivation activation information.
Therefore, the derivation start information that is no longer needed is successively overwritten, so that the derivation management DB need not be reorganized. In the example of overwriting the derivative activation information, the derivative management serial number indicating the segment storing the derivative activation information that may be deleted using the derivative index DB or the like is specified. Therefore, in terms of storing data, the derivation management DB
Is not always unused. Even if the data is stored, the derived activation information has finished its role and is in an erasable state. This erasable state is called “usable”.

In the example shown in FIG. 7, the file 6 further includes
A self-oscillation-related DB for generating a message (a group of business processing requests) requesting the central batch processing, and various master DBs for storing transaction details, information related to financing, and the like are provided.

The operation means 4 processes the business processing request input from the terminal or the like as an online transaction and controls the output of the processing result as a response to the terminal. A transaction management unit 64 that manages a derivative transaction requested to be activated as a part of a predetermined derivative transaction execution process and manages the online transaction.

In the present embodiment, in particular, the transaction management section 64 refers to the derived index DB to specify a usable derived management serial number.
And a derived activation information storage control function 102 for storing the derived activation information in the specified segment of the derived management serial number, and a derived activation transaction commit processing function 1 for committing the derived transaction after storing the derived activation information.
03, a serialization control function 104 for terminating the process of the derived transaction without starting when the derived start transaction is aborted, and a derived transaction for committing the derived transaction and updating the used derivation management serial number to be usable. Commit processing function 10
5 is provided. The transaction management unit 64
Has a derived restart control function 106 for controlling the restart of the aborted derived transaction.

The derivation management serial number specifying function 101 is configured to execute the derivation index DB when a derivation transaction activation request request is issued from an on-line transaction or a derivation activation transaction which is a derivation transaction.
At the same time as specifying the index information 68, based on the specified index information, a usable derivative management serial number of the derivative management DB is specified. If all the transactions executed in parallel read one piece of index information, contention to this index information would increase. For this reason, in the present embodiment, the derivative management serial number specifying function 101 specifies index information that can be used by a derived start transaction that has issued a start request request according to some condition. When the index information can be specified, a usable derivative management serial number is specified with reference to the index information. Since access to the derivation management DB is performed using the derivation management serial number as a key, unintended contention does not occur.

The derived activation information storage control function 102 stores the derived activation information relating to the derived transaction activation request request by the derived activation transaction in the segment of the derived management serial number specified by the derived management serial number specifying function 101. The derived activation information storage control function 102
After storing the derived activation information, the derived transaction is activated.

The derivative activation transaction commit processing function 103 commits the derivative activation transaction when each of the operations of the derivative activation transaction ends normally after the derivative activation information is stored in the given segment of the derivation management serial number. Let it. As in the first embodiment, the derived activation transaction reaches the synchronization point early regardless of the fate of the derived transaction. Then, the seriality control function 104 starts each process of the derived transaction when the derived startup information is successfully read normally in a lockable state at the start of the derived transaction. “Normal reading” means reading in the state stored by the derived startup transaction. That is, when the derived activation transaction is aborted and the derived activation information stored by the derived activation transaction is not rolled back, the seriality control function 104 determines that normal reading has not been performed. , Do not start derived transactions.

Derived transaction commit processing function 1
In step 05, when each process of the derived transaction ends normally, the derived index DB 68 and the derived management DB 70 are updated to be usable with the used derived management serial number. Derived index DB and derived management DB
Commit the derived transaction before and after the process of updating to enable. The process of updating the derived index DB to be usable may be performed as a part of the derived transaction, or may be performed in another transaction (derived DB control process) as described in detail in the third embodiment. You may do it.

The derivation restart control function controls the restart based on the derivation start information stored in the derivation management DB when the derivation transaction is aborted. The restart may be performed automatically or may be performed when a business process request instructing the restart is received.

FIG. 8 is an explanatory diagram showing the relationship between JOB and derived index DB and the like. CICS and IMS, which are types of TP monitors, provide an abstraction called a region. A region is an address space that can execute a plurality of processes. A region is a unit that holds resources, and failures during application execution are localized in the region. The business process request is scheduled in the region. For example, when activating 50 regions, transactions with JOB numbers 0 to 49 operate in parallel. The job number is a fixed number in advance. As described above, the number of regions is predetermined, and the JOB number (for example, J
If the last three digits of the OB name are numerical values within a predetermined range, the index information of the derived index DB 68 may be constructed using the JOB number as a unit. In this case, there is no conflict between a transaction executed in parallel in another region and reading of index information. Even in a system that does not use the concept of a region, there are always numbers for identifying transactions executed in parallel. In this case, a transaction ID or a number obtained by editing the transaction ID is used as the JOB number. The job number may be unique among transactions or processes executed in parallel, and the number may be a numerical value within a predetermined range.

In the example shown in FIG. 8, the derived activation transaction is executed with one of the JOB numbers in a predetermined group of JOB numbers. And derived index D
B has an index bitmap 68 for each index area number 88 with the transaction JOB number as an index area number 88 serving as a key value. Then, in the example shown in FIG.
Holds the index information as a bitmap for each index area number. In region 0, JOBFP000 is scheduled and running. When the transaction of JOBFP000 reads the index information (bitmap),
The derived index DB is accessed using “000”, which is the last three digits of the B name, as a key value. Then, the bit map having the index area number “000” is accessed. In this bitmap, “11100
… ”. Similarly, a transaction operating in region 1 accesses a bitmap with an index area number of “001”. This bitmap is "0100 ..." from the top.

In the example where the index information is a bitmap, the bit ON (1) and OFF (0) indicate whether or not the derived management serial number is in use, and the derived management serial number is specified by the position of the bit. . Here, as an example, it is assumed that 400 derived management serial numbers can be used from one region. In this case, the bitmap has 400 bits. That is, the length is 50 when one byte is used as a unit. Taking Region 0 as an example, the derived management serial number 000
1,0002,0003 are in use and the rest can be used. The fact that the three derived management serial numbers are in use means that the three derived transactions requested to be activated from the region 0 have not been committed.

The derivative management serial number specifying function 101 is, for example,
The bit map is sequentially read from the head, and the bit position of the bit “0” is specified. Then, a derived management serial number is obtained from this bit position. For example, in the case of region 0, since the fourth bit from the beginning is “0”, the specified derivation management serial number is 0004. In the case of region 1, the derivation management serial number starts from 0401. Therefore, when the head of the bitmap is specified, the derivation management serial number is 04.
01.

As described above, in the preferred embodiment, the derivation management serial number specifying function 101 has a function of specifying the derivation management serial number of the derivation management DB 70 based on the index area number 88 and the bit position of the bitmap. .

FIG. 9 is an explanatory diagram exemplifying the data items of the derived DB in this case, and FIG. 9A is a diagram showing an example of the items of the derived index DB. N is for example 125, M
Is 400. The derived index DB 68 includes, as its items, an index area number (a numerical value assigned to each bitmap and the same as the JOB number) and a bitmap (index bitmap). Further, the derivative index DB stores the remaining number of derivative management serial numbers and the number of derivative cases specified by the bitmap. For example,
If the remaining number is 0, processing such as waiting for activation of a derived transaction is performed. The initial value M of the remaining number in FIG. 9A is 400 in the above example.

FIG. 9B is a diagram showing an example of items in the derivation management DB. The derivation management DB has a derivation management serial number as a key value. Other items are details of the derived activation information.
By holding the APPL ID of the derived activation transaction and the APPLID of the derived transaction, it is recorded which main business has derived and activated the associated business. The derived edit number is used to specify the input / output format. The entry date and time are used for searching for an aborted derived transaction. The in-use flag is used by the derived transaction to know whether the derived activation transaction has been committed. FIFO
“Save” is a storage area for various data contents prepared by the derived activation transaction to activate the derived transaction.

In this specification, the term FIFO is used to
Formatted Input Formatted Outpu
t). It is not used as an abbreviation for first-in first-out. FIFO is an abstraction provided by SAIL, an IMS / ESA online application development / operation support program. All inputs from terminals and the like are edited and set in an information area called FIFO according to the task. For this reason, the application program can be developed on the premise that data of a specific item is set at a predefined position in the FIFO irrespective of the format of input from a terminal or the like. That is, by using the FIFO, an application program can be developed regardless of the format of the input / output message. The input / output message and the FIFO are associated using an edit definition. For example, when a derived start transaction starts a derived transaction, data necessary for executing the derived transaction is set to F.
It is set in the IFO, and a derived activation request request is made. Then
SAIL generates a derived message from the FIFO according to the derived edit number. Similarly, the edit definition for each job is used for input of a job processing request from the terminal and output messages to the terminal.

FIG. 10 is an explanatory diagram exemplifying the relationship among the JOB number, the index area number 88 of the derived index DB 68, the bit position, and the derived management serial number indicated by reference numeral 89. As shown in FIG.
The number of the index bitmap (index area number) read by the transaction executed at 00 is “000”. In the example shown in FIG. 10A, bit positions 1 and 5 are in use. In this case, the contents of the derivation management DB are as shown in FIG. On the derived start transaction side, the index
It is desirable that the bits of the bitmap (referred to as derived index bits) and the in-use flag be wrapped in atomicity.

As shown in FIGS. 10C and 10D, 1
If the number M of the derived management serial numbers specified by one index bitmap is determined, the index area number 8
The derivative management serial number can be specified based on 8 and the bit position.

FIG. 11 is a flowchart showing an example of a derivation request management process for managing a derivation transaction request. FIG. 12 is a flowchart illustrating an example of a derived characteristic management process for managing the characteristics of a derived transaction. The derivation request common process shown in FIG. 11 is executed as a part of the derivation start transaction. FIG.
The derived characteristic management common process shown in FIG. 2 is executed as a part of a derived transaction or as another process.

Referring to FIG. 11, when a derivation start request is received from a derivation start transaction, the derivation request common process first reads the derivation index DB using the JOB number (that is, index area number) as a key value (step). S52). Then, the remaining number field in the index area number is checked (step S52), and if there is a space, the bit position of the space (index bit is 0) is specified from the index bit map. If there is no free space in step S52, the spare derived index DB is read, and the remaining number field is checked (step S62). If the spare derivation management serial number is being used, the process ends abnormally.

When a free derived index bit is specified, a derived management serial number is calculated based on the bit position. Then, the derivation management serial number is set in the FIFO of the region in which the derivation start transaction is operating. Further, the derived index bit is updated to “1” indicating ON (the corresponding derived management serial number is in use) (step S54).

Subsequently, the derivation management DB is read using the derivation management serial number as a key value (step S55), and the remaining number field and the derivation number field of the derivation index DB 68 are updated (step S56). Then, the derivative activation information is registered in the derivative management DB, and the in-use flag of the derivative management DB 70 is set to “in use” (step S57).
Subsequently, the activation of the derived transaction is controlled (step S58). For example, SAIL generates a derived message from the FIFO of the derived activation transaction and enqueues it. Subsequently, the derived activation transaction commits.

FIG. 12 is a flow chart showing processing at the start and end of a derived transaction. In the derived characteristic management common processing, first, when a derived transaction is scheduled in any region, first, the derived management DB 70 is read using the derived management serial number of the derived activation message as a key value. At the stage where the derived start transaction has not been committed, the segment of the derived management sequence number in the derived management DB 70 is locked. Therefore, in step S71, the derived started transaction commits or aborts and waits until this lock is released. .

When the derivation transaction succeeds in reading the contents of the derivation management DB, first, the in-use flag is checked. The busy flag has been updated to 1 indicating busy in step S57 by the derived activation transaction. If the derived start transaction commits, this in-use flag remains "in use". On the other hand, the derived activation transaction is executed in step S58.
If aborted later, rollback causes the "in use" flag of the in-use flag to be used by the derived startup transaction.
Update is canceled, and the in-use flag indicates that use is possible 0
It has become. Therefore, in step S72, if the in-use flag is usable, the process is terminated without executing the application program of the derived transaction according to the nature of the derived transaction that the derived transaction commits only when the derived startup transaction commits. (Step S74).

When the derived start transaction has committed normally, the application flag of the derived transaction is called and the execution is controlled because the in-use flag is “in use” (step S75). When the execution of the application program is completed, in the derived characteristic management common process, the derived management DB is read using the derived management serial number as a key (step S76). Then, the in-use flag is updated to be usable (step S77). At this time, the derived index bit of the derived index DB also remains in use. Therefore, the derived index bit of the derived index DB 78 is updated to off as part of the derived transaction or by using another transaction. Before and after updating the derived index bit, the derived transaction commits.

When a derived transaction whose characteristics are managed by the derived characteristics management common process shown in FIG. 12 activates another derived transaction, before the derived transaction is committed, FIG.
The processing shown in is performed.

Here, the relationship between each function shown in FIG. 7 and each process shown in FIGS. 11 and 12 will be described. Each function 101, 102, of the transaction management system shown in FIG.
As in the first embodiment, the CPUs 103, 104, 105, and 106 execute a derivative management serial number specifying command for realizing the derivative management serial number specifying function 101, a derivative start information storage control command, and the like. This can be achieved by:

For example, this program specifies the index information of the derived index DB when there is a request to start a derived transaction from a derived transaction which is an online transaction or a derived transaction, and based on the specified index information. A derivative management serial number specifying command for specifying a usable derivative management serial number in the derivative management DB is provided. When this command is executed, the CPU operates as the derivative management serial number specifying function 101. In the example shown in FIG. 11, when the derivation management serial number specifying command is executed, the CPU realizes steps S51, 52, S53, S54 and the like.

Further, the program causes the segment of the derived management serial number specified in accordance with the derived management serial number specifying command to store the derived startup information relating to the request for starting the derived transaction by the derived startup transaction and to store the derived startup information. A derivative activation information storage control command for activating the derivative transaction after the storage is provided. The CPU operates as the derived activation information storage function 102 by executing this command. In the example shown in FIG. 11, the processes of steps S54, S55, S56, and S57 are processed.

The program further includes a derivative activation transaction commit processing command for committing the derivative activation transaction when each process of the derivative activation transaction ends normally after storing the derivative activation information. Thus, the CPU operates as the derived activation transaction commit processing function 103. Step S
11 is the last step.

Further, the program includes a seriality control command for starting each processing of the derived transaction when the derived start information is successfully read normally in a lockable state at the start of the derived transaction. In the example shown in FIG. 12, this realizes the control of the seriality by the step S71 of reading the derived activation information in step S12. CPU for executing serial control command
Performs the processing of steps S71 to S75 shown in FIG.

The derived transaction management program further updates the derived index DB and the derived management DB to be usable and commits the derived transaction with respect to the derived management serial number used when each process of the derived transaction is normally completed. A derivative transaction commit processing command is provided. The CPU that executes this command performs S76, S77, and S7 shown in FIG.
8. The processing of S79 is performed. In the third embodiment, in order to prevent the occurrence of a deadlock, the derived index DB is updated in S78 and S79 as a separate transaction from the derived transaction.

Further, the program includes a derived restart control command for controlling a restart based on the derived activation information stored in the derived management DB when the derived transaction is aborted. The CPU that executes the derivative restart control command functions as the derivative restart control function 106. The actual restart process may be performed by the derivative restart control unit 77. As described above, each part shown in FIG.
Each step shown in the flowcharts of FIG. 1 and FIG. 12 can be realized by executing a program for performing each processing. The same applies to the steps shown in the flowcharts of the total amount control processing (FIG. 19), the derivation restart necessity determination processing (FIG. 22), and the derivation restart control processing (FIG. 23).

As described above, in the example shown in FIGS. 11 and 12, the derived index DB 68 has a bit map for each of the index area numbers 88 as a column of the derived index bits, and sets the derived index bits to ON or OFF. Accordingly, the usage state of the derivation management DB 70 corresponding to the bit position of the bit is recorded. The derivation management DB 70 has an in-use flag that records the use state of the derivation management serial number as being used or available for each derivation management serial number.

Furthermore, the derivation management serial number specifying function 101
When a derived index bit of OFF (0) indicating availability and a derivation management serial number of available (0) are specified, ON indicating that the derived index bit is in use.
Update to (1) (step S54). Subsequently, the derivative activation information storage control function 102 updates the in-use flag of the derivative management serial number to “in use” (1) when the derivative activation information is stored (step S57). Then, when the in-use flag of the derivation management serial number passed from the derivation start transaction is usable (0), the seriality control function 104 performs processing without starting the derivation transaction requested to be started. Is terminated (step S74), and the derived transaction commit control function 10
5 updates the derived index bit and the in-use flag to a usable state (0) at or after completion of the derived transaction (step S7).
7, S79). That is, the derived index bit is set to O
FF (0), and the in-use flag is enabled (0).

As described above, by using the content of the derived activation information between the derived transaction and the derived transaction, the properties of the derived transaction can be realized by using a general DB lock mechanism.

Next, an example of the derived transaction management will be described with reference to the cancellation / recut main in the future completion processing system. If the timing of transaction commit is not described in the program, the reusability of the program is enhanced. For this reason, the program that manages the execution of the transaction is executed by the application program (APP)
If L) is called, executed, and a commit is given at the stage when the process is completed normally, the APPL can be used in various modes. The program that manages the transaction is referred to as a business main here. Also, APP
As an execution form of L, the case where it is input from the terminal for the first time, the case where it is continuously and repeatedly processed, the case where it is called as an interlocked process, the case where it is started as a derived transaction, or the case where it is input as a center batch process There are cases. Even if these transaction modes are different, some or all of the programs may be common. For this reason, if the program is subdivided and an appropriate program is specified according to the mode of activation, the reusability of the program is enhanced, and the total number of lines can be reduced.

FIG. 13 is an explanatory diagram showing an example of an operation code table for providing such a mechanism. The business process request and the contents of the derived transaction are specified by the operation code. For example, the operation code of the ordinary deposit withdrawal process is 01001. Then, in the case of the terminal first input, the programs 01, 02, and 03 are called and executed in this order. Similarly, when the request for the interlocking process is received, the programs 06, 07, and 08 are executed in this order.
Upon receiving a business process request (including an operation code), the SAIL specifies an edit definition corresponding to the business, assembles a FIFO based on the edit definition, and calls the business main. The business main calls the program (APPL) according to the program list in the operation code table.

Further, when the business main receives a request to start a derived transaction, it calls a program for executing the processing shown in FIG. On the other hand, when starting the derived transaction, before and after the APPL is called by the operation code of the derived transaction, FIG.
The processing shown in is performed.

As shown in FIG. 13, the operation code of the ordinary deposit and withdrawal is 01001. This savings withdrawal may be canceled in a future-dated closing system. For this cancellation, a system is used in which a constant value (500 in the example shown in FIG. 13) is added to all the operation codes. This eliminates the need to search for an opcode when canceling a transaction. As shown in FIG. 13, withdrawal of the ordinary deposit is started in conjunction with or derived from fixed deposit (03001) or regular deposit (04001).

FIG. 14 is an explanatory diagram showing an example of processing in the cancellation re-cut main. FIG. 14A is a diagram showing an example of canceling an electricity charge withdrawal (internal self-generation) by account processing. 1
FIG. 4 (B) is a diagram showing the transition of the balance due to the processing.
As shown in FIG. 14B, the balance on the 6th is 60,000.
Then, the deduction of electricity charges with the 7th as the accounting date (self-oscillation serial number 123
45) 20,000 is executed by the post-date completion processing,
Assume that the balance on the 7th is 40,000. In this state, if there is a deposit from the ordinary deposit to the time deposit using the ATM, the term deposit processing S21 is performed with the operation code 01001.
Of the ordinary deposit and withdrawal S22 are started in conjunction with each other. In savings account withdrawal, the balance on the 6th is 60,000, so 50,000
Since the withdrawal of 0 is possible, the withdrawal of 50,000 is made, and the fact that the withdrawal is established is sent to the periodic deposit (interlocked return).

In the time deposit, it is recorded in a time deposit master or the like,
A response to the effect that the periodic payment has been completed is output to the ATM. On the other hand, in the ordinary deposit withdrawal S22, after updating the balance on the 6th,
The balance on the 7th, which is the account date of the future date, is also updated. The balance on the 7th will be minus 10,000. Deposit withdrawal S2
In the case of No. 2, since the balance on the 7th is minus, the cancellation recut main is started with the 7th as the account date. Cancel re-cut main is 7 until the minus of the withdrawable amount disappears
Control to cancel the account processing established on the day. Here, the cancellation of the withdrawal of the electricity fee is started. In step S24, the withdrawal of the electricity charge is canceled (operation code 0200).
1 + 500 = 02501), and is linked to the cancellation of ordinary withdrawal. Cancel normal withdrawal (Opcode 01001 + 50
In the case of 0 = 0501), 20,000 is added to the balance on the 7th to cancel the withdrawal of 20,000. And
Since a change has occurred in the account balance on the 7th, the recancellation recut main is started again as a derived transaction. The cancellation / recut main S26 performs the processing shown in FIG. 4, and ends the processing without any activation since there is no need for the cancellation / recut.

As shown in FIG. 14A, the regular payment and the ordinary payment are linked, and are one transaction T1. This is scheduled for Region 0, and JO
Assume that the B number is “000”. When the ordinary withdrawal requests the activation request of the derived transaction, the transaction T1 has not committed. In a system using the fast path (FP), a derived transaction is scheduled before the commit of transaction T1. Since region 0 is used by the derived start transaction T1, the derived transaction, ie, the cancellation recut main, is scheduled in, for example, region 1. In this case, the job number of the cancel / recut main is “0”.
01 ". The cancellation re-cut main S23 activates cancellation of the electricity charge as a derived transaction after performing various determination processes.

When the cancellation re-cut main S23 activates the cancellation processing of the electricity charge withdrawal as the derivative activation transaction T2, the transaction T for the regular deposit and the normal withdrawal is executed.
1 is highly likely to have already committed. That is, the derivative activation transaction T1 commits without waiting for the commit of the derivative transaction T2 that is the cancellation / recut main, which is an associated task. Transaction T1
Is committed, since region 0 is vacant, a derived transaction T3 that cancels the electricity charge withdrawal
May be scheduled in Region 0.

FIGS. 15 to 17 are explanatory diagrams for explaining the storage of the derived activation information, the output of the derived message, and the transition of the FIFO in this state. In this example, IB
The IMS operating on the MVS of M company is speeded up by the FP, the FIFO and the edit definition by SAIL are used, and each transaction is managed by the operation main using the operation code table. In this example, the derivation index DB and the derivation management DB described in the second embodiment
Is used.

The business main receives a business processing request for periodic payment from the ATM in the form of an input message indicated by reference numeral M1 in FIG. In the input message M1, H is the header, the opcode is 04001 (see FIG. 13), which indicates regular payment, and the amount is 50,000.
Request the process of depositing the account 3000xxxx of the store number. When the IMS removes the input message M1 from the queue, it schedules it to an empty region 0 and starts a transaction. As shown in FIG. 17, the SAIL and the business main develop a FIFO 86A for regular payment using a predetermined input edit definition from the input message M1 in this region 0. As shown in FIG.
In the FIFO 86A, an operation code, a store number for regular payment, a deposit amount, and the like are stored at predetermined positions.
Then, the business main calls up and executes a predetermined program with reference to the operation code table of the periodic payment.
The term deposit program activates interlocking with opcode 01001 to request a withdrawal from the ordinary deposit. At this time, based on the linked editing definition, the FIF for ordinary withdrawal
O86B is set. The result code is a code indicating whether or not the withdrawal from the ordinary deposit is successful.

[0158] The ordinary deposit withdrawal refers to the balance set in the FIFO with the account date of 2001/3/6, determines whether or not withdrawal is possible, and if the withdrawal is possible, Update the balance on the 6th to 10,000. Then, since there is a future date, the balance on the 7th is also updated. Since the balance on the 7th became minus, the start date (derivation date) for processing the cancellation / recut main is set to 2001/3/7, and the derivation start request request is passed to the business main. For example, the macro of the derivative start is executed. SAIL is a regular withdrawal FI
A derived message (cancellation / recut main) M2 is generated from the contents of the FO using the derived editing definition. At this time, the business main calls the processing shown in FIG. As shown in FIG. 11, the called derivation request common process stores the contents of the ordinary withdrawal FIFO in the derivation management DB. In this example, since the JOB number is “000”, the index bitmap of the index area 1 is read as shown in FIG. Then, together with the entry date and time, the contents of the ordinary dispensing FIFO 86B shown in FIG. In the state where the ordinary withdrawal FIFO is recorded, FIG.
As shown in (1), the derived index bit at the head of the index bitmap is ON (1), and the in-use flag of the derived management serial number 1 is in use (1).

As shown in FIG. 15, when the savings are successfully dispensed, a result code (0000) indicating that the dispensing was successful is recorded in the interlocked return block using the interlocked return edit definition. The recurring payment process was successful because
An output message is generated from the periodic deposit FIFO using the output edit definition and transmitted to the ATM. With this, JO
Transaction T1 of BFP000 commits.

The IMS schedules the derived message M2 in Region 1, and SAIL sets the Cancel Recut FIFO 86D from the derived message. Since the cancellation / recut main is a derived transaction, the business main first performs the processing shown in FIG. That is, as the derived characteristic management common processing, the derivation management DB using the derived management serial number as a key value is read. Here, the segment of the derivation management serial number 1 is read. That is, derivation management D
The normal withdrawal FIFO 86B stored in B70 is read. As a result, while waiting for the commit of the transaction T1, the presence or absence of the abort of the T1 is confirmed. After the transaction T1 including the normal withdrawal is normally committed, the application program is called as shown in step S75. Here, a program constituting 05001 (cancellation / recut main) which is the operation code of the derived message is called. The cancellation / recut main specifies the object of cancellation, sets its self-oscillation serial number (123456), the cancellation amount, and the like in the cancellation / recut FIFO 86D, and makes a derivative activation request request. The business main executes the derivation request common process shown in FIG. At this time, since the cancellation / recut main operates with the job number 001, the derivative management serial number is 401 as shown in FIG. Therefore, F
The item of the derivative management serial number of the FIFO 86D is updated from 1 to 401, and the FIFO 86D is stored in the segment of the derivative management serial number 401. And, according to the derived edit definition,
A derived message M3 shown in FIG. 16 is generated.

Derived message M3 is self-oscillation (withdrawal of electricity)
And the operation code is 02501. The transaction T3 cancels the self-vibration using the interlocking transaction, and the ordinary withdrawal canceling process, which is the interlocking passive operation, outputs the derived message M4. At this time, the transaction T
Suppose that 3 is scheduled in region 0.

In the example shown in FIG.
When the second derivation request common process outputs a derivation message, the transaction T1 has committed. This is because the derivative activation transaction T1 commits early without waiting for the commit of the derivative transaction T2, and here, the responsiveness of the periodic deposit process is secured. On the other hand, a derived message (self-cancel cancellation) M3
Is scheduled before transaction T2 commits. Therefore, the transaction T3 whose main task is to cancel self-vibration is scheduled in the region 0.
In the transaction T3, first, in order to wait for the commit of the transaction T2, which is the cancellation / recut main, the derivation management information of the derivation management serial number 401 is read.

When transaction T2 commits,
As shown in FIG. 12, the business main executes the derived characteristic management common processing (S76, S77) as a part of the transaction T2. Further, in the example where S78 and S79 are also executed as a part of the transaction T2, the derived transaction T2 commits after the head derived index bit of the index area 1 is updated to OFF. In this case, when the transaction T3 starts the derived transaction, the derived management serial number 1 is already empty.

In the example shown in FIG.
The update of B to OFF (the corresponding derivation management serial number can be used) is started as a separate transaction. In this case, the transaction T2 commits when step S77 ends. At this time, in the transaction T3, when the derivation management serial number 401 is successfully read, and when the savings / withdrawal of the ordinary deposit is completed, the transaction T3 attempts to activate the cancellation / recut main again. At this time, if the process of updating the derived index bit to OFF (derived DB control process) started by the transaction T2 is not completed, the derived index bit at the head of the index area 1 remains 1. For this reason, the next unused bit position specifies the derived index bit of 2. Transaction T3
Is a normal withdrawal cancellation FIFO or the like, which is stored in the segment of the derivation management serial number 2.

When the derived DB control process started by the transaction T2 updates the index bit, the leading bit of the index bit in the index area 1 becomes 0. Therefore, when the next transaction executed in the region 0 activates the derived transaction, the derived management serial number 1 is used. As described above, since the derivation management serial number is repeatedly used, the reorganization process of the derivation management DB and the derivation index DB is unnecessary in the present embodiment.

In the examples shown in FIGS. 15 to 17, each region has been described as executing both a general transaction and a derived transaction. However, as shown in FIG. 18, a JOB number (region) is derived from a general transaction and a derived transaction. You may make it allocate to a transaction separately. In the example shown in FIG. 18, since there is no possibility that all JOBs are used by a derived transaction, it is possible to prevent the deterioration of online responsiveness. In order to facilitate the handling of business process requests (messages), in the example shown in FIG. 18, the online system temporarily stores a message (telegram) requesting execution of an online transaction or center batch processing as a queue 13. General queue 13 for storing information
A and a derivation queue for temporarily storing a derivation message requesting execution of a derivation transaction. By using two types of queues together, it becomes easy to control the total amount of transactions.

<Total Volume Control> Referring again to FIG. 7, the online system (or transaction control system) monitors the number of transactions stagnating in the general queue 13A and the derivative queue 13B shown in FIG. A unit 78 and a total amount control unit 79 for controlling the activation of the derivative activation transaction or the derivative transaction in accordance with the number of transactions remaining in each queue monitored by the retention monitoring unit 78.

FIG. 19 is a flowchart showing an example of the stay monitoring process. When the number of stays in the general queue or the derivative queue is equal to or higher than a predetermined first level (steps S81 and S83), the stay monitoring unit 78 turns on the derivative activation transaction interruption bit (step S82). ,
S84). In the example shown in FIG.
When the number of messages stored in 3A and 13B exceeds 200, the derivative activation transaction interruption bit is set to ON.
If the number of transactions staying in the derivation queue is greater than or equal to the second level (500) set in advance by a number greater than the first level (200) (step S85), the derivation is stopped. The bit is turned on (step S86). On the other hand, if the number of stays in each queue becomes 0 after each bit is turned on (step S87), each bit is turned off (step S88). The monitoring process by the stay monitoring unit 78 is repeatedly executed at predetermined monitoring time intervals, for example, every 30 seconds. The retention monitoring unit 78 outputs a derivative activation transaction interruption bit,
The derivation stop bit is stored in the system status DB 83 shown in FIG.

FIG. 20 is a chart showing an example of a process for waiting for the execution of a derived transaction. Total control unit 7
9 is provided with a derivative activation transaction input interruption control function 28 for interrupting the input of a business process request for activating the derivative transaction when the derivative activation transaction interruption bit is ON. An example of a business process request that starts a derived transaction is a center batch process. In the present embodiment, the derivative activation transaction input interruption control function 28 includes, for example,
When the center cut message requesting the center batch processing is input (for example, at the time of EXIT processing of SAIL), the derived activation transaction interruption bit stored in the system status DB 83 is referred to, and if the derived activation transaction interruption bit is ON, Interrupt the input of the center cut message. Therefore, the system load may be reduced by waiting the center batch process itself, and the center batch process may start the cancellation / recut main as a derived transaction.
Invocation of derived transactions can be suppressed.

Further, the total amount control unit 79 determines whether the system status D
If the derivation abort bit stored in B83 is ON and there is a derivation start request, after the derivation start information is registered in the derivation management DB, the derivation start abort control function 30 that does not start the derivation transaction is executed. Prepare. FIG.
In the example shown in FIG. 8, the derivation start request common process that manages the derivation start transaction does not output the derivation message if the derivation stop bit is ON after the derivation start information is registered. Then, the derived start transaction commits, and the state becomes the same as when the derived transaction is aborted. That is, the derivative activation suspension control function 30
Is the system status DB8 during the output processing of the derived message
With reference to the derivation abort bit of No. 3, if the derivation abort bit is ON, a derivation transaction which is an accompanying process is not started.

When the derivation stop bit is ON, the total amount control unit 79 receives the business process request, and if the business process request specifies stoppage during stay, the total amount control unit 79 A staying error control function 31 that disables the processing of the request and outputs an error may be provided. Referring to FIG. 13, as the operation environment specification, following the operation code, there is a specification such as stay = No, center batch = Yes. In the case where the derivation stop bit is ON when the processing of the operation code of “Stay = Yes” is requested in the operation environment specification, in the example including the stay-time error control function 31, the message is processed. Output an error as impossible.

<Derived Restart> Next, restart of a derived transaction will be described. The derived transaction is restarted afterwards when it is aborted, when a system failure occurs during execution of the derived transaction, or when the activation of the derived transaction is stopped. By clarifying the procedure for restarting the derived transaction, the actual atomicity of the derived use transaction using the derived start transaction and the derived transaction can be maintained.

Referring again to FIG. 7, the calculating means 4 refers to the derived index DB 68 and the derived management DB 70 and turns on the derived index bit and the busy flag.
And a derivation restart necessity monitoring unit 76 for judging a derivation management serial number that has passed a predetermined time or more after derivation start information is stored in the derivation management DB as a derivation restart necessary, and a derivation restart necessity monitoring When restarting the derivative management serial number determined to be necessary for restart by the unit 76, the derivative transaction is activated based on the derivative activation information specified by the derivative management serial number, and the derivative activation information is transmitted to the derivative management serial number. And a derived restart control unit 77 for updating the stored time.

First, the mode of the abort will be described. When the derived activation transaction is aborted, even if the derived activation information is once stored, the update is invalidated by rollback, so that the in-use flag of the derived management serial number is turned off. Therefore, the derived transaction does not start (FIG. 12, S74). Therefore, the abort of the derived start transaction does not require a restart of the derived transaction.

When the derived transaction aborts, even if the busy flag is updated to be usable, the update to the usable state is canceled by rollback.
Therefore, due to the atomicity of the derived transaction, when the derived transaction aborts, it is guaranteed that the busy flag is in use. Therefore, the derivation restart necessity monitoring unit 76 determines the derivation management serial number for which the derivation index bit and the busy flag are ON and the derivation management DB has stored the derivation start information in the derivation management DB for a predetermined time or more. It can be determined that activation is required. In the same manner as the determination based on the elapsed time after the start of the process is extremely effective in finding a deadlock, in the present embodiment, the determination of the abort of the derived transaction is performed by using the elapsed time after the entry of the derived activation information. To find the abort of the derived transaction.

In the termination processing of the derived transaction, when the derived index bit is executed in the derived DB control processing, when the derived DB control processing is aborted, the update of the busy flag by the derived transaction succeeds, and Since the commit has been performed, the in-use flag is off, and the derived index bit is on. In this case, it is not necessary to restart the derived transaction because the contents of the associated business of the derived transaction have been committed normally.

When restarting the derived management serial number determined to be necessary for restart by the derived restart necessity monitoring unit 76, the derived restart control unit 77 adds the derived start information specified by the derived management serial number. A derived transaction is activated based on the information, and the time at which the derived activation information is stored in the derived management serial number is updated. In the present embodiment, instead of performing the automatic restart, the existence of the aborted derived transaction is displayed to the operator, and the restart processing is performed after the restart request from the operator. At this time, the derived restart control unit 77 updates the entry time when the derived transaction is restarted.

FIG. 21 is a block diagram showing a configuration in which re-execution of a derived transaction is performed by a derived management task. When the derivation re-execution request 90 is received from the console terminal 2A, the command is analyzed, and it is determined whether to restart a specific derivation transaction or collectively restart all aborted derivation transactions. When restarting one derived transaction specified by the derived management serial number, the derived management business 92 specifies the FIFO stored in the derived management DB from the derived management serial number, and then uses this FIFO as the FIFO of the derived management business 92. Set to Then, a derivative transaction activation process is performed based on the FIFO of the derivative management task. Derived passive business 9
As 3, the derived transaction is restarted.

When restarting all the transactions, the derivation management business 92 activates a predetermined number of derivation transactions, and in a form as shown in FIG.
The derivative management task 95 is derived and activated. Derivation management work 95
Also, when a predetermined number of derivative transactions are activated, the derivative management task is activated as a derivative transaction. Each derivation management task performs only a predetermined number of restarts because the number of derivation transactions that can be started from one JOB number is the number of derivation management serial numbers M (for example, 400+ This is because it is limited to the following.

FIG. 22 is a flowchart showing the detailed configuration of the derivation restart necessity determination processing by the derivation restart necessity monitoring unit 76. This derivation restart necessity determination process is a process of monitoring whether there is a derivation transaction that has been aborted and needs to be restarted. This derivation restart necessity determination processing is executed by a command input from the console terminal 2A. Alternatively, it may be automatically started at a fixed time interval. When the processing is executed by inputting a command, the processing is executed before the date is changed or before the end time of a certain process. Further, when the transaction is aborted, a message to that effect is displayed on the console terminal 2A. In the case of a banking system, for example, the transfer process to another financial institution must be completed by a certain time. By executing the judgment processing, the existence of the aborted derived transaction is confirmed. For example, the above-described approval notification process uses a derived transaction, but confirms that the derived transaction has not been aborted. In addition, when the date is changed, it is necessary that there is no derivative transaction (accompanying process) requiring a restart. Therefore, before the date change command is input, the derivative restart necessity determination process is started by inputting a command. Referring to FIG. 22, the derivation restart necessity monitoring unit 76 first sets the target index area number to 0 (step S91). Subsequently, the index bitmap of the derived index DB 78 is read in the "read only" mode (step S92). This is to prevent the occurrence of contention on the index bitmap with the normal derived start transaction. Subsequently, the position of the index bit is set to the head (first) (step S93). Then, the bit at the set position is read, and it is determined whether or not the derived index bit is ON (in use) (step S9).
4). If the derived index bit is ON, the content of the derived management DB is read (step S95). And
With reference to the entry time of the derivative activation information, it is determined whether 30 seconds or more have elapsed from the derivative transaction activation time (step S96). If 30 seconds or more have elapsed, it is checked whether the re-derivation unnecessary bit is ON or whether the in-use flag of the derivation management DB is available (0) (step S97A). The re-derivation unnecessary bit is turned ON, for example, in the terminal return continuous processing. Derived index bit is in use and in use flag in derivation management DB is OFF
Since the derived transaction commits and the derived DB control process aborts, it is not necessary to restart the derived transaction. Step S97A
If the answer is no, it is determined that re-derivation is necessary for the derived transaction started with the derived management serial number, and the derived management serial number, the identification code of the startup business, the operation code of the derived passive business, the The entry date and time of the start-up information, the input store number and terminal number of the initial business process request, and the store number and account number of the account for the derivative transaction are output (step S97B). With reference to the re-derivation related information, the operator determines whether to restart the derived transaction managed by the derivation management serial number.

If the derived index bit is OFF (step S94, NO), or if it is ON but not more than 30 seconds from the derivative transaction start time (step S96, NO), steps S98A, S98
The next index bit (the next derivative management serial number) is determined via B. And 30 from the derivative transaction start time
Even if more than one second has elapsed, the re-derivation unnecessary bit is ON or if the derived transaction has been committed but the derived DB control processing has been aborted (derivation management DB
Also, when the in-use flag of 70 is usable (step S97A, Yes), the next index bit is determined. In step S98A, it is determined whether or not the index bit position is at the end. If not the last position,
The next derivation management serial number corresponding to the next derivation management number is set as a processing target by shifting the bit position by one (step S98B), and step S98 is performed.
Move the process to 94. On the other hand, if the position of the index bit is the last, the index region number corresponding to the next region is set as a determination target by adding 1 to the target index region number, and the process proceeds to step S92. On the other hand, if the search of all index areas (regions) has been completed in step S99A, the derivative restart necessity determination processing ends.

FIG. 23 is a flow chart showing an example of a process for sequentially restarting all the aborted or aborted derivative transactions with a single command. In the example illustrated in FIG. 23, the derived restart control unit 77 first sets 0 as the target index area number at the time of the first startup (step S101). Next, a search is made for a bit position being used in the index bitmap of the target index area number (step S102). If there is a bit being used, a derivation management serial number is calculated from the target index area number and the bit position, and the content stored in the derivation management DB is read (step S103). Then, it is determined whether or not the in-use flag is ON (in use) and five minutes or more have elapsed since the activation time of the derived transaction (entry time of the derived activation information) (step S104). If five minutes or more have not elapsed, a search is made for a derived index bit that is being used next (step S102).

The in-use flag of the derivation management DB is “in use”
If 5 minutes or more have passed since the entry of the derivative activation information, the activation of the derivative transaction is controlled based on the derivative activation information stored in the derivative management DB 70 (step S105). Specifically, derivation management D
The FIFO stored in B70 is set, and the derivation management DB
A derived message is generated from the FIFO in accordance with the derived edit number stored in 70. When the derived activation control is performed,
Increment the number of re-derivation processes (step S10)
6). Then, the derivative transaction start time is changed to the current time, and the derivative management DB is updated. Subsequently, a search is made for the next in-use index bit (step S102). When all the index bitmaps of the target index area number have been confirmed (step S102), 1 is added to the target index area number and set in order to examine the next derived index bit (step S10).
8). At this time, if the number of re-derivation processes (the number of activated derivation transactions) exceeds a certain number (for example, 80), the number of re-derivation processes is cleared to 0, and the derivation restart process is defined as a derivation transaction. Activate (step S111). In the restarted derivation restart process, since it is not the first start, the process skips step S101 and considers restarting the derivation transaction of the index bitmap of the set index area number.

If the number of re-derivation processes does not exceed a certain number in step S108, it is confirmed whether or not the search for all index area numbers (index bitmaps) has been completed (step S110). If an unexamined index bitmap remains, 1 is added to the target index area number, and step S102 is performed.
Transfer processing to As a result, it is possible to search all index bitmaps for aborted derived transactions.

As described above, according to the second embodiment, the derivative index DB can be accessed for each JOB number, and the derivative activation information is stored in the derivative management DB. It is possible to manage the characteristics of the derived transaction using a general DB locking mechanism while preventing tension, preventing the occurrence of deadlock, and eliminating the need to reorganize the derived management DB.

[0186]

Third Embodiment In the derived characteristic management common process shown in FIG. 12, if step S79 is a process in a derived transaction, deadlock may occur. This deadlock can be avoided by the way the program is constructed, but the matters that the programmer of the application program should pay attention to in order to avoid the deadlock are complicated. For this reason, the third embodiment discloses, as an extension of the second embodiment, a mechanism that can avoid the occurrence of a deadlock while using a derived DB. Specifically, step S79 is executed as a transaction (derived DB control processing) different from the derived transaction.

FIG. 24 is a block diagram showing the configuration of the present embodiment. The online system shown in FIG.
Receiving means 2 for receiving a business processing request input from the terminal 1A such as the M and the branch office terminal 1B via the network, and receiving a business processing request (command) input from the console terminal 2A; 2 comprises a computing means 4 for processing the business processing request received at 2 as an online transaction, and a file 6 for recording the result of the business processing request by the calculating means 4.

The file 6 records, for each of the derivation management serial numbers, the derivation start information of the online transaction or a derivation transaction started as a part of the execution of the derivation start transaction which is a predetermined derivation transaction. A derivation management DB 70 having an in-use flag indicating whether or not is in use;
The derivation management serial number in the derivation management DB 68 specifies a usable derivation management serial number from a plurality of derivation management serial numbers in units of the JOB number of the transaction, and a derivation indicating whether or not the derivation management serial number is in use. And a derived index DB 68 having a plurality of index bits for each JOB number. The configurations and roles of the derived index DB and the derived management DB 70 are the same as in the second embodiment. Therefore, in a preferred example, JO
An index bitmap is specified from the B number, and a usable derivation management serial number (bit position of a derived index bit) is specified with reference to the index bitmap.

In the example shown in FIG. 24, the operation means 4 comprises a business main processing unit 100 for managing the execution of a program constituting the transaction in accordance with an operation code for specifying the type of the online transaction or the derived transaction, A job processing unit 110 for executing a program called by the main processing unit 100; Here, the configuration of the arithmetic unit 4 is divided into a function of a business main processing unit 100 that manages each program as a transaction and a business processing unit 110 that actually executes the program, according to the actual program distribution.

In the calculating means 4, the FP and the SA on the IMS
It is assumed that the IL provides various services. Upon receiving a business process request (input message), the message input means 8 (for example, a SAIL input interface) shown in FIG. Identify the table. In the present embodiment, the operation identification code and the input edit number are converted from the operation code. The input interface performs the specified editing of the data on the message according to the input editing definition table, and sets the edited data in the specified FIFO field. After completing the editing, SAIL calls the application program corresponding to the job identification code. In the present embodiment, a program called a task main common to all tasks is called.

As shown in FIG. 25, the business main processing section 100 executes a business main (1) start process. Then, for example, the application program is specified and called based on the operation code table as shown in FIG. FIG.
In the example shown in (1), the business main calls a derived activation APPL that is a part of the derived activation transaction. Then
The task processing unit 110 executes the derived activation APPL. During this execution, the business processing unit 110 inputs a derivation start request request (when using a macro, a derivation request macro) to the business main.

When the business main receives the derived activation request request, it calls the derived request common processing. That is,
The business main processing unit 100 includes a derivation request common process calling function 102 that executes a derivation request common process as a part of the derivation startup transaction when a derivation startup request request is received by executing the derivation startup transaction. The derivation request common process is, for example, the process illustrated in FIG. The business processing unit 110 includes a derivation request common processing function 112 that executes the derivation request common processing. The derivation request common processing function 112 may be implemented, for example, by the CPU shown in FIG.
This is realized by executing the derivation request common processing command 112A shown in FIG.

As shown in FIG. 25, when the derivation request common processing function 112 is called to start processing (1), the derivation request common processing function 112 executes the JOB of the transaction in the region where the derivation activation APPL 111A is scheduled. The number is specified (2), and the derived index DB is referred to (3). With this reference, the derivative management serial number of the derivative management DB is specified, and the derivative index bit is turned ON (in use) (4). Then, a derived management serial number is calculated from the bit position, and this is
Set to IFO (6). Then, the remaining number and the number of derived items in the derived index DB 68 are updated (7). Further, the derivative activation information is stored in the segment of the derivative management serial number, and the busy flag is updated to busy (8). And
The derivation request common process refers to the derivation stop bit stored in the system status DB 83, and if the derivation stop bit is OFF, inputs a derivation start request (derivation request macro) to SAIL (part of OS) (9). . Thereafter, the process returns to the business main (10). If the derivation stop bit is ON, the derivation start macro is committed without inputting the derivation request macro.

When the derivation request macro is output, SAIL
The interworking interface specifies a derived edit definition table from the passive business identification code / edit number specified by the startup business identification code / program. In the present embodiment, the passive work identification code and the derived edit number are converted from the operation code of the derived passive process (derived transaction). The interlocking interface performs the specified editing and sets the derived message on the derived starting business side FIFO in the derived message according to the derived editing definition table. Upon receiving the derived message, the interlocking interface specifies the derived editing definition table based on the starting business identification code, the passive business identification code, and the derived editing number on the input message.
The linking interface sets the data on the derived message to the specified FIFO field after performing the specified editing according to the derived editing definition table.
After this editing is completed, SAIL calls the business main. As a result, the processing of the derived transaction is started.
In the example shown in FIG. 25, the called business main executes the derived characteristic management common processing command 104A.

In the present embodiment shown in FIG. 25, the “derivative characteristic management common process 104A” is, for example, a portion of the process shown in FIG. 12 except for the process of updating the derived index bit to be usable. In the examples shown in FIGS. 24 and 25,
The business main processing unit 100 performs the derived characteristic management common processing 104
A derived characteristic management common processing function 104 for executing A is provided.

The derived characteristic management common processing function 104 is shown in FIG.
As shown in FIG. 5, when the derivation characteristic management common processing 104A is started (1), first, the derivation management DB is read using the derivation management serial number as a key value (2) to maintain seriality with the derivation start transaction. . If the derivation management information is successfully read, the in-use flag is checked. If the in-use flag is OFF, it is determined that the derived activation transaction has been aborted, and the business main is terminated without calling the derived passive APPL (4). On the other hand, if the in-use flag of the derived management serial number is being used, the derived passive business program corresponding to the operation code of the derived transaction is called and executed (4).

The business processing unit 110 executes the derived passive APPL, and upon completion, returns the processing to the business main. Derived characteristic management common processing is that after the derived passive APPL is completed,
The in-use flag of the derivation management DB is updated to off (6), and a predetermined derivation DB control process is started as a derivation transaction (7). SAIL outputs a derived message based on a predetermined edit definition with reference to the FIFO of the derived transaction. When a derived message is scheduled, a derived DB control process is executed.

The business processing unit 110 has a derived DB control processing function 114 for executing a derived DB control process for updating a derived index bit to usable as a separate transaction from a derived transaction.
The derived DB control processing function 114 is realized when the CPU executes the derived DB control processing command 114A. Derived DB
In the control processing 114A, first, the index area number and the bit position of the derived index DB 68 are calculated from the derived management serial number (2). Then, the index bitmap of the derived index DB 68 is read using the calculated index area number as a key value (3). continue,
The derivation management DB 70 is read using the derivation management serial number as a key value (4). By reading the derivation management DB, the seriality with the derivation characteristic management common process 112A is maintained. Then, it is determined whether or not the in-use flag of the derivation management DB is OFF.
The derived index DB is updated to FF (usable).

FIG. 26 is an explanatory diagram showing an example of a deadlock that may occur when the derived index bit of the derived index DB is turned off when the derived transaction is completed as a part of the derived transaction. That is, it is a diagram illustrating an example of a deadlock state that may occur when the derived DB control processing for specifying the derived management serial number using the derived index DB 68 is not a separate transaction from the derived transaction.

A deadlock occurs when two transactions wait for each other to complete processing.
For example, the transaction T1 reads DBx, locks it, and then tries to read the derived index DB68. On the other hand, after the transaction T2 reads the derived index DB 68 and locks it,
Next, it is assumed that DBx is to be read. When the transaction T1 attempts to read the derived index DB 68 and the derived index DB 68 is locked by the transaction T2, the transactions T1 and T2 are deadlocked.

In the example shown in FIG. 26, first, JOBFP0
00, a derived activation request is output, and the derived transaction T2 has been scheduled to JOBFP001.
In the transaction T2, although linked with another operation code, the linked DBx is read with the key y. After the interlocking process is completed, the transaction T2 is executed as a post-process of the derived transaction (derivative characteristic management common process).
The in-use flag of the derivation management DB is turned off, and the derivation index bit of the derivation index DB is turned off.
At this time, since the key value of the derived index DB is the index area number,
The number 0 is the key value. The key value (derivation management serial number) of the derivation management DB is set to 1 here.

During the processing of transaction T2, transaction T3 was scheduled in JOBFP000. In the transaction T3, the operation is linked to another operation code. However, in order to start the derived transaction at the link destination, the derived index DB is read with the key value being 0, and the derived start information is stored in the segment of the derived management serial number 1 in the derived management DB. In transaction T3, DBx is read after the interlocking process is completed.

Now, in transaction T2, DBx
After that, an attempt is made to read the derived index DB as the key value 0. In transaction 3, after reading the derived index DB, go to DBx.
For this reason, the interlocked passive processing is
After reading and locking Bx, derived index DB
If the transaction T3 reads the derived index DB at a timing before the data is read, a deadlock occurs. Transaction T3 is derived index D
After reading B, if the transaction T2 reads DBx at the timing before the interlocking process is completed and before reading DBx, deadlock occurs.

A method for completely preventing the occurrence of a deadlock is to perform no parallel processing, but this cannot be adopted. With respect to locks, in order to maintain serialization of parallelism, some transactions must follow a two-phase locking protocol: a phase to acquire a lock and a phase to release a lock. Therefore, once a lock is released, the transaction must not acquire the lock. According to the requirements of this two-phase locking protocol, one transaction must be aborted if a deadlock occurs.

A method of maintaining the parallelism while avoiding the deadlock is to adjust the lock order of the transactions. For example, if all transactions request locks in the same order, deadlock can be avoided. However, this is a severe limitation for programmers. Also, by acquiring all locks used by the transaction at the start of the transaction and then performing the actual processing, it is possible to avoid the occurrence of deadlock, but in this case, it becomes as close as possible to serial processing,
The benefits of parallel processing are reduced.

In order to avoid deadlock by using these standard techniques, "before linking to a linked passive process that may start a derived transaction, read the DB read after linking before linking" There is a need. This allows
The execution order is the same. If all the linked activation processes satisfy this condition, the occurrence of the deadlock shown in FIG. 26 can be avoided. However, it is difficult for the developer of the linked startup task to be conscious of observing the reading order of the DB because the burden is large.

For this reason, in the third embodiment, as the derived DB control processing, the processing of turning off the derived index bit of the derived index DB is a separate transaction. Therefore, in the derived characteristic management common processing, the derived index bit of the derived index DB is not updated. Therefore, it is not necessary to lock the DBx and the derived index DB within one transaction. The derived DB control process is performed in a derived DB (derived management DB).
No deadlock occurs because the database other than the index DB and the derived index DB) is not read.

Referring to FIG. 25 again, the derived transaction management method in the present embodiment will be described. The derived transaction management method executes the derived start transaction (derived start APPL 111A) and commits the derived start transaction without waiting for the commit of the derived transaction (derived passive APPL 113A) requested to be started by the derived start transaction. Derived startup transaction management process (100
A, 112A) and a derived transaction management process (derived characteristic management common process 1) for managing a derived transaction requested to be activated by the derived activation APPL 111A.
04A) and a derived DB management process (derived DB control process 114A) started as a derived transaction in the derived transaction management process.

[0209] The derivative activation transaction management step refers to the derivative index DB according to the JOB number of the derivative activation transaction as a part of the derivative activation transaction, and specifies the derivative management serial number of the derivative management DB. Derivation request common processing step of storing the derivation start information in the segment of the derivation management serial number, updating the index bit and the busy flag corresponding to the used derivation management serial number to "in use", and starting the derivation transaction (Derived request common processing 112
A) is provided.

When the derived transaction is activated and scheduled in the derived request common processing step 112A as a part of the derived transaction, the derived transaction management step uses the derived management serial number given to the derived transaction as a key. The derived management DB is read as a value, and if the in-use flag of the derived management serial number is in use, the derived passive business program corresponding to the operation code of the derived transaction is executed. Derivation management D
It further includes a derived characteristic management common processing step (derived characteristic management common processing command 104A) for updating the in-use flag of B to off and starting a predetermined derived DB control processing as a derived transaction. Since the index / bitmap is not updated in the derived characteristic management common processing step, the deadlock shown in FIG. 26 does not occur.

Then, the derived DB management step is performed in the aforementioned derived D
When the B control process is scheduled, the derived index of the derived index DB corresponding to the derived management serial number of the derived management DB in which the derived startup information for restarting the derived transaction including the derived passive business program is stored. A derived DB control processing step (derived DB control processing command 114A) for updating bits to be usable is provided.
In the derived DB control process, as one of them, only the update of the index / bitmap is performed, so that the lock of another transaction may be waited, but no deadlock occurs. In the example shown in FIG. 25, the derived DB control transaction by the derived DB control process reads the derived management DB 70 with the derived management serial number designated by the derived characteristic management common process 104A.
It has seriality with the derived characteristic management common processing 104A. In other words, the index / bitmap is updated after the derived characteristic management common process has successfully committed. Therefore,
Parallel processing does not result in loss of system consistency.

Further, as shown in FIG. 24, each component of the total amount control section 14 may be provided in the third embodiment. In the third embodiment, when the system load is large, the activation of the derived DB control process may be stopped, and the process of turning off the derived index bits collectively after the elimination of the stay may be performed.

In the third embodiment, the restart of the aborted derived transaction is the same as in the second embodiment. When the business main 100A and the derivation start APPL are aborted, both the in-use flag and the derivation index bit remain usable, and no derivation start request is made. When the abort is performed before the output of the derivation start request after the update of the derivation DBs 68 and 70 in the derivation request common process 112A, the in-use flag and the derivation index bit are updated, but the update is not performed by the rollback. It will be. And no derived transactions are scheduled.

After the derivation start request is output, the derivation request common processing 112A, the business main 100A, and the derivation start APPL
Even when 111A is a linked passive task and the process of the linked startup task after the linked return is aborted, there is no update of the derived request common processing to the DB due to rollback. However, derived messages may be scheduled. In this case, the derived characteristic management common processing 10
At 4A (3), the busy flag is checked. When the busy flag can be read, the derived start transaction is aborted. Therefore, the in-use flag that is not updated by the rollback is read. Therefore, in the derived characteristic management common process 104A (3), the in-use flag is “usable”, and thus the process is terminated without calling the derived passive APPL. In this case, there is no derived start transaction or derived transaction.

When the derivation start transaction commits, it is recorded in the derivation management DB with durability while the in-use flag is “in use”. Derived characteristic management common processing 10
In the case of 4A (1) to (5) and the abort of the derived passive APPL, the in-use flag of the derivation management DB remains in use, and the derivation index DB remains in use. After the derived passive APPL is completed, the derived characteristic management common process aborts after turning off the busy flag,
Further, when aborted during processing such as the derivation request common processing 112A for starting a derived transaction,
There is no update of the derived characteristic management common process by rollback. Therefore, the in-use flag remains in use (1).

After the derived characteristic management common processing commits,
It is assumed that the derived DB control processing has been aborted. In this case, the in-use flag is off. However, the derived index bit of the derived index DB remains ON. Thus, (1). In the case of aborted derived transaction, the derived transaction is not started. (2). The derived transaction has committed,
Derived passive APPL 113A and derived characteristic management common processing 10
If 4A aborts, both the busy flag and the derived index bit remain busy. (3).
When the derived transaction is committed but the derived DB control processing 114A is aborted, the in-use flag is available and the derived index bit is ON.

It is necessary to restart the derived transaction as described in (2). Is the case. Therefore, by searching for a process in which the in-use flag is ON and a predetermined time has elapsed since the start, it is possible to specify a derivative transaction for which the necessity of restart is to be determined. (3). In the case of the abort of the derived DB control processing 114A, the derived passive APPL
Since the derived characteristic management common process 104A has committed normally, there is no need to restart the derived transaction.

As described above, according to the present embodiment, it is possible to avoid a deadlock that occurs in a state where derivation and interlocking are intertwined in a complicated manner by the derivation DB control processing. Eliminates the need.

[0219]

According to the present invention, the present invention is divided into an online transaction which requires an online response and a derivative transaction which executes processing accompanying the online transaction. Therefore, processing necessary for an online response is processed as an online transaction, and associated processing not required for an online response is processed as a derived transaction. Therefore, the online transaction can be committed early. As a result, it is possible to process only ancillary business as a derived transaction afterwards while ensuring online responsiveness. Therefore, it is possible to perform a process parallel to the online transaction by using the derived transaction for the process that has been conventionally performed in the batch process. As described above, according to the present invention, by using the derived transaction model, online responsiveness can be improved while executing processing conventionally realized by batch processing or the like and processing that requires a large amount of processing as one transaction. It is possible to realize an online transaction control system that can secure the transaction. According to the present invention having the total amount control unit, when the number of transactions being executed becomes large in relation to the capacity of the system, activation of a derived transaction that does not require an immediate online response is limited, and the system load is reduced. Therefore, the priority is given to the processing of the online transaction, and the execution of the derived transaction can be leveled in time. As a result, complicated processing can be realized while always ensuring online responsiveness.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a configuration of an online transaction control system according to the present embodiment.

FIG. 2 is an explanatory diagram for explaining the nature of a derived transaction. FIG. 2A is a diagram showing an example in which a derived transaction activation request is issued from a derived activation transaction, and FIG. FIG. 2 is a diagram showing a case where the derived activation transaction is a linked transaction, and FIG.
(C) is a diagram illustrating an example in which a derived transaction requests activation as a derived transaction.

FIG. 3 is an explanatory diagram for explaining a terminal response and the like according to a usage method of a derived transaction, and FIG.
FIG. 3B is a diagram showing the case of the incidental work, and FIG. 3B is a diagram showing the case of the cancel / recut main.

FIG. 4 is an explanatory diagram showing an operation example of the cancellation / recut main;

FIG. 5 is an explanatory diagram showing an example in which a derived transaction is used in the terminal return continuous processing.

FIG. 6 is a flowchart illustrating an example of total transaction control.

FIG. 7 is a block diagram illustrating a configuration of a second embodiment.

FIG. 8 is an explanatory diagram illustrating a relationship between a job and a derived index DB and the like.

FIG. 9 is an explanatory diagram illustrating data items of a derived DB; FIG. 9 (A) is a diagram showing an example of items of a derived index DB; FIG. 9 (B) is an example of items of a derived management DB; FIG.

FIG. 10 is an explanatory diagram exemplifying a relationship among a job ID, an index area number of a derived index DB, a bit position, and a derived management serial number;
FIG. 10A is a diagram showing a relationship between a derived index DB read by a transaction executed by JOB ID000, its bit position, and a derived management serial number, and FIG. FIG. 10C is a diagram showing the relationship between the derived index DB read by the transaction executed with JOB ID 001, its bit position and the derived management serial number, and FIG. 10D is the derived management in this case. It is a figure showing the example of contents of DB.

FIG. 11 is a flowchart illustrating an example of a derived request management process for managing a derived transaction request.

FIG. 12 is a flowchart illustrating an example of a derived characteristic management process for managing the characteristics of a derived transaction.

FIG. 13 is a diagram showing an example of an operation code table. Here, an operation code table of an ordinary deposit is illustrated.

FIG. 14 is an explanatory diagram showing an example of processing in cancellation re-cut main. FIG. 14 (A) is a diagram showing an example of canceling electricity charge withdrawal (internal self-generation) by account processing. FIG.
(B) is a diagram showing the transition of the balance by the processing.

FIG. 15 is a diagram showing a FIFO in the process shown in FIG. 14;
It is explanatory drawing which shows the example of a transition and a derived message.

FIG. 16 is an explanatory diagram showing transition of FIFO and the like following FIG. 15;

FIG. 17 is an explanatory diagram showing an example of using a derived DB in the examples shown in FIGS. 14 and 15;

FIG. 18 is an explanatory diagram illustrating an example in which a job is separately allocated to a general transaction and a derived transaction.

FIG. 19 is a flowchart illustrating an example of a stay monitoring process.

FIG. 20 is a chart illustrating an example of a total amount control process for waiting for execution of a derived transaction;

FIG. 21 is a block diagram illustrating an example of a restart process of an aborted derived transaction;

FIG. 22 is a flowchart illustrating an example of a process of determining whether to restart a derived transaction.

FIG. 23 is a flowchart illustrating an example of a process of restarting a derived transaction.

FIG. 24 is a block diagram showing a configuration of a third embodiment;

FIG. 25 is an explanatory diagram illustrating a configuration of a derivation management process;

FIG. 26 is an explanatory diagram illustrating an example of a deadlock state that may occur when the derived DB control processing is not performed as another transaction;

[Explanation of symbols]

 2 Receiving unit 4 Computing unit 6 File 8 Message input unit 10 Online response unit 12 Derived transaction management unit 14 Total amount control unit 16 Transaction execution unit

Claims (25)

[Claims] 1. A receiving means for receiving a business processing request input from a terminal or the like via a network, an arithmetic means for processing the business processing request received by the receiving means, A file for recording a processing result, wherein the computing means causes the business processing request input from the terminal or the like to be processed as an online transaction and controls the output of the processing result as a response to the terminal. A derived transaction management unit that manages a derived transaction that is requested to be started as part of the execution process of the online transaction or a derived start transaction that is a predetermined derived transaction and that processes a subsidiary business related to business processing by the derived start transaction; The derived transa Deployment management unit, online transaction control system comprising the derivation startup control function to commit the derived start transaction without waiting for commit of the derived transaction. 2. A derived activation information storage control function for committing the derived activation transaction after storing the derived activation information relating to the activation request of the derived transaction in the file, and the derived activation transaction. If aborted, the serialization management function that controls not to start or commit the derived transaction, and if the derived transaction aborts after the derived startup transaction commits, 2. The online transaction control system according to claim 1, further comprising a derived restart control function for restarting the derived transaction. 3. The computer according to claim 1, wherein the calculating unit includes a total amount control unit that restricts activation of the derived transaction in accordance with a total amount of transactions whose execution is managed by the online response unit and the derived transaction management unit. The online transaction control system according to claim 1. 4. An execution status monitoring function for monitoring the total number of transactions waiting to be executed, and the total amount control unit includes: 4. The online transaction control system according to claim 3, further comprising a derivative activation transaction input interruption control function for interrupting the input of a business process request as a derivative activation transaction when it is determined that the number exceeds the number. 5. The total amount control unit, when the execution status monitoring function determines that the number of transactions waiting to be executed exceeds a predetermined second level number,
5. The online transaction control system according to claim 4, further comprising a derivative start suspension control function for suspending the start of the derived transaction in a state where the derived start information is registered in a file. 6. A receiving means for receiving a business processing request input from a terminal or the like via a network, an arithmetic means for processing the business processing request received by the receiving means, A file for recording a processing result, wherein the computing means causes the business processing request input from the terminal or the like to be processed as an online transaction and controls the output of the processing result as a response to the terminal. A derived transaction management unit that manages a derived transaction that is requested to be started as a part of execution processing of the online transaction or a derived startup transaction that is a predetermined derived transaction, and a transaction execution unit that executes the online transaction and the derived transaction The derivative transaction management unit, when the derivative transaction is activated, the derivative activation information storage control function for storing the derivative activation information related to the derivative transaction to be activated in the file, and the derivative activation information includes: A derivative activation management function for committing the derivative activation transaction without waiting for the commit of the derivative transaction after being stored in a file, and a serial control for controlling not to commit the derivative transaction when the derivative activation transaction is aborted. If the derived transaction aborts after the derived management transaction commits, the derived transaction is performed based on the derived start information in response to a predetermined derived restart request for the aborted derived transaction. And a derivation restart control function for restarting the Nzakushon, online system where the transaction execution section, and executes the associated operations associated with the business process request as the derived transaction. 7. The transaction execution unit, when intermediate data regarding business consistency is generated by execution of the derived startup transaction, stores the intermediate data in the file with durability. And determining and executing the intermediate transaction relating to business consistency caused by execution of the business processing request to maintain business consistency as the derived transaction. Item 7. An online system according to Item 6. 8. In the transaction execution unit, a main business transaction that processes a business processing request starts a derived transaction, and the derived transaction repeatedly starts the derived transaction until there is no more processing target. Repeating a dummy response to the terminal until the process is completed by repeatedly invoking, and after the process to be processed is completed by repeatedly invoking the derived transaction, the main business transaction returns a response to the terminal. Item 7. An online system according to Item 6. 9. A receiving means for receiving a business processing request input from a terminal or the like via a network, an arithmetic means for processing the business processing request received by the receiving means, An online transaction control method for managing transactions using the arithmetic means of an online transaction control system including a file for recording processing results, wherein a business process request input from the terminal or the like is executed as an online transaction. A step of, when the activation of the derived transaction is requested as a part of the online transaction execution processing, storing the derived activation information necessary for the activation of the derived transaction in the file; Wait for commit Committing the online transaction that has activated the derived transaction without starting the transaction, controlling the start or the commit of the derived transaction when the online transaction has aborted, and the derived transaction after the derived activated transaction has committed And restarting the derived transaction based on the derived activation information when is aborted. 10. A receiving means for receiving a business processing request input from a terminal or the like via a network, an arithmetic means for processing the business processing request received by the receiving means, An online transaction control program for managing a transaction using the arithmetic means of the online transaction control system including a file for recording a processing result, the program being stored in a recording medium. As a command to operate the arithmetic unit, a command to execute a business process request input from the terminal or the like as an online transaction; Derived tran A command for storing derived activation information necessary for activating a transaction in the file; a command for committing an online transaction that has started the derived transaction without waiting for execution start or commit of the derived transaction; and an abort of the online transaction. A command to control the start or the commit of the derived transaction if not, and a command to restart the derived transaction based on the derived start information if the derived transaction is aborted after the derived start transaction is committed. An online transaction control program characterized by comprising: 11. A receiving means for receiving a business processing request input from a terminal or the like via a network, an arithmetic means for processing the business processing request received by the receiving means, A file for recording a processing result, wherein the file includes: a derivation management DB that records derivation start information of the derivation transaction for each derivation management serial number; and a derivation management DB for each derivation management serial number that is a key of the derivation management DB. A derivative index DB for recording index information indicating whether the terminal is in use or not, wherein the arithmetic means causes a business process request input from the terminal or the like to be processed as an online transaction, and the processing result is transmitted to the terminal. An online response unit that controls output to a response to the online transaction or a predetermined A transaction management unit that manages a derived transaction that is requested to be activated as part of a raw transaction execution process, and that manages the online transaction, wherein the transaction management unit is configured to execute the online transaction or a derived transaction that is a derived transaction. A derivation management serial number specifying function of specifying index information of the derivation index DB when a request for starting a derivation transaction is made, and specifying a usable derivation management serial number of the derivation management DB based on the specified index information; Derivation start information relating to a request to start a derived transaction by the derived start transaction is stored in the segment of the derived management serial number specified by the derived management serial number specifying function. In both cases, the derived activation information storage control function activates the derived transaction after storing the derived activation information, and commits the derived activation transaction when each process of the derived activation transaction ends normally after storing the derived activation information. A derived startup transaction commit processing function to be performed; a seriality control function to start each processing of the derived transaction when the derived startup information is successfully read normally in a lockable state at the start of the derived transaction; A derivative transaction commit processing function of updating the derivative index DB and the derivative management DB to be usable with respect to the derivative management serial number used when each process of the derivative transaction has been normally completed, and committing the derivative transaction; An online transaction control system comprising: a derived restart control function for controlling a restart based on the derived start information stored in the derived management DB when a derived transaction is aborted. 12. The derivation start transaction is executed with any JOB number in a predetermined JOB number group, and the derivation index DB uses the JOB number of the transaction as an index area number serving as a key value. 12. The online transaction control system according to claim 11, wherein said index information is provided for each index area number. 13. The derivative index DB holds the index information as a bitmap for each index area number, and the derivation management serial number specifying function performs a function based on the index area number and a bit position of the bitmap. 13. The online transaction control system according to claim 12, further comprising a function of specifying a derivative management serial number of the derivative management DB. 14. The derivation index DB has a bitmap for each index area number as a derivation index bit, and the derivation management DB corresponding to a bit position of the bit in accordance with ON or OFF of the derivation index bit. Recording a use state, the derivation management DB has a use flag for recording the use state of the derivation management serial number as being used or available for each of the derivation management serial numbers, and the derivation management serial number specifying function is OFF. When the derived index bit and the available derivative management serial number are identified, the derived index bit is updated to ON indicating that the derived index bit is being used, and the derived activation information storage control function performs the derived activation. When the information is stored, the used flag of the derivative management serial number is updated to “in use”, and the When the in-use flag of the derivation management serial number passed from the derivation start transaction is usable, the serialization control function terminates the process without starting the derivation transaction requested to be started, 14. The online transaction control system according to claim 13, wherein the commit control function updates the derived index bit and the in-use flag to usable at or after completion of the derived transaction. 15. A receiving means for receiving a business processing request input from a terminal or the like via a network, a calculating means for processing the business processing request received by the receiving means, and a processing means for processing the business processing request received by the calculating means. A file for recording a processing result, wherein the file includes: a derivation management DB that records derivation start information of the derivation transaction for each derivation management serial number; and a derivation management DB for each derivation management serial number that is a key of the derivation management DB. A derived transaction that is requested to be started as part of execution processing of an online transaction or a predetermined derived transaction using an online transaction control system including a derived index DB that records index information indicating whether or not it is in use A derivative transaction management method for managing When there is a request to start a derived transaction from a derived startup transaction that is an in-transaction or a derived transaction, the index information of the derived index DB is specified, and the derived management DB becomes usable based on the specified index information. Derivation management serial number specifying step for specifying the derived management serial number, and the derived startup information related to the derived transaction start request request by the derived startup transaction is stored in the segment of the derived management serial number specified in the derived management serial number specifying step. And a derivative activation information storage control step of activating the derivative transaction after storing the derivative activation information together with the derivative activation information. If each process of the derivative activation transaction ends normally after storing the derivative activation information, the derivative activation transaction is controlled. Derived startup transaction commit processing step for committing the transaction, and serialization control step for starting each processing of the derived transaction when the derived startup information is successfully read normally in a lockable state at the start of the derived transaction A derivative transaction commit processing step of updating the derivative index DB and the derivative management DB to be usable for the derivative management serial number used when each process of the derivative transaction has been normally completed, and committing the derivative transaction; A derivation restart control step of controlling a restart based on the derivation activation information stored in the derivation management DB when the derivation transaction is aborted. 16. A receiving means for receiving a business processing request input from a terminal or the like via a network, a calculating means for processing the business processing request received by the receiving means, and a processing means for processing the business processing request by the calculating means. A derivation management DB for recording derivation start information of the derivation transaction for each derivation management serial number, and a derivation management DB for each derivation management serial number serving as a key of the derivation management DB. A derived transaction that is requested to be started as a part of execution processing of an online transaction or a predetermined derived transaction using an online transaction control system including a derived index DB that records index information indicating whether or not it is in use Derived transaction management program that manages
When a request for starting a derived transaction is made from the derived transaction which is the online transaction or a derived transaction, the index information of the derived index DB is specified and stored on a recording medium, and the derivation is performed based on the specified index information. Management DB
Derivation management sequence number specifying command for specifying a usable derivation management sequence number, and derivation start information relating to a request for starting a derivation transaction by the derivation start transaction in the segment of the derivation management sequence number specified according to the derivation management sequence number specification command And a derivative activation information storage control command for activating the derivative transaction after storing the derivative activation information, and the derivative activation when each process of the derivative activation transaction ends normally after storing the derivative activation information. A derived activation transaction commit processing command for committing a transaction, and a seriality control command for starting each processing of the derived transaction when the derived activation information is successfully read normally in a lockable state at the start of the derived transaction And said A derivative transaction commit processing command for updating the derivative index DB and the derivative management DB to be usable with respect to the derivative management serial number used when each process of the derivative transaction is normally completed, and for committing the derivative transaction; A derivation restart control command for controlling a restart based on the derivation activation information stored in the derivation management DB when aborted. 17. A receiving means for receiving a business processing request input from a terminal or the like via a network, and a predetermined online transaction and a predetermined derivative transaction for processing the business processing request received by the receiving means. Calculating means for processing a number of job numbers in parallel, a file for recording the processing result of a business processing request by the calculating means, and a transaction scheduled to the job number of the calculating means are temporarily stored. A derivation management DB in which the file records the derivation start information of a predetermined derivation transaction for each derivation management serial number, and a derivation management DB for each derivation management serial number serving as a key of the derivation management DB. Derivation for recording index information indicating whether or not the job is in progress for each JOB number in the arithmetic means And a index DB, the queue, and the general queue for storing general transaction request for processing the business processing request temporarily,
A derivation queue for temporarily storing the derivation transaction request, wherein the arithmetic means causes a general transaction requested from the terminal to be processed as an online transaction and outputs the processing result as a response to the terminal An on-line response unit for controlling, and a transaction management unit for managing a derivation transaction requested to be started as a part of the execution processing of the on-line transaction or a predetermined derivation transaction; When the request for starting a derived transaction is made by J
Derivation activation information for identifying a usable derivation management serial number in the derivation management DB by referring to the derivation index DB according to the OB number, and storing derivation activation information of the derivation transaction in the segment of the derivation management serial number A storage control function, and a derivative activation transaction commit processing function of committing the derivative activation transaction without waiting for the commit of the activated derivative transaction after storing the derivative activation information by the derivative activation information storage control function, A calculating means for monitoring the number of transactions stagnating in the general queue and the derivation queue; and a derivation start-up in accordance with the number of stagnating transactions in each queue monitored by the detention monitoring part. Control the start of the transaction or the derivative transaction An online transaction control system, comprising: 18. The detention monitoring unit, when the number of detentions in the general queue or the derivation queue is equal to or higher than a predetermined first level, sets a derivation start transaction interruption bit to ON and outputs the derivation queue. If the number of transactions staying at the second level is greater than or equal to the first level and is greater than or equal to the second level that is set in advance, the derivation stop bit is turned on. Is ON
If the derivation start bit is ON, a derivation start transaction input interruption control function for interrupting the input of a business process request to activate the derivation transaction; 18. The online transaction control system according to claim 17, further comprising a derivation start suspension control function that does not start the derivation transaction after registering the derivation in the derivation management DB. 19. The total amount control unit, when the business process request is received when the derivation stop bit is ON, and when the business process request specifies stoppage during stay, the total amount control unit 19. The online transaction control system according to claim 18, further comprising a stay-time error control function for outputting an error by disabling the processing of the request. 20. Receiving means for receiving a business processing request input from a terminal or the like via a network, processing means for processing the business processing request received by the receiving means, and processing of the business processing request by the processing means. A file for recording a processing result, wherein the file records the derivation start information of the derivation transaction for each derivation management serial number and sets an in-use flag indicating whether or not each derivation management serial number is in use. A derivation management DB provided for each serial number, and a derivation index DB for recording index information indicating whether or not the derivation management DB is in use for each derivation management serial number serving as a key of the derivation management DB; Means for processing a business processing request input from the terminal or the like as an online transaction, and responding the processing result to the terminal. An online response unit that performs control to output the online transaction, and a transaction management unit that manages the online transaction or a derived transaction that is requested to be activated as part of execution processing of a predetermined derived transaction, and that manages the online transaction, The transaction management unit specifies a derivative management serial number that can be used in the derivative management DB based on the derivative index DB when a derivative transaction activation request request is issued from the derivative transaction that is the online transaction or the derivative transaction. A derivation management serial number specifying function for updating the specified index bit to ON; and a derivation start transaction for the derivation management serial number segment specified by the derivation management serial number specification function A derivation activation information storage control function for storing information relating to a derivation request request for a derivation transaction and the activation time as derivation activation information, and updating the in-use flag of the derivation management serial number to ON to activate the derivation transaction; Derived transaction commit processing function for updating the in-use flag of the derivation management DB and the index bit of the derivation index DB to usable for the derivation management serial number used when each processing of the transaction is completed normally, and committing the derivation transaction. The arithmetic means refers to the derivative index DB and the derivative management DB, indicates that the derivative index bit and the in-use flag are in use, and stores the derivative activation information in the derivative management DB, and is predetermined. More than time Online transaction control system comprising the derivative restart essential and determines a derived restart necessity monitoring unit derived management serial number you are. 21. When restarting the derivative management serial number determined to be necessary for restart by the derivative restart necessity monitoring unit, the arithmetic unit is configured to execute the restart based on the derivative start information specified by the derivative management serial number. 21. The online transaction control system according to claim 20, further comprising: a derivation restart control unit that activates a derivation transaction and updates a time at which the derivation start information is stored in the derivation management serial number. 22. A receiving means for receiving a business processing request input from a terminal or the like via a network, a calculating means for processing the business processing request received by the receiving means as an online transaction, and a business by the calculating means. A file for recording a result of the processing request, wherein the file is used for each of the derivation management serial numbers. A derivation management DB that records and has an in-use flag indicating whether the derivation management serial number is in use or available, and a derivation management serial number in the derivation management DB,
An available derivation management serial number is specified from a plurality of derivation management serial numbers in units of OB numbers, and a derivation index bit indicating whether or not the derivation management serial number is being used is indicated by the ON or OFF of the JOB number. A business main processing unit comprising: a plurality of derived index DBs, each of which includes a plurality of derived index DBs, wherein the arithmetic unit manages, as a transaction, execution of a program configuring the transaction in accordance with an operation code specifying the type of the online transaction or the derived transaction; A job processing unit that executes a program managed by the job main processing unit. The job main processing unit executes a derivation request common process when a derivation start request request is received by executing the program. Derived startup transaction that made the request A derivation request common process call function to be executed as a part, wherein the business processing unit refers to the derivation index DB according to a JOB number of the derivation start transaction when the derivation request common process is called, Derivation management serial number of the derivation management DB is specified, derivation start information is stored in the segment of the derivation management serial number, and the index bit and the in-use flag corresponding to the used derivation management serial number are updated to a used state. The business main processing unit includes a derivation request common processing function for activating the derivation transaction, wherein the business main processing unit performs the derivation given to the derivation transaction as a part of the derivation transaction whose activation is controlled by the derivation request common processing function. The derivation management DB is read using the management serial number as a key value, and the derivation management serial number is read. If the in-use flag is in use, the derived passive business program corresponding to the operation code of the derived transaction is executed, and after the derived passive business program ends, the in-use flag of the derivation management DB is updated to be usable. And a derivation characteristic management common processing function for starting a predetermined derivation DB control process as a derivation transaction. The business processing unit includes a derivation process including the derivation passive business program when the derivation DB control process is scheduled. A derived DB control processing function is provided for updating the derived index bit of the derived index DB corresponding to the derived management serial number of the derived management DB in which the derived activation information for restarting the transaction is stored to OFF indicating that the transaction can be used. A derived transaction management system, characterized in that: 23. The derivative DB control processing function, wherein the derivative index DB holds the derivative index bits as a bitmap in units of the JOB number and specifies the derivative management serial number at a bit position of the bitmap. Calculating the bit map and the bit position from the derivation management serial number. 24. A receiving means for receiving a business processing request input from a terminal or the like via a network, a calculating means for processing the business processing request received by the receiving means as an online transaction, and a business by the calculating means. A file for recording a result of the processing request, wherein the file is used for each of the derivation management serial numbers. A derivation management DB that records and has an in-use flag indicating whether the derivation management serial number is in use, and a plurality of derivation managements in which the derivation management serial number in the derivation management DB is set in units of the job number of the transaction Derivation management serial number that can be used from serial number A derived transaction management method for managing a derived transaction using the arithmetic means of an online system including a derived index DB having a plurality of derived index bits for each JOB number indicating whether or not a logical sequence number is in use. A derived start transaction management step of executing the derived start transaction and committing the derived start transaction without waiting for the commit of the derived transaction requested to be started by the derived start transaction; and a start request by the derived start transaction. A derived transaction management step of managing the requested derived transaction; and a derived DB management step started as a derived transaction in the derived transaction management step. The dynamic transaction management step refers to the derivative index DB according to the JOB number of the derivative start transaction as a part of the derivative start transaction, specifies the derivative management serial number of the derivative management DB, and Derivation start information is stored in the segment, and the index bit and the in-use flag corresponding to the used derivation management serial number are updated to a used state, and a derivation request common processing step of starting the derivation transaction is provided, The derivative transaction management step includes, when a derivative transaction is started and scheduled in the derivative request common processing step as a part of the derivative transaction, the derivative management serial number given to the derivative transaction is used as a key value. Read the DB and If the in-use flag of the raw management serial number is in use, a derived passive business program corresponding to the operation code of the derived transaction is executed, and after the derived passive business program ends, the in-use flag of the derived management DB is used. And a derivation characteristic management common processing step of starting a predetermined derivation DB control process as a derivation transaction, wherein the derivation DB management process is performed when the derivation DB control process is scheduled. Derived DB control for updating the derived index bit of the derived index DB corresponding to the derived management serial number of the derived management DB storing the derived startup information for restarting the derived transaction including the business program to OFF indicating that it is usable Derived transaction management characterized by processing steps Law. 25. A receiving means for receiving a business processing request input from a terminal or the like via a network, a calculating means for processing the business processing request received by the receiving means as an online transaction, and a business by the calculating means. A file for recording a result of the processing request, wherein the file is used for each of the derivation management serial numbers. A derivation management DB that records and has an in-use flag indicating whether the derivation management serial number is in use, and a plurality of derivation managements in which the derivation management serial number in the derivation management DB is set in units of the job number of the transaction Derivation management serial number that can be used from serial number Derived transaction management program for managing a derived transaction using the calculating means of an online system including a derived index DB having a plurality of derived index bits for each JOB number indicating whether or not a logical sequence number is in use Stored in a recording medium, and the derivative transaction management program is a command to be executed as a part of a derivative start transaction as a command for operating the arithmetic means, and is executed in accordance with a JOB number of the derivative start transaction. The derived index DB is referenced to specify the derived management serial number of the derived management DB, the derived startup information is stored in the segment of the derived management serial number, and the index bit corresponding to the used derived management serial number and the in use status are stored. Update flags to in-use status A derivative request common processing command that activates the derivative transaction, and a command that is executed as a part of the derivative transaction, wherein the derivative transaction is activated and scheduled according to the derivative request common processing command, The derived management DB is read using the derived management serial number given to the derived transaction as a key value, and when the in-use flag of the derived management serial number is being used, the derived passive business program corresponding to the operation code of the derived transaction is executed. After the derived passive business program is completed, the in-use flag of the derived management DB is updated to be usable, and a derived characteristic management common processing command for starting a predetermined derived DB control process as a derived transaction is further provided. Derived transaction that executes the characteristic management common directive And a derivation command corresponding to a derivation management serial number of a derivation management DB in which derivation start information for restarting a derivation transaction including the derivation passive business program is stored. A derivative DB control processing command for updating the derived index bit of the index DB to OFF indicating that the derived index bit is usable.