7.16.1 DATECHECK Parameters
Specifies the name of the field which is to be checked. Only fields of type Alpha, Packed, Signed, Date, or Datetime may be specified. Fields of any other type cannot be specified.
Specifies the format the date is expected in. The only permissible values are *SYSFMT, *DDMMYY, *MMDDYY, *YYMMDD, and *DDMMYYYY, *YYYYMMDD, *YYYYDDMM, *YYMM, *MMYY, *MMDDYYYY, *YYYYMM, *MMYYYY, *SYSFMT8.
*SYSFMT, which is the default value, indicates the date format nominated in the operating system "system value" QDATFMT should be used as the date format required. Refer to the appropriate IBM supplied manual for more details of system value QDATFMT.
If the specified field is of type Date or Datetime, this parameter is irrelevant as fields of type Date or Datetime are always in ISO format. So, if this parameter is specified as other than *SYSFMT, a FFC Warning is displayed stating that the format is ignored.
Specifies the number of days prior to the current date for which this date will still be valid. If no days are specified, the value 9999999 is assumed.
Specifies the number of days after the current date for which this date will still be valid. If no days are specified, the value 9999999 is assumed.
Specifies the action to be taken if the field is a valid date in the format nominated and also passes any associated range checking.
If *NEXT is specified the field is considered to have passed the validation check. Processing will continue with the next RDML command.
If *ERROR is specified the field is considered to have failed the validation check. Either the message text specified in MSGTXT or the message specified in MSGID and MSGF parameters will be displayed on line 22/24 of the next screen format presented to the user. In addition the field named in the FIELD parameter will be displayed in reverse image and the screen cursor will be positioned to the first field on the screen that is in error. Processing continues with the next RDML command.
If *ACCEPT is specified the field is considered to have passed the validation check AND no other validation checks will be performed against the field named in the FIELD parameter within this validation block. Processing continues with the next RDML command. However, if this is another validation check against the same field it will be effectively "disabled" and not performed.
Specifies the action to be taken if the date is not a valid date in the format nominated or fails any associated range checking.
If *NEXT is specified the field is considered to have passed the validation check. Processing will continue with the next RDML command.
If *ERROR is specified the field is considered to have failed the validation check. Either the message text specified in MSGTXT or the message specified in MSGID and MSGF parameters will be displayed on line 22/24 of the next screen format presented to the user. In addition the field named in the FIELD parameter will be displayed in reverse image and the screen cursor will be positioned to the first field on the screen that is in error. Processing continues with the next RDML command.
If *ACCEPT is specified the field is considered to have passed the validation check AND no other validation checks will be performed against the field named in the FIELD parameter within this validation block. Processing continues with the next RDML command. However, if this is another validation check against the same field it will be effectively "disabled" and not performed.
Allows up to 80 characters of message text to be specified. The message text specified should be enclosed in quotes. Use either the MSGTXT parameter or the MSGID / MSGF parameters but not both.
Allows a standard message identifier to be specified as the message that should be used. Message identifiers must be 7 characters long. Use this parameter in conjunction with the MSGF parameter.
Specifies the message file in which the message identified in the MSGID parameter will be found. This parameter is a qualified name. The message file name must be specified. If required the library in which the message file resides can also be specified. If no library name is specified, library *LIBL is assumed.
Use this parameter only in conjunction with the MSGID and MSGF parameters. It specifies from 1 to 20 values that are to be used to replace "&n" substitution variables in the message specified in the MSGID parameter.
Values in this parameter may be specified as field names, an expandable group expression, alphanumeric literals or numeric literals. They should exactly match in type, length and specification order the format of the substitution variables defined in the message.
When a field specified in this parameter has a type of signed (also called zoned) decimal, the corresponding "&n" variable in the message should have type *CHAR (character). This may cause a problem when dealing with negative values. In this case use packed decimal format instead.
When an "&n" variable in the message has type *DEC (packed decimal) the field specified in this message must be of packed decimal type.
When using alphanumeric literals in this parameter, remember that trailing blanks may be significant. For instance, if a message is defined as .
"&1 are out of stock ... reorder &2"
where &1 is defined as (*CHAR 10) and &2 as (*DEC 7 0), then the message will NOT be issued correctly if specified like this :
MSGDTA('BOLTS' #ORDQTY)
or like this
MSGDTA('BOLTS ' #ORDQTY)
To make LANSA aware of the trailing blanks, the parameter must be specified like this:
MSGDTA('''BOLTS ''' #ORDQTY)
When expandable expressions are used, the expanded field list must not exceed the maximum number of substitution variables allowed in the parameter.