RE: *DATE on DSPF program

Thanks (I guess) for the information.  Not what I wanted to hear but it
did help to lower my temperature a little.  It just seemed like this
must have been a problem that could be easily corrected w/ a PTF.  Now
that I understand why it's happening, I can decide which work-around I
want to use (change CA keys to CF or use the *PSSR routine).

Thanks again for the info,
Dave

> ----------
> From:         bvining@VNET.IBM.COM[SMTP:bvining@VNET.IBM.COM]
> Reply To:     MIDRANGE-L@midrange.com
> Sent:         Thursday, September 17, 1998 12:50 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      *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
> +---
> 
+---
| 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
+---