Computer system and access verification method

Abstract

To provide a computer system having high confidentiality during a program transition period.SOLUTION: A computer system comprises: an acquisition unit that acquires, from a first computer system, management information used for access verification of a resource referred to in a job step to which a program has been transferred from the first computer system; a changing unit that changes the management information acquired by the acquisition unit into management information usable in a second computer system; a storage unit that stores the management information changed by the changing unit; and a verification unit that performs access verification of the resource by using the management information on the resource referred to in the job step stored in the storage unit, in response to a request for execution of the job step with which the program transferred from the first computer system is associated.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention generally relates to techniques for performing access validation for resources referenced in a job step. [Background technology]

[0002] In recent years, an increasing number of users have been hoping to migrate their mainframe system program assets to open systems in order to make the most of the program assets stored in those systems.

[0003] In this regard, there is a technology that divides batch business programs executed in mainframe systems into program units corresponding to the job steps that make up a job, and sequentially ports the programs for each job step that have been modified to an open system (see Patent Document 1). [Prior art documents] [Patent documents]

[0004] [Patent Document 1] International Publication No. 2017 / 208409 Summary of the Invention [Problem to be solved by the invention]

[0005] In the access control of mainframe systems, when a job step program is executed, access verification of the program is performed. However, during the migration to an open system, the management information of the program on the open system becomes unknown, and access verification cannot be performed when the program is executed on the open system. In this state, there is a problem that a user who does not have the authority to execute the job step may mistakenly execute the job step.

[0006] The present invention has been made in consideration of the above points, and aims to propose a computer system etc. that can perform access verification of resources referenced in a job step in an open system. [Means for solving the problem]

[0007] In order to solve this problem, the present invention provides a second computer system, different from a first computer system, to which programs of a plurality of job steps are sequentially migrated, the second computer system comprising: a first computer system that is provided with management information used for access verification of resources referenced in each of a plurality of job steps and that performs access verification of the resources using the management information of the resources referenced in the job steps when executing any one of the plurality of job steps; an acquisition unit that acquires from the first computer system the management information used for access verification of resources referenced in the job steps whose programs have been migrated from the first computer system; a modification unit that changes the management information acquired by the acquisition unit to management information usable in the second computer system; a memory unit that stores the management information modified by the modification unit; and a verification unit that, in response to a request for execution of a job step associated with the program migrated from the first computer system, performs access verification of the resources using the management information of the resources referenced in the job steps stored in the memory unit.

[0008] According to the above configuration, for example, access verification of resources referenced in a job step executed on a second computer system during a program migration period can be realized, thereby maintaining confidentiality equivalent to that of the system environment of the first computer system. [Effects of the Invention]

[0009] According to the present invention, it is possible to realize a computer system that maintains high confidentiality during program migration. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiment. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 illustrates an example of a computer system according to a first embodiment. [Figure 2] FIG. 1 is a diagram illustrating an example of a hardware configuration of an open system according to a first embodiment. [Figure 3] FIG. 3 is a diagram illustrating an example of management information according to the first embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of migration history information according to the first exemplary embodiment. [Figure 5] FIG. 4 is a diagram illustrating an example of access history information according to the first exemplary embodiment. [Figure 6] 4A to 4C are diagrams illustrating an example of a program registration process and a program monitoring process according to the first embodiment. [Figure 7] FIG. 10 illustrates an example of a job execution process according to the first embodiment. [Figure 8] FIG. 10 illustrates an example of a job step execution process according to the first embodiment. [Figure 9] FIG. 10 is a diagram illustrating an example of access verification processing according to the first exemplary embodiment. [Figure 10] 10A to 10C are diagrams illustrating an example of management information change processing and management information change monitoring processing according to the first exemplary embodiment. [Figure 11] FIG. 10 is a diagram illustrating an example of a history reporter process according to the first embodiment. [Figure 12] FIG. 10 is a diagram illustrating an example of a migration history collection process according to the first exemplary embodiment. [Figure 13] FIG. 10 illustrates an example of an access history collection process according to the first embodiment. [Figure 14] FIG. 3 is a diagram illustrating an example of management information according to the first embodiment. [Figure 15] FIG. 10 is a diagram illustrating an example of authority type correspondence information according to the first exemplary embodiment. [Figure 16] FIG. 4 is a diagram illustrating an example of aggregation correspondence information according to the first exemplary embodiment. [Figure 17] FIG. 4 is a diagram illustrating an example of an error code according to the first embodiment. [Figure 18] FIG. 3 is a diagram showing an example of designated items according to the first embodiment. [Figure 19] FIG. 2 is a diagram illustrating an example of a history reporter according to the first embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] (I) First embodiment An embodiment of the present invention will be described in detail below, but the present invention is not limited to the embodiment.

[0012] In this embodiment, the open system generates management information to be used in its own system based on management information from the mainframe system (hereinafter referred to as "mainframe"). With this configuration, access verification can be performed when a job is executed, and confidentiality equivalent to that of the mainframe can be maintained even during migration simply by executing the existing business. Furthermore, this embodiment automatically supports mainframe-specific functions for which there are no alternatives in the open system.

[0013] Furthermore, when job-related programs are being gradually migrated from the mainframe to the open system, if the user wants to change management information on the mainframe side or organize users or user groups, they must check all related data on the open system side in addition to the related data on the mainframe side to prevent inconsistencies with programs and data that have already been migrated.

[0014] In this regard, in this embodiment, additions, changes, and deletions of management information on the mainframe side are reflected (synchronized) on the open system side. Synchronization is also confirmed when a job is executed on the open system side, and operation is performed according to the option (execution possible or not possible when there is a mismatch). In addition, in this embodiment, the migration history of management information and the access history of jobs and job steps executed on the open system during migration are recorded.

[0015] Migration history and access history make it easier to investigate the impact when changing permissions, easier to investigate the impact when reorganizing users and user groups, easier to identify the cause of inconsistencies in permissions, easier to identify the cause when an error occurs, and easier to predict concentrated access by analyzing access frequency.

[0016] Next, an embodiment of the present invention will be described with reference to the drawings. The following description and drawings are examples for explaining the present invention, and appropriate omissions and simplifications have been made for clarity of explanation. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural. In the following description, the same elements in the drawings will be denoted by the same numbers, and their description will be omitted as appropriate.

[0017] The designations "first," "second," "third," etc. in this specification are used to identify components and do not necessarily limit the number or order. Furthermore, numbers used to identify components are used in different contexts, and numbers used in one context do not necessarily indicate the same configuration in another context. Furthermore, this does not prevent a component identified by a certain number from also serving the function of a component identified by another number.

[0018] In FIG. 1, 100 indicates the entire computer system according to the first embodiment.

[0019] The computer system 100 is configured to include a mainframe 110, which is the source of the program migration, an open system 120, which is the destination of the program migration, and a management terminal 130. The mainframe 110, the open system 120, and the management terminal 130 are different computer systems, and are communicatively connected via a network 101. In this computer system 100, for example, of a plurality of programs related to business processing (e.g., batch processing) executed on the mainframe 110, migratable programs are migrated to the open system 120 first.

[0020] The mainframe 110 is a server device, a computer, etc., and includes a job execution control unit 111 and a batch execution program group 112. The open system 120 is a server device, a computer, a virtual machine, etc., and includes a batch execution control unit 121 and a batch execution program group 122. The management terminal 130 is a computer, a tablet terminal, etc., that includes IT system operations management software that performs integrated operation monitoring, infrastructure management, etc. of a company's IT systems. For example, management information 113 provided in the mainframe 110 and management information 123 provided in the open system 120 are managed via the management terminal 130.

[0021] More specifically, the mainframe 110 is connected so as to be accessible to a storage device that stores management information 113, and mainframe storage that stores migration history information 114, access history information 115, etc. The open system 120 is connected so as to be accessible to a storage device that stores management information 123, and open system storage that stores migration history information 124, access history information 125, etc.

