DSXchange

There is a manual for each plug-in stage type. I note that you are on release 6, so you'll need to look in the Packages folder on your DataStage CD to find the FTP plug-in stage. In a folder called Docs you should find ftp.pdf , which is the manual that explains how to use the stage. The FTP stage d...

No. Only non-key columns can be multi-valued in hashed files. You need a generated key. Make it an Integer, and generate it as @OUTROWNUM in the Transformer stage that loads the hashed file. Specify, in the hashed file creation options, that the hashing algorithm is SEQ.NUM. If you're using a UV sta...

Pivot stage was introduced in version 4.2, if my memory serves me aright. It's certainly in 5.2, so definitely in 6.x which you're using. You may need to install it using the DataStage Package Installer if it was not initially installed.

UtilityHashLookup uses a hashed file on disk. It cannot take advantage of memory caching in the same way that the Hashed File stage can. So your job would be far slower. I have not had time for detailed analysis of your new design yet. Converting columns to rows (which is a horizontal pivot) is perf...

Because ConvertMonth is not an instrinsic function in the DataStage BASIC language. It's a regular routine. You can view its source code in the Routines branch of the Repository. It's cataloged under DSX rather than DSU because DSX is for routines that support supplied Transforms, while DSU is for u...

The reason is reasonably straightforward. Everything you do in a mainframe job generates a slab of COBOL source code (and maybe - probably - JCL).

Server jobs (a container is a subset of a server job) generate BASIC.
A COBOL compiler simply won't deal with BASIC!

Because there are no data types within DataStage (OK, that's a simplification, but it's how things seem), you can actually do nothing.

If the sign is going to cause a problem, simply perform some arithmetic. The most efficient is adding zero.

No.

Is it every Transformer stage, or one particular Transformer stage, that manifests this problem?
It might be worth re-installing the DataStage client software, or doing a clean install on a spare PC, to see whether it's a problem at the client end.

When you reset (not re-compile) the job after it aborts, is there an event in the job log called "from previous run..."? This, if it exists, may contain additional diagnostic information.

Note, however, that Cartesian products (because they return N * M rows for N rows in Table1 and M rows in Table2) can take a very long time to execute.

For sufficiently large N and M, or for more than two-way Cartesian products, this interval can be measured in days, months or even years!

Transforms can not be called. When you compile them into DataStage expressions, they are replaced by the expression that defines them. For example, the defining expression for the MONTH.LAST Transform (which you can determine by inspection of the Transform's properties) is ConvertMonth(%Arg1%, "L") ...

User-defined environment variables, like project-wide log purge settings, are stored in the DSParams file in the project directory. While there's no client-based mechanism for transferring them (at least none of which I am aware), it's a relatively straightforward process to unload them from one DSP...

It's already stored in the DSParams file on the server (in the project directory). Why not parse from there? There is a separate section for user-defined environment variables, so you can easily capture them, perhaps using a BASIC routine.

Yes.

The derivation expression referring to lookup1 and lookup2 as link names should have been a clue!