*DATE on DSPF program

Dave,

I hope to explain some of what you are seeing and why you have received
some of the responses you have.  I do not have an "answer" for you,
but can hopefully clear up a few things anyway.

Internal to work station data management (WSDM), there is a working
buffer (WB) which contains the current values for all fields on the
display station (actually there is one WB per active record format on the
display).  When the user uses a CF key/ENTER/etc. the current display
values are moved to this WB and verified.  If one or more errors are
encountered (VALUES, RANGE, Date validation, etc.) then WSDM responds
with an error message.  When no errors are encountered, WSDM moves the
WB contents to the input buffer associated with the *DSPF and RPG
application, and returns control to the RPG program (or RPG runtime
anyway).  What is happening is that the ENTER key is causing the invalid
date to be loaded into the WB, the error is being reported, the CA key
is being used to bypass entry, and the WB (in it's last used invalid
state) is being returned to the RPG program.  RPG runtime appears to be
validating the Date field contents and is signalling the RNX0112.  Note
that the very same thing (except for the RNX0112) occurs with VALUE
DDS checking.  If a VALUES('A' 'B' 'C') is defined and the user enters
"E", ENTER, CA then the RPG program does indeed get 'E' returned (but
as there is no datatype error you don't get an explicit error message).
This situation is documented in the DDS manual under CAnn as part of
Validity Checking Considerations with suggested workarounds of 1) don't
use CA keys or 2) don't use functions such as VALUES, RANGE, CHECK(VN),
etc.  As Date validity checking is done in the same manner as these
other DDS keywords (that is, in WSDM and not the work station controller)
it falls into the same classification.

Please note that I am not saying the above is "right" or "wrong", rather
that that is what is currently happening.  Personally I think the
current behavior is lacking in certain useability areas, but it is indeed
working as documented and designed.  Now a possible change, such as
maintaining a second copy (unchanged) of the WB for priming the input
buffer in CA situations would appear to solve the above problem (high
level and ignoring little things for now like subfiles); but it would
cause an increase in storage requirements, be totally incompatible with
currently documented behavior (and from past experience I am confident
someone out there is relying on this current "feature"), and have a
performance impact.  Because of these considerations I would not expect
a 24 hour APAR/PTF fix to be coming though I suspect this problem is
being looked at by WSDM and Y2K developers.

I know this isn't going to make your current problem go away, but I
usually find that knowing what's going on helps some.

Bruce Vining

>
>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
+---