IBM Mainframe Forum

Hi

I have julian and year in seperate fields..I need to copy that to a single field.
Julian-date is of PIC S9(03) comp-3 redefined to PICx(02).
Year is of PIC 9(04)..

and my o/p fileds is of length PIC s9(07) COMP-3 redefined to PIC x(04).

I have tried defining the 2 fields in a gropu var. and made move accordingly,




Now in the group field am getting as
WS-TEMP-JDYEAR



here 110 is the JD and 2011 is the year,,, this field is of lenth x(05)...
But my o/p field is of length PIC X(04).
How can I define fields so that I can get
1001
121C

This is a forum for beginners and students, not for people who cannot even read.

This is a forum for JCL. Packed Decimals and COBOL have nothing to do with JCL!

Am sorry...I have posted many queries on JCl and this is my first COBOL post...so in a hurry I have posted in JCL itself..n Do u have any idea on the query ...

these issues should be discussed with Your application support!
what are the standards for date handling inside Your organization!

anyway
the answer the solution is just basic, very basic, mathematic, ( not even mathematic, just arithmetic )

given also that the standard format for julian dates is YYYYDDD

or if You want to stick to Your illogic


and define the julian/garbag field as a comp capable of holding a 7 digit packed integer

The "standard" "Julian" (which it isn't, but that's not for this forum!) date is a 6 digit packed decimal value in 4 bytes with the format 0cyydddF, where c is 0 for dates from January 1, 1900 through December 31, 1999, 1 for dates from January 1, 2000 through December 31, 2099, yy is 01 through 99, and ddd is the day of year from 001 to 365 or 366 in a leap year, and F is an alternate packed decimal sign.

steve-myers wrote:The "standard" "Julian" (which it isn't, but that's not for this forum!) date is a 6 digit packed decimal value in 4 bytes with the format 0cyydddF, where c is 0 for dates from January 1, 1900 through December 31, 1999, 1 for dates from January 1, 2000 through December 31, 2099, yy is 01 through 99, and ddd is the day of year from 001 to 365 or 366 in a leap year, and F is an alternate packed decimal sign.

I suppose there must be some reason for that So instead of x'19' it is x'00' and instead of x'20' it is x'01'? Was there some fear that 81 centuries (OK, 80-and-a-bit centuries) wouldn't be enough, so they decided on 10?

Anyway, off the topic.



Moves to the 05. Then move to 01 to a comp-3 pic s9(7) (or pic 9(7) depending on what value you want in the sign, C or F).

If you want the day and year the wrong way round, just swap them in the definition above.

enrico's solutions will achieve the same results. The multiplies just being a means to "shift left" by 3 or 4 bytes respectively.

If you want the "standard", as above, first chop off the century (so PIC 99 for W-JULIAN-DATE-YY). Then move to a comp-3 of pic s9(5) (or 9(5), yaddady, yaddady...). Then, iterrogate the century. If 19, move an X'00', if 20, move an X'01' into field arranged as below.

The original OS/360 "Julian" data format was 00yydddF. I can remember thinking about what they would do for the 2000s as early as 1982 or so. I'm not sure exactly when IBM changed the format to 0cyydddF, but it was around that time. While 19yydddF and 20yydddF would work, it would also break a lot of existing code, both in IBM land and customer land.

Hi

garbag = days * 10000 + years

I have tried this,What enrico-sorichetti posted ...and it is working and I got the results as I required .
But wil it work every time throught...
I will try with what BillyBoyo has posted also..
Thank a lot for your response..

But wil it work every time throught...

mathematics id pretty deterministic ...
if the input respects the proper numeric bounds
no reason why it should not

Mann_B wrote:Hi

garbag = days * 10000 + years

I have tried this,What enrico-sorichetti posted ...and it is working and I got the results as I required .
But wil it work every time throught...
I will try with what BillyBoyo has posted also..
Thank a lot for your response..

I think you are missing something. enrico has give a solution which works in any language which supports multiplication. I have given you a Cobol-specific implementation of enrico's solution. You could do a COMPUTE in Cobol to implement it directly (I would comment the code to make it clear why you multiply part of a date by 10,000), but you can do it by defining the storage, an implementation you shouldn't need to comment for a Cobol programmer.

If you give it bad data, enrico's solution, and my implementation of it, will not work. If you give it good data, it will always work.