CRTDUPOBJ vs CPYF

[Guest.Visitor]

Hi. Yesterday, I have pf with *PUBLIC *CHANGE but when I try to CRTDUPOBJ it give me the error message asking for the authority. So I use CPYF with CRTFILE *YES it work properly. After sometime I ask QSECOFR to grant *ALL autority to my user then I use the CRTDUPOBJ command on the file. Then I found out that all the Referential Integrity which was setting for the original file was follow to the target file (which is in another library). I beleive that this may be the cause of the error when try to CRTDUPOBJ with *CHANGE authority (on the first time). Am I right? Are there any other setting which will effect to the CRTDUPOBJ command (such as trigger etc.)

[Guest.Visitor]

CRTDUPOBJ copies authorities... and so you are supposed to have the necessary authorities to set the private authorities for the object. This is typically the authority problem when using CRTDUPOBJ. The function is also an object function vs a data function, so that can also be an issue. Although I do not believe authority is tracked to constraints so that should not be a direct issue -- indirectly maybe reference to other objects like another file in a reference or a trigger program if those are duplicated. Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.

[Guest.Visitor]

On Monday, January 11, 1999, 10:16 PM, Panida wrote: Hi. Yesterday, I have pf with *PUBLIC *CHANGE but when I try to CRTDUPOBJ it give me the error message asking for the authority. So I use CPYF with CRTFILE *YES it work properly. After sometime I ask QSECOFR to grant *ALL autority to my user then I use the CRTDUPOBJ command on the file. Then I found out that all the Referential Integrity which was setting for the original file was follow to the target file (which is in another library). I beleive that this may be the cause of the error when try to CRTDUPOBJ with *CHANGE authority (on the first time). Am I right? Are there any other setting which will effect to the CRTDUPOBJ command (such as trigger etc.) Panida: Can't help you with the referential integrity question, but I know that you need more authority to the original object in order to use CRTDUPOBJ on a file than to copy the same file. I have found this to be true from personal experience. In addition, when I was at COMMON a few years ago, the question was put to Wayne Evans in a session, and he agreed that it was true. He also agreed that it didn't make much sense for CRTDUPOBJ on a file and CPYF to be different. Go figure . . . Debbie Gallagher

[Guest.Visitor]

On Wednesday, January 13, 1999, 04:24 PM, Debbie Gallagher wrote: <> He Wayne Evans also agreed that it didn't make much sense for CRTDUPOBJ on a file and CPYF to be different. Go figure . . . The CPYF makes a similar copy of the object using the authority available to look at those attributes and the data. CRTDUPOBJ tries to bring a fuller set of attributes to make an attempt at a more identical copy to optionally include the data. The real difference is more obvious when the file is a logical file instead of a physical file. Note too, that RUNQRY *NONE ((lib/file member)) *OUTFILE is similar to CPYF but requires even less authorities -- effectively a data-only copy . Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.