Hello again,
I've some news regarding my own question/experience (see
http://msgs2.adsm.org/cgi-bin/get/adsm0309/57.html)
The experience, which I had described there, was (re)proven by myself on a
different environment: A test on SUN Solaris (5.8) with SAP R/3 (6.2) and
Oracle (9.2) ended up the same way: backint V3R3M1 don't seem to take care of
the entries made in the 'init<sid>.utl'-file.
This sentence is only >half< true:
I manage to adjust a workaround by erasing the definitions for the first server
completly out of then *utl-file. Now backint knows nothing about the first
server anymore, and establishs two sessions to server two as defined. Deleting
the second server and taking only the first one (changing the server) leads to
the same, of course. I even tested, what happened, if you define only one
server, but with 0 session. As expected, backint fails.
But that workaround arises another problem:
Imagine you have an automatic script procedure, which change your *.utl file by
demand, to ensure, that each backup is made on the 'right side' (eg. the
correct server). When establishing that workaround I mentioned before, you have
to ensure, a "backint -p init<sid>.utl -u user -f password" is executed after a
change of the *utl-file. Interactive passwords in a batch process??? *little
laugh* Bad idea, isn't it?
By the way, is there a chance to give backint the password without using
interactive shell? OK, there is the -pa option, but that would either be
seeable in the command line or from a job scheduler like crontab or Autosys.
Unluckly again, IBM offers only backint V3R3M1 as a full release on its
website. All backint versions before are presented as 'Patchsets' only. Of
course, we have an older version of backint for Solaris and AIX, but any
additional help or comments on this untypical behaviour of backint would be
appreciated.
Marcel Runte
Deutsche BP AG
Downstream Digital Business
Germany, Central and Eastern Europe
Department ISO-1 (Systems)
|