DSXchange

The easiest and cheapest "persistent variable" for use between adjacent Transformer stages (or any active stage types) is an extra column on the link. The job itself has a "user status area" which acts like a single variable accessible from anywhere within the job. Its value is set using the DSSetUs...

Your beliefs about hashed files (except the file names) being disk based are correct. However, nearly everyone enables pre-load for read, which is why I claim that they are - or, properly, can be - memory based. The file names are DATA.30, OVER.30 and .Type30. File sets and data sets are different i...

It actually makes a difference. The Oracle stage types can use any of the data types that Oracle knows about, whereas the ODBC path means that everything has to be translated into ODBC-compliant terminology. For a very simple example, Oracle's VARCHAR2 is known as VARCHAR in ODBC. Dates can be a nig...

Well, you're part way there. In the PX environment you get the choice of three stages that do in-memory "joins" (the Join stage, the Lookup stage and the Merge stage). You have to select the correct tool. Read about them in the Parallel Job Developer's Guide . (If you think about it, what you were d...

Definitely! Simply use the appropriate Stage type, for example ORAOCI8 for Oracle 8. When importing, choose Import > Table Definition > Plug-In Metadata Definitions - you will be presented with a list of plug-in (= optionally installed) stage types installed on your server. Choose the correct one an...

Not from the UniVerse command line, unless you know the internal structure in the Repository where status is recorded (it's based on a concept of "resources" - active stages that run in separate processes are also "resources"). You can, however, use the dsjob command from the operating system comman...

The PX engine does not know about hashed files. The only way you can use them is to encapsulate a server job in a shared container, and run that in the parallel environment. Probably more trouble than it's worth; the datasets used by the Lookup stage (and the other stages that can do reference looku...

Most databases have some way to force extra (parallel) tasks to be used in processing a query. The real skill is in being able to determine when extra tasks will be useful. If some other aspect of your query demands single-threading, you can request hundreds of extra tasks, but you won't get them. F...

Welcome aboard! There are several techniques. The one that most closely adheres to the GUI model is to run a separate job that fetches the row in question into a text file. You run this from a job control routine which then reads the file and uses the values therein to set parameter value(s) in the ...

You could do it but for a fundamental rule in DataStage; no passive stage can open any of its outputs until all its inputs are closed. It has always been thus. The per-compiler detects this situation and reports a cyclic dependency if the input and output links come from the same active stage. That'...

Just reverse your logic, and SCD becomes straightforward. Hashed file stage can only be used for "=" lookup on the key - that's exactly what it's for. UV stage can access the same structure, but perform totally general queries; it's more flexible and therefore not quite as fast. In summary: pre-load...

The hidden file .uvnlsmap should not be deleted, and is not deleted by CLEAR.FILE.
This records the NLS character map used for this particular directory.
It is only present if NLS is installed.

Job Sequencers are GUIs that, when you "compile" them, write job control routines that you can inspect. Job control routines are inspected on the Job Properties window Job Control tab. In some situations a job sequencer can do everything you need. In other situations a job sequencer can be used to g...

Segmentation violation is ultimately an operating system error, though caused by software attempting to access a memory address which either does not exist or to which they have no rights. Read the man page on signal() for more information. I decoded the 911 using DataStage's SYS.MESSAGE table, in w...

That's a test from the Test Grid for a DataStage Routine. If you want that (rather than a shell script) analyzed, you'll need to post the code. The routine has called DSLogInfo() with the first variable containing a lot of junk - perhaps the OREIGN comes from FOREIGN KEY. Anyway, post the Routine so...