DSXchange

I have seen problems similiar to this with parameters and the problem we experience was that the parameters set were not migrated with the application. If you are using parameter sets, ensure that they have been successfully migrated with the application.

If you have a quality Stage license, you may be able to use the investigate stage.

From QS document: The Investigate stage looks at each record, column by column, analyzing the data content of the columns that you specify.

Are the jobs that compile parallel jobs using the transformer stages requiring a C++ compiler? When did you last compile them? Will they successfully compile now? It looks like you C++ compiler demo has expired.

My guess would be that you need a C++ compiler. The job compilation process uses it to compile parallel jobs with transformer stages, buildop components, and some lookup stages. To function properly, the transform feature of the parallel canvas requires the compiler. The old jobs use a java compiler.

Looks like it could be a license issue:

'...Error: Demo mode has expired.'

Is this a 64 bit WAS install?

Let me restate that to be a bit more clear. Is this a 64 bit version of WAS?

From what I get from your message, (i.,e jobs are locked until previous job update finish It appears the bottle neck is at the DB update process. Talk to your DBA about the issue and get recommendations on how to solve it. Ex: maybe something like partitioning your DB by country or use row level loc...

Try setting the APT_DEFAULT_TRANSPORT_SIZE to "4147970" instead of "3002368".

Although this is an old topic I will post a solution that worked for us instead of starting a new thread. Our environment is IIS v8.1 on AIX 6.1. A developer imported a job. They are the owner and belong to a different primary group. The scripts used to execute the job are run as dsadm and group is ...

As a follow-up. I installed the 3 environments Dev, QA and Prod with the pre-insatall of the 64 bit WAS. It went smoothly.

thanks!

To start, have your DBA check to see if there is contention on the table you are trying to access.

Can you supply the patch number for others to reference. Thanks

The DB2 API is not capable of understanding database partitioning and when set to parallel will perform the full read on each node and duplicate the data. If someone has done it otherwise, please correct me and I will relay the information back to support. Note: I went back to my notes and reference...

If you are still recieving the message: main_program: APT_PMListenerPort: socket() call failed: Too many open files

You might try a ulimit -a command to see what are the allocations. If the nofiles are not unlimited, you may want to raise the number to see if that will address your problem.