DSXchange

Splitting the file into three outputs is easy. Read the file with a sequential file stage with one VarChar column defined. Define a Transformer stage with three outputs. Constraint expressions are: Matches "0X' '1N0N" (question and sequence) Matches "1N0X" (response option) Matches "1A0X" (question ...

Can you monitor the system while this job is running to determine which processes are hogging the CPU? (It was the CPU usage that you thought was high, as described in your subject? If not, monitor the appropriate resource.)

As soon as your data looks like getting near to 2GB (even 1.5GB for a safety margin), you can't readily use the default dynamic hashed files; you must switch to 64-bit addressing (or Distributed files, which is an entirely different topic, and you don't get memory caching). Ideally, then, you should...

chulett wrote:Add a Transform

Craig really means a Transformer stage, not a Transform!

Informix IDS has always been notorious for needing exact version match with ODBC driver. Check with IBM (now the owners of Informix IDS) exactly what version of ODBC is required for your version of IDS.

It doesn't matter.
DSAttachJob attaches the highest version-numbered released job if there are any present.
You can (should?) use DSGetJobInfo(hJob, DSJ.JOBNAME) to return the real name of the job being executed (for example MyJob%%rel20.2.1).

The obvious one is to research smarter algorithms. For example if your 1500 iterations per row processed is to determine whether something exists in an array, contemplate more efficiently searched data structures. Even exiting the loop as soon as something has been found, rather than completing all ...

Does that technique work in the PX environment if you have more than one data partition?
Yes, you could work around it. Obviously you should use a configuration file specifying just one processing node for this job.

A recent post (m) suggested this code as a means of generating a month with a leading zero. realMonth=right('0':jMonth, 2) In this case, jMonth was a separate column. Possibly a better method is to use Fmt(jMonth,"R%2") which handles the case that jMonth has more than two c...

Does the job that pre-loads the hashed file that you use for reference lookups Trim the values on the way in, and declare the description field to be the key and the code field to be the non-key column?

kduke wrote:DS_OBJECTS should be DS_JOBOBJECTS. Must be tired.

Was. Duly edited. Thanks for the heads-up.

The error message

Unable to open "" file.

suggests that the parameter value is not being properly transmitted. Check that you have spelled it and used the same combination of upper and lower case letters in your code as in the parameter definition.

In the ODBC stage, try clicking the Get SQL Info button. This retrieves what the driver expects as the quote and separator characters, which are used in the generated SQL.
Then recompile and try View Data.

Doesn't really make sense. Typically you populate your date dimension well into the future. About the only thing that would ever change would be the holiday information - unless a Pope gets the notion to fiddle with the calendar again! So the date dimension should require little if any updating. IMHO.

From Administrator client Command window or in a telnet session in the DataStage environment in your project, execute the following commands. Commands are case sensitive; you need all upper case as shown. Job designs UPDATE DS_JOBOBJECTS SET READONLY = 'RO' WHERE READONLY = 'NRO'; Routines UPDATE DS...