On 24 Jan 2013 07:32, Stone, Joel wrote:
Good suggestion. But with all the security and authority issues
these days - and prod running on different h/w that developers don't
even have access to - is there an easy way to ensure that the new
file has EXACTLY the same authority and security attributes as the
old one? Does CRTDUPOBJ supply all the necessary duplication?

The CRTDUPOBJ copies all authority but the ownership authority as I recall; i.e. *AUTL association, *PUBLIC, private, and group authority. Although for lack of the same group(s) for the new owning user profile, what were previously group authorities become private, IIRC.

With CPYF, I know for sure that the data is ending up where it came

So true. And there may be other reasons for keeping the identical member and\or file object besides just authority. If the database file is not an SQL TABLE, then an additional member of the physical file can serve as the repository for a temporary copy of data.

Regards, Chuck

Jon Paris on Wednesday, January 23, 2013 5:04 PM wrote:

On 23 Jan 2013 11:25, Stone, Joel wrote:
Can this be done in one SQL statement with the result placed
back in WORKFILE1?

Or should I create a new table QTEMP/WORKFILE2 using DISTINCT or
GROUP BY, and then CPYF back to WORKFILE1.

Another option being to create a new file delete the old one and
either move or rename the new one to the old name. Neither move or
rename would actually move the data so both should be more
efficient than copying the new on back again.

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page