DSXchange

Welcome aboard! There are many different ways to answer this question, not all of which will be the best. Can you provide some more information about your process? Things that would help are: -- what is your target database? -- how are you connecting to that database? -- are there any permissions li...

We are having a lot of this same issue right now, especially with my project that is all multi-instance jobs (about 1200+). We have applied a fix pack already and done some tweaks. Tonight another is going into place that is specific to this issue. After testing it tomorrow morning, I'll let you kno...

Hey Arnd, Doesn't DataStage interpret 000 as the Nul indicator? That might account for the weird results. I too am having very strange issues with V8. I have a ticket open with IBM Support now since they seem to think mine is multi-instance related as well. I will post any solutions they come up wit...

Building a little on the groundwork Ray and Bharani have already laid for you: I had the same problem with very large amounts of data taking too much time to process. I removed the hashed file creation part of the process and switched to staging tables holding the same information (actually a little...

Are these essentially showing up as non-printing characters? Or maybe characters outside the standard ASCII range (32-127 I think)? If so, try this: Create a routine called 'RemoveNonPrintingChars' (or whatever - it doens't really matter). There will be one argument called 'Arg1' and the code goes l...

Is the source file being created by DataStage? If so, then set the Null handling settings in the stage that creates the Sequential file.

Here is an update on my project's migration from 7.5.1a to 8.0.1. Performance: So far, the only performance information I can give deals with the development tools and response times dealing with those. We have tried local installs of the clients, as well as our standard Citrix virtual machine insta...

We were able to fix our performance issues with the compile (to an extent). It still isn't as bad as the one minute plus per job we had, but still it is not as good as V7 was. We now get about 11 seconds per job compile time. It took a fixpack from IBM and memory tuning on both the DataStage Server ...

Don't worry, Ray! No offense was taken. :lol: My thing is that I have been employed full time in the database industry for the last 14 years and I've never even had a computer class. I learn by doing and Perl is easy enough to make sense. I tried learning C once - yeah that worked... :oops: Anywho, ...

Any thoughts on the "ROOT Job Definition Object not found" part of the error message?

In all honesty, I do not have any of that info as it is in the hands of the Administrators. I will see if I can get it from them for you and post it up.

We had (still have to an extent) very similar problems with our install. We access DataStage Designer and Director through through Citrix which exist on virtual machines, adding yet another set of layers that do not help performance. We had to contact IBM for a patch to the Information Server/WebSph...

We had (still have to an extent) very similar problems with our install. We access DataStage Designer and Director through through Citrix which exist on virtual machines, adding yet another set of layers that do not help performance. We had to contact IBM for a patch to the Information Server/WebSph...

We have two supposedly identical environments for Development and Production. We are running DataStage on AIX Unix. I recently migrated my version 7 project to version 8. It was running fine on version 7 and the initial move to version 8 Development went fine. Performance on v8 has been pitiful thus...

Oh, ow! Now Ray is beating up my widdle Perl ego... :cry: Remember guys, I use Perl so much because I am not bright enough to handle 'real' programming languages. ;-) Anyhow, Ray's point is well taken. There can certainly be more than one V-number combination depending on the complexity of your jobs...