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)