Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
5666534
Gilbert , ; et al.
September 9, 1997
Title
Method and appartus for use by a host system for mechanizing highly configurable capabilities in carrying out remote support for such system
Abstract
A remote service facility (RSF) unit is integrated into the operating system of the host system being supported. The RSF unit utilizes a standard generic menu interface system (GMIS) unit through which a user can enter different types of commands which results in the display of a number of menu sequences for configuring how the different independently controllable components of the RSF unit will operate in performing remote support functions. The components include a problem detection and reaction component, a system action component and a callback component, each of which operatively couple to the GMIS unit. The components are integrated in a predetermined manner so that collectively, they carry out remote support according to the way in which they were configured.
Inventors:
Gilbert; Jeremy H.
(Billerica,
MA
)
, Hout; David B.
(Wilmington,
MA
)
, Keohane; Michael P.
(Brighton,
MA
)
, Perlow; David K.
(Merrimack,
NH
)
, Peters; Daniel G.
(Nashua,
NH
)
, Storch; Eric J.
(Nashua,
NH
)
Assignee:
Bull HN Information Systems Inc.
(Billerica,
MA
)
Appl. No.:
085272
Filed:
June 29, 1993
Current U.S. Class:
713/1
714/31
709/224
Field of Search:
395/700,200.11,651
U.S. Patent Documents
5111384
May 1992
Aslanian et al.
5210757
May 1993
Barlow et al.
5432941
July 1995
Crick et al.
5437030
July 1995
Reitman et al.
Other References
"DPX/2 500 Remote Maintenance Facility Guide", Bull HN Information Systems Inc., Mar. 1991 Order No. LW07-00..~
Primary Examiner:
Heckler; Thomas M.
Assistant Examiner:
Chaki; Kakali
Attorney, Agent or Firm:
Driscoll; Faith F. Solakian; John S.
Claims
What is claimed is:
1. A method of organizing and operating a proactive and reactive remote services facility (RSF) unit installable within a host system which is operatively connected to communicate with a remote response center dedicated to performing remote support services for said host system involving diagnosis of host system problems reported to said center, said method comprising the steps of:
(a) constructing a number of independently operable software components, each component being constructed for performing one of a predetermined number of different basic functions required for performing said proactive and reactive support for said host system;
(b) including in each of said number of software components, configuration control means for preconfiguring each component by establishing predetermined parameters defining how said each component is to perform said one of said number of basic functions in carrying out remote support; and,
(c) integrating said number of software components together in a predetermined manner so that said components collectively perform said proactive and reactive remote support according to said predetermined parameters preconfigured in step (b).
2. The method of claim 1 wherein said host system includes a host computer, an operating system for controlling the operation of said host computer, a generic menu interface system (GMIS) unit for communicating with said operating system using menu initiated dialog sequences and a display terminal unit operatively coupled to said host computer and to said GMIS unit for enabling a user to enter commands directly or through said GMIS unit for execution by said RSF unit, said method further comprising the steps of:
(d) operatively coupling each of said number of software components to said GMIS unit; and,
(e) including within each of said number of components, a number of modules which operatively couple to said GMIS unit, said number of modules being responsive to a different predetermined command set containing a small number of commands customized for configuring said each of said components according to step (b).
3. The method of claim 2 wherein said computer system includes a number of source error log files used by said host computer for logging errors encountered while running applications on said host computer and wherein said remotely located response center performs support services for said host system by calling back into said host system in response to a first component of said number of components having detected an overthreshold condition which caused a callout action to be made by said RSF unit for further diagnosis and correction of a system problem reported by said host system, said first component including said number of source error log files and a control attribute file and wherein said step (b) of said method further includes the steps of:
(f) configuring each of said number of source error log files to be monitored by causing storage of a source record entry in said control file for each of said number of source log files to be monitored, said record entry containing a unique user specified name for said log file, a path name to said log file, information identifying the type of log file, information identifying how often to scan for new messages and information designating what notification action to invoke if a message is detected by said first component as being overthreshold; and;
(g) initiating said notification action specified by said source record entry to said response center upon detecting an occurrence of an overthreshold condition within one of said source log files being monitored.
4. The method of claim 3 wherein step (f) further includes the step of specifying said scan rate by defining the time interval for monitoring error information being stored by each of said source error log files being monitored.
5. The method of claim 3 wherein step (f) further includes the step of configuring said notification action by specifying a callout action and/or an electronic mail notification action.
6. The method of claim 3 wherein step (f) further includes the step of configuring said type of source by indicating whether said source is a system or ASCII log file.
7. The method of claim 3 wherein said first component includes a message template database associated with each source log file to be monitored and wherein said step (f) further includes the steps of:
(h) configuring said potential messages to be monitored by causing storage in said message template database designated by said source identifier contained in said control file entry for said each source log file, a number of information message entries corresponding to a number of said potential messages to be monitored, each said entry including search criteria information used for detecting when said potential message should be deemed to match messages stored in said source error log file and threshold information indicating a number of messages that must be exceeded to be deemed an occurrence of an over threshold condition.
8. The method of claim 7 wherein said search criteria includes either a message identifier for each system type of source error log file or regular expression parameters for each ASCII type of source error log file.
9. The method of claim 7 wherein said step of configuring said message template database is performed in response to a user generated make message source command.
10. The method of claim 9 wherein said method further includes the steps of:
(i) issuing a make message template command for creating an initialization file containing said number of messages to be added to said message template database file; and,
(j) designating said initialization file by including in said make message source command, a parameter specifying said initialization file.
11. The method of claim 7 wherein said first component further includes a storage library, said library being operatively coupled to said control file, said message template databases and source error log files and wherein said method further includes the steps of:
(k) storing a plurality of different types of routines in said library; and
(l) accessing different ones of said routines in response to different commands within said small set of commands to configure said first component.
12. The method of claim 11 wherein said plurality of different types of routine includes a number of different search routines, one for each different type of source error log file and wherein said method further includes the steps of:
(m) accessing one of said different search routines according to type information stored in said control file for scanning said source by reading messages from said source and comparing each message with message entries stored in said message template database for determining a match according to search criteria specified in said message entries.
13. The method of claim 3 wherein said number of components further includes a second component operatively coupled to said operating system and to said first component and wherein said method further includes the steps of:
(h) preconfiguring said second component to be responsive to said notification action to perform any support notification operation in accordance with said specified callout action as preconfigured by said user.
14. The method of claim 13 wherein said number of modules of said second component further includes a call configuration file and a call configuration module coupled to said file and to said GMIS unit and wherein step (g) further includes the steps of:
(1) configuring site parameters and modem parameters through said GMIS unit as a function of how said host system has been configured;
(2) initiating storage of said site parameters and modem parameters in said call configuration file by causing generation of a predetermined one of said set of commands with a preestablished command line; and
(3) said call configuration module in response to said predetermined command causing said site parameters and modem parameters to be written into said call configuration file for subsequent use in controlling how said second component performs support notification operations.
15. The method of claim 14 wherein said host system is configurable in standalone, cluster client and cluster server configurations and wherein steps (1) through (3) are performed wherein said host system is configured in said standalone and cluster server configurations.
16. The method of claim 15 wherein said host system is configured in a cluster client configuration and wherein said RSF unit further includes a third component for performing support notification operations using communications facilities of another host system, said number of modules of said third component including a call configuration module coupled to said GMIS unit and a call configuration file coupled to said call configuration module and to said GMIS unit and wherein in lieu of steps (1) through (3) being performed, said method further includes the steps of:
(4) configuring cluster server parameters through said GMIS unit;
(5) initiating storage of said cluster server parameters in said call configuration file by causing generation of a predetermined command with a preestablished command line; and
(6) said call configuration module in response to said predetermined command causing said cluster server parameters to be written into said call configuration file for subsequent use in controlling how said third component performs support notification operations.
17. The method of claim 14 wherein step (1) further includes the steps of:
(7) configuring communications control OK and CONNECT strings as a function of modem type being used;
(8) initiating storage of said communications control OK and CONNECT strings in said call configuration file by causing generation of said predetermined command with a preestablished command line; and
(9) said call configuration in response to said predetermined command causing said communications control OK and CONNECT strings to be written into said call configuration file for controlling how said second component performs support notification operations.
18. The method of claim 14 wherein said number of modules of said second component further includes a call configuration file, a call configuration module coupled to said file and to said GMIS unit and a mailaction module operatively coupled to said operating system, to said first component and to said call configuration file and wherein step (g) of said method further includes the steps of:
configuring electronic mail address parameters as a function of whether said support notification operation includes a mail notification action;
initiating storage of said electronic mail address parameters in said call configuration file by causing generation of said predetermined command with a preestablished command line; and
said call configuration module in response to said predetermined command causing said electronic mail parameters to be written into said call configuration file for enabling said mail action module to perform said mall notification action using said electronic mail parameters.
19. The method of claim 13 wherein said number of modules of said second component further includes a callout manager subcomponent including a call control file containing a callout queue for storing callout requests generated in response to callout actions initiated by said first component and a plurality of different call modules, each different call module being operatively coupled to said GMIS unit and wherein said method further includes the steps of:
removing a callout request through said GMIS unit by initiating generation of a first one of said small set of commands; and
a first one of said different call modules in response to said first one of said set of commands accessing said call control file and removing said callout request from said callout queue.
20. The method of claim 19 wherein said method further includes the steps of:
changing parameters of a callout request by initiating generation of a second one of said set of commands with command line parameters; and
a second one of said different callout modules in response to said second one of said set of commands accessing said call control file and changing said callout request stored in said callout queue according to said command line parameters.
21. The method of claim 19 wherein said method further includes the steps of:
listing callout requests stored in said callout queue by initiating generation of a third one of said set of commands; and
a third one of said different callout modules in response to said third one of said set of commands accessing said call control file and listing each request stored in said callout queue.
22. The method of claim 2 wherein said number of components further includes a fourth component operatively coupled to said operating system and to said GMIS unit and wherein said step (b) of said method further includes the steps of:
preconfiguring said fourth component to enable further diagnosis of said problem by said response center by accessing facilities of said host system only as preconfigured.
23. The method of claim 22 wherein said number of modules of said fourth component includes a permissions subcomponent including a configure permissions module operatively coupled to said GMIS unit, a remote configuration file coupled to said configure permissions module and a doremote module coupled to said GMIS unit and to said remote configuration file, said preconfiguring step further including the steps of:
configuring whether remote dial-in access is to be permitted as a function of how said host system is configured and whether root access privileges are to be granted by generating a predetermined command with a preestablished command line parameters;
said configure permissions module in response to said predetermined command storing said parameters in said remote configuration file; and
said doremote module in response to a remote command specifying a task to be performed, accessing said remote configuration file to determine whether said task is allowed to be performed by said doremote module.
24. The method of claim 22 wherein said fourth component further includes a mirroring monitoring subcomponent, said subcomponent including a configuration monitor module operatively coupled to said GMIS unit and a monitoring configuration file coupled to said configuration monitor module and wherein said preconfiguring step further includes the steps of:
configuring said monitoring subcomponent by selecting parameters defining types of session scripting operations to be performed by said monitoring subcomponent and generating a predetermined command with command line parameters; and,
said configuration monitor module in response to said predetermined command accessing said monitoring configuration file and writing said parameters into said file specifying how said session scripting is to be performed.
25. The method of claim 24 wherein said configuring step further includes the step of entering a terminal type parameter for defining the type of terminal which is to be used by said response center in making the callback to said host system.
26. The method of claim 1 wherein said number of components of said RSF unit are included within a predetermined number of subpackages, said predetermined number of subpackages including a problem detection and reaction subpackage, a system action subpackage, a callback subpackage and a cluster subpackage and wherein said method further includes the step of:
selectively loading predetermined ones of said predetermined number of subpackages as a function of how said host system has been configured to operate.
27. The method of claim 2 wherein said GMIS unit utilizes a hierarchical organization of menu screens, said organization including an initial problem determination submenu containing a number of selection items relating to specific components of said number of components, each selection item leading to a number of submenus which in turn lead to dialogs for each command of said small number of commands enabling configuration of said number of said components.
28. A proactive and reactive remote services facility (RSF) unit installable within a host system which is operatively connected to communicate with a remote response center dedicated to performing remote support services for said host system involving diagnosis of host system problems reported to said center, said RSF unit comprising:
a number of independently operable software components, each component being constructed for performing one of a predetermined number of different basic functions required for performing said proactive and reactive support for Said host system;
each of said components including configuration control means for preconfiguring said each component by establishing predetermined parameters defining how said each component is to perform said one of said number of basic functions in carrying out remote support; and,
means for integrating said number of software components together in a predetermined manner so that said components collectively perform said proactive and reactive remote support according to said predetermined parameters.
29. The RSF unit of claim 28 wherein said host system includes a host computer, an operating system for controlling the operation of said host computer, a generic menu interface system (GMIS) unit for communicating with said operating system using menu initiated dialog sequences and a display terminal unit operatively coupled to said host computer and to said GMIS unit for enabling a user to enter commands directly or through said GMIS unit for execution by said RSF unit, said RSF unit further comprising:
means operatively coupling each of said number of software components to said GMIS unit; and,
each of said number of components further including a number of modules which operatively couple to said GMIS unit, said number of modules being responsive to a different predetermined command set containing a small number of commands customized for configuring said each of said components.
30. The RSF unit of claim 29 wherein said host computer further includes utility and application programming means for logging errors encountered while running on said host computer and wherein said remotely located response center performs support services for said host system by calling back into said host system in response to a first component of said number of components having detected an overthreshold condition which caused a callout action to be made by said RSF unit for further diagnosis and correction of a system problem reported by said host system, said first component further including:
a number of source error log files used by said programming means for logging said errors and a control attribute file;
means for configuring each of said number of source error log files to be monitored, said means for configuring causing storage of a source record entry in said control file for each of said number of source log files to be monitored, said record entry containing a unique user specified name for said log file, a path name to said log file, information identifying the type of log file, information identifying how omen to scan for new messages and information designating what notification action to invoke if a message is detected by said first component as being overthreshold; and;
means for initiating said notification action specified by said source record entry to said response center upon detecting an occurrence of an overthreshold condition within one of said source log ties being monitored.
31. The RSF unit of claim 30 wherein said means for configuring further includes means for specifying said scan rate by storing information coded to designate a time interval for monitoring error information being stored by each of said source error log files being monitored.
32. The RSF unit of claim 30 wherein said means for configuring further includes means for storing information coded for specifying a callout action and/or an electronic mail notification action.
33. The RSF unit of claim 30 wherein said means for configuring further includes means for storing type information coded to designate said source as a system or ASCII log file.
34. The RSF unit of claim 30 wherein said first component includes a message template database associated with each source log file to be monitored and wherein said means for configuring further includes:
module means for configuring said potential messages to be monitored by causing storage in said message template database designated by said source identifier contained in said control file entry for said each source log file, a number of information message entries corresponding to a number of said potential messages to be monitored, each said entry including search criteria information used for detecting when said potential message should be deemed to match messages stored in said source error log file and threshold information indicating a number of messages that must be exceeded to be deemed an occurrence of an over threshold condition.
35. The RSF unit of claim 34 wherein said search criteria includes either a message identifier for each system type of source error log file or regular expression parameters for each ASCII type of source error log file.
36. The RSF unit of claim 34 wherein said module means for configuring said message template database is responsive to a user generated make message source command.
37. The RSF unit of claim 34 wherein said first component further includes a library operatively coupled to said control file, said message template databases and source error log files and wherein said library stores a plurality of different types of routines which are accessed in response to said different commands of said small set of commands for configuring said first component.
38. The RSF unit of claim 34 wherein said plurality of different types of routines includes a number of different search routines, one for each different type of source error log file and wherein said means for configuring further includes:
means for accessing one of said different search routines according to type information stored in said control file for scanning said source by reading messages from said source; and,
means for comparing each message with message entries stored in said message template database for determining a match according to search criteria specified in said message entries.
39. The RSF unit of claim 29 wherein said number of components further includes a second component operatively coupled to said operating system and to said first component and wherein said means for configuring further includes:
preconfiguring said second component to be responsive to said notification action to perform any support notification operation in accordance with said specified callout action as preconfigured by said user.
40. The RSF unit of claim 39 wherein said number of modules of said second component further includes a call configuration file and a call configuration module coupled to said file and to said GMIS unit, said means for configuring including:
means for configuring site parameters and modem parameters through said GMIS unit as a function of how said host system has been configured;
means for initiating storage of said site parameters and modem parameters in said call configuration file by causing generation of a predetermined one of said set of commands with a preestablished command line; and
said call configuration module in response to said predetermined command causing said site parameters and modem parameters to be written into said call configuration file for subsequent use in controlling how said second component performs support notification operations.
41. The RSF unit of claim 40 wherein said host system is configurable in standalone, cluster client and cluster server configurations and wherein said host system is configured in said standalone and cluster server configurations.
42. The RSF unit of claim 41 wherein said host system is configured in a cluster client configuration and wherein said RSF unit further includes a third component for performing support notification operations using communications facilities of another host system, said number of modules of said third component including a call configuration module coupled to said GMIS unit and a call configuration file coupled to said call configuration module and to said GMIS unit and wherein in lieu of configuring site parameters and modem parameters, said configuring means includes:
means for configuring cluster server parameters through said GMIS unit;
means for initiating storage of said cluster server parameters in said call configuration file by causing generation of a predetermined command with a preestablished command line; and
said call configuration module in response to said predetermined command causing said cluster server parameters to be written into said call configuration file for subsequent use in controlling how said third component performs support notification operations.
43. The RSF unit of claim 41 wherein said means for configuring further includes:
means for configuring communications control OK and CONNECT strings as a function of modem type being used;
means for initiating storage of said communications control OK and CONNECT strings in said call configuration file by causing generation of said predetermined command with a preestablished command line; and
said call configuration in response to said predetermined command causing said communications control OK and CONNECT strings to be written into said call configuration file for controlling how said second component performs support notification operations.
44. The RSF unit of claim 39 wherein said number of modules of said second component further includes a call configuration file, a call configuration coupled to said file and to said GMIS unit and a mailaction module operatively coupled to said operating system, to said first component and to said call configuration file and wherein said means for configuring further includes:
means for configuring electronic mail address parameters as a function of whether said support notification operation includes a mail notification action;
means for initiating storage of said electronic mail address parameters in said call configuration file by causing generation of said predetermined command with a preestablished command line; and
said call configuration module in response to said predetermined command causing said electronic mail parameters to be written into said call configuration file for enabling said mail action module to perform said mail notification action using said electronic mail parameters.
45. The RSF unit of claim 40 wherein said number of modules of said second component further includes a callout manager subcomponent including a call control file containing a callout queue for storing callout requests generated in response to callout actions initiated by said first component and a plurality of different call modules, each different call module being operatively coupled to said GMIS unit and wherein said second component further includes:
means for removing a callout request through said GMIS unit by initiating generation of a first one of said small set of commands; and
a first one of said different call modules in response to said first one of said set of commands accessing said call control file and removing said callout request from said callout queue.
46. The RSF unit of claim 45 wherein said second component further includes:
means for changing parameters of a callout request by initiating generation of a second one of said set of commands with command line parameters; and
a second one of said different callout modules in response to said second one of said set of commands accessing said call control file and changing said callout request stored in said callout queue according to said command line parameters.
47. The RSF unit of claim 45 wherein said second component further includes:
means for listing callout requests stored in said callout queue by initiating generation of a third one of said set of commands; and
a third one of said different callout modules in response to said third one of said set of commands accessing said call control file and listing each request stored in said callout queue.
48. The RSF unit of claim 30 wherein said number of components further includes a fourth component operatively coupled to said operating system and to said GMIS unit and wherein said means for configuring further includes:
means for configuring said fourth component to enable further diagnosis of said problem by said response center by accessing facilities of said host system only as preconfigured.
49. The RSF unit of claim 48 wherein said number of modules of said fourth component includes a permissions subcomponent including a configure permissions module operatively coupled to said GMIS unit, a remote configuration file coupled to said configure permissions module and a doremote module coupled to said GMIS unit and to said remote configuration file, said configuring means further including:
means for configuring whether remote dial-in access is to be permitted as a function of how said host system is configured and whether root access privileges are to be granted by generating a predetermined command with a preestablished command line parameters;
said configure permissions module in response to said predetermined command storing said parameters in said remote configuration file; and
said doremote module in response to a remote command specifying a task to be performed, accessing said remote configuration file to determine whether said task is allowed to be performed by said doremote module.
50. The RSF unit of claim 48 wherein said fourth component further includes a mirroring monitoring subcomponent, said subcomponent including a configuration monitor module operatively coupled to said GMIS unit and a monitoring configuration file coupled to said configuration monitor module and wherein said preconfiguring means further includes:
means for configuring said monitoring subcomponent by selecting parameters defining types of session scripting operations to be performed by said monitoring subcomponent and generating a predetermined command with command line parameters; and,
said configuration monitor module in response to said predetermined command accessing said monitoring configuration file and writing said parameters into said file specifying how said session scripting is to be performed.
51. The RSF unit of claim 50 wherein said means for configuring further includes means for entering a terminal type parameter defining the type of terminal which is to be used by said response center in making the callback to said host system.
52. The RSF unit of claim 29 wherein said GMIS unit utilizes a hierarchical organization of menu screens, said organization including an initial submenu containing a number of selection items relating to specific components of said number of components, each selection item leading to a number of submenus which in turn lead to dialogs for each command of said small number of commands enabling configuration of said number of said components through said configuration means.
Description
BACKGROUND OF THE INVENTION
1. Field of Use
The present invention relates to systems for detecting and reporting problems encountered in a host system during normal operations and more particularly to methods and systems for providing remote maintenance and support services for Such host systems.
2. Prior Art
Numerous kinds of systems have been developed over the years for maintaining and diagnosing faults occurring within data processing systems either locally ore remotely. Such systems have taken the form of system management apparatus, maintenance processors and remote maintenance system interfaces and systems. Examples of these types of systems are discussed in U.S. Pat. Nos. 4,298,935, 5,202,963, and 5,210,757.
Also, software components have been used to provide remote support for host systems. One such system disclosed in U.S. Pat. No. 5,111,384 provides for automating the dump analysis process. Another type of system monitors a system error log to detect problems and automatically calls a remote center for diagnosis and corrective action. An example of this system is the remote maintenance manager (RMM) tool developed by Bull HN Information Systems Inc. which is described in the publication entitled, "DPX/2 500 Remote Maintenance Facility Guide," published by Bull HN Information Systems Inc., dated March, 1991, having Order No. LW07-00.
The remote maintenance manager (RMM) subsystem tool is implemented as a single component which is integrated into the operating system of the host system. The tool includes a daemon (background) process that is initialized by an interface program run by an administrator or operator to set up parameters for the RMM subsystem. The daemon process continues to monitor the host system for error conditions established through exceeding predetermined thresholds and responds by making an automatic callout to a response center when an established threshold has been exceeded.
Upon receipt of the callout and accompanying message, a remote operator is able to determine the source of the callout by examining the message contents. When the callout is made, the administrator is informed of the action by receipt of a mail message. Also, the remote operator writes a message to the administrator's console notifying the administrator when a callback has been made to host system by the remote operator. Such callback takes the form of the remote operator logging onto the host system's operating system facilities wherein the remote operator initiates a remote session.
If the administrator needs to terminate the remote session, the administrator enters a standard command via the console or can communicate with the logged on remote operator by standard operating system utilities.
This type of system is very inflexible in that its operations are dictated by a set of predefined sequences of operations which assumes the existence of a particular configuration of host system components.
With more and more vital information databases being entrusted to computerized systems, access and security of such information is of the utmost importance to users. Also, it is essential that faults or errors be detected and corrected without delay to prevent any loss of user information and computer time. At times, there arise conflicts between these two requirements. Also, since security requirements could vary from installation to installation, there could be a variety of different needs to satisfy. Hence, it is desirable that the user be able to have a certain degree of control over how remote support is carried out.
An area which should be distinguished relative to remote support systems is developments pertaining to network management which provide for the handling or processing of events occurring on a communications network. Network management systems normally manage a network of local or remote distributed resources and other communications devices for the purpose of ascertaining the status of such resources and devices in order to ensure that certain jobs or tasks have been completed. Such systems have the ability to receive events and include means for signalling software related alert conditions visually or audibly to an operator based on receipt of such events so that the operator is able to take any necessary prompt corrective action to bring about the completion of such jobs and tasks in a timely and proper fashion. Thus, this type of system is concerned with monitoring network resources and applications which utilize such resources. Examples of this type of system are disclosed in U.S. Pat. No. 4,965,772 entitled, "Method and Apparatus for Communication Network Alert Message Construction" which issued on Oct. 23, 1990 and U.S. Pat. No. 5,155,842 entitled, "Logical Event Notification Method and Apparatus" which issued on Oct. 13,
1992.
Therefore, there is a need to provide a high degree of flexibility and control in providing remote, support for a host system.
Accordingly, it is a primary object of the present invention to provide a highly modular and configurable remote support system for a host system.
Accordingly, it is a more specific object of the present invention to provide a remote support system which can be customized to meet user requirements for controlling how remote support is to be performed on a host system.
It is a further object of the present invention to provide a remote support system in which an administrator has greater control over the host system during the performance of remote support operations.
SUMMARY OF THE INVENTION
The above objects and advantages are achieved in a preferred embodiment of the present invention by a remote service facility (RSF) unit which is integrated into the operating system of the host system being supported. The RSF unit utilizes a standard generic menu interface system (GMIS) unit which is included as a standard part of the host operating system. Through this interface, a user can enter different types of commands which results in the display of a number of menu sequences for configuring how the different independently controllable components of the RSF unit will operate in performing remote support functions.
In the preferred embodiment, the RSF unit comprises three major components for carrying out the basic functions required for performing remote support. These are a problem detection and reaction component, a system action component and a callback component, each of which operatively couple to the GMIS unit. Each component is independently configurable and includes configuration means for storing configuration information accessed by the component which establishes how the component is to perform its particular function. The components are integrated in a predetermined manner so that collectively, they carry out remote support according to the way in which they were configured.
The problem detection and reaction component performs the function of monitoring a number of host error log file sources for determining when an error message over threshold condition occurs and initiating a specified action. In the preferred embodiment, the system action component includes modules for performing different types of support modification actions in response to the detection of a source over threshold condition. However, any defined action program module can be specified as the action to be performed when an overthreshold condition occurs. The callback component performs the function of processing calls from the response support center made in response to a callout action initiated by the problem detection and reaction component for purposes of conducting remote support operations.
The approach utilized by the present invention is that of defining a minimum number of basic functions required to perform the remote support function and then to utilize a corresponding number of independently operable components for carrying out those basic functions which are operatively coupled in a manner so as to collectively perform remote support function.
This approach makes it possible to maximize the configurability of each component. Additionally, the approach enables different components to be installed within the host system for supporting different host system communication configurations such as standalone and cluster configurations. Further, the arrangement facilitates the addition of new capabilities or improvements to components, new commands and new host system configurations without necessitating a redesign of the basic unit.
In the preferred embodiment, each component operates under the control of a separate daemon or background program which can be enabled or configured for operation through the GMIS unit. The configurations for components can be either preloaded or modified during installation of the unit's components as required for customizing the unit for a given host system configuration.
Considering each component in more particular terms relative to the preferred embodiment of the present invention, the configuring means of the problem detection and reaction component can be used to configure each type of error log source to be monitored. This is achieved by providing different search capabilities which are selected based on source type.
Also, the time interval for monitoring each source can be configured by setting a search time parameter to a desired value. This permits monitoring to be set according to the type of error information being stored by the host system or according to the frequency it is being stored by the host system. For example, where timing is critical to a source, the search time may be set to monitor the source once every second. If another source is used by the host system to store electronic mail messages or occasional messages, the search time for that source may be set to scan it once every hour. The associated daemon process, by accessing the configured search time parameters for each source, is able to schedule events for source monitoring according to such values. This has the advantage of being able to adjust search time values to reduce the amount of system overhead expended in executing the monitoring function.
Additionally, the configuration means of the problem detection and reaction component can be used to set a clean time parameter which establishes the time interval at which the daemon process cleans its associated database files to free them of stale messages. This parameter can be used in conjunction with another parameter (keepmax) for setting an upper limit on how many copies of a given message are to be stored in an associated storage message database file managed by the daemon process for each source being monitored thereby reducing host system storage requirements.
Also, in accordance with the present invention, the configuration means can be used to configure the problem detection and reaction component to enable different actions to be initiated in response to detecting an over threshold condition on a particular source. This decouples the problem detection and reaction component from the operation of the system action component thereby providing greater flexibility in prescribing what actions should be taken in a given case as well as the option to take no action in certain cases. Thus, a variety of different options can be configured. In the preferred embodiment, this includes callout via local or through shared communications facilities and mail notification actions.
The configuration means of the system action component of the preferred embodiment can be used to support the actions mentioned above through the facilities of the host system. Additionally, such means can be used to support the support notification actions for standalone and cluster host configurations (i.e., cluster client and cluster server). In the standalone configuration, the callout function is carried out by a daemon process which manages the execution of callout requests entered into a callout manager queue using the communication facilities (modem) of the host system. In the cluster configuration, the callout function is carried out through shared communication facilities using cluster client/server software facilities installed on the different systems which make up the cluster. An additional daemon process is used to manage such shared communications requests.
Also, the managing of the callout function in terms of how it is executed can also be configured. It is possible to select the type of response center communications protocol to be used in communicating a callout action and provide the appropriate parameters to a response center such as unique host system identification information for enabling the selected such callout remote center to respond properly to such callout request, a comprehensive list of response center phone numbers to be tried in sequence until a successful connection is made, remote password information to be used by the center in responding to the callout and an electronic mail address to which notification of the callout action is to be sent.
Also, in accordance with the present invention, the configuration means of the system action component can be used in specifying a comprehensive set of communication parameters for establishing a communications link via a large number of different types of modems such as acknowledgment response (OK) byte strings and connection byte strings which can vary from link to link. The configuration means further enables configuring other parameters such as the number of tries to be made for each phone number, the delay between busy tries and communications (modem) delays. This capability provides an effective way of matching the callout action to the type of host system resources to be utilized in making and responding to the callout function in an efficient and expeditious manner.
In accordance with the present invention, the configuration means of the callback component enables remote access by a response center, the establishment of permissions to be granted to a remote user and selection of a number of different types of session scripting or monitoring options for enabling an administrator of the host system to view all of the actions being taken by a remote user. In this way, it is possible to maintain the security and integrity of host system data as well as capturing for later viewing, all actions taken during a given session conducted in the performance of the remote support function. A further feature of the callback component is a hot key capability which allows the administrator to immediately terminate any current session by the remote user thereby providing further security control.
The above and other objects of the present invention are achieved in the illustrative embodiment described hereinafter. Novel features which are believed to be characteristic of the invention, both as to its organization and method of operation, together with further objects and advantages, will be better understood from the following description when considered in connection with the accompanying drawings. It is expressly understood, however, that these drawings are for the purpose of illustration and description only and are not intended as definition of the limits of the present invention.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a standalone configured host system which incorporates the remote support facility of the present invention.
FIG. 2 is a block diagram of cluster configured host systems which incorporate the remote support facility of the present invention.
FIG. 3 is a block diagram of the remote support facility of the present invention.
FIGS. 4a through 4d illustrate in greater detail, the different components of FIG. 3.
FIGS. 5a through 5e illustrate in greater detail, the formatting of the different databases and sources of the problem detection and reaction component of FIG. 4a.
FIG. 6 illustrates the organization of the menu system utilized by the, generic menu interface system of FIG. 1 in accordance with the present invention.
FIG. 7a illustrates a sample sequence of configuration steps.
FIG. 7b illustrates in greater detail, the install operation of FIG. 7a.
FIG. 7c illustrates in greater detail, the source configuration operations of FIG. 7a.
FIGS. 7d1 through 7d4 illustrates in greater detail, the callout, configuration operation of FIG. 7a.
FIG. 7e illustrates in greater detail, the set system identifier operation of FIG. 7d.
FIG. 7f illustrates in greater detail, the configure callback operation of FIG. 7a.
FIG. 7g illustrates in greater detail, the configure monitoring/mirroring operation of FIG. 7f.
FIG. 7h illustrates in greater detail, the configure diagnostic operation of FIG. 7a.
FIG. 7i illustrates in greater detail, the configure daemons operation of FIG. 7a.
FIGS. 8a through 8t illustrate menus utilized in carrying out the configuration operations of FIGS. 7a through 7d.
FIGS. 9a through 9c illustrate menus utilized in carrying out the configuration operations of FIGS. 7f and 7g.
FIGS. 10a through 10d illustrate menus utilized in carrying out the configuration operations of FIGS. 7h and 7i.
FIGS. 11a through 11d are flow diagrams used in describing the operation of the problem detection and reaction component of FIG. 4a.
FIGS. 12a through 12d and 13a through 13d are flow diagrams used in describing different functions performed by the callback component of FIG. 4c.
DESCRIPTION OF HOST SYSTEM OF FIG. 1
FIG. 1 illustrates the use of the remote service facility (RSF) unit of the present invention in a standalone system environment. As shown, this environment includes a host system 10 coupled to a communications link via a modem 12 for establishing dial out access to a remotely located response center 14 or a technical assistance center (TAC) as well as dial in access for carrying out support operations. As shown, the host system 10 includes a host computer system 10-2 which operatively couples to a main memory 10-3 and to input/output storage devices, such as disk files 10-16. The disk files 10-16 provide storage for the different files utilized by the RSF unit of the present invention. For the purpose of the present invention, the host computer system is conventional in design and may take the form of the DPX/20 system marketed by Bull HN Information Systems Inc.
A user can directly access the computer system 10-2 through a terminal or local console 10-14 while a system administrator is able to access system 10-2 through a administration terminal or administration console 10-12. As shown, each of the consoles 10-12 and 10-14 includes a display device, keyboard and optionally, a pointing device such as a mouse.
The system 10-2 is operated under the control of a UNIX* based software system 10-4 which includes a UNIX based operating system or kernel which controls the *UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open company Limited. computer system 10-2 and provide a system call interface to all of the programs running on the system. The system 10-4 also includes a library for storing procedures for processing such system calls (one procedure per call) and a large number of standard utility programs such as the command processor or shell, compilers, text processing programs and file manipulation utilities. Additionally, the host system includes a generic menu interface system (GMIS) unit 10-8 which operates as a resident command building facility. For the purpose of the present invention, the unit 10-8 can be considered conventional in design. In the preferred embodiment, GMIS takes the form of the System Management Interface Tool described in the publication entitled, "Bull DPX/20 General Programming Concepts" dated April, 1993, published by Bull HN Information Systems Inc., order reference SC23-2205.
In accordance with the present invention, the system 10 includes a remote services facility (RSF) unit 10--10 of the present invention which has an interface to GMIS unit 10-8 and to the UNIX system 10-4. The RSF unit 10--10 operates to detect problems occurring in the host system, to report such problems to a response center via autodial out and to provide a secure operating environment for callback responses made via dial-in access by such response center utilizing the host system facilities.
In addition to operating in a standalone configuration, the RSF unit 10--10 also operates in a cluster configuration of client and server host systems such as that shown in FIG. 2. As shown, each host system connects to a local area network (LAN) or wide area network (WAN) system. In this configuration, the modem 12 is shared among all of the host systems using the network communication facilities of the LAN/WAN system and remote call procedures (RPCs) provided as part of the UNIX system
10-4 utilizing the TCP/IP network software protocol. Each host system also includes its own complement of consoles, disk devices, etc., not shown.
As indicated and described in further detail herein, a different component module (netact/netacd) is configured for client host systems and the server host system directly connected to the modem 12 which is to be shared by the client host systems. In this system configuration, a callout request originating on a client host system is able to utilize the server host system via the LAN/WAN to make the callout request.
DESCRIPTION OF RSF UNIT 10--10
FIG. 3 shows in block diagram form, the packaging structure and major components of the RSF unit 10--10. As shown, the RSF unit 10--10 includes the following four subpackages: a problem detection and reaction subpackage 10-100; a system action subpackage 10-200, a cluster services subpackage 10-300 and a callback environment subpackage 10-400. As a function of the type of system installation, different ones of these subpackages are installed into the host system 10-2. The below table shows which subpackages are installed for the standalone, cluster client and cluster server system configuration illustrated in FIGS. 1 and 2.
TABLE ______________________________________ Problem System Type of Detection Action System and (Auto- Installa- Reaction Callback dial) Cluster tion Subpkg. Subpkg. Subpkg. Subpkg. ______________________________________ Stand X X X alone Cluster X X X Client Cluster X X X X Server ______________________________________
As indicated by the table, in the standalone system of FIG. 1, subpackages 10-100, 10-200 and 10-400 are installed. In each client system of FIG. 2, subpackages 10-100, 10-200 and 10-300 are installed. In the server system of FIG. 2, all of the subpackages 10-100, 10-200, 10-300 and 10-400 are installed.
Each of the subpackages will now be considered in greater detail. As shown in FIG. 3, subpackage 10-100 includes the problem detection and reaction component of unit 10--10. This component operatively couples to GMIS unit 10-8, to administrator console 10-14 and to local console 10-12 for receiving commands therefrom. As shown, component 10-100 provides output action signals to system action subpackage 10-200 and cluster subpackage 10-300. This component can be configured to monitor different types of sources such as the host system log error file and any ASCII log file generated by any application running on host system 10-2.
The component 10-100 includes a plurality of databases and log files represented by block 10-102 which are accessed via routines contained within a RSF library 10-104. A number of command programs included within block 10-106 execute the different types of commands received from GMIS unit 10-8 and consoles 10-12 and 10-14 utilizing the library routines of block 10-104. Additionally, component 10-100 includes a rsfd daemon 10-110 which also accesses certain routines of library 10-104 for performing certain operations such as diagnostic callout operations discussed herein. The rsfd daemon 10-110 monitors the configured sources to detect when messages reach over threshold conditions and executes those types of actions specified for such sources.
The subpackage 10-200 includes the system action component of RSF unit 10--10. As shown, the system action subpackage 10-200 operatively couples to rsfd daemon 10-100 to modem 12 and to cluster subpackage 10-300. In the preferred embodiment, component 10-200 includes a mail action subcomponent 10-202 and an autodial/callout subcomponent 10-204. The subcomponent 10-204 includes a callout manager module 10-210, a call force module 10-212, a call configuration file 10-216, a call action module
10-218 and a callout/callbin module 10-220 which operatively couple to each other as indicated in FIG. 3. When configured, the mail action subcomponent 10-202 operates to carry out electronic mail notification through the E-Mail facilities of the UNIX-based system 10-4. The callout subcomponent 10-204 when configured operates to carry out callout action operations initiated by the problem detection and reaction component 10-100 through modem 12 via module 10-220.
The cluster subpackage 10-300 includes the cluster services component of RSF unit 10-10. The cluster subpackage 10-300 operatively couples to rsfd daemon 10-110, the RPC and TCP/IP communication facilities of system 10-4 and to callout subcomponent 10-204 as shown. In the preferred embodiment, the component 10-300 includes a call force module 10-312, a callact module 10-318 and the netactd/netcall modules of block 10-320. To accommodate different installation requirements, modules
10-212, 10-214, 10-216 and 10-218 are also included in component 10-300 and correspond to modules 10-312, 10-314, 10-316 and 10-318. The modules netactd and netcall are used in cluster server and cluster client systems, respectively. When configured, the component 10-300 operates to carry out callout operations for cluster system configurations via the local area network and operating system communication facilities illustrated in FIG. 2.
The callback subpackage 10-400 includes the callback component of RSF unit 10--10. The callback subpackage 10-400 operatively couples to the modem 12, GMIS unit 10-8 and to console 10-12. As shown, component 10-400 includes a mirroring subcomponent 10-402 and a permission control subcomponent 10-422. The subcomponent 10-402 can be configured to carry out a plurality of different mirroring and scripting operations which enable an administrator to observe all of the operations carried out by a remote user who dials into the host system 10-2 from TAC 16. The permission control subcomponent 10-420 can be configured as desired for security purposes to control remote user access to host system facilities.
Problem Detection and Reaction Component 10-100--FIG. 4a
FIG. 4a shows in greater detail, the problem detection and reaction component 10-100 of the present invention. The block diagram indicates the operative coupling between the different programs and files utilized by the component 10-100. As shown, block 10-106 includes command programs 10-106a through 10-106k and files 10-106l and 10-106m. These programs are invoked through a command line generated either via GMIS unit 10-8 or console 10-12. With the exception of command program 10-106a, these programs access one or more routines contained in RSF library 10-104 as a function of the parameters contained in the command line. The program 10-106a also receives an input from the system 10-4 and the user generated configuration file 10-106m. As discussed herein, program 10-106a generates the initialization file 10-106l which can be used by programs 10-106b, 10-106c and 10-106e.
As shown, library 10-104 includes a plurality of routines 10-104a through 10-104k which will be discussed in greater detail herein. The routines 10-104a through 10-104k described in greater detail in the appendix are used to manage the contents of the database files and log files of block 10-102 as indicated in FIG. 4a. As shown, the database files 10-102 include an action log file 10-102a, a control or source attributes file 10-102b, a message template databases file 10-102c and a stored messages (keep) database file 10-102d. The source log files include any number of system error log files 10-102e and ASCII log files 10-102f. Additionally, block 10-102 includes a diagnostic configuration file 10-102g used by rsfd daemon 10-110.
The action log file 10-102a, shown in greater detail in FIG. 5c, is used to maintain a record of actions for one of the system error log files 10-102e designated as "system." As indicated in FIG. 5e, each action includes the data and time theaction was initiated, the path of the action program, the result of the action (successful, unsuccessful) and a description of the particular action performed (e.g. callout).
The control or source attributes file 10-102b is shown in greater detail in FIG. 5a. As shown, it contains one record for each source (log file) being monitored by RSF unit 10-8. Each such control record includes an identifier field specifying the user's name for the source, the path for accessing the source, the action to be taken such as identifying the program to be executed upon detection of an overthreshold condition, the type of source, and cleantime and searchtime values.
The message template databases file 10-102c is shown in greater detail in FIG. 5b. As shown, it contains information about all potential messages that are being monitored for a particular source. This includes search criteria (message IDs for system error log files or regular expressions for ASCII log files) and information used to determine if the message is overthreshold.
The stored messages (keep) database file 10-102d is shown in greater detail in FIG. 5d. As shown, the file contains messages of variable length, each of which include the following fields: ID, time stamp, expiration data, length of message and message field which store the indicated information. This database is used to carry out threshold detection operations. Since its operation is not pertinent to an understanding of the present invention, it is not described in further detail herein.
Examples of system error log files 10-102e and ASCII log files 10-102f are shown in FIG. 5e. The system error file of FIG. 5e is shown in human readable form as generated by system 10-4 of FIG. 1. Each entry includes the following fields: ID, label, type, class and error description. The ID field is an 8-character hexadecimal number which uniquely identifies each of the potential messages in the host system error log. The label field identifies the particular error condition. The type field indicates the type of error such as unknown, temporary (transient) and permanent (hard).
The class field indicates whether the error is a hardware (H) or software (S) error. The error description field provides a description of the error condition.
The ASCII log file includes lines of text separated by new line characters as shown in FIG. 5e. The text lines can take any form. In the case of clock errors, it was convenient to indicate the date, time, source and clock adjustments.
Considering the command programs of block 10-106 in greater detail, the make message template (mkmsgtmp) command program 10-106a allows for creation of an initialization file 10-106l which contains groups of messages to be added to the message template database file 10-102c for a particular source by programs 10-106b, 10-106c and 10-106e defining the potential messages to be monitored for over threshold conditions.
In greater detail, the mkmsgtmp program 10-106a reads in the standard input from a host system utility program normally used to print out all of the message templates utilized by the operating system 10-4 which contains information for all possible error messages which can be utilized by the host system 10-2. The user can set up values in tables within the configuration file which specify particular parameters, such as threshold, duration, keepmax values, for certain classes or types of potential error messages. The following is an example of such a configuration file:
______________________________________ HARDWARE PEND 2 10-mins 10 PERF 5 1-hour 10 PERM 1 1-day 10 TEMP 20 1-day 21 UNKN 1 1-hour 10 SOFTWARE PEND 7 1-day 10 PERF 10 1-day 11 PERM 6 1-hour 10 TEMP 25 1-day 26 UNKN 6 1-hour 10 RE X.*25 -5 1-hour +20 ______________________________________
When mkmsgtmp program 10-106a is invoked, it reads entries from system 10-4, examines the configuration file tables to determine which parameters the user has specified for that particular potential message and writes a record in the initialization file containing that potential message with the specified parameters. The mkmsgtmp program 10-106a is used for the creation of system source initialization files only. Examples of such initialization files are as follows:
______________________________________ ASCII SOURCE INITIALIZATION FILE: #expression threshold duration keepmax ______________________________________ "system.sub.-- error.sub.--.*" 2 1-day 50 "i/o.sub.-- error.sub.-- on-device.*" 5 4-days
20 ______________________________________ SYSTEM SOURCE INITIALIZATION FILE: #id threshold duration keepmax ______________________________________ 23e44f01 2 1-day 50 abcdef11 3 2-hours 50. ______________________________________
As explained herein, the command programs 10-106b, 10-106c and 10-106e can be invoked in a way to use the contents of the initialization file 10-106l to add a group of records at a time containing potential messages to a message template database included within block 10-102c. An example of the type of information written into the message template database is shown in FIG. 5b.
The mkmsrc command program 10-106b in response to an mkmsrc command which is generated by either unit 10-8 or from console 10-14 initiates the operation of defining a new source to be monitored by unit 10-2 (i.e., either a system log file or arbitrary ASCII log file). The mkmsrc command described in greater detail in the appendix provides the necessary parameters in a generated command line. The mkmsrc program 10-106b parses the command line and performs the necessary error checking operations for validating the command line parameters to ensure that source is valid. It then accesses the control routines of library 10-104 for writing a control record with the appropriate source attribute information into the control file database
10-102b.
If the command line includes an initialization file parameter option, this causes mkmsrc program 10-106b to access the search routines of library 10-104 to write the records previously stored in initialization file 10-106l containing all of the potential messages to be monitored for a particular source into the message template database file of block 10-102c. The result is a database such as shown in FIG. 5b.
Continuing with the other commands that can utilize initialization file 10-106l, the chmsrc program 10-106c allows modification of the message attributes of a particular source (e.g. 10-102e or 10-102f) being monitored utilizing the control routines of library 10-104. This program is invoked in response to a chmsrc command with the appropriate command line such as described in the appendix. If the command line includes an initialization file option parameter, then chmsrc program 10-106c accesses the search routines of library 10-104. The program 10-106c causes the record contents of the source's message template database to be replaced with the messages previously stored in initialization file 10-106l. It will be appreciated that with few exceptions, the information contained in initialization file 10-106l and information contained in the source's message template database is the same information, except for the following differences. The initialization file is in human readable format, while the message template database is in binary format. The message template database also contains count information which is initialized to zero when the messages are added.
The last command program which utilizes initialization file 10-106l is mkmsg program 10-106e. This program enables a message to be added to a source's message template database utilizing the search routines of library 10-104. This program is invoked in response to a mkmsg command with the appropriate command line such as described in the appendix. If the command line includes an initialization file option parameter, then mkmsg program 10-106e via the search routines adds the messages previously stored in initialization file 10-106l to the source's message template database.
The lsmsrc program 10-106b allows information pertaining to one or more identified sources being monitored by unit 10--10 to be displayed or printed using the control routines of library 10-104. This program is invoked in response to a lsmsrc command which generates an appropriate command line such as described in the appendix. The program 10-106c invokes various routines contained in library 10-104 for accessing information contained in action log 10-102a and control file 10-102b, to be displayed or printed as specified by the command line parameters.
The rmmsrc program 10-106d allows the removal of a source being monitored. This program is invoked in response to a rmmsrc command with an appropriate command line such as described in the appendix. When invoked, program 10-106d utilizing the applicable routines of library 10-104 removes the appropriate record from control file 10-102b, removes the source's message template database, removes the appropriate keep-base information pertaining to the source and action log information for the specified source.
The lsmsg program 10-106f allows the listing of messages being monitored for a particular source. This program is invoked in response to a lsmsg command with the appropriate command line parameters such as described in the appendix. The program
10-106f invokes the appropriate routines in library 10-104 for accessing information contained in control file 10-102b, and the source's message template database used in listing such messages.
The chmsg program 10-106g allows modification of the attributes of messages being monitored. This program is invoked in response to a chmsg command with the appropriate command line parameters such as described in the appendix. The program
10-106g invokes the appropriate routines in library 10-104 accessing the control file 10-102b to obtain the record specific to the identified source and uses the specified message ID to locate the message to be changed in the message template database. It then updates the message template database with all the changes made to the message. It also updates the keep database 10-102d as required so as to properly reflect and be consistent with such changes (e.g. if a new threshold value is less than the current count, the appropriate keepbase record entry for that message is cleared).
The rmmsg program 10-106h is used to remove a record from a message template database thereby stopping RSF unit 10--10 from monitoring a particular message for a particular source. This program is invoked in response to a rmmsg command with the appropriate command line parameters such as described in the appendix. The program 10-106h in turn invokes the appropriate routines in library 10-104 which remove the message from the message template database of block 10-102c identified by the command line parameters, in addition to removing all messages stored in the keep database of block 10-102d having the same message identifier.
The chrsf command program. 10-106 is used to start and stop/shut down the operation of rsfd daemon 10-110 and netactd daemon of cluster service component 10-300. This program is invoked in response to a chrsf command with the appropriate command line parameters described in the appendix. When invoked, the program 10-106 accesses the PID routines in library 10-104 for accessing the RSF PID file to determine if the rsfd daemon is running. The program 10-106i then initiates the appropriate action to start or stop the daemons as specified by the command line parameters. For the purposes of the present invention, the daemons are started and stopped in a conventional manner using the facilities of system 10-4.
The confdiag program 10-106j allows configuration of a diagnostic callout feature which enables callout action to be initiated at selected intervals such as daily, weekly, biweekly, monthly or bimonthly. This program is invoked in response to a confdiag command with the appropriate command line parameters described in the appendix. When invoked, the program accesses the appropriate routines in library 10-104 which enter the frequency at which a diagnostic message is to be injected into the system error log 10-102e as designated by the command line parameters into the diagnostic configuration file 10-102g add the diagnostic message to the system log source's message template database.
The rsfstat program 10-106k allows the status or configuration of the daemons utilized by RSF unit 10--10. This program is invoked in response to a rsfstat command with the appropriate command line parameters described in the appendix. When invoked, this program accesses the appropriate routines in library 10-104 which determine through the PID files which daemons are running and displays such status on host system 10-2. There is one PID file for each daemon.
Description of RSF Daemon 10-110
The rsfd daemon 10-110, for the purpose of the present invention, operates in the background like any standard daemon running in a UNIX-based operating system. As discussed herein, rsfd daemon 10-110 performs checks on message sources and when necessary executes preconfigured actions. It also maintains the message template search database, keepbase and action log files 10-110a, 10-101a, 10-102c and 10-102d. Accordingly, daemon 10-110 maintains a list of such managed message sources including information such as the control record and open file descriptors for the template search database and keepbase. In addition to using certain ones of the library routines, the rsfd daemon also uses a number of its own routines. These include event routines, action routines, signal routines, initialization routines, source search routines, keepbase and diagnostic message routines. The event routines are used to schedule events by creating new event structures which are placed on an event list, described later herein.
The action routines are used to free and allocate space for action data structures, calculate arguments for action process and place them in an argument list in the action data structure.
The signal routines perform waits for the finished child processes and get the PIDs. It looks up the action records and adds the records to the action log of the associated source.
The initialization routines read the control file and initialize the source list. It reads entries from the control file and for each entry it opens all associated files, creates a new source item and places it on the list. It opens the message template database, the keepbase and source files. It initializes the action list to NULL. As discussed herein, the initialization routines schedule initial events.
The source search routines perform message scanning of a particular source. That is, they read messages from the source, compare messages against the message template database, manipulate counts, manage the keepbase and perform actions if necessary. If a match between the source file message template database is detected, it adds the message with time stamp information to the keepbase. If a message template (search) database entry for a message is already overthreshold, this is noted and the message count is updated.
The keepbase cleaning routines delete excess messages and search for overthreshold errors for a source starting at the beginning of the keep database. The diagnostic routine writes a specified message into the system error log file.
System Action Component 10-200 Detailed Description--FIG. 4b
FIG. 4b shows in greater detail, a portion of the system action component 10-200. More specifically, it shows the modules which make up the callout manager module 10-210. These modules correspond to a make call (mkcall) module 10-210a, a calld daemon 10-210b, a file 10-210c containing a set of call control file access routines, a list call (lscall) module 10-210d, a change call (chcall) module 10-210e, a remove (rmcall) module 10-210f and a call control (callctrl) file 10-210g which are operatively coupled as shown. The lscall module 10-210d allows callout requests stored in a callout queue in file 10-210g by the callout manager 10-210 to be listed. As discussed, callout manager 10-210 controls the timing and sequencing of callout requests made to a response center. It manages the callout requests stored in the callout queue. The callout queue is serviced by calld daemon 10-210b and parameters relating to the queue can be set by chcall module 10-210e. This queue also can be manipulated by mkcall module 10-210a and rmcall module 10-210f.
The lscall module 10-210d is invoked by a lscall command with the appropriate command line parameters described in the appendix. When invoked, module 10-210d accesses the call control file access routines of block 10-210c to read out queued callout requests for listing as specified by the command line parameters.
The chcall module 10-210e is invoked by a chcall command with the appropriate command line parameters described in the appendix. When invoked module 10-210e enables configuration of the delay and max calls parameters stored in file 10-210g and used internally by the callout manager 10-210 in controlling the processing of queued callout requests.
The rmcall module 10-210f is invoked by a rmcall command with the appropriate command line parameters described in the appendix. When invoked, module 10-210f utilizing the call control file access routines of block 10-210c removes callout requests from the callout queue as specified by the command line parameters.
The calld daemon 10-210b, as indicated, services the queue by scanning it for waiting callout requests and executing the requested callout action by transmitting a callout record created by callact module 10-218 via callout/callbin module 10-220
and modem 12 to the response center.
The mkcall module 10-210a in response to receipt of a call action request from callact module 10-218 sets up a new record entry after determining that there are not too many callout requests waiting. It uses the command line parameters received from module 10-218 to be added to the callout queue of call control file 10-210g. It then updates its callout count and next sequence number in a call control header used to identify the sequence of callout requests.
The other modules of FIG. 4b will now be discussed in greater detail. The call configuration (callcfg) module 10-214 allows the display and modification of all of the various parameters in configuration file 10-216. The module 10-214 is invoked in response to the callcfg command with the appropriate command line parameters as described in the appendix. When invoked, module 10-214 accesses the callconf file 10-216, reads it, verifies that the specified subpackages are installed and modifies the applicable configuration structure according to the command line parameters. Also, module 10-216 displays the different configuration parameters as specified by the command line parameters.
The callforce module 10-212 performs a forced callout operation with a user defined free form record of data. This module 10-212 is invoked in response to a callforce command with the appropriate command line parameters described in the appendix. When invoked, module 10-212 determines which editing facility in system 10-4 to use to create the free form record, gets the user generated callout message from a user file and generates a callout record containing the required information. The module 10-212 then performs the callout operation via callout module 10-220 in the case of a standalone host system or via the netact module 10-320 in a cluster system.
Cluster Services Component 10-300--FIG. 4c
FIG. 4c shows in greater detail, the cluster services component 10-300 can be viewed as having a cluster client subcomponent 10-300a and cluster server subcomponent 10-300b. Callcfg module 10-314, callconf file 10-316, callact module 10-318, callforce module 10-312 and netact module 10-320 make up the cluster client subcomponent 10-300a. The netact daemon 10-320 and netcall module 10-320 make up the cluster server subcomponent 10-300b. The callact module 10-318 and callforce module 10-312
perform the same functions as described in connection with system action component 10-200. The netact module 10-320 when invoked by either module 10-312 or 10-318 in response to receipt of command arguments, contacts the cluster server system subcomponent 10-300b via the operating system network facilities and sends the command arguments to netactd daemon 10-320. The daemon 10-320 in turn calls netcall module 10-320 which sends out a callout record to the response center 16 via callout module 10-220 in the case of callforce module 10-312 or through the callout manager in the case of callact module 10-312.
Callback Component 10-400 FIG. 4d
FIG. 4d shows in greater detail, the mirroring subcomponent 10-402 and permission control subcomponent 10-422 of callback component 10-400. As shown, subcomponent 10-402 includes a remote account module 10-403, a command for configuring monitoring options (confmon) module 10-404, a monitoring configuration file 10-405, a callscript module 10-406, a PID file 10-407, an interactive session monitoring file 10-408, a session log file(s) 10-409, a lsles module 10-410, a rmlses module 10-411, a showlses module 10-412, a showses module 10-413 and a showscript module 10-414. These modules and files are operatively coupled as shown in FIG. 4d. The profile module 10-403 is operatively coupled to receive the remote login from the TAC 14 via modem 12. The login is received and processed by host system 10-2 in a conventional manner through the remote login facilities of UNIX based system 10-4. However, the profile module 10-403 causes the remote login session to be executed in a predetermined manner under control of callback component 10-400 as described herein.
The confmon module 10-404 allows the configuration of the callback monitoring sessions by mirroring subcomponent 10-402. The confmon module 10-404 is invoked in response to a confmon command with the command line parameters described in the appendix. When invoked, module 10-404 reads the existing configuration from configuration file 10-405, processes the command line parameters, performs any necessary checks and writes the new configuration into configuration file 10-405.
The callscript module 10-406 performs the required operations necessary to carry out the scripting operations in response to a callscript command with the command line parameters described in the appendix. When invoked, module 10-406 opens up the appropriate file(s) into which data from modem 12 is to be written, then sets the terminal modes and routes the data into the designated files (i.e., 10-408, 10-409). Additionally, the module 10-406 also accesses PID file 10-407 as required for recording the process ID of the child process it creates to carry out the operation specified by the command line parameters. The child process alos poerforms other functions such as closing those files opened by the parent process not needed by the child process.
The showscript module 10-414 operatively couples to administrator console 10-14. The module 10-414 allows display or playback of the monitoring output captured by callscript module 10-404 and stored in one or more of the files 10-408 and 10-409
during a scripting session. The module 10-414 is invoked in response to a showscript command with the command line parameters described in the appendix. The command may be initiated by GMIS unit 10-8 through showlses module 10-412 and showses module
10-413 as indicated in FIG. 4d. When invoked, module 10-414 reads the files-created by callscript module 10-406 and enables playback of the session files on console 10-14 in two modes. In one mode, module 10-414 shows complete session and terminates operation. In another mode, it shows the current session as it is being created and where the end of the file is reached it waits for more data to be added to the file.
The first mode is carried out under control of showlses module 10-412 while the second mode is controlled by showses module 10-413. The showlses module 10-412, as mentioned, allows the playback of a completed or logged session. The module
10-412 is invoked in response to a showlses command with the command line parameters described in the appendix. When invoked, module 10-412 performs the necessary checks (i.e., access permission and valid command line argument). It obtains the designated or named logged session(s) to be reviewed and provides the required parameters to showscript module 10-414 for displaying the session file(s).
The showses module 10-413, as mentioned, allows the playing of a currently active session, if available. The module 40-413 is invoked in response to a showses command described in the appendix. When invoked, showses module 10-413 performs the necessary checks and verifies that there is a current session taking place (i.e., callscript module 10-406 is running). If there is current session running, module 10-413 passes the required parameters for displaying the current session to showscript module 10-414.
The lslses module 10-410 allows listing of logged sessions. This module is invoked in response to a lslses command described in the appendix. When invoked, module 10-410 accesses the directory of session log files 10-409 and lists the logged sessions using the facilities of system 10-4.
The rmlses module 10-411 allows removal of logged sessions. This module is invoked in response to a rmlses command which generates command line parameters described in the appendix. When invoked, module 10-411 performs permission and command argument checks and then accesses the directory of the session log files 10-409 and removes the specified session.
The permission control subcomponent 10-422 includes a doremote module 10-424, a remote configuration (remote conf) file 10-426, a configure permissions (confperm) module 10-428, a privileged tasks function module 10-430 and nonprivileged tasks function module 10-432. The modules are operatively connect as indicated in FIG. 4d.
The doremote module 10-424 performs operations for the "remote" user that require a certain level of permission. The module 10-424 is invoked in response to a doremote command which generates command line parameters described in the appendix. When invoked, module 10-424 accesses remote config file 10-426 for determining if root access is allowed. When it is, the module spawns a root subshell.
The confperm module 10-428 allows the configuration of permissions to be granted to remote users who have logged onto the host system 10-2 through remote account module 10-403 and operating under the control of callback component 10-400. This module is invoked in response to a confperm command with the command line parameters described in the appendix. When invoked, module 10-403. It accesses the permissions configuration file through access routine, not shown, similar to those described above and reads the existing configuration from file 10-426. It then processes the command line parameters and writes the new configuration into file 10-426.
The privileged tasks module 10-430 and the nonprivileged tasks module 10-432 provide the appropriate interface call parameters to the operating system 10-4 required for carrying out their respective tasks.
RSF Unit Menu System--FIG. 6
As discussed above, the RSF unit 10-10 utilizes the generic menu interface system (GMIS) unit 10-8 which provides a graphic interactive screen oriented command interface. This interface in the preferred embodiment uses a hierarchical screen organization which includes menu, selector and dialog screen to generate the required command line parameters for causing RSF unit 10-10 to perform a specific task. FIG. 6 illustrates the relationships between the different menu, selector and dialog screens utilized by unit 10-10 according to the present invention. As indicated, RSF unit 10-10 is accessible from the top level of the menu system which corresponds to a problem determination submenu. This submenu includes four selection items corresponding to message sources, messages, actions and callout/callback. All four menu items lead to submenus and all traversals down through the menu structure eventually lead to dialogs for each RSF command associated with the menu selection. Therefore, the different command line operations described above in connection with FIGS. 4a through 4d are normally carried out using this interface.
Description of RSF Configuration Process FIGS. 7a Through 7i
FIG. 7a illustrates a sequence of configuration operations which have been chosen only for the purpose of explaining by way of example, how the different components of RSF unit 10--10 can be configured to operate according to the present invention. In many instances, the parameters being configured in the example would normally have been preconfigured within unit 10--10 and the user or customer running the host system 10-2 would only need to modify such parameters if there was a need to do so.
Considering FIG. 7a, it is seen that to integrate RSF unit 10--10 into host system 10-2, an install operation is performed as indicated by block A. This operation is initiated by a user through GMIS unit 10-8. The install operation proceeds in a conventional way relative to placing the diskettes containing the RSF subpackages into an available disk drive device. The user next selects the device name for the drive device to be used for installing RSF (e.g. /dev/fd0) contained in an initial dialog menu. The user upon indicating to unit 10-8 to continue the install operation, is next presented with the dialog menu of FIG. 8a.
As shown, the menu indicates that the previously named device is the device being used to install the RSF subpackages. The user changes the "SOFTWARE to install" menu item to select only the subpackages that are required for the type of host system configuration which is going to use RSF unit 10--10. Assuming that the host system is configured as a standalone system, the user would make the selections as shown in FIG. 7b. This is carried out by selecting the "List" button next to the "SOFTWARE to install" field. This causes the unit 10-8 to display the selector menu of FIG. 8b. Next, the user selects both the "obj" and "data" parts for each subpackage which is to be installed. Such selections are made according to FIG. 7b. After each subpackage selection is made, the user causes the dialog to be executed according to the instructions displayed on the menu screen. As indicated in FIG. 7b, after completing the selection process of block 700, the user causes the dialog to be executed which begins the installation operation of block 702. During this operation, the host system 10-2 prompts the user for the disks to be swapped during the installation. In the present example, the result is that subpackages 10-100, 10-400 and
10-200 will be installed in host system 10-2.
As indicated in FIG. 7a, by way of example, the user performs the operation of configuring a host system source such as ASCII source 10-102f of FIG. 4a. The sequence of operations for configuring the source is shown in detail in FIG. 7c. Referring to FIG. 7c, it is seen from FIG. 6 that the User selects the "message sources" submenu from which can be run, four tasks, one of which is labeled "add a source." The submenu can be selected directly through a fast path. For this submenu, the user types GMIS msg.sub.-- sources. This results in the display of the first submenu of FIG. 8c as indicated by block 710 of FIG. 7c.
The user by selecting the "add a source" menu item causes the display of the dialog screen shown in menu #2 of FIG. 8c.
As indicated by blocks 712, 714 and 716, the user enters information such as the source identifier, source path name and the pathname of the action to be executed such as a callout action indicated as/usr/bin/callact. Next, as indicated by block
718, the user enters information specifying the source type as an ASCII source which is indicated as "ASCII." Also, the user specifies the source's cleantime and searchtime parameters as indicated by blocks 720 and 722.
In adding the source, the user also needs to specify the potential messages which are to be monitored by the source being added. This can be done in two ways. One way is to prepare an initialization file ahead of time either manually or by using the mkmsgtmp program 10-106a in the manner previously discussed. In that case, the user need only specify the initialization file as indicated by block 724 and then perform the indicated dialog. The block 106 of FIG. 4a will cause these messages to be added to the message template database for the specified ASCII source 10-102f when the source is added. The GMIS unit 10-8 generates a command line for the mkmsrc command with the user supplied information. Mkmsrc program 10-106b causes the source to be added by establishing the appropriate control record for the ASCII source within control file 10-102b in the manner discussed above.
If an initialization file has not been prepared ahead of time, the user can add messages one at a time by selecting the "add messages to message template database" submenu. As shown in FIG. 6, this submenu is displayed By selecting the "add messages to message template database" item of the messages submenu as indicated in block 730. Selecting this item results in the display of a selector screen containing the identifiers of all sources currently being monitored by RSF unit 10--10. The user selects the source identifier that was Just added as indicated in block 732. Once the desired source is selected, the dialog screen of FIG. 8d is displayed by GMIS unit 10-8.
Next, as indicated in block 734, the user selects the regular expression value for the message which is the parameter used to match messages read from ASCII log file 10-102f. The user next performs the operations of blocks 736 through 738 for selecting the message threshold, the duration and keepmax parameters for that message. This results in the generation of a mkmsg command line by GMIS unit 10-8 which invokes the mkmsg program 10-106e of FIG. 4a. As previously discussed, this program causes the message having the user specified parameters to be added to the message template database of the added ASCII source as indicated by block 740. If there are more messages to be monitored for the source, then the user repeats the sequence defined by blocks 730 through 740 for each message to be added.
Following completion of adding an ASCII source, the user by way of example, next configures a system source as indicated by block C in FIG. 7a. This operation is performed in the same way as configuring an ASII source. The only differences are when the user specifies the source type, "SYSTEM" is selected instead of ASCII. Also, instead of selecting a regular expression value, the user selects a message identifier (ID) which uniquely identifies each of the potential messages in the host system error log 10-102e of FIG. 4a (see FIG. 5e). The above described arrangement facilitates the addition of other types of binary log files having specific structures.
As seen from FIG. 7a, the user by way of example, next performs the configure callout operation of block E for configuring the system action component 10-200 of FIG. 4b. The sequence of operations performed relative to block E are shown in FIGS.
7d and 7e.
As indicated by block 750 of FIG. 7d, it is necessary to determine if the host system utilizing RSF unit 10--10 is a cluster client system since the operations for configuring the callout component are different for the cluster client system than those for configuring a cluster server or standalone system. The reason is that the cluster server or standalone system includes a directly connected modem. Since the cluster client system performs the callout function through a cluster server system over the LAN/WAN, the user of a cluster client system does not have to configure all of the parameters which relate to such modem connection.
Since the host system 10-2 is a standalone system, the user performs a "configure callout (local modem)" selection of block 752 which results in the display of the submenu of FIG. 8e by GMIS interface 10-8 as indicated in block 753. The menu path is as indicated in FIG. 6.
The submenu of FIG. 8e contains a set of selections that allows customization of the autodial function of component 10-200. These selections include site parameters, modem parameters and callout tuning. Selecting the "site parameters" item of block 754 results in the display of another submenu such as shown in FIG. 8f. As indicated in block 756, this submenu contains further selections for manipulating local operator and system information.
When the user selects the "System Identifier" menu item of FIG. 8f, this causes GMIS unit 10-8 to generate submenus requiring further user actions. The set system identifier operation of block 758 is shown in greater detail in FIG. 7e. Upon selection of the "set system identifier" item on the displayed submenu, GMIS presents a dialog screen which asks the user to select what type of support center protocol will be used as indicated by block 758. This allows the host system 10-2 to communicate with response centers in different geographical areas which may use different standard protocol sequences/procedures for processing support calls. As indicated by block 758-2, the user selects either "RC" or "SC." This results in the user performing the operations of either block 758-4 or block 758-8. For block 758-5, the user only enters the system number information. In the case of block 758-8, the user enters several items of information which are the site identifier, the model, the serial number and a TAC character all of which have some specific meaning to the SC site processing the host system call. In either case, upon completing the entering the required information items, the user executes the dialog according to the instructions on the menu to execute the procedure for storing the system identifier parameters (i.e., "execute dialog in blocks 758-4 and 758-8"). This causes GMIS unit 10-8 to generate a callcfg command. The callcfg command is provided with a command line containing all of the required system identifier parameters defined by the user which are provided or passed in the proper form to callconfig module 10-214 for causing the storage of the user selected system identifier parameters in callconfigfile
10-216. Independent of which procedures are executed, both lead to the operation of block 760 of FIG. 7d.
When the user selects the "BRC Phone Numbers" menu item according to block 760, this results in the display of the submenu of FIG. 8g. This submenu allows the user to list, add or delete response center telephone numbers sequentially as indicated in block 762. When the user selects the item "Add a BRC Phone Number," this allows the user to enter or configure each of the proper phone numbers as indicated by blocks 764 and 766. The GMIS unit 10-8 generates a callcfg command to carry out the required "execute dialog" of block 766.
As described above, callcfg command is provided with a command line containing the appropriate phone number parameters based upon user selections which are provided to the callconfig module 10-214 for causing storage of the user selected parameters in callconfig file 10-216.
As indicated by block 768 in FIG. 7d, the user repeats the operations of blocks 764 and 766 until all of the proper phone numbers have been entered. Next, the user returns to the "site parameters" submenu as indicated by block 770. This involves following the path indicated in FIG. 6 for again displaying the submenu of FIG. 8f. This time, the user selects the "other side parameters" menu item which results in the displaying of the submenu of FIG. 8i.
As indicated by block 774, the user enters other site parameters such as those illustrated in FIG. 8i. As shown, these include operator name and phone number, system phone number, remote password, the path name of the terminal (TTY) utilized in making the callout operation and the E-Mail address of the local system operator or to the person whom notification of the callout attempt should be sent. The operator name and phone number enables the TAC 14 to contact the local system operator to arrange for a problem determination session. The remote password enables access to the remote account module 10-403 of callback component 10-403 of FIG. 4d. When the local administrator or user does not wish to allow remote access, this item is left blank. It will be appreciated that the actual password is set by using the "passwd" command facilities of system 10-4. The user then executes the dialog according to the instructions displayed by the submenu of FIG. 8i to execute the procedures for processing the entered information. As described above, it causes GMIS unit 10-8 to generate a callcfg command. The callcfg command is provided with a command line containing all of the required user entered other site parameters which are passed in the proper forms to callconfig module 10-214 for causing the storage of such parameters in callconfig file 10-216.
As indicated by block 776, the user backs out to the "configure callout (local modem)" menu of FIG. 8e. This is done by sequencing back through the path indicated in menu system of FIG. 6. As indicated by block 780, the user determines if the modem being used by host system 10-2 is the normal preconfigured (default) modem connection. If it is not, the user selects the "modem parameters" menu item of FIG. 8e (i.e., block 782). This causes GMIS unit 10-8 to display the submenu of FIG. 8j as indicated by block 782.
The user performs the sequence of operations of blocks 786 through 810 for certifying that the correct modem communication string parameters are provided for configuring callout communications for both standone alone and cluster server system configurations.
As shown, the user selects the "OK strings" menu item on the display submenu of FIG. 8j. This causes GMIS unit 10-8 to display the submenu of FIG. 8k as indicated by block 788. As seen from FIG. 8k, the user can list, add or delete OK strings. OK strings are the messages sent by the modem indicated the successful completion of a modem command. A list of modem OK strings can be displayed by having the user selecting the "list" menu item of the submenu of FIG. 8k as indicated in block 790 of FIG. 7d.
in response to block 790, GMIS unit 10-8 displays the current list of modem OK strings without any user dialog. As indicated by block 792, if the user determines that an OK string needs to be added, the user then selects the "ADD OK string" item from the menu of FIG. 8k. This causes GMIS unit 10-8 to display the dialog screen of FIG. 8l.
Next, the user enters the OK string which for most modems corresponds to the default of "0" and "OK" and presses the enter key. This causes GMIS unit 10-8 to execute the required procedure (i.e., execute dialog) as indicated in block 795. That is, this causes GMIS unit 10-8 to generate another callcfg command. The callcfg command is provided with a command line containing the user entered OK string and command parameters which are passed in the proper format to callconfig module 10-214 for the storage of such parameters in call config file 10-216.
If an OK string does not need to be entered, the user determines if an OK string needs to be deleted as indicated by block 796. If a string is to be deleted, the user selects the "delete OK string" item on menu FIG. 8l as indicated in block 797. This causes GMIS unit 10-8 to display a dialog screen similar to that of FIG. 8l. This OK string to delete may be entered manually or selected from a list. In this sequence, when a string is selected by the user and the dialog is executed to carry out the procedure (execute dialog) indicated in block 798, GMIS unit 10-8 causes the removal of the selected string from the list. That is, this causes unit 10-8 to generate a callcfg command containing a command line which includes the selected string and command parameters. These parameters are passed in the proper format to call config module 10-214 which accesses config file 10-216 and deletes the specified string from such file.
As indicated in FIG. 7d, the user can carry out a similar sequence of operations relative to connect strings. Connect strings are the messages sent by a modem to indicate that a successful communication connection has been established. The operations of blocks 801 through 809 are carried out in the same manner as the list, add and delete operations for the 0K strings described above. As shown in block 799, the user backs out to the "modem parameters" menu screen shown in FIG. 8j. This is done by following the path indicated in FIG. 6.
As indicated in FIG. 7d, the user, by selecting the "connect strings" menu item of FIG. 8j, causes GMIS unit 10-8 to display the submenu screen of FIG. 8m. If a connect string needs to be added, the user selects the "ADD Connect String" submenu item as indicated in blocks 804 and 805. This causes GMIS unit 10-8 to display the dialog menu screen of FIG. 8n. Again, the user enters the connect string to be added and executes the dialog. As indicated in block 806, this causes GMIS unit 10-8 to execute the procedure for adding the user entered connect string. That is, GMIS unit 10-8 generates a callcfg command containing a command line which includes user entered "connect string" and command parameters. These parameters are passed in the proper format to call config module 10-214 which accesses config file 10-216 and stores the specified connect string. If a connect string needs to be deleted, the user selects the "Delete Connect String" menu item from the submenu screen of FIG. 8m, enters the string to be deleted and executes the dialog as indicated in blocks 807 through 809. This sequence causes GMIS unit 10-8 to execute the procedure for deleting the user selected connect string. That is, GMIS unit 10-8 generates a callcfg command containing a command line which includes the user selected connect string and command parameters. These parameters are passed in the proper form to call config module 10-214 which accesses config file 10-216 and deletes the specified connect string from the file.
After completing this sequence, the user is able to enter additional modem parameters by backing out to the modem parameters submenu screen of FIG. 8j. As indicated by blocks 810, 812 and 814, the user upon selecting the "other modem parameters" menu item on the menu screen of FIG. 8j causes GMIS unit 10-8 to display the menu screen of FIG. 8o. As indicated in FIG. 7d, the user can enter several other modem parameters.
As illustrated in FIG. 8o, these include selection of modem network protocol (yes or no), a callback condition string which defines the modem callin conditioning string, a callout condition string which defines the modem callout conditioning string, a dial string which is the modem command string that is used to execute modem-dialing operation, a redo string which is a modem command string used to execute a modem dial repeat operation, a disconnect string which is a modem command string used to execute a modem disconnect operation, a hang-up string which is a modem command string used to execute a modem hang-up operation, a busy string which is a modem reply string for indicating when the dialed number is busy, character size (bits) parameter defining the number of bits in a character (5-8), a stop bit parameter indicating the number of stop bits in a character, a parity parameter for indicating odd, even or no parity and a baud rate parameter defining the baud rate of the modem. Upon completing the entering of the parameters, the user executes the dialog which causes GMIS unit 10-8 to execute the required procedure for adding the user entered modem parameters. That is, GMIS unit 10-8 generates a callcfg command containing a command line which includes the other modem and command parameters. These parameters are passed in the proper form to call config module 10-224 which accesses config file 10-216 and stores the other modem parameters in the file.
The final menu item appearing in the "Configure Callout (Local Modem)" menu screen if FIG. 8e is "Callout Tuning." The selection of this menu item causes GMIS unit 10-8 to display the callout timing parameters menu dialog screen of FIG. 8u. Although not shown in FIG. 7d, this sequence would be represented similar to block 776 and 782. A user via the screen of FIG. 8u can fine tune several callout parameters to satisfy the host system modem performance requirements. More specifically, the user can fine tune the following parameters: a try condition parameter specifying the number of retries when conditioning the modem, a retry for each number parameter specifying the number of retries to be attempted for each TAC phone number, a delay between busy retries parameter specifying the delay between attempts for retrying a TAC phone number, a modem intercommand delay parameter specifying the delay between items of data sent to TAC 12, and a remote time-out parameter specifying the time-out period for waiting for data from TAC 12. Upon completing the entering of the parameters, the user executes the dialog which causes GMIS unit 10-8 to execute the procedure for adding the callout tuning parameters to config file 10-216 similar to the manner described above.
As indicated in FIG. 7d, the user next performs the "perform callout management sequence" of block 830. As indicated in FIG. 7d, this sequence would be performed in the case where the host system modem is the same as the preconfigured modem as indicated by block 780. Again, the user would backup to the configure callout (local modem) menu by following the path indicated in FIG. 6. The user, by selecting the "callout management" menu item on the menu screen of FIG. 8e, causes GMIS unit 10-8
to present the menu screen of FIG. 8p. As seen from FIG. 8p, the user is able to configure different callout manager operating parameters as required for controlling the manner in which the callout manager processes incoming callout requests received from the host system and any cluster clients. This is done by blocks 832 through 839.
As indicated when the user selects the "change/show callout manager status" item on the menu screen of FIG. 8p, this causes GMIS unit 10-8 to display the dialog screen of FIG. 8q. The user can enter the amount of time that the callout manager module 10-204 of FIG. 3 will delay between consecutive callout requests. Additionally, the user can configure the maximum number of callout message requests that callout manager module 10-204 will queue at one time. After entering the values in the fields of FIG. 8q, the user executes the dialog to cause GMIS unit 10-8 execute the procedure for storing the configured values. This causes GMIS unit 10-8 to generate a chcall command containing a command line including the selected callout manager values and command parameters. These parameters are passed to the chcall module 10-210e of FIG. 4b which using the call control file access routines of block 10-210c, stores the user selected callout manager parameters in callctrl file 10-210g.
Also, the user may also want to establish when calld daemon 10-210b of FIG. 4b is to be started. As indicated by block 837, this is done by selecting the "start callout manager daemon" menu item on the menu screen of FIG. 8p. This causes GMIS unit 10-8 to generate the dialog menu screen of FIG. 8r. As shown, the user can choose to start daemon 10-210b now, at reboot time or now and at reboot time. Upon completing the selections, the user executes the dialog to cause GMIS unit 10-8 to carry out the procedure of storing the daemon configuration values. This causes GMIS unit 10-8 to generate a chcall command containing a command line which includes the user configuration and command parameters. These parameters are passed to the chcall module 10-210e which starts the calld daemon and/or uses conventional system commands to configure boot time behavior. As shown in FIG. 7d, this ends the illustrated "callout management" sequence.
It will be appreciated that the user could make other changes or view the status of the callout manager module 10-204 by selecting other parameter items on the menu screen of FIG. 8p. For example, the "List Queued Callouts" shows all of the callout requests stored in the callout manager queue. The "Show a Queued Callout" item allows an item from the queue to be shown including the callout contents when a queue index value is supplied. The "Remove Queue Callout" item allows a callout request to be removed from the queue. The "Show Callout Manager Status" item allows the current callout manager configuration and status to be displayed. The "