System configuration updating method and apparatus, storage medium, and electronic device

Abstract

The application discloses a system configuration updating method and device, a storage medium and an electronic device, relates to the field of communication, and the system configuration updating method comprises the following steps: dividing a host platform system configuration into multiple subsystem configurations, wherein the subsystem configuration comprises a product system volume, a configuration parameter library and an OMVS directory file; in the case that the host platform system configuration exists updating, determining an updating item and an updating strategy corresponding to each subsystem configuration; and updating each subsystem configuration according to the updating item and the updating strategy. Through the technical scheme, the problem that the total amount is too large in the system configuration modification process, and the manual operation may cause the risk of false modification and modification omission in the related art is solved.

Description

Technical Field

[0001] This application relates to the field of communications, and more specifically, to a method and apparatus for updating system configuration, a storage medium, and an electronic device. Background Technology

[0002] Mainframe platform (IBM z mainframe) software typically employs a cluster architecture to achieve high concurrency and high availability for business continuity requirements. In practice, core banking systems deploy multiple virtual machines (referred to as logical partitions (LPARs) on the mainframe platform), forming a parallel sysplex. Each virtual machine hosts one or more database instances. Physically, these virtual machines are distributed across multiple physical hosts (CPCs) to ensure high availability. A physical connection is established between these physical hosts and at least two physical coupling facilitators (CFs), enabling communication, data sharing, and collaborative operations among the virtual machines. Communication between physical hosts relies on the physical memory of the parallel couplers. The parallel couplers divide their memory into parallel coupling structures, which serve as the smallest management unit, providing support for communication and data sharing between physical hosts. A parallel coupled system (cluster) provides cross-system scalability services, offering efficient access services to users such as database instances and middleware instances running on virtual machines. These services include caching, list data processing, and lock management. Correspondingly, the parallel coupling units within the parallel coupler are also divided into cache-type structural units (cache), list-type structural units (list), and lock-type structural units (lock) according to these usage requirements. The database uses the lock-type structural unit lock 1 and the cache-type open structural unit Global Buffer Pool (GBP).

[0003] like Figure 1 The diagram shows a host cluster with two physical hosts for parallel couplers, Parallel Coupler 1 and Parallel Coupler 2; and four virtual machines (VMs) for services, VMs 1 to 4. Each VM hosts an operating system (z / OS), a database instance (DB2), and middleware software (CICS). On the host platform, the operating system, database, and middleware processes are referred to as subsystems. These subsystems, deployed on the VMs within the cluster, interact and collaborate to support and implement the services.

[0004] For a business virtual machine in a host cluster, its key system configuration parameters consist of three parts: the software product installation volume, also known as the system volume (SYSRES volume), the virtual machine configuration parameter libraries, and the software product and customized OMVS (z / OS UNIX System Services) directory files.

[0005] For a host cluster consisting of multiple operating system instances, database instances, and transaction middleware instances, there are many parameter libraries and configuration files in each parameter library. When encountering implementation phases such as basic software upgrades or hardware upgrades that require centralized adjustments, the overall workload for parameter adjustment and maintenance is large. If implemented manually, it is prone to errors and omissions in modification. When performing parameter synchronization operations on multiple host clusters, the above implementation actions are highly repetitive, and traditional methods are inefficient, which may lead to the implementation speed failing to meet the schedule requirements.

[0006] There is no effective solution yet to address the problem that the total amount of system configuration modifications is too large in related technologies, and the risk of accidental modifications and omissions that may occur during manual operation. Summary of the Invention

[0007] This application provides a method and apparatus for updating system configuration, a storage medium, and an electronic device to at least solve the problems in related technologies where the total amount of system configuration modification is too large, and manual operation may cause erroneous modifications and the risk of omissions in modifications.

[0008] According to one embodiment of this application, a method for updating system configuration is provided, comprising: dividing a host platform system configuration into multiple subsystem configurations, wherein the subsystem configurations include: a product system volume, a configuration parameter library, and an OMVS directory file; when the host platform system configuration is updated, determining an update item and an update strategy corresponding to each subsystem configuration; and updating each subsystem configuration according to the update item and the update strategy.

[0009] In an exemplary embodiment, when the subsystem is configured as a product system volume, updating the configuration of each subsystem according to the update item and the update policy includes: when there are multiple product system volumes, determining whether the media corresponding to any product system volume has been updated according to the update item; and when any product system volume has been updated, storing the updated product system volume in the corresponding disk volume.

[0010] In an exemplary embodiment, when the subsystem is configured as a configuration parameter library, updating the configuration of each subsystem according to the update item and the update strategy includes: creating a second parameter library according to the rules of the first parameter library, and copying the parameter configuration file of the first parameter library to the second parameter library, wherein the rules include at least: file naming rules and file attribute rules; updating the parameter configuration file in the second parameter library according to the update item to obtain the updated parameter configuration file.

