- ACB
- See access control block.
- Access control block (ACB)
- The access control block
that resides in the address space of an access method, such as ACF/VTAM®.
- ACID properties
- The term, coined by
Haerder and Reuter [1983], and used by Jim Gray and Andreas Reuter
to denote the properties of a transaction: 12
- Atomicity
- A transaction’s changes to the state (of resources) are atomic:
either all happen or none happen.
- Consistency
- A transaction is a correct transformation of the state. The actions
taken as a group do not violate any of the integrity constraints associated
with the state.
- Isolation
- Even though transactions execute concurrently, they appear to be serialized.
In other words, it appears to each transaction that any other transaction
executed either before it, or after it.
- Durability
- After a transaction completes successfully (commits), its changes to
the state survive failures.
Note:
In CICS®, the ACID properties apply to a unit of work (UOW).
See also unit of work.
- BWO
- See backup-while-open.
- backup-while-open (BWO)
- A facility
that allows a backup copy of a VSAM data set to be made while the data set
remains open for update.
When you take a backup-while-open (BWO) copy of
a data set, only the updates that are made after the BWO need to be recovered
in the event of a disk failure. This considerably reduces the amount of forward
recovery that is needed.
- CICSplex
- (1) A CICS complex--a
set of interconnected CICS regions acting as resource managers, and combining
to provide a set of coherent services for a customer’s business needs.
In its simplest form, a CICSplex operates within a single MVS™ image. Within
a Parallel Sysplex® environment, a CICSplex can be configured
across all the MVS images in the sysplex.
The CICS regions in the CICSplex are generally
linked through the CICS interregion communication (IRC) facility, using either
the XM or IRC access method (between regions in the same MVS image), or the
XCF/MRO access method (between regions in different MVS images).
(2) The largest set of CICS regions or systems to be manipulated by a single CICSPlex® SM entity.
- CICSPlex System Manager (CICSPlex SM)
- An IBM® CICS system-management
product that provides a single-system image and a single point of control
for one or more CICSplexes.
- cloned CICS regions
- CICS regions that are identical in every respect,
except for their identifiers. This means that each clone has exactly the same
capability. For example, all clones of an application-owning region can process
the same transaction workload.
- dirty read
- A read request that does not involve any locking mechanism,
and which may obtain invalid data--that is, data that has been updated,
but is not yet committed, by another task. This could also apply to data that
is about to be updated, and which will be invalid by the time the reading
task has completed.
For example, if one CICS task rewrites an updated record, another CICS task that issues a read before the updating
task has taken a syncpoint will receive the uncommitted record. This data
could subsequently be backed out, if the updating task fails, and the read-only
task would not be aware that it had received invalid data.
See also read integrity.
- general log
- A general purpose log stream
used by CICS for any of the following:
- Forward recovery logs
- Autojournals
- User journals
Contrast with system log.
- heuristic decision
- A decision that enables a transaction manager
to complete a failed in-doubt unit of work (UOW) that cannot wait for resynchronization
after recovery from the failure.
Under the two-phase commit protocol, the
loss of the coordinator (or loss of connectivity) that occurs while a UOW
is in-doubt theoretically forces a participant in the UOW to wait forever
for resynchronization. While a subordinate waits in doubt, resources remain
locked and, in a CICS Transaction Server region, the failed UOW is shunted
pending resolution.
Applying a heuristic decision provides an arbitrary
solution for resolving a failed in-doubt UOW as an alternative to waiting
for the return of the coordinator. In CICS, the heuristic decision can be made in advance by specifying in-doubt attributes on the transaction
resource definition. These in-doubt attributes specify:
- Whether or not CICS is to wait for proper resolution or take heuristic
action (defined by WAIT(YES) or WAIT(NO) respectively)
- The heuristic action that CICS is to take for the WAIT(NO) case (or
is to take after the WAITTIME has expired, if a time other than zero is specified)
- Back out all changes made by the unit of work
- Commit all changes made by the unit of work
The heuristic decision can also be made by an operator when a
failure occurs, and communicated to CICS using an API or operator command interface
(such as CEMT SET UOW).
- in-doubt
- In CICS, the state at a particular point in a
distributed UOW for which a two-phase commit syncpoint is in progress. The
distributed UOW is said to be in-doubt when:
- A subordinate recovery manager (or transaction manager) has replied (voted)
in response to a PREPARE request, and
- Has written a log record of its response to signify that it has entered
the in-doubt state, and
- Does not yet know the decision of its coordinator (to commit or to back
out).
The UOW remains in-doubt until the coordinator issues either the
commit or backout request as a result of responses received from all UOW participants.
If the UOW is in the in-doubt state, and a failure occurs that causes loss
of connectivity between a subordinate and its coordinator, it remains in-doubt
until either:
- Recovery from the failure has taken place and synchronization can resume,
or
- The in-doubt waiting period is terminated by some built-in controls, and
an arbitrary (heuristic) decision is then taken (to commit or back out).
Note:
In theory, a UOW can remain in-doubt forever if
a UOW participant fails or loses connectivity with a coordinator, and is never
recovered (for example, if a system fails and is not restarted). In practice,
the in-doubt period is limited by attributes defined in the transaction resource
definition associated with the UOW. After expiry of the specified in-doubt
wait period, the recovery manager commits or backs out the UOW, based on the
UOW’s in-doubt attributes.
For cases where data integrity is of paramount
importance, CICS supports "wait forever", indicated by a WAITTIME of zero, in
which case manual intervention is required to force a heuristic decision.
See also two-phase commit and heuristic decision.
- log manager
- A new domain in CICS Transaction Server for OS/390®, Version 1 Release 1, which
replaces the CICS journal control management function of current CICS releases. The CICS log manager uses MVS system logger services to write CICS system logs,
forward recovery logs, and user journals to log streams managed by the MVS system
logger.
- logical unit of work (LUW)
- Old term used to describe
a unit of work in earlier releases of CICS. The preferred term, adopted in CICS Transaction Server for OS/390, Version 1 Release 1,
is unit of work (UOW). UOW is used as a keyword in a number of CICS interfaces
in CICS TS. UOW also replaces LUW on two existing API commands (EXEC CICS ENQUEUE and EXEC CICS DEQUEUE), but the translator treats LUW as a synonym
for UOW and correctly translates the command.
See unit
of work.
- LUW
- See logical unit of work.
- LUWID
- Logical unit of work identifier. See UOW id.
- orphan lock
- An orphan lock is an RLS lock that is held by VSAM RLS but
is unknown to any CICS region.
An RLS lock becomes an orphan lock if it
is acquired from VSAM by a CICS region that fails before it can log it.
A VSAM interface enables CICS, during an emergency restart, to detect the existence
of these locks and release them.
- Parallel Sysplex
- An MVS sysplex where all the MVS images are linked
through a coupling facility.
- read integrity
- An attribute of a read request,
which ensures the integrity of the data passed to a program that issues a
read-only request. CICS recognizes two forms of read integrity:
- 1. Consistent
- A program is permitted to read only committed data--data that cannot
be backed out after it has been passed to the program issuing the read request.
Therefore, a consistent read request can succeed only when the data is free
from all locks.
- 2. Repeatable
- A program is permitted to issue multiple read-only requests, with repeatable
read integrity, and be assured that none of the records passed can subsequently
be changed until the end of the sequence of repeatable read requests. The
sequence of repeatable read requests ends either when the transaction terminates,
or when it takes a syncpoint, whichever is the earlier.
Contrast with dirty read.
- recovery manager
- A domain in CICS Transaction
Server, the function of which is to ensure the integrity and consistency of
recoverable resources. These recoverable resources, such as files and databases,
can be within a single CICS region or distributed over interconnected systems.
The recovery manager provides CICS unit of work (UOW) management in a distributed
environment.
- shunted
- The status of a UOW that has failed at
one of the following points:
- While in-doubt during a two-phase commit process
- While attempting to commit changes to resources at the end of the UOW
- While attempting to back out the UOW
If a UOW fails for one of these reasons, it becomes a candidate to
be moved from the primary system log (DFHLOG) to the secondary system log
(DFHSHUNT) at the next activity keypoint, pending recovery from the failure.
- SMSVSAM
- The name of the VSAM server that provides VSAM record-level sharing
(RLS). See also VSAM RLS.
- sphere
- See VSAM sphere.
- system log
- A log stream maintained by CICS for back-out
recovery purposes.
The system log is used by CICS to recover data to a consistent state
following:
- The failure of an individual transaction
- The failure of a CICS region
- The failure of a connection with a partner in a distributed unit of work
User transactions are allowed to write their own recovery records
to the system log for use in an emergency restart, but the system log cannot
be used for forward recovery log or autojournal records.
Contrast with general log.
- system logger
- A central logging facility provided by OS/390 (and also MVS/ESA SP 5.2). The MVS system logger provides an integrated MVS logging
facility that can be used by system and subsystem components. For example,
it is used by the CICS log manager.
- two-phase commit
- In CICS, the protocol observed when taking a
syncpoint in a distributed UOW. At syncpoint, all updates to recoverable resources
must be either committed or backed out. At this point, the coordinating recovery
manager gives each subordinate participating in the UOW an opportunity to
vote on whether its part of the UOW is in a consistent state and can be committed.
If all participants vote "yes", the distributed UOW is committed. If
any vote "no", all changes to the distributed UOW’s resources are
backed out.
This is called the two-phase commit protocol, because there is first a "voting" phase (the prepare phase), which is followed by the actual commit phase. This can be summarized as follows:
- 1. Prepare
- Coordinator invokes each UOW participant, asking each one if it is prepared
to commit.
- 2. Commit
- If all UOW participants acknowledge that they are prepared to commit
(vote yes), the coordinator issues the commit request.
If only one UOW
participant is not prepared to commit (votes no), the coordinator issues a
back-out request to all.
- unit of work (UOW)
- A sequence of processing
actions (database changes, for example) that must be completed before any
of the individual actions performed by a transaction can be regarded as committed.
After changes are committed (by successful completion of the UOW and recording
of the syncpoint on the system log), they become durable, and are not backed
out in the event of a subsequent failure of the task or system.
The beginning
and end of the sequence may be marked by:
- Start and end of transaction, when there are no intervening syncpoints
- Start of task and a syncpoint
- A syncpoint and end of task
- Two syncpoints
Thus a UOW is completed when a transaction takes a syncpoint,
which occurs either when a transaction issues an explicit syncpoint request,
or when CICS takes an implicit syncpoint at the end of the transaction. In the
absence of user syncpoints explicitly taken within the transaction, the entire
transaction is one UOW.
In earlier releases of CICS, this was referred
to as a logical unit of work (LUW).
- unshunting
- The process of attaching a transaction
to provide an environment under which to resume the processing of a shunted unit of work.
- UOW
- See unit-of-work.
- UOW id
- Unit-of-work identifier.
CICS uses two unit of work identifiers for
two purposes, one short and one long:
- Short UOW id
- An 8-byte value that CICS passes to resource managers, such as DB2® and
VSAM, for lock management purposes.
- Long UOW id
- A 27-byte value that CICS uses to identify a distributed UOW. This
is built from a short UOW id prefixed by two 1-byte length fields and by the
fully-qualified NETNAME of the CICS region.
- VSAM RLS
- VSAM record-level sharing,
an access mode supported by DFSMS to allow multiple applications to share
data sets, with data locking at the record level. Access to data sets is through
an SMSVSAM server. See also SMSVSAM.
- VSAM sphere
- The collection of all the component data sets associated
with a given VSAM base data set--the base, index, alternate indexes,
and alternate index paths.
- 2-phase commit
- See two-phase commit.