Selective pruning of system configuration models for system reconfiguration

Abstract

A method, computer program product, and computer system are disclosed for reconfiguring a computing environment from an current input / output (I / O) configuration to a desired I / O configuration. The method may include normalizing respective hierarchical models of the current I / O configuration and the desired I / O configuration. Each of the hierarchical models comprises a hierarchical structure of leaf nodes and non-leaf nodes. The normalizing includes applying syntactic transformation rules to the first hierarchical model and the second hierarchical model such that the I / O configurations of each of the first hierarchical model and the second hierarchical model are defined in a syntactically consistent manner. The method may include creating hash tree representations of each of the first hierarchical model and the second hierarchical model. Nodes of the hash tree representations are checksum values. The nodes of the hash tree representations reflect the hierarchical structure of the respective hierarchical models. The method may include pruning one or more nodes of the hash tree representations.

Description

[Technical Field]

[0001] One or more aspects relate generally to facilitating processing within a computing environment, and more particularly to comparing system input / output (I / O) configurations of a computing environment in response to system I / O reconfigurations of the computing environment's hardware and software to facilitate processing within the computing environment. [Background technology]

[0002] Configuring a computing environment involves defining and activating various hardware and software components of the computing environment, including, but not limited to, logical partitions, input / output (I / O) configuration, operating system, etc. The I / O configuration is a definition of the hierarchically structured hardware and software components of the computing environment. Products can be used to facilitate such configuration definition. For example, the Hardware Configuration Definition (HCD) product offered by International Business Machines Corporation of Armonk, New York, can be used to define and activate the I / O configuration.

[0003] Hardware configuration definition products provide a panel-driven interface that allows elements, such as I / O devices, to be defined and connected to and used by logical partitions and operating systems. Hardware configuration definition products and other such products can also be used in reconfiguring a computing environment once it has been configured.

[0004] Currently, when multiple I / O elements within a defined, existing I / O configuration are reconfigured, the desired I / O configuration must be compared to the existing I / O configuration before the desired I / O configuration can be applied to a computing environment. However, the process of comparing the desired I / O configuration to the existing I / O configuration to identify changes is typically computationally intensive and resource-demanding when performed in a resource-constrained environment as part of the computing environment's firmware. The problems associated with this process become even worse as the complexity and size of the I / O configuration increase. Summary of the Invention [Means for solving the problem]

[0005] Shortcomings of the prior art are overcome and further advantages are provided through embodiments of the present invention. Embodiments of the present invention may include a method, a computer program product, and a computer system for reconfiguring a computing environment from a current input / output (I / O) configuration to a desired I / O configuration. One embodiment may include normalizing a first hierarchical model of the current I / O configuration and a second hierarchical model of the desired I / O configuration. The first hierarchical model and the second hierarchical model each comprise a hierarchical structure of leaf nodes and non-leaf nodes. Normalizing includes applying syntactic transformation rules to the first hierarchical model and the second hierarchical model such that their respective I / O configurations are defined in a syntactically consistent manner across the first hierarchical model and the second hierarchical model. One embodiment may include creating a first hash tree representation of the first hierarchical model and a second hash tree representation of the second hierarchical model. The nodes of the first hash tree representation are checksum values ​​calculated for leaf nodes and non-leaf nodes of the first hierarchical model. The nodes of the second hash tree representation are checksum values ​​calculated for leaf nodes and non-leaf nodes of the second hierarchical model. The nodes of the first hash tree representation and the nodes of the second hash tree representation reflect the hierarchical structure of the first hierarchical model and the hierarchical structure of the second hierarchical model, respectively. One embodiment may include pruning one or more nodes of the first hash tree representation and the second hash tree representation where checksum values ​​are equal up to the root node of the first hash tree representation and the root node of the second hash tree representation.

[0006] The proposed method, computer program product, and computer system for reconfiguring a computing environment from a current input / output (I / O) configuration to a desired I / O configuration provide multiple benefits and technical effects. For example, computing environment resources not used by internal processes (e.g., I / O configuration comparison) can be freed and made available to users of the computing environment. Computing environment memory for subtrees with equal checksum values ​​can be safely freed. Additionally, computing environment network traffic is reduced because the size of I / O reconfiguration requests is reduced. Furthermore, faster comparison of I / O configurations is achieved because comparisons for subnodes (e.g., I / O subelements) of equal parent nodes are not required.

[0007] In the following, additional embodiments of the inventive concept, namely its applicability to methods, computer program products and computer systems, will be described.

[0008] According to an advantageous embodiment, the current I / O configuration is defined by a current input / output definition file (IODF), and the desired I / O configuration is defined by a desired IODF, both of which comprise binary data structures similar to relational databases with tables and cross-references.

[0009] According to an advantageous embodiment, the first hierarchical model and the second hierarchical model are based on the current IODF and the desired IODF, respectively. Here, the hierarchical model is a text-based JavaScript object notation (JSON) data structure including hierarchically nested leaf and non-leaf nodes and one or more cross-references between them. The leaf and non-leaf nodes represent I / O elements of the IODF. Deriving the hierarchical model includes iteratively parsing the IODF to collect a plurality of I / O elements (including their properties) contained in the IODF; and deriving the plurality of I / O elements ... 登録商標 Combining the domain model defined by the classes; and serializing the domain model into a JSON data structure.

[0010] According to an advantageous embodiment, the leaf and non-leaf nodes of the first hierarchical model represent I / O elements in the current I / O configuration, the leaf and non-leaf nodes of the second hierarchical model represent multiple I / O elements in the desired I / O configuration, and the syntax transformation rules may be specific to each I / O element in an I / O configuration and may need to be applied in a specific order.

[0011] According to an advantageous embodiment, the method, the computer program product, and the computer system may further include pruning one or more nodes of the second hash tree representation where checksum values ​​are the same between the first hash tree representation and the second hash tree representation.

[0012] According to an advantageous embodiment, the method, the computer program product, and the computer system may further include persisting the first hash tree representation of the first hierarchical model and the second hash tree representation of the second hierarchical model in a memory of the computing environment.

