×
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
midrange.com
