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)
