JP2015038641A - Transaction management program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technique for shifting only a transaction monitor from a general-purpose machine environment to an open environment while leaving the logic of applications on a general-purpose machine in environments of the transaction monitor before and after shifting.SOLUTION: A transaction management program according to the present invention secures a region for holding a communication session between an application program configured on the premise that the transaction monitor manages communication sessions and a client terminal, on a storage device. If the communication session is to continue, the transaction management program hands over communication session data in the region to a next transaction.

Description

  The present invention relates to a technique for calling an application program configured to be called via a transaction monitor on a general-purpose machine via another transaction monitor.

  Conventionally, general-purpose machines (also called mainframes, hosts, etc.) have been used in large-scale information systems such as enterprise mission-critical systems. However, as demands such as downsizing increase, it is required to migrate applications and middleware running on general-purpose machines to open systems such as UNIX servers.

  Some general-purpose machines include a transaction monitor that provides a transaction management function when accessing an application from the screen of a client terminal. If there is no open environment transaction monitor compatible with the transaction monitor on the general-purpose machine, it is necessary to migrate the application according to the specifications of the open environment transaction monitor.

  As a technique for shifting a general-purpose machine application to an open system, there is a technique for converting a COBOL application running on a general-purpose machine into a program used in an open system such as Java.

  In addition, Patent Document 1 below describes a technique that focuses on the screen configuration as a technique for shifting a mainframe application to an open environment. This document describes that a general-purpose screen form and general-purpose screen data are used to form a screen form that can handle a plurality of main frames.

JP 2004-355413 A

  Some transaction monitors on general-purpose machines have a function for managing a communication session between a client terminal and a general-purpose machine. Managing a communication session means, for example, that the communication connection is maintained as it is even after one round-trip communication between the client terminal and the general-purpose machine, and that the next communication is treated as continuing from the previous communication. This means managing the continuity of communication.

  However, not all transaction monitors have the communication session management function as described above, and there are transaction monitors that delegate the management of communication sessions to applications.

  In order to move from a transaction monitor on a general-purpose machine that manages communication sessions to an open environment transaction monitor that does not manage communication sessions, it is necessary to migrate applications according to the specifications for communication session management in the transaction monitor after migration. is there.

  In order to migrate an application using a transaction monitor on a general-purpose machine to an open system, it is necessary to reconstruct the application or convert a program as described above.

  However, rebuilding the application is costly and time consuming. Even if the program is converted, it is necessary to rewrite the logic on the program in the part linked with the transaction monitor due to the difference in the specifications of the transaction monitor, and not all of them can be automatically converted. When a programmer rewrites a program, it takes the same cost and time as rebuilding an application.

  The present invention has been made to solve the above-described problems. In the transaction monitor environment before and after the transition as described above, the transaction logic alone is used while leaving the application logic on the general-purpose machine. The purpose is to provide technology to shift from the machine environment to the open environment.

  The transaction management program according to the present invention secures an area for holding a communication session between a client terminal and an application program configured on the premise that the transaction monitor manages the communication session on the storage device. When continuing the communication session, the communication session data in the area is taken over to the next transaction.

  According to the transaction management program of the present invention, since the application program does not need to manage the communication session, it is not necessary to rewrite the application program in accordance with the transaction monitor after migration. Thereby, it is possible to move only the transaction monitor environment to the open environment without substantially changing the application program.

It is a figure which compares the operation | movement of the transaction monitor which operate | moves on a general purpose machine, and the operation | movement of the transaction monitor which operate | moves in an open environment. 1 is a diagram showing a configuration of a transaction management system 3000 according to Embodiment 1. FIG. It is a figure explaining the operation | movement sequence of the transaction management system 3000 which concerns on Embodiment 1. FIG. It is a figure which shows the structure of the transaction management system 3000 based on Embodiment 2, and the transaction management system 1000 in the general purpose machine environment before transfer. 6 is a diagram illustrating a configuration example of destination definition data 360. FIG. It is a figure explaining the operation | movement sequence of the transaction management system 3000 which concerns on Embodiment 2. FIG. It is a figure which compares the operation | movement of the transaction monitor which operate | moves on a general purpose machine, and the operation | movement of the transaction monitor which operate | moves in an open environment. FIG. 10 illustrates a configuration of a transaction management system 3000 according to a third embodiment. It is a figure explaining the operation | movement sequence of the transaction management system 3000 which concerns on Embodiment 3. FIG. FIG. 10 is a diagram illustrating an operation sequence of a transaction management system 3000 according to a fourth embodiment. FIG. 10 is a diagram showing a configuration of a transaction management system 3000 according to a fifth embodiment. It is a figure which shows the surrounding environment of the transaction management system 3000 which concerns on Embodiment 6. FIG.

