Prism to DataStage

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

Post Reply
gdean
Participant
Posts: 24
Joined: Mon Feb 09, 2004 9:09 pm

Prism to DataStage

Post by gdean »

Hi,

We have a warehouse that was designed earlier using Prism Warehouse Executive. We now want to move on to using DataStage for our warehouse design and maintenance. I would like to know if anyone has done this before.

What are the major issues that we should be aware of when doing this? I would really appreciate any tips for getting started with the process.

Thank you

/gd
tomengers
Participant
Posts: 167
Joined: Tue Nov 19, 2002 12:20 pm
Location: Key West

Post by tomengers »

gdean ...

I've got about 6 years of Prism experience so let me offer a few thoughts, bearing in mind there is no way to automate this:

1. Sometimes some very bad habits emerge if no one has been watching the store: do a diff between the COBOL code presently running in production and the code you generate today via the Prism tool. This will identify places where "speedy" people have upgraded the executing code and neglected to go back and tell Prism. :evil:
2. If you are using Code Blocks to call other programs, document this architecture.
3. If you are using Code Blocks for error messaging or validation, document this.
4. Document the logic in each of your business rules in the order they are executed.
5. Walk thru each Prism program looking for logic before file open and after file close.
6. Look for host variables in all front-end SQL.
7. Look for User-controlled writes to output files - these will become constraints.
8. Using DS Manager, import all COBOL copybooks.
9. Translate your Prism business rules into DS logic. This exercise may surprise you for, in some ways, Prism had a lot more logical functionality than DS has today.

That's all I can think of now ... I'll be giving this more thought and will come back if anything more of value surfaces.

... tom
lateshj
Participant
Posts: 12
Joined: Wed Nov 05, 2003 11:54 pm

Post by lateshj »

Hi,
Would just like to share some features related to the kind of work you are doing...

You can use the PweXport.exe utility provided by DS present at (<Client CD>\Utilities\Supported\PWEMDExp)
This helps one to export Prism Table Definitions to the DataStage repository

One can use the CFF plugin stage to read work files generated by PRism program also

Tx
Latesh
kcbland
Participant
Posts: 5208
Joined: Wed Jan 15, 2003 8:56 am
Location: Lutz, FL
Contact:

Re: Prism to DataStage

Post by kcbland »

gdean wrote:I would really appreciate any tips for getting started with the process.
Get Tom inhouse and have him give you a bootcamp....He's getting too comfortable in Key West.
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
gdean
Participant
Posts: 24
Joined: Mon Feb 09, 2004 9:09 pm

Post by gdean »

Tom,

Thank you so much for your input. Most of the issues you have mentioned, I never thought about them... I thought it was enough to convert the logic in Prism into DataStage...
5. Walk thru each Prism program looking for logic before file open and after file close.

Can you please explain the significance of doing this?
7. Look for User-controlled writes to output files - these will become constraints.
How do I look for user-controlled writes?
8. Using DS Manager, import all COBOL copybooks.

How is this going to effect the migration from Prism from DataStage? What will happen in case I don't export the copybooks?

For example if I have two tables, one is used as the main data source and the second one for lookups. To design a DataStage job I will extract all the business rules, mappings, lookups, field conversions, record selections, user exits and convert them into relevant DataStage jobs. Am I thinking wrong here? I am afraid I am missing something fundamental.


Latesh,

Thank you for the info regarding PweXport... I am definately going to try it out and let you know.

Many thanks to you all,

/gd
tomengers
Participant
Posts: 167
Joined: Tue Nov 19, 2002 12:20 pm
Location: Key West

Post by tomengers »

gdean ...

Let me do a little research over the weekend ... it's been a while and am a little rusty.

And Ken's right. I'm probably rusty from all the fresh salt air down here. And I've certainly had way too many margaritas and far too much lobster, grouper and hammock time ... :wink:
gdean
Participant
Posts: 24
Joined: Mon Feb 09, 2004 9:09 pm

Post by gdean »

Tom,

Please take your time. I am in no hurry and look forward to your valuable insights in this matter.

Have a great weekend.

/gd
tomengers
Participant
Posts: 167
Joined: Tue Nov 19, 2002 12:20 pm
Location: Key West

Post by tomengers »

gdean wrote:
8. Using DS Manager, import all COBOL copybooks.

How is this going to effect the migration from Prism from DataStage? What will happen in case I don't export the copybooks?

For example if I have two tables, one is used as the main data source and the second one for lookups. To design a DataStage job I will extract all the business rules, mappings, lookups, field conversions, record selections, user exits and convert them into relevant DataStage jobs. Am I thinking wrong here? I am afraid I am missing something fundamental.
/gd
gdean ...

Import your copybooks as Latesh suggested. Your approach (above) is quite correct, you are not missing anything "fundamental". One of the first things you will do as you create your DS process is to Load the appropriate Table Definition into the Stage - this is the definition you will have imported from the Prism job. You will use the CFF (Complex Flat File) plug-in in DS to flatten occurring groups and potentially normalize.

User-controlled Writes: Prism, like DataStage, has an internal cycle which will write the input record to each output leg. If you don't want that, you must turn off the automatic selection in each leg by creating an "acceptance" test which will never be true, so that records are never (automatically) written. Now when you want to write to that leg, it is done in a Business Rule via a PERFORM to that leg - it is now a user-controlled write.

Other things to check for in the Prism program:

1. Use of the WS-IN1-EOF-FLAG which is turned on when the last record is read. Look then for end of job logic in Location 65.
2. Look for automatic field conversion in each source => target move.
3. Understand how the WS-IE-FLAG is used, this is the Include-Exclude flag and is used to skip input records.
4. Look for conditional logic in the Direct Reads.
5. At the Project level, look for a Break Year default setting.
6. Look for and document parameters in Binary, Serial and VSAM searches.
7. Check all input Date fields for automatic conversions.

I think that's about it ... good luck ... you're going to have your hands full. :shock:

... tom
Post Reply