Hey all,

So, I have a few drill reports that have the following COMPUTEs in their table request blocks:

Level 1 drill:

COMPUTE SellRatio/D10.3% = ABS(( CreditSell / ABS(SELL_AMT) ) * 100);
COMPUTE YTDSellRatio/D10.3% = ABS(( YTDCreditSell / ABS(YTDSell_Amt) ) * 100);

Level 2 drills (both have the following):

COMPUTE SellRatio/D10.3% = ABS(( RADNET / ABS(&NETSELL) ) * 100);
COMPUTE YTDSellRatio/D10.3% = ABS(( YTDNet / ABS(&YTDNETSELL) ) * 100);

These 2nd level drill reports just crash with the 32027 hard kill error. So, I've placed a -EXIT after the request portions of the procedures to try and troubleshoot possible issues. The only error I can/do get if any is one for the top COMPUTE saying ABS() doesn't have the right amount of arguments (which is 1). Or, I do not get any error at all and things just crash with the 32027 error. (Note: When I drill to the level 1 drill, things run fine.) These procedures were migrated from 7.x to 8.x and ran without a hitch on 7.x. I never changed these COMPUTEs from what syntax they had in the old environment either.

I noticed in the output for the top compute where I could get the above error that there was indeed nothing between the ABS() brackets for an argument where &NETSELL was supposed to provide a value. I ran its parent report to find that any records where the &NETSELL value is empty/missing that are drilled to throw the 32027 crash error. I attempted to see if I could SET NODATA = 0 to see if that would work. Nope. Then I thought to myself, maybe it is crashing due the COMPUTE trying to divide by 0. But that shouldn't be the case because the level 1 drill report was doing that and running without a problem. I also can get the level 2 drills to run without a problem if I drill to them from records where the value of &NETSELL is not null/empty. The even more mind boggling thing is I tried SET NODATA = 1 to see if things would run then, and nope. I get crashes even still! At some times I get the crash for a level 2 or even level 3 drill of the same procedures in offense and can get the output source luckily and there are no (FOC#####) errors to be had! How can I troubleshoot something that crashes but never gives any indications as to why it crashed? SO frustrating. I guess I can try setting XRETRIEVAL to OFF as well and see if I can get anything more than what I'm currently getting.

If anyone here has had similar issues when migrating, and has found a good "system" of steps they could take to always find the offending code, please let me know. Thanks for your help!

This message has been edited. Last edited by: CoolGuy,

quote:

Level 1 drill:COMPUTE SellRatio/D10.3% = ABS(( CreditSell / ABS(SELL_AMT) ) * 100);
COMPUTE YTDSellRatio/D10.3% = ABS(( YTDCreditSell / ABS(YTDSell_Amt) ) * 100);
Level 2 drills (both have the following):COMPUTE SellRatio/D10.3% = ABS(( RADNET / ABS(&NETSELL) ) * 100);
COMPUTE YTDSellRatio/D10.3% = ABS(( YTDNet / ABS(&YTDNETSELL) ) * 100);

A few questions:

1. What purpose is served by the inner ABS? Regardless of the sign of its argument, the outer ABS will yield a non-negative result.

2. In the Level 2 execution, do you expect the string-value of &NETSELL and &YTDNETSELL to be a numeric value obtained from the source of the drilldown, or the name of a column?

(If a value, and that value can be zero, you probably should add a condition (WHEN) in the drilldown code to avoid such a call.)

Jack,

Answers to your questions:

For your first question, I agree with you. I was wondering the same. I figure the outcome will be the same no matter if that inner ABS() exists or not due to the outer ABS(). I'm tasked to bring this and other non-commented code over from an old environment. So, why the original devs have made various coding decisions is beyond me.

For your second question, I've found that the value of NETSELL and YTDNETSELL are taken from fields from the request in the first level drill, and passed as values in the drills (i.e. NETSELL=N5, etc.) to the 2nd, 3rd, etc. levels and then referenced as amper variables in those, and that is where the errors are happening.

I had another dev look at it and he found and thinks that the strings getting passed that define the store name that have apostrophes in them aren't getting parsed correctly due to such. I'm going to try and strip the apostrophes out and see if that fixes things at all as well. I will update this post as soon as I make any progress.

Thanks Jack.

Either the parent fex has to avoid calling the child and passing a null parameter value, or the child has to play defense and adjust the parameters as needed (-DEFAULTs, and -IF ... SET ... )

Thanks Jack for your advice. I did as you have directed and the drills are now working at that point. I still have drills in other places not working and crashing with a hard kill error, but I can't seem to get them to give me any error messages no matter if I've added -EXITs in conjunction with -SET &ECHO = 'ALL';, or even setting XRETRIEVAL to OFF. I may open a case on those though. I hope IBI implements better error handling and stack tracing at some point.

Again, thanks.