[0022] Management information 113 is information for managing the authority used to verify access to resources related to batch processing executed by mainframe 110. Resources related to batch processing are resources to be protected in batch processing, such as users, datasets, volumes, storage pools, jobs, job classes, and programs. Management information 113 is configured to include a user registry 113A, a dataset registry 113B, a volume registry 113C, a storage pool registry 113D, a job registry 113E, a job class registry 113F, and a program registry 113G.

[0023] Management information 123 is information for managing authority used to verify access to resources related to batch processing executed by open system 120. Management information 123 includes a user registry 123A, a dataset registry 123B, a job registry 123E, and a program registry 123G.

[0024] The management information 113 of the mainframe 110 is migrated to the management information 123 of the open system 120 at an appropriate timing. Resources for which there is no corresponding function or alternative in the open system 120 are linked to the protection information of resources that can be migrated to the open system 120 according to the settings, in accordance with the security protection method of the mainframe 110. For example, the volume registry 113C and the storage pool registry 113D are aggregated into the dataset registry 123B. The job class registry 113F is aggregated into the job registry 123E. Details will be described later using Figures 7, 8, etc.

[0025] For example, the job execution control unit 111 executes batch processing (batch execution program group 112) in accordance with a job control statement (for example, a JCL (Job Control Language) file 116) that describes information such as the program to be executed and the disk to be accessed.

[0026] Batch processing consists of multiple jobs (JOB1, JOB2, ...) with a specified execution order, and each job consists of one or more job steps (STEP1, STEP2, ...) with a specified execution order. A "job" is the processing unit in batch processing, and a "job step" is the processing unit in a job.

[0027] A job step is completed by executing one program associated with that job step. A job is completed by sequentially executing the programs associated with each job step in the order of the job steps. A batch process ends when all jobs are completed. Note that a program may be associated with one job step or multiple job steps.

[0028] In this embodiment, the programs required to execute each job step of the batch processing are transferred to the open system 120 in order, starting with those that have been modified for execution on the open system 120 .

[0029] For example, the open system 120 registers the migrated program in a library that can be recognized by the batch execution control unit 121 (batch execution platform). The open system 120 automatically detects the program and requests the mainframe 110 to recognize it as a program that can be executed in the new environment.

[0030] When the mainframe 110 executes any of the batch processing jobs, among the job steps constituting the job, those for which the corresponding program has not been migrated to the open system 120 are executed in the mainframe 110, while those for which the corresponding program has been migrated to the open system 120 are executed in the open system 120.

[0031] FIG. 2 is a diagram showing an example of a hardware configuration (computer 200) related to the open system 120. As shown in FIG.

[0032] The computer 200 includes a processor 210 , a main memory device 220 , an auxiliary memory device 230 , an input device 240 , an output device 250 , and a communication device 260 .

[0033] The processor 210 is a device that performs arithmetic processing and is, for example, a central processing unit (CPU), a micro processing unit (MPU), a graphics processing unit (GPU), or an artificial intelligence (AI) chip.

[0034] The main memory device 220 is a device that stores programs, data, etc. The main memory device 220 is, for example, a ROM (Read Only Memory), a RAM (Random Access Memory), etc. The ROM is, for example, an SRAM (Static Random Access Memory), an NVRAM (Non Volatile RAM), a Mask ROM (Mask Read Only Memory), a PROM (Programmable ROM), etc. The RAM is, for example, a DRAM (Dynamic Random Access Memory).

[0035] The auxiliary storage device 230 is a hard disk drive, a flash memory, a solid state drive (SSD), an optical storage device, etc. The optical storage device is a compact disc (CD), a digital versatile disc (DVD), etc. The programs, data, etc. stored in the auxiliary storage device 230 are read into the main storage device 220 as needed.

[0036] The input device 240 is a user interface that accepts information from a user, and is, for example, a keyboard, a mouse, a card reader, a touch panel, or the like.

[0037] The output device 250 is a user interface that outputs various types of information (display output, audio output, print output, etc.). The output device 250 is, for example, a display device that visualizes various types of information, an audio output device (speaker), a printer, etc. The display device is an LCD (Liquid Crystal Display), a graphics card, etc.

[0038] The communication device 260 is a communication interface that communicates with other devices via a communication medium. The communication device 260 is, for example, a network interface card (NIC), a wireless communication module, a universal serial bus (USB) module, a serial communication module, etc. The communication device 260 can also function as an input device that receives information from other devices that are communicatively connected. The communication device 260 can also function as an output device that transmits information to other devices that are communicatively connected.

[0039] The functions of the computer 200 (such as the batch execution control unit 121, the batch execution program group 122, the acquisition unit 211, the change unit 212, the storage unit 213, the verification unit 214, and the output unit 215) may be realized, for example, by the processor 210 reading a program stored in the auxiliary storage unit 230 into the main storage unit 220 and executing it (software), or may be realized by hardware such as a dedicated circuit, or may be realized by a combination of software and hardware. Note that one function of the computer 200 may be divided into multiple functions, or multiple functions may be combined into one function. Also, some of the functions of the computer 200 may be provided as separate functions or may be included in other functions. Also, some of the functions of the computer 200 may be realized by another computer that can communicate with the computer 200. Also, each hardware component of the computer 200 may be one or more.

[0040] The acquisition unit 211 acquires, from the mainframe 110, management information used for access verification of a resource referenced in a job step in which a program has been migrated from the mainframe 110. The change unit 212 changes the management information acquired by the acquisition unit 211 to management information usable in the open system 120. The storage unit 213 stores the management information changed by the change unit 212. In response to a request for execution of a job step associated with a program migrated from the mainframe 110, the verification unit 214 performs access verification of the resource using the management information of the resource referenced in the job step stored in the storage unit 213. Output unit 215 When the device receives an instruction from the management terminal 130 specifying the resources and / or period that the user needs to check, it extracts the migration history information or access history information stored in the memory unit 213 in accordance with the instruction and outputs the extracted information.

[0041] Furthermore, in this embodiment, the management information 123 is read from the storage device and stored in the main storage device 220, and the migration history information 124 and the access history information 125 are read from the open system storage and stored in the main storage device 220. The information in the main storage device 220 and the information in the storage device are synchronized. The information in the main storage device 220 and the information in the open system storage are also synchronized.

[0042] FIG. 3 is a diagram showing an example of the management information 123 (management information table 300).

[0043] The management information table 300 is a table that stores information synchronized with the management information 123, and is a table that is stored in the main memory device 220. The management information table 300 stores records that include values ​​of multiple items that indicate the authority of resources related to jobs executed by the open system 120.

[0044] More specifically, when the open system 120 executes a job, a record in which information on a resource type indicating the type of resource related to the job, a resource name indicating the name of the resource, and an authority indicating the authority to operate on the resource are associated is stored in the management information table 300. Note that the management information table 300 may also include information on registered users, registration dates and times, etc.

[0045] FIG. 4 is a diagram showing an example of the migration history information 124 (a migration history table 400).

[0046] The migration history table 400 stores records including values ​​of a plurality of items that indicate the history of migration of management information.

[0047] More specifically, the migration history table 400 stores records in which management information (e.g., information indicating authority) of a resource at a migration source is associated with management information of a resource at a migration destination. The management information of the resource at a migration source is information on a resource type indicating the type of resource in the mainframe 110, a resource name indicating the name of the resource, the authority permitted to operate on the resource, a registered user indicating the user who registered the authority, and the registration date and time when the authority of the resource was registered. The management information of the resource at a migration destination is information on a resource type indicating the type of resource in the open system 120, a resource name indicating the name of the resource, the authority permitted to operate on the resource, a registered user indicating the user who registered (migrated) the resource, and the registration date and time when the authority of the resource was registered.

