"moving TS to READ ONLY" - as in "START DB(name) SPACE(name) ACCESS(READ)"? First, you might just ask around. Failing that... Only a userid with the proper authority can do this. Or an application bound by someone with the authority. an sqlid (userid) who is SYSADM, or DBADM, maybe DBMAINT, or an sqlid who is the owner (creator) of the space, or userid in a RACF group where the RACF group has the authority. These are the ones you are looking for. So you might start off with investigating who has the authority. Check SYSIBM.SYSDBAUTH and also check SYSIBM.SYSUSERAUTH for who has these authorizations. Offhand, I do not know the way to find who issues START DB commands, but I am sure that this info is somewhere in your DB2 monitor. I would bet on it. After all, SMF records everything. And a monitor is merely reading the SMF records. So, go ask your DBA for a hand on identifying who is doing this. He can use the Db2 monitor (which ever one you have) to hunt down this information. It may (repeat may) require changing accounting classes (that is where the settings are for gathering information from a DB2 subsystem). Good luck ------------------------- Another thought - just in case this is not being caused by START DB(x) SPACE(y) ACCESS(READ) command... if you have done a LOAD of this tablespace and not done an IMAGE COPY, DB2 will not let you UPDATE any tables in this tablespace. Check this by issuing a DISPLAY DB command - look for COPYPEND (copy pending) flag to be set.

"moving TS to READ ONLY" - as in "START DB(name) SPACE(name) ACCESS(READ)"? First, you might just ask around. Failing that... Only a userid with the proper authority can do this. Or an application bound by someone with the authority. an sqlid (userid) who is SYSADM, or DBADM, maybe DBMAINT, or an sqlid who is the owner (creator) of the space, or userid in a RACF group where the RACF group has the authority. These are the ones you are looking for. So you might start off with investigating who has the authority. Check SYSIBM.SYSDBAUTH and also check SYSIBM.SYSUSERAUTH for who has these authorizations. Offhand, I do not know the way to find who issues START DB commands, but I am sure that this info is somewhere in your DB2 monitor. I would bet on it. After all, SMF records everything. And a monitor is merely reading the SMF records. So, go ask your DBA for a hand on identifying who is doing this. He can use the Db2 monitor (which ever one you have) to hunt down this information. It may (repeat may) require changing accounting classes (that is where the settings are for gathering information from a DB2 subsystem). Good luck ------------------------- Another thought - just in case this is not being caused by START DB(x) SPACE(y) ACCESS(READ) command... if you have done a LOAD of this tablespace and not done an IMAGE COPY, DB2 will not let you UPDATE any tables in this tablespace. Check this by issuing a DISPLAY DB command - look for COPYPEND (copy pending) flag to be set.