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

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].