US20090106353A1

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

Info

Publication number: US20090106353A1
Application number: US12/018,017
Authority: US
Inventors: Steven G. Belovich
Original assignee: Individual
Current assignee: Individual
Priority date: 2001-09-19
Filing date: 2008-01-22
Publication date: 2009-04-23
Also published as: US8924928B1

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

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

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

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.
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.
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.
“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.
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.
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.
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.
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.
A new method and apparatus is thus needed which overcomes the above-mentioned problems and others.

SUMMARY

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Other aspects will occur to those skilled in the art upon reading and understanding the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

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.

FIG. 1 is a graphical image representative of costs to implement a business or manufacturing automation software project, according to the prior art;

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;

FIG. 3 is an example functional block diagram of software architecture;

FIG. 4 is a graph representative of increasing levels of abstraction of the computing environment;

FIG. 5 is an exemplary network diagram;

FIG. 6 is another exemplary network diagram;

FIG. 7 is yet another exemplary network diagram; and

FIG. 8 is still another network diagram.

DETAILED DESCRIPTION

“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.
“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.
“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.
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.
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 PC₁. 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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
“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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
With reference now to FIG. 5, an example first network 200 including a plurality of client machines 210 ₁-210 _nis 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.
With reference now to FIG. 6, an example single network 300 includes both plurality of client machines 310 ₁-310 _nand interfaces 330, 332, 334, 336, connected to server A′″.
With reference now to FIG. 7, an example network 400 includes a plurality of client machines 410 ₁-410 _nand 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 ₂.
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.
1.0 Rules; 1.1 Overview; 1.1.1 Introduction to Rule-Based Software
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.
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.
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.
1.1.2 Historical Perspective
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.
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.
1.1.3 General Concepts
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(e_i) then do g(a_i)” where {e_i} is the set of allowed events and {a_i} 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.
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

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.
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.
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.
Additional concepts and approaches are listed below:
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.
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.
a. Data display
b. Data analysis
c. User interface
d. Object-level security
e. File processing (including file conversion to PDF, etc.)
f. Data archiving
g. Tracking and auditing
h. Data output (printing & export)
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.
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:
a. Submenu item(s)
b. Table
c. Spreadsheet (superset of table)
d. Line graph
e. etc.
5. Current plan is to use Open Source stuff, e.g., WxWidgets (GTK+ etc.) for display objects.
1.1.4 Current Capabilities (prior to 5/1/07)
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.
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.
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:
1. Relational database schemes, tables and fields
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.
2. IQware symbol objects, in their respective local data areas
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.
3. Flat ASCII files
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.
4. RAM Resident Data Tables
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.
Here are some additional notes on current capabilities:
1 . ICON _—1 object can invoke rule script files.
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.
3. The “data fields” within the script files correspond to fields within a data table and within a database schema.
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).
5. All user input occurs through ICON _—1 which follows security policy.
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.
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.
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.
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.
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.
1.2 IQware's Rule Sources and Types; 1.2.1 Rule Coverage
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:
1. Object/Screen display
2. User interface object rendering and control
3. Menu object rendering and control
4. Database access
5. Data acquisition
6. Data analysis
7. Report preparation, formatting and output
8. External O/S actions (e.g., run a job, execute command procedure, etc.)
1.2.2 Classes of Rule Elements
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.
1. Summary (format, ID, location, status, next)
2. Events
3. Actions
4. Data Source
5. Data Destination
6. SQL Source
7. SQL Destination
8. O/S Permissions
9. Access Modes
10. Users Allowed
11. Audit rules
1.2.3 Classes of Data Source and Data Destination Operands
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.
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.
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.
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.
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}.
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.
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.
More operand classes may be added as deemed necessary.
1.2.4 Structures of Data Source and Data Destination Operands
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.
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.
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.
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.”
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.”
5. Higher Dimension Arrays—unsupported as of 11/7/07.
The ARRAY operand definition is expected to be generalized for higher-dimension arrays after 11/7/07.
1.3 Event Definitions; 1.3.1 Detailed Event Descriptions
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.
Event List & Description
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.
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.
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”.
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.
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.
6. Mouse click in window. This event occurs when the left (or only) mouse button is pressed anywhere within the work window.
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.
8. (future)
1.3.2 Event Triggering Options
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.
1.3.3 Event Parameters
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.

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 1^stcharacter
		EV(7) = ASCII code of 2^ndcharacter
		EV(8) = ASCII code of 3^rd 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 1^stoperand. 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 2^ndoperand.
		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 1^stoperand.
	operand string for both contents	EV(10-15) = Data source of 2^ndoperand
	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

