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

[CRPence <CRPbottle@xxxxxxxxx>]

  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)