[0013] One or more aspects are particularly pointed out and distinctly claimed by way of example in the appended claims. The objects, features, and advantages of the above-discussed and one or more aspects will become apparent from the following detailed description taken in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0014] [Figure 1A] FIG. 1A illustrates one example of a computing environment for incorporating and using one or more aspects of the present invention. [Figure 1B] FIG. 1B illustrates one example of further details of the computing environment of FIG. 1A in accordance with one or more aspects of the present invention. [Figure 2] FIG. 2 illustrates one example of using a pruner module to reconfigure a hardware configuration in accordance with one or more aspects of the present invention. [Figure 3] FIG. 3 illustrates an input / output definition file 310 of a computing environment 300 in accordance with one or more aspects of the present invention. [Figure 4] FIG. 4 illustrates an current input / output definition file 410 and a desired input / output definition file 420 in accordance with one or more aspects of the present invention. [Figure 5] FIG. 5 is a flow chart diagram illustrating the operation of the pruner module of FIG. 2 in accordance with one or more aspects of the present invention. [Figure 6] FIG. 6 illustrates a resulting JavaScript object notation hierarchy model 600 derived from input / output definition files in accordance with one or more aspects of the present invention. [Figure 7] FIG. 7 illustrates an exemplary normalization 700 of a portion of an existing input / output definition file in accordance with one or more aspects of the present invention. [Figure 8] FIG. 8 illustrates a portion 800 of a checksum value calculated for a normalized hierarchical model of the current input / output definition file of FIG. 7 in accordance with one or more aspects of the present invention. [Figure 9]FIG. 9 illustrates a portion of a hash tree representation of a normalized input / output definition file in accordance with one or more aspects of the present invention. [Figure 10] FIG. 10 illustrates comparison and change detection between portions of the hash tree representation of the normalized input / output definition file of FIG. 9 in accordance with one or more aspects of the present invention. [Figure 11] FIG. 11 illustrates pruned nodes of the hash tree representation of FIG. 9 in accordance with one or more aspects of the present invention. [Figure 12] FIG. 12 illustrates a logical view of an I / O configuration along with a JSON hierarchical model of the I / O configuration in accordance with one aspect of the present invention. [Figure 13] FIG. 13 illustrates an exemplary partition renaming scenario 1300 in accordance with an aspect of the present invention. [Figure 14] FIG. 14 illustrates an exemplary partition addition scenario 1400 in accordance with an aspect of the present invention. [Figure 15] FIG. 15 illustrates an exemplary device addition scenario 1500 in accordance with an aspect of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0015] An input / output (I / O) configuration defines a set of hardware and software resources available to the operating system of a hierarchically structured computing environment, as well as the connections between these resources. When defining an I / O configuration, both physical information (e.g., type, model) and logical information (e.g., assigned device identifiers) about the hardware and software resources are provided. For example, when defining an I / O configuration, one or more of the following elements for the computing environment may be specified: an operating system; an eligible device table (EDT) with esoteric device groups; one or more processors; a logical channel subsystem; PCIe functions; partitions; channel paths on one or more processors; switches attached to the channel paths; control units attached to the channel paths or switches; and I / O devices in one or more subchannel sets and connected to the control units.

[0016] As described above, when multiple I / O elements within a defined configuration are to be reconfigured, the desired (to-be) configuration must be analyzed and compared to an existing baseline (current) configuration before it can be activated within the computing environment. As computing environments become more complex, the corresponding I / O configuration definitions can become large (e.g., hundreds of MB). As such, current techniques for analyzing and comparing I / O configuration definitions (i.e., I / O reconfiguration) require analyzing all I / O elements within a configuration definition and looping through them to identify relationships, which is computationally expensive and resource intensive (i.e., requires processor and memory utilization within the computing environment and generates network traffic). This problem becomes increasingly time-consuming and disadvantageous for computing systems, given that I / O configuration comparisons are typically performed within resource-constrained environments as part of the computing system's firmware.

[0017] As an example, consider an enterprise scenario in which a reconfiguration consisting of small incremental I / O configuration changes, represented by a to-be I / O configuration definition, is proposed for a large current I / O configuration definition. In such a scenario, before the to-be I / O configuration definition can be implemented (i.e., activated) within a computing environment, the to-be I / O configuration must be compared with the current I / O configuration to identify changes resulting from the reconfiguration. As a result, even though the required action is small (i.e., a small incremental I / O configuration change), significant processing time is spent by the computing environment analyzing and comparing the I / O configurations. Moreover, when comparing the to-be I / O configuration with the current I / O configuration, unnecessary information (e.g., the complete models of the current I / O configuration and the corresponding to-be I / O configuration are largely similar and reflect only small incremental configuration changes, and some parts of the current I / O configuration and some parts of the to-be I / O configuration are the same) is stored in the computing environment's memory, thus using valuable storage space. Moreover, both I / O configurations (the current I / O configuration and the desired I / O configuration) need to be transmitted over the internal network of the computing environment to be activated, thus generating a significant amount of network traffic.

[0018] In response to the above-described problems associated with current techniques for comparing I / O configuration definitions resulting from I / O reconfiguration, embodiments of the present invention propose a novel and advantageous approach for implementing I / O reconfiguration by performing a side-by-side comparison of two I / O configuration definitions (e.g., a current I / O configuration and a desired I / O configuration) and selectively pruning (i.e., removing) one or more elements of the two I / O configuration definitions, thereby improving resource consumption and execution time within a computing environment. More specifically, the novel and advantageous approach disclosed through embodiments of the present invention includes creating a hierarchical model of each I / O configuration definition to facilitate comparison; iteratively processing the I / O configurations without having to maintain a complete model for each configuration in memory; utilizing a checksum mechanism to more quickly determine differences between two I / O configurations; and selectively pruning one or more I / O configurations based on the checksum values ​​before sending the checksum values ​​over the computing environment's internal network for activation.

[0019] One or more aspects of the present invention relate to system reconfiguration, e.g., dynamic hardware reconfiguration within a computing environment, which allows hardware and software components of a computing environment, such as logical partitions, control units, input / output (I / O) devices, operating systems, etc., to be reconfigured without requiring an initial program load (IPL) or power on reset (POR).

[0020] One embodiment of a computing environment for incorporating and using one or more aspects of the present invention is described with reference to Figure 1A. In one example, the computing environment is a z / Architecture 登録商標Based on the hardware architecture, examples are described in the publication entitled "z / Architecture Principles of Operation," IBM Publication No. SA22-7832-12, 13th edition, September 2019. However, z / Architecture 登録商標 The hardware architecture is just one exemplary architecture, and other architectures or other types of computing environments that utilize stored I / O configuration definitions, or combinations thereof, may include or use, or include and use, one or more aspects of the present invention.