1.4 Action Definitions; 1.4.1 Detailed Action Descriptions
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.
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.
Action List & Description
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.
2. Data Transfer. The “operand” specified by the data source (DS) parameters is transferred to the location specified by the data destination (DD) parameters.
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.
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.
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}.
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.
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}.
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.
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 RULE _—1 symbol. The widgets/gadgets supported in the DEB are listed below:
a) IQ_DEB_EMPTY_TYPE—An empty DEB cell. i.e. no discernable UI Widget is displayed.
b) IQ_DEB_SEPARATOR_TYPE—A separator cell. The value for LabelString is optional and InitStringValue is ignored.
c) IQ_DEB_TEXT_FIELD_TYPE—Single-line text field UI Widget.
d) IQ_DEB_SCROLL_TEXT_TYPE—A scrollable text field UI Widget.
e) IQ_DEB_SELECT_BOX_TYPE—A selection box UI Widget.
f) IQ_DEB_FILE_SELECT_BOX_TYPE—A file selection box UI Widget.
10. Display and activate various widget UIF objects (User Interface). These objects include:
a) XmCreateMenuBar
b) XmCreatePopupMenu
c) XmCreatePulldownMenu
d) XmCreateText.
e) XmCreateTextField
f) (Others to be added as required)
11. Display a set of menus and get user input
12. Audit an event. This causes a timestamp, user ID and other relevant information to be saved for later review and reporting.
13. Alter/set object security and access levels.
14. Grant/revoke privileges at the O/S level.
15. Spawn a process (must supply the full process context)
16. Run a job
1.4.2 Action Audit Options; SGB 9/3/07 TBC.
1.4.3 Action Parameters
Here are the definitions of allowed action parameters. These were initially taken from the “ICON _—1” 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.

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	character128 deb_sqlsv(8deb_max_row)
	IQ_RP must also	character128 deb_sqldv(8deb_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)

1.4.4 Action Cleanup options
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.


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)

1.4.5 Rule Status Bits
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.


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

1.4.6 Rule Chaining
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 RULE _—1 symbol is nonzero. For User I/F rules, this happens whenever the “Next Rule ID” field of the RULE _—1 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.
1.5 Data Source & Destination Definitions; 1.5.1 Relevant Source Code Modules
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!).
1.5.2 Data Source & Destination Parameters
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.


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)

1.6 SQL Statement Definitions; 1.6.1SQL Statement Classes
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.
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).

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.

1.6.2 SQL Statement Parameters
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.
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.
1.7 Identifier Length Limits
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).
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.
1.8 Security Issues
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.
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.
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 ICON _—1 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.
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.
1.9 Proposed Rule Specification and Data Structures; 1.9.1 Structure Summary and Description
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.
1.9.2 Classes of Rule Elements
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.
1. Summary (format, ID, location, status)
2. Events
3. Actions
4. Data Source
5. Data Destination
6. SQL Source
7. SQL Destination
8. O/S Permissions
9. Access Modes
10. Users Allowed
The details of the specific rule fields are listed below:
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.
2. Rule ID (I8)—an integer identifier (and pointer) to a rule.
3. Location (I8)—pointer to the location of the RULE _—1 symbol within the screen buffer. Note that as of 7/17/07, RULE _—1 is the symbol that “carries”the rule. The RULE data structure is a companion to the RULE _—1 symbol.
4. Status flags (I8)—bits that represent the status of the event or action. Examples are event has occurred, action complete, etc.
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.
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.
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.
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.
9. Data Source Pointer (I8)—Pointer to the list of data source parameters
10. Data Source Parameter List (I8/R8/BC)—a list of parameters describing the data source and data source type
11. Data Destination Pointer (I8)—Pointer to the list of data destination parameters
12. Data Destination Parameter List (I8/R8/B/C)—a list of parameters describing the data destination and data destination type
13. SQL Source Statement Pointer (I8)—Pointer to the list of SQL statement parameters.
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.
15. SQL Destination Statement Pointer (I8)—Pointer to the list of SQL statement parameters.
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.
17. OS permissions Pointer (I8)—pointer to the list of OVMS permissions
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
19. Access Mode Pointer (I8)—Pointer to the list of access mode parameters
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
21. Users Allowed Pointer (I8)—Pointer to the list of allowed users parameters.
22. Users Allowed Parameter List (B/C)—an ACL of allowed users to access/execute the rule.
1.9.3 Rule Argument List Datatypes
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.
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.
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.
The “TYPE” field codes and meanings are listed in the table below.


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.

