Adam West wrote:
Also the dates in my file are YYMMDD. I would use the UDATE which is
MMDDYY..
Unless your code needs to be S/36 compatible, don't use UDATE. There
are many, many better ways to do things.
a) Do you really want the job date instead of the system date? The job
date reports the date that your job started (i.e. the date that you
signed on, or the date that a batch job was submitted). The system
date, by contrast, is the current date.
One nice thing about using the "job date" is that you can change it with
the CHGJOB command. You can change the job date, and that can be useful
for testing programs.
However, it's been my experience that using the system date is USUALLY
what people mean. For example, imagine that 5 years from now, your
company/client decides to have a "never-ending" batch job that's
submitted at IPL time, and it just sits in batch and does stuff. Then
one day it calls your program -- and since the last IPL was 3 months
ago, your UDATE code returns the date from 3 months ago instead of the
current date. Is that what you want it to do? If not, use the system date.
b) If you decide to keep the job date, you can get the job date in three
ways:
1) You can keep using the archaic UDATE. Problem is, it returns
the date in a 6-digit format, which means that it doesn't
know which century you're in. (Which caused many Y2K
problems -- remember Y2K?)
2) There's *DATE, which is identical to UDATE, except that it
returns an 8-digit date, and thus doesn't have the Y2K
issues. This requires V3R1 or later -- which hopefully
is a non-issue!
3) You can use a date-type field with INZ(*JOB) on the D-spec.
This is a much better option (IMNO) than UDATE or *DATE
because you don't have to muck around with the date format.
UDATE/*DATE are always in the job's date format, and the
user can change that, and it can be different per job
description, etc. It's never a good idea to hard code
*MDY or *USA just because "that's what UDATE is on my
system". When you use INZ(*JOB) on a date field, you
don't have to worry about the format, and your code will
work anywhere, no matter what the user specifies for their
date format.
c) If you decide to use the system date instead (much better, IMHO):
1) Historically this was retrieved with the TIME op-code
(for example, in RPG II or RPG III -- though, it still
works in RPG IV).
2) You can also specify %date() (the %date BIF with no
parameters) and it'll return the current system date
as a date field.
3) You can (similar to the job date) use INZ(*SYS) on a D-spec
to get the current system date.
d) Using a date field is better, even if the field is numeric in the
program. A date field can easily/trivially be converted to a
character or numeric field. It requires almost nothing.
%dec(myDateField: *ISO) <-- returned in YYYYMMDD
%dec(myDateField: *USA) <-- returned in MMDDYYYY
%dec(myDateField: *MDY) <-- returned in MMDDYY
%dec(myDateField: *YMD) <-- returned in YYMMDD
%dec(myDateField: *DMY) <-- returned in DDMMYY
There's a %char() BIF to convert it to character as well. In
character format, you can control which separators are used.
e) You can also easily convert a numeric date to a date field
with the %date() BIF. Just %date( field: format);
%date( filefield : *YMD) <-- reads from a YYMMDD field
and makes it a date field
f) Date fields can be compared against other date fields (even if
they're specified in different formats) without any problems. You can
easily add or subtract days, months or years from any date field.
With all of these options (and there sure are a lot of them) why would
you even consider using the old 6-digit job date in UDATE? IT just
doesn't seem like a good choice to me.
midrange.com
