DSXchange

You state that you are using an invocation id to run the sequencer.

Do all the jobs that the sequncer calls have "Allow multiple Instance" turned on?

Did you call them using the invocation id?

After you reimported the jobs did you validate them with the correct invocation id?

Which XML pack are you using?

How big is the file ( both file size and number of records ) that fails, compared with the file(s) that work?

you should use the #PCDATA tag.

Make sure the tag is fully qualified.

Do not set the key until you write the file in the output of the transformer.

If you want to improve the performance of the queries without using temp tables (depending upon the DBMS being used) , you could rewrite the query that Ken proposed to put the queries into the from clause instead of the select clause.

That will improve performance on DB2 and Oracle normally.

Are any of the computers using Windows XP?

If so, make sure that the XP patch is installed.

did the memory configuration parameters in the uvconfig file change when you upgraded from 7.1 to 7.5?

Error message from DB2 manual: SQL0973N Not enough storage is available in the heap-name heap to process the statement. Explanation: All available memory for this heap has been used. The statement cannot be processed. User Response: Terminate the application on receipt of this message (SQLCODE). Mod...

This is definitely a DB2 error. Check with your dba. I believe that you are trying to update / insert too many rows without a commit.

Another option is to create a view in ACCESS and rename the columns in the view so that they do not contain spaces.

Reference the view not the table using ODBC.

If you export the job in question to a dsx file and then look at the parameters section, do you see any special characters or a line feed or carriage return in the export that may be difficult to see in the job itself?

Are you invoking this job from a sequencer?

The Libpath in the dsenv must point to the 32 bit libraries, because DataStage is a 32 bit application The issue occurs when you try to execute a UNIX script connecting to DB2. In this type of script you must set the LIBPATH to the 64 bit library, because the UNIX system is seen as a 64 bit client t...

Looks like you are on a 64 bit UNIX server connecting to DB2. Is you DB2 instance a 32 bit or 64 bit database? DataStage is a 32 bit application and needs to have the links set to the 32 bit libraries. If you are trying to run UNIX commands (db2 or db2load) then the librarys need to point to the 64 ...

One system I worked on with DB2 used char(10) as the definition for all date fields and Varchar(26) for timestamps with a format of YYYY-MM-DD hh:mm:ss.sssss

This works fine and is readily visible for debugging, but you must be consistent throughout the processing.

In your first post you said "See following DB2 message for details. "

What dis DB2 complain about. Can you post the DB2 message.