Regions, topology and resource definitions
Large CICS systems are not one region but many, each with a job: some own terminals and connections, some run applications, some own files. They talk to each other, are managed as a group with CICSPlex SM, and every resource they use is defined in the CSD.
Why one region is never enough
In the basics course a CICS region was one address space running many transactions. Real production systems run dozens or hundreds of regions. Splitting work across regions gives availability (lose one region and the others keep serving), capacity (spread work across several z/OS images in a sysplex), and isolation (a looping application in one region cannot starve the others).
The classic roles
| Role | Owns | Typical job |
|---|---|---|
| TOR (terminal-owning region) | Terminals, network entry points | Receives the request and routes it to an AOR |
| AOR (application-owning region) | Application programs | Runs the business logic; usually cloned several times |
| FOR (file-owning region) | VSAM files | Gives many AORs a single point of access to the same files |
| Others | Queues, web listeners, Liberty | Some sites add queue-owning or web-facing regions |
Names vary by site, and modern designs blur the lines. Many shops now use routing regions for web and API traffic, and with VSAM RLS the AORs can open shared files directly, so dedicated FORs are less common than they used to be. The ideas still appear in every architecture diagram and interview.
How regions talk to each other
- Transaction routing: a TOR passes a whole transaction to an AOR to run.
- Function shipping: a program asks for a file or queue that lives in another region, and CICS ships the request there transparently.
- Distributed program link (DPL): a program issues
EXEC CICS LINKto a program defined as remote, and it runs in another region. - Connections: regions in the same z/OS image or sysplex use multiregion operation (MRO); links to other systems use intersystem communication over IPIC (TCP/IP) or older SNA (LU6.2) connections.
Managing many regions: CICSPlex SM
Defining and operating a hundred regions one at a time does not scale. CICSPlex SM lets you manage a group of regions (a CICSplex) as a single system. Its main pieces are a central management address space (the CMAS), a web user interface (WUI), and an agent in each managed region. It offers a single view of all regions, workload management that routes each transaction to the healthiest AOR, central resource definition (Business Application Services), and real-time analysis that raises alerts. Many teams use CICS Explorer, an Eclipse-based client, on top of it.
Resource definitions and the CSD
Every program, transaction, file, connection, URIMAP and transaction class a region uses must be defined. These definitions are usually held in the CSD (CICS system definition file), a VSAM KSDS. Definitions are grouped into groups (for example one per application), and groups are collected into lists. At an initial or cold start, the region installs the groups in the lists named by its GRPLIST system initialisation parameter. Several regions often share one CSD.
| Tool | Used for |
|---|---|
| CEDA transaction | Online define, alter, view and install of definitions |
| DFHCSDUP batch utility | Scripted, repeatable changes; what pipelines and change records normally use |
| CICSPlex SM BAS / CICS Explorer | Central definitions across many regions |
| CICS bundles | Deploy a set of resources together, often from a build pipeline |
//CSDUP EXEC PGM=DFHCSDUP //STEPLIB DD DSN=CICSTS.SDFHLOAD,DISP=SHR //DFHCSD DD DSN=CICS.PROD.DFHCSD,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE PROGRAM(PAYINQ1) GROUP(PAYAPP) LANGUAGE(COBOL) DEFINE TRANSACTION(PAY1) GROUP(PAYAPP) PROGRAM(PAYINQ1) ADD GROUP(PAYAPP) LIST(PRODLIST) /*
Defining a resource in the CSD does not make it active. It must also be installed in the running region, for example with CEDA INSTALL GROUP(PAYAPP) or by a later cold start. Library names, high-level qualifiers and change procedures depend on site configuration.
Which batch utility updates the CSD from a job?
Show a hint
Its name starts with DFH and ends with UP.
Show the solution
DFHCSDUP is the batch utility for defining, altering, listing and copying CSD definitions.
Common mistakes
A new definition in the CSD is not in the running region until it is installed. Check with CEMT INQUIRE before telling anyone the change is live.
Ad hoc CEDA changes are hard to audit, easily drift between regions and environments, and may be missing from the group list used at the next cold start. Use DFHCSDUP jobs or bundles under change control.
A 'file not found' in an AOR may really be a missing remote definition or a broken connection to the FOR. Draw the topology before troubleshooting.
What you will see at work
- Architecture diagrams show TORs, AOR clones and connections; you will be expected to read them on day one.
- Application changes usually ship as DFHCSDUP input or CICS bundles alongside the load modules.
- Operations and systems programmers use CICSPlex SM or CICS Explorer to see the state of every region at once.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.