Re: Best practice to duplicate a library with SQL stored procedures

Some external stored procedures may still be missing from the new SCHEMA even when using save\restore; e.g. those for which the referenced external object is in a different library and those for which the SQL attributes could not be assigned [such as to a CLP]. And if so, those external procedures will still need to be generated either from some script(s) or program(s), or from the procedure and parameter catalog information for the saved library, or from the retrieved SQL [if supported; I see no reason why they would not be supported, but I never tried that] against those external procedure definitions.

FWiW I would use OMITOBJ() on the SAVLIB to omit those objects and types that will not restore [either as restrictions or as duplicate]. The OMITOBJ() could be used on RSTLIB instead, but knowing that just makes its usage on the SAVLIB all that much more obviously better. Also the referenced document [in snipped quoted text] fails to suggest that with OPTION(*NEW) the MBROPT(*ALL) is required [to effect the desired restore, even to allow the request without an error about a conflict with the two parameters due to MBROPT(*MATCH) as default].

Regards, Chuck

On 3/30/11 12:12 PM, Mike Cunningham wrote:

Looks like backup/restore is the best option but need to use SQL to
create the library (schema) and not let the restore do it.
Procedures for put back OK but journaling was not. Creating the
schema setup default journaling and the restore then attached tables
to the journal in the restore library.

Create save file
SAVLIB of source lib
iNav or STRSQL to create the schema (library)
RSTLIB to target lib
Delete save file

Others wrote [about using RSTLIB]:

<<SNIP other replies>>

Wednesday, 30. March 2011 04:09 Im Auftrag von Mike Cunningham:

We have a library with only database objects which include not
only SQL tables and view but also SQL stored procedures and some
external stored procedures. A CRTDUPOBJ *ALL from this library to
another looks like it correctly duplicated all objects, include
the stored procedures, but the procedures do not appear on the
Navigator list of procedures because they are not in the SQL
catalog. Is there a better way to duplicate this type of library
or is the only option to keep a script to DROP and CREATE all the
procedures in the library after the CRTDUPOBJ command? We are on
V5R4 (but hopefully only for another 4 months)