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



rob@xxxxxxxxx wrote:
When you execute CHGPF FILE(SCHEMA/TABLE) UNIT(*SSD)
does it just flip a bit in the definition of the table
and do the actual move in the background or are you
locked out of the table until all sectors are moved?


For parameters of CHGPF that apply [only] to the member(s) and data, the attribute change will be applied to all members & the dataspace of each member. In most cases the attribute change is applied also to the *FILE, to be inherited by members added by ADDPFM. One exception, maybe the only exception, is SHARE(). The enforcement or application of that changed attribute however, will generally be reflected only at run-time; MAINT() & ALLOCATE() are two exceptions.

IIRC the UNIT() parameter is applied to the *FILE, to each *MEM, and to each dataspace as an attribute, to be inherited for ADDPFM and active at run-time; deprecated for so long and so long ago, I do not remember well, but as a given... Thus for a member changed to have UNIT(*SSD), that attribute is merely stored in each member and applied to the dataspace of the member. Then for a future request to reorganize the member data [dedicated vs active\online] that new attribute will be in effect, placing all of the organized data where requested. For the new attribute to be in effect for adding data, the dataspace must be extended [an extent] versus only having added row(s) into already-allocated storage [extents of the dataspace]; i.e. when run-time LIC DB extends the dataspace, the new storage is on the requested unit. To make the attribute affect the existing member data, during the CHGPF request, the SRCFILE(named) must be included on the request; i.e. making the request an effective ALTER TABLE, or instead an explicit SQL ALTER TABLE, since the data will be moved into a new member.dataspace and that new dataspace will have all of the added\copied data placed where requested. Note that a restore of a database file.mbr is actually a create followed by a data-load operation, so the created file should have the member data placed accordingly.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.