× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. COBOL400-L
  3. September 2016

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?

I did go back and found some notes in the manual about date fields being de-edited before moves - the implication being that they would be re-edited on assignment to the target. From that I think it should work - but then they go on to give examples of using functions to make the assignment between different types! Go figure!!

It is confusing and poorly documented.

At least they can’t blame me of that - I was long off the COBOL team when that was implemented!


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Sep 13, 2016, at 11:53 AM, Stone, Joel <Joel.Stone@xxxxxxxxxx> wrote:

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.



-----Original Message-----
From: COBOL400-L [mailto:cobol400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
Sent: Tuesday, September 13, 2016 11:11 AM
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?

Thinking about it some more Joel I’m inclined to think that you should report this as a bug to IBM.

Given the documentation for MOVE CORR it seems to me that either it should A) do it correctly OR B) should not consider the field’s to be corresponding in the first place.

In some ways the latter might be the “right” answer as at least you wouldn’t have to rename the fields.

I’m assuming of course that these fields were included in the corresponding operation as verified by using the *PRTCORR compiler option.

As a minimum IBM should be documenting that it won’t work.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Sep 13, 2016, at 10:35 AM, Stone, Joel <Joel.Stone@xxxxxxxxxx> wrote:

Hi Jon

Thanks for your response. I left out the following critical info - sorry about that. This is from the compiler spool file. (I did have the proper Conversion *DATETIME *DATE in the CRTBNDCBL command as shown below).

I am attempting to use what is probably the most common date manipulation from screen to DB: 09/13/16 on the screen should save in the db as 20160913.

It is disappointing to realize that iseries COBOL cannot handle this most simple common task :(

You are correct in your guess that MOVE CORR cannot handle dates properly. It is astounding to me that in 2016 the iseries still has trouble handling common everyday date fields. I will have to change the names of the screen date fields, so they don’t mess up the MOVE CORR statement.

I did some tests with MOVE vs MOVE CORR, and 30 lines of MOVEing each field from screen to db does work properly. Unfortunately that will add many lines of code to my pgm unnecessarily, but it does work.

Thanks for the assistance!!




COBOL Database field description:
06 CREATE-DT FORMAT DATE '@Y-%m-%d'.
CREATE DT
(Date field)


Display file field description:
06 CREATE-DT FORMAT DATE '%m/%d/%y'.
(Date field)




-----Original Message-----
From: COBOL400-L [mailto:cobol400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
Sent: Monday, September 12, 2016 7:22 PM
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?

It should be able to do it I think - but only if these were defined in the program as dates - and they do not appear to be. Is the display file field even defined in the DDS as a date?

Look like as a minimum you need the DATETIME compiler option discussed in the previous thread. That may deal with it - too long since I played with this stuff to be certain. It may be that MOVE CORR just isn’t going to cut it in this case and you’ll have to manipulate the fields “by hand”. All depends on how they are defined in the files.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Sep 12, 2016, at 5:32 PM, Stone, Joel <Joel.Stone@xxxxxxxxxx> wrote:

I would hope that COBOL is smart enough to be able to move a *MDY date to a *ISO date. However I am seeing error LNR7203 exception "The contents of date-time item does not match its format."

It is hard to tell what the exact issue is, because it is using MOVE CORR to move all the screen fields to the database fields, and there are several date fields.

Thanks!





OS400 v7r1

Conversion options . . . . . . . > *DATETIME
+ for more values > *DATE


CREATE-DT OF CSCMSTR OF CSCMST-REC OF CSCMST
CHAR(10) "2016-09-09"
"F2F0F1F660F0F960F0F9"X
CREATE-DT OF MAINT-I OF DISPLAY-REC OF DISPLAY-FILE
CHAR(8) "09/12/16"
"F0F961F1F261F1F6"X




--
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.


--
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.

--
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.


--
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.

--
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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.