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



Database *FILE object are composites. There are many related "objects" which make up the *FILE. Some of the composite pieces of the database *FILE are "shared". When a "duplicate" is made of a physical file [using CRTDUPOBJ, and by other means], the database may choose to "share" some sharable pieces. Most notably, the "record format" is identical for both files, so there is no requirement for the new file to have its own. DSPDBR TheLib/TheFile RCDFMT(*ALL) issued for either of the two files, the original and the duplicate, the "owner" [not user profile, but the owning-file] of the shared format will be listed first.

Neither CRTDUPOBJ nor Save\Restore will effect anything like a "reorganize" of the data. That would be a very worrisome\deprecated implementation :-Q In both cases, the data is copied identically; i.e. the "dataspace" object itself is "duplicated" to whichever media [including disk\DASD] is being used. Other data copy methods which choose which rows or order to copy, for example with CPYF invocations, the dataspace is unlikely copied; although some copy-all-data invocations of CPYF can take advantage of the feature to copy the dataspace versus specific rows of data.

Differences in sizes in save\restore are often related to indexes whereby rebuilds or again "sharing". Access Path sharing is "optimized" upon restore, so sharing which did not exist on save can be established at restore. Similarly sharing of formats that did not exist during save [but which were recorded merely historically] could be established during restore. There are diagnostic messages during restore which allude to possible growth\change effected.

Regards, Chuck

On 06-Jan-2012 10:27 , Charles Wilt wrote:
Basically, CRTDUPOBJ as far as I know...

Reorg wouldn't explain it, as mentioned, the files are empty.

On Fri, Jan 6, 2012 at 11:22 AM, Alan Shore<ashore@xxxxxxxx> wrote:

How was the second set of objects created?
Save & restore of individual libraries, or a save and restore of
individual objects, or some type of copy? The reason I ask this is
I seem to remember that copying a file does a form of re-org on
that file with respect to deleted records. I don't know if this is
true with save and restore though

Charles Wilt on Friday, January 06, 2012 10:56 AM
<<SNIP>>
I notice that some of the differences in sizes don't seem to have
any reason...

Example for one PF, which has 0 members and the same format on box
boxes:
System A, object size 20480
System B, object size 28672

<<SNIP>>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.