View previous topic :: View next topic
|
Author |
Message |
Katharine Allen
New User
Joined: 01 Jun 2010 Posts: 8 Location: NY, NY
|
|
|
|
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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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).
Otherwise, I don't see a problem with the 2nd-Compute....
Bill |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
Katharine Allen
New User
Joined: 01 Jun 2010 Posts: 8 Location: NY, NY
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
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 |
|
|
Katharine Allen
New User
Joined: 01 Jun 2010 Posts: 8 Location: NY, NY
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
Glad to hear you got it working! |
|
Back to top |
|
|
|