Check to see who is creating ODBC data sources from Windows to the iSeries for one thing. There is a tab named 'Packages' on the setup of an ODBC data source that asks what library you want to place package files in. Of course, unless you are using dynamic package support, you can uncheck this tab setting and bypass creating them. ====================================================== Under circumstances of "various libraries" and "by many different users", ODBC and similar access is probably the source. But are you sure that any particular package ought to be deleted? Have you determined if the packages are used? Most SQL packages are relatively small objects. Unless it's a very small system with a very large number of packages, it wouldn't seem likely that you'd recover much by deleting them. And if it is a small system that is creating many packages, it would seem that the potential performance advantages of packages is needed. See <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/ddp/rbal1sqlpack.htm">this comment</a> and consider effects on the remaining objects that might still be "dependent on the SQL package". Also, see some info on where packages come from <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzaik/rzaikexecuteprepstmt.htm">here</a> and <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzaik/useedsql.htm">here</a> for some fundamentals. Do you prefer having the ODBC requests optimized for reuse or recreated and optimized when each request is repeated? It can be a balancing act. Is the time spent tracking them down and deleting them worth it? Object creation and object deletion can be expensive operations by themselves. Tom

Check to see who is creating ODBC data sources from Windows to the iSeries for one thing. There is a tab named 'Packages' on the setup of an ODBC data source that asks what library you want to place package files in. Of course, unless you are using dynamic package support, you can uncheck this tab setting and bypass creating them. ====================================================== Under circumstances of "various libraries" and "by many different users", ODBC and similar access is probably the source. But are you sure that any particular package ought to be deleted? Have you determined if the packages are used? Most SQL packages are relatively small objects. Unless it's a very small system with a very large number of packages, it wouldn't seem likely that you'd recover much by deleting them. And if it is a small system that is creating many packages, it would seem that the potential performance advantages of packages is needed. See <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/ddp/rbal1sqlpack.htm">this comment</a> and consider effects on the remaining objects that might still be "dependent on the SQL package". Also, see some info on where packages come from <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzaik/rzaikexecuteprepstmt.htm">here</a> and <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzaik/useedsql.htm">here</a> for some fundamentals. Do you prefer having the ODBC requests optimized for reuse or recreated and optimized when each request is repeated? It can be a balancing act. Is the time spent tracking them down and deleting them worth it? Object creation and object deletion can be expensive operations by themselves. Tom