HP3000-L Archives

April 1998, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Ray Potts <[log in to unmask]>
Reply To:
Ray Potts <[log in to unmask]>
Date:
Thu, 2 Apr 1998 21:46:37 PST
Content-Type:
text/plain
Parts/Attachments:
text/plain (31 lines)
This is a little late, since I've been away from the office, but
I would like to thank everyone who replied concerning the time it
takes to call function current-date in cobol.  The replies really
confirmed what I already thought, basically that this call does
a lot more and returns more info and so, takes more time.

I also have some more info, for anyone who is interested.

I wrote a c routine which uses the 'localtime' function and
replaced my call to function current-date.  The times came back within
1/2 second.  This sort of confirmed by thought that the function
current-date call was using these same functions and that the
functions are just slow.

Then for grins, I ran the same tests on our 9000.  The program using
the c calls was as fast as using the plain current-date move.  But
when I tried the function current-date call, using microfocus cobol,
it was as slow as the function call on the 3000.  Very Interesting.

BTW, for those who are asking 'Why would a program need to find the
current date so many times, that the time would be an issue?' we
have a centralized routine which does all of our date converts.  Every
time it's called, it initializes a variable to the current date in order
to get the year and century, if they are not passed.  We changed the
routine to only get the current date if the century isn't passed and
problem solved.  It's still interesting though.

Thanks again.

Ray Potts

ATOM RSS1 RSS2