Operating system and data base using table access method with dynamic binding5682535Abstract A system for program development and execution consisting of a high level programming language based on a four part rule organization, consisting of a rule definition, a list of conditions, a list of actions which are taken upon satisfaction of a corresponding condition, and a list of exception handlers. The high level language is translated into an internal representation which controls a virtual stack machine. The virtual stack machine performs dynamic binding of rules and data to the current rule. Data access events are supplied through a table access method which provides an interface to the variety of sources of data coupled to the system. These sources of data include screens, import/export mechanisms, a foreign database system, such as IMS, and a local database system known as the table data store. The table data store organizes data in an object oriented, relational system, where each table is ordered on a primary key. Also, the table access method performs selection and ordering operations on the tables accessible through the table access method, implements and triggers invalidation routines upon data access events, in a recursive relationship with the virtual stack machine, and provides a common view of data stored across the heterogeneous data stores coupled through servers to the table access method. The ordered tables are subdividable by additional parameters associated with table names. Claims What is claimed is: Description COPYRIGHT AUTHORIZATION
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 >=
1
DD;
GET MONTHS WHERE MONTH = MM & DAYS >= 1
DD;
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
______________________________________
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 Variables 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 >=
1
DD;
GET MONTHS WHERE MONTH = MM & DAYS >= 1
DD;
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`.parallel.CARS.LICENSE#.parallel.
` MODEL `.parallel.CARS.MODEL.parallel.`RETAIL PRICE:$.parallel.
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;
______________________________________
UNITL . . . 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.sub.-- 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 -
+, -, .vertline..vertline.
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: ** * / + 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.
______________________________________
COUNT(TABLEREF, FIELDREF);
LOCAL SUM;
FORALL TABLEREF 1
SUM = SUM + (TABLEREF) . (FIELDREF) ;
END;
CALL $PRINTLINE('THE SUM OF'
.parallel.TABLEREF
2
.parallel.' '.parallel. FIELDREF .parallel. ' IS: '
.parallel. SUM);
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
Table 32:
Indirect References. The example
invocations and their results show
how indirect references can
generalize a rule.
______________________________________
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 ABCDEFGHIJKLMNOPQRSTUVWXYZ (b) digits 0123456789 (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 ** <=>==.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
______________________________________
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
General discussion--TDS options 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` (export),
`PRM` (parameter), `SUB` ((subview) and `IMS`
(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
responsible 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 features allows the system to partition
its database 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 semantic 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 occurrence 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
MANAGERNO I P 3 0 S MGR#
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.
______________________________________
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 -
Example Write - event rule
Validation
Write
Trigger
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
______________________________________
##STR2##
______________________________________
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
__________________________________________________________________________
##STR3##
__________________________________________________________________________
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
__________________________________________________________________________
##STR4##
__________________________________________________________________________
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
__________________________________________________________________________
##STR5##
__________________________________________________________________________
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: .sub.--
TABLE: expense.sub.-- data
LEFT:10 RIGHT:11 FIELD: .sub.--
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
CUSTOMER NAME:
-AAAAAAAAAAAAA ACCOUNT#: -99999
STREET ADDRESS:
-AAAAAAAAAAAAAAAAAAAAA
CITY & PROVINCE:
-AAAAAAAAAAAAAAAAAAAAA
__________________________________________________________________________
TABLE: ORDER.sub.-- CUST
FIELD SCREEN ATTRIBUTES
ROW,
COL
NAME TYP
SYN
JUST
FILL
LEN
DEC
PT
SHW
RQ
HI
SKP
__________________________________________________________________________
3 18 name s c .vertline.
14 0 n y y y y
3 35 account#
i c r 0 5 0 n y y n n
4 18 address
s c .vertline.
22 0 n y n n y
5 18 city s c .vertline.
22 0 n y y n y
__________________________________________________________________________
PFKEYS: 2 = DOC 4 = .+-.LINE 5 = CUT 6 = +FLD 13 = PRINT 16 = -LINE 17 =
PASTE 18 = -FLD 19 = LOAD
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 showns 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 (screen table) shown in FIG. 15 further provides mapping directly onto the screen itself. This dictionary data can be expanded to serve any number of servers, but its structure is hard coded ("meta meta data") in the preferred system. Now that the basic application programmer's view of the system has been described and the representation of data and dictionary data in the system has been provided, an internal specification of the operation of the virtual machines can be understood. V. Internal Representation of Rules Rules are stored in an internal representation that is directly executable by the virtual stack machine. The process of saving a rule in the rule editor involves a translation from its textual source code to virtual machine object code. When the textual representation of a rule is required, a detranslation process converts from the virtual machine object code to text. The obvious advantage of storing only one representation of a rule is that a discrepancy between representation can never arise. This section details the internal representation of a rule. It begins by describing the overall layout of the object code. A detailed description of the various data items, and virtual machine opcodes follows. Examples of the object code corresponding to various kinds of rule statements are included. THE FORMAT OF A RULE Rule object code is stored in the @RULESLIBRARY table. This table is parameterized by library name and has the rule name as its primary key. Conceptually, the object code for a rule may be subdivided into four components: 52 bytes of header information; "n" bytes of code; "m" bytes of static (non-modifiable) data; and "p" bytes of modifiable data. Only the first three of these components are actually stored in the object code. The modifiable area is allocated when the rule is loaded for execution. TABLE 46 shows the detailed layout of the rule object code. The header and code sections contain references to objects in the static data area. These references are two byte binary offsets which are relative to the start of the header. The Parameters, Local Variables, Exception Handler Names, Table. Field Names, Rule names and Constants Sections all belong to the static data area.
TABLE 46
______________________________________
Layout of rule object code
______________________________________
Header (52 bytes)
Parameters (optional)
Local Variables (optional)
Code for Conditions
Code for Actions
Code for Exceptions (optional)
Exception Handler Names (optional)
Rule Names (optional)
Table.Field Names (optional)
Constants (optional)
______________________________________
RULE HEADER The header portion of the object code, which is shown in TABLE 47, contains the name of the rule along with various other values which describe the code, static data and modifiable data areas. The length stored in the header is the number of bytes to the right of the length value. Thus the total length of the rule is the value in Length plus 28 (the number of bytes to the left of and including the Length value).
TABLE 47
______________________________________
Layout of rule object code header
Value Offset Syntax Purpose
______________________________________
Rulename
00 Char(16) Name of the rule
Date 16 Char(6) Date of translation
Time 22 Char(4) Time of translation
Length 26 Bin(2) Length of rest of rule
Num parms
28 Bin(2) Number of formal parameters
Parm off
30 Bin(2) Offset to local list
Num locs
32 Bin(2) Number of local variables
Loc off 34 Bin(2) Offset to local list
Cond off
36 Bin(2) Offset to conditions
Act off 38 Bin(2) Offset to actions
Excp off
40 Bin(2) Offset to exception names
Function
42 Char(1) Rule is a function (Y/N)
TabFld off
43 Bin(2) Offset to t.f names
Const off
45 Bin(2) Offset to constants
Rule off
47 Bin(2) Offset to rule names
Version 49 Bin(1) Object code version#
Mod data
50 Bin(2) Size of modifiable data area
______________________________________
RULE STATIC DATA This section outlines the contents of the static data area. Certain object names in the static data section contain references to items in the modifiable data area. Each reference is a two byte offset which is relative to the start of the modifiable data area. The values in the header which describe the static data area's layout are identified, when appropriate. Parameters The parameter section of the object code contains the list of names of the formal parameters declared for this rule. ##STR6## As shown in Table 48, item in the list is a 16 byte name. "Num parms" contains the number of formal paramete | ||||||