We have decided to invest in the Balanced Optimizer for Datastage to help us pushdown DB level functions and utilize the underlying DBs like neteeza properly. In theory, we understand the following flow in using BO.
1. Design DS job in designer.
2. Open BO window from designer and generate the optimized job by selecting the options.
3. Save the optimized job.
Now can I just export this job to another server (running the same version of DS), but without BO installed and run the job. In short, is the BO plugin used at the time of the optimized job generation or is it used at runtime as well, which would warrant us to pretty much procure the plugin for the entire landscape.
Would appreciate any response in this regard.
Thanks,
KK
Balanced Optimizer - Architecture Query
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 15
- Joined: Mon Jan 31, 2005 6:19 pm
Re: Balanced Optimizer - Architecture Query
This. After that it's just a 'regular' job.kripakarprasad wrote:the BO plugin used at the time of the optimized job generation
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 15
- Joined: Mon Jan 31, 2005 6:19 pm
Re: Balanced Optimizer - Architecture Query
Thanks for the response. That was our initial thought as well, but when we reached out to the vendor to confirm the same, prior to purchasing the license, here is the response we got. Am I missing something here. Would I really need to have it on my Non-dev envts?
"the generation of the Optimized code gets done in Dev (what is done from the developer's desk), but the "Optimized" code is then compiled and run in the Optimized way, which is why there would be a runtime license. It's PVU based because its a DataStage Engine component, and is licensed based on the DS environment and capacity it runs on."
"the generation of the Optimized code gets done in Dev (what is done from the developer's desk), but the "Optimized" code is then compiled and run in the Optimized way, which is why there would be a runtime license. It's PVU based because its a DataStage Engine component, and is licensed based on the DS environment and capacity it runs on."
Interesting... don't remember that from what little I've read about it. The "run in the Optimized way" doesn't make a lick of sense to me but perhaps it will to others who have had actual experience with the BO option. I can however see how they would happily force you to license it everywhere because, well... fees.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 15
- Joined: Mon Jan 31, 2005 6:19 pm
I have not used it, but only read about it here.
It appears to be a design-time tool only. The document states that once the developer verifies the final output, "the job is ready to compile and run."
The add-on has to be licensed in some way, however, the pricing model you described for this does not entirely make sense. I think it would make more sense if it were tied to the number of authorized DataStage users. Maybe you have other ideas?
I have sometimes seen the vendor offer multiple pricing models. If they don't make sense, we tell them so, and they usually come back with an alternative model.
It appears to be a design-time tool only. The document states that once the developer verifies the final output, "the job is ready to compile and run."
The add-on has to be licensed in some way, however, the pricing model you described for this does not entirely make sense. I think it would make more sense if it were tied to the number of authorized DataStage users. Maybe you have other ideas?
I have sometimes seen the vendor offer multiple pricing models. If they don't make sense, we tell them so, and they usually come back with an alternative model.
Choose a job you love, and you will never have to work a day in your life. - Confucius
-
- Participant
- Posts: 15
- Joined: Mon Jan 31, 2005 6:19 pm