Editing CICS (section)

==Structure==
[[Image:WOLA-Link-Server.jpg|thumb|left|Chart showing a particular task invocation of CICS, 2010]]

<!-- [[Tor (disambiguation)]] links to this section -->
In the [[z/OS]] environment, a CICS installation comprises one or more "[[memory management (operating systems)#Partitioned allocation|regions]]" (generally referred to as a "CICS Region"),<ref>{{Cite web
  | last = IBM
  | title = CICS Transaction Server glossary
  | work = CICS Transaction Server for z/OS V3.2
  | publisher = IBM Information Center, Boulder, Colorado
  | date = September 13, 2010
  | url = http://publib.boulder.ibm.com/infocenter/cicsts/v3r2/index.jsp
  | access-date = December 12, 2010
  | archive-url = https://web.archive.org/web/20130901150521/http://publib.boulder.ibm.com/infocenter/cicsts/v3r2/index.jsp
  | archive-date = September 1, 2013
  | url-status = dead
}}</ref> spread across one or more z/OS system images. Although it processes interactive transactions, each CICS region is usually started as a batch processing|batch address space with standard [[Job Control Language|JCL]] statements: it's a job that runs indefinitely until shutdown. Alternatively, each CICS region may be started as a [[daemon (computing)|started task]]. Whether a batch job or a started task, CICS regions may run for days, weeks, or even months before shutting down for maintenance (MVS or CICS). Upon restart a parameter determines if the start should be "Cold" (no recovery) or "Warm"/"Emergency" (using a warm shutdown or restarting from the log after a crash). Cold starts of large CICS regions with many resources can take a long time as all the definitions are re-processed.

Installations are divided into multiple address spaces for a wide variety of reasons, such as:

* application separation,
* function separation,
* avoiding the workload capacity limitations of a single region, or address space, or mainframe instance in the case of a z/OS SysPlex.

A typical installation consists of a number of distinct applications that make up a service. Each service usually has a number of "Terminal-Owning Region" (TORs) that route transactions to multiple "Application-Owning Regions" (AORs), though other topologies are possible. For example, the AORs might not perform File I/O. Instead there would be a "File-Owning Region" (FOR) that performed the File I/O on behalf of transactions in the AOR{{snd}} given that, at the time, a VSAM file could only support recoverable write access from one address space at a time.

But not all CICS applications use VSAM as the primary data source (or historically other single-address-space-at-a-time datastores such as CA Datacom) − many use either IMS/DB or Db2 as the database, and/or MQ as a queue manager. For all these cases, TORs can load-balance transactions to sets of AORs which then directly use the shared databases/queues. CICS supports XA two-phase commit between data stores and so transactions that spanned MQ, VSAM/RLS and Db2, for example, are possible with ACID properties.

CICS supports distributed transactions using SNA LU6.2 protocol between the address spaces which can be running on the same or different clusters. This allows ACID updates of multiple datastores by cooperating distributed applications. In practice there are issues with this if a system or communications failure occurs because the transaction disposition (backout or commit) may be in-doubt if one of the communicating nodes has not recovered. Thus the use of these facilities has never been very widespread.