RE: legacy date hell

My only thought on your reply, Brian, is that 99 99 99 input would require a
background changing to a legitimate date, IF there is any kind of
date-editing done at any point. If not, then that could work, but to allow
the 999999 on the screen to be written to the table could inadvertently
create another issue elsewhere in the system where an edit process is in
place.

Steve

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Brian
Parkins
Sent: Tuesday, August 25, 2020 10:15
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: legacy date hell

Correct me if I am wrong. You are holding dates as 8-digit numeric values
(8S0) in the table, but displaying them as 6-digits (3 x separate
fields) on the 5250 display?

The User wishes to specify a future date value (i.e. 31st December 9999) so
the record will never "expire"?

How about allowing 99 99 99 on input (as distinct from 21 31 99). This will
identify as "never expire". Modify the table to denote the 8S0 field as
null-capable. If 99 99 99 is entered, set the field to null.
(More coding necessary to handle null-capable fields.)

Alternatively, could you introduce an additional (century?) flag-field to
denote "never expire"? (Smart use of views / logicals would minimise the
database impact but still need some coding changes.)

Just some suggestions. (Personally, I would go for the refactor option AND
implement proper dates fields in the table(s) instead of 8S0.)

HTH.
Brian.

On 25/08/2020 14:18, Jay Vaughn wrote:

So we have an input date on the screen as 3 separate fields... mm dd
yy

Biz wants the ability to put a "max" date of 12/31/9999 in so that
this record never expires.

I guess they didn't review the 2 digit year on the screen first...
because if you put 99 in then when it comes time to store that input
into the table where the date is 8s0, then it will think it is 1999.

And if we do store the date in the table as 12/31/9999, whenever any
other pgm tries to convert from *ISO to *MDY, the pgm will blow up,
because 9999 is not a valid date for *MDY.

So the way I see it the options are, train the user to input 39 into
the screen yy for the max date which is the least invasive approach
(and will create a new y2k scenario). OR expand screen date year to
yyyy and refactor any and all pgms that convert this 8s0 date from
*MDY to *ISO to handle the 9999 stored year correctly.

Pretty sure they will want to go with the 39 approach as they "claim"
the system will be decommissioned in a couple years (which I've heard
that a million times before).

Any other suggestions I am overlooking?


tia

Jay

--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a
message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com