IMO it would be easier just to add a keyword for DATFMT to the command so
you can specify the output format you want. that maintains the backward
compatibility and gives us an option to change the behavior if desired.
Thanks,
Tommy Holden
From: Simon Coulter <shc@xxxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 06/24/2010 05:28 PM
Subject: Re: Problem solved, Re: Sorting DSPOBJD outfile by
ascending date
Sent by: midrange-l-bounces@xxxxxxxxxxxx
On 25/06/2010, at 2:18 AM, Mark S. Waterbury wrote:
Does anyone know why this works this way?
Not with certainty but educated supposition suggests it was a mistake
either by accident or poor design:
Scenario 1:
DSPOBJD was one of the first commands to get outfile support. It's
possible that outfile standards had not yet been put in place. A naive
developer (new co-op?) used MMDDYY because what other date format is
there? and once it was released it could not be corrected because
"someone" might have code that relies on that format. Users in other
countries would already have dealt with the dumb date format and if
changed their code would break too.
Scenario 2:
DSPOBJD was one of the first commands to get outfile support. The
internal date format for object creation and change is an 8-byte
machine timestamp which (at least then) needed to be converted into an
external format. Most users would be in the USA so to make life easier
for them the date format was MMDDYY. Other users could use CVTDAT to
alter it--and I think outfile support was intended for consumption by
CL.
Scenario 3:
Someone screwed up. Can't change for backward compatibility reasons,
no-one complained--USA users didn't see the problem, foreign users
just dealt with it, etc. etc. etc.
Fixing:
Could easily be fixed by adding new fields in YYMMDD format (or proper
date types) to the end of the format. New code could use the "correct"
fields. Old code will continue to use the "wrong" fields. Outfiles are
created with LVLCHK(*NO) so this process will work seamlessly.
However, DCRs will need to be submitted else Rochester won't know you
want it fixed.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
