When you write SQL statements in PL/I or COBOL programs you normally do not prefix the table names with the creator of the table. The advantage of this is that you can decide the creator when making a DB2 BIND and thereby make the programs independent of the creator. Most installations use this trick to make SQL statements independent of the environment. Very few installations (I do not know any) write embedded SQL using the creator.
Unfortunately the absence of the creator makes it hard to copy a SQL statement embedded in a program and execute it using SPUFI, QMF or other dynamic SQL tools. For many years I have spent time adding the creator to all table names. Another trick is to use a SET CURRENT SQLID = '<creator>', but if this is possible it is also possible to manipulate the data in the table and that is normally not desirable in a production environment. Many installations have restrictions on SQLID's because of the above, and then SET CURRENT SQLID is only possible if you have SYSADM authorisation on the DB2 system.
Actually it is possible to set the creator without having any rights at all using a SET CURRENT SCHEMA = '<creator>'. When this SQL statement has been executed in SPUFI, QMF or another dynamic SQL tool the following SQL statements will use the specified creator where a creator is missing in a table name. Now you only need to find out what the name of the proper creator is. This depends on the environment you want to execute against and which program you have "cut" the SQL from. These two pieces of information you feed into this SQL statement:
It may not be the COLLID that is used to specify the environment name on your installation. The environment can also be controlled by the DB2 system making the COLLID the same regardless of environment. If your installation uses DBRM's instead of packages (highly unlikely) then QUALIFIER is found on SYSIBM.SYSPLAN.
The last hurdle in order to execute a SQL statement "cut" from a program are the hostvariables. I have not found any easy solution so here you must still manually exchange the hostvariables with the desired values. Using the new dynamic SQL tool CXU it is possible to execute a SQL statement directly from the source code and to define hostvariable values. By the way you can write SET SCHEMA = instead of SET CURRENT SCHEMA = and if you want to reset SCHEMA you must use SET SCHEMA = DEFAULT.