Thank you Serge, I understand the reasons for such a behaviour. But
still I'd like to find a way to work with SPs having little impact on
DBAs activity.
It seems to me that "VALIDATE RUN" will solve the problem IF (AND ONLY
IF) at runtime db2 takes into account group membership for collecting
privileges. An appropriate test would be:
- grant only SELECT privilege on a table to PUBLIC
- login as a normal user
- CALL SYSPROC.SET_ROUTINE_OPTS('DB2_SQLROUTINE_PREPOPTS= VALIDATE
RUN')
- CREATE PROCEDURE xxx containing and UPDATE clause on that table
- ignore warnings on privileges
- CALL the procedure, hoping it works!

unfortunately the above workflow doesn't work, I receive fatal errors
when creating the SP due to the missing UPDATE privilege on the table.
(no problems related to bindadd or similar)

What's wrong with it? Is there any chance that this is the right
approach?
Otherwise, would the OWNER parameter of BIND command solve the problem?
I mean: a temporary DBADM creates all the SP (validate bind semantic)
assigning them to the instance owner ID; when the user is subsequently
revoked the DBADM privilege, will everithing continue running?

cheers
virgilio