IFS locks & programs hang during backup

[Mr. K.V.B.L.]

Presently we have our system running 24/7 for transaction processing.
These are financial transactions and system availability needs to be
100%. The sys admins have changed the backup so that in-use objects
are backed up as they are or are skipped (I don't know which).
Problem is our system makes use of the IFS too and these programs will
hang while the backup is running, which I estimate to be ~20-30
minutes. I'm guessing the routines that do I/O to the IFS are the
ones hanging up. Seems like they eventually give up and I get a
QPRINT job log that has something similar to the following:

Couldn't write to transaction log file (20111213_trans.log). Error is
'Resource busy'.

So, what can be done for this?

[CRPence]

On 14-Dec-2011 08:20 , Mr. K.V.B.L. wrote:
> Presently we have our system running 24/7 for transaction
> processing. These are financial transactions and system availability
> needs to be 100%. The sys admins have changed the backup so that
> in-use objects are backed up as they are or are skipped (I don't know
> which).

The difference can matter, with great significance. For skipping,
the more the amount of time that the save request is allowed to wait on
any one lock, impacts the amount of time existing locks are held for any
objects previously allocated for the save.

> Problem is our system makes use of the IFS too and these programs
> will hang while the backup is running, which I estimate to be ~20-30
> minutes. I'm guessing the routines that do I/O to the IFS are the
> ones hanging up. Seems like they eventually give up and I get a
> QPRINT job log that has something similar to the following:
>
> Couldn't write to transaction log file (20111213_trans.log). Error is
> 'Resource busy'.

Sounds like the error number 3029 aka errno3029 aka EBUSY, aka
message identifier CPE3029.

> So, what can be done for this?

Since the conflicts are not well defined, I can only guess... Perhaps
a poor design or implementation of the save strategy in combination with
an intent to allow concurrency, or instead an origin in poor coding of
that concurrent work for either or both waiting and error handling, or
possibly a defect.

For what it is worth, many types of "log files" will be tagged with
QP0L_ALWSAV_NO [CHGATR ATR(*ALWSAV) VALUE(*NO)] specifically in order to
prevent them from being saved and thus prevented from being allocated in
backup activity.

I did a quick search for EBUSY SAV [literally, a Google search on:
EBUSY DURING SAV] and found a v6r1 APAR SE49446 "OSP-MSGCPFA09E Object
in use after failed create" which mentions another likely related
possible outcome CPFA09E. However that APAR suggests the allocation
errors will persist until a pwrdwn\IPL is completed [though shockingly,
if so, the APAR is not (yet) marked HIPer].

Another link presented in the search results gave descriptive text
about a feature which exhibits a similar effect for conflict with a
save, and mentions how the save could have [, at least in non-OA
backups,] omitted the directory of the file to prevent impacting the
feature that opens\writes that file; text that may or may not be helpful
to read, beyond the aforementioned OMIT:
_KB item Reference #: 1153462_
http://www-01.ibm.com/support/docview.wss?uid=swg21153462

Regards, Chuck