[0011] In an exemplary embodiment, after updating the parameter configuration file in the second parameter library according to the update item, the method further includes: verifying the target content in the updated parameter configuration file, wherein the target content includes at least one of the following: a reference to the first parameter library, a reference to the software version number corresponding to the first parameter library, and a reference to the software file name corresponding to the first parameter library.

[0012] In an exemplary embodiment, when the subsystem is configured as an OMVS directory file, updating the configuration of each subsystem according to the update item and the update policy includes: determining a first directory file in the OMVS directory file according to the update item; determining the type of the first directory file and determining a first update policy for the first directory file according to the type of the first directory file; and updating the first directory file according to the first update policy.

[0013] In one exemplary embodiment, determining a first update strategy for the first directory file based on its type includes: if the type of the first directory file indicates that the first directory file is a read-only directory file, determining the first update strategy to store a second directory file in a corresponding disk volume, wherein the version of the second directory file is higher than the version of the first directory file; if the type of the first directory file indicates that the first directory file is a read-write directory file, determining the first update strategy to obtain difference data between the first directory file and the second directory file, and modifying the second directory file according to the difference data to obtain a third directory file.

[0014] In one exemplary embodiment, obtaining difference data between a first directory file and a second directory file includes: determining intersection data between the first directory file and the second directory file; determining other data in the first directory file besides the intersection data, and using the other data as the difference data.

[0015] According to another embodiment of the present application, a system configuration update apparatus is also provided, comprising: a partitioning module, configured to partition a host platform system configuration into multiple subsystem configurations, wherein the subsystem configurations include: a product system volume, a configuration parameter library, and an OMVS directory file; a determining module, configured to determine an update item and an update strategy corresponding to each subsystem configuration when the host platform system configuration is updated; and an updating module, configured to update each subsystem configuration according to the update item and the update strategy.

[0016] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0017] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0018] In this embodiment, the host platform system configuration is divided into multiple subsystem configurations, wherein each subsystem configuration includes: a product system volume, a configuration parameter library, and an OMVS directory file. When the host platform system configuration is updated, the update items and update strategies corresponding to each subsystem configuration are determined. Each subsystem configuration is then updated according to the update items and update strategies. Specifically, this application divides the host platform system configuration into three subsystem configurations and assigns a corresponding update strategy to each subsystem configuration. When any subsystem configuration is updated, the corresponding subsystem configuration is updated according to the corresponding update strategy. This technical solution solves the problem in related technologies where the total amount of system configuration modification is too large, and manual operation may cause erroneous modifications and omissions in the modification process. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of a host cluster deployment scheme in existing technology;

[0022] Figure 2 This is a hardware structure block diagram of a computer terminal for a system configuration update method according to an embodiment of this application;

[0023] Figure 3 This is a flowchart (a) of a system configuration update method according to an embodiment of this application;

[0024] Figure 4 This is a schematic diagram of the host platform system parameters in the embodiments of this application;

[0025] Figure 5 This is a schematic diagram of the parameters of a host platform system in the prior art;

[0026] Figure 6 This is a schematic diagram of a system configuration update device in an embodiment of this application;

[0027] Figure 7 This is a schematic diagram of the system configuration verification module of the system configuration update device in an embodiment of this application;

[0028] Figure 8 This is a flowchart of the workflow for the system configuration update method in the embodiments of this application;

[0029] Figure 9 This is a schematic diagram of the storage medium for the system configuration update method in the embodiments of this application;

[0030] Figure 10 This is a structural block diagram of an update device configured according to an embodiment of this application. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0033] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing systems. Taking running on a computer terminal as an example, Figure 2This is a hardware structure block diagram of a computer terminal for a system configuration update method according to an embodiment of this application. For example... Figure 2 As shown, a computer terminal may include one or more ( Figure 2 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The computer terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 2 The structure shown is for illustrative purposes only and does not limit the structure of the computer terminal described above. For example, the computer terminal may also include components that are more complex than those described above. Figure 2 The more or fewer components shown, or having the same Figure 2 The different configurations shown.

[0034] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the system configuration update method in this embodiment. The processor 202 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 204 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage systems, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 202, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0035] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the computer terminal. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0036] This embodiment provides a method for updating system configuration, applied to the aforementioned computer terminal, such as... Figure 3 As shown, Figure 3 This is a flowchart of a system configuration update method according to an embodiment of this application, the process including the following steps:

[0037] Step S302: Divide the host platform system configuration into multiple subsystem configurations, wherein the subsystem configurations include: product system volume, configuration parameter library, and OMVS directory file;

[0038] Step S304: If the host platform system configuration is updated, determine the update item and update strategy corresponding to each subsystem configuration.

