Re: SSD: CHGPF time

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