Understanding resource allocation, a key to performance
The MSDB resource allocation scheme is different from that of DL/I.
For performance reasons, the understanding of resource allocation for MSDBs is important.
An MSDB record can be shared by multiple users or be owned exclusively by one user. The same record can have both statuses (shared and exclusive) at the same time.
Updates to MSDBs are applied during sync point processing. The resource is always owned in exclusive mode for the duration of sync point processing.
Enqueue level | When | Duration |
---|---|---|
READ | GH with no update intent | From call time until sync point (phase 1)¹ |
VERIFY/get calls | Call processing | |
HOLD | GH with update intent | From call time until sync point (phase 1)¹ |
At sync point, to reapply VERIFYs | Phase 1 of sync point processing, then released | |
UPDATE² | At sync point, to apply the results of CHANGE, REPL, DLET, or ISRT calls | Sync point processing, then released |
- If there was no FLD/VERIFY call against this resource or if this resource is not going to be updated, it is released. Otherwise, if only FLD/VERIFY logic has to be reapplied, the MSDB record is enqueued at the HOLD level. If the same record is involved in an update operation, it is enqueued at the UPDATE level as shown in the table above.
- At DLET/REPL call time, no enqueue activity takes place because it is the prior GH call that set up the enqueue level.
The following table shows that the status of an MSDB record depends on the enqueue level of each program involved. Therefore, it is possible for an MSDB record to be enqueued with the shared and exclusive statuses at the same time. For example, such a record can be shared between program A (GH call for update) and program B (GU call), but cannot be shared at the same time with a third program, C, which is entering sync point with update on the record.
Enqueue level in program B | Enqueue level in program A | ||
---|---|---|---|
READ | HOLD | UPDATE | |
READ | Shared | Shared | Exclusive |
HOLD | Shared | Exclusive | Exclusive |
UPDATE | Exclusive | Exclusive | Exclusive |
The FLD/CHANGE call does not participate in any allocation; therefore, FLD/CHANGE calls can be executed even though the same database record is being updated during sync point processing.
If FLD/CHANGE and FLD/VERIFY calls are mixed in the same FLD call, when the first FLD/VERIFY call is encountered, the level of enqueue is set to READ for the remainder of the FLD call.