Patent Application
20170357494
This invention relates to systems and methods for verifying that software modules have a consistent code level.
Many software products are made up of numerous software modules that invoke one another to accomplish various tasks. When a software product is updated to a desired “code level,” some or all of the software modules that make up the software product may be updated. In many cases, software modules need to be updated at the same time in order to properly work together. For example, if a first software module is configured to call a second software module and the first software module is updated to pass additional data or commands to the second software module, the second software module may need to be updated to understand and handle the additional data or commands. If the second software module is not updated, different errors may occur when the first software module calls the second software module. These errors may be hard to predict and may result is problems such as overlays (data written to or read from a wrong location, possibly overwriting other valuable data), abends (abnormal terminations), and/or hangs (delays) in a program. In some cases, system outages or data corruption may result.
Inconsistency across software modules may be the result of errors during a code update, incorrect procedures used by an installer, and/or undesired termination of installation procedures before they are complete. Many errors caused by inconsistent software modules may be unpredictable and very hard to diagnose and/or correct. This is at least partly because code as it exists on a user's system may not be in a normal state and may not match source code used by an engineer or technician to diagnose an error.
In view of the foregoing, what are needed are systems and methods to verify that software modules are in a consistent state. Ideally, such systems and methods will determine whether software modules have a consistent code level and, if not, take measures to prevent errors or improper execution, notify appropriate personnel, and/or update software modules to ensure consistency.
The invention has been developed in response to the present state of the art and, in particular, in response to the problems and needs in the art that have not yet been fully solved by currently available systems and methods. Accordingly, systems and methods have been developed to verify that software modules have a consistent code level. The features and advantages of the invention will become more fully apparent from the following description and appended claims, or may be learned by practice of the invention as set forth hereinafter.
Consistent with the foregoing, a method for verifying that software modules have a consistent code level is disclosed. In one embodiment, such a method includes updating a software product comprising a plurality of software modules. Upon updating the software product, the method updates a code-level table that documents an expected code level for each of the software modules. When a software module is called, the method determines an actual code level of the software module and compares the actual code level with the expected code level indicated in the code-level table. If the actual code level matches the expected code level, the method allows execution of the software module. If the actual code level does not match the expected code level, the method terminates execution of the software module.
A corresponding system and computer program product are also disclosed and claimed herein.
In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered limiting of its scope, the embodiments of the invention will be described and explained with additional specificity and detail through use of the accompanying drawings, in which:
It will be readily understood that the components of the present invention, as generally described and illustrated in the Figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the embodiments of the invention, as represented in the Figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of certain examples of presently contemplated embodiments in accordance with the invention. The presently described embodiments will be best understood by reference to the drawings, wherein like parts are designated by like numerals throughout.
The present invention may be embodied as a system, method, and/or computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.
The computer readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is 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 of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages.
The computer readable program instructions may execute entirely on a user's computer, partly on a user's computer, as a stand-alone software package, partly on a user's computer and partly on a remote computer, or entirely on a remote computer or server. In the latter scenario, a remote computer may be connected to a user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may be implemented by computer readable program instructions.
These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, 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 specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
Referring to
As shown, the computing system 100 includes at least one processor 102 and may include more than one processor 102. The processor 102 may be operably connected to a memory 104. The memory 104 may include one or more non-volatile storage devices such as hard drives 104a, solid state drives 104a, CD-ROM drives 104a, DVD-ROM drives 104a, tape drives 104a, or the like. The memory 104 may also include non-volatile memory such as a read-only memory 104b (e.g., ROM, EPROM, EEPROM, and/or Flash ROM) or volatile memory such as a random access memory 104c (RAM or operational memory). A bus 106, or plurality of buses 106, may interconnect the processor 102, memory devices 104, and other devices to enable data and/or instructions to pass therebetween.
To enable communication with external systems or devices, the computing system 100 may include one or more ports 108. Such ports 108 may be embodied as wired ports 108 (e.g., USB ports, serial ports, Firewire ports, SCSI ports, parallel ports, etc.) or wireless ports 108 (e.g., Bluetooth, IrDA, etc.). The ports 108 may enable communication with one or more input devices 110 (e.g., keyboards, mice, touchscreens, cameras, microphones, scanners, storage devices, etc.) and output devices 112 (e.g., displays, monitors, speakers, printers, storage devices, etc.). The ports 108 may also enable communication with other computing systems 100.
In certain embodiments, the computing system 100 includes a wired or wireless network adapter 114 to connect the computing system 100 to a network 116, such as a LAN, WAN, or the Internet. Such a network 116 may enable the computing system 100 to connect to one or more servers 118, workstations 120, personal computers 120, mobile computing devices, or other devices. The network 116 may also enable the computing system 100 to connect to another network by way of a router 122 or other device 122. Such a router 122 may allow the computing system 100 to communicate with servers, workstations, personal computers, or other devices located on different networks.
Referring to
Inconsistency across software modules 202 may be the result of errors during a code update, incorrect procedures used by an installer, and/or undesired termination of installation procedures before they are complete. As mentioned above, many errors caused by inconsistent software modules 202 may be unpredictable and very hard to diagnose and/or correct. This is at least partly because code as it exists on a user's system may not be in the same state as source code used by an engineer or technician to diagnose an error.
In order to verify that software modules 202 are in a consistent state, a code-level verification module 204 may be provided. The code-level verification module 204 may be implemented in hardware, software, firmware, or combinations thereof. The code-level verification module 204 may be configured to determine whether software modules 202 have a consistent code level and, if not, take measures to prevent errors or improper execution, notify appropriate personnel, and/or update software modules 202 to ensure consistency.
As shown in
Referring to
As shown, a computing system 100 may, in certain embodiments, include an installation module 300 and/or maintenance module 302. The installation module 300 may be configured to manage installation of software products 200 on the computing system 100. For example, the installation module 300 may be configured to implement SMP/E (System Modification Program/Extended) which is a tool designed to manage the installation of software products on z/OS systems as well as track modifications thereto. Once a software product 200 is installed, the maintenance module 302 may be configured to maintain the software product 200, such as by applying patches and updates to the software product 200 as needed.
In order to ensure that software modules 202 are in a consistent state after they are installed or updated, the code-level verification module 204 may maintain a code-level table 330 that includes a list of software modules 202 and their expected code level, such as a fix number, version number, etc. Each software product 200 may have a separate code-level table 330 or a global code-level table 330 may be used for multiple software products 200. In certain embodiments, the code-level verification module 204 also maintains a validation table 332 that keeps track of software modules 202 that have been validated as having the correct code level. The information in the code-level table 330 and validation table 332 may in certain embodiments be combined into a single table or the information contained therein may be organized differently that what is illustrated. For example, the validation table 332 may in certain embodiments be implemented as an address hash table that stores addresses or ranges of addresses for software modules 202 that have been validated. Thus, the organization and manner in which data is stored in the code-level table 330 and validation table 332 may differ in different embodiments.
Each time a software product 200 is updated by the installation module 300 or maintenance module 302, the update module 304 may update the code-level table 330 to reflect the most updated version of the software modules 202 and expected code levels. When the update module 304 updates the code-level table 330, the reset module 306 may reset the validation table 332, such as by marking the updated software module 202 as “unvalidated,” or by simply removing the updated software module 202 or validation information (e.g., addresses or ranges of addresses associated with the updated software module 202) from the validation table 332.
When a software module 202 is called, the call detection module 308 may detect the call. In certain embodiments, the call detection module 308 is implemented as program code within a software module 202 that detects when the software module 202 is called and invokes functionality within the code-level verification module 204. As previously mentioned, this may be accomplished by recompiling existing software modules 202 to invoke functionality of the code-level verification module 204. Alternatively, the intercept module 310 may intercept calls between software modules 202 to invoke functionality of the code-level verification module 204, thereby eliminating the need to modify or recompile existing software modules 202.
When a software module 202 is called, the bypass module 312 may check the validation table 332 to determine whether the software module 202 has already been validated as having a correct code level. If so, the bypass module 312 may bypass validation procedures performed by the code-level verification module 204 and allow the software module 202 to continue execution.
If the bypass module 312 determines that a software module 202 has not been validated, the code-level determination module 314 may determine a code level of the software module 202. In certain embodiments, this may be accomplished by looking for an “eyecatcher” (e.g. descriptive text or sequence of bytes that has a low probability of randomly appearing in memory) that describes the code level of the software module 202 within the program code of the software module 202.
Once the code level of the software module 202 is determined, the comparator module 316 may compare the code level with the expected code level for the software module 202 that is listed in the code-level table 330. If the code levels match, the continuation module 318 may enable the software module 202 to continue executing and the validation module 320 may validate the software module 202 in the validation table 332, such as by marking it as “validated,” or adding the software module's name or address(es) to the validation table 332. This will allow the validation process to be bypassed the next time the software module 202 is called.
If the code level of the software module 202 does not match the expected code level in the code-level table 330, the termination module 322 may terminate the software module 202. In certain embodiments, the termination module 322 generates a new ABEND code that indicates a mismatch between the code level of the software module 202 and the expected code level, and performs a storage dump of the mismatched software module 202. The notification module 324 may optionally notify a user or administrator that the software module 202 has been terminated, and optionally indicate reasons for the termination.
The unload detection module 326 may detect when a software module 202 is unloaded from memory. While unloaded from memory, the software module 202 has the potential to be modified or updated in a way that causes its code level to change. Thus, when the software module 202 is unloaded from memory, the unload detection module 326 may remove the software module 202 from the validation table 332 or mark it as unvalidated. This will ensure that the software module 202 is once again revalidated when it is called.
Referring to
If, at step 406, the software module 202 was not previously validated (i.e., the software module 202 is not listed or validated in the validation table 332), the method 400 determines 408 the code level of the software module 202, such as by looking for an eyecatcher in the software module 202 that identifies its code level. The method 400 also determines 410 the expected code level for the software module 202 by looking in the code-level table 330. If the code level of the software module 202 matches 412 the expected code level, the method 400 proceeds 420 with the execution of the software module 202 and marks 422 the software module 202 as validated in the validation table 332. If the code level of the software module 202 does not match 412 the expected code level, the method 400 terminates 414 execution of the software module 202 and optionally notifies 416 a user or administrator of the termination and possibly the reasons for termination.
Referring to
Referring to
The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products 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 code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other implementations may not require all of the disclosed steps to achieve the desired functionality. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
