Ipaddress similar to how we have distributed dynamic vipa on z/OS

Here's the scenario
State Farm has a client server where they catalog a single node of the purescale cluster 10.5/FP5
then then connect successfully from a 10.5/FP4 client,
they then run a statement,
then kill a member,
the connection gets rerouted successfully without any client side configuration (-30108 on first retry, success on second).

If they open another session on the same server or run db2 terminate and try to connect in the same session there are two issues.

1. The connection does not get routed to another member that is up even though the ip address list was been returned via a previous successful connection. This is because the ip address list does not get persisted to disk for the CLP and possibly is the same for CLI. It should (in my opinion) be persisted. Probably an RFE??
2. This connection to the member that is done eventually returns an error message(30081) after about 5 minutes. What State Farm would expect would be a sqlcode 1224 when member is down rather than waiting for 5 minutes to get 30081
3. Does CLI behave the same way as CLP?

What they would really like is a group ipaddress similar to how we have distributed dynamic vipa on z/OS so that apps can catalog one ip address and if any member in the cluster is available they will get routed to it instead of getting an error.

State Farm Response to this URL
For DVIP:
Customer can use client side solution to specify members for the initial connection by enabling enableAlternateServerListFirstConnect and providing serverlist.
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.apdv.cli.doc/doc/c0056196.html

Sounds great but why would I want to have to do this on every client and have to update every client if I add members when IBM is using TSA for the cluster which already has the capability to have a virtual IP address for the cluster?



That's every JVM that wants to connect for java and every Linux server. You guys got anything to generate the XML for the db2dsdriver.cfg?



That doc also states



Note that if you do not define a list of alternate servers in the db2dsdriver.cfg configuration file, at the first successful connection to the server, the client obtains from the server a list of all available alternate servers. The client stores the list in memory and also creates a local cache file, srvrlst.xml that contains the server's list of alternate servers. This file is refreshed whenever a new connection is made and the server's list differs from the contents of the client srvrlst.xml file.



That is apparently not the case at least for CLP apps.


Rob Lemeuix