Diff between server Job Parallel Job
Moderators: chulett, rschirm, roy
Diff between server Job Parallel Job
Hi
Can any one please tell me what is the main diff between server job and a parallel job . It will be great if one can give me a situation where one has to develop server job only.
Becuase right now in our environment we have only parallel jobs.
-rekha
Can any one please tell me what is the main diff between server job and a parallel job . It will be great if one can give me a situation where one has to develop server job only.
Becuase right now in our environment we have only parallel jobs.
-rekha
Hi rekha,
Search the forum , you will find lot of stuff Also read the following post,
A quick answer to your question would be performance
Search the forum , you will find lot of stuff Also read the following post,
Code: Select all
http://www.dsxchange.com/viewtopic.php?t=95903&highlight=search+posting
I'm not going to cover the differences, that you can read from the 4 years of posts talking about them. I'll answer why someone would build a server job in an environment where only parallel jobs were built.
Server jobs are extremely flexible, don't require a lot of thinking to build. The Server side of DataStage is the original tool. The vast majority of customers only have the Server side licensed. Server side jobs only have a few active stages, because those stages do so much work in an intuitive and graphical nature. The equivalent logic in a PX job could span many stages. The Server side job has the full feature of the easy to use DS BASIC language plus functions, you don't have to be writing custom buildops. The hash file stage is powerful in that it allows for reading, writing, and updating a reference dataset. There is no equivalent in PX. Server jobs have a fantastic interactive debugger that lets you set watch points and step thru the job execution at the link level.
The short answer is that Server jobs are really fast to create, debug, and test. If power/speed leveraging shared resources across multiple nodes is not your only consideration, then Server jobs do well.
This is my opinion, but it's funny how snobby some folks are about PX. DataStage Server had made Ardent/Ascential, and the majority of ETL side customers still only use Server. Even with the TX, PX, Profile, and Quality product additions, the vast number of users and implementations are all about Server. It's not dead yet.
Server jobs are extremely flexible, don't require a lot of thinking to build. The Server side of DataStage is the original tool. The vast majority of customers only have the Server side licensed. Server side jobs only have a few active stages, because those stages do so much work in an intuitive and graphical nature. The equivalent logic in a PX job could span many stages. The Server side job has the full feature of the easy to use DS BASIC language plus functions, you don't have to be writing custom buildops. The hash file stage is powerful in that it allows for reading, writing, and updating a reference dataset. There is no equivalent in PX. Server jobs have a fantastic interactive debugger that lets you set watch points and step thru the job execution at the link level.
The short answer is that Server jobs are really fast to create, debug, and test. If power/speed leveraging shared resources across multiple nodes is not your only consideration, then Server jobs do well.
This is my opinion, but it's funny how snobby some folks are about PX. DataStage Server had made Ardent/Ascential, and the majority of ETL side customers still only use Server. Even with the TX, PX, Profile, and Quality product additions, the vast number of users and implementations are all about Server. It's not dead yet.
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
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
logic wrote:Hi rekha,
Search the forum , you will find lot of stuff Also read the following post,A quick answer to your question would be performanceCode: Select all
http://www.dsxchange.com/viewtopic.php?t=95903&highlight=search+posting
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
But, like any endeavour, to be done well they do require some planning and preparation.Server jobs are extremely flexible, don't require a lot of thinking to build.
- Have a source-to-target mapping document.
Have your metadata already in the Repository.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
lstsaur,
yes, the price difference (whatever it may be) is definately worth it to many organizations.
yes, the price difference (whatever it may be) is definately worth it to many organizations.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
How long is a piece of string?Ray,
It will cost about 675,000 for EE and 230,000 for Sever edition. Do you think is it worth to pay so much more for EE?
If you want the right tool for your circumstances, you buy the correct tool for your circumstances.]
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
This link does not seem to work ....... can any body view this link
logic wrote:Hi rekha,
Search the forum , you will find lot of stuff Also read the following post,A quick answer to your question would be performanceCode: Select all
http://www.dsxchange.com/viewtopic.php?t=95903&highlight=search+posting
This information was really helpful, thanks for your time
kcbland wrote:I'm not going to cover the differences, that you can read from the 4 years of posts talking about them. I'll answer why someone would build a server job in an environment where only parallel jobs were built.
Server jobs are extremely flexible, don't require a lot of thinking to build. The Server side of DataStage is the original tool. The vast majority of customers only have the Server side licensed. Server side jobs only have a few active stages, because those stages do so much work in an intuitive and graphical nature. The equivalent logic in a PX job could span many stages. The Server side job has the full feature of the easy to use DS BASIC language plus functions, you don't have to be writing custom buildops. The hash file stage is powerful in that it allows for reading, writing, and updating a reference dataset. There is no equivalent in PX. Server jobs have a fantastic interactive debugger that lets you set watch points and step thru the job execution at the link level.
The short answer is that Server jobs are really fast to create, debug, and test. If power/speed leveraging shared resources across multiple nodes is not your only consideration, then Server jobs do well.
This is my opinion, but it's funny how snobby some folks are about PX. DataStage Server had made Ardent/Ascential, and the majority of ETL side customers still only use Server. Even with the TX, PX, Profile, and Quality product additions, the vast number of users and implementations are all about Server. It's not dead yet.
The link would have worked fine if it was posted properly as a link. The way it was done, it needed to be cut-and-pasted into the Address line of your browser to see.rekha wrote:This link does not seem to work ....... can any body view this link
The URL tags allow you to link to other postings rather easily, see? There is a trick to learn to embed them in another object, like a line of text. It would also have 'worked' if it was just pasted in the body of the message like this:
viewtopic.php?t=95903&highlight=search+posting
It is the code tags it was wrapped in that made it cease to function as a link. FYI.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
I got it now .... the search in forum gave me old postings which are helpful
Thanks to all
Thanks to all
chulett wrote:The link would have worked fine if it was posted properly as a link. The way it was done, it needed to be cut-and-pasted into the Address line of your browser to see.rekha wrote:This link does not seem to work ....... can any body view this link
The URL tags allow you to link to other postings rather easily, see? There is a trick to learn to embed them in another object, like a line of text. It would also have 'worked' if it was just pasted in the body of the message like this:
viewtopic.php?t=95903&highlight=search+posting
It is the code tags it was wrapped in that made it cease to function as a link. FYI.
lstsaur wrote:Ray,
It will cost about 675,000 for EE and 230,000 for Sever edition. Do you think is it worth to pay so much more for EE?
If what you need is a space shuttle, why look at airplanes? If your requirement is to process billions of rows of data, you have a large hardware budget allowing carte blanche on your configuration, and your team are intelligent and experienced data integrators, and money to spend on tools, why would you buy Server? Likewise, if your requirement is millions of rows of data, you have a modest budget allowing for a single server implementation, your team is average developers with a few superstars, and a small software budget, why would you buy EE?
The hardware, team, budgetary and processing requirements have to come together when making this decision. I would like a Ferrari F430, but even having such a fast car is a waste of money if the speed limit is 55. Seating for 2 doesn't work with my family of five. Now if the streets were rated like the Autobahn, and I was a single guy, that F430 starts looking like the better decision.
Ahhh... Ferraris...
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
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
Comments about Parallel routines
what about Parallel routines , which forces the DataStage folks to know C?? comments please
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Server routines force you to know DataStage BASIC.
And there are probably a lot more C programmers out there than there are DataStage/UniVerse BASIC programmers.
What's the point? If you're going to program, you need to know/learn the programming language of choice for the application.
And there are probably a lot more C programmers out there than there are DataStage/UniVerse BASIC programmers.
What's the point? If you're going to program, you need to know/learn the programming language of choice for the application.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.