One for the old timers.... v 9.0

[Steve Rowe]

Hi,
I'm having the pleasure of developing on v 9.0 (SP3 U9) and I'm wondering if anyone can remember any defects in this area as I am getting an instance crash which I have been unable to code around (yet!). With a multi hour restart and an upgrade not possible it is proving rather frustrating....

Below is the prolog, the general sequence of which I have used many times in this environment (i.e. declare global vars and build a view).

If I process quit after the view build then the TI executes without issue.

In the current state the TI crashes the instance on the asciioutput line (I get an empty t.cma$ in the DD).
If I have the subset insert in play instead the instance still crashes.
If I change the cube the view is referencing the instance still crashes.
TI crashes with both none data source and a view.

The only obvious difference is that this view has consolidations un suppressed, does this ring any bells? If the view I was creating was itself causing an issue I would not expect it to crash until I actually do something with it....

Stumped....

Code: Select all

StringGlobalVariable('sCubeCPPair');
NumericGlobalVariable('nNextLog');
StringGlobalVariable('sCubeAssumption');
StringGlobalVariable('sCubeProp');
ExecuteProcess('Jnl.ChangeRequest.VarDeclarations');

#Local Variables

sProcessMe = 'Jnl.Update.CPPairToCPGroup.FileSize';
sDimProduct='Product';
sDimChannel='Channel';
sDateTimeLocal=TIMST (Now() , '\Y\m\d\h\i\s');
sRand=Subst(NumberToString(Rand),2,10);
sObjectName=sDateTimeLocal | sProcessMe | sRand;

 #Build view for the source

#Will be slow highly summarised

sCubeName=sCubeAssumption;
ExecuteProcess ('Generic.View.Create' ,
'pCubeName', sCubeName ,
'pViewName', sObjectName ,
'pSkipRules' ,1 ,
'pSkipConso' , 0 ,
'pSkipZero' , 1,
'pD1' , sObjectName,
'pD2', 'A',
'pD3', 'A',
'pD4', sObjectName,
'pD5',  sObjectName,
'pD6', sObjectName,
'pD7', sObjectName,
'pD8', sObjectName,
'pD9', sObjectName
);

 sDimName=TabDim(sCubeName , 1);
sElName='test';
#SubsetElementInsert(sDimName, sObjectName, sElName, 1);
asciioutput('t.cma' , sDimName , sElName);

 <snip>

[Alan Kirk]

I'm having the pleasure of developing on v 9.0 (SP3 U9) and I'm wondering if anyone can remember any defects in this area as I am getting an instance crash which I have been unable to code around (yet!). With a multi hour restart and an upgrade not possible it is proving rather frustrating....

Below is the prolog, the general sequence of which I have used many times in this environment (i.e. declare global vars and build a view).

If I process quit after the view build then the TI executes without issue.

In the current state the TI crashes the instance on the asciioutput line (I get an empty t.cma$ in the DD).
If I have the subset insert in play instead the instance still crashes.

For clarity... if the SubsetInsert is in play, is the AsciiOutput also still in play? Is the t.cma$ file still generated (meaning that the crash is still happening on the ASCIIOutput), or does the crash appear to happen on the SubsetInsert line instead?

(I know it's not always easy to answer these questions despite the incredibly powerful array of debugging tools that we've been given over the years.

If I change the cube the view is referencing the instance still crashes.
TI crashes with both none data source and a view.

The only obvious difference is that this view has consolidations un suppressed, does this ring any bells? If the view I was creating was itself causing an issue I would not expect it to crash until I actually do something with it....

Stumped....

Code: Select all

 sDimName=TabDim(sCubeName , 1);
sElName='test';
#SubsetElementInsert(sDimName, sObjectName, sElName, 1);
asciioutput('t.cma' , sDimName , sElName);
 <snip>

I'm probably the forum regular who has come off 9.0SP3 U9 most recently, but that was actually getting on for a handful of years back now. As best I can recollect, these gotchas existed:
(a) If you tried to concatenate strings and ended up with a string > the magical 255 length, it would crash the process / chore. I don't think it ever crashed my server, though something in the back of my mind is ringing a vague warning bell about that so I may be wrong there. However in this case you aren't concatenating them, you're just using them.
It might still be interesting to see what the Long() function reports as the length of sElName and sDimName, though. I'm wondering if there may be something wrong with those values. I suppose you could just pause it in debug mode and examine the variable values but... oh, wait.
(b) I do know that trying to do an AsciiOutput to a place that the server could not write to was enough to tank the whole server under 9.0. The problem is that based on what you've said it appears that this file is being written to the data directory, and if the server can't write to that you'd have bigger problems than an ASCIIOutput crash. (Incidentally, I assume that the data directory is NOT in the Program Files path that even now IBM still insists on using as a default despite all of the problems that that can cause?) It still may be worthwhile to put a full path in for the output file to somewhere innocuous and see whether you still get the crash.

I'm assuming that the server log is silent on the issue, which would be unsurprising for a 9.0 era log. It's like flying a DC-3 out of an airport that now operates A-380s.

If the crash occurs on the SubsetElementInsert or the AsciiOutput, though, I'd be suspecting "bad" content in the variables. How you would find out what that "bad" is without being able to use AsciiOutput though... there is the problem. I suppose you could iterate through the characters and check for anything that falls outside the ASCII mainstream like one of those stupid damn non-breaking spaces (ASCII code 160) that sometime gets picked up in data extracted from web pages. (I'm not saying that that specific character would necessarily be the cause, but something like that may be.)

[Steve Rowe]

Hi Alan,

Thanks for responding....shouldn't you be asleep?

I've not tested with both asciioutput and the insert in place. With the insert in place the crash happens after the view create job completes and I can't tell anything else hence the asciioutputs introduction.

Nothing in the log. No disc space issues.

If it was var issues then it would have to be the dim or element name, both of which are assigned directly in the lines previously, not too much to go wrong there...

Cheers,

Steve

[Steve Rowe]

Tracked this down in the end.

Somehow I got the name of one of the GlobalVars wrong, no clue how I did this since normally I copy and paste them everywhere.

StringGlobalVariable('sCubeProp'); should have read StringGlobalVariable('sCubeJnlP');

This results in sCubeProp being blank, then later on when I use that in a CellGetS the instance falls over.

This is several lines after I start Asciioutputting so not sure why there were no records in t.cma, unless it rolls back before the crash somehow.

Thanks for the input Alan, forced me to look really hard at my code rather than just reading it and cursing out the software...

A lovely start to the day