<Differences in transaction monitor operation>
The present invention assumes an environment in which the operation of the transaction monitor differs depending on the individual transaction monitor and the configuration of the application program is different due to the difference. First, the difference in operation for each transaction monitor, which is the premise of the present invention, will be described. Thereafter, the configuration and operation of the transaction management program according to the present invention will be described.

  In the following description, for convenience of description, software such as a transaction monitor and a COBOL application program may be described as an operation subject, but the software is actually executed by a computer such as a general-purpose machine. I will add that.

  FIG. 1 is a diagram comparing the operation of a transaction monitor that operates on a general-purpose machine with the operation of a transaction monitor that operates in an open environment. FIG. 1A shows a transaction monitor operating on a general-purpose machine, and FIG. 1B shows a transaction monitor operating in an open environment.

  In FIG. 1A, the transaction management system 1000 includes a client terminal 110 and a general-purpose device 120. The general-purpose device 120 executes a first TP monitor (Transaction Processing Monitor) 130 and a COBOL program 150.

  The client terminal 110 requests the general-purpose device 120 to execute the COBOL program 150. The first TP monitor 130 on the general-purpose device 120 accepts the request, starts a transaction, and calls the COBOL program 150. The COBOL program 150 returns the execution result to the first TP monitor 130 via the TP monitor interface 160. The first TP monitor 130 transmits the execution result to the client terminal 110, and the transaction ends.

  When the communication session between the client terminal 110 and the general-purpose device 120 continues, the first TP monitor 130 stores the content of the communication session in the communication session database 140. When receiving the next request from the client terminal 110, the first TP monitor 130 reads the content of the previous communication session from the communication session database 140 and takes over the new request.

  In FIG. 1B, the transaction management system 2000 includes a client terminal 210 and a server 220. The server 220 is configured as an open system using UNIX or the like, and executes the second TP monitor 230 and the COBOL program 250.

  Here, regarding the management of the communication session, it is assumed that the operation of the first TP monitor 130 and the operation of the second TP monitor 230 are different. The second TP monitor 230 does not manage the communication session by itself, but delegates the management of the communication session to the COBOL program 250. Therefore, the COBOL program 250 must execute a process different from that of the COBOL program 150 in FIG.

  The client terminal 210 requests the server 220 to execute the COBOL program 250. The second TP monitor 230 on the server 220 receives the request, starts a transaction, and calls the COBOL program 250. The COBOL program 250 returns the execution result to the second TP monitor 230. The second TP monitor 230 transmits the execution result to the client terminal 210, and the transaction ends.

  When the communication session between the client terminal 210 and the server 220 continues, the COBOL program 250 stores the content of the communication session in the communication session database 240. When receiving the next request from the client terminal 210, the COBOL program 250 reads the contents of the previous communication session from the communication session database 240 and takes over the new request.

  As described above, when the transaction monitor operation is different, the operation of the COBOL program may be different. Therefore, when the transaction monitor is transferred to the open environment, there is a possibility that an operation such as rewriting the COBOL program in accordance with the environment after the transfer may occur.

  In the present invention, the COBOL program 150 in the general-purpose machine environment is used as much as possible to shift only the transaction monitor to the open environment.

<Embodiment 1>
FIG. 2 is a diagram showing a configuration of the transaction management system 3000 according to Embodiment 1 of the present invention. The transaction management system 3000 includes a client terminal 210 and a server 220. The server 220 executes the second TP monitor 230, the transaction management program 310, and the COBOL program 150. The transaction management program 310 creates and manages the communication session database 340.

  The communication session database 340 can be configured by storing communication session data that holds the contents of the communication session on a writable storage device such as an HDD (Hard Disk Drive) or a memory device.

  The client terminal 210 and the second TP monitor 230 are the same as those in the open environment described with reference to FIG. That is, it is assumed that the client terminal 210 executes the COBOL program 250 under the second TP monitor 230.

  On the other hand, the COBOL program 150 is the same as that in the general-purpose machine environment described in FIG. 1A except that the transaction management program 310 mediates between the COBOL program 150 and the second TP monitor. That is, it is assumed that the COBOL program 150 delegates communication session management to the transaction monitor and does not manage the communication session itself.

  In order to mediate the transaction management program 310, the part in which the COBOL program 150 calls the TP monitor interface 160 in FIG. 1A is rewritten in advance so as to call the interface of the transaction management program 310.

  As described above, the client terminal 210, the second TP monitor 230, and the COBOL program 150 have different specifications for communication session management. Therefore, in the first embodiment, the transaction management program 310 mediates both and manages the communication session.

  FIG. 3 is a diagram for explaining an operation sequence of the transaction management system 3000 according to the first embodiment. Hereinafter, each step of FIG. 3 will be described. For convenience of description, some components are omitted.

