DSXchange

I've seen this error in the "101" class, where someone put the name of a Data Set control file (blah.ds rather than blah.fs, where there really was a Data Set controlled by blah.ds) in a File Set stage.

Is the second node being reported separately somewhere else in the XML document? If not, I suspect you've uncovered a bug. What does your support provider suggest?

Problem is the second approach is knowing exactly what to delete. If there's an entry in DS_JOBS there may be entries in lots of other tables.

You do need a C++ compiler. Typically the one chosen is in Visual Studio .NET. The only fully parallel-capable version of DataStage for Windows (currently) is 7.5x2; you must have this version. To "connect" the compiler to DataStage you specify the compiler and linker information via the environment...

Main job reads the flat file, one row at a time, and passes that row through a Transformer stage. Output can also go to a text file. Within the Transformer stage of the main job you build the required arguments for, and invoke, UtilityRunJob. Pass it the name of the other (subordinate) job, the one ...

Get to a command prompt, such as the Administrator client Command window, and issue the command DS.CHECKER - this checks for incompletely deleted jobs and deletes orphaned components. This ought to be enough to cure your current dilemma.

A job sequence is nothing more than a server job that contains only a job control routine. The answer, therefore, is yes.

That's a heck of a large number!!! How much of the field is actually used? Have you checked out the data type conversion routines in the SDK?

I wondered if they were all the same hashed file, even though four separate stages. The fourth create would possibly wipe out any rows thus far sent (if delete before create has been checked). Automatic creation of hashed files is a fairly recent phenomenon (7.5?). The OP only specified 7.x - I'm no...

Thanks, Roy. However APT_BUFFERING_POLICY is already in DSParams, with legal list values and a legal default value. This is what's so confusing!

Process metadata, which is what you describe, is automatically captured into the job's log (from which it can be retrieved using the DSGetLog... functions in the DataStage API - that is, in a routine). Process metadata may also automatically be captured by MetaStage, provided that the job is running...

Create one job that reads that flat file.
In a Transformer stage call the UtilityRunJob routine to run the other job, passing ID and element (and anything else required) as job parameters.

There are five system variables called @USER0 through @USER4 and another called @USER.RETURN.CODE. Each is initialized to zero automatically when your job starts. You can use any of these, thereby avoiding the need to use COMMON (and leaving open the possibility, therefore, of later migration into a...

Welcome aboard.

What messages were logged? In particular, were there any warnings? Did you check the "create file" check box in the Hashed File stage for each link?

Look in the DataStage BASIC manual for two subroutines that work with pathnames. They are called, if my memory serves, !GET.PATHNAME and !MAKE.PATHNAME

By using these to deconstruct and construct pathnames you will have a completely portable and idiot-proof mechanism.