System for creating, editing, displaying, and executing rules-based programming language rules having action part subsets for both true and false evaluation of the conditional part


United States Patent		5596752
Knudsen , ; et al.		January 21, 1997

	*Title*

System for creating, editing, displaying, and executing rules-based programming language rules having action part subsets for both true and false evaluation of the conditional part

	*Abstract*

A programmable computer which operates by executing rules, each including a rule name, and optionally: input parameters, a set of conditions, a set of actions associated with each condition, and a set of exception handlers. A condition is a logical expression which evaluates to a true or false boolean value, while an action is an executable statement. An exception handler contains executable statements. The computer includes text entry and display means for programming of rules. A rule is displayed with each condition and each action having a row of text. The computer generates a yes/no quadrant into which a programmer may enter sequence numbers, to associate ordered sets of actions with individual conditions. Sequence numbers may be entered not associated with any condition, to define a set of default actions. Upon entering a rule, the computer sequentially evaluates the rule's conditions. Upon a condition evaluating to true, the computer executes the set of actions associated with that condition, then exits the rule. If the rule contains no conditions or none evaluates to true, the set of default actions will be executed, and the rule exited. If, during execution of the rule, the computer detects an exception event, such as a missing datum or other execution error, the computer passes to the rule the name of the detected exception event. If the rule contains an exception handler bearing the same name, the computer will execute the statements within that exception handler.



Inventors:	Knudsen; Helge (Oakville, CA), Chong; Daniel T. (Woodbridge, CA), Yaffe; John (Mississauga, CA), Taugher; James E. (Mississauga, CA), Robertson; Michael (Mississauga, CA), Plazak; Zbigniew (Etobicoke, CA)
Assignee:	Amdahl Corporation (Sunnyvale, CA)
Appl. No.:	029700
Filed:	March 11, 1993

Current U.S. Class:			717/117 717/109
Field of Search:			395/600,700,50,51,53 364/DIG.1,DIG.2,274,274.5,280,280.7,282.1

	U.S. Patent Documents
4787035	November 1988	Bourne
4791561	December 1988	Huber
4816994	March 1989	Alexander et al.
4860204	August 1989	Gendron et al.
4884217	November 1989	De Caria et al.
4905138	February 1990	Bourne
4974157	November 1990	Winfield et al.
4989132	January 1991	Mellender et al.
5228116	July 1993	Harris et al.


	Other References
"Table Storage Architecture for the OS/2 Extended Edition Database Manager", IBM Technical Disclosure Bulletin, vol. 32, No. 5A, Oct. 1989, pp. 30-32. . M. Papazoglou, "An Extensible DBMS for Small and Medium Systems", IEEE Micro, vol. 9, No. 2, Apr. 1989, pp. 52-68. . A. Brown et al., "Data Base Management for HP Precision Architecture Computers", Hewlett-Packard Journal, vol. 37, No. 12, Dec. 1986, pp. 33-48. . D. J. Haderle et al., "IBM Database 2 Overview", IBM Systems Journal, vol. 23, No. 2, 1984, pp. 112-125. . Richard C. Waters, "The Programmer's Apprentice: Knowledge Based Program Editing", IEEE Transactions on Software Engineering, Jan. 1982, vol. SE-8, No. 1, pp. 1-12..~


Primary Examiner:	Kriess; Kevin A.
Assistant Examiner:	Backenstose; Jonathan, Hall
Attorney, Agent or Firm:	Fliesler, Dubb, Meyer & Lovejoy


	*Parent Case Text*

CROSS-REFERENCE TO RELATED APPLICATIONS This application is a divisional of Ser. No. 07/968,237, filed Oct. 29, 1992, which is a continuation of Ser. No. 07/830,548, filed Jan. 31, 1992, now abandoned, which is a continuation of Ser. No. 07/450,298, filed Dec. 13, 1989, now abandoned, which is a continuation-in-part of Ser. No. 07/402,862, filed Sep. 1, 1989.


	*Claims*

What is claimed is: 1. A programmable computer for use in creating, editing, displaying and executing programs in a rules-based programming language, said computer comprising: means for displaying: means for storing a set of actions in the form of executable statements and a plurality of rule means each of said rule means comprising: i) a rule name, ii) a set of parameters through which the computer provides input data to said rule means, iii) a set of conditions in the form of logical expressions, each evaluating to a boolean result, said boolean result comprising one of a true state and a false state, iv) a first ordered subset of actions from said set of actions to be executed when said result of said condition is evaluated as said true state, and v) a second ordered subset of actions from said set of action to be executed when said result of said condition is evaluated as said false state; wherein each action in said first and second subsets of actions has a sequence number indicating the order in which said actions in each said first and second subset of actions are to be executed; and rule execution means for executing a rule means comprising; means, coupled to said means for storing, for sequentially evaluating said condition of said set of conditions for a rule means being executed by said rule execution means and for generating an evaluation signal representing a first boolean value when said condition is in said true state and a second boolean value when said condition is in said false state; and means, responsively coupled to said means for evaluating, for executing, in response to said evaluation signal for said condition presently being evaluated by said evaluation means for said rule means presently being executed by said execution means in order, said first subset of actions in response to said evaluation signal representing said first boolean value and in order said second subset of actions in response to said evaluation signal representing said second boolean value. 2. The computer of claim 1 wherein: said means for storing further stores a set of exceptions, each exception of said set of exceptions including an exception name and a set of exception actions coupled with each said exception name and each said rule name comprises; vi) a subset of exceptions from said set of exception identified by said exception's names; and said rule execution means further comprises: means, coupled to said means for executing, for detecting exception events during execution of said rule name and for returning, responsive to detection of a given exception event, an exception name identifying the given exception event; and means, coupled to said means for storing and responsive to return of a said exception name by said means for detecting, for executing the set of exception actions coupled to said exception name, when said exception name is the name of an exception in said set of exceptions for the rule name presently being executed by said rule execution means. 3. The computer of claim 1 further including: text entry means for inputting text for a rule name indicating said rule name, set of parameters, set of conditions, and set of actions; display means, coupled to said text entry means, for displaying, i) said text indicating said rule name and set of parameters as a row of text, ii) text indicating each condition from said set of conditions as a row of condition text and the respective rows of condition text as a column, and iii) text indicating each action from said set of actions as a row of action text and the respective rows of action text as a column; means, coupled to said text entry mean, for generating and displaying a yes/no quadrant of boolean indicators arranged in yes/no rows each uniquely associated with one row of condition text and the corresponding condition, and in yes/no columns each including exactly one indicator of said first boolean value, said exactly one indicator being in a yes/no row uniquely coupling one of said conditions with the given yes/no column such that each condition is uniquely coupled with exactly one yes/no column; and means, coupled to said means for generating and displaying, for accepting and displaying action sequence numbers in an action quadrant arranged in action rows each uniquely associated with one row of action text and its action, and in action columns each uniquely associated with one yes/no column and the condition coupled with that one yes/no column, each given action sequence number associating, through its action row and action column, a given action with a given condition, the action sequence numbers within each action column defining the subset of actions associated with the given condition, and the order of execution of the subset of actions being defined by the relative magnitudes of the action sequence numbers in the given action column. 4. The computer of claim 3 further comprising: said text entry means being further for inputting text for a rule indicating a subset of exception names; said display means further displaying; iv) text of said set of exceptions names. 5. The computer of claim 1, wherein said conditions and actions includes object coded rule instructions where: each condition, which has associated actions, including a series of instances of a first instruction (@ACALL), execution of each of which causes execution to jump to a given action associated with the current condition; each action which terminates in a second instruction (@ARETURN), execution of which causes execution to return from execution of the given action to a point at which the given action was invoked. 6. The computer of claim 5 wherein said object coded rule instructions further include: a third instruction (@AEND), which is not executed, but which separates said set of conditions from said set of actions. 7. The computer of claim 2, wherein said conditions, actions and exceptions includes object coded rule instructions where: each condition, which has associated actions, including a series of instances of a first instruction (@ACALL), execution of each of which causes execution to jump to a given action associated with the current condition; each action which terminates in a second instruction (@ARETURN), execution of which causes execution to return from execution of the given action to a point at which the given action was invoked; and said means for detecting exception events causes said computer to execute a fifth instruction (@SIGNAL), execution of which creates an exception event and specifies a name of the created exception event. 8. The computer of claim 5, wherein said means for executing first and second subsets of actions further includes: means for operating a virtual stack which holds data including a first datum (D1) and a second datum (D2), and executes object coded arithmetic instructions upon data in said virtual stack, said arithmetic instructions comprising: a sixth instruction (@ADD), execution of which pops two data from said virtual stack, performs addition upon said two data, and pushes the sum onto said virtual stack (D2+D1); a seventh instruction (@SUB), execution of which pops two data from said virtual stack, performs subtraction upon said two data, and pushes the difference onto said virtual stack (D2-D1); an eighth instruction (@MULT), execution of which pops two data from said virtual stack, performs multiplication upon said two data, and pushes the product onto said virtual stack (D2*D1); a ninth instruction (@DIV), execution of which pops two data from said virtual suck, performs division upon said two data, and pushes the quotient onto said virtual stack (D2/D1); a tenth instruction (@EXP), execution of which pops two data from said virtual stack, performs exponentiation upon said two data, and pushes the result onto said virtual suck (D2.uparw.D1); an eleventh instruction (@UNM), execution of which pops one data from said virtual stack, and pushes the unary negative of said one data onto said virtual suck (-(D1)); and a twelfth instruction (@CAT), execution of which pops two data from said virtual suck, performs concatenation upon said two data, and pushes the concatenated result onto said virtual stack (D1D2). 9. The computer of claim 5, wherein said means for executing first and second subsets of actions further includes: means for operating a virtual stack which holds data, and executes object coded relational instructions upon dam in said virtual stack, where said means for executing in executing a relational instruction pops a first datum (D1) and a second datum (D2) from said virtual stack and compares said first datum to said second datum according to a relation specified by said relational instruction, and pushes onto said virtual stack a boolean indicator of the result of the comparison, said relational instructions comprising: a thirteenth instruction (@EQ) comparing said second datum to said first datum for equality (D2=D1); a fourteenth instruction (@NE) comparing said second datum to said first datum for inequality (D2-=D1); a fifteenth instruction (@LT) comparing whether said second datum is less than said fast datum (D2<D1); a sixteenth instruction (@LE) comparing whether said second datum is not greater than said first datum (D2<=D1); a seventeenth instruction (@GT) comparing whether said second datum is greater than said first datum (D2>D1); an eighteenth instruction (@GE) comparing whether said second datum is not less than said first datum (D2>=D1). 10. The computer of claim 5, wherein said means for executing first and second subsets of actions further includes: means for operating a virtual stack which holds data including a first datum (D1) and a second datum (D2), and further executes object coded logical instructions upon data in said stack, said logical instructions comprising: a nineteenth instruction (@AND), execution of which pops first and second data from said virtual stack, and pushes onto said virtual stack a boolean indication of whether both first and second data have values of true (D2 & D1); a twentieth instruction (@OR), execution of which pops first and second data from said virtual stack, and pushes onto said virtual stack a boolean indication of whether either first or second data, or both, has a value of true (D2 v D1); a twenty-first instruction (@NOT), execution of which pops a first datum from said virtual stack, and pushes onto said virtual stack the boolean inverse of said first datum (HD1). 11. The computer of claim 5, wherein said means for executing first and second subsets of actions further includes: means for operating a virtual stack and maintains a database having tables where each table has a table name, and accesses tables by a table access method (TAM) which accesses a table by the table named in a TAM parameter list, and further executing object coded table control instructions upon said database, said table control instructions comprising: a twenty-second instruction (@WFIELD) identifying a given field within a given table, execution of which pushes said given field of said given table onto said virtual stack; a twenty-third instruction (@RFIELD) identifying a given field within a given table, execution of which, i) pushes said given field of said given table onto said virtual stack if contents of said given field contain an assigned value, but ii) causes an exception event to occur, if contents of said given field contain no assigned value, signalling said computer that although said given field has no assigned value an attempt was made to use the contents of said field; a twenty-fourth instruction (@SET) identifying a given field within a given table and specifying a value, execution of which assigns said value to said given field of said given table; a twenty-fifth instruction (@ABN) giving a field name and a value, execution of which assigns said given value to each field having the given name, in all tables which include a field having the given name; a twenty-sixth instruction (@TAM) specifying a table access request, execution of which calls the table access method to perform the specified table access request; a twenty-seventh instruction (@TAMP) specifying a reference parameter, execution of which inserts the specified reference parameter into the TAM parameter list; and a twenty-eighth instruction (@TAMN) specifying a table name, execution of which inserts the specified table name into said TAM parameter list.


	*Description*

