Re: Ideas on cutting run time

[Mark Lazarus <mlazarus@xxxxxxxx>]

Dean,

At 02:01 PM 7/24/98 EDT, you wrote:

>> 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.

 I don't think that what you are saying is accurate.  The primary file is
defined as Update, so it won't be blocked.  One suggestion is to change the
update primary to input primary, and block it to the max.  Then do a chain
to a *LF to do the update.  There shouldn't be much overhead, since the
record is already in memory.

 -mark

+---
| 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
+---