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?

Michael-

Yes I agree and am aware that the internal storage is an integer storage. However that is somewhat meaningless as I am not aware of any method to see that value.

Using COBOL or DBU or DSPPFM, I only see an interpreted, formatted value.

Good point, however COBOL still seems to have non-intuitive ways of handling dates.

Thanks

-----Original Message-----
From: COBOL400-L [mailto:cobol400-l-bounces@xxxxxxxxxxxx] On Behalf Of MichaelQuigley@xxxxxxxxxx
Sent: Tuesday, September 13, 2016 12:52 PM
To: 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?

"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