DSXchange

Tell us what's happening in and around line 90 in RT_BP759/JOB.1316733923.DT.1493956403.TRANS1

The client is irrelevant here. It is DataStage server that needs to be able to connect to DB2 and therefore it is on the DataStage server that the bind needs to be done.

Or just use a double-quoted name in the Table field.

You're saying that you want a running job to be able to retrieve its own lineage information? Or is one job to retrieve the lineage information of another job? Either way there's nothing obvious that springs to mind until and unless they publish an API in to the metadata layer. Some of this exists i...

Exactly the same except:

(a) the fastnames are different in an MPP configuration file

(b) the mechanisms used for inter-process communication are different between SMP and MPP

Table names containing space characters have to be quoted. Is yours?

No, you can also get this if one of the databases to which you're connected is in a "not ready" state, or takes too long to execute your "query from hell".

No, you can also get this if one of the databases to which you're connected is in a "not ready" state.

Seems to be. In any case, "" is not valid as a timestamp. The Sequential File stage requires in-band nulls (that is, a substitute value that is valid for the data type).

If you have no control over the structure, specify the data type as VarChar and convert the type within your job (if necessary). Only VarChar can legitimately have a Null Field Value of "" in a parallel job.

All of the Information Server products share the same metadata repository and the same set of metadata delivery services.

Try running DS.CHECKER command when you have exclusive access to the project.

Nagaraj's suggestion will probably not work at version 8 because it only addresses the local repository and not the common repository.

The obvious one, that you probably don't have enough disk space even for one project, springs immediately to mind. Regularly make sure that files are being cleaned up from scratch disk (particularly if jobs abort).

Only the Merge stage consumes rows as they are selected from its Update input(s). You could devise a mechanism to discover what remains in the Data Set supplying the Update input.

There's no "=" in a KEEP specification.
If you're renaming the column, you don't name the column in KEEP or DROP.