IBM Support

Configuring RDB Names for High Availability and External System Access

Troubleshooting


Problem

If two systems are used as mirrors of each other and are accessed by an outside system, it might be difficult to set up the RDB directories correctly. This document explains one possible setup.

Resolving The Problem

There are many times when two IBM System i products are used in conjunction that one system is the backup of the other. In case of a problem on the main system, the systems "role swap" so that the second system takes over the workload. For these two systems to stay synchronized, some sort of communications happen between them.

Now, assume there is another system that needs to access whichever system is currently active. The problem comes in from the fact that the two System i systems need different names to be able to talk to each other, but they also need a common name so that the outside system can access whichever one is up without changing names.

In our example, System A and System B are the two System i systems. Assume we also have a System N that is an outside system that needs to access System A or B, depending upon which one is currently active. The set up follows:

System A:
TCP/IP Address: 1.1.1.1
RDB Entries:

NameAliasRemote LocationRemote Type
MainDBn/a*LOCAL*IP
MainDBOtherDB1.1.1.2*IP
SysNDBn/a1.1.1.3*IP

System B:
TCP/IP Address: 1.1.1.2
RDB Entries:
NameAliasRemote LocationRemote Type
MainDBn/a*LOCAL*IP
MainDBOtherDB1.1.1.1*IP
SysNDBn/a1.1.1.3*IP

So, for each system you run the following commands:

System A:

ADDRDBDIRE RDB(MAINDB) RMTLOCNAME(*LOCAL *IP)

ADDRDBDIRE RDB(MAINDB OTHERDB) RMTLOCNAME('1.1.1.2' *IP)

System B:

ADDRDBDIRE RDB(MAINDB) RMTLOCNAME(*LOCAL *IP)

ADDRDBDIRE RDB(MAINDB OTHERDB) RMTLOCNAME('1.1.1.1' *IP)

System N:
TCP/IP Address: 1.1.1.3
RDB Entries:
NameAliasRemote LocationRemote Type
SysNDBn/a*LOCAL*IP
MainDBn/aMainDB*IP

Host Table Entries:
Internet AddressHost name:
1.1.1.1MainDB

Host Table Entries when role swap takes place (this could also be done by a network switch):
Internet AddressHost name:
1.1.1.2MainDB

With this setup, System A or B can access themselves with the name MainDB. When they need to connect to the other system, they use the name OtherDB. OtherDB is aliased on each side to MainDB and has the TCP/IP address of the other system. This way they can connect to OtherDB, which the system will replace with MainDB allowing the connection to occur. Remote journaling or other processes going between the systems would use OtherDB as the remote RDB name.

Because they both have a local name of MainDB, an outside application can always connect to MainDB and the connection will work. The item that must change is the network. This can be done by one of the following ways. The first method is to use a DNS name with local look-up before remote look-up. With this set up, the host table is changed from the TCP/IP address of System A to the TCP/IP address of System B. The second method to do this is with a network that does the same processing - intercepts one address and replaces it with the other. Many Enterprise-level switches offer this functionality.

If the system names are different, the following configuration is also supported.

System A
TCP/IP Address: 1.1.1.1
RDB Entries:
NameAliasRemote LocationRemote Type
SysAn/a*LOCAL*IP
SysAMainDB1.1.1.1*IP
SysNDBn/a1.1.1.3*IP

System B
TCP/IP: 1.1.1.2
RDB Entries:
NameAliasRemote LocationRemote Type
SysBn/a*LOCAL*IP
SysBMainDB1.1.1.2*IP
SysNDBn/a1.1.1.3*IP

Notes on RDB and Alias Use

The source RDB may have an alias and that alias can be used to connect successfully with DRDA. Creating multiple RDB entries on the source system with the same name and different alias names is permissible.

So, in theory, you could connect from one source system to multiple different boxes that all have the same *LOCAL RDB name at the same time .

DDM RDB name on source system does not have to match target *LOCAL RDB name - as long as the target system has an alias for the *LOCAL RDB name. For example, LPDAC710 has an RDB name that can be used to access RCHASK60 named "K60ALIAS". Remote location on that entry is "rchask60". This works because there is a matching RDB entry on rchask60 named K60ALIAS that is an alias to the *LOCAL name which is RCHASK60.

On LPDAC710, STRSQL -> "Connect to K60ALIAS" works fine with the config below:

On LPDAC710:
Relational database  . . . . . . :   K60ALIAS
Remote location:                            
 Remote location  . . . . . . . :   rchask60
   Type . . . . . . . . . . . . :   *IP    
 Port number or service name  . :   *DRDA  

On RCHASK60:
Relational database  . . . . . . :   RCHASK60
 Relational database alias  . . :   K60ALIAS
Remote location:                            
 Remote location  . . . . . . . :   loopback
If the above alias is removed from rchask60, the "Connect to K60ALIAS" from LPDAC710 will fail with "Relational database K60ALIAS not found."

[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"6.1.0"}]

Historical Number

416466888

Document Information

Modified date:
18 December 2019

UID

nas8N1014936