(FIG. 3: Step S301)
The client terminal 210 requests the server 220 to execute the COBOL program 150. At this time, it is assumed that the client terminal 210 calls a COBOL program that operates under the second TP monitor 230.
(FIG. 3: Step S302)
The second TP monitor 230 receives a request from the client terminal 210, starts a new transaction, and delivers the request to the transaction management program 310.

(FIG. 3: Step S303)
The transaction management program 310 calls the COBOL program 150. At this time, processing for absorbing differences caused by differences in transaction monitors, such as converting the parameter format of the request received from the client terminal 210, may be executed as appropriate.
(FIG. 3: Step S304)
The COBOL program 150 executes an application process defined by itself, and returns an execution result to the transaction management program 310 via an interface for calling the transaction management program 310.

(FIG. 3: Step S305)
If the request received from the client terminal 210 in step S301 is to maintain a communication session, the transaction management program 310 stores the content of the communication session in the communication session database 340 as communication session data. The communication session data here is data necessary for the continuation of the communication session, for example, an identifier of the communication session, input information on the previous screen, an intermediate result, and the like.
(FIG. 3: Step S305: Supplement)
In FIG. 3, the communication session data is stored in the communication session database 340 within this step for both round trips of the communication session. For example, for the uplink session, the communication session database 340 communicates between the steps S302 and S303. Session data may be stored. As long as the content of the communication session can be held, the execution timing of the process corresponding to this step may be arbitrary.

(FIG. 3: Steps S306 to S307)
The second TP monitor 230 receives the execution result of the COBOL program 150 and transmits it to the client terminal 210. When the second TP monitor 230 receives the next request from the client terminal 210, the second TP monitor 230 executes the same processing as that after step S301. However, when it is requested to maintain the communication session in the previous request, the previous communication session data is read from the communication session database 340, and the communication session data is taken over in the new request.

<Embodiment 1: Summary>
As described above, the transaction management program 310 according to the first embodiment stores the content of the communication session between the client terminal 210 and the server 220 as communication session data in the communication session database. As a result, the COBOL program 150 does not need to manage the communication session by itself. Therefore, even if the second TP monitor 230 does not manage the communication session, the application operation is configured on the assumption that the first TP monitor 130 manages the communication session. Can be executed. Further, it is not necessary to add a communication session management function to the COBOL program 150.

  Further, when the transaction management program 310 according to the first embodiment continues the request received from the client terminal 210 to the communication session in the previous request, the transaction management program 310 reads the corresponding communication session data from the communication session database 340, and newly Take over to a simple request. Thereby, an environment similar to that of the first TP monitor 130 that manages the communication session can be realized under the control of the second TP monitor 230 that does not manage the communication session.

