Validate that's is a true date? True date fields must contain real dates. You cannot enter a "bad" date in a date field. To test the 8A date field - there are two ways 1. use the TEST(D) command 2. Use MONMSG, for example MONMSG EVAL datefield = %date(charfield:*MDY/) ON-ERROR .... send error message .... ENDMON The date format parm may need to be chnaged to whatever format the char field has. I usually use the MONMSG if the error condition is hardly ever goning to happen, and I need the datefield anyway. Its got more overhead than the TEST(D). ================================================================ One way to "validate" a Date field is to use INSERT or UPDATE to write the value to the file. SQL will validate on input to a file and won't allow you to put values into columns that violate the data type. Standard I/O validates on reads. Validation on input happens once. Validation on read happens every read. IOW, if you spend cycles and programmer time doing the validation, the CPU cycles are going to be automatically spent again if INSERT/UPDATE is used. And you still need to code for SQL error conditions anyway. Additional validation for other fields/columns should probably also be done by SQL, or at least by DB2. Essentially anything that could be done with DDS (and more) can be done with constraints, e.g., ADD CONSTRAINT REVENUE CHECK (SALARY + COMM > 30000) can ensure that SALARY and COMM can't be updated or inserted with a value that isn't greater than 30000 for the sum of the two. This ensures that DFU, CPYF, whatever, won't be corrupting your database; and you don't need to add any code except to test for errors on output and displaying any errors to the user. Rather than coding specific tests for each field and making database maintenance programs complex, just issue the I/O statement and report errors. Tom

Validate that's is a true date? True date fields must contain real dates. You cannot enter a "bad" date in a date field. To test the 8A date field - there are two ways 1. use the TEST(D) command 2. Use MONMSG, for example MONMSG EVAL datefield = %date(charfield:*MDY/) ON-ERROR .... send error message .... ENDMON The date format parm may need to be chnaged to whatever format the char field has. I usually use the MONMSG if the error condition is hardly ever goning to happen, and I need the datefield anyway. Its got more overhead than the TEST(D). ================================================================ One way to "validate" a Date field is to use INSERT or UPDATE to write the value to the file. SQL will validate on input to a file and won't allow you to put values into columns that violate the data type. Standard I/O validates on reads. Validation on input happens once. Validation on read happens every read. IOW, if you spend cycles and programmer time doing the validation, the CPU cycles are going to be automatically spent again if INSERT/UPDATE is used. And you still need to code for SQL error conditions anyway. Additional validation for other fields/columns should probably also be done by SQL, or at least by DB2. Essentially anything that could be done with DDS (and more) can be done with constraints, e.g., ADD CONSTRAINT REVENUE CHECK (SALARY + COMM > 30000) can ensure that SALARY and COMM can't be updated or inserted with a value that isn't greater than 30000 for the sum of the two. This ensures that DFU, CPYF, whatever, won't be corrupting your database; and you don't need to add any code except to test for errors on output and displaying any errors to the user. Rather than coding specific tests for each field and making database maintenance programs complex, just issue the I/O statement and report errors. Tom