× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 04-Jun-2011 09:57 , Tom Hightower wrote:

Working on getting our new v6r1 system up and going.

One of our daily processes is to rename one of our production
libraries;

Ugh! IMO that process should be rethought. Anything "production" should almost never have that fate.

when I tried to do it, I received the following error:

Message ID . . . . . . : CPF2136
Date sent . . . . . . : 06/04/11 Time sent . . : 11:52:44
Message . . . . : Renaming library PRODFILES failed.
Cause . . . . . : Library PRODFILES cannot be renamed because it
contains one of the following object types.
-- CRG -- DTADCT -- JRN -- JRNRCV -- SQLPKG -- SQLUDT
Recovery . . . : Either try renaming another library or delete the
objects of the types listed above and try the request again.

I searched and found this object: MSACCESVBA *SQLPKG in the library.
Can I delete MSACCESVBA from this library, and will it be recreated
the next time one or our power user runs something that needs it?


By that naming, I believe the package can be deleted with little harm, but I can not be sure. A package that exists for Extended Dynamic generally can be deleted by DLTSQLPKG with little concern, such that the application that generates the package and adds statements will typically just do that again on the next connection. Packages created for other reasons may not be so forgiving to the application dependent on the missing SQL Package; e.g. from CRTSQLPKG to create the package on a remote RDB.

The "package location" information [DBXPLOC of QADBPKG, or LOCATION or PACKAGE_CATALOG of SYSPACKAGE] will indicate 'QSQPRCED' for those which are created by the Extended Dynamic API, and either the *LOCAL RDB name or a remote Relational Database name for the others.

As a "production" library, that library name will obviously exist again after the RNMOBJ of the *LIB, so preceding the delete of the *SQLPKG object, a SAVOBJ can be taken [best to include private authorities] to make a backup copy of the object, probably best into a *SAVF in the library to be renamed, from which a later RSTOBJ can be performed into the new version of that library name. The effect from that, for whomever or whatever access the *SQLPKG, would be about the equivalent of never having renamed the *LIB.

Regards, Chuck
kwds: RNMLIB

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.