Re: Hostnames conflict imminent in Connect String - Haaaalp!

In <4aqr1n$pq4_at_gaia.cc.gatech.edu> badri_at_cc.gatech.edu (badri) writes:
>
>
>Hi:
>
> I have a machine called host1. We bought anew machine
>recently (both Dynix/ptx boxes). We run a lot fo batch jobs
>that reference the hostname absolutely as "host1". This is
>in batch jobs where the connect string is being passed as
>a parameter. Now that we are moving to the new machine, I
>want to explore easier options than changing hundreds of files.
>The instance name on both the machines (ORACLE V 7.2.2.4) is
>the same. I am aware of only one other option:
>
> Change the hostname of the new machine to host1 and change
>the name of the existing machine to host2 (for example) and run the
>scripts. The problem here is that if we want to fall back to the
>machine that is currently host1, we need to revert its name again.
>
> Is there a way by which I can declare equivalent hostnames
>and also ensure that the jobs only run on the new machine? In
>addition I want the switch back and forth (if need be) to be easy.
>Incidentally, the two machines are connected by a FDDI ring. There
>are a lot of PC clients that reference the hostname absolutely as
 well.
>The jobs are not in the same directory or filesystem for me to do a
 grep
>and replace with a shell script. Some of them have hardcoded server
>names and have been compiled!
>
>any suggestions/ideas are greatly welcome,
>
>thanks a lot,
>
>-Badri
>
>p.s: This may not be an oracle question, but I thought my senoirs
>would have had something like this to do before and would shed some
light!

You're obviously still using SQL*Net V1. If you upgrade to SQL*Net V2, which you have to do sometime in the next six months anyway as V1 is obsolete, you can create 'service handles' that are host/protocol/sid independant that become portable.

Rich Woods
Oracle Worldwide Customer Support Received on Mon Dec 18 1995 - 00:00:00 CET