MVSFORUMS.com

[infoman123]

Hi All,

In our system, there are lot of places where lot of cobol logic performing Julian to Greg, Greg to Jul , elapsed days between 2 julian dates, future & back date from a Julian date is performed.
Currently, these routines are performed for each record in the system. We are trying to look for a tuning opportunity here. In such a way that suppose for 1st recod, if these date checks are performed store it somewhere and if any of the later records are with same date use the already calculated value earlier for 1st record and avoid the date routine execution.

For eg
Record 1 date is 2010159 and it has to perform jul to greg, and future date after 1 month, back date before 1 month etc
Record 2 date is 2010160 and it has to perform jul to greg, and future date after 1 month, back date before 1 month etc
Record 3 date is 2010161 and it has to perform jul to greg, and future date after 1 month, back date before 1 month etc
--
--
--
Record 10 date is 2010159 and it has to perform jul to greg, and future date after 1 month, back date before 1 month etc
Record 11 date is 2010160 and it has to perform jul to greg, and future date after 1 month, back date before 1 month etc

What we are looking for is already the calculation for 2010159, 2010160 has performed for record 1 & 2, so these value has to store somewhere and should be used for Record 10 & 11 without recalculating it.

If the date routines are already performed for earlier records, the idea is to re use this for later records without again calculating it.

Can someone help, how can we achieve this with cobol. This will defenitely help us to save our batch window.

Regards

[dbzTHEdinosauer]

well, don't know if you are running IMS, DB2 or vsam.

one thing to consider is that if you attempt, during the run, to 'store' the calculations,
the extra cost of 'storing' the data has to be added to your run time.
then you have the additional overhead of reorg, etc....

there are only 366 potential days in a year. for a 10 year-time frame, this would be 3660 entries someplace (where ever you are going to store).

you have only shown us one calculation. how many types of calculations could be performed on one date? only adding 1 month, only subtracting 1 month.

if it is that simple, I would write a one-off program to populate whatever storage facility (ims, db2, vsam) that you employ. This program would have to take into consideration holidays, etc... But the program would only be run occasionally (yearly to extend for new, and to delete those dates that are too old)

each record/row would contain the julian date, the greg, and the calculated dates.
a simple read would replace the calculation routines.
properly buffered it could possibly be quicker that recalculation.

but again, keep in mind you are replacing potential CPU-boundness with I/O-boundness
_________________
Dick Brenholtz
American living in Varel, Germany

[dbzTHEdinosauer]

still don't know what you are doing, but if the date calculations are so intensive,
sort the file on date and expand the records to include the calculated dates.
that way you could off-load all the date calculation to one program,
since the file is sorted on date,
you could maintain the last calculated and skip the calculations if dates are same.
_________________
Dick Brenholtz
American living in Varel, Germany

[Dibakar]

I beleive logic for Greg to Julian conversion and looking ahead and back a month would be simple. So you can as well copy the logic of the called program in the caller to save time on calls.

Also check your date conversion utility to see if it can be optimised, it may be doing more calls and conversions at backend then you may need.
_________________
Regards,
Diba

[infoman123]

Thanks all.

Apologies if my explanation are not clear

Suppose these below are the fields in one record of a file. I am trying to explain it in a simple way but the logic of our program is quite complex to explain here.
Record1

[dbzTHEdinosauer]

you are going to expend resources 'saving calculation results'.

why not sort the file in date order?
_________________
Dick Brenholtz
American living in Varel, Germany

[prino]

The following code converts a date to a Julian Day Number, all arithmetic is integer:

[Dibakar]

[infoman123]

Thanks Prino..

For converting JD to greg and viceversa..dont need this complex logic... basically if we hard code all the equivalent dates in working storage for leap and non leap year.. thts more faster.. our program is coded like that...

Dibakar... as i explained these" - today, today -15, today + 1 year, today + 1 month, today -1 month" but actual program logic is more complex than this. all these date calculation in our program is based on some parameters defined.

basically what i'm looking is something like this
suppose i want find elapsed days between 2 dates date 1 => 2010159 & date 2 => 2010156, then if its caluclated already for rec 1, for for later records if the elapsed days required for date 1 & date 1, the ws-elapsed-days (date1,date2) should give result 3 which is alredy calculated.

[Dibakar]

informan123,

I think you need to answer two questions from Dick -

Why are you not pre sorting on date

How many date calculations are you expecting to save in memory

Also what is the date window of your calculations. From your questions it looks like the dates are falling in a short window, maybe couple of months from current date, thats why you expect lots of repeatation. If so specify the window for all the date fields that may occur in your calculation.
_________________
Regards,
Diba

[jsharon1248]

What leads you to this conclusion?

[infoman123]

[infoman123]

[jsharon1248]

You really haven't answered the question. Look at it this way. If you eliminated the date conversions all together, how much elapsed time would you save? Now, having said that, if 80% of the transactions are using the same date, why not add a snippet of code to bypass the date conversions if the dates on 2 consecutive records are the same. The converted values will already be in working storage. In your testing phase, add counters to determine how many date conversion are bypassed. Now you're in a position to run a parallel with the prod version to determine how much time you're really saving. Something like this:

[Dibakar]

I am trying to extend the solution propsed by jsharon1248.