Date performance

[awarren@xxxxxxxxxxx (Warren Andrew)]

I'm throwing out a recent experience in hope it may help 
someone else:

We recently Y2K remediated a report to use ISO dates. The 
pre-remediation
performance was good. The remediated performance was not.

The users melted the support line and threatened to storm 
the data center
with torches and pitchforks. They needed these reports for 
upcoming meetings.

We originally thought that the culprit might be an ISO date 
in the key field of
a logical file. The physical had 17 other logicals built 
over it.

We then noticed that the program was spending a lot of time 
doing a lookup
of a *USA date against a 500 element array of *ISO dates.

A small program was constructed that did 10,000 iterations 
of an ISO date lookup
against a 500 element array of dates. We chose the worst 
case, in which the
field did not occur in the array. When run, it pegged the 
CPU% and took 298
cpu-seconds on our S20. It did not appear to matter whether 
the dates were in the same format or not, as we changed 
everything to *ISO and got identical results.
It seemed to spend most of its time in _DT_CVT_DD.

We then modified the test program to use 8 digit packed 
numbers to represent the
dates. This took 2 CPU-seconds. We modified our report to 
use this and the
performance returned to near pre-remediation levels.

Other date datatype surprises, anyone?

Thanks,

Andy Warren
Ottaway Newspapers Inc.
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---