This article explains the workings related to configuring access to multiple DB2 subsystes on a IBM/ZOS machine via the Attunity product. During the process of installing the product and configuring a DB2 data source according to our documentation, there are steps taken to modify RACF or Top secret security to gain access to the DB2 subsystem using our default server task names, ATTDAEMN and ATTSRVR and the ID used to run these tasks. For the cloned processes mentioned below I am going to assume the same security related tasks will be performed for the task names and the ID's running the alternate named tasks.
Note: It is also assumed here that the implementer has a working knowledge of the Attunity Studio product to configure the Attunity definitions used to gain access to the different subsystems.

Working with two different DB2 subsystems on MF:
For this explanation the DB2 subsystems will be named DB2T and DB2P. After the installation of the Attunity product is complete, we deliver JCL in our HLQ..USERLIB called ATTSRVR, which is to be copied to the startup proclib as a task for this system. We also deliver an ODBCINI file located in our PDS library called HLQ..USERLIB(ODBCINI). This is used to configure one DB2 subsystem using DB2 client access to get to the subsystem and data base configured within our product. This file is referenced in the default JCL in ATTSRVR.

********************************* Top of Data **********************************
; This is a comment line...
; Example COMMON odbcini
; Example SUBSYSTEM odbcini for DSN1 subsystem
******************************** Bottom of Data ********************************

For the DB2T subsystem we will use the default binding called NAV and the default workspace called Navigator in the Attunity product.

Configure access to the DB2T subsystem:
Using Attunity Studio under the NAV binding create a data source called DB2TDS pointing to a data base that is defined under the DB2T subsystem. Using the Studio Runtime Manager reload this configuration.Test this definition by querying the data source via the Attunity Query Tool selecting the workspace Navigator when prompted. When this tests through, sign onto the ZOS machine with an ID that has access to this subsystem and data base and the Attunity product. Execute the REXX EXEC script HLQ..USERLIB(NAVCMD) and at the "Local>" prompt type "execute DB2TDS". Run a simple query against one of the tables here to test subsystem and data base connectivity. When this has been tested thoroughly you are ready to create the components in the Attunity product to access alternate DB2 subsystems.

Configuring alternate DB2 subsystem access:
Copy the default members to new members in their respective PDS libraries.


Edit the member DB2PINI and change the subsystem ID to DB2P. Edit the member NAVDB2P and change the reference from the default member ODBCINI to the member DB2PINI.Moving back to Attunity Studio, create a binding called DB2PBND. Under this binding create a data source DB2PDS and fill in the parameters that are valid for this subsystem and data base. Under the IRPCDINI, create a new workspace called DB2PWRK and copy the configuration of the Navigator workspace. Edit this workspace and change the startupScript from the default ATTSRVR.XY value to ATTDB2P.XY. Change the workspace binding to use the new binding named DB2PBND. Using Runtime Manager reload the machine. This configuration should test through via a client server connection via the workspace.

Accessing DB2P via Attunity on the ZOS machine:
Execute the REXX EXEC script HLQ..USERLIB(NAVDB2P). At the "Local>" prompt type "switch DB2PBND" to use the new binding. At the "Local,DB2PBND>" prompt type "execute DB2PDS" to gain access to the data source. Run a simple query against one of the tables here to test subsystem and data base connectivity.