[0048] Note that the table that stores the information (migration history) acquired from the migration history information 124, that is, the table stored in the main storage device 220, may be similar to the migration history table 400, and therefore illustration and description thereof will be omitted.

[0049] FIG. 5 is a diagram showing an example of the access history information 125 (access history table 500).

[0050] The access history table 500 stores records including values ​​of a plurality of items indicating a history of accesses to resources of the open system 120. More specifically, the access history table 500 stores records in which the following information is associated: a date indicating the day when a resource of the open system 120 was accessed, a time indicating the time when the resource was accessed, an executed process indicating the process by which the resource was accessed, a resource type indicating the type of the resource, a resource name indicating the name of the resource, an accessing user indicating the user who accessed the resource, a result indicating the result of accessing the resource, and a reason indicating the reason for failure to access the resource.

[0051] Note that the table that stores the information (access history) acquired from the access history information 125, that is, the table stored in the main memory device 220, may be similar to the access history table 500, and therefore will not be illustrated or described here.

[0052] Next, the processing in the computer system 100 will be explained using Figures 6 to 13. First, the processing related to the migration of management information will be explained.

[0053] FIG. 6 is a diagram showing an example of a process (a program registration process and a program monitoring process) for transferring management information used for program access verification.

[0054] In S601, the open system 120 determines whether or not a newly added program exists. If the open system 120 determines that a newly added program exists, it proceeds to S602, and if it determines that a newly added program does not exist, it proceeds to S623.

[0055] In S602, the open system 120 acquires management information (program protection information) of the newly added program from the mainframe 110. For example, the open system 120 transmits information of the newly added program (for example, the program name) to the mainframe 110.

[0056] In S611, the mainframe 110 registers the program as a program migrated to the new environment based on the program information sent from the open system 120.

[0057] In S612, the mainframe 110 extracts the program protection information from the management information 113.

[0058] The process of extracting program protection information will now be described with reference to Fig. 14. For example, when program "PGM01" is migrated, record 1417 of program "PGM01" is obtained from program registry 113G as program protection information. Record 1417 contains information on resource type "PGM", resource name "PGM01", and authority "USE". Although not shown in the figure, record 1417 may also contain information such as the registered user and the date and time of registration.

[0059] In S613, the mainframe 110 transmits the program protection information extracted in S612 to the open system 120.

[0060] In S621, the open system 120 registers the program protection information sent from the mainframe 110 in the management information 123.

[0061] At this time, the open system 120 uses an authority type correspondence table 1500 shown in Fig. 15 to change the program protection information to a format (notation) usable by the open system 120. For example, when record 1417 is received as the program protection information, the open system 120 changes "USE," which indicates authority in the mainframe 110, to "ExecuteFile," which indicates the corresponding authority in the open system 120. Then, the open system 120 adds record 1427, which includes information on the resource type "PGM," resource name "PGM01," and authority "ExecuteFile," to the program registry 123G. Although not shown in the figure, record 1427 may also include information on the registered user and the date and time of registration.

[0062] In S622, the open system 120 records the migration history of the program protection information in the migration history information 124. For example, a record 401 including the program protection information before the change in the mainframe 110 (record 1417) and the program protection information after the change in the open system 120 (record 1427) is added to the migration history table 400.

[0063] In S623, the open system 120 waits for a certain period of time and then returns to S601.

[0064] In the above process, management information used for program access verification is migrated from the mainframe 110 to the open system 120. According to the above process, when the open system 120 executes a program migrated from the mainframe 110, the open system 120 can perform access verification of the program.

[0065] FIG. 7 is a diagram showing an example of a process (job execution process) for transferring management information used for job access verification.

[0066] In S701, the mainframe 110 extracts the programs to be used in the job steps of the job to be executed (target job).

[0067] In S702, the mainframe 110 determines whether all of the programs extracted in S701 have been migrated to the open system 120. If the mainframe 110 determines that all of the programs have been migrated, it proceeds to S705, and if it determines that at least one program has not been migrated, it proceeds to S703.

[0068] In S703, the mainframe 110 performs job step execution processing, which will be described later with reference to FIG.

[0069] In S704, the mainframe 110 performs job execution termination processing and ends the processing.

[0070] In S705, the mainframe 110 sends an execution request for the target job to the open system 120. For example, the execution request for the target job includes information used to execute the target job (for example, the JCL file 116, information for identifying the JCL file 116, or the resource name of the resource described in the JCL file 116).

[0071] In S711, the open system 120 obtains management information used for access verification of resources referenced in the job requested to be executed (executed job) from the mainframe 110 (old environment) and performs a conversion process to convert it into the format of the open system 120.

[0072] The conversion process will now be described. For example, for users and programs, the open system 120 leaves the permissions unchanged. For jobs and job classes, since there are no alternatives for the job class, the open system 120 applies the job class permissions to the job if the job has no protection setting or if the permissions are job ⊂ job class, and applies the job permissions as is if the permissions are job ⊇ job class. This process aggregates (integrates) the job class permissions and the job permissions. For datasets, volumes, and storage pools, the open system 120 aggregates the permissions of the datasets, volumes, and storage pools according to the aggregation correspondence table 1600 shown in FIG. 16. The open system 120 then converts the permissions after the conversion process into a format usable by the open system 120 using the permission type correspondence table 1500 shown in FIG. 15.

[0073] More specifically, the following example will be described in which the open system 120 receives a resource name (e.g., job name "JOB01," class name "A," user name "USER1," job step name "STEP1," program name "PGM01," and dataset name "DATAX") described in the JCL file 116. In this case, the open system 120 acquires, as management information linked to the resource name, record 1411 of the user registry 113A, record 1412 of the dataset registry 113B, record 1413 of the volume registry 113C for the volume in which the dataset with the dataset name "DATAX" is stored, record 1414 of the storage pool registry 113D for the storage pool to which the volume belongs, record 1415 of the job registry 113E, record 1416 of the job class registry 113F, and record 1417 of the program registry 113G.

[0074] For user authority, the open system 120 leaves record 1411 "WRITE". For dataset authority, the dataset authority is record 1412 "USE", the volume authority is record 1413 "NONE", and the storage pool authority is record 1414 "NONE", so the open system 120 aggregates them into the dataset authority "USE" in accordance with record 1610 of the aggregation correspondence table 1600. For job authority, the job authority is record 1415 "WRITE" and the class authority is record 1416 "USE", so the open system 120 determines that the authority is job name ⊇ job class and aggregates the job authority into "WRITE". For program authority, the open system 120 leaves record 1417 "USE".

[0075] Then, the open system 120 uses the authority type correspondence table 1500 to change the type of user authority to "Write", the type of dataset authority to "ExecuteFile", the type of job authority to "Write", and the type of program authority to "ExecuteFile".

[0076] In S712, the open system 120 determines whether the management information of the executed job is registered in the management information 123 of the open system 120 (new environment). For example, the open system 120 refers to the management information 123 and checks whether the job management information, user management information, dataset management information, and program management information are registered. If the open system 120 determines that the management information of the executed job is registered in the management information 123 of the new environment, it proceeds to S713, and if it determines that the management information of the executed job is not registered in the management information 123 of the new environment, it proceeds to S720.

[0077] In S713, the open system 120 acquires management information for the old environment of the job to be executed and management information for the new environment of the job to be executed, and performs conversion processing on the management information for the old environment in the same manner as in S711.

[0078] In S714, the open system 120 determines whether the management information (authority) of the old environment of the executed job matches the management information (authority) of the new environment of the executed job. If the open system 120 determines that the authorities of the old environment and the new environment match, it proceeds to S715, and if it determines that the authorities of the old environment and the new environment do not match, it proceeds to S722.