[0039] It should be noted that the above update items may include at least one of the following: the name of the subsystem configuration to be adjusted, the name of the configuration file in the specific subsystem configuration, and how to modify a certain line of the configuration file.

[0040] Step S306: Update the configuration of each subsystem according to the update item and the update strategy.

[0041] Through the above steps, the host platform system configuration is divided into multiple subsystem configurations, wherein the subsystem configurations include: product system volume, configuration parameter library, and OMVS directory file; when the host platform system configuration is updated, the update items and update strategies corresponding to each subsystem configuration are determined; and each subsystem configuration is updated according to the update items and update strategies. That is, this application divides the host platform system configuration into three subsystem configurations and assigns a corresponding update strategy to each subsystem configuration; when any subsystem configuration is updated, the corresponding subsystem configuration is updated according to the corresponding update strategy; by adopting the above technical solution, the problems of excessively large total amount of system configuration modification during related technologies, and the risk of accidental modification and omission of modifications that may be caused by manual operation are solved.

[0042] Since the host platform basic software related configurations and parameters are divided into three categories in this embodiment, specifically into product system volumes, configuration parameter libraries, and OMVS directory files, updates to any of these three types of parameters can be achieved in the following way:

[0043] 1) When the subsystem is configured as a product system volume, update the configuration of each subsystem according to the update item and the update policy, including: when there are multiple product system volumes, determine whether the media corresponding to any product system volume has been updated according to the update item; when any product system volume has been updated, store the updated product system volume in the corresponding disk volume.

[0044] If the product system volume is updated, install the latest version of the media. After completing the installation of the product system volume in the media library, copy the product system volume. This can be implemented by backing up the system volume to a tape library, and then restoring it to the target system via a disk library recovery operation. Depending on the user's product installation method, the number of system volumes is not limited to one. For example, operating system software z / OS, database software DB2, transaction middleware software CICS, and utility software can be installed on separate disk volumes for easier future maintenance. In terms of program implementation, the DUMP command of the ADRDSSU program in the host platform's DFSMS (Data Facility Storage Management Subsystem) component can be used to back up the product system volume to the tape library, and the RESTORE command of the ADRDSSU program in the host platform's DFSMS can be used to restore the product system volume to the directory system.

[0045] 2) When the subsystem is configured as a configuration parameter library, update the configuration of each subsystem according to the update item and the update strategy, including: creating a second parameter library according to the rules of the first parameter library, and copying the parameter configuration file of the first parameter library to the second parameter library, wherein the rules include at least: file naming rules and file attribute rules; updating the parameter configuration file in the second parameter library according to the update item to obtain the updated parameter configuration file.

[0046] If the configuration parameter library is updated, a new configuration parameter library (equivalent to the second parameter library in the above embodiment) is allocated according to the allocation plan of the original configuration parameter library (equivalent to the first parameter library in the above embodiment). The configuration parameter files in the original configuration parameter library are copied to the new configuration parameter library, and then the parameter configuration files in the new configuration parameter library are uniformly modified and adjusted according to the updated items.

[0047] A new configuration parameter library will be allocated based on the existing allocation plan. This new library must meet the naming conventions for parameter library files. For example, if the existing configuration parameter library is named SYS1.OLD.**, the newly allocated parameter library can be named SYS1.NEW.**. The newly allocated system parameter libraries are shown in Table 1. Figure 4 As shown; simultaneously, the allocation of parameter configuration files in the new configuration parameter library must be consistent with the file attributes of the old parameters, such as the allocation size of each parameter library, the size of the primary and secondary libraries, and the disk volume where they are located. If the space utilization of the original configuration parameter library is high, the new configuration parameter library can be appropriately enlarged according to the specific situation. In terms of program implementation, the allocation process of the new configuration library SYS1.NEW.** can be implemented through the host program IEFBR14.

[0048] Table 1

[0049] LOAD01 LOAD02 SYS1.OLD.PARMLIB SYS1.NEW.PARMLIB SYS1.OLD.PROCLIB SYS1.NEW.PROCLIB SYS1.OLD.CMDPROC SYS1.NEW.CMDPROC SYS1.OLD.ISPPLIB SYS1.NEW.ISPPLIB SYS1.OLD.VTAMLST SYS1.NEW.VTAMLST SYS1.OLD.TCPPARMS SYS1.NEW.TCPPARMS SYS1.OLD.LINKLIB SYS1.NEW.LINKLIB

[0050] The process involves copying configuration parameter files from the existing configuration parameter library to the new one, and copying all configuration files from the original library to the new one. These copied configuration files will then be used as the source files for unified modification. This copying process can be implemented using the host's IEBOPY program.

