Calling a Oracle Stored Procedure From Datastage (URGENT)

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

Teej
Participant
Posts: 677
Joined: Fri Aug 08, 2003 9:26 am
Location: USA

Post by Teej »

One last thing:

LET GO OF YOUR TECHNICAL BACKGROUND.

If you are a master of PL/SQL, forget it.

If you are a master of C/C++, forget it.

Approach DataStage with a new insight -- the BUSINESS BACKGROUND.

"I need to ensure that all customers' sales are collected together."

Input -> Aggregator -> Output.

Simple! (Life is not simple though... :mrgreen:)

* * *

Trust me on this -- it takes SO MUCH less time to do the coding for DataStage. Revising based on new rules are so much easier. Unfortunately, dynamic fields are not fully realized (Column Propagation on the GUI is a nightmare for PX).

Once you get a good familiarity with DataStage, you can slowly reintroduce the other tools for other issues. For example, transactional control? C/C++ or PL/SQL is much better than DataStage for that, so for ODS databases, it's a recommended step. However, you do NOT need transactional control on EVERYTHING so much that DataStage is unuseable. There are many logic solutions to address that issue within DataStage.

Just let go of your PL/SQL background, and start from scratch.

-T.J.
Developer of DataStage Parallel Engine (Orchestrate).
kcbland
Participant
Posts: 5208
Joined: Wed Jan 15, 2003 8:56 am
Location: Lutz, FL
Contact:

Post by kcbland »

Teej wrote: No. It is more difficult to archive within a source repository multiple diverse location of codes, and to ensure that your gatekeeper (for code migration) migrate the correct version to the correct designations. To also identify failure points are more difficult. You will have combatants between PL/SQL team and DataStage team blaming each other for a bug. To conduct a QA would require more test cases - you MUST independently validate the PL/SQL code, AND the DataStage code to ensure that it is performing correctly on its own. Code changes within PL/SQL also may have an adverse effect on the DataStage code -- which flies against the philosophy of Data Warehousing Design -- Graceful changes.
If the PL/SQL team and DataStage team are separate entities, what a joy to try to coordinate these two. What a joy to try to convince one team their code object has a problem. What a joy when the procedure works great for one set of jobs/scripts, but poorly for others. Too bad the technology for DataStage PX/Server isn't being used. Good points Teej, you're a man who's survived trial by fire. 8)
Kenneth Bland

Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Teej
Participant
Posts: 677
Joined: Fri Aug 08, 2003 9:26 am
Location: USA

Post by Teej »

kcbland wrote:Good points Teej, you're a man who's survived trial by fire. 8)
*nods*

GET ME OUT OF HERE PLEASE! SAVE ME! *scratches the closed windows to the world*

:mrgreen:

-T.J.
Developer of DataStage Parallel Engine (Orchestrate).
Post Reply