[0079] In S715, the open system 120 executes access verification processing. In the access verification processing, access verification for the job execution and access verification for the number of job steps included in the job execution are performed. The access verification processing will be described later with reference to FIG. 9.

[0080] In S716, the open system 120 determines whether there is a problem with the access verification. If the open system 120 determines that there is no problem with the access verification, it proceeds to S717, and if it determines that there is a problem with the access verification, it proceeds to S724.

[0081] In S717, the open system 120 executes the job (all job steps included in the job).

[0082] In S718, the open system 120 generates a result indicating that the job has been executed.

[0083] In S719, the open system 120 transmits the results of the job execution to the mainframe 110, and ends the process.

[0084] In S720, the open system 120 adds to the management information 123 the management information that has been converted in S711 and that has not been registered in the new environment.

[0085] In S721, the open system 120 records a migration history indicating that the management information has been migrated in the migration history information 124, and proceeds to S713. For example, when the open system 120 executes a job with the job name "JOB01" for the first time after migration and adds management information of the job to the management information 123, it adds a record (record 411) including management information of the job before the change in the mainframe 110 (record 1415) and management information of the job after the change in the open system 120 (record 1425) to the migration history table 400. At this time, the open system 120 also adds a record (record 412) including management information of the aggregated job class (record 1416) to the migration history table 400.

[0086] In S722, the open system 120 investigates the cause from the migration history information 124 and the access history information 125, and outputs a warning message.

[0087] If the permissions are changed in the new environment by an operation that does not remain in the history, or if the changes are made unintentionally, the information for the permissions of user "USER1" may become inconsistent between the old and new environments. For example, if the permission of "USER1" in the old environment is "WRITE" and the permission of "USER1" in the new environment is "Read," and the permissions in the old and new environments are different, the open system 120 searches the most recent migration history record 431 for "USER1." According to the migration history record 431, the permission of "USER1" was migrated with "WRITE" in the old environment and "Write" in the new environment, but is now "Read" in the new environment. Since the open system 120 cannot further investigate the cause of the inconsistency from the migration history information 124, it ends the migration history investigation here and displays a message like the following on the management terminal 130: >AUTHORITY MISMATCH:USER1 >USER USER1 WRITE USERA 20 / 12 / 10 09.11.00 USER USER1 Write USER1 23 / 11 / 20 09.10.00

[0088] Next, the open system 120 checks the latest access history of "USER1." The open system 120 extracts record 511 of the access history of the resource that "USER1" was able to access, and records 401 and 441 of the migration history of that resource, and displays them together on the management terminal 130 as shown below.

[0089] >23 / 11 / 28 09.15.00 STEP PGM PGM01 USER1 SUCCESS - >23 / 11 / 28 09.15.01 STEP DS DATAA USER1 SUCCESS - >23 / 11 / 28 09.15.01 STEP DS DATAB USER1 SUCCESS - >PGM PGM01 USE USERA 20 / 12 / 10 09.12.00 PGM PGM01 ExecuteFile USER1 23 / 11 / 20 09.10.00 >DS DATAA READ USERA 20 / 12 / 10 09.14.00 DS DATAA Read USER1 23 / 11 / 20 09.13.00 >DS DATAB READ USERA 20 / 12 / 10 09.15.00 DS DATAB Read USER1 23 / 11 / 20 09.13.00

[0090] Based on the above information, the user can narrow down the period in which the permissions of "USER1" in the new environment were changed and investigate system logs, etc. If the "Read" permission in the new environment is correct, for example, the user can perform synchronization processing to reflect the "Read" permission in the new environment, and by matching the information between the old and new environments, the error will no longer be output. Additionally, since the process for programs is the same as for users, a description of this will be omitted. Furthermore, because permissions are converted when management information is migrated for datasets and jobs, there may be a "mismatched but correct" state. This state is confirmed in S714, and processing proceeds to S722.

[0091] In S723, the open system 120 determines whether or not there is an execution prohibition setting. If the open system 120 determines that there is an execution prohibition setting, it proceeds to S724, and if it determines that there is no execution prohibition setting, it proceeds to S715. For example, if the user does not have sufficient authority, an error occurs in the access verification process even if there is no execution prohibition setting.

[0092] In S724, the open system 120 sets an error code and moves the process to S719. For example, if the result of the access verification is NG, the open system 120 sets the error code in FIG. 17 indicating the result. More specifically, if the determination in S714 is NO (if the result of the access verification is "authority information does not match between the old environment and the new environment"), the open system 120 sets the error code "X24" corresponding to "authority information does not match between the old environment and the new environment", generates the result ">FAILED-X24 AUTHORITY MISMATCH:USER1", and moves the process to S719.

[0093] 8 is a diagram showing an example of the job step execution process. In the job step execution process, the mainframe 110 performs the processes of S801 to S803 for all job steps.

[0094] In S801, the mainframe 110 determines whether all programs used in the job step to be processed have been migrated. If the mainframe 110 determines that all programs have been migrated, it proceeds to S805, and if it determines that at least one program has not been migrated, it proceeds to S802.

[0095] In S802, the mainframe 110 executes the job step to be processed. In this embodiment, the mainframe 110 has management information used for access verification of resources referenced in each of the multiple job steps. When executing one of the multiple job steps, the mainframe 110 performs access verification of the resource using the management information of the resource referenced in that job step. For example, the mainframe 110 performs access verification of the program using management information of the program associated with that job step.

[0096] In S803, the mainframe 110 generates a result indicating that the execution of the job step being processed has been completed.

[0097] In S804, the mainframe 110 performs processing to end the execution of the job step, and then ends the processing.

[0098] In S805, the mainframe 110 sends an execution request for the job step to be processed to the open system 120. For example, the execution request includes information used to execute the job step to be processed (e.g., the JCL file 116, information for identifying the JCL file 116, or the resource name of the resource described in the JCL file 116).

[0099] In S811, the open system 120 acquires management information for resources referenced in the job step for which execution has been requested (executed job step) from the mainframe 110 (old environment) and performs conversion processing to convert the information into a format suitable for the open system 120. Note that the conversion processing is the same as in S711, and therefore a description thereof will be omitted.

[0100] In S812, the open system 120 determines whether the management information of the executed job step is registered in the management information 123 of the open system 120 (new environment). If the open system 120 determines that the management information of the executed job step is registered in the management information 123 of the new environment, it proceeds to S813, and if it determines that the management information of the executed job step is not registered in the management information 123 of the new environment, it proceeds to S820. Here, the open system 120 checks whether the user management information, dataset management information, and program management information are registered. Note that whether the job management information is registered is checked during job execution processing.

[0101] In S813, the open system 120 acquires management information for the old environment of the job step being executed and management information for the new environment of the job step being executed, and performs conversion processing on the management information for the old environment of the job step being executed in the same way as in S811.

[0102] In S814, the open system 120 determines whether the management information (authority) of the old environment of the executed job matches the management information (authority) of the new environment of the executed job. If the open system 120 determines that the authorities of the old environment and the new environment match, it proceeds to S815, and if it determines that the authorities of the old environment and the new environment do not match, it proceeds to S822.

[0103] In S815, the open system 120 executes access verification processing. In the access verification processing, access verification of the resource referenced in the executed job step is performed. The access verification processing will be described later with reference to FIG.

[0104] In S816, the open system 120 determines whether there is a problem with the access verification. If the open system 120 determines that there is no problem with the access verification, it proceeds to S817, and if it determines that there is a problem with the access verification, it proceeds to S824.

[0105] In S817, the open system 120 executes the job step.

[0106] In S818, the open system 120 generates a result indicating that the job step has completed execution.

[0107] In S819, the open system 120 transmits the results of the job step execution to the mainframe 110, and ends the process.

[0108] In S820, the open system 120 adds to the management information 123 the management information that is not registered in the new environment, out of the management information of the job steps determined in S812.