COPYRIGHT AUTHORIZATION A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. BACKGROUND OF THE INVENTION The present invention relates to a method for programming a computer to execute a rule and a programmable computer for executing a rule. DESCRIPTION OF RELATED ART The development of applications programs by software engineers is a complicated task. This complication arises in part because of environmental parameters, like the variety of data types, hardware types, operating system types, program auditing techniques, and other details. Computer programming languages have developed to handle all of these environmental parameters, usually by requiring explicit recognition of the parameters in the code. Thus, the typical application programmer must contend with data definitions, editing and validation of input data, selection and ordering of data available to the program, looping constraints on the system for the program, output editing and validation conventions, error processing, program auditing, and other complicated tasks in addition to the basic algorithm for accomplishing the application in mind. These environmental parameters also complicate the running of programs written with high level languages. These programs must be compiled or loaded prior to execution, during which time all the physical resources, data, and rules associated with the application must be bound together. This binding of resources required for a given application at compile time or load time, makes it difficult to implement truly event driven, or data driven, programs. Attempts have been made to make some programming languages interpretive. That is, to allow them to bind certain resources to the program while it is being run. However, these interpretive programs have very limited performance and have not gained widespread acceptance in the industry. Accordingly, there is a need for an operating system, data base, and data access method which will allow application programmers to be free of complications caused by environmental parameters. SUMMARY OF THE INVENTION The present invention provides an operating system, data base, and access method which pushes data definitions, input editing and validation, selection and ordering, looping, output editing and validation, error processing, and auditing down into the data access method, thereby freeing the application programmer of explicit recognition in his program of these environmental parameters. The system comprises a virtual stack machine, which operates based on a simple instruction set to execute programs of instructions. In addition, a data base having a unique access structure stores all the dictionary information required for binding during run time of objects stored in the data base to the program being executed. Finally, a data access method, optimized for the access structure, performs all the access functions on the dictionary, sub-routines, and data to be used by the program being executed. The system performs the binding during run time of objects retrieved through the access method during execution of a current program. In addition, the system includes servers for display screens, storage subsystems based on other data access structures, such as IMS, and other peripheral subsystems. These servers again are dynamically bound to a given program at run time. The access structure consists of a plurality of tables, each table having a plurality of rows, and each row having a plurality of fields. Each row in the access structure is identified by a unique primary key in one of the fields of the row and by a table identifier. Objects that are retrievable through the access structure are stored as fields in the tables. Tables in the access structure can be further divides into subtables, where each subtable is identified by a table parameter. Tables are identified by a table name and any table parameters that have been assigned to the table. The access method maintains indexes into the tables stored in the access structure. The indexes are first ordered on the table name, and then ordered on the parameter or parameters associated with a given table. Finally, the indexes are ordered on the primary key of each row within a table. A subset of the tables stored in the access structure consists of dictionary data or metadata, which is utilized for binding objects stored in the data base with a program currently being executed. The dictionary data includes event rules which are executed in response to data access events, selection criteria by which access to objects within the data base can be controlled, ordering algorithms, by which objects within the access structure can be ordered during access events, and a plurality of peripheral device servers. The implementation of servers within the access method allows the extended common view of objects available to the data processing system to be processed through a single interface. Thus, objects in the native store of the access method stored in other systems, such as IMS, DB2, or other data base management systems, are viewed according to a single access structure by the programmer. Furthermore, the operating system, according to the present invention, operates based on an isomorphic programming representation. The high level language correlates one to one with internal representation of programs which are directly executed on the virtual stack machine. Thus, only one copy of a given program module is stored within the data base. According to this aspect, a translator/detranslator is utilized by application programmers who perform program development functions. Whenever the programming is being done, the internal representation is translated to a high level source. Whenever the resulting program is stored, the source is translated back to the internal representation. This provides for great mobility of programs from system to system, and eliminates many problems associated with maintaining a consistent view of a program which may be operated by a number of users. Other aspects and advantages of the present invention can be seen upon review of the figures, the detailed description, and the claims which follow. BRIEF DESCRIPTION OF THE FIGURES FIG. 1 is an overview block diagram of a data processing system implementing the present invention. FIG. 2 is a schematic block diagram of the virtual data processing machine according to the present invention. FIG. 3 is a table definition for: TABLES. FIG. 4 is a table definition for: FIELDS. FIG. 5 is a table definition for: PARMS. FIG. 6 is a table definition for: SELECTION. FIG. 7 is a table definition for: ORDERING. FIG. 8 is a table definition for: EVENTRULES. FIG. 9 is a table definition for: @RULESLIBRARY. FIG. 10 is a table definition for: IMSTABFIELDS. FIG. 11 is a table definition for: IMSSEGFIELDS. FIG. 12 is a table definition for: IMSACCESS. FIG. 13 is a table definition for: SCREENS. FIG. 14 is a table definition for: SCREENTABLES. FIG. 15 is a table definition for: SCREENFIELDS. FIG. 16 is a conceptual diagram of the transaction processor according to the present invention. FIG. 17 is a schematic diagram illustrating operation of the transaction processor for a rule call. FIG. 18 is a diagram of the rule name hashing method. FIG. 19 is a schematic diagram of the table name hashing method. FIG. 20 is a conceptual diagram of the table access machine with a plurality of servers and buffers according to the present invention. FIG. 21 is a conceptual diagram of the storage in the table access machine. FIG. 22 is a table showing the table types and the table operands which work for a given table type. FIG. 23 is a conceptual diagram of the CTABLE. FIG. 24 is a conceptual diagram of a source table and a subview table. FIG. 25 illustrates the operation of the intent list. FIG. 26 is a conceptual diagram of a transaction in the virtual machine of the present invention. FIG. 27 is a schematic diagram of the table data store access method. FIG. 28 illustrates the layout of a page of data in the table data store. FIG. 29 is an overview of the rule editor components according to the present invention. FIG. 36 shows the TOKENS and the LONG.sub.-- STRINGS tables used by the rule editor. FIGS. 31, 32, 33A-33C, and 34A-34E illustrate operation of the detranslator according to the present invention. DETAILED DESCRIPTION A detailed description of a preferred embodiment of the present invention is disclosed with reference to the figures. First, an overview of the data processing system according to the present invention is provided. Next, a description of the rule language used by application programmers in the system is described. Next, the specification of the manner in which data is stored in the system is provided. After setting out the application programmer's view of the system, a specification of the object level representation of the rules is provided. From this specification, a description of the virtual machines which make up the data processing system are described. These systems include a virtual stack machine which executes the object level rules, a table access method which provides an interface between the virtual stack machine and the data storage systems. Finally, a description of the native data storage system, known as the table data store, is disclosed. In addition, the mechanism for translating from the rule language to the internal object level representation of the rules, and for detranslating from the object representation of the rules to the rule language according to the present invention is described. I. System Overview FIG. 1 illustrates the basic implementation of the data processing system according to the present invention. This system is implemented as a virtual machine on a main frame computer 10. The main frame computer runs a host operating system, MVS in the preferred system. Under the host operating system, a data base access system, such as IMS 11, can run. At the same time, the data processing system according to the present invention, known as HURON 12, runs under MVS. Coupled with the main frame are a plurality of user terminals 13, 14, such as the Model 3270's. Also, work stations 15 running other operating systems, such as UNIX, could be coupled to the main frame 10. Connected with the main frame data server, such as IMS 11, are direct access storage devices 16 and 17 storing corporate data. Also, direct access storage devices 18 and 19 are coupled with the HURON system 12. FIG. 2 shows a conceptual block diagram of the HURON data processing system. The system includes a transaction processor 20, a table access machine 21, and a table data store server 22 which is coupled to direct access storage device 23. The table access machine 21 also drives a screen server 24 which is coupled to a user terminal 25, and an import/export server 26 coupled to other sources of data files 27 and 28. In addition, the table access machine 21 provides an interface to a heterogeneous data base system server, such as IMS server 29, which is coupled to direct storage access devices 30. The transaction processor 20 is implemented as a virtual stack machine which executes the object code level representation of rules. Those rules are stored in a rule library 31 associated with each transaction. The rule library typically includes a session manager 39 which provides a screen menu and basic utilities to the programmer. Utilities include rule editor 32, a table editor browser 33, RPW and print utilities 34, query processors, if necessary, 35, and application programs 36, 37, 38 such as are called up for a given transaction. Through the table access machine 21, physical data stored in direct access storage devices 23, 30, 27, 28 are presented to the transaction processor 20 as if it were stored in the table data store system. The servers 22, 24, 26, 29, the table access machine 21, and the transaction processor 20 are all implemented as virtual machines on the host operating system. Thus, in the preferred system, these virtual machines are implemented with system 370 assembler language and perform the functions which are described in detail below. A high level view of the system is best provided by understanding the rule language used by application programmers. II. Rules Language The rule language is the programming interface for the system. The language comprises an integrated set of database access commands, 4th-generation constructs, and conventional language statements which makes structured programming a natural consequence of developing an application. The rules have four parts. These parts contain: 1. the rule definition 2. conditions 3. actions 4. exception handlers The rules are introduced by giving several short examples. Next, each of the four parts of a rule are described, in turn. Then, details concerning expressions, data types, and indirect references to tables and fields are set out. Finally, a formal specification of the rule language in Backus-Naur form is provided, and the standard routines are described. General Form of Rules Conceptually, a rule has four parts. When presented physically, the four parts are separated by horizontal lines. The examples that follow show the general form of Huron rules. Table 1 shows a sample rule named LEAPYEAR, which has one argument names YEAR. LEAPYEAR is a function because it RETURNs a value--either `Y` or `N`--as a result of execution. TABLE 1 ______________________________________ The Rule LEAPYEAR LEAPYEAR (YEAR); ______________________________________ REMAINDER (YEAR, 4) = 0' Y N ______________________________________ RETURN (`Y`); 1 RETURN (`N`); 1 ______________________________________ The rule definition contains the rule header "LEAPYEAR(YEAR);" and would contain local variable definitions, if there were any. The conditions determine the execution sequence. In this rule, there is only one condition, the comparison "REMAINDER(YEAR, 4)=0;". The actions are executable statements in the rule, only some of which will be executed on any particular invocation. The first action, "RETURN(`Y`);", is executed if the condition is satisfied, and the second action, "RETURN(`N`);", is executed if the condition is not satisfied. The rule in this example has no exception handlers, so there are no statements in the fourth part of the rule. Table 2 shows a more complex rule. The two GET statements verify that the month referred to by the parameter MM occurs in the table MONTHS and that the day referred to by the parameter DD is less than or equal to the maximum for that month. Failure of a GET statement causes the exception GETFAIL, and the exception handler produces a message and returns the value `N`. TABLE 2 __________________________________________________________________________ The rule VALID.sub.-- DATE VALID.sub.-- DATE (YY, MM, DD); __________________________________________________________________________ DD <= 0; Y N N LEAPYEAR (YY); Y N __________________________________________________________________________ CALL MSGLOG (`INVALID DAY ENTERED`); 1 GET MONTHS WHERE MONTH=MM & LDAYS >=DD; 1 GET MONTHS WHERE MONTH=MM & DAYS >=DD; 1 RETURN (`N`); 2 RETURN (`Y`); 2 2 __________________________________________________________________________ ON GETFAIL: CALL MSGLOG (`INVALID MONTH/DAY COMBINATION`); RETURN (`N"); __________________________________________________________________________ Table 3 shows the table MONTHS, which the rule VALID.sub.-- DATE refers to. Note the two columns for the numbers of days in a month for leap years and non-leap years. Table 4 shows a rule containing a FORALL statement. The rule COUNT.sub.-- CARS calculates the number of owners with cars of a given model and year and then prints the result (MODEL and YEAR are fields in the table CARS). The rule has no conditions. The standard routine MSLOG presents the result of the summation in the message log (the symbol .parallel. is the concatenation operator). Table 5 shows the table CARS, which the rule COUNT.sub.-- CARS refers to. TABLE 3 ______________________________________ The Table MONTHS MONTH ABBR NAME DAYS LDAYS ______________________________________ 1 JAN JANUARY 31 31 2 FEB FEBRUARY 28 29 3 MAR MARCH 31 31 4 APR APRIL 30 30 5 MAY MAY 31 31 6 JUN JUNE 30 30 7 JUL JULY 31 31 8 AUG AUGUST 31 31 9 SEP SEPTEMBER 30 30 10 OCT OCTOBER 31 31 11 NOV NOVEMBER 30 30 12 DEC DECEMBER 31 31 ______________________________________ TABLE 4 ______________________________________ The Rule COUNT.sub.-- CARS COUNT.sub.-- CARS (MDL, YY); LOCAL COUNT; ______________________________________ FORALL CARS WHERE MODEL=MDL AND 1 YEAR=YY COUNT = COUNT + 1; END; CALL MSGLOG (`RESULT:` .vertline..vertline. COUNT); 2 ______________________________________ TABLE 5 ______________________________________ The Table CARS LICENSE MODEL YEAR PRICE ______________________________________ ASD102 FIESTA 86 7599 BNM029 ESCORT 84 5559 BXT524 TAURUS 88 12099 FDS882 TEMPO 87 10099 GET347 THUNDERBIRD 57 10999 LLA498 FIESTA 87 85059 PFF356 MUSTANG 84 10599 RTY211 TORINO 85 9599 SOT963 LTD 86 15159 TDS412 THUNDERBIRD 88 35299 ______________________________________ Rule Definition The rule definition, the first part of a Huron Rule, contains a rule header (obligatory) and a declaration of local variables (optional). Rule Header The rule header gives a name to the rule and defines its parameters (if any). Parameter passing between rules is by value: a called rule cannot alter the value of a parameter. The data representation of a parameter is dynamic: it conforms to the semantic data type and syntax of the value assigned to it. The scope of a parameter is the rule in which the parameter is defined. Table 6 gives an example of a rule header. TABLE 6 ______________________________________ Rule Header for the Rule LEAPYEAR LEAPYEAR (YEAR); ______________________________________ Declaration of Local Variables Local variables are declared below the rule header. The scope of a local variable is the rule in which it is defined and any descendant rules. A local variable can be assigned an arithmetic value or a string and can be used anywhere in an action. The data representation of a local variable is dynamic: it conforms to the semantic data type and syntax of the value assigned to it. Local variables are initialized to null (i.e., zero, the logical `N`, or the null string, depending on the usage). Table 7 gives an example of a local variable declaration. TABLE 7 ______________________________________ Declaration of the Local Varibales SUM and RESULT LOCAL SUM, RESULT; ______________________________________ Conditions Conditions, which are logical expressions evaluated for their truth value, determine the flow of control in a rule. Conditions are evaluated sequentially, and, if one of them is satisfied, the actions corresponding to it are executable, and no further conditions are evaluated. If there are no conditions (as in the rule in Table 4), then the rule's actions are executable. Table 8 gives some examples of conditions. REMAINDER and SUPPLIER.sub.-- LOC are functions which return values. Although one of them is a system supplied standard routine and one is a user routine, there is no distinction in the invocation. TABLE 8 ______________________________________ Conditions CARS.PRICE > INPUT.MIN; REMAINDER (YEAR, 4) = 0; INVOICE.LOCATION = SUPPLIER.sub.-- LOC(INPUT.SUPP#); ______________________________________ Note: the example rules in earlier tables show that the part of a rule that contains conditions also contains a Y/N Quadrant, which displays Y/N ("yes/no") values. The Y/N values coordinate conditions and actions. Huron supplies the Y/N values, however, not the user. The function of the Y/N Quadrant will become clear in the section on actions. Actions An action is an executable statement. Action sequence numbers determine which actions will be executed for each particular condition. The same action can be executed for different condition. A rule, in effect, is an extended case statement. The conditions and actions can be read as follows: ______________________________________ CASE: condition 1: actions condition 2: actions . . . condition n: actions else: actions END CASE; ______________________________________ Consider the rule in Table 9, for example. The conditions and actions in the rule VALID-DATE can be read as the case statement below: __________________________________________________________________________ CASE: DD <= 0; CALL MSGLOG (`INVALID DAY ENTERED`); RETURN (`N`); LEAPYEAR (YY): GET MONTHS WHERE MONTH = MM & LDAYS >= DD; RETURN (`Y`); ELSE: GET MONTHS WHERE MONTH = MM & DAYS >= DD; RETURN (`Y`) END CASE; __________________________________________________________________________ The actions available in the rule language are described below. TABLE 9 __________________________________________________________________________ Action Sequence Numbers VALID.sub.-- DATE (YY, DD); DD <= 0; Y N N LEAPYEAR (YY); Y N __________________________________________________________________________ CALL MSGLOG (`INVALID DAY ENTERED`); 1 GET MONTHS WHERE MONTH=MM & LDAYS >= DD; 1 GET MONTHS WHERE MONTH=MM & DAYS >= DD; 1 RETURN (`N`); 2 RETURN (`Y`); 2 2 __________________________________________________________________________ ON GETFAIL; CALL MSGLOG (`INVALID MONTH/DAY COMBINATION`); RETURN (`N`); __________________________________________________________________________ Assignment Statements There are two kinds of assignment statement. In simple assignment, a single value is assigned to a field of a table or to a local variable. Table 10 shows simple assignment. TABLE 10 ______________________________________ Simple Assignment CARS.PRICE = (PRICES.BASE + PRICES.SHIPPING) TAXES.RETAIL; AMOUNT = PRINCIPAL (1 + INTEREST) ** YEARS; ______________________________________ In assignment-by-name, all the values of the fields of the table on the right are assigned to identically named fields of the table on the left. Table 11 shows an example. Assignment-by-name is a convenient way of assigning all the values of fields of a screen table to fields of a data table, or vice versa. TABLE 11 ______________________________________ Assignment-by-Name ORDERS.* = ORDER.sub.-- SCREEN.; ______________________________________ Rule Invocation A rule can invoke another rule implicitly through a logical or arithmetic expression that uses functional notation or explicitly with a CALL statement. Table 12 shows the implicit invocation of the function REMAINDER(YEAR,4), which is a standard routine that returns an integer. TABLE 12 ______________________________________ Implicit Invocation of a Rule R = REMAINDER (YEAR, 4); ______________________________________ RETURN Statement A rule is a function if it contains a RETURN statement, which specifies the result. Table 13 shows examples of RETURN statements. TABLE 13 ______________________________________ RETURN Statement RETURN (`Y`); RETURN (CARS.PRICE - REBATE); ______________________________________ CALL Statement The CALL statement can invoke a rule directly by referring to the rule by its name or indirectly by referring to a field of a table or to a parameter which contains the name of the rule. The first two examples in Table 14 invoke the rule SELECT.sub.-- RENTAL directly. Note that arguments in CALL statements can be passed by an argument list or by a WHERE clause. A parameter keyword in a WHERE clause must be the name of a parameter in the rule header of the called rule. The calls in the first two examples have identical effects, but the calls use different parameter passing mechanisms. All parameters must be specified when a rule is called. TABLE 14 ______________________________________ CALL Statement CALL SELECT.sub.-- RENTAL (NEAREST.sub.-- CAR(LOCATION)); CALL SELECT.sub.-- RENTAL WHERE RENTAL.sub.-- LOC = NEAREST.sub.-- CAR(LOCATION); CALL PFKEYS.ROUTINE; ______________________________________ The last example in Table 14 invokes a rule indirectly. The value of the field ROUTINE in the table PFKEYS is the name of the rule to be executed. Table I/O A Huron database is a collection of tables. Rules access tables on an occurrence basis. When a rule refers to a table, it creates a table template, which serves as a window to the table. Rules enter new information into the table by first placing the new data in the appropriate fields of a table template and then executing either a REPLACE or an INSERT statement. Rules retrieve information from the table into a table template with a GET statement or a FORALL statement. Rules delete information from the table by placing the information in a table template and then executing a DELETE statement (the table template is undefined after a DELETE statement). Selection Criteria For a GET, FORALL, or DELETE statement, selection criteria can be specified in a WHERE clause. The WHERE clause contains a predicate composed of one or more comparisons. The predicate is evaluated before data is placed in the table template. Table parameters can be specified in list form or in a WHERE clause (the two forms correspond to the two methods of parameter passing in the CALL statement). GET Statement The GET statement retrieves the first occurrence in a table satisfying the specified selection criteria. Table 15 gives examples. TABLE 15 ______________________________________ GET Statement GET STUDENTS; GET STUDENTS WHERE STUDENT# = `810883`; GET MONTHS WHERE MONTH = MM and DAYS >= DD; GET EMPLOYEES WHERE EMP# = INPUT.EMP; ______________________________________ In the first example of Table 15, the GET statement retrieves the first occurrence in the table STUDENTS. In the second example, the GET statement retrieves the first occurrence in the table STUDENTS whose field STUDENT# has a value equal to 810883. In the third example, the GET statement retrieves the first occurrence in the table MONTHS whose field MONTH has a value equal to the value of MM and whose field DAYS has a value greater than or equal to the value of DD. In the fourth example, the GET statement retrieves the first occurrence in the table EMPLOYEES whose field EMP# is equal to the value of the field EMP of the table INPUT. If there are no occurrences that meet the selection criteria, the GETFAIL exception is signaled. FORALL Statement The FORALL statement, which is a looping construct, processes a set of occurrences. The body of the loop consists of the statements to be executed for each occurrence satisfying the selection criteria. Nesting of FORALL statements is allowed. A FORALL statement contains a table name, an optional WHERE clause, optional ORDERED clauses, an optional UNTIL clause, and actions. A colon (:) comes after the optional clauses (or the table name, if there are no optional clauses). The actions, which comprise the body of the loop, come on separate lines after the colon. An "END;" clause, on a separate line, marks the end of the FORALL statement. Table 16 gives an example of a FORALL statement. TABLE 16 ______________________________________ FORALL Statement FORALL CARS: CALL PRINT.sub.-- CARS; END; ______________________________________ As with all table access statements, parameters can be specified in an argument list or in a WHERE clause. Selection on fields is also specified in the WHERE clause, as in Table 17. TABLE 17 __________________________________________________________________________ Selection Criteria in FORALL Statements FORALL CARS WHERE MODEL = MDL AND YEAR = YY: FORALL EMPLOYEES WHERE HIREDATE >.BIRTHDATE+40: FORALL EMPLOYEES WHERE LASTNAME LIKE `SON`: __________________________________________________________________________ A WHERE clause in a FORALL statement has the same effect as in a GET statement. In the first example of Table 17, the FORALL statement retrieves all occurrences in the table CARS whose field MODEL has a value equal to the value of MDL and whose field YEAR has a value equal to the value of YY. A WHERE clause can refer to the current table with an asterisk (). In the second example of Table 17, the FORALL statement retrieves all occurrences in the table EMPLOYEES for which the field HIREDATE has a value greater than the value of the field BIRTHDATE plus 40. A WHERE clause can contain the "partial match" operator LIKE, which allows comparison of incompletely specified data strings. Incompletely specified data strings can refer to zero or more unspecified characters with an asterisk (), and they can refer to one unknown character with a question mark (?). In the last example of Table 17, the FORALL statement retrieves all occurrences in the table EMPLOYEES in which the field LASTNAME ends in "SON". When a FORALL statement is executed, table occurrences are retrieved in primary key order, unless a different order is specified by one or more ORDERED clauses. In the example of Table 18, the occurrences will be presented sorted by descending values of the field PRICE, then by ascending values of the field MODEL, and then by ascending values of the primary key LICENSE (the default for ordering is ASCENDING). Execution of a FORALL statement will terminate under either of two circumstances: (1) all occurrences satisfying the FORALL selection criteria have been processed, or (2) an exception is detected during the execution of the statements comprising the loop. The table template is undefined at the end of a FORALL statement. Accessing CARS.MODEL after the FORALL statement in the example of Table 18 would not provide the model of the last car, but would cause the UNASSIGNED exception. TABLE 18 ______________________________________ FORALL Statement with Ordering FORALL CARS (INVOICE.CITY) ORDERED DESCENDING PRICE AND ORDERED ASCENDING MODEL: CALL $PRINTLINE (`CAR ID`.vertline..vertline.CARS.LICENSE#.vertline..ver tline. `MODEL`.vertline..vertline.CARS.MODEL.vertline..vertline.`RETAIL PRICE:$.vertline..vertline. CARS.PRICE); END; ______________________________________ INSERT Statement The INSERT statement adds a new occurrence to a table in the database. No field selection is possible: the WHERE clause can only specify parameter values. Occurrences within a table must have unique primary keys. An attempt to insert an occurrence with a primary key that already exists will cause the INSERTFAIL exception. Table 19 gives examples of the INSERT statement. Note that, in the second example, CITY is a parameter. The third example shows another way to specify the same parameter. TABLE 19 ______________________________________ INSERT Statement INSERT STUDENT; INSERT CARS WHERE CITY = INPUT.CITY; INSERT CARS (INPUT.CITY); ______________________________________ REPLACE Statement The REPLACE statement updates an occurrence in the database. No field selection is possible: the WHERE clause can only specify parameter values. If the occurrence does not exist, the REPLACEFAIL exception is signaled. In order to alto the primary key value of the occurrence, it is necessary to DELETE the old occurrence and INSERT the new one. Table 20 gives examples of the REPLACE statement. Note that, in the second example, CITY is a parameter. The third example shows another way of specifying the same parameter. TABLE 20 ______________________________________ REPLACE Statement REPLACE STUDENTS; REPLACE CARS WHERE CITY = INPUT.CITY; REPLACE CARS (INPUT.CITY); ______________________________________ DELETE Statement The DELETE statement removes an occurrence from a table in the database. A WHERE clause can specify field selection on the primary key field if the relation specified is equality. No other field selection is allowed. A WHERE clause can specify parameter values, as usual. If the primary key is specified in a WHERE clause, then that occurrence is deleted. If no primary key is specified, then the occurrence referred to by the primary key in the table template is deleted. If the occurrence does not exist in the table, the DELETEFAIL exception is signaled. Table 21 gives examples of the DELETE statement. TABLE 21 ______________________________________ DELETE Statement DELETE STUDENT; DELETE STUDENT WHERE ID = `810883`; DELETE CARS (`TORONTO`); ______________________________________ User Interface Screens are the standard user interface. They support input from a keyboard and produce output to a terminal. DISPLAY Statement The DISPLAY statement causes the specified screen to be displayed, and any input that is entered on the screen is available for processing. Table 22 gives an example of the DISPLAY statement. TABLE 22 ______________________________________ DISPLAY Statement DISPLAY CAR.sub.-- INPUT; ______________________________________ UNTIL . . . DISPLAY Statement The UNTIL . . . DISPLAY statement, which is a looping construct, displays a screen repetitively. The body of the loop consists of statements which are executed each time the screen is displayed. Inside the body of the loop, any input is available for processing. Table 23 gives an example of an UNTIL . . . DISPLAY statement. TABLE 23 ______________________________________ UNTIL . . . DISPLAY Statement UNTIL DONE DISPLAY QUERY.sub.-- SCREEN: CALL PROCESS.sub.-- QUERY; END; ______________________________________ Looping: . . . UNTIL Clause Two constructs allow looping, the FORALL statement, which can contain an UNTIL clause, and the UNTIL . . . DISPLAY statement. The statements between the FORALL part or the UNTIL . . . DISPLAY part, which is terminated with a colon (:), and the "END;" clause comprise the body of the loop. The UNTIL clause specifies one exception or two or more exceptions separated by the keyword OR. Looping terminates if an exception is detected. Table 24 gives an example of a FORALL statement with an UNTIL clause. TABLE 24 ______________________________________ FORALL . . . UNTIL Statement FORALL SRC.sub.-- TBL1 UNTIL GETFAIL: GET SRC.sub.-- TBL2 WHERE LINE.sub.-- NUM = SRC.sub.-- TBL1.LINE.sub.-- NUM; CALL CMP.sub.-- LINES (SRC.sub.-- TBL1.TEXT, SRC.sub.-- TBL2.TEXT); END; ______________________________________ If a loop terminates because of an exception, control passes to new actions as follows: If the exception is specified in an UNTIL clause for the loop, then the actions executed next will be those following the END clause of the loop (control passes to those actions even if there is an ON statement for that exception in the exception handler part of the rule). Upon completion of those actions, the rule is finished executing and control passes to the caller. Execution does NOT resume at the point where the exception was detected. If the exception is not specified in an UNTIL clause for the loop but is specified in an ON statement in the exception handler part of the rule, then the exception will be handled in the usual way: the actions executed next will be those listed in the ON statement. If the exception is not specified in an UNTIL clause for the loop or in an ON statement in the exception handler part of the rule, then the exception will be handled in the usual way: either the exception will be trapped by an exception handler in a rule higher in the calling hierarchy or the transaction will terminate. Synchronization Five statements control the synchronization of transaction, the COMMIT statement, the ROLLBACK statement, the SCHEDULE statement, the TRANSFERCALL statement, and the EXECUTE statement. COMMIT and ROLLBACK Statements The statements COMMIT and ROLLBACK establish transaction synchronization points. All or none of the changes between synchronization points will be applied to the database. Normal termination of a transaction implies COMMIT, and abnormal termination implies ROLLBACK. Table 25 shows COMMIT and ROLLBACK statements. TABLE 25 ______________________________________ COMMIT and ROLLBACK Statements COMMIT; ROLLBACK; ______________________________________ SCHEDULE Statement The SCHEDULE statement allows asynchronous processing by allowing a rule to be queued for execution independently of the current transaction. The rule to be executed must exist when the SCHEDULE statement is executed. The name of a queue can be specified by an optional TO clause. Definition of queues is handled by system parameters and is not done within the rule language. Queuing depends on the normal completion of the current transaction, that is, completion in accordance with the transaction protocol. Table 26 shows examples of SCHEDULE statements. TABLE 26 ______________________________________ SCHEDULE Statement SCHEDULE PRINT.sub.-- INVOICE ( INPUT.INVOICE# ); SCHEDULE TO WEEKEND CLEANUP WHERE LOCATION = INPUT.CITY; ______________________________________ TRANSFERCALL Statement The TRANSFERCALL statement terminates the current transaction and invokes a new one. Control does not pass back to the calling rule. When the called rule is finished executing, the transaction is complete. Like the CALL statement, the TRANSFERCALL statement can invoke a rule directly by referring to the rule by its name or indirectly by referring to a field of a table or to a parameter which contains the name of the rule. The first two examples in Table 27 invoke the rule SELECT.sub.-- RENTAL directly, and the last example invokes the rule whose name is the value of the field ROUTINE of the table PFKEYS. TABLE 27 ______________________________________ TRANSFERCALL Statement TRANSFERCALL SELECT.sub.-- RENTAL (NEAREST.sub.-- CAR(LOCATION)); TRANSFERCALL SELECT.sub.-- RENTAL WHERE RENTAL.sub.-- LOC = NEAREST.sub.-- CAR(LOCATION); TRANSFERCALL PFKEYS.ROUTINE; ______________________________________ EXECUTE Statement The EXECUTE statement invokes a descendant transaction. Control passes back to the original transaction on completion of the executed transaction. (Note that the CALL statement invokes a rule within the scope of the current transaction, but the EXECUTE statement invokes a rule that starts an independent transaction.) Like the CALL statement, the EXECUTE statement can invoke a rule directly by referring to the rule by its name or indirectly by referring to a field of a table or to a parameter which contains the name of the rule. The first two examples in Table 27 invoke the rule SELECT.sub.-- RENTAL directly, and the last example invokes the rule whose name is the value of the field ROUTINE of the table PFKEYS. TABLE 28 ______________________________________ EXECUTE Statement EXECUTE SELECT.sub.-- RENTAL (NEAREST.sub.-- CAR(LOCATION)); EXECUTE SELECT.sub.-- RENTAL WHERE RENTAL.sub.-- LOC = NEAREST.sub.-- CAR(LOCATION); EXECUTE PFKEYS.ROUTINE; ______________________________________ Exceptions: SIGNAL Statement The SIGNAL statement causes the exception specified within the statement. An ON statement or an UNTIL clause can subsequently detect and process an exception caused by the SIGNAL statement. In Table 29, the SIGNAL statement causes a user-defined exception MISSING.sub.-- INVOICE. Note: the SIGNAL statement gives the user a way to signal exceptions. The system automatically signals system exceptions such as GETFAIL or ERROR when it detects an error. TABLE 29 ______________________________________ SIGNAL Statement SIGNAL MISSING.sub.-- INVOICE; ______________________________________ Exception Handling The fourth part of a rule contains exception handlers (if there are any). ON Statement An exception handler is an ON statement that contains the name of an exception followed by a sequence of actions to be executed in the event that the exception is detected. The ON statement is in effect only during the execution of the actions of the rule in which it occurs. It will trap exceptions generated both in the rule and in any of the rule's descendants (rules which are below the rule in the calling hierarchy). If ON statements in two or more rules at different levels in the calling hierarchy can handle the same exception, the ON statement in the lowest rule handles the exception. System exceptions are hierarchically defined (the hierarchy is presented in the next section). If more than one handler within a rule can handle an exception, the most specific handler will handle it. For example, GETFAIL is lower than ACCESSFAIL in the exception hierarchy. If a rule has both a GETFAIL handler and an ACCESSFAIL handler, and a GETFAIL exception occurs, the GETFAIL handler will be invoked. If the rule has no GETFAIL handler but does have an ACCESSFAIL handler, the ACCESSFAIL handler will be invoked. In Table 30, the exception DATE.sub.-- INVALID caused by the SIGNAL statement, if it is trapped, is trapped higher in the calling hierarchy, because DATE.sub.-- INVALID is not handled in the rule CUSTINFO. The rule that called CUSTINFO, for example, might trap this exception. If the exception DATE.sub.-- INVALID is not trapped, the transaction terminates with an error condition, and the message log shows that the exception was signaled. The GETFAIL handler (ON GETFAIL CUSTOMER) will handle a GETFAIL exception if it occurs on a GET access to the table CUSTOMER when the rule VALID DATE is invoked (assuming VALID.sub.-- DATE does not provide its own handler), or if it occurs in the GET CUSTOMER statement. TABLE 30 ______________________________________ Exception Handling CUSTINFO(DATE, ID) ; ______________________________________ VALID.sub.-- DATE(DATE); Y N ______________________________________ GET CUSTOMER WHERE NAME = ID; 1 SIGNAL DATE.sub.-- INVALID; 1 ______________________________________ ON GETFAIL CUSTOMER : CALL ENTER.sub.-- CUSTOM; ______________________________________ Data access exception handlers (handlers for GETFAIL, INSERTFAIL, DELETEFAIL, REPLACEFAIL, ACCESSFAIL, and DEFINITIONFAIL) can limit their scope by specifying a table name, as in Table 30. If a table name is specified, the handler will only trap the corresponding exception if it is detected while accessing that table. If no table is specified, the handler will trap the exception regardless of what table is being accessed. The statements comprising an exception handler might cause the same exception. If this happens (and the second exception is not handled somewhere lower in the calling hierarchy), the currently executing handler will not handle the second exception. The rule executor will detect a possible "infinite loop" condition and abort the transaction. Exception Hierarchy The run time environment signals system exceptions to permit an application to recover from an error. System exceptions form a hierarchy of names. The ERROR exception will trap all detectable errors, but the GETFAIL exception will only trap a table occurrence not found on execution of a GET statement. The following diagram shows all of the system exception names with their relative position in the hierarchy. ##STR1## Three levels of exceptions are defined, and an exception will trap any of the exception names that are below it in the hierarchy. The conditions under which each of these exceptions is signaled are described below. ACCESSFAIL table access error has been detected ______________________________________ COMMITLIMIT limit on number of updates for one transaction has been reached CONVERSION value contains invalid data for syntax or cannot be converted to target syntax DATAREFERENCE error in specification of selection criteria has been detected DEFINITIONFAIL error in definition of a table has been detected DELETEFAIL key for DELETE statement does not exist DISPLAYFAIL error in displaying a screen has been detected ERROR an error has been detected EXECUTEFAIL an error in the child transaction has been detected GETFAIL no occurrence satisfies the selection criteria INSERTFAIL key for INSERT statement already exists LOCKFAIL there is a lock on an occurrence or a table is unavailable or a deadlock has occurred OVERFLOW value is too big to be assigned to target syntax REPLACEFAIL key for REPLACE statement does not exist RULEFAIL error results from arithmetic computation SECURITYFAIL permission for requested action is denied STRINGSIZE size error in assigning one string to another has been detected UNASSIGNED a field of a table that has not been assigned a value has been referenced UNDERFLOW value is too small to be represented in target syntax (mostly exponential errors) VALIDATEFAIL validation exit requested through validation exit key ZERODIVIDE attempt to divide by zero has been detected ______________________________________ Expressions, Operators, and Data Types Conditions, actions, and exception handlers contain expressions. Expressions may contain arithmetic operators and/or a string-concatenation operator. These operators conform with conventional notation, and they obey the precedence given below (exponentiation has highest precedence): ______________________________________ * exponentiation ,/ multiplication, division +,- unary +, unary - +,-,.parallel. addition, subtraction, string- concatenation ______________________________________ A sequence of arithmetic operators or string-concatenation operators of the same precedence is evaluated from left to right. Table 31 shows operators within expressions. TABLE 31 ______________________________________ Expressions (PRICES.BASE + PRICES.SHIPPING) TAXES.RETAIL PRINCIPAL * ( 1 + INTEREST) YEARS ______________________________________ Each element of an expression has a syntax and a semantic data type. The syntax describes how the data is stored, and the semantic data type describes how the element can be used. Syntax The syntax for values of a field of a table is specified in the table definition. The maximum length of the field is also specified in the table definition. Valid specifications for syntax are: B (binary) valid lengths are 2 and 4 bytes P (packed decimal) valid lengths range from 1 to 8 bytes, which can hold from 1 to 15 decimal digits the number of decimal digits is specified in the table definition F (floating point) valid lengths are 4, 8, and 16 bytes, for a primary key field, or from 1 to 256 bytes for other fields C (fixed length character string) valid lengths range from 1 to 128 bytes, for a primary key field, or from 1 to 256 bytes for other fields V--variable length character string valid lengths range from 3 to 128 bytes, for a primary key field, or from 3 to 256 bytes for other fields storage is reserved for the length specified, but string operations use the current length Semantic Data Types The semantic data type for values of a field of a table is specified in the table definition. The semantic data type determines what operations can be performed on values of the field. Operators in the language are defined only for meaningful semantic data types. For example, negating a string or adding a number to an identifier are invalid operations (consider adding 3 to a license plate number). Valid semantic data types and their permitted syntax are: I (identifier) C (fixed length character string) V (variable length character string) B (binary) P (packed decimal) S (string) C (fixed length character string) V (variable length character string) L (logical) C (fixed length character string of length 1) Possible values: Y (yes) N (no) C (count) C (fixed length character string) V (variable length character string) B (binary) P (packed decimal with no decimal digits) Q (quantity) C (fixed length character string) V (variable length character string) B (binary) P (packed decimal) F (floating point) Comparison Operators The rule language contains the following operators for making comparisons: = < <= > >= Note the following points about semantic data types in expressions containing these operators: The relational operators for equality and inequality (=, =) allow any two operands of the same semantic data type. These operators allow two operands of different semantic data types if the types are identifier and string or identifier and count. The relational operators for ordering (<, <=, >, >=) allow any two operands of the same semantic data type except logical. Values of type logical are not permitted in comparisons which involve ordering. Trailing blanks are significant for variable length strings, but not for fixed length strings. For example, comparison of two fixed length strings X and Y with lengths 12 and 16 will have the same result as if the shorter string X had been padded with four blanks on the right. If syntax differs, operands are converted to a common syntax. The result of a comparison is always a logical value (`Y` or `N`). The Assignment Operator The rule language uses the equal sign (=) as the assignment operator. Note the following points about semantic data types in expressions containing this operator: A value of any semantic data type can be assigned to a field of the same semantic data type. A value of type identifier can be assigned to a field of type count (and vice versa). A value of type identifier can be assigned to a field of type string (and vice versa). A value of type string can be assigned to a field of type quantity (and vice versa). A value of type string can be assigned to a field of type count (and vice versa). Arithmetic Operators The rule language contains the following operators for doing arithmetic: I / + The arithmetic operators allow two operands in these combinations: count and count quantity and quantity count and quantity The Concatenation Operator the rule language uses a double vertical bar (.parallel.) as the concatenation operator. The concatenation operator is valid between any two semantic data types, and the result is always a variable length string. Indirect Table and Field References To assist the coding of generic routines and utility functions, the rule language permits indirect references to table and field names. The rule COUNT in Table 32 is a generic routine that determines the sum of a field over all occurrences. This rule generalizes the rule COUNT.sub.-- CARS in Table 4 so that it sums any field of any table (more precisely, any table without parameters): it receives the name of the table in the parameter TABLEREF, an it receives the name of the field in the parameter FIELDREF. The parentheses around the names TABLEREF and FIELDREF signify indirection. The FORALL statement in the rule COUNT shows the two kinds of indirect reference. First, the FORALL statement loops over the table specified by the indirect table reference "(TABLEREF)" Second, the action in the body of the loop involves the field specified by the indirect field reference "(FIELDREF)". Suppose that the rule is call in this way: CALL COUNT(`PARTS`,`PRICE`) The value of TABLEREF will be `PARTS`, the value of FIELDREF will be `PRICE`, and the call will find the sum of the prices of all parts. TABLE 32 ______________________________________ Indirect References. The example invocations and their results show how indirect references can generalize a rule. COUNT(TABLEREF, FIELDREF); LOCAL SUM; ______________________________________ ______________________________________ FORALL TABLEREF 1 SUM = SUM + (TABLEREF).(FIELDREF) ; END; ##STR2## 2 ______________________________________ Example Invocation: CALL COUNT(`CARS`, PRICE`); Resulting printline: THE SUM OF CARS PRICE IS: 5690230.19 Example Invocation: CALL COUNT(`PARTS`, `QUANTITY`); Resulting printline: THE SUM OF PARTS QUANTITY IS: 6750 ______________________________________ Syntax A complete, formal syntax of the rule language in Backus-Naur Form (BNF) follows. BNF Notation (a) Lower case words enclosed in angle brackets, < >, denote syntactic categories. For example: <start character> (b) In a list of alternatives each alternative starts on a new line. (c) A repeated item is enclosed in braces, { }. The item may appear zero or more times. For example: {<digit>} (d) Optional categories are enclosed in square brackets, [ ]. For example: [<exponent>] Character Set All rule language constructs are represented with a character set that is subdivided as follows: (a) letters A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (b) digits 0 1 2 3 4 5 6 7 8 9 (c) special characters @ # $ .vertline. & * () - .sub.-- = + ; : ` , . / < > Lexical Elements A rule is a sequence of lexical elements. Lexical elements are identifiers (including reserved words), numeric literals, string literals and delimiters. A delimiter is one of the following special characters .vertline. & * () - + = : ; ` , / < > or one of the following compound symbols II <= >= = .parallel. Adjacent lexical elements may be separated by spaces or a new line. An identifier or numeric literal must be separated in this way from an adjacent identifier or numeric literal. The only lexical element which may contain a space is the string literal. String literals may span more than one line; all other lexical elements must fit on a single line. Identifiers Rule language identifiers may not exceed 16 characters in length. ______________________________________ <identifier> ::= <start character> { <follow character> } <start character> ::= A B C D E F G H I J K L M N 0 P Q R S T U V W X YZ@#$ <follow character> ::= <start character> <digit> <digit> ::= 0 1 2 3 4 5 6 7 8 9 ______________________________________ Numeric Literals The rule language supports the following forms of numeric literals: ______________________________________ <numeric literal> ::= <digits> [ . <digits> ] [ <exponent>] <digits> ::= digit { <digit> } <digit> ::= 0 1 2 3 4 5 6 7 8 9 <exponent> ::= E [ <sign> ] <digits> <sign> ::= .+-. ______________________________________ String Literals A string literal is zero or more characters enclosed in single quotes: ______________________________________ <string literal> ::= ` { <character> } ` ______________________________________ Single quotes within a string literal are written twice. Thus the following string literal is a single quote ````. Reserved Words The following list of names are reserved by the system as key words in the rule language. ______________________________________ AND ASCENDING CALL COMMIT DELETE DESCENDING DISPLAY END EXECUTE FORALL GET INSERT LOCAL NOT ON OR ORDERED REPLACE RETURN ROLLBACK SCHEDULE SIGNAL TO TRANSFERCALL UNTIL WHERE LIKE Syntax of Rules <rule> ::= <rule declare > <cond list> <action list> <exception list> <rule declare> ::= <rule header> [ <local name declaration> ] <rule header> ::= <rule name> [ <rule header parm list> ] ; <rule header parm list> ::= ( <rule parameter name> { , <rule parameter name> } ) <local name declaration> ::= LOCAL <local name> { , <local name> } ; <cond list> ::= { <condition> ; } <condition> ::= logical value> NOT <logical value> <expression> <relop> <expression> <logical value> ::= <field of a table> <rule parameter name> <function call> <action list> ::= <action> { <action> } <exception list> ::= { <on exception> } <on exception> ::= ON <exception designation> : { <action> } <action> ::= <statement> ; <statement> ::= <assigment> <rule call> <function return> <table access stmt> <sync processing> <display processing> <signal exception> <asynchronous call> <iterative display processing> <assignment> ::= <assignment target> = <expression> <assign by name> <assignment target> ::= <field of a table> <local name> <assign by name> ::= <table ref> .* = <table ref> .* <rule call> ::= CALL <call spec> [ <call arguments> ] <call spec> ::= <rule name> <rule parameter name> <table name> . <field name> <call arguments> ::= <arg list> WHERE <where arg lists> <where arg lists> ::= <where arg istem> { <and> <where arg item> } <where arg item> ::- <identifier> = <expression> <function return> ::= RETURN ( <expression> ) <table access stmt> ::= <get stmt> <insert stmt> <replace stmt> <delete stmt> <forall stmt> <get stmt> ::= GET <occ spec> <occ spec> ::= <table spec> [ WHERE <where predicate> ] <table spec> ::= <table name> [ <arg list> ] <rule parameter name> [ <arg list> ] <table name> . <field name> [ <arg list> ] <where predicate> ::= <where nexpr> { <logical op> <where nexpr> } <where nexpr> ::= { <not> } <where expr> <where expr> ::= <where relation> ( <where predicate> ) <where relation> ::= <fieldname> <relational op> <where expression> <where expression> ::= [ <unary op> ] <where expr term> { <add op> <where expr term> } <where expr term> ::= <where expr factor> { <mult op> <where expr factor> } <where expr factor> ::= <where expr primary> [ <exp op> <where expr primary> ] <where expr primary> ::= ( <where expression> ) <where field of a table> <rule parameter name> <local name> <function call> <constant> <where field of a table> ::= <where table ref> . <field ref> <where table ref> ::= * <table name> ( <rule parameter name> ) ( <table name> . <field name> ) Notice that the <where table ref> production allows a "" to be specified as the table name. <insert stmt> ::= INSERT <table spec> [ WHERE <where arg list> ] <replace stmt> ::= REPLACE <table spec> [ WHERE <where arg list> ] <delete stmt> ::= DELETE <table spec> [ WHERE <where arg list> ] <forall stmt> ::= FORALL <occ spec> [ <table order> ] [ <until clause> ] : <for alist> END <until clause> ::= UNTIL <exceptions> <exceptions> ::= <exception designation> {<or> <exception designation>} <exception designation> ::= <exeption name> [ <table name> ] <exception name> ::= <identifier> <for alist> ::= { <for action> ; } <for action> ::= <assignment> <rule call> <table access stmt> <display processing> <asynchronous call> <iterative display processing> COMMIT <table order> ::= <table order item> { AND <table order item> } <table order item> ::= ORDERED [ <ordering> ] <field name> <ordering> ::= ASCENDING DESCENDING <order clause> ::= ORDER <order item> {<and> <order item>} <order item> ::= ORDERED <fieldname> ORDERED ASCENDING <fieldname> ORDERED DESCENDING <fieldname> <sync processing> ::= COMMIT ROLLBACK <display processing> ::= DISPLAY <screen ref> <screen ref> ::= <screen name> <table name> . <field name> <rule parameter name> <screen name> ::= <identifier> <signal exception> ::= SIGNAL <exception name> <asynchronous call> ::= SCHEDULE [<queue spec>] <rule name> [<call arguments>] <queue spec> ::= TO <expression> <iterative display processing> ::= UNTIL <exceptions> <display processing> : {<action>} END <field ref> ::= <field name> ( <rule parameter name> ) ( <table name> . <field name> ) <function call> ::= <function name> [ <arg lists> ] <arg list> ::= ( <expression> { , <expression> } ) <expression> ::= [ <unary op> ] <expr term> { <add op> <expr term> } <expr term> ::= <expr factor> { <mult op> <expr factor> } <expr factor> ::= <expr primary> [ <exp op> <exp primary> ] <expr primary> ::= ( <expression> ) <field of a table> <rule parameter name> <local name> <function call> <constant> <field of a table> ::= <table ref> . <field ref> <table ref> ::= <table name> ( <rule parameter name> ) ( <table name> . <field name> ) <rule name> ::= <identifier> <function name> ::== <identifier> <rule parameter name> ::= <identifier> <table name> ::= <identifier> <field name> ::= <identifier> <local name> ::= <identifier> <unary op> ::= - + <add op> ::= + - .parallel. <mult op> ::= / <exp op> ::= ** <logical op> ::= <and> <or> <and> ::= AND & <or> ::= OR .sup. .vertline. <not> ::= NOT <relational op> ::= <rel op> LIKE <rel op> ::= = = > >= < <= <constant> ::= <string literal> <numeric literal> ______________________________________ III. Table Data Store The table data store stores data in relational tables according to the unique table data structure. This structure can best be understood by understanding how tables are built through the table access machine. HURON's logical access method to retrieve and access tables is the Table Access Method (TAM) HURON provides access to other heterogeneous databases. This facility is transparent to the user once the data definition has been done. TAM acts as a traffic cop in conjunction with the transaction processor to access the correct server--resident in other regions The physical access method and data organization is the TDS (Table Data Store) Data Stores are in a B+ Tree relational data structure Since HURON is a transaction system, a user's access to a large amount of data will only affect their dependent region. Defining a TDS table Table Definer is invoked using a command DT <table name> from a work bench menu or a primary command line produced by a session manager routine. The screen layout of the Table Definer is set out in Table 33. Standard naming conventions can be followed for the table name. The default table type is TDS. Other table types are available such as IMS, IMPORT--EXPORT (sequential) etc. Each table type has its own table definition screen in the session manager. Tables are universal to a system. The Security system on individual tables prevents unauthorized access to the definition and/or data. The syntax specifications of parameters and fields describe how the data is stored. The semantic specifications describe how the data should be used in applications. Event processing can be invoked at data definition time, however the actual rules are coded using the generalized programming language. The event processing is invoked when the data is accessed. TABLE 33 __________________________________________________________________________ Define Table - Screen Layout DT EMPLOYEE COMMAND==> TABLE DEFINITION TABLE:EMPLOYEE TYPE:TDS UNIT:educ IDGEN:N PARAMETER NAME TYPE SYNTAX LENGTH DECIMAL EVENT RULE TYPE ACCESS __________________________________________________________________________ USERID I C 16 FIELD NAME TYPE SYNTAX LENGTH DECIMAL KEY REQ DEFAULT __________________________________________________________________________ EMPNO I P 3 0 P LNAME S C 22 0 POSITION S C 14 0 MGR# I P 3 0 DEPTNO i B 2 0 SALARY Q P 3 2 HIREDATE S C 9 0 ADDRESS S V 40 0 CITY S C 20 0 PROV S C 3 0 P.sub.-- CODE S C 7 0 PFKEYS:3=SAVE 12=CANCEL 22=DELETE 13=PRINT 21=EDIT 2=DOC __________________________________________________________________________ 6=RETRIEVE The fields of the Define Table--Screen Layout are discussed below, except for obvious ones. ______________________________________ TYPE: The table type specifies the access method. Table Data Store (`TDS`) is the default value and is used as the reference template. Each table type has an associated template for display. When the table type is changed, the corresponding template is displayed by pressing any of the function keys or the ENTER key. Valid table types include `TEM` (temporary), `IMP` (import), `EXP` `EXP` (export), (IMS) and others defined by a user. UNIT: The user unit the table is associated with is entered in this field. Valid units are provided by the database administration. IDGEN: This informs the system that it is resposible for providing unique primary keys for each occurrence. PARAMETER: The parameter information component is a scrollable area for multiple entries. A maximum of four entries are allowed. This feature allows the system to partition its databases based on a unique field. This mimics a hierarchial structure of data which is more common in the real world than truly relational. NAME The field name which should be unique within the table. TYPE The sematic type - application design control. SYNTAX The internal representation for storage. LENGTH The length in bytes. The system stores its' data as variable length data to optimize storage. DECIMAL If specified, it indicates the number of digits to the right of the decimal point. KEY The valid entry is `P` for primary, and blank (non-key field). A table must have one field defined as its primary key. The primary key specification effectively makes the field a required one. Each occurrence in the table is uniquely identified by its primary key value. RQD The default value for this filed is blank (not required). Other valid entries are `Y` for required or `N` for not required. Inserting or editing an occurence without proper values in the required fields is not allowed. DEFAULT The default value of the field, this will be input if the filed is left blank when a new occurrence is being added. ______________________________________ Semantic Data Type and Syntax All fields of a table are bound to a semantic data type and syntax. The syntax describes how the data is stored while the semantic type describes how a field may be used. Valid semantic data types and their permitted syntaxes are: I--identifier C fixed length character string V variable length character string P packed decimal B binary S--string C fixed length character string V variable length character string L--logical C fixed length character string of length 1 value of "Y" for yes value of "N" for no C--count C fixed length character string V variable length character string B binary P packed decimal with no decimal digits Q--quantity C fixed length character string V variable length character string B binary P packed decimal F floating point Valid Field Syntaxes Specifications B--binary valid lengths are 2 and 4 bytes P--packed decimal length may range from 1 to 8 bytes which can hold 1 to 15 decimal digits number of decimal digits may be specified F--floating point valid lengths are 4, 8, and 16 bytes corresponding to 24, 56, and 112 binary digits of precision C--fixed length character string valid lengths range from 1 to 128 bytes for a primary key field and 1 to 256 bytes for other fields. results in uppercase characters V--variable length character string valid lengths range from 3 to 128 bytes for a primary key field and 2 to 256 bytes for other fields. storage is reserved for the maximum length possible for the string, however string operations use the current length results in upper/lower case Table Documentation Documentation is associated with all objects including tables. Users can specify a short summary, keywords and a long description to document any tables defined, using a documentation screen as shown in TABLE 34 invoked from the table definer. The summary is limited to one line of information. The keywords specified can be made available for use by the keyword search facility. There is space available to provide a detailed table description. Script formatting commands can be included in the long description. Documentation TABLE 34 ______________________________________ DOCUMENTATION SCREEN FOR THE EMPLOYEE TABLE DESCRIPTION OF TABLE:employee UNIT: educ MODIFIED ON: BY: CREATED ON:88.181 BY:educ KEYWORDS: EDUCATION,EMPLOYEE SUMMARY: Table of employees parameterized by USERID DESCRIPTION: ______________________________________ This table contains employee information The education department is responsible for its contents and has designed USERID as a parameter in order to provide each course participant with a copy of the table. PFKEYS: 3=EDIT OBJECT 5=EDIT/VIEW DOCUMENT ______________________________________ Subview Tables Subviews provide windows on corporate data. Users can be given a subset of the fields of a table or a subset based on selection criteria. The Table definer is invoked using a DT <subview table name> command from the workbench menu or the command line on the screen. Standard naming conventions are followed for the subview table name. The subview table definer screen is invoked by changing the default table type "TDS" to "SUB", resulting in a definer screen as shown in TABLE 35. The Security system on individual subviews prevents unauthorized access to the definition and/or use. There is no separate space allocated for a subview. All data maintenance is actually carried out on the associated source TDS table. TABLE 35 __________________________________________________________________________ Screen layout of a subview table DT SUB.sub.-- TABLE COMMAND==> TABLE DEFINITION TABLE:SUB.sub.-- TABLE TYPE:SUB UNIT:educ SOURCE:EMPLOYEE SELECT:USERID = `EDUC` & DEPTNO = 10 PARAMETER NAME TYPE SYN LEN DEC SOURCE PARM ORDER FIELD SEQ __________________________________________________________________________ FIELD NAME TYP SYN LEN DEC KEY REQ DEFAULT SRC SOURCE NAME __________________________________________________________________________ EMPLOYEENO I P 3 0 P S EMPNO LNAME S C 22 0 POSITION S C 14 0 S MGR# MANAGERNO I P 3 0 DEPTNO I B 2 0 PFKEYS: 3=SAVE 12=CANCEL 13=PRINT 15=SAVEON 21=EDIT 22=DELETE 6=RETRIEVE 2=DOC TABLE TYPE CHANGED (PF6 GETS BACK ORIGINAL DEFN). __________________________________________________________________________ General Discussion--SUBVIEWS All fields are the same as described for the `TDS` table, Fields unique to the subview are described below. SOURCE: Name of the source table whose subview is defined by this table. The source table must exist before its subview can be defined. SELECT: The scope of the selection criteria is to subgroup the number of occurrences selected. If not present, all occurrences will be selected. PARAMETERS: New parameters can be specified in the subview if there is a corresponding field in the TDS table. Source table parameters can be renamed and the source name specified in the SOURCE PARM. ORDERING: This is a scrollable area. Ordering can be specified on a field that is not defined in the subview. Ordering is only used for display purposes. SEQ--A(scending) or D(escending) Field Definition--Subviews SRC: This is the source indicator field. Fieldnames can be the same, renamed or unique to the subview table. The source indicator field identifies the status of the field in relation to the source table. Valid entries are: Blank Field definition in both source and subview are the same. S=Source: A renamed field is indicated with this entry followed by the field name in the source table D=Derived: A field unique to the subview table is indicated by this entry as a derived field. The source of a derived field ought to be a functional rule which returns a value for this field. Applicational Applicational advantages of this feature allows for table manipulations and ad hoc reporting on a subview table level. In ADHOC processing the derived fields receive values when the table is accessed. For example, when editing the table: ED (table name) Event Rules Event Rules within data definition are commonly made up of a mixture of either validations or triggers. Validations are rules such as, when information is entered into a table, that data must be validated against another table. For example, when maintaining the employee table, the department number has to be in the departments table. This could extend to a series of other tables or external files. Triggers cause actions to happen rather than just verification, such as audit trails, updating of other tables or scheduling of other jobs. With event rules, a user is provided a completely "open" environment, where rigorous checks and controls can be implemented on data. ______________________________________ Definition of Event Rules: The event rules section is a scrollable portion Event rules are coded in execution order Event rules can be defined for specific data access codes, such as insert or more generally- get and write Different event rules can be invoked on the same action - ##STR3## If a data maintenance action is invoked - such as insert or update then write will also be invoked. The event rule that should be executed can be tested from a local library, but would reside in the site library at production time. In the event that a test is required using for example the Table Editor then the workbench function cannot be used if the rule is in a local library. To force the search path to access the local library execute the Table Editor as if it was a rule: EX =====> STE(`table name(parameters)`) or Command line ===> EX STE(`tablename(parameters)`) When coding the event rule remember that the occurrence of the table has already been obtained no data access is required for that table. When coding the event rule the following has to be true: TRIGGERS - subroutines VALIDATIONS - functions returning `Y`, `N` or a message if not `Y` ______________________________________ Example of an Event Rule--Validation In defining the Employee table there was the following constraint: All employees had to have the department number validated. The validation had to be done against the DEPARTMENTS table. The department data consisted of a department number and a department name. The definition of the EMPLOYEE table had to change to reflect that a validation rule DEPT.sub.-- CHK was to be executed anytime any type of maintenance was performed. The changed EMPLOYEE table with event rule DEPT.sub.-- CHK is shown in TABLE 36. TABLE 36 __________________________________________________________________________ COMMAND==> TABLE DEFINITION TABLE:EMPLOYEE TYPE:TDS UNIT:PER IDGEN:N PARAMETER NAME TYPE SYNTAX LENGTH DECIMAL EVENT RULE TYPE ACCESS __________________________________________________________________________ USERID I C 100 DEPT.sub.-- CHK V W FIELD NAME TYPE SYNTAX LENGTH DECIMAL KEY REQ DEFAULT __________________________________________________________________________ EMPNO I P 3 0 P LNAME S C 22 0 POSITION S C 20 0 MGR# I P 3 0 DEPTNO C B 2 0 SALARY Q P 4 2 HIREDATE S C 9 0 ADDRESS S V 80 0 CITY S C 20 0 PROV S C 3 0 P.sub.-- CODE S C 7 0 PFKEYS:3=SAVE 12=CANCEL 22=DELETE 13=PRINT 21=EDIT 2=DOC __________________________________________________________________________ 6=RETRIEVE An example of the rule DEPT.sub.-- CHK would appear as in TABLE 37. TABLE 37 __________________________________________________________________________ ##STR4## __________________________________________________________________________ Example of an Event Rule--Trigger The Employee table modified to include the trigger EMP.sub.-- AUDIT is shown in TABLE 38. To provide an audit trail of the people that update the employee table, an output table will be created. This table EMP.sub.-- AUDIT will contain information about the user and also the values of the important fields such as salary. Change the definition to force an audit entry to be written every time the employee table is maintained. TABLE 38 __________________________________________________________________________ Additional Event Rule for the employee table COMMAND==> TABLE DEFINITION TABLE:EMPLOYEE TYPE:TDS UNIT:PER IDGEN:N PARAMETER NAME TYPE SYNTAX LENGTH DECIMAL EVENT RULE TYPE ACCESS __________________________________________________________________________ USERID I C 100 DEPT.sub.-- CHK V W EMP.sub.-- AUDIT T W FIELD NAME TYPE SYNTAX LENGTH DECIMAL KEY REQ DEFAULT __________________________________________________________________________ EMPNO I P 3 0 P LNAME S C 22 0 POSITION S C 20 0 MGR# I P 3 0 DEPTNO C B 2 0 SALARY Q P 4 2 HIREDATE S C 9 0 ADDRESS S V 80 0 CITY S C 20 0 PROV S C 3 0 P.sub.-- CODE S C 7 0 PFKEYS:3=SAVE 12=CANCEL 22=DELETE 13=PRINT 21=EDIT 2=DOC 6=RETRIEVE __________________________________________________________________________ The table to hold the audit trail information would have the definition shown in TABLE 39. TABLE 39 __________________________________________________________________________ COMMAND==> TABLE DEFINITION TABLE:EMPLOYEE TYPE:TDS UNIT:PER IDGEN:Y PARAMETER NAME TYPE SYNTAX LENGTH DECIMAL EVENT RULE TYPE ACCESS __________________________________________________________________________ FIELD NAME TYPE SYNTAX LENGTH DECIMAL KEY REQ DEFAULT __________________________________________________________________________ AUDIT.sub.-- NO I B 4 0 P USERID S C 8 0 TRAN.sub.-- DATE S C 8 0 TRAN.sub.-- TIME S C 8 0 EMPNO I P 3 0 LNAME S C 22 2 DEPTNO C B 2 0 SALARY Q P 4 2 PFKEYS:3=SAVE 12=CANCEL 22=DELETE 13=PRINT 21=EDIT 2=DOC 6=RETRIEVE __________________________________________________________________________ Note that this table will use an automatically generated key. An example of the rule EMP.sub.-- AUDIT would appear as shown in TABLE 40. TABLE 40 __________________________________________________________________________ ##STR5## __________________________________________________________________________ SUBVIEWS--Derived Fields SUBVIEWS can consist of a view of existing data. It can also consist of derived fields. The definition of the subview template provides a space as mentioned before for defining the source and the source name. The source can be `S` To provide an alternate name for a field from the base table. The source name must be the name from the base table. However, if the source is defined as `D` To provide a derived field using information from the base table. The source name must be the rule to be executed whenever the subview is accessed. When the subview provides source rules to be executed, these rules are functions returning one value. These rules are unlimited in their function similar to event rules. Similarly, these rules already know the current occurrence of the associated table--no data access against that table is required. The information on derived fields is never stored and therefore cannot be updated. Similar to the event rules--a search of the local library has to be forced in a testing environment. These rules would exist in the site library normally. (Please refer to event rules section). The Event rules for the base table are still in effect for the subview. Additional security can be placed on a subview over the base table. The following example of an event rule validation illustrates used of Derived fields. Request by manager of department 10 Only his employees Only certain fields Interested in how his staff could benefit from the new Employee Savings program that the company had introduced. With this in mind, a subview was created to satisfy the manager's request. Two derived fields were added to calculate the employee's length of employment and the amount that the employee could save. These fields are good choices for derived fields because the length of employment increases daily and the savings amount is a calculation based on that data and the salary. Therefore if the salary changes and the length of employment is always changing, this field is too dynamic to store on a database. The layout of the subview file is shown in TABLE 41. TABLE 41 __________________________________________________________________________ DT EMPLOYEE.sub.-- SUB COMMAND==> TABLE DEFINITION TABLE:EMPLOYEE.sub.-- SUB TYPE:SUB UNIT:EDUC SOURCE:EMPLOYEE SELECT:DEPTNO = 10 PARAMETER NAME TYPE SYN LEN DEC SOURCE PARM ORDER FIELD SEQ __________________________________________________________________________ USERID I C 100 0 FIELD NAME TYPE SYN LEN DEC KEY REQ DEFAULT SRC SOURCE NAME __________________________________________________________________________ EMPLOYEENO I P 3 0 P S EMPNO LNAME S C 22 0 HIREDATE S C 9 0 MANAGERNO I P 3 0 S MGR# DEPTNO I B 2 0 LGTH.sub.-- EMPLOY I B 4 0 D LGHT.sub.-- EMPLOY EMP.sub.-- SAVINGS I B 4 0 D EMP.sub.-- SAVINGS PFKEYS:3=SAVE 12=CANCEL 13:PRINT 15:SAVEON 21=EDIT 22=DELETE 6=RETRIEVE 2=DOC __________________________________________________________________________ An example of the rule LGTH.sub.-- EMPLOY to calculate the length of employment would appear as shown in TABLE 42. TABLE 42 __________________________________________________________________________ ##STR6## __________________________________________________________________________ The difference between the two dates--HIREDATE and today's date would be obtained using the function DATE.sub.-- DIFFERENCE. This value is then returned anytime the data is access through this subview. An example of the rule EMP.sub.-- SAVINGS would appear as shown in TABLE 43. TABLE 43 __________________________________________________________________________ ##STR7## __________________________________________________________________________ A decision has to be made based on the length of employment: Employment a year or more then the employee is eligible to use the plan. Calculation--6 Percent of the annual salary (52 weeks) Less than that--no eligibility amount is zero. Changing a Table Definition Changing a table definition is allowed if the table is not populated. If the table is populated, then some restrictions apply, which will be caught by the Table Definer. Any new fields must be added to the end of the previous ones Field lengths can be made longer, but should not be shortened Some syntaxes do not allow modification Semantic constraints can be changed Table Definition Command Summary 1. Line Commands The leftmost column of the screen is reserved for entering line commands. A line command is entered by placing the first letter of the command in the command space on the line. All line commands are processed when a function key or the ENTER key is pressed. I--INSERT AFTER THIS LINE D--DELETE THIS LINE R--REPLICATE THIS LINE C--COPY THIS LINE M--MOVE THIS LINE A--DESTINATION OF MOVE/COPY AFTER THIS LINE B--DESTINATION OF MOVE/COPY BEFORE THIS LINE The destination of a MOVE or COPY command is determined from either an explicit destination "A" for after or "B" for before, or an implicit destination (the line after the current cursor position). 2. Primary Commands and Function Keys The primary commands are entered in the area provided on the first line of the screen. Most primary commands have corresponding function keys for user convenience. Following is a list of PF keys and their functions and associated primary commands: ______________________________________ PF Key Command Summary ______________________________________ PF1 HELP. PF2 DOC DOCUMENTATION FOR THIS TABLE PF3 SAVE SAVE THE DEFINITION AND LEAVE THE DEFINE TABLE. PF6 RETRIEVE COMMENCES A NEW SESSION BY RETRIEVING THE DEFINITION OF THE NAMED TABLE PF7 SCROLL UP IN THE RULE PF8 SCROLL DOWN IN THE RULE PF9 REDISPLAY PREVIOUS PRIMARY COMMAND PF12 CANCEL LEAVE THE TABLE DEFINE WITHOUT SAVING CHANGES PF13 PRINT PRINT THE DEFINITION PF15 SAVEON SAVE AND CONTINUE PF22 DELETE DELETE THE DEFINITION AND EXIT COPY APPEND THE DEFINITION OF A NAMED TABLE PF21 EDIT SAVE THE DEFINITION & BEGIN AN STE SESSION ______________________________________ Screen Definition Facilities of the Screen Definer The HURON Screen Definer is invoked from the workbench. A screen is made up of various screen tables. Screen tables are unique to the system and are shareable between screens. The Screen Definer consists of two separate functions. (1) The screen definition--which screen tables should be used. (2) Painting the screen tables and defining the fields within the screen table. Screen tables have no stored representation in the data store and are temporary tables within the user's environment. Screen tables are manipulated using the same data access commands in the rules language specifications as all other tables. Screen Definition Screen definition is invoked by a PS <screen name> command. This results in a layout screen as shown in TABLE 44. The screen name is unique to the system. The screen definition provides for default keys and will automatically perform scrolling for the user. A screen can be viewed by pressing PF21, any validation rules or require fields can be entered at this time to test validation--without the user having written a DISPLAY command in the rules language. PF12--the default validation exit will provide an exit if the validation rules cannot be met. If the user provides a fieldname from a screen table within the SCROLL AMOUNT ENTRY area then HURON will allow scrolling values such as M--maximum, P--page, etc., to be invoked without any further coding. The user can control the initial cursor position. Default PFkeys can be modified to meet the user's standards. TABLE 44 __________________________________________________________________________ HURON BUILD SCREEN: employee.sub.-- expense UNIT: acc PF KEYS SCROLL AMOUNT ENTRY DEFAULT CURSOR POSITION __________________________________________________________________________ UP:7 DOWN:8 TABLE: TABLE: expense.sub.-- data LEFT:10 RIGHT:11 FIELD: FIELD: employee# VALIDATION EXIT:12 HELP:1 REFRESH:24 SCREEN TABLES FOR EMPLOYEE.sub.-- EXPENSE ORIGIN MAX VALIDATION FIX NAME ROW: COL: OCCUR: SCROLL: RULE: TITLE: FOOTING COL __________________________________________________________________________ acct.sub.-- title 1 1 1 n expense.sub.-- data 5 5 5 y AUTHORIZE 2 PFKEYS: 2=DOCT 6=PAINT 9=DEFHLP 13=PRINT 16=EXCLD 19=DUP 21=DISPLAY __________________________________________________________________________ Screen Definitions Command Summary Following is a list of PF keys and their functions: ______________________________________ PF Key Function Summary ______________________________________ PF1 Help HELP ON SCREEN DEFINITION. PF2 Document DOCUMENTATION FOR THIS SCREEN. PF3 Save SAVE THE DEFINITION AND EXIT. PF6 Paint SAVE AND CALL THE SCREEN PAINTER FOR THE TABLE AT CURSOR POSITION. PF7 SCROLL UP. PF8 SCROLL DOWN. PF9 Define HELP DEFINE HELP SCREEN TO BE ASSOCIATED WITH THIS SCREEN. PF12 Cancel EXIT THE FACILITY WITHOUT SAVING CHANGES. PF13 Print PRINT THE SCREEN. PF16 Exclude EXCLUDE THE TABLE THE CURSOR IS ON. PF19 Duplicate DUPLICATE THE LINE THE CURSOR IS ON. PF21 Display DISPLAY THE SCREEN. PF22 Delete DELETE THE DEFINITION AND EXIT. ______________________________________ Painting Screen Tables The screen table painter has two portions: the actual painting of the screen; and the definition of the fields and attributes. The layout screen is shown in TABLE 45. Screen table names are unique to the system. Screen tables are not directly associated with any data tables. Painting the screen tables is very flexible, and free format. The user is provided the ability to copy the fieldnames from an existing data table, if required. Validation rules can be associated with each screen table, as opposed to just the screen. This provides sharing for validation rules as well. The features of the screen table painter provide a great deal of flexibility, such as moving the positions of fields, deleting lines, easy online help screens etc. TABLE 45 __________________________________________________________________________ Screen Table Painter CUSTOMER INFORMATION ##STR8## __________________________________________________________________________ ##STR9## __________________________________________________________________________ ##STR10## ##STR11## __________________________________________________________________________ Screen Painter Command Summary Following is a list of PF keys and their functions: ______________________________________ PF Key Function Summary ______________________________________ PF1 Help HELP ON SCREEN DEFINITION. PF2 Document DOCUMENT FOR THE SCREEN TABLE. PF3 Save SAVE THE DEFINITION AND EXIT. PF4 Add line INSERT A LINE AFTER THE CURSOR. PF5 Cut field CUT & HOLD THE FIELD AT CURSOR. PF6 Add field ADD A FIELD AT THE CURSOR PF7 SCROLL UP. PF8 SCROLL DOWN. PF12 Cancel EXIT THE FACILITY WITHOUT SAVING CHANGES. PF13 Print PRINT THE SCREEN. PF16 Delete line DELETE THE LINE THE CURSOR IS ON. PF17 Paste field RELEASE A CUT FIELD & POSITION AT THE CURSOR POSITION. PF18 Del field DELETE THE FIELD THE CURSOR IS ON. PF19 Copy COPY THE NAMED TABLE DEFINITION. PF22 Delete DELETE THE DEFINITION AND EXIT. ______________________________________ IV. Dictionary Data All data within the HURON data processing machine is stored according to the table access machine, either directly in the table data store or virtually in other data storage systems. The actual location and the type of table in which a given occurrence is stored is defined by a plurality of dictionary tables within the table data store. These dictionary tables can be considered metadata in that they are prespecified tables having a structure known to the table data store and to the table access machine so that they can be automatically surveyed in order to build control tables used for accessing occurrences in generic tables. The dictionary tables include the table named TABLE which has the structure shown in FIG. 3. This table includes the name and type of all tables available to a given session in the machine. Also, the dictionary includes a table named FIELDS (table name) which is a table which includes the attributes of all data elements in the system and has the structure set out in FIG. 4. This table is parameterized on the table name. Therefore, the table access machine generates a view of the table called FIELDS which is limited to the fields of a given table. The dictionary also includes a table called PARMS (table name) which is shown in FIG. 5. This table identifies the parameter associated with each table, if there are any. The dictionary also includes the table called SELECTION (table name) shown in FIG. 6, in which is stored a selection string or filter to be applied to accesses to the table. Other dictionary tables include ORDERING (table name) as shown in FIG. 7 which defines a set of ordering operations to be implemented upon accesses to the table, EVENTRULES (table name) as shown in FIG. 8 which specifies rules to be executed upon access events to occurrences in the table, @RULESLIBRARY (library name) as shown in FIG. 9 which stores actual object code for executable rules for the session. The parameter library name is a basic method for dividing up the rules library by a variety of names. The dictionary also includes dictionary tables required for accesses through the servers other than the table data store. For instance, FIGS. 10, 11, and 12 shown the tables IMSTABFIELDS (table name), IMSSEGFIELDS (db name, seg name), and the IMSACCESS (table name) tables which are used by the IMS server. The IMSTABFIELDS table maps the table access method filed name to an IMS field name. The IMSSEGFIELDS table provides the syntax and mapping parameters for an access based on parameters retrieved from the IMSTABFIELDS table. The IMSACCESS table is used by the server to generate actual access sequences for transmission to the IMS data base. Also, the dictionary table includes the tables used by the screen servers as shown in FIGS. 13-15. FIG. 13 shows the table SCREENS which identifies all the screens that are accessible through the table access machine in a given session. FIG. 14 shows the table SCREENTABLES (screen) which provides a screen definition for a window in a position within a screen for the window. The table SCREENFIELDS (s