JP2008217318A - Program update management system, program update management method, and computer program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a program update management system, a program update management method and a computer program, capable of managing an update history without omission while associating a source program file with an execution type program file by eliminating any margin in which the intentional act of a person in charge of maintenance lies. <P>SOLUTION: An execution format program is prepared based on a source program file updated by a first computer, and when the execution request of a job for registering so as to be executable is made, a second computer judges whether or not a person who has updated the source program file is an authenticated user, and when it is judged that the person who has updated the source program file is an authenticated user, the second computer executes the job whose execution request has been made according to a specific procedure about the source program file. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a technical field such as a program update management system that manages an update history of a program or the like.

  For example, in a large-scale system of a company where the same execution format program is running on a plurality of computers (hereinafter referred to as “actual machines”), the above execution format is used for function expansion or defect correction in the system. When the program is edited and updated, the maintenance person updates the source program file (upgrades) by modifying the source program that is the source of the execution program and modifying the source program. Then, the source program file updated in this way (written in a program language that can be understood by the maintenance staff) is converted into an executable program file (written in a machine language that can be executed by a computer) ( After being compiled, it is incorporated (installed) into the plurality of actual machines.

  Thus, when a program applied to a large-scale system as described above is updated, the update history needs to be strictly managed. In particular, the content of the program change request, the association with the source program file, and the executable program file (association for version matching) are important management elements. In addition, the Japanese version of the SOX (Survein Oxley) Act, which is a law that requires the enhancement of the accounting audit system and the strengthening of internal control of corporations, demands stricter management of the above update history.

Patent Document 1 discloses a system for upgrading a program version. In this system, after the development management server and the active machine server are separated, the source program file changed by the person in charge of development is transferred from the development management server to the active machine management server according to the upgrade instruction, and after generation management is performed The source program file is transmitted to the current machine and converted into an executable program file. According to this system, it is possible to accurately manage the update history of source program files that have been changed by the developer, by dividing the person in charge of development and the person in charge of operation, and giving only the necessary and sufficient authority to each. Conceivable.
JP 2004-310230 A

  However, in the technique of Patent Document 1, in an emergency that requires version upgrade as soon as possible, the source program file changed by the developer is directly transmitted to the current machine. Although processing to ensure the consistency of the generation of source program files is performed, the possibility of intervention by the development staff (maintenance staff) cannot be denied, and it is difficult to accurately manage the update history It is assumed that

  The present invention has been made in view of the above points and the like, eliminates the space for maintenance personnel's work, and can manage the update history without omission while associating the source program file with the executable program file. An object of the present invention is to provide a program update management system, a program update management method, and a computer program.

  In order to solve the above problem, the invention described in claim 1 is created by a source program file updated in a first computer and a second computer different from the first computer based on the source program file. A program update management system for managing an update history of executable program files registered so as to be executable, wherein the second computer is a process of creating an executable program file based on the updated source program file; Based on the source program file updated in the first computer, storage means for storing a specific procedure that defines at least a procedure for registering the executable program file so as to be executable and a process for registering the update history Create an executable program file and register it as executable A determination means for determining whether or not an updater of the source program file is an authorized person when there is a job execution request, and an updater of the source program file And an execution unit that executes the job requested to be executed according to the specific procedure for the source program file when the user is an authorized person.

  According to a second aspect of the present invention, in the program update management system according to the first aspect, the determination unit further determines whether or not an updater of the source program file specifies the specific procedure. The execution means follows the specific procedure for the source program file only when the updater of the source program file is the authorized person and specifies the specific procedure. The job requested to be executed is executed.

  According to a third aspect of the present invention, in the program update management system according to the first or second aspect, the determination by the determination unit is performed by a check routine by the operating system.

  According to a fourth aspect of the present invention, a computer program causes a computer to function as the second computer according to any one of the first to third aspects.

  The invention according to claim 5 is a source program file updated in the first computer, and an execution format created and registered executable by a second computer different from the first computer based on the source program file. A program update management method for managing an update history of a program file, wherein the second computer creates an executable program file based on the updated source program file, and can execute the executable program file And a step of storing a specific procedure that defines at least the procedure of the process of registering the update history and the process of registering the update history, and creating and executing an executable program file based on the source program file updated in the first computer Job execution request to register as possible A determination step for determining whether the updater of the source program file is an authorized person, and the updater of the source program file is the authorized person In the case, the execution step of executing the job requested to be executed according to the specific procedure for the source program file is provided.

  According to the present invention, when there is a job execution request for creating and registering an executable program file based on the source program file updated in the first computer, the second computer It is determined whether or not an updater of the source program file is an authorized person. If the updater of the source program file is an authorized person, the source program file is updated. Since the job that has been requested to be executed is executed according to the specific procedure, the maintenance staff is forced to use the specific procedure, and the procedure defined in this is strictly observed. Eliminates the need for intervention by maintenance personnel, and relates source program files to executable program files. Update history without omission while attached can be managed.

  DESCRIPTION OF EXEMPLARY EMBODIMENTS Hereinafter, the best embodiment of the invention will be described with reference to the drawings.

  First, the configuration and function of a program update management system according to an embodiment of the present invention will be described with reference to FIG.

  FIG. 1 is a diagram showing a schematic configuration example of a program update management system according to an embodiment of the present invention.

  As shown in FIG. 1, the program update management system S according to the present embodiment includes a person-in-charge terminal 1 as an example of a first computer, a repository server 2, and an actual machine (real number machine) as an example of a second computer. 3) and the like, and is created by a source program file updated in the person-in-charge terminal 1 (hereinafter referred to as “source file”) and an actual machine 3 different from the person-in-charge terminal 1 based on the source file. An update history of executable program files (hereinafter referred to as “executable files”) registered so as to be executable is managed.

  The person-in-charge terminal 1 and the actual machine 3 are connected to the repository server 2 via a network such as a LAN (Local Area Network) and can communicate with each other. A plurality of person-in-charge terminals 1 and actual machines 3 are provided, but in the example of FIG. 1, only one is shown for convenience of explanation.

  The person-in-charge terminal 1 is composed of, for example, a general-purpose personal computer. Although not shown, the person-in-charge terminal 1 inputs a control unit mainly composed of a CPU, a storage unit composed of an HD (hard disk) drive, etc. For example, an operation unit including a keyboard and a mouse, a display unit including a CRT display or a liquid crystal display (LCD), and a communication unit including a communication device for connecting to a network.

  In the person-in-charge terminal 1, a maintenance person as an updater operates the operation unit to edit and update the source file, and the updated source file is transmitted to the network in accordance with an instruction from the maintenance person. Via the repository server 2 and registered. At this time, a job execution request for creating an executable file based on the updated source file and registering it executable (hereinafter referred to as “file update job execution request”) is sent from the person-in-charge terminal 1 to the repository server 2. Will be sent and registered.

  In such a file update job execution request, an authorized person ID (identification information) given to a maintenance person who is authorized to register the updated file, a catalog-type procedure (hereinafter referred to as “catapro”) described later. (For example, catapro name) and change management number (number) are included.

  When the maintenance person in charge edits and updates the source file in the person in charge terminal 1, he / she logs in by inputting the authority ID given to him / her by operating the operation unit. When registering a source file in the repository server 2, for example, a catapro name is designated (for example, entered in a predetermined form) by operating the operation unit.

  In addition, the source in this embodiment is a program created by programming languages, such as COBOL, C, PL / I, PL / SQL, for example.

  Although not shown, the repository server 2 and the actual machine 3 are communication units including a control unit mainly composed of a CPU, a storage unit including an HD (hard disk) drive, and a communication device for connecting to a network. Part. The updated source file and the file update job execution request from the person-in-charge terminal 1 are registered (stored) in the storage unit in the repository server 2.

  Further, the CPU of the actual machine 3 (an example of a determination unit and an execution unit in the present invention) sequentially executes (batch processing) various jobs. Then, when the CPU of the real machine 3 obtains the file update job request from the repository server 2, for example, it determines whether the updater of the source file is an authorized person (the file update job execution request). Whether or not the ID included in is the above-mentioned authority ID), and whether or not the updater of the source file specifies a specific catapro (an example of a specific procedure in the present invention). It is determined (based on whether the catapro name included in the file update job execution request indicates a specific catapro name), and the updater of the source file is an authorized person, Only when a specific catapro is specified, the job that requested the execution according to the specific catapro for the source file It is adapted to run. If the updater of the source file is not authorized, or if the specific catapro is not specified, creation and registration of an executable file based on the source file is prohibited. Become.

  Here, the specific catapro (this catapro name is referred to as “catapro A”) creates an executable file based on the updated source file (that is, converts (compiles) the source file into the executable file) (hereinafter, referred to as “catapro”). Define at least the procedures of “compilation processing”, processing to register the executable file as executable (hereinafter referred to as “collaboration editing processing”), and processing to register update history (hereinafter referred to as “history registration processing”) (Described in Job Control Language (JCL)) and stored in advance in the actual machine 3.

  By forcibly using such Catapro A and ensuring that the above procedure is followed, there is no room for maintenance personnel's work, and the update history is managed without omission while associating the source file with the execution file. It is.

  Next, with reference to FIG. 2, the processing in the real machine 3 when there is a file update job execution request will be described.

  FIG. 2 is a flowchart showing processing in the real machine 3 when there is a file update job execution request.

  The process of FIG. 2 is started when a file update job execution request is acquired. In step S1, the ID included in the acquired file update job execution request is stored in the authority 3 (this is stored in the real machine 3 in advance). ), It is determined whether the updater of the source file is an authorized person. If the updater of the source file is not an authorized person, (Step S1: NO), the processing is finished (JOB FAIL), and if the updater of the source file is an authorized person (Step S1: YES), the process proceeds to Step S2.

  In step S2, whether or not the catapro name included in the acquired file update job execution request is the catapro A (this is stored in the actual machine 3 as a catapro required for registering the updated file). Is determined, it is determined whether or not the updater of the source file specifies Catapro A. If the updater of the source file does not specify Catapro A (for example, Catapro B different from Catapro A) (Step S2: NO), the process is completed (JOB FAIL), and when the source file updater specifies Catapro A (step S2: YES), the source A job is executed for the file according to the Catapro A (steps S3 to S8 shown in FIG. 2).

  The processes in steps S1 and S2 are performed by a check routine that operates at the operating system level, but are not performed for jobs other than jobs for registering files. Thereby, the load on the actual machine 3 can be kept to a minimum.

  In step S3 shown in FIG. 2, a compilation process is performed. In such a compilation process, a source file (updated source file) related to a file update job execution request is acquired from the repository server 2 and an executable file is created based on the source file (that is, converted from a source file to an executable file ( Compiled)).

  Next, in step S4, an update date registration process is performed. In the update date registration process, the update date is incorporated into the created (converted) executable file (time stamp).

  Next, in step S5, it is determined whether or not the ID included in the acquired file update job execution request is the ID of the person who has been given the authority to update the library, thereby updating the source file. Is determined to be a person who has been given the authority to update the library, and if the updater of the source file is not a person who has been given the authority to update the library (step S5: NO), the process ends. If the source file updater is a person who has been given the authority to update the library (step S5: YES), the process proceeds to step S6.

  In step S6, it is determined whether or not the ID included in the acquired file update job execution request is the ID of the person who has been given the authority to use the cooperative editing program. If it is determined whether or not the person who has been given the authority to use the cooperative editing program (PGM) and the updater of the source file is not the person who has been given the authority to use the cooperative editing program (step S6: NO), When the processing is finished (JOB FAIL) and the updater of the source file is a person who has been given the authority to use the cooperative editing program (step S6: YES), the process proceeds to step S7.

  In step S7, the cooperative editing program is executed, and the cooperative editing process is performed. In such cooperative editing processing, the time-stamped executable file is registered to be executable.

  In step S8, history registration processing is performed. In such history registration processing, for example, a change management number associated with a program change request (for example, function addition in the real machine 3), a job name related to the file update job execution request, and a file name of the source file The update history such as the file name (or module ID), library name, and identification information of the actual machine 3 that is the update target of the file is registered in the database.

  As described above, according to the above-described embodiment, when there is a job execution request for creating an executable file based on the source file updated in the person-in-charge terminal 1 and registering the executable file, the actual machine 3 Determining whether the updater of the source file is an authorized person, and determining whether the updater of the source file specifies a specific catapro, Only when the updater of the file is an authorized person and a specific catapro is specified, the job requested to be executed according to the specific catapro is executed for the source file. By forcing maintenance personnel to use the specific catapro and ensuring that the procedures defined in this are followed, there is no room for maintenance personnel to intervene. Update history without omission while associated with the source file and the executable file can be managed.

  In addition, since the processing of steps S1 and S2 is executed only for the job for registering the file in the check routine that operates at the operating system level, the load on the third embodiment can be kept to a minimum. .

  The embodiment has been described in detail with reference to the drawings. However, the specific configuration is not limited to the embodiment, and there are design changes and the like without departing from the scope of the invention. Are also included in the present invention.