[0109] In S821, the open system 120 records the migration history of the management information added to the new environment in the migration history information 124, and proceeds to S813. For example, when the open system 120 adds management information (record 1422) of the dataset "DATAX" to the management information 123, it adds to the migration history table 400 a record (record 421) that includes the management information (record 1412) of the dataset before it was changed in the mainframe 110 and the management information (record 1422) of the dataset after it was changed in the open system 120. At this time, the open system 120 adds to the migration history table 400 a record (record 422) that includes the management information (record 1413) of the aggregated volume and a record (record 423) that includes the management information (record 1414) of the aggregated storage pool.

[0110] In S822, the open system 120 investigates the cause from the migration history information 124 and the access history information 125, and outputs a warning message. Note that the processing of S822 is similar to the processing of S722, and therefore a detailed explanation thereof will be omitted.

[0111] In S823, the open system 120 determines whether or not there is an execution prohibition setting. If the open system 120 determines that there is an execution prohibition setting, it proceeds to S824, and if it determines that there is no execution prohibition setting, it proceeds to S815.

[0112] In S824, the open system 120 sets an error code and moves the process to S819. Note that the process of S824 is the same as the process of S724, and therefore a detailed description thereof will be omitted.

[0113] FIG. 9 is a diagram illustrating an example of the access verification process.

[0114] In S901, the open system 120 verifies the user who instructed the execution of the job (executing user). For example, the open system 120 acquires user management information for the user name described in the job control statement from the management information 123, and if the authority of the executing user is "None", the open system 120 denies the execution. Also, for example, if the user name and password entered by the executing user differ from the user name and password described in the job control statement, the open system 120 denies the execution.

[0115] In S902, the open system 120 determines whether the verification of the execution user is OK for execution. If the open system 120 determines that the execution is OK, it proceeds to S903, and if it determines that the execution is not OK (execution is NG), it proceeds to S913.

[0116] In S903, the open system 120 verifies the job name. For example, the open system 120 acquires the job management information of the job name described in the job control statement from the management information 123, and if the authority of the executing user is the same as that of the job, or if the authority of the executing user is stronger (broader) than that of the job, it approves the execution. Note that if the access verification process is called from the job step execution process, the job name is not verified (the processes of S903 and S904 are omitted, and the process proceeds to S905).

[0117] In S904, the open system 120 determines whether the job name is verified to be executable. If the open system 120 determines that the job is executable, it proceeds to S905, and if it determines that the job is not executable, it proceeds to S913.

[0118] In S905, the open system 120 verifies the program name. For example, the open system 120 obtains the program management information of the program name described in the job control statement from the management information 123, and if the authority of the executing user is the same as that of the program, or if the authority of the executing user is stronger than that of the program, it is allowed to execute. Here, all program names described in the job control statement are verified.

[0119] In S906, the open system 120 determines whether the program name is verified to be executable. If the open system 120 determines that the program is executable, it proceeds to S907, and if it determines that the program is not executable, it proceeds to S913.

[0120] In S907, the open system 120 determines whether there is access to the dataset (data input / output specified in the job step of the job control statement). If the open system 120 determines that there is access to the dataset, it proceeds to S908, and if it determines that there is no access to the dataset, it proceeds to S910.

[0121] In S908, the open system 120 verifies the dataset. For example, the open system 120 obtains management information for the dataset with the dataset name described in the job control statement from the management information 123, and if the authority of the executing user is the same as that of the dataset, or if the authority of the executing user is stronger than that of the dataset, it determines that execution is OK. Here, verification is performed for all datasets described in the job control statement.

[0122] In S909, the open system 120 determines whether the verification of the data set is OK to execute. If the open system 120 determines that the data set is OK to execute, it proceeds to S910, and if the open system 120 determines that the data set is not OK to execute, it proceeds to S913.

[0123] In S910, the open system 120 sets the access verification result to "OK", which indicates that there is no problem in the access verification.

[0124] In S911, the open system 120 records the access history in the access history information 125 for each verified resource.

[0125] In S912, the open system 120 sets the access verification result and ends the process. The access verification result is set to "OK" or "NG" and an error code, which will be described later.

[0126] In S913, the open system 120 sets the access verification result to "NG", which indicates that there is a problem in the access verification.

[0127] In S914, the open system 120 investigates the cause of the access verification result and moves the process to S911. The open system 120 identifies an error code for the verification that failed to execute. For example, if the open system 120 determines in S909 that execution is not OK, it identifies the error code "X20" shown in FIG. 17 as being due to insufficient authority for the data set.

[0128] 10 is a diagram showing an example of processing (management information change processing and management information change monitoring processing) for synchronizing the management information 113 and the management information 123. The processing for synchronizing the management information is performed for resources for which migration of management information has been completed.

[0129] In S1001, the mainframe 110 changes the contents of the management information 113 in response to an operation to change the management information by the management terminal 130.

[0130] In S1002, the mainframe 110 transmits a notification of the change in management information to the open system 120. For example, when management information of a resource for which migration has been completed is changed, the mainframe 110 transmits the management information before the change and the management information after the change to the open system 120.

[0131] In S1003, the mainframe 110 waits until it receives a notification that synchronization is complete, and when it receives a notification that synchronization is complete, it ends the process.

[0132] In S1011, the open system 120 waits until it receives a notification of a change in management information.

[0133] In S1012, the open system 120 reflects the change in the management information 123.

[0134] In S1013, the open system 120 reflects the change history in the migration history information 124 (for example, adds a record including the management information before the change and the management information after the change to the migration history table 400).

[0135] In S1014, the open system 120 sends a notification of synchronization completion to the mainframe 110, and the process moves to S1011.

[0136] Next, processing related to the history reporter will be explained. The history reporter is an example of the output unit 215, and outputs information on history (migration history and / or access history) according to a report output instruction from the management terminal 130. The report output instruction specifies the resource from which history is to be acquired, the output destination, and other information related to acquiring the history according to a list of specified items 1800 shown in Fig. 18.

[0137] FIG. 11 is a diagram showing an example of processing (history reporter processing) executed by the history reporter.

[0138] In S1101, the open system 120 determines whether or not a migration history has been designated (for example, whether or not the input in the history type 1810 is migration history) when it receives a report output instruction from the management terminal 130. If the open system 120 determines that a migration history has been designated, it moves the process to S1102, and if it determines that a migration history has not been designated, it moves the process to S1103.

[0139] In S1102, the open system 120 performs a migration history collection process, and moves the process to S1103. The migration history collection process will be described later with reference to FIG.

[0140] In S1103, the open system 120 determines whether or not an access history is specified (for example, whether or not the input in the history type 1810 is an access history). If the open system 120 determines that an access history is specified, it proceeds to S1104, and if it determines that an access history is not specified, it proceeds to S1105.

[0141] In S1104, the open system 120 performs an access history collection process, and then proceeds to S1105. The access history collection process will be described later with reference to FIG.

[0142] In S1105, the open system 120 determines whether or not a graph output is specified (for example, whether or not the input of the output method 1870 is a spreadsheet file). If the open system 120 determines that a graph output is specified, it proceeds to S1106, and if it determines that a graph output is not specified, it proceeds to S1107.

[0143] In S1106, the open system 120 outputs the collected information to a spreadsheet file and ends the process.

[0144] In S1107, the open system 120 determines whether or not text output is specified (for example, whether or not the input of the output method 1870 is a text file). If the open system 120 determines that text output is specified, it proceeds to S1108, and if it determines that text output is not specified, it proceeds to S1109.

[0145] In S1108, the open system 120 outputs the collected information to a text file and ends the process.

[0146] In S1109, the open system 120 displays the collected information on the screen of the management terminal 130, and ends the process.

[0147] FIG. 12 is a diagram illustrating an example of the migration history collection process.

