DataStage Client/Server Connectivity

Connection from a DataStage client to a DataStage server is managed through a mechanism based upon the UNIX remote procedure call mechanism.  DataStage uses a proprietary protocol called DataStage RPC

which consists of an RPC daemon (dsrpcd) listening on TCP port number 31538 for connection requests from DataStage clients.

Before dsrpcd gets involved, the connection request goes through an authentication process.  Prior to version 8.0, this was the standard operating system authentication based on a supplied user ID and password 

(an option existed on Windows-based DataStage servers to authenticate using Windows LAN Manager, supplying the same credentials as being used on the DataStage client machine – this option was removed for 

version 8.0). With effect from version 8.0 authentication is handled by the Information Server through its login and security service.

Each connection request from a DataStage client asks for connection to the dscs (DataStage Common Server) service.The dsrpcd (the DataStage RPC daemon) checks its dsrpcservices file to determine whether there is an entry for that service and, if there is, to establish whether the requesting machine's IP address is authorized to request the service.  If all is well, then the executable associated with the dscs service (dsapi_server) is invoked.

DataStage Processes and Shared Memory

Each dsapi_server process acts as the "agent" on the DataStage server for its own particular client connection, among other things managing traffic and the inactivity timeout.  If the client requests access to the Repository, then the dsapi_server process will fork a child process called dsapi_slave to perform that work.

Typically, therefore, one would expect to see one dsapi_server and one dsapi_slave process for each connected DataStage client.  Processes may be viewed with the ps -ef command (UNIX) or with Windows Task Manager.

Every DataStage process attaches to a shared memory segment that contains lock tables and various other inter-process communication structures.  Further each DataStage process is allocated its own private 

shared memory segment.  At the discretion of the DataStage administrator there may also be shared memory segments for routines written in the DataStage BASIC language and for character maps used for National 

Language Support (NLS).  Shared memory allocation may be viewed using the ipcs command (UNIX) or the shrdump command (Windows).  The shrdump command ships with DataStage; it is not a native Windows command.

RUN-TIME

Now let us turn our attention to run-time, when DataStage jobs are executing.  The concept is a straightforward one; DataStage jobs can run even though there are not clients connected (there is a command line interface (dsjob) for requesting job execution and for performing various 

other tasks).

However, server jobs and parallel jobs execute totally differently.  A job sequence is a special case of a server job, and executes in the same way as a server job.

Server Job Execution

        Server jobs execute on the DataStage server (only) and execute in a shell called uvsh (or dssh, a synonym).  The main process that runs the job executes a DataStage BASIC routine called DSD.RUN – the name of this program shows in a ps –ef listing (UNIX). This program interrogates the local Repository to determine the runtime configuration of the job, what stages are to be run and their interdependencies.  When a server job includes a Transformer stage, a child process is forked from uvsh also running uvsh but this time executing a DataStage BASIC routine called DSD.StageRun.  Server jobs only ever have uvsh processes at run time, except where the job design specifies opening a new shell (for example sh in UNIX or DOS in Windows) to perform some specific task; these will be child processes of uvsh.

Parallel Job Execution

        Parallel job execution is rather more complex.  When the job is initiated the primary process (called the “conductor”) reads the job design, which is a generated Orchestrate shell (osh) script.  The conductor also reads the parallel execution configuration file specified by the current setting of the APT_CONFIG_FILE environment variable.  Based on these two inputs, the conductor process composes the “score”, another osh script that specifies what will actually be executed.  (Note that parallelism is not determined until run time – the same job might run in 12 nodes in one run and 16 nodes in another run. 

        This automatic scalability is one of the features of the parallel execution technology underpinning Information Server (and therefore DataStage).Once the execution nodes are known (from the configuration file) the conductor causes a coordinating process called a “section leader” to be started on each; by forking a child process if the node is on the same machine as the conductor or by remote shell execution if the node is on a different machine from the conductor (things are a little more dynamic in a grid configuration, but essentially this is what happens).  Each section leader process is passed the score and executes it on its own node, and is visible as a process running osh.  Section leaders’ stdout and stderr are redirected to the conductor, which is solely responsible for logging entries from the job.

        The score contains a number of Orchestrate operators.  Each of these runs in a separate process, called a “player” (the metaphor clearly is one of an 

orchestra).  Player processes’ stdout and stderr are redirected to their parent section leader.  Player processes also run the osh executable.Communication between the conductor, section leaders and player 

processes in a parallel job is effected via TCP.  The port numbers are configurable using environment variables.  By default, communication between conductor and section leader processes uses port number 10000 (APT_PM_STARTUP_PORT) and communication between player processes and player processes on other nodes uses port number 11000 (APT_PLAYER_CONNECTION_PORT).

To find all the processes involved in executing a parallel job (they all run osh) you need to know the configuration file that was used.  This can be found from the job's log, which is viewable using the Director client or the dsjob command line interface.