DSXchange

Hello All,

I am trying to extract a subsrting based on a delimiter. Now all of you must be thinking that this is easy and why I am asking this question?

The reason is that the delimiter I am supposed to use is a string and not a chracter. All the substring functions in the DS BASIC use a single character as a delimiter rather than a string itself.

The other problem I have is that I cannot write a routine. This is a client requirement. So I have to do this in a Transformer Stage itself.

An example:

The Value String = "ABCDEFGHIJKL"
The Delimiter String = "EFG"
The Resultant String1 = "ABCD"
The Resultant String2 = "HIJKL"

Any insights?

Thanks,
Siddharth

INDEX will return the starting byte position for a given occurrence of a substring within a string.

Opinion alert:
Your client requirement is asinine.
Tell them I said so.

Your solution is:
This code works for a string of two fields only. If you have to go for something like the third delimited field, we'll work on that if needed.

By the way, your client requirement is asinine.

I would love to hear why the client has an embargo on routines!

Since you can't use routines you can avoid long derivation code by using Stage Variables. For example you can put a COUNT into a stage variable to create a field that tells you how many delimited values are in the string.
FIELDCOUNT = COUNT(input.value, "EFG")

Now you can use this FIELDCOUNT throughout your transform. You can put one in the constraint to handle rows with a count of zero as a reject. You can put it into the derivation of your value columns.

The FIELD command is another way to get your delimited values:
FirstValue = FIELD(input.value, "EFG", 1)
IF FIELDCOUNT > 1 THEN SecondValue = FIELD(input.value, "EFG", 1) ELSE 0

Thanks again guys....

The reason the client is skeptical in using Routines is because the application that is being built is a Data Migration application which will be replicated across the globe for the users. The users would just be trained to start/stop the jobs from DataStage Director.

So for the easy maintaince purposes the client wants the usage of Routines to be negated.

Thanks,
Siddharth

siddharthkaushik wrote:The other problem I have is that I cannot write a routine. This is a client requirement.

Ask your client if their goal is to produce correct results in the shortest amount of time, with the greatest reliability possible.

If so, then provide them with general guidelines on migrating routines along with their jobs to different projects.

Repeat to them that the goal here it to produce correct data, not make stylish programs. If we can make stylish code while producing correct data, well... it's a bonus!

-T.J.

P.S. Definitely a feature Ascential should use -- dependency migration for DSXs. "Oh, this job requires this routine... oh this routine requires..."

What the heck do you think the Dependencies tab is there for ?!!!

The old style of propagation (released jobs) could use it, so can Version Control.

I second Ken's condemnation of your client. They are, purely and simply, wrong. Tell them:

It's no big deal to ensure that Routines on which a job depends are deployed when the job is.

As someone once said on TV: "we have the technology...".

Your client is wrong in that there will come a time when you have a derivation that requires using a BASIC statement, not a function. The only way to use a BASIC statement is to build a Function with the statement inside.

In addition, your client has eliminated the possibility of re-usable objects, before/after subroutine calls that don't use pre-canned routines, as well as functions that have more logic than can fit within a derivation dialog box.

Please point your client at this site and we'll gang up on them.

ray.wurlod wrote: What the heck do you think the Dependencies tab is there for ?!!!

Are you talking about the Package Wizard in Manager? Won't work for PX. It is a pain in the arse to ensure that custom stages and buildops along with their associated table definitions are migrated. But it's NOT that hard. 5 minutes work or so.

-T.J.

The management and delivery of routines to other sites is a no brainer, routines are easily handled by export/import or the Version Control tool, they add virtually they can be used to improve the maintainability of jobs.

It is an interesting challenge to build a DataStage project that will be delivered to sites around the world and run by users who don't necessarily have much DataStage knowledge.

In a data migration you are likely to get rejections, warnings and aborts due to the uncertainty of source data and database connections. Novice users will find it easier to receive messages in an email, with reject files attached, rather than have to look for them through Director logs. If you have error handling and email notification in place you can make sure your support team is CC'd on all error messages from DataStage so they can keep track of problems from all sites. You can also collect and report on input and output row counts and rejection counts.

Hey Guys,

Vincent, TJ, Ken and Ray. Thanks for your insights. Infact I agree with you guys. I have been telling all these points to the client since I was industed into the project a month ago.

I have done 3 projects in DataStage and this is my fourth one; the previous three being in the Datawarehouse environment. So from my experience of DataStage, I have been telling to the client that if they want more robustness in their architecture, they use make full use of the capabilities of DataStage.

But I guess much English doesn't enter their heads and I don't know how to speak Chinese.....

Thanks,
Siddharth

Teej wrote:

ray.wurlod wrote: What the heck do you think the Dependencies tab is there for ?!!!

Are you talking about the Package Wizard in Manager? Won't work for PX. It is a pain in the arse to ensure that custom stages and buildops along with their associated table definitions are migrated. But it's NOT that hard. 5 minutes work or so.

-T.J.

OP specified Server

And Version Control supports the notion of a Custom Folder, which it "knows" has to be promoted/migrated.

We still have the technology...