Re: *DATE on DSPF program

Dave,

I agree this is a problem.  The other problem we have with this is our custom 
date formatting code cannot get control unless a valid (according to the guy 
who codes date validations at IBM) date is entered.  We have used date fields 
for over five years, and this latest "enhancement" is a big step backwards in 
our case.  We have the same problem with database pre-action triggers.  They no 
longer get control unless all date fields are "valid".  We used to supply 
values for date record added, etc.  Can't do that anymore, we have to supply an 
useless value.  Setting an ALWNULL field null doesn't even seem to prevent the 
unecessary validation.  Another step backwards.

I like the idea of having the system validate dates, but would like more 
control over what is considered valid.  It would be nice if field, and field 
type validation could be supported through optional snap-in programs.  That way 
we could replace the standard date validation handler with our own.  In our 
case it would be just fine to have no date validation supplied at the entry 
point, because we there is no way it could get to the database.  Minimally, the 
date validation for database fields should happen after the trigger pre-action 
is called.

David Morris


>>> "Leland, David" <dleland@Harter.com> 09/16 12:09 PM >>>
I've posted this problem one other time but I was hopeful at the time
that it would be resolved by IBM.  Well, I've officially received the
word that it "works as designed".  So, now I'd like to know what you
think.

Background:
1)  Date data types can be placed on Display Files as of V4R2M0
(finally!)
2)  Error checking of date data types on display files is handled by the
internal error checker (terrific!)

Test:
1)  Create a simple display file with 1 input/output date field on it.
Place command key CA03 on it as well.
2)  Create a simple RPG program which does the following:
        Declares the display file
        moves *DATE to the date data type on the display
        does an EXFMT to the record format on the display
        does a RETURN
3)  Run the program.  When the screen displays, today's date should be
in the date field.
4)  Enter an invalid date and press enter.  The internal error checker
will tell you it's an invalid date and require you to press the reset
key.
5)  Now, press the F3 key to exit the program.  You will receive RNX0112
(Date, Time or Timestamp value is not valid.).

What do you think, should the program receive this error?  When you
answer the error with a "D", the dump doesn't have the invalid date in
it, but the original.

IBM's answer is that the date is in the "buffer" (whatever that is) and
that the internal error checker checks twice - once when enter was
pressed with the invalid date and again when the F3 (CA03) is pressed.

All comments welcomed.

Dave


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---