[0021] In one example, computing environment 100 includes a central processing unit complex 102, one example of which may be, as a particular example, one or more IBM z15 商標 IBM Z with systems 登録商標 Other central processing unit complexes or other systems based on the same or other hardware architectures, or combinations thereof, may also incorporate and use one or more aspects of the present invention. 登録商標 z / Architecture 登録商標 , IBM 登録商標 Z 登録商標 , and IBM 登録商標 z15 登録商標 are trademarks or registered trademarks of International Business Machines Corporation in at least one jurisdiction. As one example, central processing unit complex 102 may include, for example, memory 104 (also known as system memory, main memory, main storage, central storage, storage) connected to one or more processors (also known as central processing units (CPUs)) 106, and input / output subsystem 108, each of which is further described below.

[0022] The memory 104 may include, for example, one or more logical partitions 110, a hypervisor 112 that manages the logical partitions, and processor firmware 114. One example of a hypervisor 112 is the Processor Resource / System Manager (PR / SM) offered by International Business Machines Corporation of Armonk, New York. 商標 ) hypervisor. As used herein, firmware includes, for example, processor microcode, which may comprise, for example, hardware-level instructions or data structures, or a combination thereof, used in implementing higher-level machine code. In one embodiment, it includes, for example, trusted software or proprietary code typically distributed as microcode that includes microcode specific to the underlying hardware and controls operating system access to system hardware. PR / SM is a trademark or registered trademark of International Business Machines Corporation in at least one jurisdiction.

[0023] Each logical partition 110 includes an operating system (e.g., O / S 1-O / S 3) 116, e.g., z / OS 登録商標 The z / OS operating system, or other operating systems, may run different programs (e.g., App.A-App.F) 118. 登録商標 are trademarks or registered trademarks of International Business Machines Corporation in at least one jurisdiction.

[0024] Memory 104 is connected to processors (e.g., CPU 0-CPU n) 106, which are physical processor resources that may be assigned to logical partitions. For example, a logical partition 110 may include one or more logical processors, each representing all or a portion of the physical processor resources 106 that may be dynamically assigned to that logical partition.

[0025] Additionally, memory 104 is connected to an I / O subsystem 108, which may be part of or separate from a central processing complex, and which directs the flow of information between main storage 104 and an input / output control unit 120 or input / output (I / O) devices 122, or a combination thereof, connected to the central processing complex.

[0026] Many types of I / O device 122 may be used. One particular type is a data storage device 130. The data storage device 130 may store one or more programs 132, one or more computer-readable program instructions 134, or data, or any combination thereof. The computer-readable program instructions may be configured to perform the functions of embodiments of aspects of the present invention.

[0027] Central processing unit complex 102 includes or is connected to, or includes and is connected to, removable / non-removable, volatile / non-volatile computer system storage media. For example, central processing unit complex 102 includes or is connected to, or includes and is connected to, non-removable, non-volatile magnetic media (typically referred to as a "hard disk"), a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), or an optical disk drive for reading from and writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media, or a combination thereof. It should be understood that other hardware or software components or combinations thereof can be used in combination with central processing unit complex 102. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data archive storage systems, etc.

[0028] Moreover, central processing unit complex 102 may be operational with numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use with central processing unit complex 102 include, but are not limited to, personal computer (PC) systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments comprising any of the above systems or devices.

[0029] Further details regarding one embodiment of a computing environment, such as computing environment 100, are described with reference to FIG. 1B. In one embodiment, input / output (I / O) subsystem 108 is a channel subsystem 150 that receives commands in a channel program from one or more operating systems (e.g., operating system 116). The channel program includes one or more channel command words (CCWs), and each channel command word includes a command (e.g., read, write, control) and a data address for use in data communication. The channel subsystem forwards the commands, e.g., via channel 152, to one or more communication components of the computing environment, e.g., one or more switches 154, which in one example are connected to one or more control units 120. The one or more control units are connected to one or more I / O devices 122. The one or more switches obtain requested information based on the commands, e.g., from one or more I / O devices 122, and return the results to one or more operating systems.

[0030] In accordance with one or more aspects, a computing environment, such as computing environment 100, may be dynamically reconfigured by, for example, adding, modifying, or removing one or more I / O elements, such as logical partitions, one or more control units, or one or more devices, or any combination thereof. To perform the hardware reconfiguration, in one example, a hardware configuration definition is used, as described with reference to FIG. 2.