[0051] The process involves uniformly modifying and adjusting the parameter configuration files in the new configuration parameter library based on the update items. This includes, but is not limited to: modifying references to the new parameter library starting from LOADxx; modifying references to file names in the parameter configuration files of each parameter library; uniformly replacing old and new software version numbers; and uniformly replacing references to new hardware in each parameter library. In terms of program implementation, the ISREDIT macro command provided by the host platform's REXX for ISPF can be used to uniformly replace strings in the configuration files within the aforementioned new configuration parameter library.

[0052] After uniformly modifying and adjusting the parameter configuration files in the new configuration parameter library, the modified configuration parameter library can be checked and confirmed. The specific implementation method is as follows:

[0053] The target content in the updated parameter configuration file is validated, wherein the target content includes at least one of the following: a reference to the first parameter library, a reference to the software version number corresponding to the first parameter library, or a reference to the software file name corresponding to the first parameter library.

[0054] In this embodiment, the modified configuration parameter library can be checked and confirmed. After completing the unified modification and adjustment of all new configuration libraries in the third step, the contents of each parameter configuration file in the modified new parameter library need to be checked to ensure that the replacement is complete. The scope of the check includes, but is not limited to, references to the original configuration parameter library, references to the original software version number, and references to the original software file name. The check keywords can be scanned using the SRCHFOR command of the ISRSUPC program in the host ISPF subsystem.

[0055] 3) When the subsystem is configured as an OMVS directory file, update the configuration of each subsystem according to the update item and the update strategy, including: determining a first directory file in the OMVS directory file according to the update item; determining the type of the first directory file, and determining a first update strategy for the first directory file according to the type of the first directory file; and updating the first directory file according to the first update strategy.

[0056] Specifically, if the type of the first directory file indicates that the first directory file is a read-only directory file, the first update strategy is determined to be to store the second directory file in the corresponding disk volume, wherein the version of the second directory file is higher than the version of the first directory file; if the type of the first directory file indicates that the first directory file is a read-write directory file, the first update strategy is determined to be to obtain the difference data between the first directory file and the second directory file, and modify the second directory file according to the difference data to obtain the third directory file.

[0057] The aforementioned difference data can be achieved by: determining the intersection data of the first directory file and the second directory file; determining other data in the first directory file besides the intersection data, and using the other data as the difference data.

[0058] When the OMVS directory files are updated, the OMVS directory files mounted at startup are divided into two categories. The first category is the OMVS directory files that come with the product during installation (equivalent to the read-only directory files in the above embodiments). These directory files are read-only and are copied from the media library to the target system during use. They can be mounted at startup for use. The second category is the OMVS directory files customized by users in each cluster environment (equivalent to the read-write directory files in the above embodiments). These OMVS directory files need to be reassigned during a new installation, and the contents of the previously used OMVS directory files are merged into the newly assigned OMVS directory files.

[0059] Maintenance of the OMVS directory file that comes with the first type of product during installation can be achieved by restoring it to the target environment after the OMVS directory file is installed in the media library through tape library backup. This can be done using the DUMP and RESTORE commands of the host DFSMS ADRDSSU program. At the same time, it is necessary to confirm the correctness of the reference to the new OMVS directory file in BPXPRMFS in SYS1.NEW.PARMLIB during the system parameter library modification process.

[0060] The maintenance of the second type of user-customized OMVS directory files mainly includes ETC directory files and VAR directory files. After restoring the new customized OMVS directory files from the media library to the target environment through backup, the first step is to mount the new customized OMVS directory files to meet the directory system's read and write requirements for such files. The second step is to compare the differences between the two customized OMVS directory files. The third step is to generate a merge job flow based on the difference comparison results. The fourth step is to import the content that needs to be retained from the original customized OMVS directory files into the new customized OMVS directory files through the merge job flow.

[0061] The first step is to mount the VAR and ETC directories. This can be done by using the host program IKJEFT01 to invoke the MOUNTFILESYSTEM command of the host UNIX service.

[0062] The second step involves comparing the differences between the two customized OMVS directory files. This can be done by calling the BPXBATCH program of the host UNIX service through the host program IKJEFT01, which in turn calls the UNIX SHELL diff command to perform a recursive comparison of the contents of the original ETC and VAR directory files with the new ETC and VAR directory files. The difference results are saved for use in the third step of merging.

[0063] The third step involves comparing the differences between the two customized OMVS directory files. Based on the difference results in the second step, a merge job flow can be formed. The content merge job flow can be prepared using the OSHELL command cp on the host UNIX service.

[0064] In the fourth step, the merge workflow imports the content that needs to be retained from the original customized OMVS directory file into the new customized OMVS directory file, and then submits the merge workflow for multiple VAR and ETC directory files in the third step to realize the directory merge operation.

[0065] To better understand the process of updating the system configuration described above, the implementation flow of updating the system configuration will be further described below with reference to optional embodiments, but this is not intended to limit the technical solution of the embodiments of this application.

