RE: security hole in interactive sql call statement?

I promises to shut up after this.

I think most of you get what I try to say, but some don't.  I'm concluded with 
below.

Here is the background:
1) First of all, all our production data files are secured from programmers.  
They only have read-only access for most files.  The libraries are also 
secured.  Programmer cannot add/delete object from library.
2) Programmer user profiles are set to LMTCPB(*YES) on production box (They 
have another userID that have command line access but require signature from 
manager to get activate and these user IDs are under audit).
3) We also have ftp, and database server exit programs that will restrict 
programmer from doing anything remotely.

With above, below is why I thing this is a security hole:
4) Programmers (me) love STRSQL.  Because of the above, we have assumed that 
letting programmer have STRSQL access will not be a problem.  Well, as I 
mentioned before, that is not exactly true.  Inside STRSQL, programmer is able 
to use SQL call statement to call any program (include those that are not 
created as external sql procedure).  Personally, if I set the user profile to 
LMTCPB(*YES), the profile should not be able to access any limited command from 
any ibm tool.
5) Because the call command is wide opened, the LMTCPB(*YES) has become 
useless.  In the STRSQL session, programmer can do CALL QCMDEXC ('ANYCOMMAND', 
000000010.0000) to access any command.  (most command are shipped with *public 
*use, to secure every command is closed to impossible).