This display results when:
A new date format/range rule is to be added.
|
|---|
|
Note that file name is only displayed when working at file level. Change and 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 date format/range rule:
Order to Process
Mandatory, but always prefilled to <highest order number + 10>. 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, RULE04, RULE01, RULE02, RULE05, RULE03 would be performed:
Rule | Level | Order To Process |
|---|---|---|
RULE01 | Dictionary | 100 |
RULE02 | Dictionary | 200 |
RULE03 | File | 20 |
RULE04 | Dictionary | 50 |
RULE05 | File | 10 |
|
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.
Validate Date in Format
Mandatory. Initially set to SYSFMT. It specifies the format that the date field should be in.
Valid format types in this version of LANSA are:
SYSFMT | Operating system date format (from QDATFMT) |
SYSFMT8 | 8 digit date in operating system format. |
DDMMYY | Day month year format |
MMDDYY | Month day year format |
YYMMDD | Year month day format |
DDMMYYYY | Day month century year format |
MMDDYYYY | Month day century year format |
YYYYMMDD | Century year month day format |
YYYYDDMM | Century year day month format |
YYMM | Year month format |
YYYYMM | Year month format with 4 digit year |
MMYY | Month year format |
MMYYYY | Month year format with 4 digit year |
For example, to satisfy each format type, 28th October 1986 must be entered as:
SYSFMT | 281086 (Usual format for Australia and Europe) |
SYSFMT | 102886 (Usual format for USA) |
SYSFMT8 | 28101986 (Usual format for Australia and Europe) |
SYSFMT8 | 10281986 (Usual format for USA) |
DDMMYY | 281086 |
MMDDYY | 102886 |
YYMMDD | 861028 |
DDMMYYYY | 28101986 |
MMDDYYYY | 10281986 |
YYYYMMDD | 19861028 |
YYYYDDMM | 19862810 |
YYMM | 8610 |
YYYYMM | 198610 |
MMYY | 1086 |
MMYYYY | 101986 |
Note: The client's date format will be automatically passed to the server. If the client and server date formats are different (e.g. MDY vs DMY), the server will automatically return data in the client's format.
The client's format can be changed from the default by specifying the x_run parameter DATF=. For more information, please refer to Standard X_Run Parameters in the Technical Reference Guide.
If client and server date formats are different (such as between USA and UK clients), date format validation rules specifying exact formats will fail. For example, DDMMYY may be returned as MMDDYY. Where clients need to use different date formats, date format SYSFMT is recommended.
Number of Days Allowed into the Past
Mandatory. Prefilled to 9999999. Specifies the lower limit of the date range rule.
Number of Days Allowed into the Future
Mandatory. Prefilled to 9999999. Specifies the higher limit of the date range rule.
The use of the "days into the past" and "days into the future" range limit values can be illustrated with a time line:
Current date
Lower limit (date on which the Upper limit
for valid date rule is performed) for valid date
| | |
| | |
| N |
======|======= PAST ==========O======= FUTURE =======|=======>
| W |
| | |
| | |
|<---------------------|-------------------->|
"X" days allowed | "Y" days allowed
into the past | into the future
If Field Passes Date Format/Range Rule
Mandatory. Prefilled to NEXT. Specifies what is to happen if the field is found to be in the required date format and passes the range test. 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 Field Fails Date Format/Range Rule
Mandatory. Prefilled to ERROR. Specifies what is to happen if the field is not in the required date format or fails the range test. 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 (described below), 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.
If you are working on an IBM i, you can directly edit the message details from this screen panel. 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 operating system facility will allow you to create or edit the message details. Upon completion of the WRKMSGD command, this screen panel 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 (described above) 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.
Note: All dates must have a four character year so that accurate comparisons and calculations can be performed. Where a two character year (eg. DDMMYY, YYMMDD, MMYY) is supplied the century value is retrieved from the system definition data area. The year supplied is compared to a year in the data area, if the supplied year is less than or equal to the comparison year then the less than year is used. If the supplied year is greater than the comparison year then the greater than year is used.