[0066] First, let's introduce the business virtual machine:

[0067] For a business virtual machine in a host cluster, its key system configuration parameters consist of three parts: the software product installation volume, also known as the system volume (SYSRES volume), the virtual machine configuration parameter libraries, and the software product and customized OMVS (z / OS UNIX System Services) directory files.

[0068] Specifically, such as Figure 5 As shown in (1), the system volumes of products that operate basic software such as z / OS, DB2, and CICS on the host platform are usually installed using the ServerPAC (Server Package) tool that comes with the product. For some other software that cannot be installed through ServerPAC, they can be installed through CBPDO (Custom-Built Product Delivery Option). The ServerPAC tool provides a graphical installation process, and users can arrange the product files in a structured manner according to their own needs to realize the installation and setup process of key basic software. CBPDO uses a fixed template job flow (JCL - Job Control Language) to perform installation operations on products that cannot be installed by ServerPAC. Through the two installation methods, the installation and deployment of all host basic software can be realized. After the installation of the host basic software is completed, the system volumes of each new version of the product will no longer change. After disk library backup and restoration to the target system, the new system volume is used in the target system for subsequent new version software booting and other operations.

[0069] like Figure 5 As shown in (2), the second part of the key configuration parameters constituting the host platform consists of virtual machine parameter library files. These files include system key setting parameter libraries, different process startup script setting libraries, user-customized program libraries, host network VTAM and TCPIP configuration setting libraries, and executable program libraries pre-compiled by users or products. Each type of parameter library corresponds to a readable and writable parameter library file directory (except for executable program libraries). Each directory contains multiple configuration texts to set different parameter requirements. Specifically, they include the following:

[0070] The boot control file LOADxx (where xx is a 2-digit file extension) is stored in the SYS0.IPLPARM library and is allocated on the same physical disk volume as the host peripheral device definition file (IODF, Input / Output Definition File). The contents of this file include references to the system's main parameter library SYS1.OLD.PARMLIB.

[0071] The system's main parameter library is SYS1.OLD.PARMLIB, which is the root directory of the virtual machine parameter library. The IEASYMxx configuration file in this library primarily sets the parameters of the hardware used by the virtual machine and specifies the control files IEASYSxx for other subsystems of the virtual machine. The BPXPRMFS configuration file specifies a list of directory files required by the host UNIX system services (OMVS, z / OS UNIX System Services) that need to be automatically mounted when the virtual machine starts. The automatically mounted OMVS directories include directories provided with the product and directory files customized for different virtual machines. The PROG00 configuration file specifies a list of authorized programs that can access system memory at startup. The MSTJCL configuration file specifies the process startup configuration script library SYS1.OLD.PROCLIB used by each application (PROCEDURE).

[0072] The process startup configuration script library SYS1.OLD.PROCLIB specifies the startup configuration information for the processes that need to be started on the host virtual machine, including the configuration of basic operating system service processes and other subsystems such as DB2 and CICS. Specifically, it includes the JES2 configuration script for the Job Entry Subsystem (JES2), the VTAM (Virtual Telecommunication Access Method) network configuration script for the host SNA (System Network Architecture), the TCPIP configuration script for TCPIP, the OMVS configuration script for the host UNIX service processes, the OMPROUTE configuration script for the host OSPF (Open Shortest Path First) dynamic routing, and the TN3270 configuration script for the host Telnet; and startup configuration scripts for other subsystems such as DB2, CICS, and MQ (message queue) startup scripts.

[0073] The user-defined program library SYS1.OLD.CMDPROC contains user-implemented CLIST (commandlist) and REXX (Restructured Extended Executor) interpreted programs. These programs can improve the efficiency of system administrators in maintaining the system. A typical example is the main interface (Panel) that users see after logging into the system. Users can add new subsystem entries to the main interface to improve the efficiency of jumping to different subsystems.

[0074] The user interaction subsystem ISPF (Interactive System Productivity Facility) customization library SYS1.OLD.ISPPLIB contains the system's customization configuration files for user operations within the system, such as file management and session management.

[0075] The custom library SYS1.OLD.VTAMLST contains configuration information related to the host SNA network implementation process VTAM, including the network name NETID, peripheral connection device name CPNAME, SNA configuration information on the TCP / IP network (SNA / TCPIP, SNA OVER TCPIP), network card configuration, etc. This is a collection of traditional host network configuration files ATCCONxx and ATCSTRxx.

[0076] The TCP / IP custom configuration library SYS1.OLD.TCPPPARMS contains configuration files for IP addresses and port bindings used by virtual machines, dynamic routing OSPF configuration files, and remote connection Telnet configuration files, including files such as TNPROFxx, ONLPxxEN, and TNPROFx.

