Re: is COBOL ILE smart enough to move a screen-defined date field *MDY mm/dd/yy to a database-defined *ISO yyyy-mm-dd field?

You are correct about the four byte storage on disk Michael, but in this case a display file was involved which cannot use that storage method. In fact programs as such cannot actually see the date in that universal form. The database system converts from the underlying four byte integer to the format requested by the program on I/O.

RPG handles things a lot better than COBOL which sadly is always somewhat hamstrung by the need to maintain ANSI compatibility.

If I have time I will play a bit with COBOL dates to try and get a better understanding of what is going on.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Sep 13, 2016, at 12:51 PM, MichaelQuigley@xxxxxxxxxx wrote:

"COBOL400-L" <cobol400-l-bounces@xxxxxxxxxxxx> wrote on 09/13/2016
12:53:42 PM:

----- Message from "Stone, Joel" <Joel.Stone@xxxxxxxxxx> on Tue, 13
Sep 2016 16:53:17 +0000 -----

To:

"Cobol400-L@Midrange. Com" <cobol400-l@xxxxxxxxxxxx>

Subject:

Re: [COBOL400-L] is COBOL ILE smart enough to move a screen-defined
date field *MDY mm/dd/yy to a database-defined *ISO yyyy-mm-dd field?

Thanks for the follow-up.

Im not so sure the issue is with the MOVE CORR.

It’s a bit frustrating to debug because there are 30 fields on the
screen, so the MOVE CORR moves all 30 fields with like names. Any
errors with a MOVE CORR cannot be easily traced to which field is the

culprit.

It seems to work well at times, and not at other times. At this
point it looks like it may be data dependent, so I have to trace
things thru in debug and dump analysis and figure out which fields
are giving trouble and why.

There are so many moving parts with these dates in COBOL - it seems
hard to figure it out.

Something else has to be wrong here. I do moves like you're describing all
the time and there's no problem with formatting. One point to keep in mind
is that the system does not store "date" fields in the format we see them.
Rather they are stored as a Scaliger Integer or Julian Day number. (Not to
be confused with an ordinal date--commonly called a Julian date.) Hence,
there is not really any conversion between a *MDY date and a *ISO date.
They are simply external representations of the same Julian Day number.

I did a lot of research after I posted a comment about the dates actually
being stored as *ISO once. Someone else corrected me. Even a DSPPFM
command doesn't show the raw data, but converts it to *ISO before
displaying.

More information can be found at:
http://whatis.techtarget.com/definition/Julian-date
http://www.hermetic.ch/cal_stud/jdn.htm

IBM documents this somewhere, but I can't put my finger on it right now.
I'll do a little more digging. If I can find it, I'll post an update.

Michael Quigley
Computer Services
The Way International
www.TheWay.org
--
This is the COBOL Programming on the IBM i (AS/400 and iSeries) (COBOL400-L) mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.