Re: Ideas on cutting run time

[DAsmussen@xxxxxxx]

Mark,

In a message dated 98-07-24 11:30:47 EDT, you write:

> We have a program that runs each night that is the majority of our
>  nightly processing time.  This job ran for about an 70 minutes last
>  night.  There are no users or other batch jobs on the system while this
>  job is running.
>  
>  Any ideas on making this run faster:  Last night MU7TRANS had 410,663
>  records for that 70 minute run.  The L1 fields are the key to the file
>  and the select criteria is used so only records we want are in the file
>  (all need processed).

I don't see much code-wise that would speed this up.  You could replace the
CABEQ code with IF/ELSE logic, use *LIKE DEFN instead of line-level field
specs, and use MOVE *ON/*OFF instead of SETON/OFF -- but I don't recall how
much (or _IF_ ) these will actually help performance and nano-seconds aren't
what you're looking for anyway.  You could also use a CL front-end to perform
an OVRDBF on MU7TRANS to increase the blocking factor, but you've already got
_some_ blocking due to the fact that it's a primary file.

Have you performed a WRKSYSTS to see if the memory pool for the subsystem is
experiencing high page faulting levels?  If page faulting is occuring, you
could automate changing the pool sizes at night to pull memory from the
subsystems that aren't in use, then put them back to daytime settings after
the job runs.  If paging is OK and you have the memory for it, you could use
SETOBJACC to put the files into memory during processing and take them out
when finished (but watch the faulting again).

HTH,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@aol.com

"One of the greatest labor-saving inventions of today is tomorrow." -- Vincent
T. Foss
+---
| 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
+---