DSXchange

Error code 9 12 is a very unusual combination.

The first number is reported by DBsetup. Unfortunately, the UniVerse Administration Guide only decodes numbers up to 8 for this number; I suspect 9 is one added by Ascential after DataStage and UniVerse development diverged. Check through your support provider.

The second number is the signal number generated by the UNIX signal(3C) facility. 12 is (SIGSYS), which means "bad argument to system call", and will cause a core dump that the support organization may be able to analyze.

Does this problem occur every time, or only once?
What release of DataStage?
Do you have NLS enabled? (I ask because shared memory segment must be allocated for NLS map and locale information.)

Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518

Given that you're in Taiwan I would suggest that it's almost certain you have NLS enabled. If any of the stages have NLS tabs on their properties, or if the job properties have a tab for NLS, then you have NLS enabled. Even easier; if you are processing Chinese characters correctly, you have NLS enabled.

Hi Ray,

I'm Hsiuling's colleague and I'd like to follow up this problem. You are right, we have NLS enable and use CP950. This problem does not occur often and it's the first time. We did nothing change to our system but ran some multiple-instance jobs. Do you think it cause the problem. Our solution is not to run multiple-instance jobs and restart DataStage, then everything's fine.

We're working on DataStage 5.2r2 and OS is Solaris 8 on E10000 marchine. BTW, the DB is Oracle. Thanks for your kind reply.

regards,

Azens Chang
MetaEdge Corp.

I am hesitant to try to answer this till I know what error code 9 is. The problem has occurred when trying to initialize UniVerse (that is, a DataStage process) and could be due to any one of a number of causes.
Have you sought help from your support provider?
While I have my suspicions, and you may be right about starting multiple instances of jobs in quick succession (to which one fix might be leaving a second or so between them), let's get some more information so that we don't waste time following false trails.

I've now found out (from the truly helpful Ascential engineers who post on datastage-users@oliver.com) that code 9 means running out of memory or temporary disk space. They suggest checking the settings of the UVTEMP and UVSPOOL configuration parameters - for DataStage the latter is probably not relevant, but UVTEMP definitely is. How much space is left on this file system?
The 12 is not, in this case, a signal, but is the operating system error code ENOMEM, which again indicates that sufficient memory could not be allocated.
The following things may need to be checked, when times are good and when the problem occurs.
* Disk space available for swap.
* Disk space on UVTEMP file system.
* Core memory usage.
* Whether Oracle is hogging resources.
* Whether DataStage processes are hogging resources.

Dear Ray,

Thanks a lot! I'll check every point you mentioned.

regards,

Azens Chang
MetaEdge Corp.