[0148] In S1201, the open system 120 determines whether or not there is a designation of output on a resource-by-resource basis (for example, whether or not the input of the acquired resource type 1820 is a user, a data set, or a program). If the open system 120 determines that there is a designation of output on a resource-by-resource basis, it proceeds to S1202, and if it determines that there is no designation of output on a resource-by-resource basis, it proceeds to S1203.

[0149] In S1202, the open system 120 acquires the migration history of the specified resource for the specified period from the migration history information 124, and ends the processing. For example, the open system 120 acquires from the migration history information 124 the migration history of the resource name that matches the resource name input as the acquired resource name 1830, for the period input as the extraction period 1860.

[0150] In S1203, the open system 120 determines whether or not there is a designation of output on a job step basis (for example, whether or not the input of the acquired resource type 1820 is a job step). If the open system 120 determines that there is a designation of output on a job step basis, it proceeds to S1204, and if it determines that there is no designation of output on a job step basis, it proceeds to S1205.

[0151] In S1204, the open system 120 acquires the migration history of the specified job step for the specified period from the migration history information 124 and terminates the processing. For example, the open system 120 acquires from the migration history information 124 the migration history of resources (users, user groups, programs, storage pools, volumes, datasets, etc.) related to the job step of the job step name input as the acquired job step name 1850, for the period input as the extraction period 1860.

[0152] In S1205, the open system 120 determines whether or not there is a job-by-job output designation (for example, whether or not the input of the acquired resource type 1820 is a job). If the open system 120 determines that there is a job-by-job output designation, it proceeds to S1206, and if it determines that there is no job-by-job output designation, it terminates the process.

[0153] In S1206, the open system 120 acquires the migration history of the specified job for the specified period from the migration history information 124 and ends the process. For example, the open system 120 acquires the migration history of resources (job, job class, user, user group, etc.) related to the job of the job name input as the acquisition job name 1840, for the period input as the extraction period 1860, from the migration history information 124. Note that when a job step name is input as the acquisition job step name 1850, the open system 120 acquires the migration history of resources related to the job step of that job step name, for the period input as the extraction period 1860, from the migration history information 124.

[0154] FIG. 13 is a diagram illustrating an example of the access history collection process.

[0155] In S1301, the open system 120 acquires the access history of the specified resource for the specified period from the access history information 125. For example, the open system 120 acquires from the access history information 125 the migration history for the period input as the extraction period 1860, which is the access history of the resource name that matches the resource name input as the resource name 1830.

[0156] In S1302, the open system 120 determines whether an access predictor function has been specified (for example, input of a future date). If the open system 120 determines that an access predictor function has been specified, it proceeds to S1303, and if it determines that an access predictor function has not been specified, it terminates the process. Note that the access predictor function may be specified by any appropriate method and at any appropriate timing.

[0157] In S1303, the open system 120 calculates a predicted value (such as the access frequency of each resource) for a specified period from the access history of the specified resource, and ends the process. The calculation of the predicted value is performed using a known technique such as a predictive analysis model (for example, a linear regression model, a generalized linear model, or a neural network model). Additionally, the calculation of the predicted value may be performed by a computer other than the open system 120.

[0158] FIG. 14 is a diagram showing an example of the management information 113 and the management information 123. As shown in FIG.

[0159] The user registry 113A stores information related to user privileges in the mainframe 110. For example, the user registry 113A stores records containing information on resource type, resource name, privileges, password (PW), group, and group privileges. The dataset registry 113B stores information related to privileges for datasets in the mainframe 110. For example, the dataset registry 113B stores records containing information on resource type, resource name, and privileges. The volume registry 113C stores information related to privileges for volumes in the mainframe 110. For example, the volume registry 113C stores records containing information on resource type, resource name, and privileges. The storage pool registry 113D stores information related to privileges for storage pools in the mainframe 110. For example, the storage pool registry 113D stores records containing information on resource type, resource name, and privileges.

[0160] The job registry 113E stores information related to job authority in the mainframe 110. For example, the job registry 113E stores records including information on resource types, resource names, and authority. The job class registry 113F stores information related to job class authority in the mainframe 110. For example, the job class registry 113F stores records including information on resource types, resource names, and authority. The program registry 113G stores information related to program authority in the mainframe 110. For example, the program registry 113G stores records including information on resource types, resource names, and authority.

[0161] The registry of the mainframe 110 may include information on registered users and registration dates and times. The registry of the mainframe 110 may be entirely stored in the same storage device, or part of it may be stored in a different storage device.

[0162] The user registry 123A stores information related to user authority in the open system 120. The data items in the user registry 123A are the same as the data items in the user registry 113A. The dataset registry 123B stores information related to dataset authority in the open system 120. The data items in the dataset registry 123B are the same as the data items in the dataset registry 113B. The job registry 123E stores information related to job authority in the open system 120. The data items in the job registry 123E are the same as the data items in the job registry 113E. The program registry 123G stores information related to program authority in the open system 120. The data items in the program registry 123G are the same as the data items in the program registry 113G.

[0163] The registry of the open system 120 may include information on registered users and registration dates and times. The registry of the open system 120 may be entirely stored in the same storage device, or part of it may be stored in a different storage device.

[0164] 15 shows an example of authority type correspondence information (authority type correspondence table 1500). The authority type correspondence table 1500 may be stored in the auxiliary storage device 230, may be stored in another computer, or may be included in an application program.

[0165] The authority type correspondence table 1500 includes records indicating the correspondence between the authority types in the mainframe 110 and the authority types in the open system 120. The authority types in the mainframe 110 are rewritten into the format of the authority types in the open system 120 in accordance with the authority type correspondence table 1500. For example, if the authority in the mainframe 110 is "NONE", when it is migrated to the open system 120, it is rewritten to "NONE" as the authority in the open system 120 in accordance with the record 1510.

[0166] 16 is a diagram showing an example of the aggregation correspondence information (aggregation correspondence table 1600). The aggregation correspondence table 1600 may be stored in the auxiliary storage device 230, may be stored in another computer, or may be included in an application program.

[0167] The aggregation correspondence table 1600 includes records that specify the authorizations to be applied in accordance with whether a dataset is protected (authorized), whether a volume is protected, and whether a storage pool is protected. For example, if the dataset authorization is "MEMBER," the volume authorization is "READ," and the storage pool authorization is "READ," then the dataset is protected, the volume is protected, and the storage pool is protected, and the authorization correspondence corresponds to record 1620. When the authorizations for these datasets, volumes, and storage pools are migrated from the mainframe 110 to the open system 120, the authorizations are aggregated to the volume authorization "READ" in accordance with record 1620.

[0168] 17 is a diagram showing an example of error codes (error code table 1700) for identifying errors that have occurred in the open system 120. The error code table 1700 shows the meanings of error codes.

[0169] FIG. 18 is a diagram showing an example of designated items (designated item list 1800) that are items that can be designated to the history reporter.

[0170] The list of specified items 1800 is configured to include items that can specify conditions for acquiring history (access history and / or migration history). As shown in the list of specified items 1800, there are provided items for history type 1810, acquisition resource type 1820, acquisition resource name 1830, acquisition job name 1840, acquisition job step name 1850, extraction period 1860, output method 1870, and output file 1880. These items are specified (input) by the user via the management terminal 130.

[0171] FIG. 19 is a diagram illustrating an example of a history reporter (history reporter 1900).

[0172] The history reporter 1900 is, for example, an application program provided in the open system 120. When the history that the user wishes to acquire is specified via the management terminal 130, the history reporter 1900 extracts and outputs the history from the migration history information 124 and the access history information 125 in accordance with the specification.

[0173] For example, when an item is specified as in report output instruction 1910, the history reporter 1900 outputs data 1911 on the screen, which is the access history of the data set “DATAA” for the specified period “23 / 11 / 29.09:10.40-23 / 11 / 29.09:10.50” extracted from the access history information 125.

