× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.