Dates in CFO and Julian format to mm/dd/yyyy format

rgupta71 · Posted: Fri Oct 30, 2009 3:50 pm

Is there any way through which we can convert the Julian and Cypros dates to external format(mm/dd/yyyy)?

Cypros Date:- Stored in COMP-3 format

mmmmmCdddC where mmmmm is No of months since 1900 ,ddd is the day of the month and 'C' is the signed bit of the COMP-3 varaible.

Julian Date:- Stored in COMP-3 format

nnnCdddC where nnn is no of the years since 1800 and ddd is the day of the year and C is again the signed bit of COMP-3

for Example:

External Date : 10/30/2009
Julian Date : 209C303C
Cypros Date : 01318C030C

enrico-sorichetti · Posted: Fri Oct 30, 2009 4:33 pm

Cypros looks like local jargon, if not I' ll be glad to add the term to my knowledge base

did you try at least to devise an algorithm to do it

looks very simple to me , a bit of simple arithmetic !

rgupta71 · Posted: Fri Oct 30, 2009 5:05 pm

@enrico-sorichetti

enrico-sorichetti · Posted: Fri Oct 30, 2009 5:13 pm

rgupta71 · Posted: Fri Oct 30, 2009 5:27 pm

U r right enrico-sorichetti about the IT standard but if we store Julian date in YYYYDDD format it will take 7 bytes. Storing it in the format of
year part :--- S9(3) COMP-3
Day Part :---- S9(3) COMP-3

will only take 4 bytes. So, for efficient use of space this format is being used.

Ragards,
Rahul Gupta

enrico-sorichetti · Posted: Fri Oct 30, 2009 5:37 pm

how old is the application design and implementation ??

the excuse is acceptable for an old application,
but then the relevant conversion routines should already be available
that what is done by decently competent people when using non standard formats for common entities

if the application is new the concern for efficient use of space is just plain bullshit...
if the data format requirement and specification were done by decently competent people
then they would not be using non standard formats for common entities

just think about using Your conflicting date formats fwhen accessing DB2 tables

anyway routines for such weird requrements should be written only once and made available to all the programming staff

again, where do You have issues...
with the logic or with the code ??

Robert Sample · Posted: Fri Oct 30, 2009 5:40 pm

1) Why not store the Julian date as PIC S9(07) COMP-3 and it only uses 4 bytes anyway?

2) More importantly, WHY ARE YOU WORRYING ABOUT 3 BYTES? The extra processing required to move things into and out of your specialized format probably costs orders of magnitude more than the storage space.

rgupta71 · Posted: Fri Oct 30, 2009 6:29 pm

We store year in just 2 bytes
for example year 2000 as 200C in COMP-3 format.

expat · Posted: Fri Oct 30, 2009 6:38 pm

Just wondered if binary has been considered here, after all, a seven digit Julian date could be squeezed into only 3 bytes, thus an extended saving of an extra byte

enrico-sorichetti · Posted: Fri Oct 30, 2009 6:41 pm

we can read quite well and understand the same...

here is some elementary math...
YYYYddd ==> seven digits + sign ==> 4 bytes packed decimal ( comp-something)

You can display/print it with a single move (YYYY/ddd)
You can sort it with a single field
the comparison can be carried on straight from system info
no ugly adjustments for data entry/output

YYY ==> 3 digits + sign ==> 2 bytes packed decimal ( comp-something)
ddd ==> 3 digits + sign ==> 2 bytes packed decimal ( comp-something)
total 4 bytes...
ok the same as occupancy

to print it
one addition to get the proper year plus two moves
two fields have to be specified for sort
some ugly adjustments have to be done for data entry/output

generalized routine are available all over for standard julian dates
even IBM LE/COBOL provided

for what You define as julian You are on Your own...
if the application is old why You are asking on a forum, ask Your peers or Your support
they must have already faced the issue... or not???

by the way Your julian is not a com-3, is the concatenation of two comp-3

enrico-sorichetti · Posted: Fri Oct 30, 2009 6:53 pm

3 hours since the initial post...
anybody would have alrady written, tested, deployed the whole thing

I wonder how long the TS will wait for a forum response ?
I asked at least to post his idea for the algorithm, but... I did not see anything yet

rgupta71 · Posted: Fri Oct 30, 2009 7:07 pm

Thank You everyone for your response.

We do have routines to convert dates but very frequently we are asked to make reports which require conversion of dates and to code in COBOL about which I am not so confident.
The reports are not of similar kind they vary a lot.I was wondering if we can achieve this in just a single sort step.

Reagrds,
Rahul Gupta

enrico-sorichetti · Posted: Fri Oct 30, 2009 7:22 pm

I had overlooked the DFSORT/ICETOOL forum..
and even if the thread shifted a bit off topic
still all the concerns I expressed are still valid

maybe Frank and Skolusu will be able to help You
at least for the julian/psudo julian part...
adding 1800 to the year will revert to an alrady solved problem

if You search for julian in the dfsort forum You will find quite a few matches for Your issue

converting from two fields to a standard julian should be easy enough..
one addition and one concatenation

sorry for the confusion

Skolusu · Posted: Fri Oct 30, 2009 10:28 pm

rgupta71,

What is the LRECL and RECFM of the input file?

what is the position and length of the Cypros date?

what is the position and length of the Julian date?

what is the LRECL and RECFM of output dataset?

rgupta71 · Posted: Mon Nov 02, 2009 9:42 am

@ Skolusu

Its LRECL is 714 and RECF is FB.

LRECL & RECF of o/p is same as i/p.

Starting position of julian date is 10 and Length is 4.

Starting posion of Cypros Date is 15 and Length is 5.

Skolusu · Posted: Mon Nov 02, 2009 11:21 pm

rgupta71,

*Sigh* How do you expect to a fit in 2 expanded dates into the same LRECL as the input?

You are expanding 2 dates each into 10 byte date and you want to have the same lrecl as the input without overlaying any of the input?

The following JCL will expand the 2 dates and put them at the very end of the file ie. 715(cypros date) and 726(julian date)

rgupta71 · Posted: Tue Nov 03, 2009 12:09 am

@ Skolusu

I will also use outrec to remove some unwanted fields.

Any way the position of date doesn't matter to me what matters to me was the conversion.

Thanks for you reply.