<Embodiment 2>
In the second embodiment of the present invention, an environment is assumed in which external resources such as the client terminal 110 and the COBOL program 150 accessed by the first TP monitor 130 are defined as resource information.

  FIG. 4 is a diagram showing a configuration of the transaction management system 3000 according to the second embodiment and the transaction management system 1000 in the general-purpose machine environment before migration. Hereinafter, each configuration shown in FIG. 4 will be described.

  In FIG. 4A, the resource definition data 170 describes an identifier for uniquely identifying the client terminal 110, the COBOL program 150, and the like. For example, the COBOL program 150 is also described with its program name. The first TP monitor 130 reads the resource definition data 170 and uniquely identifies the client terminal 110, the COBOL program 150, and the like. Other configurations are the same as those in FIG.

  In FIG. 4A, the COBOL program 150 only has to deliver the execution result to the first TP monitor 130, and does not need to be aware of the destination type. The type of destination to which the execution result of the COBOL program 150 is to be transmitted is defined in the resource definition data 170. The first TP monitor 130 transmits the execution result of the COBOL program 150 to the client terminal 110 according to the description of the resource definition data 170.

  On the other hand, the second TP monitor 230 does not have a destination control function like the first TP monitor 130, and the destination control is delegated to the COBOL program 250. Therefore, the COBOL program 250 must execute a process different from that of the COBOL program 150 in FIG.

  The transaction management system 3000 in FIG. 4C uses destination definition data 360 to be described later in order to simulate the operation of the first TP monitor 130 managing the transaction destination using the resource definition data 170 in FIG. .

  In FIG. 4C, the transaction management system 3000 newly includes destination definition data 360 and a destination definition generation program 410 in addition to the configuration described in FIG. The destination definition generation program 410 is a program that reads the resource definition data 170 and generates destination definition data 360. The configuration of the destination definition data 360 will be described later with reference to FIG.

  FIG. 5 is a diagram illustrating a configuration example of the destination definition data 360. The destination definition data 360 is data that defines a correspondence relationship between each external resource under the first TP monitor 130 and each external resource under the second TP monitor 230.

  The destination definition data 360 holds a first transaction ID 361, a destination type 362, a second transaction ID 363, a program name 364, a conversation mode 365, and a call session buffer size 366.

  The first transaction ID 361 is a transaction ID used by the COBOL program 150 under the first TP monitor 130. The second transaction ID 363 is a transaction ID used by the client terminal 210 under the second TP monitor 230.

  The destination type 362 describes the destination type of the transaction identified by the first transaction ID 361 or the second transaction ID 363. For example, the destination type 362 of a transaction that calls the COBOL program 150 from the client terminal 210 is “COBOL program”. Similarly, the destination type 362 of the transaction for transmitting print data from the COBOL program 150 to the printer is “printer”. A destination address and the like can be described together with the destination type.

  The program name 364 is a program name for identifying the COBOL program 150. The conversation mode 365 indicates whether the transaction identified by the first transaction ID 361 or the second transaction ID 363 is a transaction that should hold a communication session. The communication session buffer size 366 indicates the size of a buffer area to be secured on the communication session database 340 for a transaction that should hold a communication session.

  FIG. 6 is a diagram for explaining an operation sequence of the transaction management system 3000 according to the second embodiment. Hereinafter, each step of FIG. 6 will be described. For convenience of description, some components are omitted.

(FIG. 6: Step S601)
The client terminal 210 requests the server 220 to execute the COBOL program 150. At this time, since it is assumed that the client terminal 210 calls a COBOL program operating under the second TP monitor 230, a request is issued by designating the second transaction ID assigned in accordance with the rules of the second TP monitor 230. To do.
(FIG. 6: Step S602)
The second TP monitor 230 receives the request from the client terminal 210 and the second transaction ID, and delivers the request to the transaction management program 310.

(FIG. 6: Step S603)
The transaction management program 310 refers to the destination definition data 360 using the second transaction ID 363 as a key, and acquires the corresponding first transaction ID 361. Further, the name of the COBOL program 150 to be called is acquired from the program name 364 and specified.
(FIG. 6: Step S604)
The transaction management program 310 starts a new transaction and calls the COBOL program 150 specified in step S603. The transaction ID specified at this time is the first transaction ID acquired in step S603.

(FIG. 6: Step S605)
The COBOL program 150 executes an application process defined by itself, and returns an execution result to the transaction management program 310 via an interface for calling the transaction management program 310. The transaction ID specified at this time is the first transaction ID used under the first TP monitor 130.
(FIG. 6: Step S605: Supplement)
In this step, the COBOL program 150 may start a new transaction in parallel with the transaction returned to the client terminal 210. Further, the destination of a newly started transaction may be a terminal other than the client terminal 210. The process in which each program processes a new transaction is similar to the following steps.

(FIG. 6: Step S606)
The transaction management program 310 inquires the destination definition data 360 using the first transaction ID as a key, and acquires the corresponding second transaction ID. Further, the type of the client terminal 210 to be called and the address thereof as necessary are acquired from the destination type 362 and specified.
(FIG. 6: Steps S607 to S609)
These steps are the same as steps S305 to S307 in FIG. As the transaction ID, a second transaction ID used under the second TP monitor 230 is designated.

