Thanks everyone
Here is the command used to copy the objects in a library
(sql procedures and all other objects in the library that are not
source physical files or database physical or logical files)
other commands are used for these
DEL OBJLNK(&TOOBJ)
MONMSG MSGID(CPF0000)
CPY OBJ(&OBJ) TOOBJ(&TOOBJ) REPLACE(*YES) +
OWNER(*KEEP)
the obj/toobj parameters are retrieved from a dspobjd
if anyone knows of anything else I should be afraid of let me know.
seemed to work for a lifetime of traditional programming objects
Jim Horn
message: 1
date: Tue, 09 Sep 2008 12:01:37 -0500
from: CRPence <CRPbottle@xxxxxxxxx>
subject: Re: view sysprocs and library consolidation
MOVOBJ [AFaIK still] would not effect registration into the catalog
[nor removal of the old], but I believe CRTDUPOBJ will. I would expect
that the CPY would effect invocation of the QLICRDUP [i.e. CRTDUPOBJ]
for a request performed on a /QSYS.LIB object, so the outcome I would
expect to be the same.?
Although "SQL procedures" was noted, often External SQL procedures is
meant or included. For external procedures, if either the procedure was
created before the program or the program [attribute, e.g. CLP] does not
support the registration of the SQL information on the object itself
[i.e. registration is only into the catalog], then even the save\restore
of one of those objects would not assist to get the procedure registered
in the catalog. For external procedures in those cases, the CREATE
PROCEDURE EXTERNAL NAME must be performed again, and DROP SPECIFIC
PROCEDURE to rid of the old procedure.
Regards, Chuck
Elvis Budimlic wrote:
> CPY support does not (presently) update SQL catalogues, but SAV/RST
> does. I think the easiest avenue to pursue is to save restore those
> objects and you'll see that the catalogues have been updated
> appropriately.
>
> Jim Horn wrote:
>>
>> I was consolidating some libraries. another programmer had created
>> sql procedures in one of the libraries I was consolidating. when
>> I copied the procedure from 1 library to another, the view sysprocs
>> in qsys2 (and qsys2 in the isap) was not updated for the change. I
>> believe this is causing run issues.
>>
>> Is there a way to get sysprocs back in sync?
>>
>> any insights on this with other programming objects?
message: 1
date: Tue, 09 Sep 2008 12:01:37 -0500
from: CRPence <CRPbottle@xxxxxxxxx>
subject: Re: view sysprocs and library consolidation
MOVOBJ [AFaIK still] would not effect registration into the catalog
[nor removal of the old], but I believe CRTDUPOBJ will. I would expect
that the CPY would effect invocation of the QLICRDUP [i.e. CRTDUPOBJ]
for a request performed on a /QSYS.LIB object, so the outcome I would
expect to be the same.?
Although "SQL procedures" was noted, often External SQL procedures is
meant or included. For external procedures, if either the procedure was
created before the program or the program [attribute, e.g. CLP] does not
support the registration of the SQL information on the object itself
[i.e. registration is only into the catalog], then even the save\restore
of one of those objects would not assist to get the procedure registered
in the catalog. For external procedures in those cases, the CREATE
PROCEDURE EXTERNAL NAME must be performed again, and DROP SPECIFIC
PROCEDURE to rid of the old procedure.
Regards, Chuck
Elvis Budimlic wrote:
> CPY support does not (presently) update SQL catalogues, but SAV/RST
> does. I think the easiest avenue to pursue is to save restore those
> objects and you'll see that the catalogues have been updated
> appropriately.
>
> Jim Horn wrote:
>>
>> I was consolidating some libraries. another programmer had created
>> sql procedures in one of the libraries I was consolidating. when
>> I copied the procedure from 1 library to another, the view sysprocs
>> in qsys2 (and qsys2 in the isap) was not updated for the change. I
>> believe this is causing run issues.
>>
>> Is there a way to get sysprocs back in sync?
>>
>> any insights on this with other programming objects?
------------------------------
message: 7
date: Tue, 9 Sep 2008 12:31:36 -0500
from: "Elvis Budimlic" <ebudimlic@xxxxxxxxxxxxxxxxxxxxxxxxx>
subject: RE: view sysprocs and library consolidation
MOVOBJ is definitely the worst option, as catalogues are not updated,
meaning they're now reflecting incorrect information (external program
name
is incorrect). One 'might' still be OK (i.e. SP still functions), if the
system's cross reference includes resolved address to the object instead
of
looking up the external object by name, but I am not familiar with the
internal implementation of this particular processing.
I'm confident neither CRTDUPOBJ nor CPYLIB will effect the registration
either, so I doubt the QLICRDUP api will (but haven't ever used the API,
so
don't know for sure).
I know that SAV/RST will work, as long as the internal 'mark' count of 32
has not been exceeded for the object (talking *SRVPGM here). If mark has
been exceeded, only the max of 32 will be registered.
Here's a good article discussing this process:
http://www.mcpressonline.com/programming/sql/procedures-and-functions-and-ca
talogs-oh-my.html
HTH, Elvis
Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com
midrange.com
