Re: *DATE on DSPF program

Dave,

In a message dated 98-09-16 15:12:39 EDT, you write:

<<snip>>
> 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.

I dunno.  While they're easy to use and "handier than a pocket on a shirt", I
don't like using DDS-level validation for DSPF's for several reasons:

1.  The user has to press the <RESET> key.
2.  They execute before any program-level validation occurs, so the user
doesn't get all possible errors reported in one fell swoop.
3.  You have to use the <HELP> key, rather than <F1>, to get the extended text
of the error message.  With PC's, <HELP> isn't always mapped to <SHIFT>
<SCROLL-LOCK> so the user has to know two different ways to display extended
message text.
4.  They're completely useless for C/S applications.
5.  Adding new validations requires a re-compile of _BOTH_ the DSPF and *PGM
objects.

The console-like error message is pretty sloppy, did you have the ERRMSG
keyword on the field?  The dump doesn't have the invalid date because it is a
dump of the RPG program -- the DSPF never passed the value to the RPG because
it was invalid.  The buffer (ZZnnBIN in the dump, where nn is the logical
value of where your DSPF appears in the "F" specs) might have the invalid
value, but I'm not sure in this case.  

The buffer is something that you don't have to deal with much with externally-
defined display files, but those of us that did work on the S/36 cursed it
almost daily!  To simplify it, a display file has two buffers -- one for
input-capable fields and one for output-capable fields.  In the olden days,
you had an "I" spec for one and an "O" spec for the other.  Pretty much two
data structures that pass data in two different formats to the same object.

If the ERRMSG keyword was used, I don't think that the program should receive
this message...

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@aol.com

"Income tax returns are the most imaginative fiction being written today." --
Herman Wouk
+---
| 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
+---