UYEAR

[bvining@xxxxxxxxxxxx]

Wendy,

UYEAR is defined as a 2-digit value, and to change that to 4 digits
would cause a level of incompatibility which is very much frowned on
in AS/400 circles.  The 4-digit solution is indeed *YEAR.

A couple of comments though.  One, most of the system when working with
2-digit years uses a window of 1940 to 2039.  The current application
approach of UYEAR *GE 50 could potentially cause confusion in the future.

Two, the comparison of UYEAR to 50, and related moves of '19' or '20',
might be simplified by using the 2-digit century value provided in the
Program Status Data Structure at decimal offsets 199 and 200.  Just
moving this in directly would allow you to continue using UYEAR and still
get the right 4-digit year.  That is:

   Dmypsds          sds
   Dcentury                199    200  0
   C                   move      udate         year              4
   C                   movel     century       year
   C     year          dsply

correctly shows year as 1930, 1998, 2050, and 2070 when changing the
current jobs date.  Doing this, of course, assumes that just using the
2-digit UYEAR is a safe practice in some parts of the application.
Otherwise the application should just change over to *YEAR and be done
with it.

Bruce Vining

>
>Does anyone know if UYEAR is going to 4/0?  Or will there be a *YEAR?  We're
>trying to finish up 2k & some old stuff is calculating 4/0 current calendar
>year & fiscal year from UYEAR & plugging century (If UYEAR *GE 50, movel 19
>year... else movel 20)  It works & I'd just as soon cross these programs off
>the "To Do" list...
>
>Wendy Brenzel
>

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