[0031] As shown in FIG. 2, in one example, a hardware configuration definition (HCD) product 200 may be configured to run an operating system, operating system 116 (e.g., z / OS 登録商標 The hardware configuration definition product 200 runs on one or more servers (e.g., IBM Z) of a computing environment (e.g., computing environment 100).登録商標 The hardware configuration definition product 200 is used to define and activate the I / O configuration of a storage system (e.g., a server) and its operating system. For example, the hardware configuration definition product 200 defines elements from a storage system, such as I / O devices, and connects them to partitions and operating systems to enable their use on a set of other I / O elements. The configuration defining the I / O elements may be stored in a binary data structure. For example, the output of the hardware configuration definition product 200 is an input / output definition file (IODF) that contains both hardware and software configuration data for a computing environment (e.g., computing environment 100). The IODF may be represented as a binary data structure similar to a relational database with tables and cross-references, may be optimized for memory usage, and may define multiple hardware and software configurations for an operating system. For example, the IODF may include information about the I / O configuration, such as operating system data, switch data, device data, processor data, partition data, channel path data, control unit data, and channel subsystem data. By way of example, FIG. 3 illustrates an IODF 310 for a logically represented computing environment 300. The IODF 310 describes / defines the allocation of partitions (P) among multiple control units (CUs) and I / O devices (I / O Devs) via separate channel paths. When the hardware configuration definition product 200 activates an IODF (e.g., IODF 310), it defines the I / O configuration to the channel subsystem, the operating system, or both.

[0032] When activating a desired (to-be) I / O configuration (e.g., a to-be IODF), the I / O elements defined therein must be analyzed and compared to a baseline (current) I / O configuration (e.g., a current IODF) to identify changes. By way of example, FIG. 4 illustrates current IODF 410 and to-be IODF 420. Current IODF 410 may define computing environment 300 of FIG. 3, and to-be IODF 420 may define changes (represented by bold black binary text) to computing environment 300 of FIG. 3. The changes defined by to-be IODF 420 are logically illustrated by computing environment 400 and include adding a partition (Pa) and removing a control unit (CUd). However, before the to-be IODF 420 can be submitted for activation, it must be compared to the current IODF 410 so that changes in the I / O configuration depicted by the computing environment 400 (i.e., adding Pa and removing CUd) can be identified.

[0033] In one example, hardware configuration definition product 200 is a panel-driven interface that facilitates the definition of multiple I / O elements of the computing environment and communicates with an interface, such as HCD support element (SE) interface 202, running on a support element 204. Support element 204 is, for example, a notebook or server connected to the central processing unit complex. It may be part of the central processing unit complex or may be separate from it. HCD support element interface 202 is, for example, a command line interface that communicates with a service, such as activation service 210, running on an internal firmware partition (e.g., processor firmware 114).

[0034] In one exemplary embodiment, the pruner module 203 may be a program or a subroutine included within a program to compare two IODFs (e.g., an as-is IODF and a to-be IODF) side-by-side and selectively prune elements from one or more of the two IODFs, thereby improving resource consumption and execution time within the computing environment. More specifically, in an exemplary embodiment, the pruner module 203 may create a hierarchical model of each IODF to facilitate comparison; iteratively process IODFs without having to keep a complete model for each IODF in memory; utilize a checksum mechanism to more quickly determine differences between two IODFs; and selectively prune one or more portions corresponding to multiple IO elements from one or more IODFs based on the checksum value before sending the checksum value over the computing environment's internal network for activation. In an exemplary embodiment, pruner module 203 executes on support element 204 and communicates with hardware configuration definition product 200 via HCD support element (SE) interface 202 and communicates with services, such as activation service 210, executing on an internal firmware partition (e.g., processor firmware 114). In another embodiment, pruner module 203 is integrated within hardware configuration definition product 200 and communicates with an operating system, such as operating system 116 (e.g., z / OS 登録商標 One example of the operation and functionality of the pruner module 203 is described in further detail below with respect to FIG.

[0035] The activation service, in one embodiment, is used to at least initiate requested I / O configuration changes (e.g., configuration changes defined in a desired IODF). For example, in one example, the activation service makes calls (e.g., channel subsystem calls (CHSC)) to a channel subsystem (e.g., channel subsystem 150) to perform the respective changes, such as defining partitions, adding / modifying / deleting channels, control units, or I / O devices, or a combination thereof, and stores information about the I / O configuration changes in hardware storage area 220. While various I / O configuration changes are provided as examples, many other I / O configuration changes may be made without departing from the scope of the present invention.

[0036] In one embodiment, to change a system's I / O configuration, a system administrator goes through a series of preparatory steps. A dynamic hardware activation phase is then initiated, during which the I / O configurations (current and desired I / O configurations) are sent and activated over an internal network, and the system administrator waits for completion, which currently can take hours or even days, depending on the computing environment's resource constraints and the reconfiguration aspects (e.g., amount of I / O changes, size of IODFs). Thus, in accordance with one aspect of the present invention, a superior approach to system I / O reconfiguration is presented that reduces resource (e.g., CPU and memory) consumption and improves execution time (e.g., activation time) within a computing environment by comparing two I / O configurations (e.g., two IODFs) side-by-side and thereby selectively pruning elements within one or both of the I / O configurations before submitting them for activation via a service, e.g., activation service 210, and storing them, e.g., in hardware storage area 220.

[0037] An advantage of the present invention is that resources not used by internal processes of a computing environment related to I / O reconfiguration are freed up and made available for use. Another advantage of the present invention is reduced network traffic associated with I / O reconfiguration as a result of a reduction in the size of the requested I / O configuration (e.g., sending a smaller IODF file). Portions of I / O configurations that are determined to be equal through comparison may be sent over the network only once or not at all. Another advantage of the present invention is reduced memory consumption within the computing environment because elements in I / O configurations that are determined to be equal through comparison do not need to be stored in memory. Yet another advantage of the present invention is faster comparison of I / O configurations (e.g., comparing the to-be and current IODFs) because comparison of corresponding subelements between I / O configurations does not need to be performed if corresponding parent elements of corresponding subelements between I / O configurations are determined to be equal through comparison.

[0038] Although a system administrator is described herein as managing the configuration / reconfiguration, in other embodiments, it may be another administrator, a user, or a computing system or component configured to determine reconfiguration changes, perform preparatory steps, schedule maintenance, etc.

[0039] 5 shows a flowchart illustrating the operation of pruner module 203 according to an exemplary embodiment of the present invention. In an exemplary embodiment, one or more I / O configuration changes may be initiated by a system administrator or automatically by a processor based on operations within a computing environment (e.g., computing environment 100). The one or more I / O configuration changes may be included in a second I / O configuration defined by a to-be IODF proposed for activation to a first I / O configuration defined by a current IODF that defines the current configuration of the computing environment. Moreover, in an exemplary embodiment, both the current IODF and the to-be IODF for the computing environment may be defined using hardware configuration definition product 200.

[0040] Referring to step S510, in an exemplary embodiment, the pruner module 203 normalizes the hierarchical models created for the current IODF and the to-be IODF. As part of this process, the pruner module 203 creates a first hierarchical model based on the current IODF and a second hierarchical model based on the to-be IODF. Each IODF contains a description of the computing environment's I / O configuration—the multiple I / O elements defined therein and their relationships and attributes—and can span multiple systems and potential I / O configurations. As described above, the internal structure of an IODF resembles a relational database with tables and cross-references. To derive the hierarchical model, the IODF file may be converted into a text-based JavaScript Object Notation (JSON) data structure, which is a hierarchically nested data structure containing leaf and non-leaf nodes representing the multiple I / O elements in the computing environment's I / O configuration defined by the IODF. Such a structure inherently captures the hierarchical nature of the I / O elements of an IODF by hierarchically nesting them in leaf and non-leaf nodes with one or more cross-references between them. The transformation of an IODF into a hierarchical model is achieved in a series of steps. First, the IODF is parsed / read, and then all I / O elements (including their properties) contained in the IODF that are relevant to the computing environment under investigation are collected in the order in which the IODF is processed. Next, the I / O elements are compiled using Java 登録商標 They are combined into a domain model defined by classes, and finally the domain model is serialized into a JSON data structure.

[0041] By way of example, Figure 6 illustrates a resulting JSON hierarchy model 600 derived from an IODF, e.g., a hierarchy model derived from the current IODF of a computing environment in an exemplary embodiment. As shown in callout 601, multiple I / O elements (i.e., partitions, subchannel sets) in the resulting JSON hierarchy model 600 are hierarchically nested, along with their properties. Although not shown, in an exemplary embodiment, a JSON hierarchy model is similarly derived for the desired IODF. It should be noted that the JSON format is just one exemplary data structure, and other object notations / syntaxes (e.g., Extensible Markup Language (XML)) can be used to derive the hierarchy model.

[0042] Continuing with step S510, in an exemplary embodiment, the pruner module 203 normalizes the hierarchical models created for the current IODF and the to-be IODF. The goal of the normalization process is to analyze the various I / O elements contained within each hierarchical model representation of the IODF (e.g., the hierarchical models for the current IODF and the to-be IODF) and apply various syntactic transformation rules to each hierarchical model so that each hierarchical model still represents the respective I / O configuration but is defined in a syntactically consistent manner across the two hierarchical models. Different types of I / O components may require one or more different kinds of transformation rules. The syntactic transformation rules may be specific to each I / O element in the hardware configuration and may need to be applied in a specific order.

[0043] For example, the order of I / O configuration properties may need to be changed. One I / O component may specify an "id" property followed by a "name" property, while an equivalent configuration may have the "name" specified first (followed by the "id"). In addition, property values ​​may require transformations. For example, a list of three partition ids may be described by "1, 2, 3" or "2, 3, 1" (i.e., two syntactic expressions with the same semantics: three partitions). Also, grouping of consecutive numbers may also be necessary, since "1, 2, 3-8" is equivalent to "1-8". In an exemplary embodiment, normalization between the hierarchical models created for the current and desired IODFs is required for proper comparison below.

[0044] As an example, Figure 7 illustrates an exemplary normalization 700 of a portion of the hierarchical model of the current IODF of Figure 6. The partition and subchannel properties of the pre-normalized hierarchical model 701 of the current IODF are sorted and regrouped, resulting in a normalized hierarchical model of the current IODF 702. Specifically, the partition properties 701A are sorted to list the partition IDs in numerically increasing order, resulting in normalized partition properties 702A. In addition, the subchannel properties 701B are grouped to combine partitions listed separately, resulting in normalized subchannel properties 702B. Although not shown, the normalized hierarchical model of the IODF to be created in the example embodiment would reflect a similar manner of sorting and regrouping the partition and subchannel properties.

[0045] Referring to step S520, in an exemplary embodiment, the pruner module 203 creates a first hash tree representation for the normalized hierarchical model of the current IODF and a second hash tree representation for the normalized hierarchical model of the to-be IODF. As part of this process, the pruner module 203 calculates checksum values ​​for all leaf nodes based on the leaf information and for all non-leaf nodes based on the node and its child information for the normalized hierarchical models of the current IODF and the to-be IODF. The checksum values ​​are calculated according to the hierarchical structure of the JSON data structure. More specifically, in an example I / O configuration having a JSON hierarchical model with one root element and two child elements, checksum values ​​are calculated for all individual nodes (i.e., the root node and child nodes). Additionally, because the root element is itself a subtree, a checksum value is calculated for the root, including its child elements. 8 illustrates a portion 800 of checksum values ​​calculated for leaf and non-leaf nodes of the normalized hierarchical model of the current IODF, using, for example, Secure Hash Algorithm (SHA)-3. Although not shown, checksum values ​​are also calculated for the to-be normalized hierarchical model of the IODF in the illustrative embodiment.

[0046] Following step S520, a first hash tree representation for the normalized hierarchical model of the current IODF and a second hash tree representation for the normalized hierarchical model of the to-be IODF are created in response to the checksum value calculations for the leaf and non-leaf nodes described above. The nodes of the created hash tree representations are checksum values ​​calculated for each hierarchical model and reflect the logical hierarchical dependencies (e.g., leaf and non-leaf nodes) of each hierarchical model. Furthermore, each hash tree representation at the root includes checksum values ​​for similar subtrees for comparison with the subtrees, with references to their individual checksum values ​​and to the checksum values ​​of their child nodes. By way of example, FIG. 9 illustrates a portion of a hash tree representation for a normalized current IODF 910 and a portion of a hash tree representation for a normalized to-be IODF 920. The hash tree representations 910 and 920 may be created for, and based on, the normalized current IODF and normalized to-be IODF of the exemplary embodiment, respectively.

[0047] In an alternative embodiment, once a checksum value is calculated for an I / O configuration represented by a normalized hierarchical model, the checksummed I / O configuration may be persisted (or cached) in system memory so that in a potential comparison against the same I / O configuration, the I / O configuration does not need to go through the normalization and checksum calculation process again.

[0048] Referring to step S530, in an exemplary embodiment, the pruner module 203 prunes (i.e., removes) one or more nodes from the first hash tree representation for the normalized hierarchical model of the current IODF and the second hash tree representation for the normalized hierarchical model of the to-be IODF based on a checksum value comparison between the first hash tree representation and the second hash tree representation. As part of this process, the pruner module 203 compares the calculated checksum value of the hash tree representation for the normalized hierarchical model of the current IODF with the calculated checksum value of the hash tree representation for the normalized hierarchical model of the to-be IODF. The hash tree representations of the normalized current IODF and the normalized to-be IODF allow for a quick comparison of their respective configuration data because the comparison of the hash trees can be traversed hierarchically and stop at the highest level where the checksum values ​​match.

[0049] As an example, Figure 10 illustrates the comparison and change detection between portions of the hash tree representation of the normalized current IODF 910 and portions of the hash tree representation of the normalized to-be IODF 920 in an exemplary embodiment. As shown in Figure 10, the value of a node with checksum value "25a2b7fe23a..." in the hash tree representation of the normalized current IODF 910 has changed to "22314aa8901f..." in the hash tree representation of the normalized to-be IODF 920. Also, the value of a node with checksum value "7a49b32cf39b..." in the hash tree representation of the normalized current IODF 910 has changed to "ffe910400dea..." in the hash tree representation of the normalized to-be IODF 920. The pruner module 203 may restrict the comparison to non-equivalent nodes. For example, according to one aspect of the invention, a comparison of the hash trees illustrated in FIG. 10 may stop at the non-leaf node with a checksum value of "954ac65ef12b..." because this non-leaf node and its respective leaf node have the same checksum value in both the hash tree representation of the normalized current IODF 910 and the hash tree representation of the normalized to-be IODF 920.

[0050] Continuing with step S530, in an exemplary embodiment, the pruner module 203 prunes (i.e., removes) one or more nodes of the hash tree representations based on the comparison of the checksum values ​​described above. More specifically, the pruner module 203 may remove hash tree information in both hash tree representations whose checksum values ​​are equal up to the root node of the hash tree representations; otherwise, the pruner module 203 may remove hash tree information in only one hash tree representation (e.g., the hash tree representation of the normalized hierarchical model of the to-be IODF). The current IODF and the to-be IODF may be updated to reflect the removals made in their respective hash tree representations of their respective normalized hierarchical models. Furthermore, the pruner module 203 may send the updated to-be IODF for activation via a service, such as the activation service 210. The updated current IODF, or the original current IODF, or a combination thereof, may also be sent along with the updated to-be IODF to provide context for the changes defined by the to-be IODF. In an exemplary embodiment, the pruner module 203 prunes one or more nodes in at least one hash tree representation (e.g., the hash tree representation of the to-be IODF) where the checksum values ​​of one or more nodes are the same between the hash tree representation of the normalized current IODF and the normalized to-be IODF. According to one aspect of the present invention, not only can the comparison between the hash tree representation of the current IODF and the hash tree representation of the to-be IODF stop where corresponding nodes in the hash trees have matching checksum values, but further, because a match in checksum values ​​between these hash tree representations means that the to-be IODF does not differ from the current IODF with respect to the I / O configuration data represented by the matching checksum values, the I / O configuration data (e.g., I / O elements) represented by the matching checksum values ​​do not need to be retained in system memory.

[0051] By way of example, FIG. 11 illustrates pruned nodes in the hash tree representation of the current IODF 910 and the to-be IODF 920 in an exemplary embodiment. As shown in FIG. 11, nodes in each hash tree with the same checksum value are pruned (i.e., deleted), while nodes in each hash tree with different checksum values ​​are maintained. According to one aspect of the invention, the pruner module 203 may only prune the hash tree representations of both the current IODF 910 and the to-be IODF 920, provided that there are equal respective checksum values ​​(e.g., hash values) up to the root (i.e., parent) node. Otherwise, due to bidirectional parent-child dependencies, only one hash tree representation may be pruned. For example, in FIG. 11, the parent node with a checksum value of "954ac65ef12b..." is pruned in both the current IODF and the to-be IODF, along with each of its child nodes. In an exemplary embodiment, once the to-be IODF has been compared and pruned according to the operation of pruner module 203 described with respect to FIG. 5, the to-be IODF may then be submitted for activation via an activation service, such as activation service 210.

[0052] Figures 12, 13, 14, and 15 illustrate exemplary scenarios in accordance with aspects of the present invention. Referring to Figure 12, a logical view 1210 of an exemplary I / O configuration is shown along with a corresponding JSON hierarchy model 1220 of the exemplary I / O configuration. Portions of the JSON hierarchy model include meta information 1221, adapters 1222, partitions 1223, and channel paths 1224 connected to the partitions. Referring to Figure 13, an exemplary partition rename scenario 1300 is illustrated. The JSON hierarchy model shown on the left is the JSON hierarchy model 1220 from Figure 12 and represents the current IODF. The JSON hierarchy model 1320 shown on the right represents the desired IODF with changed name attributes for the partitions. Section 1321 includes the changes between JSON hierarchy model 1220 and JSON hierarchy model 1320. Specifically, partitions with a name attribute of "OLD" in JSON hierarchy model 1220 are renamed to a name attribute of "NEW" in JSON hierarchy model 1320. Moreover, as shown in FIG. 13, portions of the to-be IODF 1320 can be pruned by pruner module 203 because they do not reflect any changes from the current IODF 1220 on the left (i.e., the checksum values ​​of the hash tree representations for these portions will be the same). In this example scenario, portions of the current IODF 1220 that are the same as corresponding portions of the to-be IODF 1320 are not pruned to provide context for the changes reflected in the to-be IODF 1320. Referring to FIG. 14, an example partition addition scenario 1400 to an I / O configuration is shown. The current JSON hierarchy model 1410 of the I / O configuration is illustrated on the left, and the to-be JSON hierarchy model 1420 of the I / O configuration is illustrated on the right. Section 1421 reflects the differences between current JSON hierarchy model 1410 and desired JSON hierarchy model 1420, specifically the addition of a partition with attributes "id":3 and "name":"NEWNEW".Portions of the current IODF and the to-be IODF that can be pruned by the pruner module 203 are also identified. Referring to FIG. 15 , an exemplary device addition scenario 1500 to an I / O configuration is shown. The current JSON hierarchical model 1510 of the I / O configuration is illustrated on the left, and the to-be JSON hierarchical model 1520 of the I / O configuration is illustrated in the center portion, reflecting the addition of a second device. Specifically, within section 1521 of the to-be JSON hierarchical model 1520, the devices count property is increased to 6 (from 3 in the corresponding section 1511 of the current JSON hierarchical model 1510) to account for the added second device. Additionally, another to-be JSON hierarchical model 1520-1, which is semantically equivalent to the to-be JSON hierarchical model 1520, is illustrated on the right. JSON hierarchy model 1520-1 is shown to illustrate that a JSON hierarchy model (e.g., to-be JSON hierarchy model 1520) can be expressed in different, but semantically equivalent, ways. For example, sections 1521 and 1521-1 in Figure 15 are semantically equivalent in that they describe the same two devices, but the devices are grouped in section 1521 and separated in section 1521-1. Portions of 1510, 1520, and 1520-1 that can be pruned by pruner module 203 are also identified.

[0053] One or more aspects of the present invention are closely tied to computer technology and facilitate processing within a computing environment. By detecting reconfigurations through a side-by-side comparison of two I / O configurations and selectively pruning portions of at least one I / O configuration prior to activation, the ability to improve the process and execution time of a system being reconfigured is provided. This improves system resource consumption and system performance.

[0054] While various embodiments have been described herein, many variations and other embodiments are possible without departing from the scope of the present invention. It should be noted that, unless inconsistent, each aspect or feature described herein, and variations thereof, may be combined with any other aspect or feature.

[0055] The present invention may be a system, method, or computer program product, or combination thereof, at any level of technical detail that may be integrated. The computer program product may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0056] The computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction-execution device. The computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette 登録商標, hard disk, random access memory (RAM), read only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device such as punch cards or raised structures in grooves in which instructions are recorded, or any suitable combination thereof. As used herein, the computer-readable storage medium should not be construed to be a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or an electrical signal transmitted over an electrical wire.

