2 11 Complex Logic Rule

LANSA for i

2.11 Complex Logic Rule

This display results when:

  • An existing complex logic rule has been chosen for review.
  • A new complex logic rule is to be added.

 

 DC@P700107                Complex Logic Rule                          

                                                                       

  File      : XXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX      

  Field     : XXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX       

                                                                       

 Order to process / source . . . 999 / DATA DICTIONARY                 

 User description of rule  . . . ______________________________        

 Use rule when performing  . . . ADD    CHG     DLT                    

 Check by calling program  . . . ________  Type . . . .  ___  FUN/3GL  

 with standard parameters  :  < return code >                          

                              < name of field being checked >          

                              < value of field being checked >         

 and additional parameters :  ____________________                     

                              ____________________ +                   

                                                                       

 If           the program gives a "good" return code          : NEXT   

 Else         the program gives a "bad" return code           : ERROR  

 Specify error message number, file and library : _____  ______  _____ 

 Or text : ___________________________________________________________

                                                                       

                                                                       

 Fnn=Help  Fnn=Exit  Fnn=Cancel  Fnn=Messages                          

 

 

 

Note: File name is only displayed when working at file level. Change & Delete function keys are only enabled when an existing check is displayed.

If an existing rule is being reviewed then the CHANGE key can be used to place the screen in change mode and the required changes made.

If an existing rule is being reviewed then the DELETE key can be used to delete the rule. Note that the delete is immediate. No confirmation is required.

If a new rule is being added then the screen will be presented initially with default values. Change as required and press Enter to complete specification of the rule.

Input Options

These input options apply to a complex logic rule:

Order to Process:

Mandatory, but always prefilled to <highest order number + 10>. Validation rules are performed (and displayed) in the sequence of these order numbers (within the validation level). Order numbers must be unique within the validation level.

For instance:

Rule

Level

Order To Process

RULE01

Dictionary

100

RULE02

Dictionary

200

RULE03

File

20

RULE04

Dictionary

50

RULE05

File

10

 

 

would be performed: RULE04, RULE01, RULE02, RULE05, RULE03.

Source

Output field. Indicates the source or level at which the rule applies.

User Description of Rule

Mandatory. Enter a brief description of the rule to aid other users in understanding its purpose.

Use Rule When Performing

At least one entry required. Prefilled to ADD and CHG. Specifies "when" the rule is to be performed. Allowable values are:

ADD

When information is added (inserted) to the database.

ADDUSE

When information is added, and the field is actually specified/used in the INSERT command being executed.

CHG

When information is changed (updated) in the database.

CHGUSE

When information is changed, and the field is actually specified/used in the UPDATE command being executed.

DLT

When information is deleted (removed) from the database.

 

Most commonly used entries are ADD, CHG and CHGUSE. Use of DLT by itself is a common and a very powerful check mechanism. If ADDUSE is specified, ensure that the default value of the field is a valid database value. Use caution when specifying CHGUSE with a rule that involves multiple fields, because the check will only be done when the field linked to the rule is specified on an UPDATE command, and not done when it is omitted, regardless of whether or not any of the other fields referenced in the rule are specified.

Check by Calling Program

Mandatory. Specify the name of the LANSA function or 3GL program to be called. Note that no check is done for the existence of the function/program.

Note: The function/program should be able to be found in the user's library list at the time the rule is to be performed.

 

Type

Specifies whether the field is to be checked by calling a LANSA function or a 3GL program. Note that additional parameters cannot be specified if a validation function is being specified. See the FUNCTION command in the Technical Reference Guide for design constraints on validation functions.

With Standard Parameters

Output fields. For information purposes only. All 3GL programs called as part of a complex logic rule must have a least 3 standard parameters. These are:

Name

Description

Return code

Alphanumeric length 1. Returned by the program as '1' (good return) or '0' (bad return). Used by the program to indicate to LANSA the success or failure of the complex logic rule.

Name of field

