DSXchange

Michael, the easiest method is to do a full DataStage export and then simply search the .dsx for the SQL string, that will quickly let you identify the job(s) where it is used.

You will need the correct c++ compiler to compile DataStage EE jobs with transform stages.

[...Yes I found the variable "APT_DUMP_SCORE" in the administrator under environment variables , under reporting category , which set as false,if I make the value as true , where will I be able to see how parallel processes are running for a particular job... If you set it to "true" you can see an ...

did you try "whereis cpp" as mentioned earlier? If that doesn't return a path you haven't set up the compiler correctly.

You would seem to have run out of total virtual memory on your machine but starting that many datastage jobs and processes. If you increase your swap space you will probably get rid of these errors but chances are quite good that your performance will be abyssmal. You can look up "out of process mem...

Access the metadata of jobs is identical for Server and Parallel jobs, so if you have it working in server BASIC code it will do so for both types of jobs.

(1) Table method is quite efficient, there is no need to use a SQL query
(2) The Load method is the most efficient. Indexing can be controlled in Options -> Index Mode portion of the Oracle stage definition.

Just restoring the DataStage engine directory without having run through the install will not work, which is why going through the project recovery as you mentioned in your first post is the easiest way to get back up and running.

Well - that means you either don't have the c++ compiler installed, or it is not in that location. My guess is that you don't have the c++ compiler installed, but perhaps you could ask your administrator and/or use "find" to locate your c++ compiler executable

right-mouse click on the column and choose "edit row", then in the null properties you will see that you can add attributes such as "default null value".

I would tend to look at your SOLARIS configuration first. Tuning the DataStage engine is often counterproductive. Almost all of the tuning possible in DataStage is done with the uvconfig file, and odds are you haven't changed that in the old installation and thus it shouldn't be changed in the new, ...

Look up "APT_DUMP_SCORE" - when set it will tell you exactly how many processes were started for a job run.

What exactly is the problem? I just tested it and it worked as expected with parameters.

If you go into the UV shell and issue the command "COUNT DS_JOBS" what do you get? Perhaps your restore settings were such that existing files in the project directories were not overwritten.

You cannot tune DataStage at all unless you know what your bottleneck is. The first step to tuning is understanding what is slowing your jobs down. Are you close to 100% CPU when jobs are running? If not, then CPU is most likely not your bottleneck. Are your I/O channels at maximum throughput? Is yo...