FYI:
Had a developer who erroneously used *M thinking it was for *MINUTES, but that is really *MONTHS. *MN should be used for *MINUTES. And, due to the unique situation this wasn't really a problem, (just trust me on this). However it hit us here these last few days of the month.
There's a recent change to the Knowledge Center pointing out that *M can give unexpected results the last few days of the month.
From my email to the developer:
<coworker>
I have noticed one logic flaw.
// If zero hours, ensure >= 3 minutes to filter any pending.
if %diff(%timestamp():Fil.CrtTS:*m)>=3;
*m = *months
*mn = *minutes
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rzasd/bbdif.htm
Note: There is a recent update in that section!
| The results for *MONTHS and *YEARS may be surprising. See Unexpected Results. |<
If you click on that link you will see:
<snip>... , the following operations can give unexpected results:
Adding or subtracting a number of months (or calculating a duration in months) with a date that is on the 29th, 30th, or 31st of a month
</snip>
Sounds about that time of the month, eh?
</coworker>
The value of Fil.CrtTS is: 2020-07-30-15.14.25.000000
The value of %timestamp() should have been in the range of
Job 524576/MASTER/OPEMLUNSB started on 07/30/20 at 15:10:00
Job 524576/MASTER/OPEMLUNSB ended on 07/30/20 at 15:14:28;
I would hardly suspect that you would get a result of >=3 here
if %diff(%timestamp():Fil.CrtTS:*m)>=3;
But that does help to explain "may be surprising".
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.com
midrange.com