[0057] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing device / processing device, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may be comprised of copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing device / processing device receives the computer-readable program instructions from the network and transmits the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing device / processing device.

[0058] The computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, such as object-oriented programming languages, e.g., Smalltalk, C++, etc., or conventional procedural programming languages ​​(e.g., the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any kind of network, such as a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., over the Internet using an Internet Service Provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the invention.

[0059] Aspects of the present invention are described herein with reference to flowchart illustrations or block diagrams, or combinations thereof, of methods, apparatus (systems), and computer program products or computer programs according to embodiments of the invention. It will be understood that each block of the flowchart illustrations or block diagrams, or combinations thereof, and combinations of blocks in the flowchart illustrations or block diagrams, or combinations thereof, can be implemented by computer-readable program instructions.

[0060] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts identified in one or more blocks of the flowchart diagrams or block diagrams, or a combination thereof, to produce a machine. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer-programmable data processing apparatus or other device, or a combination thereof, to function in a particular manner, such that a computer-readable storage medium having stored instructions includes an article of manufacture including instructions that implement aspects of the functions / acts identified in one or more blocks of the flowchart diagrams or block diagrams, or a combination thereof.

[0061] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device such that the instructions, which execute on the computer, other programmable data processing apparatus, or other device, implement the functions / acts identified in one or more blocks of the flowchart diagrams or block diagrams, or combinations thereof, to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process.

[0062] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products or computer programs according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing one or more specified logical functions. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may actually be accomplished as a single step performed simultaneously, substantially simultaneously, partially, or fully in a time-overlapping manner, depending on the functionality involved, or the blocks may be performed in the reverse order. It should be noted that each block of the block diagrams or flowchart diagrams or combinations thereof, and combinations of multiple blocks in the block diagrams or flowchart diagrams or combinations thereof, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations, or may execute a combination of special-purpose hardware and computer instructions.

[0063] Although various embodiments are described above, these are merely illustrative. For example, computing environments of other architectures can be used to incorporate and use one or more embodiments. Additionally, other components may be used, or may utilize one or more aspects of the present invention, or other components may be used and utilize one or more aspects of the present invention. Moreover, other types of reconfigurations may be performed. Many variations are possible.

[0064] Additionally, other types of computing environments can be beneficially utilized. As one example, a data processing system suitable for storing and / or executing program code can be utilized, the data processing system including at least two processors coupled directly or indirectly to memory elements through a system bus. The memory elements can include, for example, local memory used during the actual execution of the program code; bulk storage; and cache memory that provides temporary storage of at least some program code to reduce the number of times code must be retrieved from bulk storage during execution.

[0065] Input / output devices, or I / O devices (including but not limited to keyboards, displays, pointing devices, DASDs, tapes, CDs, DVDs, thumb drives, and other memory media, etc.) can be connected to the system either directly or through intervening I / O controllers. Network adapters may also be connected to the system to enable the data processing system to become connected to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the available types of network adapters.

[0066] The terms used herein are for the purpose of describing particular embodiments only and are not intended to be limiting of the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. As used herein, the words "comprises" or "comprising" specify the presence of stated features, integers, steps, operations, elements, or components, or combinations thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or combinations thereof.

[0067] In addition to corresponding structure, material, acts, and all means or steps in the appended claims, equivalents of functional elements are intended to encompass any structure, material, or act for performing a function in combination with other claimed elements, as specifically claimed. The detailed description of the present invention has been presented for purposes of illustration and description and is not intended to be exhaustive or to limit the invention to the disclosed form. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the invention. The embodiments have been chosen and described in order to best explain the principles and practical applications of the invention and to enable those skilled in the art to understand the invention in various embodiments with various modifications suited to the particular applications contemplated.

Claims

1. 1. A computer-implemented method for reconfiguring a computing environment from an existing input / output (I / O) configuration to a desired I / O configuration, comprising: normalizing a first hierarchical model of the current I / O configuration and a second hierarchical model of the desired I / O configuration, wherein the first hierarchical model and the second hierarchical model each comprise a hierarchical structure of leaf nodes and non-leaf nodes, and the normalizing includes applying a syntax transformation rule to the first hierarchical model and the second hierarchical model such that their respective I / O configurations are defined in a syntactically consistent manner across the first hierarchical model and the second hierarchical model; creating a first hash tree representation of the first hierarchical model and a second hash tree representation of the second hierarchical model, wherein nodes of the first hash tree representation are checksum values ​​calculated for leaf nodes and non-leaf nodes of the first hierarchical model, and nodes of the second hash tree representation are checksum values ​​calculated for leaf nodes and non-leaf nodes of the second hierarchical model, and wherein the nodes of the first hash tree representation and the nodes of the second hash tree representation reflect the hierarchical structure of the first hierarchical model and the hierarchical structure of the second hierarchical model, respectively; and pruning one or more nodes of the first hash tree representation and the second hash tree representation where checksum values ​​are equal up to the root node of the first hash tree representation and the root node of the second hash tree representation; The method comprising:

2. 2. The method of claim 1 , wherein the current I / O configuration is defined by a current Input / Output Definition File (IODF) and the desired I / O configuration is defined by a desired IODF, and the current IODF and the desired IODF comprise binary data structures similar to a relational database with tables and cross-references.

3. the first hierarchical model and the second hierarchical model are based on the current IODF and the to-be IODF, respectively, where the hierarchical model comprises a text-based JavaScript Object Notation (JSON) data structure including hierarchically nested leaf nodes and non-leaf nodes and one or more cross-references therebetween, where the leaf nodes and the non-leaf nodes represent I / O elements of an IODF; and where deriving the hierarchical model includes: iteratively parsing the IODF to collect the I / O elements (including their properties) contained in the IODF; Combining the I / O elements into a domain model defined by Java classes; and Serializing the domain model into a JSON data structure The method of claim 2 , comprising:

4. The method of claim 2 , further comprising transmitting the to-be-IODF for activation via an activation service.

5. 2. The method of claim 1, wherein leaf nodes and non-leaf nodes of the first hierarchical model represent I / O elements in the current I / O configuration, leaf nodes and non-leaf nodes of the second hierarchical model represent I / O elements in the desired I / O configuration, and the syntax transformation rules may be specific to each I / O element in an I / O configuration and may need to be applied in a specific order.

6. 2. The method of claim 1, further comprising pruning one or more nodes of the second hash tree representation where checksum values ​​are the same between the first hash tree representation and the second hash tree representation.

7. 2. The method of claim 1, further comprising persisting the first hash tree representation of the first hierarchical model and the second hash tree representation of the second hierarchical model in a memory of the computing environment.

8. 1. A computer program for reconfiguring a computing environment from a current input / output (I / O) configuration to a desired I / O configuration, comprising: normalizing a first hierarchical model of the current I / O configuration and a second hierarchical model of the desired I / O configuration, wherein the first hierarchical model and the second hierarchical model each comprise a hierarchical structure of leaf nodes and non-leaf nodes, and the normalizing includes applying a syntax transformation rule to the first hierarchical model and the second hierarchical model such that their respective I / O configurations are defined in a syntactically consistent manner across the first hierarchical model and the second hierarchical model; creating a first hash tree representation of the first hierarchical model and a second hash tree representation of the second hierarchical model, wherein nodes of the first hash tree representation are checksum values ​​calculated for leaf nodes and non-leaf nodes of the first hierarchical model, and nodes of the second hash tree representation are checksum values ​​calculated for leaf nodes and non-leaf nodes of the second hierarchical model, and wherein the nodes of the first hash tree representation and the nodes of the second hash tree representation reflect the hierarchical structure of the first hierarchical model and the hierarchical structure of the second hierarchical model, respectively; and pruning one or more nodes of the first hash tree representation and the second hash tree representation where checksum values ​​are equal up to the root node of the first hash tree representation and the root node of the second hash tree representation; The computer program causing a computer to execute each step of the method comprising:

9. 9. The computer program product of claim 8, wherein the current I / O configuration is defined by a current Input / Output Definition File (IODF) and the desired I / O configuration is defined by a desired IODF, and the current IODF and the desired IODF comprise binary data structures similar to a relational database with tables and cross-references.

10. the first hierarchical model and the second hierarchical model are based on the current IODF and the to-be IODF, respectively, where the hierarchical model comprises a text-based JavaScript Object Notation (JSON) data structure including hierarchically nested leaf nodes and non-leaf nodes and one or more cross-references therebetween, where the leaf nodes and the non-leaf nodes represent I / O elements of an IODF; and where deriving the hierarchical model includes: iteratively parsing the IODF to collect the I / O elements (including their properties) contained in the IODF; Combining the I / O elements into a domain model defined by Java classes; and Serializing the domain model into a JSON data structure Including, 10. A computer program according to claim 9.

11. 10. The computer program product of claim 9, further causing the computer to transmit the desired IODF for activation via an activation service.

12. 9. The computer program product of claim 8, wherein leaf nodes and non-leaf nodes of the first hierarchical model represent I / O elements in the current I / O configuration, leaf nodes and non-leaf nodes of the second hierarchical model represent I / O elements in the desired I / O configuration, and the syntax transformation rules may be specific to each I / O element in an I / O configuration and may need to be applied in a specific order.

13. 9. The computer program product of claim 8, further causing the computer to prune one or more nodes of the second hash tree representation where checksum values ​​are the same between the first hash tree representation and the second hash tree representation.

14. 9. The computer program product of claim 8, further causing the computer to persist the first hash tree representation of the first hierarchical model and the second hash tree representation of the second hierarchical model in a memory of the computing environment.

15. 1. A computer system for reconfiguring a computing environment from a current input / output (I / O) configuration to a desired I / O configuration, the computer system comprising: comprising one or more processors, one or more computer-readable memories, one or more computer-readable tangible storage devices, and a plurality of program instructions stored on at least one of the one or more computer-readable tangible storage devices for execution by at least one of the one or more processors via at least one of the one or more memories; The plurality of program instructions: program instructions for normalizing a first hierarchical model of the current I / O configuration and a second hierarchical model of the desired I / O configuration, wherein the first hierarchical model and the second hierarchical model each comprise a hierarchical structure of leaf nodes and non-leaf nodes, and the normalizing includes applying a syntax transformation rule to the first hierarchical model and the second hierarchical model such that their respective I / O configurations are defined in a syntactically consistent manner across the first hierarchical model and the second hierarchical model; program instructions for creating a first hash tree representation of the first hierarchical model and a second hash tree representation of the second hierarchical model, wherein nodes of the first hash tree representation are checksum values ​​calculated for leaf nodes and non-leaf nodes of the first hierarchical model and nodes of the second hash tree representation are checksum values ​​calculated for leaf nodes and non-leaf nodes of the second hierarchical model, and wherein the nodes of the first hash tree representation and the nodes of the second hash tree representation reflect the hierarchical structure of the first hierarchical model and the hierarchical structure of the second hierarchical model, respectively; and program instructions for pruning one or more nodes of the first hash tree representation and the second hash tree representation where checksum values ​​are equal up to the root node of the first hash tree representation and the root node of the second hash tree representation; Including, The computer system.

16. 16. The computer system of claim 15, wherein the current I / O configuration is defined by a current Input / Output Definition File (IODF) and the desired I / O configuration is defined by a desired IODF, and the current IODF and the desired IODF comprise binary data structures similar to a relational database with tables and cross-references.

17. the first hierarchical model and the second hierarchical model are based on the current IODF and the to-be IODF, respectively, where the hierarchical model comprises a text-based JavaScript Object Notation (JSON) data structure including hierarchically nested leaf nodes and non-leaf nodes and one or more cross-references therebetween, where the leaf nodes and the non-leaf nodes represent I / O elements of an IODF; and where program instructions for deriving the hierarchical model include: program instructions for iteratively parsing the IODF to collect the I / O elements (including their properties) contained in the IODF; program instructions for combining the plurality of I / O elements into a domain model defined by Java classes; and Program instructions for serializing the domain model into a JSON data structure Including, 17. The computer system of claim 16.

18. 17. The computer system of claim 16, further comprising program instructions for transmitting the to-be-activated IODF for activation via an activation service.

19. 16. The computer system of claim 15, wherein leaf and non-leaf nodes of the first hierarchical model represent I / O elements in the current I / O configuration, leaf and non-leaf nodes of the second hierarchical model represent I / O elements in the desired I / O configuration, and the syntax transformation rules may be specific to each I / O element in an I / O configuration and may need to be applied in a specific order.

20. 16. The computer system of claim 15, further comprising program instructions for pruning one or more nodes of the second hash tree representation where checksum values ​​are the same between the first hash tree representation and the second hash tree representation.

Images