Re: SSD: CHGPF time

rob@xxxxxxxxx wrote:

So what you are saying is that it doesn't move the data
right at the time you run CHGPF, nor does it fire off a
background task.

Correct [see Note:], the CHGPF SRCFILE(*NONE) UNIT(*SSD) [where all defaults are *SAME] would not move any data. That request just changes the attribute at the *FILE, *MEM, & *QDDS object levels. New members will have their dataspace created from segments on the *SSD, and existing members have their dataspaces acquire new segments on the *SSD.

Instead it waits until certain reorgs or alter tables are
executed against the file.

Not just reorganize or alter, but for whenever "new data segments" are added since the attribute change; i.e. the specified UNIT() attribute would then be used to designate from where the storage should be obtained, for those new data segments. For an ALTER or a CHGPF SRCFILE(named) UNIT(*SSD), the new\altered file is created with UNIT(*SSD), its member(s) added with UNIT(*SSD), its data segments created on\from the *SSD, and the data copied from the old file.member.dataspace with its data segments on whatever units.

How do you verify that it is REALLY on SSD now?

There is no "map dataspace segments" feature to show which SegmentIDentifier make up the dataspace, nor a "map SID" feature to show on which unit\drive it resides. The STRSST D/A/D using a [formatted] dump of the *QDDS object would show the segment table, and the segment header of each segment [somehow] identifies its location.

I'm wondering how to do this. I'd hate to have the first month
end or something come to a creeping crawl as the files are
reorged because the data is then being moved at the same time
(but again, maybe I need to get into a SSD frame of mind?).

Not sure what "to do this" would be. To move the existing data onto SSD? That would be the ALTER, RGZPFM ALWCANCEL(*NO), or restore of the changed file.

What about month end would move the data causing some implicit reorganize to move the data that any other I/O activity would not? Unless the dataspace is adding new segments from the designated unit, the UNIT() specification is not even in play; i.e. nothing is going to cause the existing data to move except something like an ALTER which creates a new file.member and thus its all-new dataspace segments from the specified UNIT, or a dedicated reorganize which copies the active row data from the existing dataspace into a new dataspace with the specified order.

Note: See Sue Baker's post and "DB2 and SSD integration" section of the following documents:
http://www-03.ibm.com/systems/resources/ssd_ibmi.pdf
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/5cb5ed706d254a8186256c71006d2e0a/0c819f965197f53c8625765f0004b3e5/$FILE/SSD4i.pdf
reference to TD105280 noted in above document can be searched at:
http://www.ibm.com/support/techdocs/atsmastr.nsf

Hmmm.... OK, so now that I see what Sue wrote and having found some references to PTF changes to the behavior, maybe your questions and what seems alluded by "reorged" is in regard to new functions of both synchronous and asynchronous movement of the existing data by the CHGPF. Sorry, I was not aware of those changes. Seems like without some specific control feature, there will be no ability to predict when or by when any asynchronous movement will be able to complete; I know nothing of its implementation. The synchronous data movement apparently is already available by PTF and will be performed while the CHGPF is active. However there is also note of asynchronous data movement to *SSD, done in some background [presumably LIC DB] tasks which I expect would not be predictable for its impact, for lack of any comment on any available control that can be applied to the background processing; i.e. any such background data movement could indeed impact some later activity [e.g. month-end processing] when that later processing is started before the background data movement completes. The impact would presumably be much like what would be for ASP balancing when the data segments of a database file are being moved.

Regards, Chuck