Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
5586329
Knudsen , ; et al.
December 17, 1996
Title
Programmable computer with automatic translation between source and object code with version control
Abstract
A computer which executes rules which are defined according to a language having a valid grammar. The computer comprises input means for receiving and temporarily storing a first source code representation of a rule; object code translation means for translating the first source code representation into a first object code representation executable by the computer; storage means for storing the object code representations of rules; discard means for automatically discarding from the input means the first source code representation upon the storing of the first object code representation in the storage means; source code translation means for translating the first object code representation into a second source code representation where the second source code representation has lines of text; edit means for editing the second source code representation by deleting, adding, or changing one or more of the lines of text of the second source code representation; second object code translation means for translating the second source code representation, as edited, into a new object code representation of the edited rule for storage in the storage means; and the discard means discarding the first object code and second source code representations automatically upon the storing of the new object code representation of the edited rule in the storage means. The computer thereby minimizes the storage required in the storage means for storing rules and maintains version control over the object code representations of rules stored in the storage means.
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.:
424234
Filed:
April 18, 1995
Current U.S. Class:
717/108
717/112
717/117
717/137
707/100
Field of Search:
395/700
U.S. Patent Documents
4099230
July 1978
Mead
4667290
May 1987
Goss et al.
5005152
April 1991
Knutsen
Foreign Patent Documents
0243110
Oct., 1987
EP
2126761
Mar., 1984
GB
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. 2, No. 9, 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. .
Hintz et al., "Design of an Incremental Compiler and Interactive Interpreter Utilizing a Hybrid Token-Threaded Code", IBM Technical Disclosure Bulletin, vol. 26, No. 10A, Mar. 1984, pp. 5301-5302..~
Primary Examiner:
Kriess; Kevin A.
Assistant Examiner:
Chaki; Kakali
Attorney, Agent or Firm:
Fliesler, Dubb, Meyer & Lovejoy
Parent Case Text
CROSS-REFERENCE TO RELATED APPLICATIONS
This application is a continuation of Ser. No. 08/029,908, filed Mar. 11, 1993, now abandoned, which is a divisional of Ser. No. 07/968,237, filed Oct. 29, 1992, now abandoned, 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 computer apparatus for creating and modifying object rules stored in a computer system to be executed by said computer system, said object rules being in an object rule language which is executable by said computer system, said computer apparatus comprising:
a) means for retrieving from said computer system a first object rule to be modified;
b) a text editor including
i) means for translating the retrieved said first object rule into a first token rule in a token source code language;
ii) means for translating said first token rule into a first source rule in a source code language where said source rule is a line by line textual representation of said first object rule, said source code language being defined in accordance with grammatical criteria;
iii) means for modifying said lines of said source code language for said first source rule in accordance with said grammatical criteria for said source code language to form a modified first source rule;
iv) means for generating new lines of source code in accordance with said grammatical criteria for said source code language to form a new source rule;
v) means for performing lexical analysis for determining the grammatical validity of said new source rule and each said modified line of said modified first source rule;
vi) means translating, when valid, said new source rule into a new token rule in said token source code language and said modified first source rule into a modified token rule in said token source code language; and
vii) means for translating said new token rule into a new object rule in said object code language said modified first token rule into a modified object rule in said object code language; and
c) means for storing in said computer system said new object rule and said modified first object rule in place of said first object rule that was modified thereby maintaining within said computer system only the most current version of said object rules, in said object code language, to provide version control for said object rules stored in said computer system.
2. The computer apparatus of claim 1 further comprising:
means for displaying the current said line or lines of said source code for said new source rule being generated or said line or lines of source code for said modified source rule being modified.
3. The computer apparatus of claim 1 further comprising:
means for entering into said text editor data to generate said lines of said source code for said new source rule to modify at least one line of said source code for said modified first source rule.
4. The computer apparatus of claim 1 wherein said text editor further comprising:
means for deleting from said text editor said new source rule and said new token rule after said new object rule has been stored in said computer system and said modified first source rule and said modified first token rule after said modified first object rule has been stored in said computer system.
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 computer which executes rules defined according to a language having a valid grammer.
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 stroage 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. 30 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 heterogenous 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.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 - +,-,.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:
**
*
/
+
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:
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:
(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:
(d) Optional categories are enclosed in square
brackets, [ ]. For example:
Character Set
All rule language constructs are represented with a character set that is subdivided as follows:
(a) letters
(b) digits
(c) special characters
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
or one of the following compound symbols
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> ::=<assignment> <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 list>
<where arg list> ::=<where arg item> {<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> ::=<exception 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 list>]
<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> <expr 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 .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
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 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 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.
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:
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
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:
or
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 __________________________________________________________________________ ##STR3## __________________________________________________________________________
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 __________________________________________________________________________ ##STR4## __________________________________________________________________________
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 __________________________________________________________________________ ##STR5## __________________________________________________________________________
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 __________________________________________________________________________ ##STR6## __________________________________________________________________________
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).
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
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 ##STR7## __________________________________________________________________________ ##STR8## __________________________________________________________________________ ##STR9## ##STR10## __________________________________________________________________________
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.
TABLE 48 ______________________________________ The internal representation of a parameter ##STR11## ______________________________________
As shown in Table 48, item in the list is a 16 byte name. "Num parms" contains the number of formal parameters declared for this rule, while the "Parm off" value is an offset to the start of this list.
Local Variables
The local variables section of the object code contains the list of names of local variables declared in this rule.
TABLE 49 ______________________________________ The internal representation of a local variable ##STR12## ______________________________________
As shown in Table 49, each item in the list contains a 16 byte name followed by a two byte offset to the modifiable data area. "Num locs" contains the number of local variables declared in this rule, while "Locs off" contains an offset to the start of this list.
Exception handler names
The exception name section contains the list of names of exceptions handled by this rule.
TABLE 50 ______________________________________ The internal representation of an exception name ##STR13## ______________________________________
As shown in Table 50, each item in the list consists of a 16 byte name followed by a pair of two byte offsets. The first two byte offset references the name of the table associated with this exception. The table name is stored in the static data area as a 16 byte name. If there is no associated table name, this offset is zero. The second offset references the code which handles the exception. "Excp off" contains an offset to the start of this list; the list is terminated with a two byte zero.
Fields of tables
The table.field section of the rule object code is a list of all direct table.field names in the rule.
TABLE 51 ______________________________________ The internal representation of a direct table.field name ##STR14## ______________________________________
As shown in Table 51, each item in the list consists of two 16 byte names (one for the table and one for the field) followed by a two byte offset to the modifiable data area. "TabFld off" references the start of the list; the list ends at the "Const off" offset.
Rule names
The rule name section is a list of all the direct rule (or local variables not declared in this rule) names called by this rule.
TABLE 52 ______________________________________ The internal representation of a direct rule name ##STR15## ______________________________________
As shown in Table 52, each item in the list consists of a 16 byte name, followed by a two byte offset to the modifiable data area. "Rule off" references the start of the list; the list ends at the "TabFld off" offset.
Constants
The constants section is a list of all the constants in the rule (either literal constants or constants generated internally by the translator). A shown in Table 53, each item in the list has a six byte descriptor followed by data. The data itself is prefixed by a one or two byte length (one byte if the data is 0 . . . 127 bytes in length, two bytes for 128+). The high order bit of CLen is on if CLen is two bytes, otherwise CLen is one byte.
TABLE 53 ______________________________________ The internal representation of a constant ##STR16## ______________________________________
The type is a single byte which contains the semantic type of the constant. All constants have an unknown (blank) semantic type. The Syntax is a byte which indicates the representation of the data. Valid syntaxes are B(binary) P(packed decimal) F(floating point) C(fixed char) and V(variable char). The DLen is two bytes and contains the definition (or maximum) length of the Data. CLen contains the current length of the Data. Dec is also two bytes and contains the number of digits to the right of the decimal point. Dec is only meaningful for packed decimal constants. "Const off" references the start of the list of constants; the list terminates at the end of the object code which is given by "Length"+28.
RULE OPCODES
The virtual stack machine is based on a stack architecture. Most virtual machine instructions manipulate the items on the top of the stack. All stack items are four bytes in length. Many items are pointers to values which are either fields of a table, rule constants or temporary values built during execution. As shown in Table 54, all values are comprised of a six byte descriptor, followed by a four byte pointer to the actual data. The data itself is prefixed by a one or two byte length. The stack may contain other information, such as that necessary to implement rule call and return.
TABLE 54 ______________________________________ The virtual machine representation of a value ##STR17## ______________________________________
For values that are built during execution, the virtual machine maintains a temporary area. When temporary values are popped from the stack, their storage in the temporary area is freed.
All virtual machine instructions contain a single byte opcode. Depending upon the opcode, it may require zero, one or two, two byte operands.
For the purpose of describing the semantics of each opcode, let item1 represent the top item on the stack and item2 represent the second item on the stack. Let operand1 and operand2 denote the first and second immediate operands, respectively.
______________________________________ Name Opcode #Ops Semantics ______________________________________ @ADD 4 0 Add two values together. Pop item1 and item2. Create and push a temporary value of item2 + item1. @SUB 8 0 Subtract one value from another. Pop item1 and item2. Create and push a temporary value of item2 - item1. @MULT 12 0 Multiply two values together. Pop item1 and item2. Create and push a temporary value of item2 * item1. @DIV 16 0 Divide one value by another.