US20090106353A1 - Method and system for providing an event auditing client server software arrangement - Google Patents

Method and system for providing an event auditing client server software arrangement Download PDF

Info

Publication number
US20090106353A1
US20090106353A1 US12018017 US1801708A US2009106353A1 US 20090106353 A1 US20090106353 A1 US 20090106353A1 US 12018017 US12018017 US 12018017 US 1801708 A US1801708 A US 1801708A US 2009106353 A1 US2009106353 A1 US 2009106353A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
data
rule
parameters
source
action
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US12018017
Inventor
Steven G. Belovich
Original Assignee
Belovich Steven G
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to network resources
    • H04L63/101Access control lists [ACL]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32High level architectural aspects of 7-layer open systems interconnection [OSI] type protocol stacks
    • H04L69/322Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer, i.e. layer seven

Abstract

A computer system, includes a first input configured for data communication with a network of computers; a computer-readable medium storing processor executable instructions corresponding to a plurality of rules where the plurality of rules control the functionality of the system; a first processor configured to receive external events from the network via the first input and configured to receive rule events from the processor executable instructions; and logic configured to audit the received external events and rule events, where the audit comprises recording event initiation data and selectively approving event action where the processor processes an event only in response to the logic approving event action.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • [0001]
    This application claims priority to U.S. application Ser. No. 10/247,731, now U.S. Pat. No. 7,322,028, filed Sep. 19, 2002, which claims the benefit of U.S. Provisional Application No. 60/323,575 filed Sep. 19, 2001.
  • FIELD
  • [0002]
    This application relates in general to software systems, and in particular to an architecture configured to provide an event auditing client server software arrangement.
  • BACKGROUND
  • [0003]
    Recently, a large variety of new computer-based business and manufacturing automation systems have been introduced. New hardware products are coming out at an incredible rate, while new software products are being introduced even more quickly. Although the data analysis, information management and control capabilities brought by these new products have certainly been of great benefit, the products, when installed and configured, seldom meet expectations at anywhere near the projected costs.
  • [0004]
    One significant problem is constant, never-ending software development. Although the capabilities and features of software packages have increased greatly in the last ten (10) years, the need for programmers and programming services has grown even more rapidly. This is true across various types of software including general packages and those directed towards business and manufacturing automation. The successful system integration of common software packages invariably demands that a great deal of custom code be designed, written and debugged, which is a costly and error-prone activity.
  • [0005]
    Another emerging and largely unanticipated problem is cyber attacks and other malicious software. Nearly all software systems were designed assuming a benign operating environment in which program operation would proceed without interference. Unfortunately, this assumption is violated nearly every day, especially since 9/11/2001. Cyber attacks are increasing in frequency and in severity and vast majority existing software systems are unable to operate properly under such conditions.
  • [0006]
    “Stop-gap” measures such as firewalls and anti-virus software have been employed to provide some degree of protection. However, none of these techniques and technologies can provide 100% protection. Firewalls have been successfully breached by teenagers and anti-virus software only works for known virus instances. Software skill sets have migrated across the globe with the natural consequence of a dramatic rise in the sophistication of malicious software used in cyber attacks. This situation is expected to worsen as the software tools and technologies available to the attackers rivals those available to the defenders.
  • [0007]
    Systems integration firms and end users are devoting an ever-increasing fraction of their budgets to cyber defense, software design, programming and verification. Pedestrian software activities such as configuring a firewall, creating custom menus, formatting dialog boxes, creating custom displays and the like can usually be done via traditional “point-and-click” or by at most editing a script file. Unfortunately, this traditional level of flexibility is woefully inadequate to meet end users' changing needs in a timely and cost-effective manner.
  • [0008]
    More sophisticated software efforts, such as implementing a new business rule, conforming to new data analysis & reporting regulations, increasing system security, executing a custom menu option, and the like invariably requires significant custom code development in a computer language such as Visual Basic, Visual C or Java. Additionally, to obtain the desired level of end-user functionality, still more custom code must be designed, written and debugged. Further, if the original application was not architected well, it may not even be possible to add this new functionality without extensively rewriting it. The cost of these software design and programming efforts is significant and is considerably greater than the cost of the original out-of-the-box software package. FIG. 1 illustrates a typical cost breakdown of implementing a business or manufacturing automation software project.
  • [0009]
    Nearly all companies maintain Information Technology (IT) departments to handle software installations, upgrades, and custom code development. Significant fractions of companies' operating budgets are allocated to IT departments for these tasks. Companies who are not even in the software business must still make large financial and personnel investments in Information Technology. Thus, both human and capital resources are inefficiently expended on tasks far outside the companies' area of core competency and industry. Cyber defense and software security efforts exacerbate this situation and are beginning to consume a significant fraction of both corporate and government resources.
  • [0010]
    New operating systems and platform products are introduced into the market at a phenomenal rate. This rapid change often requires application software to be redesigned just to continue to operate with the new computer platform, operating system and/or other application. Thus, many companies' software development efforts and expenses are now driven by external market forces that are completely unrelated to their core business or market. Unfortunately, money spent on this type of software development may not even directly improve productivity, product quality or increase sales. It may even negatively impact profitability and cash flow. The same is true for cyber defense and software security efforts. These activities negatively impact cash flow because they are required for successful business operation yet they do not have direct business benefit in terms of sales, product quality improvement or cost reduction.
  • [0011]
    A new method and apparatus is thus needed which overcomes the above-mentioned problems and others.
  • SUMMARY
  • [0012]
    In accordance with an aspect of this description, a single software application may provide desired functionality to users in a client-server architecture irrespective of the operating system (O/S) operating any computer so architected.
  • [0013]
    In accordance with another aspect of this description, at least one computer in a client-server architecture may be secure. The server platform and operating system can be configured to implement the “Reference Monitor” software security architecture that is well-known in the art to provide a “Trusted Computing Base” (TCB). The reference monitor may enforce a predetermined (and adjustable) system security policy by controlling the access of every subject or user to every object or rule in the software system. The reference monitor may maintain an access control list (ACL) which determines which subjects or users have access to which objects or rules and the manner of allowed access. Subjects can also be active entities, user processes, etc. while objects can be files, directories, passive data repositories, etc. The reference monitor also may maintain a tamper proof audit trail so that security-related events can be tracked and reported. At least one computer may use this TCB as a platform to help ensure its security.
  • [0014]
    In accordance with another aspect of this description, the software configuration process corresponds to a software development process that eliminates or significantly reduces the amount of coding required to create a new application or to modify an existing application. The software configuration process may build upon so-called “planar code” permitting introduction of new or revised rules in the process at run-time without need to reference prior code sections.
  • [0015]
    In accordance with another aspect of this description, the software system may be architected so that it standardizes on multi-vendor-controlled interfaces between major elements—rather than standardizing on vendor-specific, client operating systems, Application Programmer Interfaces (APIs) and other rapidly changing items. Multi-vendor-controlled interfaces are those interfaces that cannot be changed by one software vendor alone. Rather, an interface change requires the express consent of multiple and competing software vendors in the marketplace. Examples of multi-vendor-controlled interfaces/standards are SQL for database access and TCP/IP for network communication. Examples of single-vendor-controlled interfaces/standards are OLE for Object Linking and Embedding for inter-application data object sharing, and NetBUI and NetDDE for network communication, all of which are strictly controlled by Microsoft. Further, these single-vendor-controlled interfaces/standards only apply to Microsoft operating systems and Wintel platforms. Experience has shown that multi-vendor-controlled interfaces/standards have a much longer lifetime than any other type of software “standard” and that they are much more universal in their usage. Standardizing on these types of interfaces—and avoiding the ephemeral, single-vendor-controlled interfaces, is an aspect of the invention to help assure that systems constructed in accord with the teachings herein will have a long operational lifetime.
  • [0016]
    In accordance with another aspect of this description, the single application that provides the functionality to the end user may be immune to desktop computer viruses or resistant. Authentication logic may be configured to ensure that virus script files, malicious desktop executable images, time bombs and the like cannot authenticate execute on the server or interfere with the proper operation of the single application in any way.
  • [0017]
    In accordance with another aspect of this description, a method is provided whereby the precise functionality implemented by the single application can be altered or enhanced in real time and delivered to the client machines irrespective of the client machine's O/S.
  • [0018]
    In accordance with another aspect of this description, the software system can often provide the user-specific functionality without writing new code. The software system may be configured to provide functionality, as determined by rules. Note that this transformation process is one of functionality only. The software system's code itself need not change. The configuration process is flexible enough to change the functionality provided by this single application, including displays, menu options, database tables and structures, data analysis processes, operating rules, reports, graphic objects, and the like. In short, the system can provide nearly any data acquisition, analysis, presentation and archiving functionality by the configuration process.
  • [0019]
    In accordance with another aspect of this description, the rule based flexibility of the system enables functional behavior that may be configured as an industry-specific software products. The system, when configured with rules “A” may function as industry-specific software product “A”. The same system, when combined with rules “B,” may function as industry-specific software product “B”. In this manner, the system may be configured to service varied industries meeting specific functional requirements.
  • [0020]
    In accordance with another aspect of this description, the ability of the system to selectively become any of a variety of industry-specific software products may significantly reduce the amount of software development effort and support for this set of software products. Traditionally, one software engineering team and one technical support team would be required for each software product a company makes. A total of “N” software products would require “N” software engineering teams and “N” technical support teams. The system may reduce support needs to only one software engineering team and technical support team since there can be only one application. Systems configured under the teachings herein may enjoy an N-to-1 reduction in the amount of staff and expense needed for software development and technical support.
  • [0021]
    In accordance with another aspect of this description, a computer may communicate via at least one network and may provide functionality with client computers of any kind, including desktop platforms (PCs), Personal Digital Assistants (PDAs), midrange machines, and the like.
  • [0022]
    In accordance with another aspect of this description, a system may provide desired functionality to users regardless of the computing environments (e.g. Linux, Windows, Palm and the like), the connection mode to the server (e.g. networked, serial, wireless and the like), and the mix of various client operating systems. The system may provide functionality in part by an enabling architecture which is independent of quickly changing code (client or operating systems) and their associated application program interfaces.
  • [0023]
    In accordance with another aspect of this description, a system may quickly adapt to new client machine technologies, operating systems, and hardware devices. The system may not require re-design to do this. During a communication process with a client, a translation may convert the communicated items to/from a form that the client machine can understand. This translation may be done dynamically, on-the-fly during any communication with the client. When a new client machine is introduced, the system may only require a translation module or rule set that may convert communicated items to/from a form that the new client understands. This translation need not impact either the operation or the functionality of the single application in any way. Thus, the system may be designed in a client-independent fashion and may not need client-specific items in its architecture. This feature may preserve the substantial investment in software purchase and configuration effort because the system (performing industry-specific functions for an end user) may take nearly immediate advantage of new technology without undue expense and without significant interruption in service. This feature may also provide a significant improvement in the state-of-the-art, which requires that an existing application be redesigned/reworked to work with a new client operating system and/or platform.
  • [0024]
    In accordance with another aspect of this description, the system can be configured to provide client-specific functionality which can be implemented and maintained by a single support team.
  • [0025]
    In accordance with another aspect of this description, the single executable application can be configured to act as a standalone software product, or tailored to any desired industry vertical market (e.g., metal forming, pharmaceutical production, chemical process, etc.). The ease of the configuration process and the lack of any code development may make it economically feasible to create entire families of industry-specific and market-specific software products without a corresponding increase in development time, or costly development staff. These new products may employ the same system, differing only in the configuration information or rules.
  • [0026]
    In accordance with another aspect of this description, a method and system are provided that may provide protection from intentional or unintentional client machine flaws, O/S flaws, errors or omissions, desktop viruses, and other malicious software attacks. This protection may be provided by architecturally segregating, critical functional areas of the application and moving them to protected areas and auditing rules for authorization.
  • [0027]
    In accordance with another aspect of this description, a method and system are provided that may allow the system to be reconfigured to alter its functionality while it is running and without interrupting its current operation. Further, the altered functionality may be available to all client machines without the need for installing additional software, rebooting or reworking in any way.
  • [0028]
    Other aspects will occur to those skilled in the art upon reading and understanding the following detailed description.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0029]
    The teachings here may take physical form in various parts and arrangements of parts, and in various steps and arrangements of steps. The drawings are only for purposes of illustrating exemplary embodiments including the presently preferred embodiment and are not to be construed as limiting the invention. In the accompanying drawings which are incorporated in and constitute a part of the specification, embodiments of the invention are illustrated, which, together with a general description given above, and the detailed description given below, serve to describe the example embodiments of the system and method. It will be appreciated that the illustrated boundaries of elements (e.g. boxes or groups of boxes) in the figures represent one example of the boundaries. One of ordinary skill in the art will appreciate that one element may be designed as multiple elements or that multiple elements may be designed as one element. An element shown as an internal component of another element may be implemented as an external component and vice versa.
  • [0030]
    FIG. 1 is a graphical image representative of costs to implement a business or manufacturing automation software project, according to the prior art;
  • [0031]
    FIGS. 2A, 2B and 2C are architecture diagrams comparing an example of the high-level system architecture described herein with that of an exemplary system architecture contained within the prior art;
  • [0032]
    FIG. 3 is an example functional block diagram of software architecture;
  • [0033]
    FIG. 4 is a graph representative of increasing levels of abstraction of the computing environment;
  • [0034]
    FIG. 5 is an exemplary network diagram;
  • [0035]
    FIG. 6 is another exemplary network diagram;
  • [0036]
    FIG. 7 is yet another exemplary network diagram; and
  • [0037]
    FIG. 8 is still another network diagram.
  • DETAILED DESCRIPTION
  • [0038]
    “Software,” as used herein, includes but is not limited to one or more computer readable and/or executable instructions that cause a computer or other electronic device to perform functions, actions, and/or behave in a desired manner. The instructions may be embodied in various forms such as routines, algorithms, modules or programs including separate applications or code from dynamically linked libraries. Software may also be implemented in various forms such as a stand-alone program, a function call, a servlet, an applet, instructions stored in a memory, part of an operating system or other type of executable instructions. It will be appreciated by one of ordinary skill in the art that the form of software is dependent on, for example, requirements of a desired application, the environment it runs on, and/or the desires of a designer/programmer or the like.
  • [0039]
    “Logic,” as used herein, includes but is not limited to hardware, firmware, software and/or combinations of each to perform a function(s) or an action(s), and/or to cause a function or action from another logic, method, and/or system. For example, based on a desired application or needs, logic may include a software controlled microprocessor, discrete logic like an application specific integrated circuit (ASIC), a programmed logic device, a memory device containing instructions, or the like. Logic may include one or more gates, combinations of gates, or other circuit components. Logic may also be fully embodied as software. Where multiple logical logics are described, it may be possible to incorporate the multiple logical logics into one physical logic. Similarly, where a single logical logic is described, it may be possible to distribute that single logical logic between multiple physical logics.
  • [0040]
    “Virus,” as used herein includes any type of malicious software targeted toward desktops, personal computers, hand held devices and the like. This includes worms, trojans and time bombs. Viruses can take many forms including executable images and script files. “Virus Immune,” refers to the ability of a system to operate properly despite components of that system being infected or otherwise compromised by a virus. Operating properly includes both protection of data items and operations on those data items.
  • [0041]
    With reference now to FIGS. 2A and 2B, a system architecture 10 is shown in comparison to the traditional, non-secure architecture 12. Architecture can include the logical organization of software components, showing the data paths between them. Architecture may also include the distribution of software functionality across hardware components or platforms. The secure server executes a properly-configured secure O/S. The secure O/S may implement a reference monitor 14 (or similar) structure in order to be secure. The reference monitor 14 enforces a predetermined and adjustable system security policy by controlling the access of every subject to every object within the system. The reference monitor 14 maintains an access control list (ACL) which determines which subjects have access to which objects and the manner of allowed access. Subjects can be active entities, user processes, etc. while objects can be files, directories, passive data repositories, etc. The reference monitor 14 also maintains an audit trail so that security-related events can be tracked and reported.
  • [0042]
    As shown in FIG. 2A, in one embodiment, a system may allocate a portion for execution on the secure server while another portion executes on the client PC1. The client machine can be any common desktop PC with any common operating system, including Windows (all versions), Linux, OS/X (MacIntosh), and the like. Indeed, as discussed more fully below, a system is readily adaptable to operating systems yet to be introduced. The operating systems running on the client machines do not have to be secure or all using the same operating systems.
  • [0043]
    Turning now to FIG. 2C, the assignment of functionality between the TCB 16 (secure server plus secure O/S) and the various client machines 18 is shown. The portion of the system that runs on the TCB 16 performs critical application functions where tampering must not occur. The database and program operations on the database are fully protected. The client portion of the system may perform less critical application functions where tampering may occur but is not damaging to the program data nor proper program operation. Examples of these less critical application functions are data display and other user interface functions. Data display errors due to viruses or other malicious software cannot adversely affect the TCB 16 because the combination of the reference monitor's security attributes and the TCB's O/S architecture being incompatible with desktop executable images and/or script files. Since all viruses use desktop executable images and/or script files, they cannot execute on the TCB.
  • [0044]
    With reference now to FIG. 3, a system includes at least one computer platform with network management hardware A and an operating system. Such computer platforms and their operating systems are commercially available from manufacturers such as SUN, HP, Compaq, IBM and others. In one exemplary embodiment, network management hardware or server A runs a resident executable application which provides functionality to client machines in data communication with the server A. The resident executable application may include a number of VIEW 20 images corresponding to the number of users or client machines using the network. Preferably, a single DRIVER image 30 contains the interface components required to support communication with client machines and display devices. DRIVER 30 may contain interface components, whether or not they are used by a specific application. DRIVER 30 may be a sharable image that is installed once, independent of the number of simultaneous users, thus saving memory. VIEW 20 and BUILD 40 may use DRIVER 30 directly to interface with a client machine or display device, although it is more common to use GRAPHICS 50.
  • [0045]
    GRAPHICS image 50 contains the “Smart Objects” 54. These Smart Objects 54 comprise graphic images, display objects, interactive analysis objects, action icons, etc. In addition to their data presentation aspects, some Smart Objects may also contain data analysis rules and procedures. For example, one Smart Object could be an “X-bar-R Chart.” The methods and formulas for computing the various statistical measures that comprise the X-bar-R Chart are well-known in the art. These well-known formulas, rules and/or procedures would be a part of the Smart Object called “X-bar-R Chart.” Other Smart Objects could be charts, graphs, spreadsheets, tables, animated objects and the like. GRAPHICS 50 contains these various items, whether or not they are used in a specific application. GRAPHICS 50 may also be a sharable image that is installed once, independent of the number of simultaneous users. VIEW 20 and BUILD 40 use GRAPHICS 50 to display, update and interact with objects, images, and the like. GRAPHICS 50 may include a wide variety of Smart Objects including new Smart Objects, with new and powerful data presentation capabilities, data analysis rules and procedures. Various image modules, such as VIEW 20, DRIVER 30, BUILD 40, GRAPHICS 50, may be resident on server 10 or alternately distributed across the network or multiple servers.
  • [0046]
    Configuration files 60 may comprise display/screen files, some menus, dialog boxes, help files, special images, some data analysis instructions, some operational rules and the like and are usually created by the BUILD 40 configurator/editor. Alternatively, some of the configuration files may be edited with a normal text editor. This allows non-graphic, text-based devices such as cellular and mobile phones to configure/modify the system—an advantage for supporting systems remotely where, for example, high-speed connections may not be available. Alternatively, some, or all configuration information may be contained in one or more relational databases 70.
  • [0047]
    Ram-resident database(s) 80 are non-executable images that are sharable, global storage areas for various kinds of real-time data and status information. Preferably, databases 80 are external to the executable application 20 although they may physically reside on the server or be disposed elsewhere on the network.
  • [0048]
    Relational databases 70 are optional. These can be any relational database such as Oracle, DB-2, Informix, Sybase, etc. Oracle is preferred but not required. These databases may contain historical data, object action rules, some data analysis rules and may include any or all other configuration information. Data communication with any or all of the relational databases occurs through specialized interfaces 72. Input/Output (I/0) handlers/interfaces 74 are also optional and support communication with intelligent instruments, PLCs, DCSs, controllers, foreign databases and the like. These I/O handlers implement the specific communication protocol(s) used by the various external devices and can communicate via a network or a dedicated serial port. These I/O handlers generally take data in ram-resident databases 80 or in relational databases 70 and send it to the particular external device. Conversely, these I/O handlers generally receive data from the external device and place it into either ram-resident databases 80 or in relational databases 70 or both. All communication with external devices, except for user display devices and client machines, is handled by one or more input/output handlers 74 (also called input/output drivers).
  • [0049]
    In a simple configuration, a system may be composed of four executable images: VIEW 20, DRIVER 30, BUILD 40 and GRAPHICS 50. GRAPHICS 50 and DRIVER 30 can be sharable, re-entrant executable images that are used by all copies of VIEW 20 and BUILD 40. Beneficially, one copy of DRIVER 30 and GRAPHICS 50 may be installed on a given system, even if there are many simultaneous users.
  • [0050]
    The BUILD 40 image may be used to set up configuration files 60 and optionally relational databases 70 and ram-resident databases 80 so that VIEW 20 can read them and function as the customer-specific application. Although the function changes, VIEW may not change in any way. Rather, VIEW may behave differently, which is really what a new software application is all about—different behavior and/or functionality. This differs from traditional object-oriented programming techniques. In object-oriented programming, significant new functionality in a program is implemented by creating new object(s) and/or re-linking existing ones to form a new executable image. This re-linking can often mean an interruption in program operation which may not be permissible in mission-critical situations. The architecture of this system may avoid this problem because a new executable image may not be created. Significant new functionality can be added simply by changing the configuration information which may be distributed across configuration files 60, relational databases 70 and ram-resident databases 80 and/or the rules that may be separate or embodied therein.
  • [0051]
    As listed above, a system may include the GRAPHICS, DRIVER, VIEW and BUILD, various configuration files and a database. For each specific application, the same VIEW, GRAPHICS and DRIVER images may be used. In one embodiment, only the configuration files 60, the database 70 (often, but not always) and/or RAM 80 may be altered. This is in sharp contrast to other application creation methods where components, modules, routines, etc. are added/edited/deleted and relinked to create a new executable image.
  • [0052]
    GRAPHICS 50 may already contain the “Smart Objects” 54 needed. These Smart Objects 54 may comprise graphic images, display objects, interactive analysis objects, action icons, etc. In addition to the data presentation aspects, some Smart Objects may also contain data analysis rules and procedures. If a given application does not need all of the Smart Objects, they may simply not be used, even though they are still present in the software. Thus, GRAPHICS 50 may stay the same regardless of the application. Some Smart Objects 54 may be display objects that control how information is displayed or how it appears to a user. Example Smart Objects may include charts, tables, graphics, numbers, geometric shapes, equipment, images, and the like. Some Smart Objects 54 may include data analysis procedures, rules, etc. within them that may be object-specific and unique. Data analysis rules, procedures and object methods that are common to all Smart Objects need not be included in the Smart Objects 54. Rather, common object methods may be contained in the BUILD 40 module and VIEW 20 module as required. This may save considerable memory and may allow these common object methods to be changed dynamically. Smart Objects 54 are typically static, but may be configured by the BUILD 40 module during the configuration process. They may be configured to do a wide variety of things, including (but not limited to) getting data, performing mathematical analyses, graphic animation, changing in response to external conditions, etc. Each Smart Object may have its own specific set of things that it is able to do. Smart Objects may have different visual display characteristics and data handling attributes may be defined and added to Graphics 50 at any time. Such additional Smart Objects are within the scope of the present disclosure.
  • [0053]
    Similarly, DRIVER 30 may include the components needed to interface with all client machines and/or display devices. If a given application does not need all of the interface components (because, for instance, the client machines are all of the same type) then the other interface components may simply not used, even though they are still present in the software.
  • [0054]
    The VIEW utility 20 may be the one executable image that runs on the server computer (HP, Sun, Compaq, Linux, etc.). It may be the only executable image needed for a system. This executable image may be relabeled as required to look like an industry- or market-specific software product, but the actual executable image is still VIEW 20 and is not changed. As previously explained, changing the configuration information can make the VIEW 20 image behave like a completely different product.
  • [0055]
    To advantageously make one image look and act like a completely different product, the configuration information, contained in either files 60, relational databases 70 or RAM 80 or any combination, or the rules separate from or contained therein may be changed. The configuration information 60, 70, 80 may configure VIEW 20 regarding operation, including what to visual attributes to display, what database tables, fields, datatypes to save to (Data Destination) or retrieve from (Data Source), what data to analyze, how to analyze it, what menus to show, what menu options to execute, what dialog boxes to have, what help files to have, what action(s) to take as a consequence of events such as user input or data value change, what rules to implement, what external/internal procedures to run, etc. So, different configuration information 60, 70, 80 can configure VIEW 20 to act like a different software product, including defining a set of actions and events on which the actions are predicated.
  • [0056]
    Architecturally, in one embodiment VIEW 20 may consist of two parts I, II. Part I may read the configuration information 60, 70, 80 for the menus, dialog boxes, etc. and sets up the user interface accordingly. Part I may also read the display configuration files as requested by external events, internal or rule events and/or user input (that can also be thought of as an external event). Based upon the display files read by Part I, Part II may gather data, dynamically route it to the proper Smart Object(s) 54, perform some limited analyses (most analyses may be done by each Smart Object), look for desired events and take the corresponding action(s) as required.
  • [0057]
    Part II may act as a spawned process that executes at a dynamically adjustable rate. Part II may include three components: interactive display and data analysis handler 82; rule handler 84; and icon handler 86. Note that Part II may be a spawned process or may be an internal routine that can be scheduled to execute as needed. This design choice is a function of the capabilities of the particular server's operating system.
  • [0058]
    The interactive display and data analysis handler 82 may get application data from services specified by the configuration information 60, 70, 80. As further dictated by the configuration information, analysis or computations may be performed and data, results, and the like may be stored in places also specified by the configuration information.
  • [0059]
    Rule handler 84 may read rules from sources specified in configuration information 60, 70, 80 and execute these rules. These rules may be generic and may specify events, actions, data sources, data operations, data destinations, visual attributes, and data analysis for both application data and computational results. In some applications of the invention, data may be obtained from an external source corresponding to a real-world event. In other applications, writing data to a destination may cause an action to be taken. For example, a “Pressure Safety Rule” could be constructed such that if the pressure in a pipe exceeds a certain threshold, then a safety valve should be opened to release fluid and reduce the pressure. In this example, the communication handler and/or the I/O driver ensures that external pressure data is placed in either the ram database 80 or the relational database(s) 70 or both. The communication handler and/or the I/O driver also ensures that the “Pressure Safety Rule” data output (i.e., opening the safety valve) is sent to the external control device. The specific data formats, data locations, data sampling rates, etc. may be set up as part of the system configuration process using BUILD 40.
  • [0060]
    Icon handler 86 is a routine that reads a subset of simpler rules contained in the icon Smart Objects 54 in the displays. These icons and the rules they contain may be set up during the configuration process using BUILD 40. Icon handler 86 may read these rules in the icon and execute them. This may result in the icons obtaining information from the configuration information 60, 70, 80 and producing results that may be stored to other locations identifiable through the configuration information or otherwise. Icons can also receive user input directly via mouse clicks, keyboard commands, and dialog boxes. Further, icon information can also be password protected or conform to other authorization schemes. For example, audit logic may be configured to audit received external events and rule events. The audit can include recording event initiation data and selectively approving event action. Exemplary events monitored in this fashion can include thresholds, rates of change, user inputs, time, comparison results, and the like. Representative actions in response to these events include getting particular screens, altering a display, running an internal job, issuing commands to external applications, setting or changing menu options, writing an output or result to a location, performing calculations, and the like.
  • [0061]
    The BUILD configurator 40 (editor) can be used to set up the configuration data 60, 70, 80 for the VIEW utility 20. In a one embodiment, BUILD may look and feel like a graphics editor. This may make it easy and intuitive to learn. BUILD may produce the configuration data required for the particular application. This configuration information may specify which Smart Objects 54 to use, what each object's data source(s) and destination(s) are, what processing is to be done on the data and how the object's appearance is to be altered as a function of the data and subsequent processing and functionality as discussed above.
  • [0062]
    For data sources or destinations that are within a relational database 70, the tables, views, fields, data types, data processing, TCP/IP address, account and password, etc. may be set up via BUILD. SQL queries, common “where clauses”, database triggers, and such all may be set up as part of the configuration process via BUILD 40.
  • [0063]
    For RAM-resident database 80, the data sources, the pointer(s) to the data locations, the data identifiers are also typically set by BUILD 40. Also, data processing rules can be established by BUILD to provide the behavior demanded by the application. These data processing rules are normally saved in the configuration files 60 but can also be placed in the relational database 70.
  • [0064]
    “Action Icons” are one kind of Smart Object in GRAPHICS 50. These objects may associate an event with an action. Using BUILD 40, an “event” may be defined to observe, for example, a threshold value for a real-time input, a database field value, an alarm condition, or a user input (i.e., a mouse click). Then, an action is defined for whenever this event occurs. For example, the action can be to display a new report/screen, force a real-time output to a new value, write to a table/field in the database, execute another rule, or any of a variety of actions. Configuring an action icon to perform an action may be done through BUILD 40. As is the case with other configuration information, the action icon settings are normally saved in the configuration files 60 but can also be placed in the relational database 70.
  • [0065]
    In one simplified embodiment, when VIEW 20 executes (i.e., the application is running) it may loop awaiting an event. When one or more of the events occur, VIEW 20 takes the requested action(s). One possible action is to spawn an external (i.e., a foreign) job feeding data or pointers to external applications. For example, if VIEW is configured to act as an environmental monitoring software system, it may have to recalibrate environmental sensors from time to time. Since sensor re-calibration applications are normally supplied by the sensor manufacturer, an action icon might be configured to launch this app whenever a sensor re-calibration is needed. The action icon would not have to know anything specific about the operation of the sensor re-calibration app. It is now apparent that the action icon would only have to know the app identifier, initial parameters to be sent to it and the command string to launch it. This may allow the integration of pre-existing foreign and perhaps incompatible software without having to understand it or link to it at the code level. A command string may be sent to the operating system of the machine where the app to be launched resides. The operating system can interpret the command string and launch the application. This may allow use of pre-existing, specialized applications whenever required. Other variations exist for this idea for using pre-existing, external software without connecting to it at the code level. All such variations are within the scope and spirit of the disclosure.
  • [0066]
    As an example, if an anomalous condition is detected, VIEW 20 can automatically launch and communicate with a pre-existing application specifically designed to handle the anomalous condition. This powerful feature advantageously employs other software and pre-developed, pre-tested applications. This powerful feature also eliminates unnecessary code development that would traditionally be required to take advantage of external, specialized apps.
  • [0067]
    Referring to FIG. 3, a chart illustrates levels of abstraction within the computing environment. Illustrated are exemplary levels at which “compatibility” is required. At the top, physical user 92 interface compatibility is among the highest abstraction including, for example, the display screen, mouse, keyboard, speakers and the like. In other words the computing environment is compatible with the human sensory system. Toward the other side, individual applications are designed to have software, or code level 94 compatibility. This level of abstraction deals with proper paths, subroutine calls, APIs and the like. It can now be appreciated that towards the lower levels of abstraction, change often occurs relatively quickly. However, resistance to change increases as the level of abstraction increases. Additionally, at lower levels, decisions which relate to compatibility are often made by few people, perhaps a single company. On the other hand, as the level of abstraction increases, compatibility decisions become more decentralized.
  • [0068]
    An previous attempt at compatibility at the code level 94 that provides an object lesson into why compatibility at this level tends to be inconsistent with market place realities is the introduction and evolution of JAVA. The JAVA language was created by Sun Micro-systems and was intended to allow software development in one common language, without regard to the underlying operating system or computer platform. Microsoft obtained a license for the JAVA technology and began inserting proprietary extensions to the JAVA language. These proprietary language extensions later appeared in a Microsoft programming manual called “J++.” These proprietary extensions were not seen by Sun as being compatible with the JAVA language standard. The tension was that Microsoft wanted to push their proprietary language extensions so that programs written in J++ would only work on Microsoft platforms, thus defeating the entire interoperability purpose of JAVA in the first place. This tension eventually resulted in litigation with the practical upshot being that Microsoft has launched a new operating system, Windows XP, which is not JAVA-compatible. This entire language evolutionary process took less than six years. Thus, at the code level, change is quite rapid and “new” and “universal” standards may not be standards at all for very long.
  • [0069]
    Above code level is the “interface level” 98. This level tends to be multi-vendor controlled and standardized, and thus supported for relatively long periods of time. Examples of software interfaces at this level are TCP/IP, SQL, X-Windows, etc. One aspect of the invention is a software system that provides interoperability and cross-platform functionality at or above the interface level 98. Interfaces have a much longer lifetime—often ten times the lifetime—than operating system APIs and other code-level conventions. Consequently, standardizing at the interface level results in a software system with a much longer lifetime than standardizing at the code level. It is an aspect of this invention to standardize at or above the interface level.
  • [0070]
    With reference now to FIG. 4, a network is illustrated which includes a various client machines with various operating systems and network connections operably connected to the server A′. Client machine 100 is a Wintel device directly connected to the server A′, while client machine 110 is another Wintel device, perhaps with a similar but more recent operating system, connected to the server A′ through a data bus 112. Client machine 120 is a representative device using a different operating system such as UNIX connected via a parallel data cable, while personal appliance 130, such as a PDA, telephone or other device is connected via serial wireless connection. Any data connection mechanism such as RF, infrared, or hardwire connection may be substituted with no loss of functionality. Client machine 140 may be an Apple device on the network to further illustrate platform independence.
  • [0071]
    Platform independence is achieved by the client-server architecture. New desktop platforms are treated as clients. They are not used as servers, but may optionally be used as such, depending upon their capabilities. New clients may be added at any time if they are already supported by Driver 30. New client types can be accommodated simply by creating a translation module for the new client type and adding it to Driver 30. The translation modules convert the client-independent interface information used by the single application into a form understood by the new client type. For some client types, an X-Windows emulation performed by Driver 30 would suffice. Web-based clients such as browsers, for example, would use the XML/HTML capabilities of Driver 30. Any number of new client types may be added in this fashion. This architecture allows the inexpensive and non-secure client machines to be used for what they are best suited for: high-performance, interactive data presentation devices that handle user interface tasks and perform some local analysis functions.
  • [0072]
    Since the desktop, and indeed most client machines, change rapidly, using the desktop as an interactive data display/data entry device with some local analysis capability makes the most design sense. By comparison, changing the server architecture every few months to keep up with desktop changes is very costly, time consuming, error-prone and may not add any value, functionality, reliability, speed, and the like.
  • [0073]
    Data analysis is rule-based. Data analysis capabilities are built into each display symbol or Smart Object 54 in the symbol library or GRAPHICS 50. Each symbol can be set to appear as desired, perform arithmetic and mathematical computations, send results to a database, etc. Additionally, “non-visible” symbols can be used to do the same operations. For special cases, code can be written to handle analyses that do not fall into a standard category. Generally speaking, a new Smart Object 54 is created and/or additional functionality is added to existing Smart Object(s) 54 to handle such situations.
  • [0074]
    Data acquisition is done by the server A. It can also be done by external equipment such as sensors sending real-time messages to the server, in any format. Client machines which are used for human-system interaction can be used for data acquisition but are not recommended for this duty. Isolation of the data acquisition, analysis and storage features provide virus-immunity because client machines or other virus-prone devices are isolated from the server and databases. This also preserves the interrupt-driven real-time performance of the data acquisition process. Additionally, many viruses employ scripts or binary code configured to exploit WINTEL based systems. Desirably, these scripts and codes are ignored by systems not employing the WINTEL architecture.
  • [0075]
    For applications that are not time-critical, acquired data can be transferred to a relational database 70 (FIG. 2). Data can also be acquired directly from one or more existing relational databases via SQL/ODBC. Data is acquired from control equipment and instrumentation via the specific manufacturer's communication protocol and hardware interface. This varies from device to device. In any case, the acquired data is either written to a RAM-resident database 80 (for applications requiring sub-second response) or directly to a relational database 70 such as Oracle.
  • [0076]
    In one embodiment, the application typically uses non-Microsoft platform(s) for the server. These platforms usually have a real-time OS (Compaq's Tru64 UNIX, OpenVMS, HP-UX and Sun Solaris). They are also relatively immune to desktop viruses because they do not run common desktop operating systems and typically do not have the virus-prone MS-software (Outlook, Excel, Explorer, etc.). Such servers are also more secure in their fundamental design and have protection against malicious software that is simply unavailable in common consumer-type desktop platforms. The server architecture and O/S also allows rigorous and effective protection schemes to be incorporated into the application so that the software will continue to operate properly even in the presence of viruses and other malicious software.
  • [0077]
    With continued reference to FIG. 4, an MS client machine, such as 100, in a system may be affected by viruses. In this case, the infected client machine 100 will not be able to perform the display/user interaction functions because of the virus. On the other hand, database, data acquisition, data analysis functions and the like are done on the protected server 10′ and not relegated to the client machines 100, 110, 120, 130, 140. Thus, these critical functions are protected and immune from infection by viruses originating on or designed against MS products or any client.
  • [0078]
    This also keeps desktop-based viruses from hindering system operation. When a desktop is infected, it may cease to function properly (if at all) but it will not in any way affect the operation of the server or system herein disclosed. As an additional security measure, preferably, non-Microsoft operating systems are employed on the server. Such operating systems may include real-time, 64-bit, hyper-reliability, reducing the likelihood of problems such as viruses.
  • [0079]
    With reference now to FIG. 5, an example first network 200 including a plurality of client machines 210 1-210 n is connected to a server A″ residing on a second network 220 having various components such as interfaces 230, 232, 234, 236, 238. As illustrated, the second network 220 supports server A″ by providing access to remote input/output interfaces such as distributed control system 230, programmable logic controller 232, microcontrollers 234 and other intelligent instruments 236, 238.
  • [0080]
    With reference now to FIG. 6, an example single network 300 includes both plurality of client machines 310 1-310 n and interfaces 330, 332, 334, 336, connected to server A′″.
  • [0081]
    With reference now to FIG. 7, an example network 400 includes a plurality of client machines 410 1-410 n and an internal data base 420 within server A″″. Interfaces 430, 432, 434, 436 and an external data base 438 are in data communication with the network through a selected client machine 410 2.
  • [0082]
    The exemplary networks have been relatively simple to ease comprehension but much larger more complicated networks are possible. Additionally, the examples set forth herein are not mutually exclusive. Thus, combinations and sub-combinations of components of each are within the spirit of the disclosure. The application has been described with reference to several exemplary embodiments. Potential modifications and alterations will occur to others upon a reading and understanding of the specification. It is intended that the invention be construed as including all such modifications and alterations insofar as they come within the scope of the append claims or the equivalents thereof.
  • [0083]
    1.0 Rules; 1.1 Overview; 1.1.1 Introduction to Rule-Based Software
  • [0084]
    IQware™ is rule-based. That means a set of “rules'—rather than formal programming—is used to specific and control the operation of the IQware system, as delivered. This feature is fundamental to the architecture of IQware and is also one of the primary reasons for IQware's tremendous flexibility.
  • [0085]
    Traditional software applications are developed through design and programming efforts. Nearly all decisions are made at compile time and only a very restricted set of user inputs is allowed at run-time. There is almost no provision for significantly altering the behavior of the delivered system in response to significant changes in the operational environment and/or significant changes in the tasks that the system needs to correctly perform. In such cases, the existing software system must usually be discarded and a new software system must be designed, created and deployed. This is always an expensive undertaking and results in a serious loss of operational capability and continuity.
  • [0086]
    In contrast, a rule-based system is far more flexible. By design, it can be reconfigured as needed so it can adapt to radical changes in its operational environment. IQware can also adapt to significant changes in the tasks that the system is required to do. This eliminates the need for extremely expensive re-design, re-programming and re-deployment of large-scale software systems. IQware's design also ensures 100% continuity of operations—even while reconfiguration underway. This is a unique advantage of IQware and makes it suitable for all critical infrastructure applications.
  • [0087]
    1.1.2 Historical Perspective
  • [0088]
    The need for a rule-based system derived from the necessity of building sufficient flexibility into IQware systems without hard-coding process-flow logic. With the “conditional” rule execution model, operational flexibility is greatly increased. This capability, combined with a sufficiently general definition of events and actions, lets the hard-coded operational rules for the software be fully removed from the source code and performed at run-time, per the rule specifications.
  • [0089]
    Prior to 7/7/07, ICON_1 was the only “rule carrier” that communicated a rule to both BVC_COMN_ACTION and IQ View. There is one rule per ICON_1 symbol and the rules are screen-specific. This was done for historical reasons because when the software was originally designed, “rule processing” was not considered. It was added later after many of the data structures were already built. Execution-wise, BVC_COMN_ACTION handles the “automatic rules” while IQ View itself handles the “manual rules”; i.e., those rules initiated by mouse clicks.
  • [0090]
    1.1.3 General Concepts
  • [0091]
    The Rule Processor (RP) reads operational “rules” from a .BXB or .BXC file. These rules contain the parameters for the events and actions that comprise the rule. Rules are of the form “upon event(s), take action(s)”. Mathematically, rules are of the form “if f(ei) then do g(ai)” where {ei} is the set of allowed events and {ai} is the set of allowed actions. The events and action definitions are sufficiently general to handle a wide variety of “business process flow” requirements. The event-action pairs are orthogonal so that any event(s) can cause any action(s) to be taken—no limitations.
  • [0092]
    Rules govern the appearance and behavior of data display objects, user interface objects, data gathering operations, database access operations and miscellaneous I/O operations. Not all rules result in something visible occurring on the screen. Rule “classes” that are required to deliver a working system include those in the list below. Note that these categories are for “humans only.” Operationally, there may not be a need for classification:
      • 1. Object display & screen appearance
      • 2. User Interface (UIF) operation
      • 3. Database access (Oracle read/write)
      • 4. Data collection (from MADT)
      • 5. Data analysis (sophisticated calculations)
      • 6. Database schema—right now this is only a pointer to the specific tablespace. It is implemented by a unique substring that points to a data file that contains the UID/PWD for the database. This UID/PWD combination puts the user into the table space “preset” in Oracle (or other DB).
      • 7. Data archiving
      • 8. Object access security & security in general
      • 9. Audit trail and content
  • [0102]
    IQ_BILD supports the graphical setting up of rules. The IQ_BILD_RULE subroutine contains the rule setup DEBs and parameter assignments. The BVC_COMN_FILE subroutine controls the reading/writing of the rules, which (as of Jun. 8, 2007) are embedded as part of the .BXB screen file.
  • [0103]
    The Rule processor uses the “Reference Monitor” security rules where required for proper enforcement. A portion of the rule parameters contain “O/S permission” parameters, “users allowed” parameters and “access mode” parameters. The security processing is done in one place so that it is easy to test, verify and modify.
  • [0104]
    It is anticipated that a spreadsheet could be used to specify the rules so the RP will read a CSV file, which is the portable format for a spreadsheet output. It is also expected that rules may be stored in a relational database. Further, rules should also be storable in “IQ private files” (e.g., BXB or BXC files) which will be one of the end products of the IQ Build configuration process.
  • [0105]
    Additional concepts and approaches are listed below:
  • [0106]
    1. Each “intelligent object” may have its own private rules that it uses for its own operation. These rules will also be edited by IQ Build. These rules will be screen-specific and only active when that object is displayed on the screen. Other rules will be global. The specification of “local/global” is done in IQ Build.
  • [0107]
    2. Classes of objects are given below. Note that some functions may be combined and/or they already overlap. That's OK. A certain amount of redundancy in what objects can do provides alternate paths for accomplishing the final software system goals. Also, “sub-objects” may be used to handle lower-level tasks. This implies an object hierarchy. An example this (right now, a current IQware capability) is with graph symbols. These objects use sub-objects to handle graph axes, graph “paper”, graph labels and “plot pen” behavior. Such sub-objects are used for histograms, line graphs, pie charts, pareto charts, x-bar-r charts, etc. Again, this is an existing capability.
  • [0108]
    a. Data display
  • [0109]
    b. Data analysis
  • [0110]
    c. User interface
  • [0111]
    d. Object-level security
  • [0112]
    e. File processing (including file conversion to PDF, etc.)
  • [0113]
    f. Data archiving
  • [0114]
    g. Tracking and auditing
  • [0115]
    h. Data output (printing & export)
  • [0116]
    3. All classes of objects listed above must be device independent and “user I/F independent”. In other words, whatever client communication protocol is used, these objects should operate correctly and not contain any protocol-specific code.
  • [0117]
    4. Need to create list of user interface objects that we need. Starting point is the list that we have now. Also, the general principle of IQware must apply: the objects must be “very smart”, written in a device-independent manner and in vector form—NEVER pixel! A sample list of essential objects is the following:
  • [0118]
    a. Submenu item(s)
  • [0119]
    b. Table
  • [0120]
    c. Spreadsheet (superset of table)
  • [0121]
    d. Line graph
  • [0122]
    e. etc.
  • [0123]
    5. Current plan is to use Open Source stuff, e.g., WxWidgets (GTK+ etc.) for display objects.
  • [0124]
    1.1.4 Current Capabilities (prior to 5/1/07)
  • [0125]
    Here is a list of some current capabilities. This list is not sorted (yet, Oct. 29, 2006) but it will be classified later. It is also expected that this list will be added to as capabilities are discovered and/or added to the architecture.
  • [0126]
    Currently, there are two main script file types that perform operations on relational database. These files are called SD_VIEW_QUERY_<sub string>.DAT and SD_VIEW_ALTER_<sub string>.DAT. These files cause a sequence of dialog boxes to be presented. The sequence of dialog boxes allows for user input and editing. Based upon the user input, operations are performed on the relational database. Such operations include database queries, database alterations and database updates/inserts.
  • [0127]
    The rules are stored in various places and they are entered into the IQware through various mechanisms. Some of the rule storage areas, their usage and advantages are highlighted below:
  • [0128]
    1. Relational database schemes, tables and fields
  • [0129]
    The rules stored in a relational database typically provide operational parameters to data collection and analysis operations done by the IQware system. The relational database provides a flexible “mailbox” for communication between IQware and outside devices, events, user input, etc.
  • [0130]
    2. IQware symbol objects, in their respective local data areas
  • [0131]
    These are created by our IQ Build TM utility which acts similar to a graphics package. IQware symbols are supplied with parameters for database schemas, database access, arithmetic “pre-processing” operations and data display.
  • [0132]
    3. Flat ASCII files
  • [0133]
    These simple rule configuration files are used for menu definitions, submenu options, database queries, dialog boxes and similar interface object setup. These setup files allow IQware to be altered and reconfigured remotely by duly authorized and authenticated users. Even better, hand-held devices may be used to completely reconfigure IQware from any remote location. Further, any and all combinations of authentication and encryption may be used to ensure security of the remote connection. IQware works with all available technologies in this area.
  • [0134]
    4. RAM Resident Data Tables
  • [0135]
    RAM-resident data tables are used when the rules—or rule parameters—must be rapidly updated, re-read, re-processed and re-executed. This situation occurs primarily in real-time applications such as plant control, plant monitoring and safety-related situations. This feature allows IQware to be configured and used as a real-time control system interface. This is an application that traditional business intelligence software cannot handle. IQware's unique and flexible architecture enables this capability.
  • [0136]
    Here are some additional notes on current capabilities:
  • [0137]
    1 . ICON1 object can invoke rule script files.
  • [0138]
    2. Script files cause a sequence of DEBs to appear. These DEBs let the user to enter/edit data in various fields. This data entry is fully flexible here in terms of datatypes & formats.
  • [0139]
    3. The “data fields” within the script files correspond to fields within a data table and within a database schema.
  • [0140]
    4. At the conclusion of the series of DEBs—after all user input has been acquired—the database is either queried and/or altered (including updates).
  • [0141]
    5. All user input occurs through ICON1 which follows security policy.
  • [0142]
    6. Negative object access results are logged to a security text file for later review. This capability should become rule-based so that it can be changed on the fly.
  • [0143]
    7. All users share ONE COPY of BVC_GRAPHICS & BVC_DRIVER. This is VERY powerful and allows a LOT of users to coexist in one small RAM space. It is also very convenient for OVMS because it lets OVMS use its own, proven, trusted memory management procedures.
  • [0144]
    8. IQ Build is not currently linked into Oracle 10g. This allows IQ Build to be used without Oracle installed—very handy. For rules that are stored in the database (if we choose to do that) this will have to change.
  • [0145]
    9. A minimum number of OVMS APIs are used. Very minimal. So, porting is straightforward. This minimal “intrusion into the O/S space” is another feature of our unique approach.
  • [0146]
    10. Right now, we control our own code. The only things needed for IQware are a compiler, OVMS and Oracle. That's it. Every “tool” or “thingy” that we introduce makes the “dependency graph” a lot worse (exponentially). This in turn places severe limits on IQ's ability to grow and improve over time. We must not embed anything if we can avoid it.
  • [0147]
    1.2 IQware's Rule Sources and Types; 1.2.1 Rule Coverage
  • [0148]
    IQware's rules come from various sources. The rules are informally categorized based upon the areas of IQware's operation(s) that they control. The categories of items that are governed by rules are the following:
  • [0149]
    1. Object/Screen display
  • [0150]
    2. User interface object rendering and control
  • [0151]
    3. Menu object rendering and control
  • [0152]
    4. Database access
  • [0153]
    5. Data acquisition
  • [0154]
    6. Data analysis
  • [0155]
    7. Report preparation, formatting and output
  • [0156]
    8. External O/S actions (e.g., run a job, execute command procedure, etc.)
  • [0157]
    1.2.2 Classes of Rule Elements
  • [0158]
    Rule elements are grouped into eleven (11) classes. Classes 2 through 11 each require a parameter list for complete specification of the parameters for the rule. The “summary” class does not require a parameter list.
  • [0159]
    1. Summary (format, ID, location, status, next)
  • [0160]
    2. Events
  • [0161]
    3. Actions
  • [0162]
    4. Data Source
  • [0163]
    5. Data Destination
  • [0164]
    6. SQL Source
  • [0165]
    7. SQL Destination
  • [0166]
    8. O/S Permissions
  • [0167]
    9. Access Modes
  • [0168]
    10. Users Allowed
  • [0169]
    11. Audit rules
  • [0170]
    1.2.3 Classes of Data Source and Data Destination Operands
  • [0171]
    As of 11/7/07, there are six classes of data source (DS) and data destination (DD) operands. These are called INTERNAL, MADT, SCRATCH PAD, EXTERNAL, ORACLE and USER. Each of these classes have at least three operand data types: INTEGER, REAL and CHARACTER. The meanings of these operand classes are listed below.
  • [0172]
    1. INTERNAL—the operand is contained within the symbol itself, which is a rule symbol or a symbol with rule capabilities. Note that any symbol with RULE capabilities has non-zero values within the symbol descriptor INFO_LIST(16,*). This is the descriptor which contains the pointers to the values and counts of the various rule parameters. See PRM section 8.5 for more details regarding rule parameters.
  • [0173]
    2. MADT—the operand is contained within the Main Data Table (MADT). The MADT is public to all IQ processes and is generally used only for things that must be shared between IQware users.
  • [0174]
    3. SCRATCH PAD—the operand is in the scratch pad, which is like the MADT in structure but is process-private. The scratch pad is declared and managed by the rule processor, IQ_RP. The scratch pad is used for items specific to each user's instantiation of IQware.
  • [0175]
    4. EXTERNAL OBJECT—the operand is contained within another symbol. Two integer identifiers are required to specify the operand. The first one points to the particular symbol and the other points to a location within one of the three symbol parameter lists {IL, RL, TL}.
  • [0176]
    5. ORACLE—the operand is in the database. In this case, the SQL substrings are concatenated and the desired data item is extracted from the database using the assembled SQL statement.
  • [0177]
    6. USER—the operand will be supplied as a text string by a user interface (UIF) device/widget. This is only relevant for Data Sources.
  • [0178]
    More operand classes may be added as deemed necessary.
  • [0179]
    1.2.4 Structures of Data Source and Data Destination Operands
  • [0180]
    As of 11/7/07, there are three “structures” of data source (DS) and data destination (DD) operands. These are called SCALARS, VECTORS and ARRAYS. The meanings of these operand types/kinds are listed below.
  • [0181]
    1. SCALAR—only ONE operand value is required/supplied. A SCALAR DS/DD operand requires three (3) integer parameters to completely specify it: a) DS/DD source, b) DS/DD Value/Pointer, c) an external array {IL/RL/CL} pointer.
  • [0182]
    2. VECTOR—a linear array of operands is required/supplied. A VECTOR DS/DD operand requires four (4) integer parameters to completely specify it: a) DS/DD source, b) DS/DD Value/Pointer, c) an external array {IL/RL/CL} pointer, d) a count/maximum number of operands. Note that either (b) or (c) represents the “starting pointer”, depending upon the operand source, specified by item (a). The rule for interpreting the count/maximum is that if the number of actual operands is LESS THAN the number requested, then the count/maximum is set to the actual number of operands retrieved. Conversely, if the number of actual operands retrieved is GREATER THAN the number requested, then the number of operands retrieved is CLAMPED at the count/maximum value.
  • [0183]
    3. ARRAY (2D)—a two-dimensional array of operands is requested/supplied. A two-dimensional ARRAY DS/DD operand requires five (5) integer parameters to completely specify it: a) DS/DD source, b) DS/DD Value/Pointer, c) an external array {IL/RL/CL} pointer, d) the number of rows in the array, e) the number of columns in the array. Note that either (b) or (c) represents the first array item, “array element(1,1)”, depending upon the operand source, specified by item (a). In processing the 2D array, columns are always incremented in the “inner loop”; i.e., they are incremented first. The “rows” are incremented last in the “outer loop.”
  • [0184]
    4. ARRAY (3D)—a three-dimensional array of operands is requested/supplied. A three-dimensional ARRAY DS/DD operand requires six (6) integer parameters to completely specify it: a) DS/DD source, b) DS/DD Value/Pointer, c) an external array {IL/RL/CL} pointer, d) the number of “rows” in the array, e) the number of “columns in the array, f) the number of “levels” in the array (the z-axis). Note that either (b) or (c) represents the first array item “array element(1,1,1)”, depending upon the operand source, specified by item (a). In processing the 3D array, “levels” are always incremented in the “inner loop”; i.e., they are incremented first. The “columns” are incremented in the “middle loop”. The “rows” are incremented last in the “outer loop.”
  • [0185]
    5. Higher Dimension Arrays—unsupported as of 11/7/07.
  • [0186]
    The ARRAY operand definition is expected to be generalized for higher-dimension arrays after 11/7/07.
  • [0187]
    1.3 Event Definitions; 1.3.1 Detailed Event Descriptions
  • [0188]
    The allowed set of events and actions provide the raw capabilities for any IQware system. This list is subject to changes and it is expected that additional events and actions will be added as development continues. Also contained in this list are the items required to fully specify each event and each action.
  • [0189]
    Event List & Description
  • [0190]
    1. Mouse click on object. This event occurs when the left (or only) mouse button is pressed over the specified RULE object. The RULE object's geometry determines the region of interest for the mouse click.
  • [0191]
    2. Key press. This event occurs when the “keypress input” matches the desired key sequence, if specified. The ke sequence may be an ASCII byte stream or an XLIB “key symbol code” which is 16-bits.
  • [0192]
    3. Comparison operation. This event occurs whenever <data object#1><comparison> <data object#2>=TRUE. The data objects are generic and may one of {INTERNAL, MADT, SCRATCH PAD, EXERNAL, ORACLE}. The data types may be one of {INTEGER, REAL, CHARACTER}. The datatypes may be mixed as desired because conversions are automatic. When doing character comparisons, numbers come before letters and letter are in alphabetical order. Thus, “B23”<“C23” and “1234”<“ABCD”.
  • [0193]
    4. Status of rule “i”. This event occurs when the status bits of rule “i” are set to the desired “bit mask”. As of 8/28/07, the only status bit looked at is bit #2 which signifies “action completed”. The rule status bits are defined in the event parameter table below.
  • [0194]
    5. Periodically. The event occurs when a “periodic timer” expires. This event causes the specified action to occur on a regular basis at preset intervals.
  • [0195]
    6. Mouse click in window. This event occurs when the left (or only) mouse button is pressed anywhere within the work window.
  • [0196]
    7. On Load event. This event occurs when a screen is initially loaded. This condition is sensed by the IQ_RP.FOR internal counter ACTION_LOOP_CTR. This variable is I*8 and is incremented each time the RULE actions are processed. When a new screen is retrieved, this counter is reset to zero.
  • [0197]
    8. (future)
  • [0198]
    1.3.2 Event Triggering Options
  • [0199]
    Events can be triggered in one of three ways: always (the default), periodically (on a regular basis), or once only (upon startup of a new screen). SGB 9/3/07 TBC.
  • [0200]
    1.3.3 Event Parameters
  • [0201]
    Here are the definitions of allowed event parameters. These specifications are subject to change. The event code is an integer which specifies the event to be tested. Upon occurrence of this event, the requested action(s) will be performed. In the actual source code, the event parameters are copied to local variable for convenience.
  • [0000]
    Event Parameter Table
    EC Event Parameters Defined
    0 Undefined - not assigned. This EV(1) = EC (event code) = 0, EPC (event
    event is ignored if encountered. parameter count) = 1
    1 Mouse click. Event occurs when EV(1) = 1, EPC = 2
    the mouse button is pressed EV(2) = Trigger Mode (Always, Only After
    within the X-Y coordinate Reset, Oncer per New Screen)
    boundaries of the rule. Later
    (after Aug. 5, 2007) this can be altered
    by specifying the “coordinates of
    interest” as well.
    2 Key press. Event occurs when EV(1) = 2, EPC = 6, 7, 8 depending upon the
    the selected key sequence is number of ASCII characters to be looked for
    entered by the user. EV(2) = Trigger Mode (Always, Only After
    Reset, Oncer per New Screen)
    EV(3) = 0 means look for ASCII sequence
    EV(3) = 1 means look for 16-bit OSF Keysym
    EV(4) = OSF Keysym
    EV(5) = ASCII character count
    EV(6) = ASCII code of 1st character
    EV(7) = ASCII code of 2nd character
    EV(8) = ASCII code of 3rd character
    3 Data comparison. The event EV(1) = 3, EPC = 9
    occurs when <data object #1> EV(2) = Trigger Mode (Always, Only After
    <comparison> <data object #2> = Reset, Once per New Screen)
    TRUE. The data objects are EV(3) = Data source of 1st operand. This is
    specified in the same manner as interpreted the same way that the Data
    the Data Source & Data Source parameters are interpreted. Note that
    Destination parameters. The the supported values are 1-12. These codes
    allowed comparison operations stand for “INTERNAL (I/R/C values 1-3)”,
    are arithmetic and lexicographic. “MADT (I/R/C values 4-6)”, “SCRATCH PAD
    (I/R/C values 7-9)” and “OTHER SYMBOL
    (I/R/C values 10-12)”, respectively. No
    database values are supported as of Aug. 3, 2007.
    EV(4) = Data source of 2nd operand.
    Interpreted in the same way as for EV(2).
    EV(5) = Comparison code. The meaning of the
    comparison code is as follows:
    1 means “<” (less than)
    2 means “<=” (less than or equal to)
    3 means “=” (equal to)
    4 means “>=” (greater than or equal to)
    5 means “>” (greater than)
    6 means “<>” (not equal to)
    EV(6) takes on different meanings based
    upon EV(3) the data source operand. Here is
    the list of parameter values and meanings:
    If EV(3) = {1, 2, 3} then EV(6) is the operand
    itself
    If EV(3) = {4, 5, 6} then EV(6) is the pointer to
    the MADT location containing the operand
    If EV(3) = {7, 8, 9} then EV(6) is the pointer to
    the scratch pad location containing the
    operand
    If EV(3) = {10, 11, 12} then EV(6) is the ID of
    another symbol in the screen buffer and EV(7)
    is the pointer to the operand within the IL(*)
    array of the symbol.
    EV(7) is the pointer to the operand within the
    IL(*) array of the symbol if EV(3) = {10, 11, 12}.
    EV(8) takes on different meanings based
    upon EV(4) the data source operand. Here is
    the list of parameter values and meanings:
    If EV(4) = {1, 2, 3} then EV(8) is the operand
    itself
    If EV(4) = {4, 5, 6} then EV(8) is the pointer to
    the MADT location containing the operand
    If EV(4) = {7, 8, 9} then EV(8) is the pointer to
    the scratch pad location containing the
    operand
    If EV(4) = {10, 11, 12} then EV(8) is the ID of
    another symbol in the screen buffer and EV(9)
    is the pointer to the operand within the IL(*)
    array of the symbol.
    EV(9) is the pointer to the operand within the
    IL(*) array of the symbol if EV(4) = {10, 11, 12}.
    4 Rule Status. Event occurs when EV(1) = 4, EPC = 4
    the specified rule status bit(s) EV(2) = Trigger Mode (Always, Only After
    are set. The “Rule Status” bits Reset, Oncer per New Screen)
    are listed below: EV(3) = Rule ID for rule status to be tested.
    Bit Meaning When Set EV(4) = Desired “Bit Mask” for rule status. As
    0 Event occurred (set by an example, if EV(4) = 1 then look for rule
    IQ_RP) status bit #0 to be set. If EV(4) = 2 then look
    1 Action is in progress (set by for rule status bit #1 to be set. If EV(4) = 3 then
    IQ_RP) look for rule status bits #0 & #1 to be set (a
    2 Action is completed (set by logical AND). Normally, bit #2 (ACTION
    IQ_RP or by callbacks for User COMPLETED) is the only one tested.
    Interface events)
    3 OK BUTTON (or APPLY
    BUTTON) was hit by the user.
    This only applies to UIF events!
    4 CANCEL BUTTON was hit
    by the user. This only applies to
    UIF events!
    5 Periodically. The event occurs EV(1) = 5, EPC = (4)
    at intervals specified by EV(3) in EV(2) = Trigger Mode (Always, Only After
    milliseconds. Note that EV(4) Reset, Oncer per New Screen)
    is used for temporary storage to EV(3) = “re-trigger” interval in milliseconds
    keep track of when this event EV(4) = temporary storage for the
    should be triggered. decremented down counter for this event.
    Each AST cycle, this value is decreased by
    the IQ_RP_AST “sleep time” until it hits zero.
    Then the event is flagged and EV(4) is
    reloaded with the specified period stored in
    EV(3). The cycle then repeats.
    6 Mouse click. Event occurs when EV(1) = 6, EPC = 2
    the mouse button is pressed EV(2) = Trigger Mode (Always, Only After
    within the work window. Reset, Oncer per New Screen)
    7 On Load event. Event occurs EV(1) = 7, EPC = 2
    when a screen is initially loaded. EV(2) = Trigger Mode (1 = Always, 2 = Once per
    This is sensed by the New Screen)
    IQ_RP.FOR internal counter
    ACTION_LOOP_CTR. This
    variable is I*8 and is
    incremented each time the
    RULE actions are processed.
    When a new screen is retrieved,
    this counter is reset to zero.
    8 String Comparison Operations. EV(1) = 8, EPC = 15
    Two sets of strings are EV(2) = Trigger Mode (Always, Only After
    compared. The event occurs if Reset, Once per New Screen)
    the comparison is “TRUE.” As EV(3) = String comparison operation code.
    of Nov. 19, 2007, only a scalar-to- Supported codes are the following:
    vector string comparison is 0 = No operation
    supported. The supported string 1 = Exact Match. Strings must match exactly
    comparison operations are listed for length and contents.
    below: 2 = Case Blind comparison
    “Exact Match.” The event 3 = Wildcard match. The wildcards are {*, %}.
    occurs if the first operand string The {*} equates to one or more characters.
    exactly matches the second EV(4-9) = Data source of 1st operand.
    operand string for both contents EV(10-15) = Data source of 2nd operand
    and length. Event Operand Specification
    “Case Blind Compare.” The SCALAR operands use three (3) integer
    event occurs if the first operand parameters to completely specify it: a) DS/DD
    string matches the second source, b) DS/DD Value/Pointer, c) an
    operand string - case- external array {IL/RL/CL} pointer.
    insensitive. VECTOR operands use four (4) integer
    “Match Wild.” The event occurs parameters to completely specify it: a) DS/DD
    if the first operand string (with source, b) DS/DD Value/Pointer, c) an
    {%, *} wildcards) matches the external array {IL/RL/CL} pointer, d) a
    second operand string. The {*} count/maximum number of operands. Note
    wildcard equates to zero or that either (b) or (c) represents the “starting
    more characters. The {%} pointer”, depending upon the operand source,
    wildcard equates to exactly one specified by item (a). The rule for interpreting
    character. the count/maximum is that if the number of
    (future?) actual operands is LESS THAN the number
    “Find First In Set”. The event requested, then the count/maximum is set to
    occurs if any one (or more) of the actual number of operands retrieved.
    the characters in first operand Conversely, if the number of actual operands
    appear in the set of characters retrieved is GREATER THAN the number
    described by the second requested, then the number of operands
    operand. retrieved is CLAMPED at the count/maximum
    “Find First Not In Set”. The value.
    event occurs if any one (or ARRAY (2D) operands use five (5) integer
    more) of the characters in first parameters to completely specify it: a) DS/DD
    operand do NOT appear in the source, b) DS/DD Value/Pointer, c) an
    set of characters described by external array {IL/RL/CL} pointer, d) the
    the second operand. number of rows in the array, e) the number of
    columns in the array. Note that either (b) or
    (c) represents the first array item, “array
    element(1, 1)”, depending upon the operand
    source, specified by item (a). In processing
    the 2D array, columns are always
    incremented in the “inner loop”; i.e., they are
    incremented first. The “rows” are incremented
    last in the “outer loop”.
    ARRAY (3D) operands use six (6) integer
    parameters to completely specify it: a) DS/DD
    source, b) DS/DD Value/Pointer, c) an
    external array {IL/RL/CL} pointer, d) the
    number of “rows” in the array, e) the number
    of “columns in the array, f) the number of
    “levels” in the array (the z-axis). Note that
    either (b) or (c) represents the first array item
    “array element(1, 1, 1)”, depending upon the
    operand source, specified by item (a). In
    processing the 3D array, “levels” are always
    incremented in the “inner loop”; i.e., they are
    incremented first. The “columns” are
    incremented in the “middle loop”. The “rows”
    are incremented last in the “outer loop”.
    9 Future
  • [0202]
    1.4 Action Definitions; 1.4.1 Detailed Action Descriptions
  • [0203]
    The allowed set of events and actions provide the raw capabilities for any IQware system. This list is subject to changes and it is expected that additional events and actions will be added as development continues.
  • [0204]
    The allowed actions are described in the numbered list below. Note that most actions will have data source and data destination specifiers. These specifiers will determine where data is obtained and where it is put when the action is completed.
  • [0205]
    Action List & Description
  • [0206]
    1. Get A Screen. The screen specified by the data source parameters will be retrieved. This screen retrieval process will “load up” the rule structure with the rules for that screen. The scratch pad area will be cleared out so that “stale data” does not contaminate the new screen, which may use the SP for its operation.
  • [0207]
    2. Data Transfer. The “operand” specified by the data source (DS) parameters is transferred to the location specified by the data destination (DD) parameters.
  • [0208]
    3. Use Scrolled Text. The title string will appear on the top of the scrolled text box. The DS will appear within the scrollable window and will be editable. Once edited by the user, the text will be written to the destination specified by the DD parameters.
  • [0209]
    4. Use File Selection Box. The “pattern string”, directory and selection label are all user-settable per the IQware standard data source (DS) parameters. The pattern string is the “mask” for selecting a group of files, *.FOR or *ABC*.DAT. The directory may be physical of a logical pointer, e.g., IQ$MTM:. The selection label is simply a string that describes what is being selected.
  • [0210]
    5. Use Prompt Dialog. A dialog box is displayed with some initial text, specified by the data source (DS) parameters. The user can edit this text string and then save it as specified by the data destination (DD) parameters. The DS operand is always converted to a string for editing. The edited string is always converted automatically to the DD data type {I,R,C}.
  • [0211]
    6. Use Information Dialog. An “information” dialog box is displayed with some message text, specified by the data source (DS) parameters. This string is non-editable and there is no data destination for it.
  • [0212]
    7. Use Selection Dialog. A list of items is displayed in a scrollable selection dialog widget. The data source (DS) parameters specify the list of items, along with action parameters AV(3) and AV(4). AV(3) is the item list count, or the maximum number of items allowed. AV(4) is the item list “start pointer”, for non-Oracle item lists. If the data source (DS) is oracle, then the SQLS parameters determine the list of items displayed. The selected item from the list is saved as specified by the data destination (DD) parameters. The list item is always converted automatically to the DD data type {I,R,C}.
  • [0213]
    8. Use Push Button. A Push Button is displayed that activates another rule, specified by the NEXT RULE ID field. The push button also transfers data as specified by the DS and DD parameters.
  • [0214]
    9. Use DEB. Display a generic DEB with each cell user-specified in IQ_BILD_RULE. Note that each cell can have different DS/DD parameters. The DEB is a container widget which is organized as a rectangular array of user interface widgets and possibly gadgets. Because the DEB requires a large amount of data to completely specify it, the DEB specification information is contained within a binary file. The binary file is “pointed to” by the RULE1 symbol. The widgets/gadgets supported in the DEB are listed below:
  • [0215]
    a) IQ_DEB_EMPTY_TYPE—An empty DEB cell. i.e. no discernable UI Widget is displayed.
  • [0216]
    b) IQ_DEB_SEPARATOR_TYPE—A separator cell. The value for LabelString is optional and InitStringValue is ignored.
  • [0217]
    c) IQ_DEB_TEXT_FIELD_TYPE—Single-line text field UI Widget.
  • [0218]
    d) IQ_DEB_SCROLL_TEXT_TYPE—A scrollable text field UI Widget.
  • [0219]
    e) IQ_DEB_SELECT_BOX_TYPE—A selection box UI Widget.
  • [0220]
    f) IQ_DEB_FILE_SELECT_BOX_TYPE—A file selection box UI Widget.
  • [0221]
    10. Display and activate various widget UIF objects (User Interface). These objects include:
  • [0222]
    a) XmCreateMenuBar
  • [0223]
    b) XmCreatePopupMenu
  • [0224]
    c) XmCreatePulldownMenu
  • [0225]
    d) XmCreateText.
  • [0226]
    e) XmCreateTextField
  • [0227]
    f) (Others to be added as required)
  • [0228]
    11. Display a set of menus and get user input
  • [0229]
    12. Audit an event. This causes a timestamp, user ID and other relevant information to be saved for later review and reporting.
  • [0230]
    13. Alter/set object security and access levels.
  • [0231]
    14. Grant/revoke privileges at the O/S level.
  • [0232]
    15. Spawn a process (must supply the full process context)
  • [0233]
    16. Run a job
  • [0234]
    1.4.2 Action Audit Options; SGB 9/3/07 TBC.
  • [0235]
    1.4.3 Action Parameters
  • [0236]
    Here are the definitions of allowed action parameters. These were initially taken from the “ICON1” symbol, because it is already implemented. These specifications are subject to change. The action code is an integer which specifies the action to be taken. The “Parameters Defined” column details all relevant parameters for the action, where they are stored and what to do with them. Collectively, the list of action parameters uniquely describe the action to be taken.
  • [0000]
    Action Parameter Table
    AC Action Parameters Defined
    0 Undefined/not set. If None (N/A). Note that in general, RULE_ARGLIST
    the Rule Processor (RA) holds the parameters. Note that these are
    (RP) encounters this “pointed to” by relative integer addresses. So, AP(i)
    action code, then no is the i-th action parameter for this rule. Likewise,
    action is taken. This DSP(j) is the j-th data source parameter for this rule.
    happens when an This applies to all Rule actions.
    ICON_1 or RULE_1 If the NEXT RULE ID is non-zero, then THAT rule's
    has no action “EVENT OCCURRED” flag will be set upon
    configured but is is completion of the current action. This feature lets the
    placed on the screen completion of the current rule automatically force the
    as a screen object. execution of the next rule, specified by the NEXT
    RULE ID field.
    1 Get a screen. This Action Parameters
    action replaces the AP(1) = 1, the action code
    current display with the AP(2) = Action Cleanup BWS
    screen specified in the Data Source Parameters
    icon symbol. Of There are three sets of data source parameters for
    course, the device name, directory name and filename of the
    BVC_COMN_FILE will screen file to be retrieved. Each set of three data
    populate the data source parameters are interpreted in the usual way
    structures with the new (see the Data Source Parameter section below).
    rules, actions and DSP(1, 2, 3) => specifies the screen filename.
    symbols that pertain to DSP(4, 5, 6) => specifies the directory name
    that screen. containing the screen file
    DSP(7, 8, 9) => Specifies the device name for the
    screen file
    SQL Parameters
    Assembled from substrings. See detailed description
    in SQL Statement Definitions section (Section 8.8)
    2 Data Transfer. Move Action Parameters
    data from the data AP(1) = 2, the action code
    source to the data AP(2) = Action Cleanup BWS
    destination. Data Source Parameters
    There is one of data source parameters. These DS
    parameters describe the source of the data to be
    transferred. This set of three data source parameters
    are interpreted in the usual way (see the Data Source
    Parameter section below).
    DSP(1, 2, 3) => specifies the source of the data to be
    moved.
    Data Destination Parameters
    DDP(1, 2, 3) => specifies the destination of the data to
    be transferred.
    SQL Parameters
    Assembled from substrings. See detailed description
    in SQL Statement Definitions section (Section 8.8)
    3 Use Scrolled Text Action Parameters
    AV(1) = 3 the action code
    (geometry & color are from the RULE_1 symbol
    itself)
    AV(2) = Action Cleanup BWS
    AV(3) = Number of text rows to display, initially.
    Data Source Parameters
    There are two sets of data source parameters.
    These DS parameters describe the initial editable
    prompt text string and the title, respectively. Both
    sets of data source parameters are interpreted in the
    usual way (see the Data Source Parameter section
    below).
    DSP(1, 2, 3) => specifies the editable initial prompt
    text
    DSP(4, 5, 6) => specifies the title
    Data Destination Parameters
    DDP(1, 2, 3) specifies where to store the edited
    scrolled text string.
    SQL Parameters
    Assembled from substrings. See detailed description
    in SQL Statement Definitions section (Section 8.8)
    4 Use File Selection Action Parameters
    Dialog. Display a file AP(1) = 4 the action code
    selection box with an (geometry & color are from the RULE_1 symbol
    initial text string itself)
    specified by the DS AP(2) = Action Cleanup BWS
    parameter. Let the Data Source Parameters
    user edit the string There are three sets of data source parameters.
    then put it where These DS parameters describe the initial editable
    indicated by the DD prompt text string, the dialog box title and the
    parameter. Note the selection label, respectively. Each set of three data
    string may be long, like source parameters are interpreted in the usual way
    a series of notes. The (see the Data Source Parameter section below).
    file selection is DSP(1, 2, 3) => specifies the pattern string
    controlled by the local DSP(4, 5, 6) => specifies the directory
    window manager so it DSP(7, 8, 9) => Specifies the selection label
    may be moved around Data Destination Parameters
    as required. DDP(1, 2, 3) => Specifies where to store the selected
    file name.
    SQL Parameters
    Assembled from substrings. See detailed description
    in SQL Statement Definitions section (Section 8.8)
    5 Use Prompt Dialog. Action Parameters
    Display a dialog box AP(1) = 5 the action code
    with an initial text (geometry & color are from the RULE_1 symbol
    string specified by the itself)
    DS parameter. Let the AP(2) = Action Cleanup BWS
    user edit the string Data Source Parameters
    then put it where There are three sets of data source parameters.
    indicated by the DD These DS parameters describe the initial editable
    parameter. Note the prompt text string, the dialog box title and the
    string may be long, like selection label, respectively. Each set of three data
    a series of notes. The source parameters are interpreted in the usual way
    dialog prompt is (see the Data Source Parameter section below).
    controlled by the local DSP(1, 2, 3) => specifies the editable initial prompt
    window manager so it text
    may be moved around DSP(4, 5, 6) => specifies the title
    as required. DSP(7, 8, 9) => Specifies the selection label
    Data Destination Parameters
    DDP(1, 2, 3) specifies where to store the edited
    prompt string.
    SQL Parameters
    Assembled from substrings. See detailed description
    in SQL Statement Definitions section (Section 8.8)
    6 Use Information Action Parameters
    Dialog. Display a AP(1) = 6 the action code (geometry & color are from
    dialog box with an the RULE_1 symbol itself)
    initial text string AP(2) = Action Cleanup BWS
    specified by the DS Data Source Parameters
    parameter. This text There are three sets of data source parameters.
    string is not editable. These DS parameters describe the information
    The information dialog string. This string is NOT editable. The other strings
    is controlled by the describe the dialog title and the selection label,
    local window manager respectively. Each set of three data source
    so it may be moved parameters are interpreted in the usual way (see the
    around as required. Data Source Parameter section below).
    DSP(1, 2, 3) => specifies the message/information
    text.
    DSP(4, 5, 6) => specifies the dialog title
    DSP(7, 8, 9) => Specifies the Information “symbol”
    Data Destination Parameters
    None
    SQL Parameters
    Assembled from substrings. See detailed description
    in SQL Statement Definitions section (Section 8.8)
    7 Use Selection Dialog. Action Parameters
    Display a dialog box AP(1) = 7 the action code
    with a list of items, (geometry & color are from the RULE_1 symbol
    specified by both the itself)
    DS and action AP(2) = Action Cleanup BWS
    parameters. This list Data Source Parameters
    of items is not editable. There are three sets of data source parameters. The
    The selection dialog is first set of DS parameters specify the vector of
    controlled by the local displayed items. The other strings describe the
    window manager so it dialog title and the selection label, respectively. Each
    may be moved around set of data source parameters are interpreted in the
    as required. usual way (see the Data Source Parameter section
    below).
    DSP(1, 2, 3, 4) => specifies the vector of displayed
    items
    DSP(5, 6, 7) => specifies the dialog title
    DSP(8, 9, 10) => Specifies the selection label
    Data Destination Parameters
    DDV(1, 2, 3) => specifies where the selected item is to
    be stored. Selected item must be a scalar.
    SQL Parameters
    The SQL is assembled from n substrings where n =
    SQLC. If SQLC = 0 then there is no SQL. Clearly, if
    either the data source or data destination specifies
    Oracle, then SQLC must be 1 or greater. Each SQL
    substring is “described by a RULE_ARGLIST
    element (type, value, pointer, length). Based upon
    the TYPE and POINTER fields, the SQL substrings
    are identified, located and retrieved. When all
    substrings are retrieved, they are concatenated to
    form the final SQL string.
    SQL(1) = descriptor/pointer to the first SQL substring
    SQL(2) = descriptor/pointer to the second SQL
    substring
    ***
    SQL(SQLC) = descriptor/pointer to last SQL
    substring.
    8 Use Push Button. Action Parameters
    Display a Push Button AP(1) = 8 the action code
    with a text string (geometry & color are from the RULE_1 symbol
    specified by the itself)
    second set of DS AP(2) = Action Cleanup BWS
    parameters. The first Data Source Parameters
    set of DS parameters There are three sets of data source parameters.
    is the data source that These DS parameters describe the information
    will be copied to the string. This string is NOT editable. The other strings
    data destination (DD) describe the dialog title and the selection label,
    when the button is respectively. Each set of three data source
    pressed and released. parameters are interpreted in the usual way (see the
    Data Source Parameter section below).
    DSP(1, 2, 3) => specifies the “Data Source”
    DSP(4, 5, 6) => specifies the Push Button label
    Data Destination Parameters
    DDP(1, 2, 3) => specifies the “Data Destination.”
    SQL Parameters
    Assembled from substrings. See detailed description
    in SQL Statement Definitions section (Section 8.8)
    9 Use DEB. Display a Action Parameters
    generic DEB with each AP(1) = 9 the action code
    cell user-specified in AP(2) = Action Cleanup BWS
    IQ_BILD_RULE. Note AP(3) = number of DEB rows
    that each cell can have AP(4) = number of DEB columns
    different DS/DD Data Source Parameters
    parameters. Contained within the DEB data file.
    The DEB is a container Data Destination Parameters
    widget which is Contained within the DEB data file.
    organized as a SQL Parameters
    rectangular array of Contained within the DEB data file. Assembled per
    user interface widgets the usual method.
    and possibly gadgets. The supported component widgets are listed below:
    Because the DEB Empty DEB cell (nothing displayed)
    requires a large Separator (a horizontal line)
    amount of data to Single-line Text field UI Widget (like prompt dialog)
    completely specify it, Scrollable Text field UI Widget (like scrolled text
    the DEB specification dialog)
    information is Selection Box UI Widget (requires a vector of
    contained within a operands)
    binary file. The binary File Selection Box UI Widget (requires directory and
    file is “pointed to” by filter strings)
    the RULE_1 symbol. DEB Data File Structures
    The DEB data file integer*4, parameter :: DEB_MAX_ROW = 32
    format is totally integer*4, parameter :: DEB_MAX_COL = 4
    determined by the record/deb_cell/deb_cell(deb_max_row,
    “DEB data file write deb_max_col)
    process” in integer*4 deb_sqlsp(deb_max_row, deb_max_col)
    IQ_BILD_RULE. So, if integer*4 deb_sqlsc(deb_max_row, deb_max_col)
    IQ_BILD_RULE integer*4 deb_sqldp(deb_max_row,
    changes, then the deb_max_col)
    “DEB data file read integer*4 deb_sqldc(deb_max_row, deb_max_col)
    process” contained in character*128 deb_sqlsv(8*deb_max_row)
    IQ_RP must also character*128 deb_sqldv(8*deb_max_row)
    change. integer*4 deb_dsv(deb_max_row,
    deb_max_col, 9)
    integer*4 deb_ddv(deb_max_row,
    deb_max_col, 3)
    integer*4 deb_av(deb_max_row, deb_max_col, 8)
    Special Parameter Assignment for Scrolled Text
    DEB_AV(i, j, 3) = Number of rows to display, initially
    Special Parameter Assignment for Selection Box
    DEV_DSV(1, 2, 3, 4) = Vector of displayed items
    specifier
    Special Parameter Assignment for File Selection Box
    DEV_DSV(1, 2, 3) = Filename pattern string specifier
    DEB_DSV(4, 5, 6) = Directory string specifier
    “Hard-Coded parameters
    TL(1) = DEB (full) File Specification
    TL(2) = DEB Title, which appears in the DEB's
    window frame
    10 Update & Redraw Action Parameters
    Symbol. The specified AP(1) = 10 the action code
    symbol is “updated” AP(2) = Action Cleanup BWS
    with the DS value(s) Data Source Parameters
    and repainted. The set of data source parameters is interpreted in
    the usual way (see the Data Source Parameter
    section below).
    DSP(1, 2, 3, 4) => specifies the vector of data source
    items
    Data Destination Parameters
    DDV(1, 2, 3) => specifies where the selected item is to
    be stored. The supported values are external object
    scalars/vectors.
    SQL Parameters
    The SQL is assembled from n substrings where n =
    SQLC. If SQLC = 0 then there is no SQL. Clearly, if
    either the data source or data destination specifies
    Oracle, then SQLC must be 1 or greater. Each SQL
    substring is “described by a RULE_ARGLIST
    element (type, value, pointer, length). Based upon
    the TYPE and POINTER fields, the SQL substrings
    are identified, located and retrieved. When all
    substrings are retrieved, they are concatenated to
    form the final SQL string.
    SQL(1) = descriptor/pointer to the first SQL substring
    SQL(2) = descriptor/pointer to the second SQL
    substring
    ***
    SQL(SQLC) = descriptor/pointer to last SQL
    substring.
    11 Future (11/6/07)
  • [0237]
    1.4.4 Action Cleanup options
  • [0238]
    After an action has been completed, some “cleanup” may be required. This cleanup may involved clearing out the data source(s) for a comparison operation so that it is not re-triggered. This cleanup may require setting/clearing rule status bits, etc. The table below lists the options that are available for rule action cleanup. This “action cleanup word” is a 4-byte BWS and it is stored in AV(2) the second action parameter. Thus, all actions require at least two parameters for complete specification.
  • [0000]
    Action Cleanup
    Bit
    Assignments Meaning of Bit (When Set = 1)
    0 NONE (no cleanup). Note that if the entire BWS = 0 then this also
    means NO ACTION CLEANUP.
    1 Clear out event data source #1. This is generally used for ON DATA
    COMPARISON events. “Clear out” means set the values for {I, R, C}
    datatypes to 0, 0.0, NULL respectively.
    2 Clear out event data source #2. This is generally used for ON DATA
    COMPARISON events.
    3 Clear out action data source #1.
    4 Clear out action data source #2.
    5 Clear out action data source #3.
    6 Clear out ACTION COMPLETED rule status bit for the “target” rule.
    This applies to rules that execute when another rule's status bit(s)
    are set. For such rules, EV(3) points to the “target” rule which is the
    rule whose status bits are to be tested. The action completed bit (bit
    #2 of the status word) is cleared out. Also, the other “action
    completed-related” bits of the rule status word are cleared. These
    are the OK BUTTON HIT (rule status bit #3) and the CANCEL
    BUTTON HIT (rule status bit #4).
    7 Future (11/6/07)
  • [0239]
    1.4.5 Rule Status Bits
  • [0240]
    Each rule has a 4-byte status word associated with it. This 4-byte integer tracks the status pf the rule and is used for both IQ_RP's “internal housekeeping” as well as for conditioning other events. As an example, Rule “i” can be set to trigger upon the completion of Rule “j”. The table below lists the Rule status bits and their meaning.
  • [0000]
    Rule Status
    Bit Assignments Meaning of Bit (When Set = 1)
    0 The event for Rule “i” occurred. IQ_RP “event code block” sets this
    bit. The IQ_RP “action code block” clears this bit. For UIF objects,
    this bit is cleared after the UIF object is rendered but before the
    action is completed. This bit is also cleared at the end of the IQ_RP
    Main Loop, which occurs after all actions have been processed.
    1 The action for Rule “i” is in progress. For user I/F objects this means
    that the object has been rendered and is awaiting user input. The
    callbacks for each UIF (User Interface) object clear the “in progress”
    bit. The IQ_RP “action code block” sets this bit.
    2 The action for Rule “i” has been completed. For user I/F objects this
    means that the object has been rendered, has received user input,
    the callback has been invoked and executed. The callbacks for
    each UIF (User Interface) object set this bit.
    3 The user hit the “OK” or “APPLY” buttons for a UIF object. The “OK
    callbacks” set this bit. The OK Callbacks are StoreRuleData and
    okCallbackFunc
    4 The user hit the “CANCEL” button for a UIF object. The “cancel
    callbacks” set this bit. The “cancel callbacks” are CancelCallback
    and CancelCallbackFunc.
    5 Future expansion
    6 Future expansion
  • [0241]
    1.4.6 Rule Chaining
  • [0242]
    One rule can be configured to cause the “triggering” (and hence cause the execution) of another rule. For Non-User I/F rules, this happens whenever the “Next Rule ID” field of the RULE1 symbol is nonzero. For User I/F rules, this happens whenever the “Next Rule ID” field of the RULE1 symbol is nonzero—AND—the rule's “OK Callback” was activated. If the “Cancel” callback was activated, then no rule chaining occurs. IQ_BILD_RULE allows the setting of this “Next Rule ID” field for each rule action.
  • [0243]
    1.5 Data Source & Destination Definitions; 1.5.1 Relevant Source Code Modules
  • [0244]
    The subroutine IQ_DSDD handles the data “gets” and data “puts”. It is called by IQ_RP whenever a data object is required to a) test for an event or b) take an action. It is also called by one or more widget callback routines (e.g., StoreRuleData, okCallbackFunc) that handle the processing of user input. It supports scalars, vectors, 2D-arrays and 3D-arrays (perhaps!).
  • [0245]
    1.5.2 Data Source & Destination Parameters
  • [0246]
    The number of data source & destination parameters required for a given rule depends upon the specific rule action code. Each action code is unique and may require more than one data source parameter. The data source parameter codes are listed in the table below. Note that scalars require 3 DS/DD parameters, vectors require 4 DS/DD parameters, 2D-arrays require 5 DS/DD parameters.
  • [0000]
    DS/DD Code
    DSV(1),
    DDV(1) Structure Type Class Data Source/Destination Parameter Meaning
     0 None! Very important for rules that have no Data
    Source/Data Destination defined.
     1 Scalar I Internal Internal INTEGER data source. The data is within
    the RULE symbol itself, IL(DSV/DDV(2)); i.e., it is
    pointed to by DSV/DDV(2)
     2 Scalar R Internal Internal REAL data source. The data is within the
    RULE symbol itself, RL(DSV/DDV(2)); i.e., it is
    pointed to by DSV/DDV(2)
     3 Scalar C Internal Internal CHARACTER data source. The data is
    within the RULE symbol itself, TL(DSV/DDV(2)); i.e.,
    it is pointed to by DSV/DDV(2)
     4 Scalar I MADT MADT INTEGER data source.
    MADT(DSV/DDV(2)).IVAL (global data area). The
    data is pointed to by DSV/DDV(2)
     5 Scalar R MADT MADT REAL data source.
    MADT(DSV/DDV(2)).RVAL (global data area). The
    data is pointed to by DSV/DDV(2)
     6 Scalar C MADT MADT CHARACTER data source.
    MADT(DSV/DDV(2)).CHAR (global data area). The
    data is pointed to by DSV/DDV(2)
     7 Scalar I Scratch SP (Scratch Pad) INTEGER data source.
    Pad SP(DSV/DDV(2)).IVAL (local data area). The data is
    pointed to by DSV/DDV(2)
     8 Scalar R Scratch SP (Scratch Pad) REAL data source.
    Pad SP(DSV/DDV(2)).RVAL (local data area). The data
    is pointed to by DSV/DDV(2)
     9 Scalar C Scratch SP (Scratch Pad) CHARACTER data source.
    Pad SP(DSV/DDV(2)).CHAR (local data area). The data
    is pointed to by DSV/DDV(2)
    10 Scalar I External External object INTEGER data source. DSV/DDV(2)
    points to the symbol object and IL(DSV/DDV(3)) is
    the data item.
    11 Scalar R External External object REAL data source. DSV/DDV(2)
    points to the symbol object and RL(DSV/DDV(3)) is
    the data item.
    12 Scalar C External External object CHARACTER data source.
    DSV/DDV(2) points to the symbol object and
    TL(DSV/DDV(3)) is the data item.
    13 Scalar I Oracle Oracle INTEGER data source. Assemble SQL
    parameters to from SQL string and access the data
    item in the database.
    14 Scalar R Oracle Oracle REAL data source. Assemble SQL
    parameters to from SQL string and access the data
    item in the database.
    15 Scalar C Oracle Oracle CHARACTER data source. Assemble SQL
    parameters to from SQL string and access the data
    item in the database.
    16 Scalar I User “USER” INTEGER data source. Data item is
    supplied by the user through an interface object (e.g.,
    Motif or wxWidgets) at run-time.
    17 Scalar R User “USER” REAL data source. Data item is supplied by
    the user through an interface object (e.g., Motif or
    wxWidgets) at run-time.
    18 Scalar C User “USER” CHARACTER data source. Data item is
    supplied by the user through an interface object (e.g.,
    Motif or wxWidgets) at run-time.
    19 Vector I Internal Internal INTEGER vector data source. The data is
    within the RULE symbol itself. DSV/DDV(2) is the
    starting pointer so IL(DSV/DDV(2)) is the first
    element. DSV/DDV(3) is the number of vector
    elements/maximum number of elements.
    20 Vector R Internal Internal REAL vector data source. The data is within
    the RULE symbol itself. DSV/DDV(2) is the starting
    pointer so RL(DSV/DDV(2)) is the first element.
    DSV/DDV(3) is the number of vector elements/
    maximum number of elements.
    21 Vector C Internal Internal CHARACTER vector data source. The data
    is within the RULE symbol itself. DSV/DDV(2) is the
    starting pointer so TL(DSV/DDV(2)) is the first
    element. DSV/DDV(3) is the number of vector
    elements/maximum number of elements.
    22 Vector I MADT MADT INTEGER vector data source. DSV/DDV(2) is
    the starting pointer so MADT(DSV/DDV(2)).IVAL is
    the first element. DSV/DDV(3) is the number of
    vector elements/maximum number of elements.
    23 Vector R MADT MADT REAL vector data source. DSV/DDV(2) is the
    starting pointer so MADT(DSV/DDV(2)).RVAL is the
    first element. DSV/DDV(3) is the number of vector
    elements/maximum number of elements.
    24 Vector C MADT MADT CHARACTER vector data source.
    DSV/DDV(2) is the starting pointer so
    MADT(DSV/DDV(2)).CVAL is the first element.
    DSV/DDV(3) is the number of vector elements/
    maximum number of elements.
    25 Vector I Scratch SP (Scratch Pad) INTEGER vector data source.
    Pad DSV/DDV(2) is the starting pointer so
    SP(DSV/DDV(2)).IVAL is the first element.
    DSV/DDV(3) is the number of vector elements/
    maximum number of elements.
    26 Vector R Scratch SP (Scratch Pad) REAL vector data source.
    Pad DSV/DDV(2) is the starting pointer so
    SP(DSV/DDV(2)).RVAL is the first element.
    DSV/DDV(3) is the number of vector elements/
    maximum number of elements.
    27 Vector C Scratch SP (Scratch Pad) CHARACTER vector data source.
    Pad DSV/DDV(2) is the starting pointer so
    SP(DSV/DDV(2)).CVAL is the first element.
    DSV/DDV(3) is the number of vector elements/
    maximum number of elements.
    28 Vector I External External object INTEGER vector data source.
    DSV/DDV(2) points to the symbol object and
    IL(DSV/DDV(3)) is the first data item. DSV/DDV(4) is
    the number of vector elements/maximum number of
    elements.
    29 Vector R External External object REAL vector data source.
    DSV/DDV(2) points to the symbol object and
    RL(DSV/DDV(3)) is the first data item. DSV/DDV(4)
    is the number of vector elements/maximum number
    of elements.
    30 Vector C External External object CHARACTER vector data source.
    DSV/DDV(2) points to the symbol object and
    TL(DSV/DDV(3)) is the first data item. DSV/DDV(4)
    is the number of vector elements/maximum number
    of elements.
    31 Vector I Oracle Oracle INTEGER vector data source. Assemble
    SQL string from from SQL substrings and access the
    data item in the database. DSV/DDV(2) is the
    number of vector elements/maximum number of
    elements.
    32 Vector R Oracle Oracle REAL vector data source. Assemble SQL
    parameters from SQL substrings and access the
    data item in the database. DSV/DDV(2) is the
    number of vector elements/maximum number of
    elements.
    33 Vector C Oracle Oracle CHARACTER vector data source. Assemble
    SQL parameters from the SQL substrings and
    access the data item in the database. DSV/DDV(2)
    is the number of vector elements/maximum number
    of elements.
    34 Vector I User “USER” INTEGER vector data source. Data item is
    supplied by the user through an interface object (e.g.,
    Motif or wxWidgets) at run-time. DSV/DDV(2) is the
    number of vector elements requested.
    35 Vector R User “USER” REAL vector data source. Data item is
    supplied by the user through an interface object (e.g.,
    Motif or wxWidgets) at run-time. DSV/DDV(2) is the
    number of vector elements requested.
    36 Vector C User “USER” CHARACTER vector data source. Data item
    is supplied by the user through an interface object
    (e.g., Motif or wxWidgets) at run-time. DSV/DDV(2)
    is the number of vector elements requested.
    (future)
  • [0247]
    1.6 SQL Statement Definitions; 1.6.1SQL Statement Classes
  • [0248]
    There is only one class of SQL statement: a string. IQware assembles an SQL string at run-time to support fully dynamic database access of any kind. The SQL string is assembled from substrings, which can come from a variety of data sources. These different data sources constitute a different class of substring because the substring access is done differently depending upon the specific data source.
  • [0249]
    In some cases, it may be desirable to insert a value from another data source into the SQL statement. This is accomplished by using a substring beginning with the @ character. The @ character is followed by a four-letter descriptor which determines which data class will be used. INTL refers to Intemal, MADT refers to the MADT, SCRP refers to the Scratch Pad, and EXTL refers to an External Object. The descriptor is then followed by the data type, enclosed in square brackets. [INT] refers to the integer data type, [REAL] refers to the real data type, and [CHAR] refers to the character data type. Finally, a number enclosed in square brackets determines which position in the data source will be used (equivalent to DS Value/Pointer above). EXTL requires a second number in square brackets (equivalent to DS Ext. Obj. Pointer).
  • [0000]
    TABLE 8.8.1
    Example SQL Substring “Pointers”
    Source Meaning
    @MADT[INT][1] The SQL substring is the first integer item in the
    MADT
    @SCRP[REAL][2] The SQL substring is the second real item
    in the scratch pad
    @INTL[CHAR][3] The SQL substring is the third item in this rule
    symbol's Text List
    @EXTL[CHAR][4][5] The SQL substring is the fifth item in
    the Text List of the object at location #4
    @USER The SQL substring is supplied at run-time by a
    user interface (UIF) device/widget. Only relevant
    for Data Destination SQLs.
  • [0250]
    1.6.2 SQL Statement Parameters
  • [0251]
    SQL parameters are substrings. They are identified, located and retrieved at run-time and then concatenated into one “final” SQL string. The SQL substrings are described by an entry in the RULE_ARGLIST structure. If there are “n” SQL arguments, then there are “n” corresponding entries in the RULE_ARGLIST structure.
  • [0252]
    Each SQL substring is identified and located based upon the descriptor in the RULE_ARGLIST structure. Each substring may be a literal (i.e., use the substring “as is”) or may be “pointed to” by the “pointer field” of the RULE_ARGLIST entry.
  • [0253]
    1.7 Identifier Length Limits
  • [0254]
    OVMS systems using ODS-2 limits file names and UFDs (User File Directories) to 39 characters. OVMS systems version 7.2 and later limit the sum of all characters in all subdirectories of the directory and root components to 512 characters. See the OVMS User's Manual Page 3-3 (part number M-PV5JF-TK, June 2002).
  • [0255]
    Oracle (Release 10g) limits all object names to 30 bytes. Database names are limited to 8 bytes and database links can be as long as 128 bytes. See page 2-108 of the Oracle SQL Reference, Volume 1.
  • [0256]
    1.8 Security Issues
  • [0257]
    1. OVMS security model will be used throughout. Four levels of O/S object access security are defined in OVMS: user, supervisor, executive and kernel.
  • [0258]
    2. IQ OVMS accounts must be set correctly for process privileges and quotas. This is a simple administrative function. This must be documented in the IQ Setup Manual.
  • [0259]
    3. IQ security will use OVMS security and will enforce it at the object access level, identical to our current capability. The Reference Monitor architecture will be preserved because it is proven and well-accepted. All user requests for data object access must be validated through the security model. Since all of that is handled by the ICON1 symbol now, that is easy to do. In the new architecture, a security object will be used to handle this, but that object will be “invisible” per the reference monitor architecture requirements.
  • [0260]
    4. IQ security will be dynamically alterable. It will support a variety of rule-based security policies. Each IQ object will have a security code and an access code associated with it.
  • [0261]
    1.9 Proposed Rule Specification and Data Structures; 1.9.1 Structure Summary and Description
  • [0262]
    RAM-resident rules are stored in several data structures. The structures and records that comprise a rule are listed herein. Note that these structures are flexible in that each records' format may be different. The classes of rule elements are listed below. Each class of rule elements has a “parameter list” that details the parameters' type, value, pointer to its location (if applicable) and length (in bytes). Note that the “pointer” field may be required for variable or nonstandard length fields. This happens when the “argument” (i.e., the field value) is a BLOB, an image, a long text string, etc.
  • [0263]
    1.9.2 Classes of Rule Elements
  • [0264]
    Rule elements come in nine (9) classes as of 5/31/07. These classes are listed below. Classes 2 through 8 each require a parameter list for complete specification of the parameters for the rule. The first class “summary” does not require a parameter list.
  • [0265]
    1. Summary (format, ID, location, status)
  • [0266]
    2. Events
  • [0267]
    3. Actions
  • [0268]
    4. Data Source
  • [0269]
    5. Data Destination
  • [0270]
    6. SQL Source
  • [0271]
    7. SQL Destination
  • [0272]
    8. O/S Permissions
  • [0273]
    9. Access Modes
  • [0274]
    10. Users Allowed
  • [0275]
    The details of the specific rule fields are listed below:
  • [0276]
    1. Format Code (I8)—specifier for the structure of the rule. This is used for upward compatibility with “as-yet-unknown-but-anticipated” future expansion.
  • [0277]
    2. Rule ID (I8)—an integer identifier (and pointer) to a rule.
  • [0278]
    3. Location (I8)—pointer to the location of the RULE1 symbol within the screen buffer. Note that as of 7/17/07, RULE1 is the symbol that “carries”the rule. The RULE data structure is a companion to the RULE1 symbol.
  • [0279]
    4. Status flags (I8)—bits that represent the status of the event or action. Examples are event has occurred, action complete, etc.
  • [0280]
    5. Event Parameter Pointer (I8)—Pointer to the list of event parameters. The event parameters describe the event(s) whose boolean combination of occurrences trigger the rule. The event list also describes the boolean combo of the events that the rule processor will use in deciding whether or not to execute the rule.
  • [0281]
    6. Event Parameter List (I8/R8)—a list of parameters needed for description of event(s). These may include conditions, thresholds, comparison types, etc. Enough information for the rule processors to issue a Yes/No output for the event occurrence.
  • [0282]
    7. Action Parameter Pointer (I8)—Pointer to the list of action parameters. The action parameters describe the action(s) executed when the rule is triggered.
  • [0283]
    8. Action Parameter List (I8/R8)—a list of parameters needed for execution of the action(s). These may include object display parameters and object operation parameters, much like BVC_GRAPHICS arguments are handled currently.
  • [0284]
    9. Data Source Pointer (I8)—Pointer to the list of data source parameters
  • [0285]
    10. Data Source Parameter List (I8/R8/BC)—a list of parameters describing the data source and data source type
  • [0286]
    11. Data Destination Pointer (I8)—Pointer to the list of data destination parameters
  • [0287]
    12. Data Destination Parameter List (I8/R8/B/C)—a list of parameters describing the data destination and data destination type
  • [0288]
    13. SQL Source Statement Pointer (I8)—Pointer to the list of SQL statement parameters.
  • [0289]
    14. SQL Source Statement Parameter List (I8/R8/B/C)—a list of parameters required for the SQL statement assembly. These may include ASCII strings, numbers and pointers to MADT or other data areas (like previous query results, etc.). This list also includes instructions for the assembly of the SQL statement.
  • [0290]
    15. SQL Destination Statement Pointer (I8)—Pointer to the list of SQL statement parameters.
  • [0291]
    16. SQL Destination Statement Parameter List (I8/R8/B/C)—a list of parameters required for the SQL statement assembly. These may include ASCII strings, numbers and pointers to MADT or other data areas (like previous query results, etc.). This list also includes instructions for the assembly of the SQL statement.
  • [0292]
    17. OS permissions Pointer (I8)—pointer to the list of OVMS permissions
  • [0293]
    18. OS Permissions List (I8/C/B)—a list of OVMS ACL specifier(s) for S,O,G,W; i.e., System, Owner, Group, World
  • [0294]
    19. Access Mode Pointer (I8)—Pointer to the list of access mode parameters
  • [0295]
    20. Access Mode Parameter List (I8/B/C)—a list of OVMS specifier(s) for R,W,E,D; i.e., Read Write Execute Delete
  • [0296]
    21. Users Allowed Pointer (I8)—Pointer to the list of allowed users parameters.
  • [0297]
    22. Users Allowed Parameter List (B/C)—an ACL of allowed users to access/execute the rule.
  • [0298]
    1.9.3 Rule Argument List Datatypes
  • [0299]
    The rule parameters (of any type) are stored within the RULE_ARGLIST structure. This data structure has four fields: TYPE, VALUE, POINTER, LENGTH. The “TYPE” field describes the data type of the rule specific rule parameter.
  • [0300]
    The type field is a BWS (binary-weighted-sum) with a specific meaning assigned to each bit. The bits dictate the data type. This gives maximum flexibility so that all items that are not mutually exclusive may be used in any Boolean combination.
  • [0301]
    These TYPE codes apply to all RA(*) parameters except data source (DS) and data destination (DD) parameters. The DS and DD parameters themselves dictate the location of data items and so override the TYPE field.
  • [0302]
    The “TYPE” field codes and meanings are listed in the table below.
  • [0000]
    Rule Argument
    “Type” Field
    Bit Assignments Meaning of Bit (When Set = 1)
    0 The literal value is an integer.
    1 The literal value is a real.
    2 The literal value is a character string. Note that if the
    item is a pointer, it points to the character string.
    3 Item is an array. Otherwise, item is a scalar. In the
    case of an array, the RA(*).I field is the number of
    items in the array.
    4 Item is a pointer. Otherwise, it's a literal.
    5 Item is local, within the RA structure. So, the data
    item is in ra(*).v or ra(*).vr or ra(*).vc, depending
    upon the bits (0-2). Note that the item cannot be an
    array in this case.
    6 Item is within the scratch pad, which is process-
    private.
    7 Item is within the MADT, which is global.
    8 Item is within the database. In this case, the “pointer”
    field must point to an SQL string in the CLIST that
    is used to retrieve the data item.
  • [0303]
    1.9.4 Proposed Rule Structure Declarations (FORTRAN)
  • [0304]
    In FORTRAN, the various rule structures are given below. Note that the “pointer fields” are pointers into the RULE_PARAMATERS data structure. The “count fields” are the number of entries in the RULE_PARAMETERS structure for each class of rule elements. As an example, here are some pointer value calculations. Note that the storage is in series as listed within the structure.
  • [0305]
    RULE(1).EPP=1 (first entry in the RULE structure)
  • [0306]
    In general, the pointers are calculated as follows:
  • [0000]

    RULE(i).EPP=RULE(i−1).UAP+RULE(i−1).UAC (first free entry after previous rule)   1
  • [0000]

    RULE(i).EPC=(number of event parameters for rule i)   2
  • [0000]

    RULE(i).APP=RULE.EPP+RULE.EPC   3
  • [0000]

    RULE(i).DSP=RULE.APP+RULE.APC   4
  • [0000]

    RULE(i).DDP=RULE.DSP+RULE.DSC   5
  • [0000]

    RULE(i).SQLP=RULE.DDP+RULE.DDC   6
  • [0000]

    RULE(i).OSPP=RULE.SQLP+RULE.SQLC   7
  • [0000]

    RULE(i).AMP=RULE.OSPP+RULE.OSPC   8
  • [0000]

    RULE(i).UAP=RULE.AMP+RULE.AMC   9
  • [0307]
    Note that it might be desirable to have a NULL record between adjacent RULE_ARRAYS that correspond to each rule for sanity checking. This does waste space. Could terminate RULE structure with two consecutive NULL records.
  • [0000]
    structure /rule/
     union
     map
     integer*8 format
     integer*8 id !Rule ID - independent of rule location
     integer*8 loc  !ptr to RULE location in RI array/ SB
     integer*8 stat  !event/action status flags (one bit each)
     integer*8 next  !next rule to go to, if any
     integer*8 epc  !event parameter count
     integer*8 epp  !event parameter pointer
     integer*8 apc  !action parameter count
     integer*8 app  !action parameter pointer
     integer*8 dsc  !data source parameter count
     integer*8 dsp  !data source parameter pointer
     integer*8 ddc  !data destination parameter count
     integer*8 ddp  !data destination parameter pointer
     integer*8 sqlsc  !SQL source parameter count
     integer*8 sqlsp  !SQL source parameter pointer
     integer*8 sqldc  !SQL destination parameter count
     integer*8 sqldp  !SQL destination parameter pointer
     integer*8 ospc   !O/S Permissions parameter count
     integer*8 ospp   !O/S permissions parameter pointer
     integer*8 amc   !access mode parameter count
     integer*8 amp   !access mode parameter pointer
     integer*8 uac  !users allowed parameter count
     integer*8 uap  !users allowed parameter pointer
     end map
     map
     byte rbs(23*8) !just in case we need this
     end map
     end union
    end structure
  • [0308]
    Here is the general case of the parameter list structure. This structure is the same for all classes of rule parameters. This structure is the middle-level hierarchical carrier for all rule parameters. Since some rule parameters may be integer or real scalar arrays, this structure can point to those values as required via the “.p” field. Such scalar arrays are stored in other data structures.
  • [0309]
    As a reminder, the classes of rule parameters are Events, Actions, Data Source, Data Destination, SQL, O/S Permissions, Access Modes and Users Allowed.
  • [0000]
    structure /rule_arglist/  !general case
      union
       map
       integer*8 t
       integer*8 v
       integer*8 p
       integer*8 l
       end map
       map
       real*8 tr
       real*8 vr
       real*8 pr
       real*8 lr
       end map
       map
       character*8 tc
       character*8 vc
       character*8 pc
       character*8 lc
       end map
       map
       byte byte(32)   !a series of bytes
       end map
      end union
    end structure
  • [0310]
    Here is a structure for character arguments. These are of variable and unpredictable lengths. The reason for using this “third level hierarchical storage” is efficiency. The character fields are of variable lengths and so “reserving storage” for them wastes a lot of RAM. This structure allows for variable sizes and the pointers to the beginnings of each character element are mostly computed at compile time.
  • [0000]
    structure /rule_clist/  !general case
      union
       map
       character*1 c1(1024)
       end map
       map
       character*8 c8(128)
       end map
       map
       character*16 c16(64)
       end map
       map
       character*32 c32(32)
       end map
       map
       character*64 c64(16)
       end map
       map
       character*128 c128(8)
       end map
       map
       character*256 c256(4)
       end map
       map
       character*512 c512(2)
       end map
       map   character*1024 c1024
       end map
      end union
    end structure
  • [0311]
    Here is the structure for the scalar arrays. Note that these scalar arrays hold rule parameters that are sequences of integer, real or character variables. The reason for using this “third level hierarchical storage” is efficiency. If each integer or real object parameter was stored as an element of the RULE_PARAMETERS structure above, each integer/real parameter would require 32 bytes, versus 4 or 8 bytes currently.
  • [0000]
    structure   /rule_array/  !general case
     union
     map
      integer*8 il
     end map
     map
      real*8 rl
     end map
      map
      character*1 cl
     end map
     end union
    end structure
  • [0312]
    Here is the RULE_INFORMATION structure. This is a combination of RULE, RULE_ARGLIST and RULE_CLIST records. This structure should be instantiated in each routine that needs to access the rules.
  • [0000]
    structure /rule_information/
     record /rule/   ru(1000)
     record /rule_arglist/  ra(10000)
     record /rule_clist/  rc(100)
    end structure
  • [0313]
    1.9.5 Proposed Parameter Specification and Structures (RAM Oriented)
  • [0314]
    All parameters will be given in an ordered list. The start of the list will contain the total number of parameters so the rule processor (RP) knows the where the list ends. The start of the list may also contain the length (in bytes) of the entire list.
  • [0315]
    The parameters themselves will consist of a “type”, “value”, “pointer” and “length” fields. The list will terminate will a NULL record (i.e., zeros for all its component fields) for integrity verification. The lists may be mapped as integer, real, text, byte as required so that items within the list may take on whatever data type is appropriate, on an as-needed basis.
  • [0316]
    Generally if the parameter is of real or integer type, then its value will lie within the “value” field of the parameter array. If the parameter is a linear array of integers/reals, then the “pointer” field will point to the starting location of the integer./real parameter array in the “general integer/real array storage area.”
  • [0317]
    Alternatively, if the parameter is of “text/character” type then the “pointer” field of the parameter array will point to the its location within the “general text/character storage array.”
  • [0318]
    2.0 Rule Processor Structure & Organization; 2.1 IQ_RP Overview
  • [0319]
    IQ_RP.FOR is the source file for the rule processor. IQ_RP.COM is the “make file” which is a DCL command procedure that links IQ_RP with all of its component routines as well as the Oracle database.
  • [0320]
    IQ_RP reads screen files (.BXB) which contain BVC_GRAPHICS symbols. The RULE1 symbol is the carrier for the rule parameters (Note that the ICON1 symbol is obsolete as of 9/17/07). One RULE_1 symbol equals one rule. Each rule is characterized by various classes of parameters, as described in the preceding chapter. The RULE1 symbol is configured within IQ_BILD which uses the subroutine IQ_BILD_RULE to setup events-actions for each rule.
  • [0321]
    Upon launch, IQ_RP initializes the X-session, opens the startup screen file (*.BXBV) file and implements the rules contained therein. This startup screen file should contain rules that establish global parameters that are deployment-specific.
  • [0322]
    “Threaded into” IQ_RP's event checking is the use of the XLIB event queue for user events. IQ_RP looks for both user-defined events (through the RULE symbol) and XLIB user I/F events, which appear on the event queue.
  • [0323]
    IQ_RP is planar code in that its flowchart can be drawn without any crossing lines. IQ_RP consists of two main loops, the “Event Loop” (EL) and the “Action Loop” (AL). The event loop looks for events which are either user interface activities (UIF events) or events defined by the set of rules being executed. The event loop tests for these events and flags those events that have occurred.
  • [0324]
    2.2 IQ_RP_AST
  • [0325]
    IQ_RP has an AST (Asynchronous System Trap) routine that scans for periodic events, called IQ_RP_AST. IQ_RP_AST calls a timer routine (IQ_RP_AST_TIMER) which “wakes up” the AST and restarts it as needed. IQ_RP_AST and uses the XLIB procedure “XsendEvent” to put events on the XLIB event queue for processing whenever a periodic event occurs.
  • [0326]
    2.3 Component Routines
  • [0327]
    The IQ_RP program uses multiple subroutines and functions. As of 1/20/08 the list of subroutines required by IQ_RP is given in the list below. Note that many of the routines/functions are contained within the IQ_RP.FOR source file.
  • [0000]
    Subroutines Referenced:
    BVC_COMN_FILE
    BVC_DRIVER
    BVC_GRAPHICS
    BVC_REDRAW
    CancelCallback (contained herein)
    CancelCallbackDEB (contained herein)
    CancelCallbackFunc (contained herein)
    CONVERT_XY_X (contained herein)
    GetWidgetXmStringResourceAsText (contained herein)
    GetXmStringAsText (contained herein)
    IQ_ACTION_CLEANUP (contained herein)
    IQ_DSDD (contained herein)
    IQ_RP_AST (contained herein)
    IQ_RP_AST_TIMER (contained herein)
    IQ_SQL_SUBSTRING_CONVERT (contained herein)
    Init_XIO (contained herein)
    OkCallbackFunc (contained herein)
    OkCallbackDEB (contained herein)
    ProcessASTEvent (contained herein)
    Remove_XIO (contained herein)
    SetTextCursorVisibility (contained herein)
    StoreRuleData (contained herein)
    (SGB expand as required)
  • [0328]
    2.4 Security Checking (SGB TBC)
  • [0329]
    2.5 Audit Processing
  • [0330]
    IQ_RP does auditing. This occurs in between the event and action loops. Each “flagged” event may be individually audited as determined by the RULE1 setup. Each RULE1 can be configured to rule can be audited to a different degree so that the granularity of audit capability is nearly infinite.
  • [0331]
    The audit parameters that may be tracked are listed in the table below.
  • [0000]
    Audit Table Description (Table Name is “ADT”)
    Parameter name/description Oracle Name Oracle Data Type
    OVMS ID OVMS_UID VARCHAR2(1024)
    User ID USERID VARCHAR2(1024)
    Rule ID RULE_ID NUMBER(20,0)
    Screen file name (e.g., MTM_MTR.BXB) SCREEN_NAME VARCHAR2(128)
    Screen directory name (e.g., IQ$MTM:, etc. DIR_NAME VARCHAR2(512)
    Screen file directory device name (e.g., DEV_NAME VARCHAR2(32)
    DKB100:, etc.)
    Rule location within screen buffer RULE_LOC NUMBER(4, 0)
    Date/time DATETIME VARCHAR2(32)
    Event description (e.g., “Mouse click in work EVENT VARCHAR2(4000)
    window”)
    Action description (e.g., “Use fiel selection ACTION VARCHAR2(4000)
    dialog”)
    DS parameters DS_PARAMS VARCHAR2(4000)
    DD parameters DD_PARAMS VARCHAR2(4000)
    SQLS parameters SQLS_PARAMS VARCHAR2(4000)
    SQLD parameters SQLD_PARAMS VARCHAR2(4000)
    Screen image (either a BMP, JPEG or other SCREENSHOT BLOB
    graphic file format)
    IQware software version IQ_VERSION NUMBER(6, 4)
    IQ_RP.EXE image identifier RP_IMAGE_ID VARCHAR2(1024)
    Machine ID/specification MACHINE_ID VARCHAR2(1024)
    Customer ID CUSTOMER_ID VARCHAR2(1024)
    Customer location CUSTOMER_LOC VARCHAR2(1024)
  • [0332]
    2.6 Display/Screen Management
  • [0333]
    The rules/conditions for screen redraws are described in this section. Some actions require screen repaints/redraws either explicitly or implicitly. GET SCREEN action causes a redraw of the entire screen. Likewise, any change to symbol geometry requires that all overlapping symbols be redrawn from the bottom layer upward. Layers are numbered from 0 through 15. Alterations to a single symbol that do NOT affect geometry (shape, position, size, orientation) require that only the affected symbol be redrawn.
  • [0334]
    2.7 Known “Hard Limits”
  • [0335]
    IQ_RP (and its component routines./functions) has some internally-coded data storage and operand size limitations. Here is the current list of those limitations and where the limitation exists.
  • [0000]
    TABLE 9.3
    Operand and Storage Limitations Jan. 18, 2008
    Operand Value and Meaning Routine and/or Filename
    NROWS 5000. Maximum rows retrievable IQ_DB_ORACLE
    from Oracle at one time
    NROWS 5000. Maximum rows retrievable BVC_DB_ORACLE (to be
    from Oracle at one time deprecated)
    CO (CHAR*8192) 8192. Maximum number of IQ_RP & internal callbacks
    characters retrievable from one
    call to IQ_DSDD for a scalar
    character operand data type.
    IQ_DSDD gets operand literal
    values from the five classes of
    operands {INERNAL, MADT,
    SCRATCH PAD, EXTL, ORACLE}
    COA 128/1024. Maximum length (128 IQ_RP & internal callbacks
    CHAR*128(1024) bytes) and quantity (1024) of
    characters retrievable from one
    call to IQ_DSDD for a vector
    character operand data type.
    IQ_DSDD gets operand literal
    values from the five classes of
    operands {INERNAL, MADT,
    SCRATCH PAD, EXTL, ORACLE}
    IOA I*4(1024) 1024. Maximum rows of integers IQ_RP & callbacks
    retrievable from Oracle at one
    time
    ROA R*4(1024) 1024. Maximum rows of real IQ_RP & callbacks
    numbers retrievable from Oracle
    at one time
    “Scratch Pad” size 100. Maximum rows in the IQ_RP & callbacks
    scratch pad. The scratch pad is a
    structure defined within IQ_RP. It
    is shared between IQ_RP and its
    various callbacks.
    structure/scratch_pad/
    real*8 rval
    integer*8 ival
    character*256 cval
    end structure
    record/scratch_pad/sp(100)
    common/scratch_pad/sp
    DS (data source) 20. Maximum number of data IQ_RP & callbacks
    values source specifiers for any one rule.
    DD (data destination) 20. Maximum number of data IQ_RP & callbacks
    values destination specifiers for any one
    rule.
    SQLS (SQL source) 20 substrings of 128 characters IQ_BILD_RULE,
    substrings each. BVC_DEB and IQ_RP.
    Note that 128 characters is
    the maximum number of
    characters that can be
    entered in one line of an
    “old style” DEB.
    SQLD (SQL 20 substrings of 128 characters IQ_BILD_RULE,
    destination) each. BVC_DEB and IQ_RP.
    substrings Note that 128 characters is
    the maximum number of
    characters that can be
    entered in one line of an
    “old style” DEB.
    Number of “special 32 IQ_SQL_SUBSTRING_CONVERT
    directives” (aka which is contained
    substitutions) within IQ_RP.
    allowed within an
    SQL source or
    destination string
    Maximum length of 2048 characters IQ_SQL_SUBSTRING_CONVERT
    the literal value of the which is contained
    special directives within IQ_RP.
    allowed within an
    SQL source or
    destination string.
  • [0336]
    2.8 IQ_RP Flowchart
  • [0337]
    The rule processor flowchart is given below.

Claims (17)

  1. 1. A computer system, comprising:
    a first computer comprising:
    a first input configured for data communication with a network of computers;
    a computer-readable medium storing processor executable instructions corresponding to a plurality of rules where the plurality of rules control the functionality of the system;
    a first processor configured to receive external events from the network via the first input and configured to receive rule events from the processor executable instructions; and
    logic configured to audit the received external events and rule events, where the audit comprises recording event initiation data and selectively approving event action;
    where the processor processes an event only in response to the logic approving event action; and
    a second computer comprising:
    a second input configured for data communication with the network of computers;
    a second processor comprising executable instructions configured to function the second computer as a user interface for content received from the first computer over the network and to generate external events for communication to the first computer over the network.
  2. 2. The computer system as set forth in claim 1, where at least one of the plurality of rules is configured for processor execution to effect computer system actions.
  3. 3. The computer system as set forth in claim 1, where at least one of the plurality of rules is configured for processor execution to access a data location.
  4. 4. The computer system as set forth in claim 3, where the data location comprises a computer-readable medium for storing data.
  5. 5. The computer system as set forth in claim 3, where the data location comprises a computer-readable medium for retrieving data.
  6. 6. The computer system as set forth in claim 1, where at least one of the plurality of rules is configured for processor execution to format visual attributes for communication to and display on the second computer.
  7. 7. The computer system as set forth in claim 1, where the logic comprises user-level discrimination for recording event initiation data.
  8. 8. The computer system as set forth in claim 1, where the logic comprises user-level discrimination for approving event action.
  9. 9. The computer system as set forth in claim 1, where the first processor and the second processor run dissimilar operating systems.
  10. 10. A computer system, comprising:
    a first input configured for data communication with a network of computers;
    a computer-readable medium storing processor executable instructions corresponding to a plurality of rules where the plurality of rules control the functionality of the system;
    a first processor configured to receive external events from the network via the first input and configured to receive rule events from the processor executable instructions; and
    logic configured to audit the received external events and rule events, where the audit comprises recording event initiation data and selectively approving event action;
    where the processor processes an event only in response to the logic approving event action.
  11. 11. The computer system as set forth in claim 10, where at least one of the plurality of rules is configured for processor execution to effect computer system actions.
  12. 12. The computer system as set forth in claim 10, where at least one of the plurality of rules is configured for processor execution to access a data location.
  13. 13. The computer system as set forth in claim 12, where the data location comprises a computer-readable medium for storing data.
  14. 14. The computer system as set forth in claim 12, where the data location comprises a computer-readable medium for retrieving data.
  15. 15. The computer system as set forth in claim 10, where at least one of the plurality of rules is configured for processor execution to format visual attributes for communication over the network and display on a second computer.
  16. 16. The computer system as set forth in claim 10, where the logic comprises user-level discrimination for recording event initiation data.
  17. 17. The computer system as set forth in claim 10, where the logic comprises user-level discrimination for approving event action.
US12018017 2001-09-19 2008-01-22 Method and system for providing an event auditing client server software arrangement Abandoned US20090106353A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US32357501 true 2001-09-19 2001-09-19
US10247731 US7322028B2 (en) 2001-09-19 2002-09-19 Method and system for providing a virus-immune, rule-based cross-platform software system
US12018017 US20090106353A1 (en) 2001-09-19 2008-01-22 Method and system for providing an event auditing client server software arrangement

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12018017 US20090106353A1 (en) 2001-09-19 2008-01-22 Method and system for providing an event auditing client server software arrangement
US12827447 US8924928B1 (en) 2001-09-19 2010-06-30 Rule-based, run-time-alterable, client-agnostic client-server system

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10247731 Continuation-In-Part US7322028B2 (en) 2001-09-19 2002-09-19 Method and system for providing a virus-immune, rule-based cross-platform software system

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12827447 Continuation US8924928B1 (en) 2001-09-19 2010-06-30 Rule-based, run-time-alterable, client-agnostic client-server system

Publications (1)

Publication Number Publication Date
US20090106353A1 true true US20090106353A1 (en) 2009-04-23

Family

ID=40564574

Family Applications (2)

Application Number Title Priority Date Filing Date
US12018017 Abandoned US20090106353A1 (en) 2001-09-19 2008-01-22 Method and system for providing an event auditing client server software arrangement
US12827447 Active 2024-12-16 US8924928B1 (en) 2001-09-19 2010-06-30 Rule-based, run-time-alterable, client-agnostic client-server system

Family Applications After (1)

Application Number Title Priority Date Filing Date
US12827447 Active 2024-12-16 US8924928B1 (en) 2001-09-19 2010-06-30 Rule-based, run-time-alterable, client-agnostic client-server system

Country Status (1)

Country Link
US (2) US20090106353A1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100057751A1 (en) * 2008-08-26 2010-03-04 Siemens Aktiengesellschaft Method for evaluating a production rule for a memory management analysis
US20100257215A1 (en) * 2003-05-09 2010-10-07 Apple Inc. Configurable offline data store
US20110302217A1 (en) * 2010-06-08 2011-12-08 Robert Heidasch Semantic user interface data assembling

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120054626A1 (en) * 2010-08-30 2012-03-01 Jens Odenheimer Service level agreements-based cloud provisioning
US9383973B2 (en) * 2011-06-29 2016-07-05 Microsoft Technology Licensing, Llc Code suggestions
US9330148B2 (en) * 2011-06-30 2016-05-03 International Business Machines Corporation Adapting data quality rules based upon user application requirements
US9235493B2 (en) * 2012-11-30 2016-01-12 Oracle International Corporation System and method for peer-based code quality analysis reporting
CN103338254B (en) * 2013-06-28 2015-05-27 腾讯科技(深圳)有限公司 Terminal across application pushing method, device, terminal and system

Citations (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5283856A (en) * 1991-10-04 1994-02-01 Beyond, Inc. Event-driven rule-based messaging system
US5339435A (en) * 1991-02-28 1994-08-16 Hewlett-Packard Company Heterogenous software configuration management apparatus
US5414846A (en) * 1991-11-15 1995-05-09 International Business Machines Corporation Method for facilitating the configuration of programs
US5459854A (en) * 1990-06-04 1995-10-17 3Com Corporation Method for optimizing software for any one of a plurality of variant architectures
US5742829A (en) * 1995-03-10 1998-04-21 Microsoft Corporation Automatic software installation on heterogeneous networked client computer systems
US5764226A (en) * 1995-12-29 1998-06-09 International Business Machine Corp. Reusable and modifiable data entry interface part
US5797015A (en) * 1995-04-18 1998-08-18 Pitney Bowes Inc. Method of customizing application software in inserter systems
US5826239A (en) * 1996-12-17 1998-10-20 Hewlett-Packard Company Distributed workflow resource management system and method
US5909575A (en) * 1997-04-30 1999-06-01 Lucent Technologies Inc. Technique for efficiently maintaining system configuration
US5913061A (en) * 1997-01-08 1999-06-15 Crossroads Software, Inc. Modular application collaboration
US5931909A (en) * 1996-04-19 1999-08-03 Sun Microsystems, Inc. System for multiple-client software installation and upgrade
US5933646A (en) * 1996-05-10 1999-08-03 Apple Computer, Inc. Software manager for administration of a computer operating system
US5933647A (en) * 1997-01-24 1999-08-03 Cognet Corporation System and method for software distribution and desktop management in a computer network environment
US5950010A (en) * 1996-11-25 1999-09-07 J.D. Edwards World Source Co. System and method for customized application package building and installation
US5950011A (en) * 1996-03-01 1999-09-07 Bull S.A. System using designer editor and knowledge base for configuring preconfigured software in an open system in a distributed environment
US5953533A (en) * 1997-08-27 1999-09-14 Lucent Technologies Inc. Computer software distribution, installation and maintenance method and apparatus
US5970243A (en) * 1996-08-27 1999-10-19 Steeplechase Software, Inc. Online programming changes for industrial logic controllers
US5978579A (en) * 1997-08-12 1999-11-02 International Business Machines Corporation Architecture for customizable component system
US5999179A (en) * 1997-11-17 1999-12-07 Fujitsu Limited Platform independent computer network management client
US6006035A (en) * 1997-12-31 1999-12-21 Network Associates Method and system for custom computer software installation
US6029196A (en) * 1997-06-18 2000-02-22 Netscape Communications Corporation Automatic client configuration system
US6059842A (en) * 1998-04-14 2000-05-09 International Business Machines Corp. System and method for optimizing computer software and hardware
US6065116A (en) * 1997-05-07 2000-05-16 Unisys Corporation Method and apparatus for configuring a distributed application program
US6066182A (en) * 1998-11-05 2000-05-23 Platinum Technology Ip, Inc. Method and apparatus for operating system personalization during installation
US6178502B1 (en) * 2000-05-16 2001-01-23 International Business Machines Corporation Specifying complex device configeration through use characteristics
US6199158B1 (en) * 1998-12-16 2001-03-06 Nokia Mobile Phones Ltd. Method and apparatus for configuring variant software for electronic devices
US6208336B1 (en) * 1998-03-20 2001-03-27 Sun Microsystems, Inc. Dynamic graphical user interface feature-set configuration
US6223245B1 (en) * 1997-01-16 2001-04-24 Hyundai Electronics Industries Co., Ltd. Device and method for generating interrupt
US6230318B1 (en) * 1998-02-24 2001-05-08 Microsoft Corporation Application programs constructed entirely from autonomous component objects
US6256773B1 (en) * 1999-08-31 2001-07-03 Accenture Llp System, method and article of manufacture for configuration management in a development architecture framework
US6269480B1 (en) * 1999-03-29 2001-07-31 International Business Machines Corporation Cross platform installer-with the ability to create platform independent variables of specific operating system variables from a scripting language
US6282568B1 (en) * 1998-12-04 2001-08-28 Sun Microsystems, Inc. Platform independent distributed management system for manipulating managed objects in a network
US6282711B1 (en) * 1999-08-10 2001-08-28 Hewlett-Packard Company Method for more efficiently installing software components from a remote server source
US6289382B1 (en) * 1999-08-31 2001-09-11 Andersen Consulting, Llp System, method and article of manufacture for a globally addressable interface in a communication services patterns environment
US6298481B1 (en) * 1998-10-30 2001-10-02 Segasoft, Inc. System for modifying the functionality of compiled computer code at run-time
US6301707B1 (en) * 1997-09-30 2001-10-09 Pitney Bowes Inc. Installing software based on a profile
US6320309B1 (en) * 1997-12-24 2001-11-20 Futaba Denki Kogyo Kabushiki Kaisha Anode substrate for display device and method for manufacturing same
US20020064149A1 (en) * 1996-11-18 2002-05-30 Elliott Isaac K. System and method for providing requested quality of service in a hybrid network
US20030055944A1 (en) * 2001-09-19 2003-03-20 Belovich Steven G. Method and system for providing cross-platform, interoperable, rule-based software system
US20030191719A1 (en) * 1995-02-13 2003-10-09 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US6731625B1 (en) * 1997-02-10 2004-05-04 Mci Communications Corporation System, method and article of manufacture for a call back architecture in a hybrid network with support for internet telephony

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4837735A (en) * 1987-06-09 1989-06-06 Martin Marietta Energy Systems, Inc. Parallel machine architecture for production rule systems
US4918620A (en) * 1988-06-16 1990-04-17 General Electric Company Expert system method and architecture
US5475587A (en) * 1991-06-28 1995-12-12 Digital Equipment Corporation Method and apparatus for efficient morphological text analysis using a high-level language for compact specification of inflectional paradigms
US5263127A (en) * 1991-06-28 1993-11-16 Digital Equipment Corporation Method for fast rule execution of expert systems
US5442792A (en) * 1992-08-07 1995-08-15 Hughes Aircraft Company Expert system compilation method
JPH0778742B2 (en) * 1992-08-12 1995-08-23 インターナショナル・ビジネス・マシーンズ・コーポレイション Computer programming language conversion apparatus and method
US5412756A (en) * 1992-12-22 1995-05-02 Mitsubishi Denki Kabushiki Kaisha Artificial intelligence software shell for plant operation simulation
US5815713A (en) * 1995-04-13 1998-09-29 Sterling Software, Inc. Method and system for automated transformation of declarative language process specifications
GB9519678D0 (en) * 1995-09-27 1995-11-29 Philips Electronics Nv Behaviour prediction
US5875440A (en) * 1997-04-29 1999-02-23 Teleran Technologies, L.P. Hierarchically arranged knowledge domains
US7184710B2 (en) * 2001-02-13 2007-02-27 Telefonaktiebolaget Lm Ericsson (Publ) Transmission of filtering/filtered information over the lur interface
WO2003090164A3 (en) * 2002-04-19 2005-02-24 Computer Ass Think Inc System and method for providing inferencing services
US7203744B1 (en) * 2002-10-07 2007-04-10 Ipolicy Networks, Inc. Rule compiler for computer network policy enforcement systems
GB0316806D0 (en) * 2003-07-17 2003-08-20 Ivis Group Ltd Improved search engine
US20060041879A1 (en) * 2004-08-19 2006-02-23 Bower Shelley K System and method for changing defined user interface elements in a previously compiled program
US8099441B2 (en) * 2004-09-30 2012-01-17 Millennium It (Usa) Inc. System and method for configurable trading system

Patent Citations (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5459854A (en) * 1990-06-04 1995-10-17 3Com Corporation Method for optimizing software for any one of a plurality of variant architectures
US5339435A (en) * 1991-02-28 1994-08-16 Hewlett-Packard Company Heterogenous software configuration management apparatus
US5283856A (en) * 1991-10-04 1994-02-01 Beyond, Inc. Event-driven rule-based messaging system
US5414846A (en) * 1991-11-15 1995-05-09 International Business Machines Corporation Method for facilitating the configuration of programs
US20030191719A1 (en) * 1995-02-13 2003-10-09 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5742829A (en) * 1995-03-10 1998-04-21 Microsoft Corporation Automatic software installation on heterogeneous networked client computer systems
US5797015A (en) * 1995-04-18 1998-08-18 Pitney Bowes Inc. Method of customizing application software in inserter systems
US5764226A (en) * 1995-12-29 1998-06-09 International Business Machine Corp. Reusable and modifiable data entry interface part
US5950011A (en) * 1996-03-01 1999-09-07 Bull S.A. System using designer editor and knowledge base for configuring preconfigured software in an open system in a distributed environment
US5931909A (en) * 1996-04-19 1999-08-03 Sun Microsystems, Inc. System for multiple-client software installation and upgrade
US5933646A (en) * 1996-05-10 1999-08-03 Apple Computer, Inc. Software manager for administration of a computer operating system
US5970243A (en) * 1996-08-27 1999-10-19 Steeplechase Software, Inc. Online programming changes for industrial logic controllers
US20020064149A1 (en) * 1996-11-18 2002-05-30 Elliott Isaac K. System and method for providing requested quality of service in a hybrid network
US5950010A (en) * 1996-11-25 1999-09-07 J.D. Edwards World Source Co. System and method for customized application package building and installation
US5826239A (en) * 1996-12-17 1998-10-20 Hewlett-Packard Company Distributed workflow resource management system and method
US5913061A (en) * 1997-01-08 1999-06-15 Crossroads Software, Inc. Modular application collaboration
US6223245B1 (en) * 1997-01-16 2001-04-24 Hyundai Electronics Industries Co., Ltd. Device and method for generating interrupt
US5933647A (en) * 1997-01-24 1999-08-03 Cognet Corporation System and method for software distribution and desktop management in a computer network environment
US6731625B1 (en) * 1997-02-10 2004-05-04 Mci Communications Corporation System, method and article of manufacture for a call back architecture in a hybrid network with support for internet telephony
US5909575A (en) * 1997-04-30 1999-06-01 Lucent Technologies Inc. Technique for efficiently maintaining system configuration
US6065116A (en) * 1997-05-07 2000-05-16 Unisys Corporation Method and apparatus for configuring a distributed application program
US6029196A (en) * 1997-06-18 2000-02-22 Netscape Communications Corporation Automatic client configuration system
US5978579A (en) * 1997-08-12 1999-11-02 International Business Machines Corporation Architecture for customizable component system
US5953533A (en) * 1997-08-27 1999-09-14 Lucent Technologies Inc. Computer software distribution, installation and maintenance method and apparatus
US6301707B1 (en) * 1997-09-30 2001-10-09 Pitney Bowes Inc. Installing software based on a profile
US5999179A (en) * 1997-11-17 1999-12-07 Fujitsu Limited Platform independent computer network management client
US6320309B1 (en) * 1997-12-24 2001-11-20 Futaba Denki Kogyo Kabushiki Kaisha Anode substrate for display device and method for manufacturing same
US6006035A (en) * 1997-12-31 1999-12-21 Network Associates Method and system for custom computer software installation
US6230318B1 (en) * 1998-02-24 2001-05-08 Microsoft Corporation Application programs constructed entirely from autonomous component objects
US6208336B1 (en) * 1998-03-20 2001-03-27 Sun Microsystems, Inc. Dynamic graphical user interface feature-set configuration
US6059842A (en) * 1998-04-14 2000-05-09 International Business Machines Corp. System and method for optimizing computer software and hardware
US6298481B1 (en) * 1998-10-30 2001-10-02 Segasoft, Inc. System for modifying the functionality of compiled computer code at run-time
US6066182A (en) * 1998-11-05 2000-05-23 Platinum Technology Ip, Inc. Method and apparatus for operating system personalization during installation
US6282568B1 (en) * 1998-12-04 2001-08-28 Sun Microsystems, Inc. Platform independent distributed management system for manipulating managed objects in a network
US6199158B1 (en) * 1998-12-16 2001-03-06 Nokia Mobile Phones Ltd. Method and apparatus for configuring variant software for electronic devices
US6269480B1 (en) * 1999-03-29 2001-07-31 International Business Machines Corporation Cross platform installer-with the ability to create platform independent variables of specific operating system variables from a scripting language
US6282711B1 (en) * 1999-08-10 2001-08-28 Hewlett-Packard Company Method for more efficiently installing software components from a remote server source
US6289382B1 (en) * 1999-08-31 2001-09-11 Andersen Consulting, Llp System, method and article of manufacture for a globally addressable interface in a communication services patterns environment
US6256773B1 (en) * 1999-08-31 2001-07-03 Accenture Llp System, method and article of manufacture for configuration management in a development architecture framework
US6178502B1 (en) * 2000-05-16 2001-01-23 International Business Machines Corporation Specifying complex device configeration through use characteristics
US20030055944A1 (en) * 2001-09-19 2003-03-20 Belovich Steven G. Method and system for providing cross-platform, interoperable, rule-based software system

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8843530B2 (en) * 2003-05-09 2014-09-23 Apple Inc. Configurable offline data store
US20100257215A1 (en) * 2003-05-09 2010-10-07 Apple Inc. Configurable offline data store
US8352520B2 (en) * 2003-05-09 2013-01-08 Apple Inc. Configurable offline data store
US20130124580A1 (en) * 2003-05-09 2013-05-16 Apple Inc. Configurable offline data store
US8825717B2 (en) 2003-05-09 2014-09-02 Apple Inc. Configurable offline data store
US20100057751A1 (en) * 2008-08-26 2010-03-04 Siemens Aktiengesellschaft Method for evaluating a production rule for a memory management analysis
US9201771B2 (en) * 2008-08-26 2015-12-01 Siemens Aktiengesellschaft Method for evaluating a production rule for a memory management analysis
US20110302217A1 (en) * 2010-06-08 2011-12-08 Robert Heidasch Semantic user interface data assembling

Also Published As

Publication number Publication date Type
US8924928B1 (en) 2014-12-30 grant

Similar Documents

Publication Publication Date Title
Ghormley et al. SLIC: An Extensibility System for Commodity Operating Systems.
US5870611A (en) Install plan object for network installation of application programs
US7546602B2 (en) Application program interface for network software platform
US6996778B2 (en) User interface for managing multiple network resources
US6201996B1 (en) Object-oriented programmable industrial controller with distributed interface architecture
US6353926B1 (en) Software update notification
US6895586B1 (en) Enterprise management system and method which includes a common enterprise-wide namespace and prototype-based hierarchical inheritance
US7047522B1 (en) Method and system for verifying a computer program
US5732263A (en) Systems, methods and computer program products for generating and validating user defined object classes in an object oriented programming environment after build time
US7124192B2 (en) Role-permission model for security policy administration and enforcement
US6754885B1 (en) Methods and apparatus for controlling object appearance in a process control configuration system
US8104080B2 (en) Universal schema for representing management policy
US6253240B1 (en) Method for producing a coherent view of storage network by a storage network manager using data storage device configuration obtained from data storage devices
US7203937B1 (en) Software installation and configuration with specific role for target computer and identity indicator for authorization for performance of features
US6990654B2 (en) XML-based graphical user interface application development toolkit
US6779151B2 (en) Storing objects in a spreadsheet
US6862736B2 (en) Object manager for common information model
US6281896B1 (en) Data processor controlled interface with multiple tree of elements views expandable into individual detail views
US7159185B1 (en) Function objects
US5793982A (en) Validating an installation plan containing multiple transports and redirectors by adding data structure of the modules to the plan if the indicated transport and redirector modules are unavailable
US7865868B2 (en) .NET ribbon model for a ribbon user interface
US7096465B1 (en) Process control configuration system with parameterized objects
US5923885A (en) Acquisition and operation of remotely loaded software using applet modification of browser software
US6804686B1 (en) System and methodology for providing fixed UML layout for an object oriented class browser
US6049807A (en) Technique for maintaining object integrity during modification of a persistent store of objects