DSXchange

Hi We have a 11.3 installation on Linux and somehow datastage has been installed on port 9445 instead of 9443. Our sys admin says he just accepted all defaults during installation and yet it got installed at 9445 instead of 9443. Anybody knows why ? In any case, I can live with that. I have been abl...

Unfortunately IBM confirmed that there is no way to change the default 50 warnings limit other than by using -warn 0 from the command line.

So I am marking this thread resolved.

Found this article on the net - http://www-01.ibm.com/support/docview.wss?uid=swg21611065 As per this, the escalation of 50 warnings to a fatal error may not happen before the job finishes due to the asynchronous nature of osh events. In such a case the job will finish with warnings. May be this is ...

Rakesh - Yes I have. However, On my 8.1 servers, DEV/QA and PROD, this same job, after being invoked from a unix script without the benefit of -warn 0, runs to completion despite all the warnings. These jobs have been running fine on these servers for years and there is no message handler or anythin...

So you asked those questions of IBM Support? I did but based upon the quality and timing of response so far, I thought let me ask it here also and perhaps get a better answer quicker .... Notice, that he uses the phrase "I believe" - which does not engender a lot of faith in the response ...

This is the response i got from IBM tech support - I believe you can use DSSetJobLimit to set the default warning limit across all sessions. http://www-01.ibm.com/support/knowledgecenter/SSZJPZ_11.3.0/com.ibm.swg. im.iis.ds.cliapi.ref.doc/topics/r_dsvjbref_DSSetJobLimit.html When the job is run via ...

Thanks Chulett So when a job is run from the command line, what causes it to abort after 50 warnings ? Where is that setting kept. The reason I am asking is because in our production server running datastage 8.1, the job does not abort after 50 warnings. But on the new 11.3 datastage it does. This i...

Can somebody at least answer the following questions - When running a job from director, one can set the limit on warnings after which the job will abort. There is an option to make it unlimited. Question 1 - Does it apply to only that session or is it global ? Meaning If i set it to unlimited on di...

Unix script calls DSJOB to invoke a job. It does not use -warn0 Job generates a lot of warnings but DOES NOT abort. This is in version 8.1 The same job in version 11.3 aborts after 50 warnings. Question is Why ? I have changed the global warning LIMITs through director to unlimited. But the job stil...

Thanks QT_KY

That was exactly the problem. We had 13.1 compiler version whereas, apparently, Datastage is certified only with 12.1

Once we downgraded our compiler to 12.1 it all worked fine.

I will mark the thread resolved.

Created a copy of the job with just one oracle stage. job failed. Replaced the oracle stage with a sequential file stage. Job failed. Removed all stage derivations from the transformer. job was successful Went back to the original job that had one oracle stage and Changed the first stage variable de...

This is the test environment. Only this job was running. Please note that other jobs using oracle enterprise stage are working fine. So the problem is with this job in particular. Also, this is a working job from 8.1 version and being run for the first time in 11.3 where it is failing. ulimit -a ins...

Thanks for your response gentlemen. Reading from the sequential file is not a problem because we are able to do a view data from the designer. All the errors appear for the oracle enterprise stage. There is no other message. The only error messages are - grh,0: Failure during execution of operator l...

Hi We have a job that reads from a sequential file then based upon the record type, writes to one of the several oracle stages. seq_file ...........transformer .....oraclestg1 ......oraclestg2 ........oraclestg3 ... ..... .............oraclestgn At each oracle enterprise stage we are getting the fol...

Thanks Ray.
Hoping this would fix the issue.

We will monitor it for another few months and hopefully it won't happen again before we complete our migration to 11.3.1