Aspen SCM‎ > ‎Expert System‎ > ‎2. Flow of Control‎ > ‎

2.a Asserting Duplicate and Non-existent Predicates

Execution of Duplicate Predicates

Where there is more than one rule whose canonical predicate matches an assertion, the Aspen SCM Expert System will start by executing the rule which appears first in $PRED. $PRED contains a list of all predicates in their canonical form. This list is built either when you start running a rule (if RULES(LINK,1) = YES) or by executing the command LINK. It processes the entries in RULES one at a time and converts the predicate conclusions into canonical form.

Thus the first rule to be tried will be that whose rule set appears first in RULES. If there is more than one such rule in the rule set, they will be tried in the order in which they appear in that rule set.

If the first rule is proved and it resolves TRUE in the calling procedure, the interpreter then continues in the calling procedure. But if the first rule does not end TRUE or if it ends TRUE but resolves FALSE in the calling procedure (because arguments have been changed), the interpreter then tries the next rule whose predicate matches the assertion. If this also fails, it then tries the third rule which matches the assertion; and so on. Only when all possible rules have been tried and failed does the interpreter regard the assertion in the calling procedure as FALSE and proceed accordingly.

Mistakes Interpreted as Predicates

One unfortunate consequence of Aspen SCM Expert System’s approach to tokenising is that if, by mistake, you include a blank where one is prohibited, the interpreter may regard the resulting token as a predicate which it attempts to prove. Thus the statement (a real example)

AND     ?STRCOPY = STRFMT(?NCOPY, F4.3)

with a blank after the comma in the arguments to STRFMT is interpreted as asserting the predicate “?STRCOPY” “=” “STRFMT(?NCOPY,” “F4.3)”, where each item within a pair of double quotes is a separate token (the double quotes are just to demonstrate the tokens and are not part of the tokens).

As it cannot find such a predicate, it asserts other predicates with the same number of tokens (in this case predicate verb + three tokens) and branches to the rule which could prove the predicate. If you are fortunate, an error will result fairly quickly, bringing execution to a halt; if you are not, the interpreter will get stuck in a loop and you will be none the wiser as to where it was when it hung.

Another unfortunate misinterpretation of a statement occurs with character strings which are blank. Consider the statement (another real example)

AND     MPLXUVAR(?ORDR,:VAR) = ?USEMPLX

where MPLXUVAR is a character array. Then if ?USEMPLX happens to be blank this statement is interpreted as the predicate “MPLXUVAR(?ORDR,:VAR)” “=”. As this predicate does not exist, the interpreter branches to the first predicate with two tokens (i.e. predicate verb + one argument) and executes it in an attempt to prove what the purported predicate. Needless to say, a crash usually ensues.

Yet another misinterpretation occurs where a mistake has been made in the name of a set or table to which a value is being assigned. Thus

AND     LPRUNOUT(?ORDR,?MPLX) = ?TONRUN

is interpreted as a predicate if the table LPRUNOUT does not exist.

Such problems are trapped by setting the “Error on Unknown” flag CNTLE(EOU,1) = YES; see section 2.d.


Back                                Next
Comments