On 10-Oct-2016 10:03 -0500, broehmer wrote:
We have data areas inside a library that is backed up using a SAVLIB
command. Just before the SAVLIB command runs, one of the DTAARAs in
that library is changed to indicate that backup is now running.
Other subsystem procedures check this DTAARA to see if the backup is
running and loop wait until available. Is the DTAARA available for
read only or does it get locked down while being backed up? I ask
this because I have suggested that the data area be moved away from
that specific library to one that isn't being saved so that there is
absolutely no contention.
That the Save Library (SAVLIB) allows for read-only access to the
Data Area (DTAARA) object can be shown empirically, by verifying the
SAVLIB request does *not* obtain an Exclusive (*EXCL) lock: In one job,
allocate a DTAARA with a shared read-only lock such as *SHRRD or
*SHRNUP, and then while that lock remains, in a different job, perform
the SAVLIB. Because the SAVLIB can complete for that object whilst the
other job holds the/any lock, known is that the SAVLIB request did not
require an exclusive lock. Because the SAVLIB does not require an
exclusive lock, that means, for any method that is truly using read-only
access of the data in a DTAARA [such as the Display Data Area
(DSPDTAARA) or Retrieve Data Area (RTVDTAARA) commands], the data in the
data area can be accessed without any conflict with the SAVLIB activity.
Note: Obviously, if the /read-only/ requester either explicitly or [by
the method invoked] implicitly effects the same as, ALCOBJ
((the_lib/the_DtaAra *DTAARA *EXCL)) to Allocate Object for exclusive
use [or some other conflicting lock as allocation] prior to the
read-require, then the requester is not making a truly read-only request.
[IBM i 7.3->Programming->Control language->CL programming->Communicating
between programs and procedures->Using data areas->Data area locking and
allocation]
(
http://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/rbam6/dalal.htm)
"Locking and allocating a data area helps to ensure that the data area
is not accessed by more than one job at a time.
The Change Data Area (CHGDTAARA) command uses a *SHRUPD (shared for
update) lock on the data area during command processing. The Retrieve
Data Area (RTVDTAARA) and Display Data Area (DSPDTAARA) commands use a
*SHRRD (shared for read) lock on the data area during command processing. …
…"
Or, found under an unlikely doc heading, to have learned that the
lock obtained by SAVLIB [or SAVOBJ, et al] for non-SWA [i.e. not Save
While Active] requests for the DTAARA object is, like for most objects,
a "Shared, No Update" (*SHRNUP) lock, for which the "object can be
shared with another job if the <ed: other> job requests either a
shared-no-update lock state, or a shared-for-read lock state."
[IBM i 7.3->Systems management->Backup and recovery->Backing up your
system->Save-while-active function->Considerations and restrictions for
the save-while-active function->Save-while-active object locking rules]
(
http://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/rzaiu/rzaiurzaiu319.htm)
"…
The following table shows the locks a normal save operation holds, …
Table 1. Lock type needed for save operation
Object Type SAVACT(*NO) …
… … …
Data area *SHRNUP …
…"
[IBM i 7.3->Programming->Control language->Objects and
libraries->Allocating resources->Lock states for objects]
(
http://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/rbam6/objlockstates.htm)
"A lock state identifies the use of the object and whether it is shared.
Objects are allocated on the basis of their intended use (read or
update) and whether they can be shared (used by more than one job). …
Table 1. Valid lock state combinations
If one job obtains Another job can obtain
this lock state: this lock state:
---------------------- ---------------------------------------
*EXCL None
*EXCLRD *SHRRD
*SHRUPD *SHRUPD or *SHRRD
*SHRNUP *SHRNUP or *SHRRD
*SHRRD *EXCLRD, *SHRUPD, *SHRNUP, or *SHRRD
…"
midrange.com