Alphanumeric length 10. Passed to the program. Contains the name (as opposed to the value) of the field that is passed in the third parameter.

Value of field

Length and type depend upon the data dictionary definition of the field. Alphanumeric fields are passed with same type and length as their data dictionary definition. All numeric fields (type P or S) are passed as packed (type P) and the same length and number of decimal positions as their data dictionary definition. Note that the value of the field is passed in a work area, thus it is not possible to change the value of the field by changing the value of the parameter in the validation program.

 

 

Note that LANSA does not check that the 3GL program being called has the correct parameter list. This is a user responsibility.

 

And Additional Parameters

Optional. Additional parameters may be passed to the program. Additional parameters may be:

  • An alphanumeric literal (in quotes) such as 'STATUS', 'JONES'.
  • A numeric literal such as 1, 14.23, - 1.141217.
  • Another field name such as CUSTNO, INVNUM, etc.
  • A system variable name such as *BLANKS, *ZERO, *DATE or any other system variable defined at your installation.
  • A process parameter such as *UP01, *UP02, etc.

The type and length of the parameter(s) passed depends upon the type and length of the parameter value supplied.

For alphanumeric fields (alpha literals, alpha fields, alpha system variables or alpha process parameters) the parameter is passed as alpha (256) with the parameter value left aligned into the 256 byte parameter.

For numeric fields (numeric literals, numeric fields, numeric system variables or numeric process parameters) the parameter is passed as packed 15 with the same number of decimal positions as the parameter value. For numeric literals this means the same number of decimal positions as specified in the literal (e.g.: 1.12 will be passed as packed 15,2. 7.12345 will be passed as packed 15,5. 143 will be passed as packed 15,0. etc). For all other types of numeric parameters this means the same number of decimal positions as their respective definitions.

As with the standard parameters, the actual value is passed in a work area so it is not possible to change the value of a field by changing the parameter value in the validation program.

Note 1: Additional parameters may only be used when a 3GL program is called, and cannot be used when a validation function is called.

Note 2: LANSA does not check that the 3GL program being called has the correct parameter list. This is a user responsibility.

If the Program Gives a Good Return Code

Mandatory. Prefilled to NEXT. Specifies what is to happen if the return code parameter is returned as '1' (a "good" return). Allowable values are:

NEXT

Field is "okay". Proceed to next rule for this field.

ERROR

Field is in error. Issue error message described below.

ACCEPT

Field is okay. Bypass all other rules for this field.

 

Else the Program Gives a Bad Return Code

Mandatory. Prefilled to ERROR. Specifies what is to happen if the return code parameter is returned as something other than '1' (a "bad" return). Allowable values are:

NEXT

Field is "okay". Proceed to next rule for this field.

ERROR

Field is in error. Issue error message described below.

ACCEPT

Field is okay. Bypass all other rules for this field.

 

Error Message Number, File and Library

Optional. Specify either error message number, file and library or error message text (see following), but not both. Error message files and error message numbers are a native part of the IBM i operating system. Refer to the IBM supplied Control Language Reference Manual for details. CL commands involving message files include CRTMSGF and ADDMSGD.

You can directly edit the message details from this screen. Enter as much of the message details as is known and use the function key labeled "Work Msgd" (Work Message Description). This will cause a WRKMSGD command to be executed, using as much of the supplied message details as is possible. This facility will allow you to create or edit the message details. Upon completion of the WRKMSGD command, this screen will be redisplayed, unchanged, to allow you to proceed.

Do not store user defined messages in, or modify "shipped" messages in, the LANSA message file DC@M01 via this or any other message file editing facility. It is regularly replaced by new version or PC (program change) installations.

Text

Optional. If you do not wish to use an error message file to store the message text, then you may enter the text of the error message to be displayed directly. If this facility is used then the message will have no second level text associated with it. Refer to the section on Messages and the Help Key.

If neither an error message number, file and library nor error message text is specified LANSA will insert a default error message number, file and library as the error message. These default messages are "general purpose" and do not provide much detail about the specific cause of the error.