[0077] The compiled executable library SYS1.OLD.LINKLIB contains the binary programs that need to be loaded into memory after the system boots up. The contents of this library cannot be modified.

[0078] like Figure 5 As shown in (3), the third part of the key system configuration of the host platform is the host operating system z / OS host UNIX system service directory file. This type of file can be divided into two categories. One type of file is a user-defined custom directory file, such as ETC, VAR, etc. required by each business unit. If the basic software is upgraded, the new version of the program needs to be used to redistribute the files. However, the custom content in the old version needs to be merged into the new version file and used as a combination of the old and new versions. The other type is the OMVS directory file required by the software installed with the product. It needs to be automatically mounted at startup to be used. This type of file cannot be modified and is in read-only mode. When using it, the user can back up and restore this type of file from the media library to the target environment. The startup mounting of this type of file is achieved by modifying the file BPXPRMFS in the SYS1.OLD.PARMLIB library in advance.

[0079] To better understand the process of updating the system configuration described above, this application also proposes a system configuration updating device, such as... Figure 6 As shown, Figure 6This is a schematic diagram of a system configuration update device in an embodiment of this application. The device consists of four modules: a product system volume maintenance module, a parameter library maintenance module, an OMVS directory file maintenance module, and a system configuration verification module.

[0080] The product system volume maintenance module includes: a new version media installation unit and a system volume copy unit. The new version media installation unit is used to install the new version of the product system volume; the system volume copy unit is used to copy the new version of the product system volume to the target environment.

[0081] The parameter library maintenance module includes: a parameter library allocation unit, a parameter file copying unit, a parameter library parameter modification unit, and a parameter library verification unit;

[0082] The parameter library allocation unit is used to allocate new parameter libraries, and consists of a job that allocates multiple parameter libraries.

[0083] The parameter file copy unit is used to copy parameter configuration files from multiple existing configuration parameter libraries to multiple new configuration parameter libraries, and consists of a single copy job.

[0084] The parameter library parameter modification unit is used to modify and adjust multiple parameter configuration files in the multiple parameter libraries as needed, and consists of a modification job;

[0085] The parameter library verification unit is used to check the modification results of multiple configuration files of multiple parameter libraries after modification, and to confirm that all keyword replacement operations have been completed within the scope of modification.

[0086] The OMVS directory file maintenance module includes: an OMVS directory file copy and mount unit, an OMVS directory file difference comparison unit, an OMVS directory file difference import unit, and an OMVS directory file difference content verification unit;

[0087] The OMVS directory file copy and mount unit is used for creating customized OMVS directory files in the new version, mounting them on the target system, and backing up and restoring the product's built-in read-only OMVS directory files. It consists of an OMVS directory allocation and mount job, a backup job for a read-only OMVS directory file, and a restore job for a read-only OMVS directory file.

[0088] The OMVS directory file difference comparison unit is used to compare the differences between the customized content in the old and new versions and form the difference comparison results. It consists of a job that performs difference comparison on multiple ETC and VAR directory files.

[0089] The OMVS directory file difference import unit is used to perform a merging operation based on the difference results of the directory file difference comparison unit. It consists of a merging job for multiple customized OMVS directory file difference contents.

[0090] The OMVS directory file difference content check unit checks the content of the merged new customized OMVS directory file and consists of a check job.

[0091] The system configuration verification module assists in verifying the accuracy of newly modified parameters during the system's startup process. For example... Figure 7 As shown, the system configuration verification module consists of a virtual machine 1 deployed in a z / VM virtual machine. It is started with a new system volume, a new configuration library, and a new OMVS directory file. The accuracy of the modifications is checked through the startup process.

[0092] It should be noted that the above-mentioned job workflow scheduling specifically includes two parts: the scheduling of the product installation completion phase and the scheduling of the target cluster parameter configuration update phase, such as... Figure 8 As shown.

[0093] The product installation completion phase schedule consists of system volume backup jobs and OMVS directory file backup jobs, which can be submitted in the media library environment to perform backup operations on the required system volumes and OMVS directory files to the tape library.

[0094] The target cluster parameter configuration update phase schedule consists of three types of job flows: the first type is configuration recovery jobs, the second type is jobs that update the configuration parameter library and configuration files, and the third type is jobs that customize and merge the customized content in the old and new directory files of the OMVS directory.

[0095] Specifically, the first type of configuration recovery job includes system volume recovery job and OMVS directory recovery job;

[0096] The second category involves updating the configuration parameter library and configuration files. Specific tasks include new parameter library allocation, configuration file copying, configuration file modification, and configuration file verification.

[0097] The third category of OMVS directory files involves customizing and merging custom content from old and new directory files. Specific tasks include directory file mounting, directory file difference comparison, difference result import, and directory content verification.