[0174] Furthermore, for example, when an item is specified as in report output instruction 1920, the history reporter 1900 outputs data 1921 extracted from the transition history information 124, which is the transition history for all periods of job "JOB1" and job steps "STEP1" and "STEP2", to a file named "Access_Log1.txt".

[0175] Furthermore, for example, when an item is specified as in report output instruction 1930, a future date is specified, so the history reporter 1900 outputs data 1931 containing a graph showing the results of extracting the access history of the data set "DATAX" for the specified period "23 / 12-24 / 04" from the access history information 125 and calculating the predicted value, under the file name "Access_Graph.xxx."

[0176] According to this embodiment, it is possible to appropriately migrate a program from a mainframe to an open system.

[0177] (II) Supplementary Note The above-described embodiment includes, for example, the following contents.

[0178] In the above embodiment, the present invention is described as being applied to a computer system, but the present invention is not limited to this and can be widely applied to various other systems, devices, methods, and programs.

[0179] In the above embodiment, the job step execution process is called from the job execution process, but the present invention is not limited to this. For example, the job step execution process may be called in response to an operation from the management terminal 130.

[0180] Furthermore, in the above embodiment, when management information of a resource for which migration has been completed is changed, the mainframe 110 transmits the management information before the change and the management information after the change to the open system 120, but the present invention is not limited to this. For example, the mainframe 110 may transmit the management information before the change and the management information after the change, or the management information after the change, for all resources to the open system 120, and the open system 120 may reflect the change in the management information of the resource for which migration has been completed.

[0181] In the above-described embodiments, some or all of the programs may be installed from a program source into a device such as a computer that implements the computing device 200. The program source may be, for example, a program distribution server connected via a network or a computer-readable recording medium (e.g., a non-transitory recording medium). In the above description, two or more programs may be implemented as one program, or one program may be implemented as two or more programs.

[0182] Furthermore, in the above-described embodiments, the configuration of each table is an example, and one table may be divided into two or more tables, or all or part of two or more tables may be one table.

