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