Re: Getting "hard halts" on years > 2039

Six digits dates are very convinient, but we have the limit at 2039. I
hope IBM will provide some option to "slide" the window, in the
meantime, it is possible to "fix" the problem by substracting 100 years
to the dates past 2039.

Like this: 2040-06-17 -%years(100) -> 1940-06-17 -> *DMY/ -> 17/06/40
-> *MDY/ -> 06/17/40.



On 04/22/2015 01:56 PM, Brian May wrote:

I agree it is the 1940 to 2039 window. Honestly, the "correct" way to fix it will be to migrate all dates into true date data types. This is not a small "fix". This will most likely be a major overhaul, but in the end, you will know it is done correctly.

Brian May
Solutions Architect
Profound Logic Software
http://www.profoundlogic.com
937-439-7925 Phone
877-224-7768 Toll Free



The IBM i Modernization Experts
www.profoundlogic.com



-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Bruce Vining
Sent: Wednesday, April 22, 2015 12:33 PM
To: Midrange Systems Technical Discussion
Subject: Re: Getting "hard halts" on years > 2039

Oh I'm sure it's the 1940 to 2039 window, but without you knowing what statement is failing I don't see how they can expect you to resolve the issue (with any certainty anyway). There are plenty of operations besides TEST that might fall over.

On Wed, Apr 22, 2015 at 11:01 AM, Dan <dan27649@xxxxxxxxx> wrote:

So, I was handed a project the other day to fix a problem with a
program that gets a "hard halt" (their terminology) when the program
encounters a date with a year > 2039. Since it's been over 15 years
since I've last had to think about this type of problem, I *think*
this has to do with the
1940-2039 window for 2-digit years. The fix is to change the edit
(TEST opcode, I'm guessing) so that it doesn't dump on a year > 2039.

I do not have an error message or a dump to work with. Not even
actual data. All I have is that the "program gave a hard halt when
the next payment date = 2040-06-17". (BTW, the lack of actual
errors/dumps is something I intend to address in our next programming
team meeting. This is, apparently, a common scenario for fix
projects. I'm new here, so I need to tread carefully.)

The immediate concern is to identify where this error is taking place.
My initial search is to look for TEST opcodes using the 'dtz-formats'
*YMD, *DMY, *MDY, & *JUL. The program has many different 6-digit date
fields, and even the term "next payment date" is ambiguous in this
large 20+ year old program.

Should the above search cover all of the bases? If not, can anyone
suggest what else to look for?

Are there still any free Y2K analysis tools available? In researching
this project, I was astounded by the number of 6-digit dates that
pervade not only the files used in this program, but throughout the system.

- Dan
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
Regards,
Bruce
www.brucevining.com
www.powercl.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

-- Este e-mail fue enviado desde el Mail Server del diario ABC Color --
-- Verificado por Anti-Virus Corporativo Symantec --