<Embodiment 2: Summary>
As described above, in the second embodiment, the destination definition data 360 describes the first transaction ID 361 used under the first TP monitor 130 and the destination of the client terminal 210 to which the execution result of the COBOL program 150 is to be transmitted. The correspondence with the destination type 362 is described. As a result, the COBOL program 150 can execute the same operation as that for delegating the destination control of the transaction to the first TP monitor 130, so there is no need to add a destination control function to the COBOL program 150.

  In the second embodiment, the destination definition data 360 includes the second transaction ID 363 used under the second TP monitor 230 and the program name of the COBOL program 150 to be called under the transaction identified by the second transaction ID 363. Is described. Thus, the client terminal 210 can call the COBOL program 150 by specifying the second transaction ID used under the second TP monitor 230.

<Embodiment 3>
In the third embodiment of the present invention, an environment is assumed in which the first TP monitor 130 is responsible for the process of transmitting the execution result of the COBOL program 150 to the client terminal 110. On the other hand, the second TP monitor 230 is not responsible for transmitting the execution result of the COBOL program 250 to the client terminal 210, and assumes an environment in which the COBOL program 250 itself transmits the execution result to the destination.

  FIG. 7 is a diagram comparing the operation of a transaction monitor operating on a general-purpose machine with the operation of a transaction monitor operating in an open environment under the above assumption. FIG. 7A shows a transaction monitor operating on a general-purpose machine, and FIG. 7B shows a transaction monitor operating in an open environment.

  In FIG. 7A, the client terminal 110 specifies the first transaction ID used under the first TP monitor 130, and requests to execute the COBOL program 150. The first TP monitor 130 starts a new transaction and calls the COBOL program 150. The COBOL program 150 is not involved in the transaction and simply returns only its execution result to the first TP monitor 130. The first TP monitor 130 transmits the execution result of the COBOL program 150 to the client terminal 110 in accordance with the description of the resource definition data 170 described in the second embodiment.

  In FIG. 7B, the client terminal 210 specifies the second transaction ID used under the second TP monitor 230 and requests to execute the COBOL program 250. The second TP monitor 230 starts a new transaction and calls the COBOL program 250. The COBOL program 250 is responsible for the process of transmitting the execution result to the client terminal 210. Therefore, it is necessary to instruct a procedure for transmitting the execution result to the client terminal 210 from the COBOL program 250 to the second TP monitor 230.

  In the environment shown in FIG. 7A, the COBOL program 150 only has to return its own execution result to the first TP monitor 130, and the subsequent processing is delegated to the first TP monitor 130 and does not need to be involved. On the other hand, in the environment shown in FIG. 7B, the COBOL program 250 needs not only to execute its own application logic but also to a procedure with the client terminal 210.

  Therefore, in the environment shown in FIG. 7A, the transaction monitor alone cannot be transferred from the first TP monitor 130 to the second TP monitor 230, and the COBOL program must be rewritten in accordance with the second TP monitor 230 after the transfer. is there.

  Therefore, the third embodiment provides a technique for complementing parameters to be transferred between the COBOL program 150 and the second TP monitor 230 while using the COBOL program 150 in the general-purpose machine environment as much as possible.

  FIG. 8 is a diagram showing a configuration of a transaction management system 3000 according to the third embodiment. The transaction management system 3000 includes a transmission management area expansion module 370 and a transmission management area 380 in addition to the configuration described in FIG. 4C of the second embodiment. Other configurations are the same as those of the second embodiment.

  The transmission management area development module 370 designates a destination to which the execution result of the COBOL program 150 should be transmitted in place of the COBOL program 150 by using the value of the first transaction ID. The transmission management area development module 370 is configured as a program module, and writes the first transaction ID into the transmission management area 380. The transmission management area development module 370 is created in advance for each COBOL program 150. That is, the first transaction ID is fixedly embedded in the transmission management area development module 370, and the first transaction ID is written in the transmission management area 380 only by executing the transmission management area development module 370.

  The transmission management area 380 is a storage area configured on the memory of the server 220 by the transmission management area expansion module 370.

  Since the COBOL program 150 calls the transmission management area expansion module 370 before executing the application logic, a process for calling the transmission management area expansion module 370 before the part for calling the interface of the transaction management program 310 is executed in advance. It is assumed that it is embedded in the program 150.

  FIG. 9 is a diagram for explaining an operation sequence of the transaction management system 3000 according to the third embodiment. Hereinafter, each step of FIG. 9 will be described. For convenience of description, some components and steps are omitted.

