
Unable to run db2 commands via 'su'
JP, in order to understand this, you need to know a bit about the way CLP is
implemented.
The "db2" executable is referred to as a "Front-End" application. When it is
first called, DB2 will launch a "Back-End" process ("db2bp") which will service
that front-end application.
When that service is done, and the Front-End application goes away, the
Back-End process stays around in case another Front-End comes along.
I suspect that your problem is occurring because there is an existing backend
process which is "owned" by a previous ID. When you call a "db2" Front-End
application, it will try to talk to the existing Back-End process, and fail
because that Back-End is owned by a different ID.
The solution to your problem might be the same as Dorie recently suggested to
someone else (Ron Boggs)... from the first ID, do a "db2 terminate" command.
This will end the existing Back-End process, so that the 2nd ID will be able to
start a useable one.
This is an inherent problem (I won't call it a 'bug') in CLP when using more
than one ID. The best way to avoid this problem is to always always always
always always always always always always always always always use "terminate"
at the end of CLP scripts, and if using interactive CLP, always always always
always always always always always always do a "db2 terminate" when you're done.
Note that while "db2 quit" does end the CLP session, it does NOT terminate
the Back-End process. That's why I highly recommend using "terminate" instead
of "quit" in multi-user scenarios. (In my previous position in DB2 Function
Test this caused us incalculable grief for a loooong time until we forced all
test buckets to use "terminate".)
Hope this helps.
Quote:
> DB2 UDB 5.2 Fixpack 13, Aix 4.3.2
> I have some Unix shell scripts which run db2 commands via the 'su' command
> as the instance owner. Normally this works fine but on a box with multiple
> instances I keep getting the following messages :
> nirvana:/tmp/jp>su - osm -c "db2 connect"
> DB21016E The Command Line Processor encountered a system error while
> sending the command to the backend process.
> The following is also found in the db2diag.log file :
> 2000-11-10-15.19.34.216033 Instance:osm Node:000
> PID:19370(db2) Appid:
> oper_system_services sqlowque Probe:5
> 0000 000d ....
> All commands work fine when directly logged in as the instance owner, either
> with single or multiple instances running. Checked DB and DB Manager
> parameters and all seem ok - is it kernel parameters ? If so which ones ?
> Idea's appreciated.
> Thanks
> John.
--
Larry Menard
IBM Workstation Database (DB2) Performance Team
Defender of Geese and of all things Natural