DSXchange

All,

I would like to know the DataStage naming standard for the links as well as for the stages. Is there any document available?

Can anybody refer some useful links or documents?

DataStage names links Link_n where n is the order that the object was added to the design. You can call links whatever you like, provided that the name begins with a letter and contains only letters and underscore characters. There's probably a name length limit too.

ray.wurlod wrote:You can call links whatever you like, provided that the name begins with a letter and contains only letters and underscore characters. There's probably a name length limit too.

is there any predefined standard available to name the link?

say for example,

procdure should atart with pr_<name>
Trigger should start with tr_<name>

we follow the above standard while writing a SP or Trigger. i just want to know is there any IBM standard available for naming ? or we can decide for ourself?

So far almost every project that I've worked on has created a set of standard naming rules for everything from links and stages to variables and parameters.

No two projects have had the same rules, and only a few have had rules similar to another project.

There is no standard as such, however the name should reflect what exactly the purpose of that link..

Suppose you are reading from any database stage

Link name could be :-

L_TableName
L_TableName

For Sort Stage

L_DataSort


It also depends on your projects, however these linknames should be consistent throughout the project and can give readbility to the other user that what kind of data is flowing through the link..

Hope this helps !

karthi_gana wrote:All,

I would like to know the Datastage naming standard for the links as well as for the stages. is there any document available?

can anybody refer some useful links or documents?

I think the following ibm redbook is a good thing to start with. It was published this summer and was updated recently (september). It covers almost all parts/components of datastage and its repository that might be affected if you plan to implement naming standards.

InfoSphere DataStage Parallel Framework Standard Practices
Pasted from http://www.redbooks.ibm.com/abstracts/s ... .html?Open

BR

Werner

We use acronym-like designations for stages, and name them with all-uppercase letters. Links carry that designation on the output side of the stages, and we name them with all-lowercase letters.

An example: FTP input stage "FTPR_SALES_DATA", with an output link named "ftpo_sales_data". An Oracle input stage would start with "ORAR_", "R" for "read".

If nothing else, if you use Designer reports at all for documentation, it makes them a bit easier to read.

I'll echo what has been said above: there are many, many, many different naming standards that can be used for links and stages. The best ones are internally consistent, easy to read (on the canvas, in the log, and in reports), and forbid duplicate link names within a single job.

I've seen a wide variety of standards, and they can all work fine - as long as all the developers on the project use the same standard. It is also helpful if this standard is set up front (and spelled out in a document all developers have read access to and which they are required to read when they join the project. This document should have a lot more than naming standards in it, but that is a topic for a different thread) before any development starts.

The great thing about standards is that there are so many to choose from.

Q: How many Microsoft engineers does it take to change a light bulb?
A: None. They simply define a new standard called "darkness".

A standard is what is used barely enough such that the developers who come later can clearly see where it was not used.

I started out in the COBOL world 20 years ago, and I will pompously and arrogantly assert that you guys have it easy by comparison.

Don't work FranklinE,

Your secret is safe with me. But I will agree that COBOL has its own set of challenges and quirks.

A standard is what is used barely enough such that the developers who come later can clearly see where it was not used.

I'll offer a corollary to your statement:
A standard is only a standard when it is enforced.

One of the few good aspects to working in Defence is that enforcement of standards is not a problem. At least once the standards have been established and everyone has agreed that they're the right ones to use! But that's done up front, so it's all good.