IBM Mainframe Forum

Hi all,

we have Cobol Programs having internal Date subroutines to calculate date difference and converting julian to Gregorian and vice versa
My question is these subroutine are calling for every input record and doing some date calculations.

can we use intrinsic date functions for date difference and converting julian to Gregorian and vice versa(Date-of-integer, integer-of-date) ?
then performance wise which is better(subroutine or intrinsic date functions)

You're not going to know which performs better without actually testing each method. There's too much variation in the way things can be coded to just state blindly that such-and-such method is better.

My question is the internal date subroutine is calling dynamically, every time for each record, why don't we use date functions(converting julian to geo)? I am thinking performance will increase, please advice

As Robert has already said, why don't you try it yourself. We don't have your date routines. You try, maybe let us know.

Do you mean, performance wise we can't say which code is best rgt..please advice(confused becoz
calling dynamically will reduce the performance as per my knowledge)

for 1 million input records

the below code will do 1 million times in the same program
suppose I want to convert Gregorian date to Julian using
FUNCTION DAY-OF-INTEGER (FUNCTION INTEGER-OF-DATE (any-date))


The below routine calling 1 million times in the program

call WS-DATE subroutine

So why are you asking us?

If you're not going to try it, we're certainly not. One might have better performance over the other, but to know if it worth changing for is a different thing. A dynamcially called sub-program is only loaded once, then it is pretty similar to a static call (branch to an address).

My question is the internal date subroutine is calling dynamically, every time for each record, why don't we use date functions(converting julian to geo)? I am thinking performance will increase, please advice

Some of the COBOL facilities become in-line code while others become subroutine calls during the compile process. I don't know which way the date functions are implemented, so I cannot tell you that changing from your called routine to COBOL intrinsic functions will have ANY performance difference. There might be, there might not be. If you don't test, you won't know. And since your date routines are not installed at our sites, we cannot do the testing for you.

Performance can be a very complicated subject, since there are many many many factors that come into play. The reason we are telling you (repeatedly) to test is that we cannot know the factors influencing performance of the two methods at your site, so we categorically cannot tell you arbitrarily which method will perform better. You can restate your question 10 ... or 20 ... or 100 times and it's not going to change our answer. Either test both and find out for yourself, or implement one or the other without testing. But do not expect us to just give you an answer -- especially since there's a chance either answer is wrong.

Dang, that's the second time today I've lost a post (without copying it first) and I also lost one for another poster. Oh well,
it was along pretty similar lines to Robert's post, so I won't bother writing it again. The only things I'd add is that we had a question on March 15 where it turned out exactly those routines didn't work for one site's compiler. If there are performance issues, it is a management decision (sounds like a lot of code to change) and might not be to do with the dates anyway. Why not hold the julian dates as well as the gregorian dates on file, if you are worried it is such a performance problem?

You're asking an impossible question of us, and we're trying to show you why it is impossible. Do the tests and let us know. We don't know, can't know, the date routines are yours, fast or slow. No point in us sagely "guessing".

Hi BillyBoyo and Robert Sample.., thanks for your valuable inputs

I'll add my €0.02

PL/I has a whole series of builtin functions to manipulate dates. Many, if not most, of them (like Cobol, I guess) use LE routines to do the actual conversions. I have PL/I code that works from 0001-03-01 until 9999-12-31, can handle the 10 missing days in October 1582, uses only integer arithmetic and is a hell of a lot faster than the PL/I builtin functions.

Another thing you might want to do is sorting and caching.