 Former Member

# BPC 7.5 NW - RUNALLOCATION combined with FOR NEXT performance issue

Hi,

We are using a script that runs 21 allocations within a FOR NEXT loop. Each allocation calculates a different rate that we need for further planning purposes.

We need the FOR NEXT loop since the allocations have to be calculated for each profit center that is indicated as a regional profit center (these are not base level members in the PARENTH1 hierarchy). In the WHERE clause we then post the result of the calculation on a dummy profit center which is equal to "H_%PROFCENT%".

We also run the same calculations for what we call the REAL profit centers (these are base level memebers of the hierarchy). Here we do not have to do a for next loop because we just left profit center out of the allocation so that it runs for all the profit centers. These allocations go very fast. So it is the combination of the for next loop with the 21 allocations that take so much time.

The problem we have is that for only 20 profit centers the allocation takes a very long time. Se we wonder if there is any faster way of running these calculations for each profit center individually.

Do you guys see any way of avoiding the for next oop and still running the allocation for all these regional profit centers?

Kind regards,

Christophe

Here is a part of the coding we use (I only show 2 of the 21 allocations taht should be run):

//0.b Set Variables

//----

*SELECT(%PROFCENTREG%,"[ID]",PROFCENT,"[REGIONAL]="REG")

*FOR %PROFCENT1% = %PROFCENTREG%

//1. CTR_RATE - Contract Type rate - REG

//----

*RUNALLOCATION

*FACTOR=USING/TOTAL

*DIM TIME WHAT=[PERIOD_TYPE]="P"; WHERE=[PERIOD_TYPE]="P" AND [PERIOD_TYPE]="F"; USING=[PERIOD_TYPE]="P2"; TOTAL=[PERIOD_TYPE]="P2"

*DIM BUSAREA WHAT=NABA; WHERE=VA; USING=<<<; TOTAL=<<<

*DIM CATEGORY WHAT=TESTCALCS; WHERE=TESTCALCS; USING=ACTUAL; TOTAL=ACTUAL

*DIM CTRTYPE WHAT=BAS(TOTCTR); WHERE=BAS(TOTCTR); USING=BAS(TOTCTR); TOTAL=BAS(TOTCTR)

*DIM ORIGIN WHAT=EXIST_LIS; WHERE=<<<; USING=<<< ; TOTAL=<<<

*DIM PRODUCT WHAT=NAPRODUCT; WHERE=SEB_MAINT; USING=<<< ; TOTAL=<<<

*DIM RCATEGORY WHAT=DUMRCAT; WHERE=<<<; USING=<<< ; TOTAL=<<<

*DIM RPTCURRENCY WHAT=LC; WHERE=<<<; USING=<<< ; TOTAL=<<<

*DIM SEBACCOUNT WHAT=COUNTER; WHERE=CTR_RATE; USING=SALES_M ; TOTAL=SALES_M

*DIM PROFCENT WHAT=H_%PROFCENT1%; WHERE=H_%PROFCENT1%; USING=BAS(%PROFCENT1%); TOTAL=<<<

*ENDALLOCATION

//2. COSR_RATE - Callout and service repairs rate (LIS - ORIGIN Callout) - REG

//----

*RUNALLOCATION

*FACTOR=USING/TOTAL

*DIM TIME WHAT=[PERIOD_TYPE]="P"; WHERE=[PERIOD_TYPE]="P"; USING=[PERIOD_TYPE]="A" AND [PERIOD_TYPE]="P2"; TOTAL=<<<

*DIM BUSAREA WHAT=NABA; WHERE=VA; USING=<<<; TOTAL=<<<

*DIM CATEGORY WHAT=TESTCALCS; WHERE=TESTCALCS; USING=ACTUAL; TOTAL=ACTUAL

*DIM CTRTYPE WHAT=CTRDUM; WHERE=CTRDUM; USING=BAS(TOTCTR); TOTAL=BAS(TOTCTR)

*DIM ORIGIN WHAT=EXIST_LIS; WHERE=CALLOUT; USING=CALLOUT ; TOTAL=EXIST_LIS, LIFS

*DIM PRODUCT WHAT=NAPRODUCT; WHERE=SEB_MAINT; USING=<<< ; TOTAL=<<<

*DIM RCATEGORY WHAT=DUMRCAT; WHERE=<<<; USING=<<< ; TOTAL=<<<

*DIM RPTCURRENCY WHAT=LC; WHERE=<<<; USING=<<< ; TOTAL=<<<

*DIM SEBACCOUNT WHAT=COUNTER; WHERE=COSR_RATE; USING=SALES_M ; TOTAL=SALES_M

*DIM PROFCENT WHAT=H_%PROFCENT1%; WHERE=H_%PROFCENT1%; USING=BAS(%PROFCENT1%) ; TOTAL=<<<

*ENDALLOCATION

10|10000 characters needed characters exceeded

### Related questions

Posted on Dec 15, 2010 at 10:12 AM

Hi Christophe,

Does the allocation run with 21 profit centers just take 21x longer than the allocation run with 1 profit center, or is there a bigger multiple involved? I guess I'm curious what the actual runtimes you are seeing look like. If it's only 20-30x longer for the 21 profit center allocation, then I think this is expected. If it is much longer than that, there is something wrong and we can try to help you figure out what is going on.

Cheers,

Ethan

10|10000 characters needed characters exceeded
• Former Member Gersh Voldman

Hi Gersh,

Kind regards,

Christophe

• Former Member
Posted on Dec 15, 2010 at 09:53 AM

Hello Christophe,

I use the same procedure in one of my projects. I have to loop just over about 10 IDs and my script also runs for a while. Without the loop it is much faster, but the loop is needed in some cases.

I think it is a script logic limitation. Currently the performance of some scripts is really weak and sometimes you cannot do even basic calculations with it. Hopefully it will get better and faster in the future.

The only workaround would be to have separate scripts and run them in a chain, but this would be versy difficult to maintain. I recommend to wait for future SPs which may improve performance.

Jan