×
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.
On 28 Feb 2013 07:54, Robert Rogerson wrote:
Yesterday we attempted to migrate a large file (37 Gig) to the SSD
using CHGPF. When I check the file (DSPFD) it confirms that
UNIT(*SSD) is now changed. This morning when I ran a query on
syspartitiondisk it told my that 8% (33 Gig on HDD and 4 Gig on SDD)
had been migrated. I was expecting this percentage to be higher if
not at 100%.
Am I misunderstanding? If I specify the UNIT on a file to be SSD
does that not mean that the entire file will be migrated to the SSD?
According to a link posted by Rob Berendt, an answer is to use the
CHGPFM in addition to the CHGPF [while instead of the CHGPF is likely
valid too, that has other implications], "to *synchronously* move the data":
http://www.ibm.com/developerworks/ibmi/library/i-db2ssd/index.html
"... additions to the CHGPFM and CHGLFM commands that were also made
available with the following PTFs: IBM i 6.1 (SF99601 Version 19) and
IBM i 7.1 (SF99701 Version 6). There are no plans to support these
enhancements on V5R4.
...
_CHGPFM and CHGLFM concurrency_
As mentioned earlier, all previous mechanisms of changing the media
preference required an exclusive lock on the entire file. This prevented
changing the media preference if any application was currently accessing
the file or any member of the file. Conversely, if an exclusive lock was
able to be acquired, concurrent applications would not be able to access
the file and could fail with a lock time-out.
CHGLFM and CHGPFM do not require an exclusive lock like the previous
methods. A *SHRUPD lock is required, but this only conflicts with
another job that has an *SHRNUP, *EXCLRD, or *EXCL lock on the file. At
this time, an exclusive seize is acquired by the DB2 engine to
synchronously move the data, so while a lock time-out will not occur,
other jobs will wait for the move to complete. At some point we may
change the commands to asynchronously move the data which would not
cause other jobs to wait for the move to complete.
..."
The other link given by Rob does not provide the same explanation,
but its origin is from the support\service group; the prior article
comes from the development group. That and because the other link does
not even properly name the commands in its "Moving Files at the Member
level" gives me confidence that the above snippet I quoted from the
first link provided by Rob [from DeveloperWorks] is a better guide.
midrange.com
