IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Converting Julian Dates to Gregorian in COBOL LE


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Katharine Allen

New User


Joined: 01 Jun 2010
Posts: 8
Location: NY, NY

PostPosted: Fri Nov 05, 2010 2:55 am
Reply with quote

Attempting to use LE to convert 5 digit Julian dates to Gregorian (and deep-six the old VS COBOL called submodule).

I've read lots of posts, and manuals, but keep getting stuck with the following:
I'm successful with converting from Julian to integer, but can't complete the process.

Running with IBM Enterprise COBOL for z/OS 3.4.0
Code:
DATEPROC(NOFLAG),YW(1995)

01  JULIAN-DATE.                                   
        10  JULIAN-CC                       PIC 99.
        10  JULIAN-DIGITS.                         
            15  JULIAN-YY                   PIC 99.
            15  JULIAN-DOY                 PIC 999.

01  JULIAN-DT          PIC 9(7).

01  GREG-DATE                       PIC 9(8).
01  DD                              PIC 9(7).

...

MOVE FIVE-POS-DATE   TO JULIAN-DIGITS.

IF JULIAN-YY > 80                 
   MOVE 19           TO JULIAN-CC 
ELSE                               
   MOVE 20           TO JULIAN-CC 
END-IF.                           

MOVE JULIAN-DATE     TO JULIAN-DT.

COMPUTE DD = FUNCTION INTEGER-OF-DAY(JULIAN-DT).

COMPUTE GREG-DATE = FUNCTION DATE-OF-INTEGER(DD).
==> IGYPA3312-E A date arithmetic result was found as a sender,
"Code"d

but the receiver was non-date "GREG-DATE (NUMERIC INTEGER)".
Execution results are unpredictable.

So the first compute is fine, but not the 2nd.
I'm sure I'm missing something obvious, but can't quite figure it out.

Katie
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Fri Nov 05, 2010 3:12 am
Reply with quote

You should make field DD PIC 9(09), to be safe and see if that does the trick.

An INTEGER-OF-DAY/DATE has a maximum value that can exceed 9999999 and perhaps that's the reason (just a WAG). icon_wink.gif

Otherwise, I don't see a problem with the 2nd-Compute....

Bill
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Fri Nov 05, 2010 6:22 pm
Reply with quote

One other question in regards to the Julian-Date.

Has the Julian-Date (after prefixing with the Century) been verified beforehand?

If not, a given COBOL DATE FUNCTION will crash and burn when a bad date is passed, instead of returning an error and will abend your program.

The funny thing is that under the covers, COBOL Functions call CEE* programs and CEE* programs (when called natively) have the ability to return a bad feedback-code (see next).

A common way (used by many shops) to verify dates is to use the LE Callable Service routine "CEEDAYS". You pass (as the 4th-parm) a 12-byte Feedback area, with the first two-bytes represented as a binary halfword.

However, you can verify the date manually yourself beforehand, by checking for Julian-Days of less than 001 or greater than 366.

If you're within a range of 001 and 366, CEEDAYS can then be used to determine whether this is a valid date or not.

Upon return, check these first 2-bytes, using reference modification for LOW-VALUES. If this is NOT true, then you've got a bad date.

Search this forum for CEEDAYS (as well as DATE-OF-INTEGER) and/or Google.

The Language Environment Programming Guide, for your LE version/release provides examples, although the syntax hasn't changed since its inception nearly 20 years ago.

IBM Book Manager link - publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/library

Mainframe Forum manuals link - www.ibmmainframes.com/manuals.php

Bill
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA

PostPosted: Fri Nov 05, 2010 6:35 pm
Reply with quote

If you are going to use the DATEPROC compiler option, you must specify
Code:
01  GREG-DATE                       PIC 9(8) DATE FORMAT YYYYXXXX.

And your code is not consistent -- you set the year window compiler option to 95, yet your code checks for year window 80.
Back to top
View user's profile Send private message
Katharine Allen

New User


Joined: 01 Jun 2010
Posts: 8
Location: NY, NY

PostPosted: Fri Nov 05, 2010 7:10 pm
Reply with quote

Program displays:

JULIAN INPUT 2010300
RESULT OF INTEGER-OF-DAY: 000149684

They seem to be o.k.

I'm going to try CEEDAYS for the 2nd phase since Date-Of-Integer does not work.

Thanks for the suggestions. I'll report back.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA

PostPosted: Fri Nov 05, 2010 7:15 pm
Reply with quote

Code:
       01  JULIAN-DATE.
           10  JULIAN-CC               PIC 99.
           10  JULIAN-DIGITS.
               15  JULIAN-YY           PIC 99.
               15  JULIAN-DOY          PIC 999.
       01  JULIAN-DT                   PIC 9(7).
       01  GREG-DATE                   PIC 9(8) DATE FORMAT YYYYXXXX.
       01  DD                          PIC 9(7).

       PROCEDURE DIVISION.
       MAIN-PARA.
           MOVE 20                     TO  JULIAN-CC.
           MOVE '10309'                TO  JULIAN-DIGITS.

           MOVE JULIAN-DATE            TO  JULIAN-DT.
           DISPLAY 'JULIAN DATE ' JULIAN-DATE.
           DISPLAY 'JULIAN DT   ' JULIAN-DT.

           COMPUTE DD = FUNCTION INTEGER-OF-DAY (JULIAN-DT).
           DISPLAY 'DD          ' DD.

           COMPUTE GREG-DATE = FUNCTION DATE-OF-INTEGER (DD).
           DISPLAY 'GREG-DATE   ' GREG-DATE.
produces results of
Code:
 JULIAN DATE 2010309
 JULIAN DT   2010309
 DD          0149693
 GREG-DATE   20101105
so DATE-OF-INTEGER works just fine.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Fri Nov 05, 2010 7:17 pm
Reply with quote

I would suggest getting into the habit of using COMP-3 Usage fields when doing arithmetic calculation.
the compiler generates code to convert the DISPLAY Usage to Packed-Decimal before a compute anyway.
Back to top
View user's profile Send private message
Katharine Allen

New User


Joined: 01 Jun 2010
Posts: 8
Location: NY, NY

PostPosted: Fri Nov 05, 2010 7:22 pm
Reply with quote

Yes, you are absolutely correct. I needed the window to be consistent, and the DATE FORMAT was required. I just tested it and had success. I knew I was missing something rather simple (once discovered), and had experimented with the DATE FORMAT but could not find much on it, and kept trying YYYMMDD - for instance.

Thanks again for spotting the inconsistencies - my specialty. ;)
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA

PostPosted: Fri Nov 05, 2010 7:30 pm
Reply with quote

Glad to hear you got it working! icon_smile.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Issues Converting From ZD to Signed N... DFSORT/ICETOOL 4
No new posts Replace each space in cobol string wi... COBOL Programming 3
No new posts COBOL -Linkage Section-Case Sensitive COBOL Programming 1
No new posts COBOL ZOS Web Enablement Toolkit HTTP... COBOL Programming 0
No new posts Calling DFSORT from Cobol, using OUTF... DFSORT/ICETOOL 5
Search our Forums:

Back to Top