class C_Xj public:
enum lnterfaceld{ld=lf; stotic C_X* Create(int size); virtual void Mx(int data)=0; virtual ~C_X()=0; private:
void* xxxNotUsed;// only here to assure compatibility
I;
class X{ private: C_X* p; public:
create(int size)
|p=C_X::Create(size);j
void Mx(int data); ~X()
{delete p;j
i;
SPECIFICATION OF UNIT USING THE INTERFACE
UNIT XProvider; SERVER OF CLASS X; END UNIT XProvider;
GENERATED CLASSDEF1N1T10N FOR XPROVIDER
SYSTEM FOR CHANGING SOFTWARE
DURING COMPUTER OPERATION
This application for patent is divisional of prior application for patent Ser. No. 07/907,294, filed Jul. 1, 1992, now 5 U.S. Pat. No. 5,410,703.
BACKGROUND OF THE INVENTION
A portion of the disclosure of this patent document 10 contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the patent and trademark office, patent file or records, but otherwise reserves all copyrights ^ whatsoever.
1. Field of the Invention
The invention relates to the modification of software, and in particular, to the replacement of software in an operating computer system. 20
2. Description of Related Art
One aspect of computer software is that it must be periodically updated with revisions, additions and/or deletions in order to continue to provide adequate functionality 25 to the user, to optimize the software and to correct errors and discrepancies that arise throughout the life of the software. As new features are added to software, it is desirable to .replace the old software with the new versions as early and as easily as possible in order to provide the user with the features of the new software.
In certain types of computing systems, such as standalone or batch processing systems, changing software from one version to another presents few obstacles. Typically, the computer system is merely shut down during a period of the 35 day when there is little activity and maintenance personnel are readily available. The old software is then simply removed and replaced by the newer version of the software. Thereafter, the computing system is restarted and all future data processing is done with the new version of the software. 40 This procedure, of course, assumes that the new software has been adequately tested and debugged on an offline system to the point that the software personnel and the operational management are confident that it will adequately perform the functions for which it is intended without undue 45 interruptions that may require halting and then re-starting the entire computing system.
In other types of computing systems, such as modern stored program control (SPC) telecommunications exchange systems (commonly referred to in the industry simply as 50 "switches"), neither the testing of new versions of software nor the changing of software in the system is as easy as in standalone batch processing systems. For example, new versions of software cannot be effectively tested without being placed into actual operation processing calls. The 55 software must be tested while in operation in order to determine whether the software will adequately function under live operating conditions and whether the new portions will properly interface with all of the other software blocks that form a part of an operational SPC switching 60 system. In addition, telecommunications switching systems are virtually never out of operation. Ideally, these systems would run perpetually, without interruption because of the continuous need for communications services within a community. That is, there is a continuous flow of telecommu- 65 nications trafiic being processed through the system even at off hours of the day or night and any interruption in the
operation of the switch results in a disruption of that telecommunications traffic. Such a disruption could be extremely damaging to the system's operation and its effectiveness, as well as to its acceptance among users or customers of the system.
These real-time requirements of telecommunications switching exchanges place severe constraints on both the testing of enhanced versions of the software, or portions thereof, containing new or improved functionality, as well as the substitution of software containing error corrections or "bug fixes" into the switch without disrupting existing telecommunications traffic being processed by the switch. Therefore, integrating new versions of software components or units into the system using the traditional "edit-compilelink-load-ran" approach is not desirable. What is preferred is a method that provides the capability to modify or extend the software while the system is in operation, without the need for any downtime.
Attempts have been made to solve the problems associated with incorporating new software into operating computer systems. For example, some advanced on-line operational systems in use today that do not operate in a standalone or batch fashion solve the problem of replacing old software in a manner that clearly differs from the method used with stand-alone or batch systems. However, such systems still replace software manually, although more transparently than in stand-alone systems, by requiring that individual users or user groups actively select whether or not to process using the new or revised version of the software. This option may be exercised by users by modifying the concatenation of software to be utilized by processes operating under their individual user-id. The option remains available to users during a fixed period of time, usually measured in weeks or months, in which time the software migrates up several levels in the concatenation structure after successfully operating at each prior level without any discrepancies. Upon reaching the top level of the concatenation, the software is declared "operational" and older versions are no longer available to users of the system. Insertion of new software into the system, as well as its migration up the various levels, is controlled by a process of configuration management—a manual process of reporting, approval, tracking software versions at each level and implementing approved changes.
As with the methods used to update software on batch or stand-alone systems, there are well known drawbacks to incorporating new or modified software into a system in this fashion. It is largely a manual, labor intensive system that is complex and time consuming. It leaves control over whether and in what cases the system will operate with certain new software to the users with no means of performing gradual, restricted, on-line use so that errors do not proliferate or immediately affect all ongoing operations. The method of controlling access to new or revised software is directly linked and limited to the individual user executing the software.
Other attempts to solve at least some of the problems associated with updating software in operational computer' systems have taken a different approach. For example, in U.S. Pat. No. 5,297,285, issued Mar. 22,1994, containing an invention by Anders Abrahamsson and Lars Holmqvist and assigned to Telefonaktiebolaget L M Ericsson, there is disclosed a system for dynamically linking software during run-time. That system, however, involves a complex system of indirect addressing that requires use Of either a specialized or extended operating system and/or a special compiler. That system also has several drawbacks, including the need
3
for a non-standard operating system. Further, the system will not work with standard applications software. The system is also limited in that it only addresses a portion of the overall problem and does not provide assistance in the areas of gradual testing and changing of control between existing and 5 revised software modules.
In the typical telecommunications system in use today, the problem of changing software or portions of software is even more severe. Although such systems cannot properly be called batch or stand-alone systems, their operation will 10 also be affected whenever a software change is made. The new software is loaded and the data that belonged with the old software is converted and transported to the new software. During the time when this transport is going on, the system cannot register any new calls. This period of dis- 15 function can last as long as an hour or more, making it necessary to schedule software changes for off-peak hours of operation. Even so, an hour of downtime in a telecommunications switching system a very long and costly period because no new calls can be processed during this period and 20 any needs for emergency communications during this time cannot be serviced.
Therefore, it would be highly useful within the telecommunications industry to be able to test and change software during actual operation of the telecommunications switch 25 without disrupting ongoing telecommunications traffic through the system. It would be of further benefit to the telecommunications industry to have the capability to direct a limited and specified portion of traffic through the new software or new portions thereof, so that the software could 30 be tested in an operational environment prior to handling live data. A smooth, transparent method of changing software during operation of the system that requires no special compilers would thus be highly desirable. The system of the present invention provides such a method. 35
SUMMARY OF THE INVENTION
The dynamic behavior of computing systems such a SPC 4Q telecommunications switching systems can essentially be described as a series of parallel, relatively independent transactions (also referred to a "threads" or "chains of events") wherein every transaction consists of a number of related activities. A transaction typically performs a job that 45 is visible and functionally useful to the external user of the system. In a telecommunications switching system a typical transaction may be a call.
Online software replacement using the smooth software change techniques of the present invention makes use of 50 transaction oriented software together with a memory capable of storing both old and new software versions at the same time. A smooth change over to a new software version is accomplished by letting ongoing transactions, i.e., "old traffic", run to completion using the old software version. 55 Transactions started after the software change has begun, i.e., "new traffic", will in a gradual and controlled way be run using the new software version.
Principal requirements satisfied by the smooth software change techniques of the present invention include minimal 60 or no user disturbance and a high level of system availability. Principal characteristics of the present invention include the facts that: (1) minimal or no disturbance is experienced by an individual user of the system during a transaction (e.g., a call) because one and only one software version controls 65 each specific transaction, i.e., the system uses either the old software version or the new software version from the start
4
to the end of the transaction; and (2) no unavailability is experienced by an individual user of the system because of the software change since both software versions are used in parallel during the change. If this latter characteristic was not present a simpler solution would be to simply make an offline change of the system software.
The data to be treated by the system can in this context be separated into two'different classes: (1) dynamic data which is created and us ed during a transaction and which is deleted after the transaction is completed; and (2) semipermanent data which is used by and survives several transactions, for example in telecom systems, data about subscriber numbers connected to the system or short numbers used by certain subscribers.
A crucial problem associated with online software replacement where minimail disturbance is required is that the state of the old software version has to be transferred to the new software version. With smooth software modification in accordance with the present invention the separation of dynamic and semipermanent data makes this problem simpler in that only the semipermanent data, if any, has to be transferred from the old software to the new version. Further, semipermanent data is typically implemented as objects in a separate data base and is more seldom changed than other parts of a telecommunications software system.
The system of the present invention provides for the installation of new software into the stores of the telecommunications system along with, and in addition to, the old software. In the system of the present invention, existing traffic in the system is initially processed by the old software and test traffic is routed through the switch for processing by the new software. Thereafter, if the test traffic is handled successfully by the new software, a portion of the actual live traffic (or normal traffic) is selectively routed through the new software with the remainder of the live traffic still being handled by the old software. The percentage of live sample traffic handled by the new software may be varied between zero and one hundred percent. Should the sample traffic be carried adequately by the new software, all of the traffic is directed to the new software. As soon as the processing of all calls being handled by the old software has been completed, the old software is no longer utilized by the system and may be removed from the system.
In another aspect, the system of the present invention comprises a system for smooth verification of new or modified software. The system of the present inventions allows data to flow through the new software in a gradual and controlled manner, yet as part of the live operational system. The system provides for early detection of errors and discrepancies with little or no impact to actual operation of a telecommunications switching system because the initial data routed to the new software is only test data generated by the system. If, in processing test data, the telecommunications system detects an error, no further traffic is directed to the new software so that, even if the new software had been processing actual data, disturbance to the overall traffic of the system is minimized.
In another aspect of the systems of the present invention, the system redirects traffic from the old software to the new software in a gradual manner. The system of the present invention includes the capability to allow transactions that began processing with the old software to complete its processing using only the old software. Only transactions that began subsequent to the installation of the new software will be processed by the new software. This aspect of the system of the present invention results in only a minimal
|