1.9.4 Proposed Rule Structure Declarations (FORTRAN)
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.
RULE(1).EPP=1 (first entry in the RULE structure)
In general, the pointers are calculated as follows:
RULE(i).EPP=RULE(i−1).UAP+RULE(i−1).UAC (first free entry after previous rule) 1
RULE(i).EPC=(number of event parameters for rule i) 2
RULE(i).APP=RULE.EPP+RULE.EPC 3
RULE(i).DSP=RULE.APP+RULE.APC 4
RULE(i).DDP=RULE.DSP+RULE.DSC 5
RULE(i).SQLP=RULE.DDP+RULE.DDC 6
RULE(i).OSPP=RULE.SQLP+RULE.SQLC 7
RULE(i).AMP=RULE.OSPP+RULE.OSPC 8
RULE(i).UAP=RULE.AMP+RULE.AMC 9
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.


	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

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.
As a reminder, the classes of rule parameters are Events, Actions, Data Source, Data Destination, SQL, O/S Permissions, Access Modes and Users Allowed.


	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

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.


	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

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.


	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

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.


	structure /rule_information/
	record /rule/ ru(1000)
	record /rule_arglist/ ra(10000)
	record /rule_clist/ rc(100)
	end structure

1.9.5 Proposed Parameter Specification and Structures (RAM Oriented)
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.
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.
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.”
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.”
2.0 Rule Processor Structure & Organization; 2.1 IQ_RP Overview
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.
IQ_RP reads screen files (.BXB) which contain BVC_GRAPHICS symbols. The RULE _—1 symbol is the carrier for the rule parameters (Note that the ICON _—1 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 RULE _—1 symbol is configured within IQ_BILD which uses the subroutine IQ_BILD_RULE to setup events-actions for each rule.
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.
“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.
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.
2.2 IQ_RP_AST
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.
2.3 Component Routines
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.


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)

2.4 Security Checking (SGB TBC)
2.5 Audit Processing
IQ_RP does auditing. This occurs in between the event and action loops. Each “flagged” event may be individually audited as determined by the RULE _—1 setup. Each RULE _—1 can be configured to rule can be audited to a different degree so that the granularity of audit capability is nearly infinite.
The audit parameters that may be tracked are listed in the table below.

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)

2.6 Display/Screen Management
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.
2.7 Known “Hard Limits”
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.

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.

2.8 IQ_RP Flowchart
The rule processor flowchart is given below.

Claims

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. 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. 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. The computer system as set forth in claim 3, where the data location comprises a computer-readable medium for storing data.

5. The computer system as set forth in claim 3, where the data location comprises a computer-readable medium for retrieving data.

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. The computer system as set forth in claim 1, where the logic comprises user-level discrimination for recording event initiation data.

8. The computer system as set forth in claim 1, where the logic comprises user-level discrimination for approving event action.

9. The computer system as set forth in claim 1, where the first processor and the second processor run dissimilar operating systems.

10. A computer system, comprising:

a first input configured for data communication with a network of computers;

where the processor processes an event only in response to the logic approving event action.

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. 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. The computer system as set forth in claim 12, where the data location comprises a computer-readable medium for storing data.

14. The computer system as set forth in claim 12, where the data location comprises a computer-readable medium for retrieving data.

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. The computer system as set forth in claim 10, where the logic comprises user-level discrimination for recording event initiation data.

17. The computer system as set forth in claim 10, where the logic comprises user-level discrimination for approving event action.