This document covers the following topics:
- Automatic Rule
An automatic rule is used automatically whenever a field to which a verification of status automatic has been linked via "Is verified by VE" is included in a map. Automatic rules cannot be changed in the Natural map editor, which guarantees consistent use of these processing rules throughout an application.
- Automatic - Verification Status
A verification has the status automatic if it contains a rule that is linked to at least one field of at least one file for which a DDM has been generated.
- Conceptual - Verification Status
A verification of status conceptual contains a rule that has not yet been cataloged with
CAT FREEorSA[VE] FREE.- Documented - Verification Status
A verification of status documented does not contain a rule and cannot be used in a Natural map. It is used in the early phases of application design.
- Free Rule
A free rule is used in a Natural map by specifying the ID of a verification of status free. The Natural code of the processing rule stored with the verification will be included into the map when the map is cataloged. Free rules can be defined and modified with the Natural map editor and directly in Predict.
- Free - Verification Status
A verification has the status free if it contains a rule that has been cataloged with
CAT FREEorSA[VE] FREE.- Inline Rule
Inline processing rules are defined within a Natural map source and do not have a name assigned. Inline rules in Natural can be used independently of Predict.
- Natural Construct - Verification Status
A verification of status Natural Construct is created by entering command
CAT NorSA[VE] Nin the Rule Editor. These verifications are only used by Natural Construct.- Processing Rule
Rule for validating data entry in a Natural map or SQL database. The following types of processing rules can be defined:
For Natural:
Inline processing rules
Free rules
Automatic rules
For SQL:
SQL
- Rule Editor
The Rule Editor is a modified Natural Editor in Predict which is used to edit the rule of a verification. See the section Editors in Predict in the Predict Reference documentation.
- SQL - Verification Status
A verification of status SQL is created by entering command
CAT SorSA[VE] Sin the Rule Editor. See Verifications of Status SQL.- Verification
A verification is a predefined object type in Predict and can contain the Natural or SQL code of a processing rule.
Natural processing rules perform validity checks on input data to ensure that the data to be processed is suitable. For example, in a program controlling traffic lights, the only input values allowed for the field colour might be red, green and amber.
Natural processing rules can be defined and stored centrally in Predict.
Storing processing rules in Predict has the following advantages:
Programming costs and the number of errors can be reduced by using free rules stored in Predict.
The use of processing rules can be forced by linking automatic rules to fields via association "Is verified by VE". Automatic rules cannot be changed in the Natural map editor. This guarantees consistent use of these processing rules throughout an application.
The use and design of processing rules can be planned and revised by using verifications of status documented and conceptual.
The following general rules apply to processing rules in Predict:
Processing rules of status documented or conceptual can be linked to fields via "Is verified by VE".
Natural inline processing rules can be integrated into Predict as free rules by giving them a name in the Natural map editor.
Automatic rules can be used as free rules by specifying their name in the map.
Processing rules can be written in either structured mode or report mode.
A GENERATE command creates the
Natural code of a processing rule from the rule of a verification. The
generated code can then be changed to meet specific requirements.
Links from fields to verifications linked via "Is verified by VE" are rippled. See Rippling Verifications
The status of the Predict verification object determines how a rule stored with the verification is used in an external environment. Six status types are distinguished:
The characteristics of the different status types are described below.
Verifications of status documented can be used in the early phases of application design when the parts of an application that have to be implemented are listed. verifications of status documented do not contain processing rules and cannot be used in Natural maps.
| Documented | |
|---|---|
| ID: | xyz |
| Type: | equal |
| Format: | alpha |
| Value | 'xyz' |
Verifications of type documented are not connected to an external environment.
Verifications containing a processing rule that has not yet been
cataloged with CAT FREE or SA[VE]
FREE have the status conceptual.
A verification has the status free if it contains a processing
rule that has been cataloged with CAT FREE or
SA[VE] FREE and can therefore be used in any Natural
map by linking it explicitly to a field.
A free rule is used in a Natural map by specifying the verification ID. A Select function is provided for selecting free rules from Predict. Only free rules with a format compatible with the format of the input field of the map for which they are to be used will be displayed by the select function. The Natural code of the processing rules stored under the given verification ID will be included into the map when the map is cataloged.
Free rules can be defined and modified with the Natural map editor and directly in Predict.
A verification has the status automatic if it contains a processing rule that is linked to at least one field of at least one file for which a DDM has been generated. An automatic rule is automatically used every time a field to which it has been linked is included in a map. Automatic rules are centrally defined by the administrator who generates DDMs and cannot be modified by individual programmers with the Natural map editor. Defining an automatic rule is a two-stage process:
Link the verification containing the rule to a field of a file (a real file or a userview) in Predict.
Activate the rule by generating a DDM for that file.
The following rules apply for the use of automatic rules:
Up to 50 automatic rules can be linked to a field.
If the code contained in an automatic rule is changed but its links to fields remain, the Predict Replace Verification Rule function can be used to update the active code which is used by the fields. There is no need to regenerate the DDM. Natural maps using processing rules that have been modified should be recataloged to ensure that they use the new version of the processing rule.
The LIST XREF function with the option Save set set to Y can be used to recatalog maps efficiently.
An automatic rule can also be used as a free rule by specifying the name of the corresponding verification in a Natural map. Automatic rules that have been used in this fashion cannot be modified with the Natural map editor.
Automatic rules cannot be changed with the Natural map editor.
Verifications of status Natural Construct can be accessed only from Natural Construct.
These verifications must be linked to a field so that Natural Construct can access them. Unlike verifications of status Automatic, it is not necessary to generate a DDM for a verification of status Natural Construct in order that the rule is used.
The following rules apply:
Verifications of status SQL are skipped by functions Generate DDM and Replace Verification rule.
The syntax of the processing rules is not checked by Predict.
These processing rules may only contain references to the field to which they are linked. Ampersand notation is used instead of a fixed allocation.
The ampersand references are replaced by the corresponding
field name when the CREATE TABLE statement is generated.
If you execute the command GEN[ERATE]
S in the Rule Editor, a corresponding SQL clause is created for
all rule types except user routine. When the code of the rule is saved, the
status of the verification is changed to SQL.
Only one verification of status SQL (and 49 of a status other
than SQL) may be linked to a field. This condition is checked only when the
CREATE TABLE statement is generated.
Comments are removed when the CREATE TABLE
statement is generated.
Otherwise the handling of these verifications corresponds to verifications of status Natural Construct. See Verifications of Status Natural Construct.
Processing rules are stored in Predict as attributes of verifications. If a verification has been linked to a field of a map, the Natural code of the rule is inserted when that map is cataloged.
In the source code of a processing rule, the name of a variable can be represented by an ampersand (&). The Natural compiler or Predict generation function will substitute the name of the field (or PF key for a PF key rule) for the ampersand. This allows the use of a rule for different fields.
IF & = ' ' REINPUT 'ENTER NAME' MARK *&
Processing rules assigned to function keys have highest priority.
Rules linked to different fields of a map are executed in the order in which the fields appear on a terminal screen.
A rank from 0 to 99 can be allocated to each inline rule or free rule linked to a field of that map. Additionally a rank can be allocated to all automatic rules linked to a field. The rules linked to that field will then be executed in ascending order of rank.
Automatic rules linked to a field in Predict are executed in the order their Predict verification IDs appear in the verification list of the field.
Every rule is allocated a format to ensure that the rule will be compatible with the field format. The following table lists the compatible combinations of field format and rule format.
| Field Format | Compatible Rule Format |
|---|---|
| A | A,B |
| N,P | N |
| I,F | B |
| B =< 4 | A,B,N |
| B > 4 | A,B |
| D (date/time) | D (date/time) |
| L | L |
The rule format K (function key) applies exclusively to free rules.
Processing rules can be created from Predict objects of type verification. Follow the steps below:
Enter Y in the field labelled Additional attributes in an Add, Copy or Modify Verification screen and select Rule code or execute the Edit rule of a Verification function (code R).
Enter the GENERATE [S|N] command in
the Rule Editor to generate a first version of the processing rule from the
definitions in the verification.
Modify the processing rule as required.
Test the rule with the RUN or
CHECK command (Natural rules only).
The rule is cataloged/saved with either one of the following commands:
SA[VE] [[FREE] RET[URN]]
CAT [[FREE] RET[URN]]
SA[VE] [S|N]
CAT [S|N]
If FREE is used, the rule is stored as a free rule.
Note:
Commands SAVE or
CAT do not perform a syntax check. The syntax is
checked when you catalog a map that uses the rule or when the CREATE
TABLE statement is executed.
The rule of a verification is edited with the Predict Rule Editor. This editor can be invoked in one of the following ways:
Enter Y in the field Additional attributes in the bottom line of the Add, Copy or Modify Verification screen and select Rule code.
Call function Edit rule in the Verification Maintenance Menu.
Enter command EDIT VERIFICATION RULE
<Verification-ID>
Note:
This section describes rule-specific editor commands. General
editor commands are described in the section
Editors in
Predict in the Predict Reference
documentation.
CAT [[FREE]
RET[URN]] |
Catalog/save the edited rule as a free
rule. This command is only available when creating new rules and when editing
conceptual rules.
Note: |
||||||||||||||||||
SA[VE] [[FREE]
RET[URN]] |
|||||||||||||||||||
C[HECK] |
Checks whether the edited rule's Natural syntax is valid and reports errors. | ||||||||||||||||||
GEN[ERATE] |
Generates a processing rule from the values defined in the rule of the verification and adds it to the end of the Natural source in the rule editor. This command is not available for verifications of type User routine. A table which shows the Natural and SQL statements generated for the different verification types can be found in the section Rule Editor in the Predict Reference documentation. |
||||||||||||||||||
GEN[ERATE] N |
Generates a rule for Natural Construct from a verification of status documented (D). The status of the verification is changed to N. | ||||||||||||||||||
GEN[ERATE] S |
Generates an SQL clause for all verification types except user routine. When the code is saved, the status of the verification is changed to S. | ||||||||||||||||||
GLOBALS SM=OFF |
Switch to the reporting mode of Natural. | ||||||||||||||||||
GLOBALS SM=ON |
Switch to the structured mode of Natural. | ||||||||||||||||||
RENUM[BER], N |
Renumber the source lines in steps of N and renumber references to them accordingly. | ||||||||||||||||||
RUN |
Checks the edited rule. If no errors are found, a map
is produced with which the user can test the rule by entering input values. The
following rules apply:
|
Predict assigns the status of verifications itself. The following table shows which actions cause a change of status.
| Old Status | New Status | Action |
|---|---|---|
| inline | free | Give the rule a name in the map editor. |
| documented | conceptual | Add a rule to the verification. |
| conceptual | free | Either catalog the rule in the rule editor with the
command SAVE FREE or CAT
FREE or use the Rename Verification function to change the status
explicitly.
|
| conceptual | SQL, Natural Construct | Catalog the rule in the rule editor with the command
SAVE S|N or CAT S|N. At
least one line must have been changed before cataloging.
|
| free | inline | Change the rule's name to a blank in the map editor. The rule will still exist in Predict with status free. |
| conceptual | automatic | Link the rule to at least one field (with the field maintenance function Link Verification), then generate a DDM for the file which includes it. |
| free | automatic | Link the rule to at least one field (with the field maintenance function Link verification), then generate a DDM for the file which includes it. |
| free | conceptual, Natural Construct | Use the Rename Verification function. The status of a free rule cannot be changed to conceptual if the rule is used in any Natural map. |
| automatic | conceptual | Unlink all fields from the rule (with the field maintenance function Link Verification) then regenerate the related DDMs. If the rule is also used as a free rule, the status of the verification will be changed to free. |
| documented | SQL, Natural Construct | Generate a rule for Natural Construct from a
verification of status documented (D) using the GEN[ERATE]
N command of the Rule Editor; for SQL using the command
GEN[ERATE] S.
|
| Natural Construct | free, conceptual | Use the Rename Verification function. |
One of six town names is allowed as input. The verification describing this validity check is created with values as shown below:
10:13:40 ***** P R E D I C T ***** 2007-05-31
- Modify Verification -
Verification ID . TEST-TOWN Modified 2007-05-31 at 09:46
Status .......... Free by HNO
Keys .. Zoom: N
Format .........* A Alphanumeric Modifier Zoom: N
Type ...........* T Table of values
Message nr ......
Replacement 1 ...
Replacement 2 ...
Replacement 3 ...
Message text .... No SAG-office in that town.
Abstract Zoom: N Values Zoom: N
BRUESSEL
RESTON
PARIS
DERBY
CAMBRIDGE
DARMSTADT
Additional attributes ..* N Associations ..* N
|
The following processing rule is generated if the
GENERATE command in the Rule Editor is applied to
this verification.
* **********************************************************************
* Verification: TEST-TOWN generated by PREDICT *
* with format: Alphanumeric; Type: Table of values; *
* on: 2007-05-31; at: 10:13:33; from user: HNO *
* **********************************************************************
IF NOT ( & = 'BRUESSEL' OR = 'RESTON' OR = 'PARIS' OR = 'DERBY'
OR = 'CAMBRIDGE' OR = 'DARMSTADT' )
REINPUT 'No SAG-office in that town.'
MARK *&
Each field of a standard file can have a list of verifications via association "Is verified by VE", which apply to that field. When the list is edited, corresponding changes are automatically made in the verification list of every field related to that standard field, according to the following rules:
Every verification contained in the verification list of a standard field must also be contained in the verification list of a field related to that standard field. However, the sequence of verifications in the lists can differ.
If a verification ID is changed, the same change is automatically made to that verification ID everywhere it appears in a verification list of related fields.
If a verification ID is deleted, every instance of that verification ID is automatically deleted from the verification list of every related field.
If a verification ID is added anywhere in the list, the same verification ID is automatically added to the end of the verification list of every related field.
A verification ID can be removed from verification lists of related fields that are marked as no check against standard.
Fields of physical files can have verifications linked to them via "Is verified by VE". When a list of verifications linked to a field in a physical file is modified, corresponding changes are automatically made in the verification list of userview fields related to that field in the file. The following rules apply:
The verification list of a field in a userview does not have to contain all the verifications that are contained in the list of the physical file field from which the userview field has been related. Hence, verifications can be deleted from the verification lists of userview fields, after these have been related to physical files.
If a verification ID is changed, the verification ID is changed in the verification lists of all related fields.
If a verification ID is deleted, every instance of that verification ID is automatically deleted from the verification list of every related field.
If a verification ID is added, it is added to the verification lists of related fields.