It is a figure showing an example of outline composition of a program update management system concerning one embodiment of the present invention. 10 is a flowchart showing processing in an actual machine 3 when there is a file update job execution request.

Explanation of symbols

1 Person in charge terminal 2 Repository server 3 Real machine S Program update management system

Claims (5)

Manages the update history of the source program file updated in the first computer and the executable program file created by the second computer different from the first computer and registered to be executable based on the source program file A program update management system for
The second calculator is
Stores a specific procedure that defines at least a procedure for creating an executable program file based on the updated source program file, registering the executable program file to be executable, and registering the update history. Storage means;
When there is a job execution request for creating and registering an executable program file based on the source program file updated in the first computer, the updater of the source program file gives the authority Discrimination means for discriminating whether or not the person has been
When the updater of the source program file is the authorized person, execution means for executing the job requested to be executed according to the specific procedure for the source program file;
A program update management system comprising: In the program update management system according to claim 1,
The determination means further determines whether or not the updater of the source program file specifies the specific procedure,
The execution means executes the execution of the source program file according to the specific procedure only when the updater of the source program file is the authorized person and specifies the specific procedure. A program update management system characterized by executing a requested job. In the program update management system according to claim 1 or 2,
The program update management system characterized in that the determination by the determination means is performed by a check routine by the operating system.   A computer program for causing a computer to function as the second computer according to any one of claims 1 to 3. Manages the update history of the source program file updated in the first computer and the executable program file created by the second computer different from the first computer and registered to be executable based on the source program file A program update management method for
The second calculator is
Stores a specific procedure that defines at least a procedure for creating an executable program file based on the updated source program file, registering the executable program file to be executable, and registering the update history. Steps,
When there is a job execution request for creating and registering an executable program file based on the source program file updated in the first computer, the updater of the source program file gives the authority A determination step for determining whether or not the person has been
An execution step of executing the requested job according to the specific procedure for the source program file when the source program file updater is the authorized person;
A program update management method comprising:

Images