Db2-Z/OS IP address cached in DDF

Carol Hynes

Db2-Z/OS IP address cached in DDF
We are using Websphere Federation Server to connect our mainframe batch
and CICS applications to an Oracle Database. We used a DNS name in the
IPADDR column of the IPNAMES table assuming that if we needed to switch
to a new WFS server, we could simply change the IP address on the DNS
server and DB2 would dynamically resolve the new IP address.

Unfortunately we have confirmed with IBM that the IP address gets cached
in DDF and the only way to get the new address is to cycle the DDF.
Since this application is not the only user of DDF, we cannot change
servers without impacting other applications. For scheduled maintenance
this is not a problem, as we have a maintenance window during which we
could cycle the DDF. It's the "unscheduled" maintenance that I'm
concerned about. Our plan was to have a separate server set up for
failover and in the event the primary server had a problem, we'd just
change the IP address in the DNS server and we'd be up and running in a
matter of minutes.

The DB2 support folks at the data center will work on opening up a
requirement with IBM, to allow a "refresh" of the IP addresses without a
recycle, but in the meantime, I was wondering if anyone had any ideas as
to how I could get around the DDF recycle.

Thanks,

Carol

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

James Campbell

Re: Db2-Z/OS IP address cached in DDF
(in response to Carol Hynes)
Most operating systems and tcpip stacks (you don't mention which one the
WFS is on) have the ability to hang multiple ip address off a single network
interface.

You **might** be able to manipulate the tcpip stacks on the primary and
backup WFS systems so that the ip address is now associated with the
backup system; and to flush the internal routing cache on the intermediate
routers so they can be rebuit with the updated information.

Alternatively - which version of DB2 are you using? DB2 V8 has the ability
to have multiple ip address associated with a location name (using
SYSIBM.IPLIST). You might find that if the primary WFS server isn't active
DB2 will go looking for an IPLIST entry and, if you've just inserted one, use
that. (And, no, I haven't done any experimentation along these lines.)

James Campbell

On 4 Jan 2007 at 11:01, Hynes, Carol wrote:

>
> We are using Websphere Federation Server to connect our mainframe batch and CICS
> applications to an Oracle Database. We used a DNS name in the IPADDR column of the
> IPNAMES table assuming that if we needed to switch to a new WFS server, we could simply
> change the IP address on the DNS server and DB2 would dynamically resolve the new IP
> address.
> Unfortunately we have confirmed with IBM that the IP address gets cached in DDF and the only
> way to get the new address is to cycle the DDF. Since this application is not the only user of
> DDF, we cannot change servers without impacting other applications. For scheduled
> maintenance this is not a problem, as we have a maintenance window during which we could
> cycle the DDF. It's the "unscheduled" maintenance that I'm concerned about. Our plan was to
> have a separate server set up for failover and in the event the primary server had a problem,
> we'd just change the IP address in the DNS server and we'd be up and running in a matter of
> minutes.
> The DB2 support folks at the data center will work on opening up a requirement with IBM, to
> allow a "refresh" of the IP addresses without a recycle, but in the meantime, I was wondering if
> anyone had any ideas as to how I could get around the DDF recycle.
> Thanks,
> Carol
> --------------------------------------------------------------------------------- Welcome to the IDUG DB2-L list.
> To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-
> l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at
> http://www.idugdb2-l.org. The IDUG List Admins can be reached at DB2-L-
> [login to unmask email] Find out the latest on IDUG conferences at
> http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm