Re: Getting "hard halts" on years > 2039 (RPG list)

If by hard error you mean something they have to respond to then it's
unlikely it is appearing on a TEST operation. Anyone testing the validity
of a date with TEST would put an indicator on it. Or a Monitor.

If's more likely it happened in some situation like this:
D mydate s d datfmt(*mdy)
D bigdate s d datfmt(*iso)

/free
*inlr=*on;
bigdate=%date('12/31/39':*mdy);
bigdate = bigdate + %days(5);
dsply bigdate; // DSPLY 2040-01-05
mydate=%date('12/31/39':*mdy);
mydate = mydate + %days(5); // RNQ0114
// The year portion of a Date or Timestamp value is not in
// the correct range (C G D F).
dsply mydate;
return;
This is what happens when you only migrate 'half way'. Meaning, way back
in the day you had some intense date calculations. And we had subroutines
in RPG to convert a "date" to some number that was an offset from some
date in history. Then we would subtract/add to that. Then there was
another subroutine to convert that offset back to a "date". Here they
were called $POPE and $ROME. Normally, if you just truncated years, you
didn't get hard halts. I suppose if your numeric representations number
of digits was exceeded unexpected situations could arise.
Now someone comes along and got confused by all the math and that someone
screwed up whether or not 2000 had a leap day. So they modified the date
conversion to use newer features. But still kept 6 digit dates. That is
when you are more likely to run into errors like RNQ0114.

Rob Berendt