[0183] In the above-described embodiment, for the sake of convenience, the information related to the computer system has been described using a table, but the data structure is not limited to a table. The information related to the computer system may be expressed using a data structure other than a table, such as XML (Extensible Markup Language), YAML (YAML Ain't a Markup Language), a hash table, or a tree structure.

[0184] Furthermore, in the above-described embodiment, the screens shown and described are merely examples, and any design may be used as long as the information received is the same.

[0185] Furthermore, the screens shown and described in the above-described embodiment are merely examples, and any design may be used as long as the information presented is the same.

[0186] In the above-described embodiment, the output of information is not limited to display on a display screen, but may be audio output from a speaker, output to a file, printed on paper or the like by a printer, projected onto a screen or the like by a projector, or in other forms.

[0187] In addition, in the above description, information such as programs, tables, files, etc. that realize each function can be stored in a storage device such as a memory, a hard disk, or an SSD (Solid State Drive), or in a recording medium such as an IC card, an SD card, or a DVD.

[0188] The above-described embodiment has the following characteristic configurations, for example.

[0189] (1) A second computer system (e.g., an open system 120) that is different from a first computer system (e.g., a mainframe 110) to which programs of the plurality of job steps are sequentially migrated includes management information (e.g., management information 123) used for access verification of resources (resources to be protected in batch processing, such as users, datasets, volumes, storage pools, jobs, job classes, programs, etc.) referenced in each of a plurality of job steps, and performs access verification of the resources using the management information of the resources referenced in the job steps when executing any of the plurality of job steps. The job step includes an acquisition unit (e.g., acquisition unit 211, computer 200) that acquires management information used for access verification of a resource referenced in a job step from the first computer system, a modification unit (e.g., modification unit 212, computer 200) that modifies the management information acquired by the acquisition unit into management information usable in the second computer system, a memory unit (e.g., memory unit 213, computer 200) that stores the management information modified by the modification unit, and a verification unit (e.g., verification unit 214, computer 200) that performs access verification of the resource using the management information of the resource referenced in the job step stored in the memory unit in response to a request for execution of a job step to which a program migrated from the first computer system is associated.

[0190] According to the above configuration, for example, access verification of resources referenced in a job step executed on the second computer system during a program migration period can be realized, thereby maintaining confidentiality equivalent to that of the system environment of the first computer system. Furthermore, according to the above configuration, management information necessary for access verification on the second computer system is acquired, and management information unnecessary for access verification on the second computer system is not acquired, so that management information can be inventoried along with the program migration.

[0191] (2) The first computer system has management information (e.g., program registry 113G) used for access verification of a program associated with each of the plurality of job steps, and when executing any one of the plurality of job steps, performs access verification of the program using the management information of the program associated with the job step, the acquisition unit acquires from the first computer system the management information used for access verification of the program when the program associated with a job step is migrated from the first computer system (e.g., see S602), the change unit changes the management information acquired by the acquisition unit to management information usable in the second computer system (e.g., see S621), the memory unit stores the management information changed by the change unit (e.g., see S621), and the verification unit performs access verification of the program using the management information of the program changed by the change unit in response to a request for execution of a job step associated with the program migrated from the first computer system (e.g., see S905 and S906).

[0192] In the above configuration, for example, when access verification of a program is executed in a first computer system, management information of the program is acquired in a second computer system. According to the above configuration, the second computer system can execute access verification of the program in the same manner as the first computer system, and can maintain confidentiality equivalent to that of the system environment of the first computer system.

[0193] (3) The first computer system is provided with a job consisting of one or more job steps, and is provided with management information (user registry 113A, job registry 113E, job class registry 113F, etc.) used for access verification of the job, and when executing the job, if all programs associated with the job steps constituting the job have been migrated to the second computer system, the first computer system requests the second computer system to execute the job (see, for example, S702 and S705), and When a request for job execution is received from the first computer system, the acquisition unit acquires management information to be used for access verification of the job from the first computer system (see, for example, S711), the change unit changes the job management information acquired by the acquisition unit to management information usable in the second computer system (see, for example, S711), and the verification unit performs access verification of the job using the job management information changed by the change unit in response to the request for job execution from the first computer system (see, for example, S903 and S904).

[0194] In the above configuration, for example, when a first computer system is requested to execute a job, the second computer system acquires management information for the job. According to the above configuration, the second computer system can execute access verification for the job in the same way as the first computer system, and can maintain confidentiality equivalent to that of the system environment of the first computer system.

[0195] (4) The first computer system is provided with a dataset, which is a collection of data, a volume for storing the dataset, and a storage pool consisting of a plurality of volumes, and is provided with management information used for access verification of the dataset (for example, a dataset registry 113B), management information used for access verification of the volume (for example, a volume registry 113C), and management information used for access verification of the storage pool (for example, a storage pool registry 113D), and the acquisition unit acquires data referenced in a job step associated with a program migrated from the first computer system. The change unit acquires from the first computer system management information used for access verification of the set, management information used for access verification of the volume referenced in the job step, and management information used for access verification of the storage pool referenced in the job step (see, for example, S811), and the change unit aggregates the management information of the data set, management information of the volume, and management information of the storage pool acquired by the acquisition unit into management information usable by the second computer system in accordance with aggregation correspondence information (e.g., aggregation correspondence table 1600) that specifies the aggregation method (see, for example, S811).

[0196] In the above configuration, even if the second computer system does not have resources for volumes and storage pools, the management information for datasets, volumes, and storage pools is aggregated according to the aggregation correspondence information. With the above configuration, the second computer system can perform resource access verification in the same way as the first computer system, and can maintain the same level of confidentiality as the system environment of the first computer system.

[0197] (5) When the memory unit stores management information used for access verification of a resource referenced in a job step to which a program migrated from the first computer system is associated, the memory unit stores migration history information (e.g., migration history information 124, migration history table 400) indicating that the management information of the resource has been migrated, and when the job step is executed, stores access history information (e.g., access history information 125, access history table 500) indicating access to the resource.

[0198] According to the above configuration, for example, if a user needs to change the settings of management information on the first computer system during a program migration period, the user can easily investigate the impact of the setting change based on the migration history information and access history information.

[0199] (6) In response to a request to execute a job step associated with a program migrated from the first computer system, the verification unit performs access verification of the resource using management information of the resource referenced in the job step stored in the memory unit, and if the access verification fails, extracts migration history information of the resource and access history information of the resource from the information stored in the memory unit (e.g., see S822).

[0200] According to the above configuration, for example, if an error is detected in access verification of a resource referenced in a job step, the migration history information and access history information of the resource are extracted. According to the above configuration, the user can identify the cause of the error based on the migration history information and access history information of the resource, thereby reducing the amount of work required to identify the cause of the error.

[0201] (7) The device is provided with an output unit (e.g., output unit 215, computer 200) that, when receiving an instruction (e.g., report output instruction 1910, report output instruction 1920, report output instruction 1930) from a management terminal (e.g., management terminal 130) specifying resources and / or periods that the user needs to check, extracts migration history information or access history information stored in the memory unit in accordance with the instruction and outputs the extracted information.

[0202] According to the above configuration, for example, the user can check desired migration history information and desired access history information.

[0203] (8) The output unit outputs the results (for example, a spreadsheet file) of predicted access to the resource specified via the management terminal based on the access history information of the resource.

[0204] In the above configuration, access to resources referenced in job steps associated with programs migrated to the second computer system is predicted, so that, for example, users can make operational plans more efficient.

[0205] Furthermore, the above-described configurations may be modified, rearranged, combined, or omitted as appropriate within the scope of the present invention.

[0206] It should be understood that items included in a list in the format "at least one of A, B, and C" can mean (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). Similarly, items listed in the format "at least one of A, B, or C" can mean (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). [Explanation of symbols]

[0207] 100...Computer system, 110...Mainframe, 120...Open system.

Claims

1. A second computer system, different from the first computer system, to which programs of the plurality of job steps are sequentially transferred from a first computer system that has management information used for access verification of a job referenced in each of one or more job steps constituting a job, and that performs access verification of the job using the management information of the job referenced in the job step when executing any one of the plurality of job steps, A processor and a memory unit are included. the processor executes the acquisition unit, the change unit, and the verification unit stored in the storage unit; the acquiring unit acquires, from the first computer system, management information used for access verification of the job as management information to be referenced in a job step whose program has been migrated from the first computer system; the change unit applies the authority of the job class as the authority of the job in the management information in the second computer system when there is no protection setting for the job in the acquired management information or the authority is job ⊂ job class, and applies the authority of the job as the authority of the job in the management information in the second computer system when the authority is job ⊇ job class in the acquired management information, thereby changing the acquired management information to management information that can be used in the second computer system; the storage unit stores the management information changed by the change unit; the verification unit, in response to a request for execution of a job step associated with the program migrated from the first computer system, performs access verification of the job using job management information referenced in the job step stored in the storage unit; Computer system.

2. the first computer system comprises management information used for access verification of a program associated with each of the plurality of job steps, and when executing any one of the plurality of job steps, performs access verification of the program using the management information of the program associated with the job step; the acquisition unit acquires, when a program associated with a job step is migrated from the first computer system, management information used for access verification of the program from the first computer system; the change unit applies the authority of the program as the authority of the program of management information in the second computer system, and changes the management information acquired by the acquisition unit to management information usable in the second computer system; the storage unit stores the management information changed by the change unit; the verification unit, in response to a request for execution of a job step associated with the program migrated from the first computer system, performs access verification of the program using the management information of the program changed by the change unit; 2. The computer system of claim 1.

3. The first computer system is provided with a job consisting of one or more job steps, and is provided with management information used for access verification of the job; when executing the job, if all programs associated with job steps constituting the job have been migrated to the second computer system, the first computer system requests the second computer system to execute the job; when execution of a job is requested from the first computer system, the acquisition unit acquires management information used for access verification of the job from the first computer system; The change unit when the job has no protection setting or the authority is job⊂job class, applying the authority of the job class as the authority of the job of the management information in the second computer system, and changing the management information of the job acquired by the acquisition unit to management information usable in the second computer system; when the authority is job ⊇ job class, applying the authority of the job as the authority of the job of the management information in the second computer system, and changing the management information of the job acquired by the acquisition unit into management information usable in the second computer system; the verification unit, in response to a request for execution of a job from the first computer system, performs access verification of the job using the management information of the job changed by the change unit; 2. The computer system of claim 1.

4. the first computer system is provided with a dataset which is a collection of data, a volume for storing the dataset, and a storage pool which is made up of a plurality of volumes, and is provided with management information used for access verification of the dataset, management information used for access verification of the volume, and management information used for access verification of the storage pool; the acquisition unit acquires, from the first computer system, management information used for access verification of a dataset referenced in a job step associated with a program migrated from the first computer system, management information used for access verification of a volume referenced in the job step, and management information used for access verification of a storage pool referenced in the job step; the change unit aggregates the management information of the dataset, the management information of the volume, and the management information of the storage pool acquired by the acquisition unit into management information that can be used by the second computer system in accordance with aggregation correspondence information that defines an aggregation method; 2. The computer system of claim 1.

5. the storage unit stores migration history information indicating that the management information of the job has been migrated when storing management information used for access verification of the job referenced in the job step associated with the program migrated from the first computer system, and stores access history information indicating access to the job when the job step is executed; 2. The computer system of claim 1.

6. the verification unit, in response to a request for execution of a job step associated with a program migrated from the first computer system, performs access verification of the job using job management information referenced in the job step stored in the storage unit, and if the access verification fails, extracts migration history information of the job and access history information of the job from the information stored in the storage unit; 6. The computer system according to claim 5.

7. an output unit that, when receiving an instruction from a management terminal specifying a job and / or a period that a user needs to confirm, extracts migration history information or access history information stored in the storage unit in accordance with the instruction and outputs the extracted information; 6. The computer system according to claim 5.

8. the output unit outputs a result of predicting access to the job based on access history information of the job specified via the management terminal.

8. The computer system of claim 7.

9. The acquisition unit acquires, in response to a request for execution of a job step to which a program migrated from the first computer system is associated, management information of the job referenced in the job step from the first computer system; the change unit changes the acquired management information to management information that can be used by the second computer system; the verification unit compares the changed management information with the corresponding management information stored in the storage unit, and outputs a warning message if they do not match.

2. The computer system of claim 1.

10. The first computer system is a mainframe, and the second computer system is an open system that does not have management information for jobs that substitute for the job class.

2. The computer system of claim 1.

11. An access verification method in a second computer system, different from the first computer system, to which programs of the plurality of job steps are sequentially transferred from a first computer system that has management information used for access verification of a job referenced in each of one or more job steps constituting a job, and that performs access verification of the job using the management information of the job referenced in the job step when executing any one of the plurality of job steps, comprising: In the second computer system having at least a processor and a storage unit, the processor: acquiring, from the first computer system, management information used for access verification of the job as management information to be referenced in a job step whose program has been migrated from the first computer system; when the job in the acquired management information has no protection setting or the authority is job ⊂ job class, apply the authority of the job class as the authority of the job in the management information in the second computer system, and when the authority in the acquired management information is job ⊇ job class, apply the authority of the job as the authority of the job in the management information in the second computer system, thereby changing the acquired management information to management information that can be used in the second computer system; storing the changed management information; in response to a request for execution of a job step associated with the program migrated from the first computer system, performing access verification of the job using job management information referenced in the job step stored in the storage unit; Access verification method.

Images