DSXchange

Specially HP-UX 11.11 (11i) PA-RISC.

We have one server running 7.5.2 - all others run 7.5.1A - and there have been enough silly little unexplainable issues that I'm about to nuke the farking thing and reload 7.5.1A. Hopefully that will help isolate if it is a problem with the server or the version of DataStage.

So, curious - anyone on that version on that platform?

Might as well be an issue related to chip speed. Revisiting the administrator guide might help. Search too had a few things to say about it I guess, though you might be familiar with that.

Make sure you get MFILES high enough, one customer was having trouble until they set it to 100 after upgrading hardware to faster chips.

I'll try that, right now I'm fairly certain it is set the same as all other servers. Odd thing with this was 7.5.2 was installed September '06 and ran 'fine' until mid February when the problems started. No-one on the infrastructure side can tell me what, if anything, changed. I've also asked if there is anything substantially 'different' about this box than the others we have, no answer on that question yet.

Friday, we rolled back to 7.5.1A and nothing really improved. Core dumps and 'Fault type is 10' SIGBUS errors abound. The SAs are thinking about scraping it down to bare metal and re-imaging it. Might as well, ain't working for me now.

Yeah, nothing changed, right.... Funny thing about kernel settings, they're cumulative. If they fired up another instance of something like Oracle, they need to make sure the kernel settings get bumped up.

This customer found that the original 56 MFILES and 1000 T30FILES was no longer sufficient to ward off the -12 and -14 issue after the 7.1 to 7.5 jump with newer chips. 100 MFILES and 2000 T30FILES finally did the trick.

The blazing machine was so fast that the job control was getting a lot more jobs started simultaneously than before. Almost had to stick a delay in the job control to slow down starting jobs . Luckily, it's stabilized again. Now that dynamic multi-instancing job control can fire off those 100 instances!

I'd just like to get one job, running all by its lonesome, to not core dump on me.

Forgot to come back and close this out. Pretty sure I posted this in a related thread, but the root of the problem was the version of the Oracle client the DBAs had installed. Reimaging the server didn't help as the Oracle client version hadn't changed. Finding they had installed a version known to have vicious memory leaks and getting it updated to a stable version finally solved the problem.