(FIG. 9: Steps S901 to S902)
These steps are the same as steps S601 to S602 in FIG.
(FIG. 9: Step S903)
The transaction management program 310 inquires the destination definition data 360 using the second transaction ID 363 as a key, acquires the name of the COBOL program 150 to be called from the program name 364, and specifies it.

(FIG. 9: Step S904)
The transaction management program 310 starts a new transaction and calls the COBOL program 150. Since the COBOL program 150 only returns its own execution result, it is not necessary to specify the first transaction ID when calling the COBOL program 150.
(FIG. 9: Steps S905 to S906)
The COBOL program 150 calls the transmission management area development module 370 before executing the application logic. The transmission management area development module 370 writes the value of the first transaction ID in the transmission management area 380.

(FIG. 9: Step S907)
The COBOL program 150 executes an application process defined by itself, and returns an execution result to the transaction management program 310 via an interface for calling the transaction management program 310.
(FIG. 9: Step S908)
The transaction management program 310 acquires the value of the first transaction ID written in the transmission management area 380.

(FIG. 9: Step S909)
The transaction management program 310 refers to the destination definition data 360 using the first transaction ID acquired from the transmission management area 380 as a key, and acquires the corresponding second transaction ID. Further, the type of the client terminal 210 to be called and the address thereof as necessary are acquired from the destination type 362 and specified.
(FIG. 9: Steps S910 to S911)
These steps are the same as steps S305 to S307 in FIG. As the transaction ID, a second transaction ID used under the second TP monitor 230 is designated.

<Embodiment 3: Summary>
As described above, according to the third embodiment, the transmission management area development module 370 writes the first transaction ID corresponding to each COBOL program 150 in the transmission management area 380. The transaction management program 310 acquires the first transaction ID corresponding to the COBOL program 150 from the transmission management area 380. As a result, the COBOL program 150 only needs to return its own execution result to the transaction management program 310, so that it is not necessary to be involved in the procedure with the client terminal 210. Therefore, it is not necessary to rewrite the COBOL program 150 in accordance with the second TP monitor 230.

<Embodiment 4>
In the fourth embodiment of the present invention, an operation example for starting a new transaction in the COBOL program 150 will be described. Other configurations are the same as those in the first to third embodiments except that a printer 260 is newly provided. In the following description, an environment in which the configuration of the second embodiment is adopted is assumed.

  FIG. 10 is a diagram for explaining an operation sequence of the transaction management system 3000 according to the fourth embodiment. Hereinafter, each step of FIG. 10 will be described. For convenience of description, some components and steps are omitted.

(FIG. 10: Steps S1001 to S1004)
These steps are the same as steps S601 to S604 in FIG.
(FIG. 10: Step S1005)
The COBOL program 150 starts a new transaction for requesting a print job to the printer 260. At this time, the transaction ID designated by the COBOL program 150 is set as the third transaction ID.

(FIG. 10: Step S1006)
The transaction management program 310 starts a new transaction and calls a COBOL program 151 that executes a print job. The transaction ID specified at this time is the third transaction ID specified in step S1005.
(FIG. 10: Step S1006: Supplement)
In this step and FIG. 10, the management of a new transaction is completed in the transaction management program 310 from the viewpoint of simplicity described. However, the processing is temporarily returned to the second TP monitor 230 and is managed under the second TP monitor 230. You may make it manage a new transaction.

(FIG. 10: Step S1007)
The transaction management program 310 queries the destination definition data 360 using the third transaction ID as a key, and acquires and specifies the name of the COBOL program 151 to be called.
(FIG. 10: Steps S1008 to S1009)
The transaction management program 310 calls and executes the COBOL program 151. The COBOL program 151 requests the printer 260 for a print job. The COBOL program 151 may return the result to the COBOL program 150 via the transaction management program 310 after the print job is completed. Further, the COBOL program 151 may execute a process for requesting a print job to the printer 260 as a new transaction via the transaction management program 310.
(FIG. 10: Steps S1010 to S1013)
These steps are the same as steps S605 to S609 in FIG.

<Embodiment 4: Summary>
As described above, in the fourth embodiment, the example of starting a new transaction from the COBOL program 150 has been described. Even in this case, by managing each transaction under the transaction management program 310, the COBOL program operating under the first TP monitor 130 can be operated under the second TP monitor 230 as in the first to third embodiments. Can do.

