Use of Server routines in Parallel Jobs
Moderators: chulett, rschirm, roy
Use of Server routines in Parallel Jobs
Hi,
We are currently using some Server Routines in our Server Jobs. We would be shortly upgrading our DataStage server to an Enterprise Edition. We would like to know whether we can use our current Server Routines in our new Parallel Jobs that we would be developing.
We are currently using some BASIC fuctions like "DSGetLinkMetaData" in our Server routines. Are use of these kinds of functions valid in a Parallel Job / Enterprise Edition?
Thanks.
We are currently using some Server Routines in our Server Jobs. We would be shortly upgrading our DataStage server to an Enterprise Edition. We would like to know whether we can use our current Server Routines in our new Parallel Jobs that we would be developing.
We are currently using some BASIC fuctions like "DSGetLinkMetaData" in our Server routines. Are use of these kinds of functions valid in a Parallel Job / Enterprise Edition?
Thanks.
Ok, thanks a lot DSguru2B.
So, if we are going to be on a MPP environment, then would need to write an equivalent code of Server routine into Parallel routine (in C / C++), right?
Again in that case, currently we are using BASIC functions like "DSGetLinkMetaData" in our Server routines. So, is it that these kinds of functionalities can never be done on a Parallel routine (or on a MPP environment)?
So, if we are going to be on a MPP environment, then would need to write an equivalent code of Server routine into Parallel routine (in C / C++), right?
Again in that case, currently we are using BASIC functions like "DSGetLinkMetaData" in our Server routines. So, is it that these kinds of functionalities can never be done on a Parallel routine (or on a MPP environment)?
-
- Premium Member
- Posts: 23
- Joined: Fri Mar 28, 2003 5:41 pm
- Location: USA
Re: Use of Server routines in Parallel Jobs
If you are gathering information about a parallel job after it has run, you can invoke a BASIC routine in 7.x as an After Job Routine in a parallel job, because once the job is finished it is no longer running in parallel. That After Job Routine still has access to the job's handle, so it can proceed to gather the information you want, even though it is no longer running in parallel.
vnspn wrote:Hi,
We are currently using some Server Routines in our Server Jobs. We would be shortly upgrading our DataStage server to an Enterprise Edition. We would like to know whether we can use our current Server Routines in our new Parallel Jobs that we would be developing.
We are currently using some BASIC fuctions like "DSGetLinkMetaData" in our Server routines. Are use of these kinds of functions valid in a Parallel Job / Enterprise Edition?
Thanks.
EPCCTX
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
You an use server routines in an MPP setup, provided you license DataStage server on every machine in the cluster or grid. Your account rep will be able to retire on the commission!
Server routines require the DataStage Engine to execute. This only exists on the machine where the DataStage server is installed.
Server routines require the DataStage Engine to execute. This only exists on the machine where the DataStage server is installed.
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.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Pretty much the case - you do have to make sure that a small number of components are deployed to the other machines, perhaps by mounting disk, perhaps by other means. Details are in the manuals. But only the parallel framework supports this capability; server jobs expect to run on a server, hence the name.
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.