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

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-2019 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].