[0098] For the target cluster parameter configuration update phase job scheduling:

[0099] 1. The product system volume recovery job and the OMVS directory file recovery job are run in the target cluster;

[0100] 2. Implement the parameter library adjustment and modification jobs, specifically including new parameter library allocation job, configuration file copy job, configuration file modification job, and configuration file verification job, which are run in the target cluster;

[0101] 3. Implement the OMVS directory file customization modification job, including directory file mounting job, directory file difference comparison job, difference result import job, and directory content check job, and run them in the target cluster.

[0102] Correspondingly, such as Figure 9 As shown, the storage medium in this embodiment includes a disk volume storing installation files for each product for booting, and a tape library device for backup and recovery operations.

[0103] In this embodiment of the application, for a host cluster consisting of multiple operating system instances, database instances, and transaction middleware instances, the number of parameter libraries is large, and the configuration files in each library are also numerous. When encountering implementation stages such as centralized adjustment of hardware-related parameters during basic software upgrades or hardware upgrades, the overall workload of parameter adjustment and maintenance is large. If implemented manually, problems such as misoperation and omission of modifications are likely to occur. When performing parameter synchronization operations on multiple host clusters, the above implementation actions are highly repetitive, and the traditional method is inefficient, which may lead to the implementation speed failing to meet the schedule requirements.

[0104] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0105] This application provides a system configuration update device. Figure 10 This is a structural block diagram of a system configuration update device according to an exemplary embodiment of this application, such as... Figure 10 As shown, it includes:

[0106] The partitioning module 1002 is used to divide the host platform system configuration into multiple subsystem configurations, wherein the subsystem configurations include: product system volume, configuration parameter library, and OMVS directory file;

[0107] The determination module 1004 is used to determine the update items and update strategies corresponding to each subsystem configuration when the host platform system configuration is updated.

[0108] The update module 1006 is used to update the configuration of each subsystem according to the update item and the update strategy.

[0109] The aforementioned apparatus divides the host platform system configuration into multiple subsystem configurations, each subsystem configuration including: a product system volume, a configuration parameter library, and an OMVS directory file. When the host platform system configuration is updated, the update items and update strategies for each subsystem configuration are determined. Each subsystem configuration is then updated according to the update items and update strategies. Specifically, this application divides the host platform system configuration into three subsystem configurations and assigns a corresponding update strategy to each subsystem configuration. When any subsystem configuration is updated, the corresponding subsystem configuration is updated according to the corresponding update strategy. This technical solution addresses the problems in related technologies where the total amount of system configuration modifications is too large, and the risk of erroneous modifications and omissions that may occur during manual operation.

[0110] In an exemplary embodiment, when the subsystem is configured as a product system volume, the update module 1006 is used to determine whether the media corresponding to any product system volume has been updated, based on the update item, when there are multiple product system volumes; and when any product system volume has been updated, to store the updated product system volume in the corresponding disk volume.

[0111] In an exemplary embodiment, when the subsystem is configured as a configuration parameter library, the update module 1006 is used to create a second parameter library according to the rules of the first parameter library, and copy the parameter configuration file of the first parameter library to the second parameter library, wherein the rules include at least: file naming rules and file attribute rules; and update the parameter configuration file in the second parameter library according to the update item to obtain the updated parameter configuration file.

[0112] In an exemplary embodiment, the update module 1006 is used to verify the target content in the updated parameter configuration file, wherein the target content includes at least one of the following: a reference to the first parameter library, a reference to the software version number corresponding to the first parameter library, and a reference to the software file name corresponding to the first parameter library.

[0113] In an exemplary embodiment, when the subsystem is configured as an OMVS directory file, the update module 1006 is configured to determine a first directory file in the OMVS directory file according to the update item; determine the type of the first directory file, and determine a first update strategy for the first directory file according to the type of the first directory file; and update the first directory file according to the first update strategy.

[0114] In an exemplary embodiment, the update module 1006 is configured to: when the type of the first directory file indicates that the first directory file is a read-only directory file, determine that the first update strategy is to store the second directory file in the corresponding disk volume, wherein the version of the second directory file is higher than the version of the first directory file; when the type of the first directory file indicates that the first directory file is a read-write directory file, determine that the first update strategy is to obtain the difference data between the first directory file and the second directory file, and modify the second directory file according to the difference data to obtain the third directory file.

[0115] In an exemplary embodiment, the update module 1006 is configured to determine the intersection data of the first directory file and the second directory file; determine other data in the first directory file besides the intersection data, and use the other data as the difference data.

[0116] Embodiments of this application also provide a storage medium including a stored program, wherein the program executes any of the methods described above when it is run.

[0117] Optionally, in this embodiment, the storage medium may be configured to store program code for performing the following steps:

[0118] S1, the host platform system configuration is divided into multiple subsystem configurations, wherein the subsystem configurations include: product system volume, configuration parameter library, and OMVS directory file;

[0119] S2, if the host platform system configuration is updated, determine the update item and update strategy corresponding to each subsystem configuration;

[0120] S3, update the configuration of each subsystem according to the update item and the update strategy.

[0121] Embodiments of this application also provide an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0122] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0123] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0124] S1, the host platform system configuration is divided into multiple subsystem configurations, wherein the subsystem configurations include: product system volume, configuration parameter library, and OMVS directory file;

[0125] S2, if the host platform system configuration is updated, determine the update item and update strategy corresponding to each subsystem configuration;

[0126] S3, update the configuration of each subsystem according to the update item and the update strategy.

[0127] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0128] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0129] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0130] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for updating system configuration, characterized in that, include: The host platform system configuration is divided into multiple subsystem configurations, which include: product system volume, configuration parameter library, and OMVS directory files; If the host platform system configuration is updated, determine the update items and update strategies corresponding to each subsystem configuration; Update the configuration of each subsystem according to the update item and the update strategy; Specifically, when the subsystem is configured as a product system volume, updating the configuration of each subsystem according to the update item and the update policy includes: when there are multiple product system volumes, determining whether the media corresponding to any product system volume has been updated according to the update item; and when any product system volume has been updated, storing the updated product system volume in the corresponding disk volume. Wherein, when the subsystem is configured as a configuration parameter library, updating the configuration of each subsystem according to the update item and the update strategy includes: creating a second parameter library according to the rules of the first parameter library, and copying the parameter configuration file of the first parameter library to the second parameter library, wherein the rules include at least: file naming rules and file attribute rules; updating the parameter configuration file in the second parameter library according to the update item to obtain the updated parameter configuration file; Wherein, when the subsystem is configured as an OMVS directory file, updating the configuration of each subsystem according to the update item and the update strategy includes: determining a first directory file in the OMVS directory file according to the update item; determining the type of the first directory file, and determining a first update strategy for the first directory file according to the type of the first directory file, wherein the type of the first directory file includes at least one of the following: a read-only directory file type, a read-write directory file type; and updating the first directory file according to the first update strategy.

2. The system configuration update method according to claim 1, characterized in that, After updating the parameter configuration file in the second parameter library according to the update item, the method further includes: The target content in the updated parameter configuration file is validated, wherein the target content includes at least one of the following: a reference to the first parameter library, a reference to the software version number corresponding to the first parameter library, or a reference to the software file name corresponding to the first parameter library.

3. The system configuration update method according to claim 1, characterized in that, Determining a first update strategy for the first directory file based on its type includes: If the type of the first directory file indicates that the first directory file is a read-only directory file, the first update strategy is determined to be to store the second directory file in the corresponding disk volume, wherein the version of the second directory file is higher than the version of the first directory file; If the type of the first directory file indicates that the first directory file is a read-write directory file, the first update strategy is determined to be to obtain the difference data between the first directory file and the second directory file, and modify the second directory file according to the difference data to obtain the third directory file.

4. The system configuration update method according to claim 3, characterized in that, Obtain the differences between the files in the first directory and the files in the second directory, including: Determine the intersection data of the first directory file and the second directory file; In the first directory file, other data besides the intersection data is identified, and the other data is used as the difference data.

5. A system configuration update device, characterized in that, include: The partitioning module is used to divide the host platform system configuration into multiple subsystem configurations, wherein the subsystem configurations include: product system volume, configuration parameter library, and OMVS directory file; The determination module is used to determine the update items and update strategies corresponding to each subsystem configuration when the host platform system configuration is updated. The update module is used to update the configuration of each subsystem according to the update item and the update strategy; Wherein, when the subsystem is configured as a product system volume, the update module is further configured to, when there are multiple product system volumes, determine whether the media corresponding to any product system volume has been updated based on the update item; and when any product system volume has been updated, store the updated product system volume into the corresponding disk volume. Wherein, when the subsystem is configured as a configuration parameter library, the update module is further configured to create a second parameter library according to the rules of the first parameter library, and copy the parameter configuration file of the first parameter library to the second parameter library, wherein the rules include at least: file naming rules and file attribute rules; and update the parameter configuration file in the second parameter library according to the update item to obtain the updated parameter configuration file; Wherein, when the subsystem is configured as an OMVS directory file, the update module is further configured to determine a first directory file in the OMVS directory file according to the update item; determine the type of the first directory file, and determine a first update strategy for the first directory file according to the type of the first directory file, wherein the type of the first directory file includes at least one of the following: a read-only directory file type, a read-write directory file type; and update the first directory file according to the first update strategy.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method described in any one of claims 1 to 4.

7. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method described in any one of claims 1 to 4 through the computer program.

Images