On 26 Apr 2012 12:09, David Gibbs wrote:
I'm working on a problem where we are having problems when using
CPYF to add records to a file.
I was reviewing the help text for the CPYF command noticed something
...
During the time a CPYF request is run, the file specified for
the To file (TOFILE) parameter may be locked (similar to an
*EXCL lock with no timeout) so that no access is possible.
This has me somewhat confused ... what do they mean "may be locked"
and "similar to an *EXCL lock"?
The dataspace may be "seized" by the LIC database to perform certain
operations. Seizes would normally only be held for very short periods
but database operations sometimes require long-held seizes. For a
scenario known to have the potential for a long-held seize, generally a
locking protocol is established above the LIC will that will prevent the
access to the dataspace because reference to a seized object will appear
as a "hang". This extra locking protocol has an effect which would
appear similar to a *EXCL lock on the file or member, but as alluded
there may be no timeout reflecting any established *WAIT* times defined
to a file.mbr [e.g. WAITFILE] or job [e.g. DFTWAIT]; though "no timeout"
would almost be pointless except to manifest the status of the thread as
LCKW vs RUN, whereby the latter more readily would be inferred to be an
apparent "hang" and the former someone might just infer all is OK even
though no conflicting lock information is available in WRKOBJLCK -- in
fact I recall WRKOBJLCK actually will fail too :-Q
I tried doing a CPYF to a file that was allocated with *SHRUPD,
but the copy worked fine. The only way I was able to get CPYF to have
a problem copying records was if allocated the object with *EXCL
myself.
I believe the caveat alluded may be for when the target member is
replaced and\or when COMPRESS(*NO) was specified; possibly exacerbated
by having a large SIZE() and ALLOCATE(*YES) and\or a large number of
access paths built over the data[space].
Database... -> Copying deleted records (COMPRESS parameter)
_Details of the COMPRESS(*NO) parameter and the Copy File command_
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/dm/rbal3details.htm
The alluded TOFILE locking I believe should be the same as that used
for both CLRPFM and RGZPFM; perhaps [if only some specific invocations
of] INZPFM.
There is a similar issue for the FROMFILE. But when any other locks
are held on the FROMFILE dataspace by another job\thread, the CPYF will
be unable to utilize "fast copy"; i.e. QDBFFCPY which also implements
CRTDUPOBJ. CRTDUPOBJ is /the same/ effect as the alluded caveat in the
CPYF help text. This is a much more common occurrence in my experience.
I am actually a little suspicious if the help text might refer to the
incorrect file; i.e. perhaps should state FromFile instead?
So the questions are ...
a) What determines if the target file is locked or not.
MBROPT(*REPLACE), and perhaps COMPRESS(*NO)
For the similar effect on the FROMFILE: From record must be *START or
1, all records must be copied, the dataspace must not be locked already
by another thread, the ERRLVL parameter must be zero [effectively *NONE
record errors allowed], the format option can not change, physical file
targets only [DDM representing PF], and from PF members only. I used to
think COMPRESS(*NO) was required also, but I think I later learned that
was not so.... but I do not recall if the compression option was being
ignored or if knowing the dataspace has no deleted records nullifies the
specification.
b) What kind of lock is put on the target file (if it's not exactly
a *EXCL lock).
A database *FILE lock will [effectively] always only be a *SHRRD
lock. The member\data may be locked *EXCL. A space location lock on
the *FILE or *MEM object is the implementation of a special locking
protocol to prevent jobs getting stuck on a seize-wait condition. I
seem to recall iNav has an option to present those types of locks (SLL)
in a job. Otherwise IBM service has a library that has some tooling
named DSPLCKSTS and\or DSPSYSLCK to assist.
Both clear of a target member and a fast-copy of a from\source member
would need to protect users from waiting on the long-held seize using
the special locking protocol.
c) Is there a way to reproduce the lock so I can diagnose the problem?
Fill a target member with a huge volume of rows before using the
replace option of the data. While the dataspace of the member is being
reset, the "lock" being held will prevent access to that member.
For a FROMFILE instead, see the parameter specifications noted
earlier, which allow that fast-copy code path.
The best way to test is not available outside the lab. That is to
use LIC debug to stop the processing in the LIC while the seize is held,
because by then the event masking and locking protocol was established
by the database. Having been established, and the work delayed at a
breakpoint, any conflicting requests would manifest the wait condition
on the locks... and tooling to show the locks need not be /lucky/ to
catch a window in which they were held.
I believe PEX trace feature can expose the locking activity, but not
much help to "see" the situation.
Regards, Chuck
midrange.com
