Chapter 4. Installation and configuration
4.35 Configuring and verifying client installations
Once the DataStage server has been installed, the DataStage client should be installed on each client workstation. This section provides specific requirements and notes regarding the DataStage client.
The version of the DataStage client is tightly tied to the version of the
corresponding DataStage Server. The product release notes will detail which client versions are compatible with a particular server.
For example, DataStage for Windows 8.1 requires and is only compatible with Version 8.1 of the DataStage client. Furthermore, DataStage client release 8.1 should only be used against a Version 8.1 DataStage server on Windows. (This should not be confused with release 8.1 for UNIX and UNIX System Services platforms.)
For this reason, it is often necessary to install and maintain multiple DataStage client versions on a single workstation. This is particularly the case when developing against different server platforms and when performing a DataStage server upgrade.
Important: You must always match the version numbers of the DataStage client and server. This eliminates any potential compatibility issues between the DataStage server and plug-in GUI clients or DataStage clients.
4.35.1 DataStage Multi-Client Manager
The DataStage Multi-Client Manager (MCM) allows multiple versions of the DataStage client to be installed on a single workstation. Only one version can be active at any time, but the MCM allows switching between installed versions. The DataStage Multi-Client Manager is now part of the default client install. If you do not want to installed or configured the MCM on your workstation, select a custom client install. This provides an option to not install the Multi-Client Manager.
Otherwise, the DataStage Multi-Client Manager installs a Windows service. During installation, it prompts you for the user name and password of a Windows administrator to install and start this service. This service needs to be run using a user account that is part of the administrator group on the local machine, because the service must alter settings in the Windows registry. It cannot be the built-in local administrator. Consider the following:
Even for local administrator accounts, you must supply the fully qualified Windows login name and password. This is of the form DOMAIN\USER, where DOMAIN is the name of your Windows server for local (non-domain) logins.
Before the DataStage Client installer is run, the user must exist and be in that group. Also, the local security policy must be set up so that the user account has the
logon as a service
user rights assigned to it. If a user account that is in the administrators group on the local machine is not specified, then the service will not be placed or installed in the service control manager, and so the MCM will not work.
If a valid user account is specified but does not have the
logon as a service
user rights, then the service will be installed into the service control manager, but it will not be started. The user would have to manually go to the service control manager, re-enter the user account and password for the service, and start the service. At this point the service control manager would automatically assign the correct user rights to the account. Rebooting the machine does not solve the problem.Note: The Multi-Client Manager installs the DataStage Multi-Client Manager Windows service using the administrative user and password that you specify. If you change the password for this account, you must update the service startup properties to use the new password.
4.35.2 WAN development considerations
The DataStage client is a four-tier client/server application. As such, its internal communication protocol includes many messages. Therefore, it is not intended for networks where the latency (roundtrip transmission time for messages) is large.
When using DataStage for remote or distributed development across a wide area network (for example, developers across the world communicating with a central server), it is better to configure a centralized Windows
terminal server
using Microsoft Remote Desktop, CITRIX, VNC, or similar technologies. In these configurations, the DataStage client would be installed on the Windows machine that is co-located with the DataStage Servers.4.35.3 Secure client installation considerations
Implementing secure installation requires that users other than dsadm be restricted from administrative functions. In addition to InfoSphere Information Server roles, this is accomplished by performing a custom installation and de-selecting the DataStage Administrator client on all workstations other than those authorized to use dsadm. Figure 4-9 depicts a custom client install panel.
This step is important in securing your installation. The workstations on which the administrator function is installed should be password secured and listed in a client installation inventory.
An effective method of specifying which workstations are to receive which functions is a table such as Table 4-32. We describe our requirements in terms of the business function that the user supports wherever possible. The installer must certify that the administrator function is installed only on the workstations that are specified.
Table 4-32 Workstation administrator functions
4.35.4 Enterprise Application PACKs
If you want to install and run any of the DataStage Enterprise Application PACKs, you must first uninstall the previous version of the DataStage client (if installed). Failure to do so will result in the stage editors for these PACKs failing to load in the Designer client.
Fix packs, patches, and refreshed install packages might be available for InfoSphere Information Server and its components. Periodically check the following web page for the current listings:
http://www.ibm.com/software/data/infosphere/support/info-server/ Workstation User Administrator Server Version Comments
ws127 johnl Yes No Yes John is the primary project administrator responsible for all areas of the project.
ws324 paulm Yes No Yes Paul is the secondary project administrator responsible for all areas of the project.
ws718 georgh No No No
ws817 richards No No No
ws887 mannie No Yes No Mannie is a contractor who will develop server routines.
ws888 moe No Yes No As above.