× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 06-Jan-2012 13:22 , Jeff Crosby wrote:

Interesting. Sometimes when I do a CRTDUPOBJ of a production file
into a test library for testing purposes, I will get an error that
the data could not be copied. The new object has been created,
however. When this happens, I follow with a CPYF to bring the actual
data across.

Would what you said about a *FILE object actually being multiple
"objects" be the reason for this behavior?


Yes. That the database file is more than just the external *FILE object, defines how the "duplication" occurs. For some reason I can not recall what would be a typical origin for "the data could not be copied" in the described scenario. Is there a specific example of which you are aware, the underlying diagnostic condition being diagnosed, to assist my memory?

The database *FILE is a "complex" object type; the external object type *FILE, and a number of other internal [or less visible] object types. There are "simple" object types which are just one object of the one external object type. Those objects which are "simple" can be operated against generically; i.e. the "generic" methods\operations like duplicate, rename, delete, move, grant, revoke, change owner, and ¿others?. However for complex object types, the Librarian component passes the work to the "object type owner", the "object handler" to perform the object-specific work to implement the "generic" action.

For CRTDUPOBJ [CPP of QLICRDUP "Q"=OS, "LI"=Librarian component, "CR"=create, "DUP"=duplicate] the librarian can implement all of the work necessary to duplicate the simple object types, but for the database file object the request is performed by the QDBDUPFI ["Q"=OS, "DB"=Database component, "DUP"=Duplicate, "FI"=File; dbf implied by component].

Because the DBF [DataBase File] object is made up of the *FILE and then various other objects, the duplication starts by duplicating the *FILE object to the new library or name. Then object level "file level" associations like triggers and constraints are duplicated; some parameters may preclude. Then each of the *MEM [database Member] objects is duplicated. And when the DATA(*YES) has been specified, then the *QDDS [dataspace] object associated with the corresponding member is [effectively; implemented as a "copy" method] duplicated.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.