<Embodiment 5>
In the fifth embodiment of the present invention, data maps used internally by the first TP monitor 130 and the second TP monitor 230 will be described. The data map is, for example, a correspondence table that describes the correspondence between the components of the screen on the client terminal and each parameter in the transaction.

  Different transaction monitors may have different data map formats. Therefore, in the fifth embodiment, a data map conversion module 390 that absorbs these differences is newly introduced. Other configurations are the same as in any of the first to fourth embodiments. In the following, for simplicity of explanation, the configuration described in the first embodiment is assumed.

  FIG. 11 is a diagram showing a configuration of a transaction management system 3000 according to the fifth embodiment. The transaction management system 3000 includes a data map conversion module 390 and a data map conversion module generation program 420 in addition to the configuration described in FIG. 2 of the first embodiment. Other configurations are the same as those in the first embodiment.

  In FIG. 11A, the transaction management system 1000 in the general-purpose machine environment before the migration includes a first data map 131 under the first TP monitor 130. Similarly, in FIG. 11C, the transaction management system 3000 according to the fifth embodiment after the migration includes a second data map 231 under the second TP monitor 230.

  The data map conversion module 390 is a program module that mutually converts the data format of the first data map 131 and the data format of the second data map 231. The data map conversion module generation program 420 generates the data map conversion module 390 based on the description of the data defining the first data map 131 or its data format.

  When the transaction management program 310 receives a request based on the data format of the second data map 231 from the second TP monitor 230, the data map conversion module converts the data map format into the data format of the first data map 131. Ask 390. Similarly, when a request based on the data format of the first data map 131 is received from the COBOL program 150, the data map conversion module 390 is requested to convert the data map format to the data format of the second data map 231. .

<Embodiment 5: Summary>
As described above, according to the fifth embodiment, even if the data map format used by each transaction monitor is different, the data map conversion module 390 converts the data format each time. There is no need to rewrite the COBOL program 150 in accordance with the data format of the second data map 231 used by.

<Embodiment 6>
FIG. 12 is a diagram showing a peripheral environment of the transaction management system 3000 according to the sixth embodiment of the present invention. In the sixth embodiment, in addition to the configurations described in the first to fifth embodiments, a COBOL source code conversion program 430 for converting the COBOL program 150 is newly provided. Since the other structure is the same as that of Embodiments 1-5, description was abbreviate | omitted.

  The COBOL program 150 described in the upper part of FIG. 12 is source code before conversion. The COBOL source code conversion program 430 rewrites the part that calls the TP monitor interface 160 so as to call the COBOL source transaction management program 310. Further, a part for calling the transmission management area development module 370 is added to the execution start position of the program.

  The underlined portion in FIG. 12 is a portion rewritten by the COBOL source code conversion program 430. It is not always necessary to directly call the transaction management program 310 and the transmission management area development module 370, and these programs may be called indirectly via another external COBOL module. This external COBOL module may be generated by any program as appropriate.

  Note that the transaction management program 310 and the transmission management area expansion module 370 may be created in a program language in which the number of function arguments is fixed at the time of function creation, such as C language. In this case, the argument itself is packed into a data aggregate such as a structure so that an arbitrary number of arguments can be set to the transaction management program 310 and the transmission management area expansion module 370, and only this data aggregate is delivered. Good. As a result, there are no restrictions due to the uniqueness of the arguments. However, individual measures such as adding a variable that specifies the number of arguments included in the data structure are required. The argument “PrmCount” in the lower part of FIG. 12 is an argument for that purpose.

  The transaction management program 310 and the transmission management area expansion module 370 internally include an interface for calling from the converted COBOL program 150 or the external COBOL module. In the process of executing the COBOL program 150, the server 220 calls the transaction management program 310 and the transmission management area expansion module 370 by calling its internal interface.

  As described above, in the sixth embodiment, the example in which the COBOL program 150 is automatically converted so that the part that calls the TP monitor interface 160 calls the transaction management program 310 and the transmission management area expansion module 370 has been described.

  110: Client terminal, 120: General-purpose machine, 130: First TP monitor, 140: Communication session database, 150 and 151: COBOL program, 160: TP monitor interface, 170: Resource definition data, 1000: Transaction management system, 210: Client Terminal: 220: Server 230: Second TP monitor 240: Communication session database 250: COBOL program 260: Printer 2000: Transaction management system 310: Transaction management program 340: Communication session database 360: Destination definition data 370: Transmission management area development module, 380: Transmission management area, 390: Data map conversion module, 410: Destination definition generation program, 420: Tamappu conversion module generation program, 430: COBOL source code converter, 3000: transaction management system.

