Re: Performance - Inventory & Allocations

[MacWheel99@xxxxxxx]

     [Al Macintyre]
Jos original question was day-to-day performance & we learned how to bypass 
portions of clean-up to make them run faster, but what does that bypass do 
for the day-to-day performance, which was the reason for the clean-up?

For those users who only access first few screens of history, or only need a 
few pages of a report, does it matter to their performance, that there's 
thousands of additional records on DASD that they won't be processing anyway, 
that we might leave on line & only off load once a quarter instead of once a 
month?

Does it matter if ITH is never resequenced by item & sequence # in INV900, 
because logicals exist, or is there a limit to the performance benefit of 
logicals when the physicals are large tangled?  We have 850,000 ITH records 
saved for 1 year.

     {Bill Robbins]
> You may want to consider the modification we made to INV970.  

     [Al Macintyre]
INV900?

     {Bill Robbins]
> We took out the logic that removed and re-sequenced the ITH records.  
> We do this now only on demand (not even twice a year).

     [Al Macintyre]
In BPCS 405 CD, INV970 only deletes ILI that have both zero balance and zero 
allocated.  Unless your end-month includes allocation reorg after this, such 
as SYS990 & INV971, Marc might want to add some allocation implication to his 
SQL.

     [Marc Lacelle]
> INV970D and INV972D should be part of your month end procedures. 
> The SQL statements are extras. You are right Otto 
> this procedure should be done after month ends and not before 
> (I did mention that). 

     [Al Macintyre]
INV972 is part of our mid week reorg ... are we creating a problem for 
ourselves?

    [Kent Van Horn]
> What impact does this have on open cycle counts?

     [Al Macintyre]
I think that if this stuff, either INV972 after INV900, or Marc's SQL & 
Bill's non-sequencing, is done during a well thought out end-of-month 
processing, then there is no impact because at one point in the end-of-month, 
any uncompleted cycle counts get closed.  The potential problem would be if 
anyone tried to do in the middle of the month any updates that belong in the 
end-month cycle, whether they are the SSA version or one of these short-cuts 
to the SSA clean-up.

Many BPCS programs do add records to various files as needed.

     [Rik Vermeir]
>  As I understood: the allocation program runs through all records on the 
>  ZEF file including all logically deleted records.  What we do now 
>  daily is  clearing physically those logically deleted records from ZEF.  
> After this deletion, the allocation works at a much higher speed.

     [Al Macintyre]
We run SYS120 once a week & did so last nite & it typically takes 1/2 hour to 
45 minutes to run through an awful lot of files & find out which need a 
reorg, and do so, but its directory ends at YPH.  ZOM & some other menu 
maintenance files were on our list of wasted bytes, so I got them through GO 
CMDRGZ.  Incidentally if ZEF is a perpetual problem for you, you might want 
to research if it makes sense to add to SYS120, which is possible via F16 
instead of F6 F18 F6 F6 but I would want to research that pretty good.

Al Macintyre
Central Industries of Indiana


+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---