DSXchange

You process the dynamic array using similar logic that you would use in the standard LIST.READU report - but searching the dynamic array is probably easier, for example using the FINDSTR() function in DataStage BASIC, which will give you the field (= row of the report) in which the string sought was...

I don't believe running in one node will have any effect in this case. But by all means try it. Just run using a single node configuration file - you don't need to set up node pools, particularly in an SMP environment. Or compile in trace mode and force sequential execution by that means.

Eliminating any GROUP BY or ORDER BY clause in your SELECT statement should allow Oracle to stream data into your job as they are retrieved. Unless, of course, Oracle has to materialize a view or perform some other operation that takes too long before being able to deliver rows.

Is the "Lookup failed" rule in your Lookup stage "Drop"?

@INROWNUM = 20 gives you row number 20 (one row) on each node.

@INROWNUM <= 20 gives you the first 20 rows on each node.

@INROWNUM <= (20 / @NUMPARTITIONS) will get you close to what you need.

No.

I am not aware of any. But there are unknown unknowns ...

Create a reproducible case and submit it to your official support provider.

rajadommeti wrote:select to_char(CAST(TO_DATE (yourdate, 'yyyyddd') as timestamp),'yyyy-mm-dd') from yourtable;

Why do you think the source is a database (and what kind of database do you believe it to be)? Source data are coming from a mainframe, and its structure is defined in a COBOL file definition.

It is necessary to include the header file JOBCONTROL.H because it is in that header file that the function definition exists.

This $INCLUDE compiler directive must precede any executable statement in the code.

There are instructions for doing that in the manuals and in the Information Center. It may have been addressed on DSXchange in the past too.

If the two tables are in the same database you can create a view in that database consisting of the required join and perform column analysis on the view.

max.madsen wrote:The problem will do a logic for choose when input "91" shall transform in "1991" or "2091" ou "2191"... How you will choose?

That decision would possibly be based on the CENTURYPIVOT setting.

You should be able to use "%yyyy%ddd" as the date format string.

Not unless the job was designed to capture that information in the first place.

Neither is preferred, though I suspect the VarChar one may be slightly more efficient.