Claims (11)

A first request for calling an application program configured to be called via a first transaction monitor on a general-purpose machine is received from a client terminal, and the application program is received via a second transaction monitor different from the first transaction monitor. A program for causing a computer to execute processing for converting to a second request to be called,
The first transaction monitor is configured to manage a communication session between the client terminal and the general-purpose device, and the second transaction monitor is configured to manage a communication session between the client terminal and the computer. Configured to delegate to an application program,
In the computer,
Receiving the first request from the client terminal;
Securing a session data storage area for storing communication session data between the client terminal and the computer on a storage device;
A response step of calling the application program and transmitting the execution result to the client terminal;
When a communication session between the client terminal and the computer continues even after the response step, the communication session data is stored in the session data storage area, and when the next request is received from the client terminal, the communication session Reading the data and taking over the communication session to the next transaction;
A transaction management program. In the computer,
A destination definition reading step of reading destination definition data describing a correspondence relationship between a second transaction ID specified when the client terminal calls the application program via the second transaction monitor and an identifier of the application program; ,
Specifying the application to be called according to the description of the destination definition data when the second request is received from the client terminal by designating the second transaction ID;
The transaction management program according to claim 1, wherein: The destination definition data is
A correspondence relationship between a first transaction ID specified by the application program via the first transaction monitor and a destination to which the application program should send a transaction;
In the computer,
When the execution result is received by designating the first transaction ID from the application program, the application program executes a step of specifying a destination to which the transaction is to be transmitted in accordance with the description of the destination definition data. The transaction management program according to claim 2, wherein: In the response step, the computer is
Reading the first transaction ID from a storage area on the storage device in which the first transaction ID corresponding to the application program is written;
Identifying a destination to which the application program should send a transaction in accordance with the description of the first transaction ID and the destination definition data;
4. The transaction management program according to claim 2, wherein the transaction management program is executed. In the computer,
5. The step of accepting a transaction newly started by the application program called in the response step as a new transaction to be executed under the second transaction monitor is executed. 5. The transaction management program according to item 1. The first transaction monitor is configured to use a first data map describing a correspondence relationship between a parameter used by the client terminal and a parameter used by the first transaction monitor.
The second transaction monitor is configured to use a second data map describing a correspondence relationship between a parameter used by the client terminal and a parameter used by the second transaction monitor in a format different from the first data map. Has been
In the computer,
The transaction management program according to any one of claims 1 to 5, wherein a data map conversion step of mutually converting the first data map and the second data map is executed. A program that is called from the application program and causes the second computer to generate the destination definition data read by the transaction management program according to any one of claims 2 to 4 in the destination definition reading step,
In the second computer,
Reading resource definition data defining a correspondence relationship between the application program, the first transaction ID, and a destination to which the application program should send a transaction;
Generating the destination definition data according to a description of the resource definition data and a specification of a second transaction ID used by the second transaction monitor;
A destination definition generation program characterized in that A program that is called from the transaction management program according to claim 6 and that causes a third computer to generate a program module that causes the computer to execute the data map conversion step,
In the third computer,
Reading data defining the data format of the first data map or the first data map;
Generating a program module for dynamically converting the first data map into a second data map according to a description of data defining the first data map or a data format of the first data map;
A data map conversion module generation program characterized in that is executed. Processing for converting the application program configured to be called via the first transaction monitor on the general-purpose machine into an application program called via the second transaction monitor different from the first transaction monitor is performed on the fourth computer. A program to be executed,
In the fourth computer,
A process of calling an interface using the first transaction monitor in the application program.
A source code conversion program that rewrites the processing to call the transaction management program according to claim 1. Processing for converting the application program configured to be called via the first transaction monitor on the general-purpose machine into an application program called via the second transaction monitor different from the first transaction monitor is performed on the fourth computer. A program to be executed,
In the fourth computer,
A process for calling an interface that uses the first transaction monitor in the application program is rewritten to a process for calling a transaction management program according to claim 4,
Source code for adding a process for calling a program module for writing the first transaction ID to a storage area on a storage device in which the first transaction ID corresponding to the application program is written. Conversion program. The transaction management program according to any one of claims 1 to 6,
A destination definition generation program according to claim 7,
A data map conversion module generation program according to claim 8,
The source code conversion program according to claim 9 or 10,
A computer that executes each of the programs;
A transaction management system comprising:

Images