IBM Developer article explaining the QR TCB, open TCB model, and task dispatching in detail. Includes diagrams of the task state machine (running, ready, waiting) and the dispatcher's selection algorithm. → Chapter 17 Further Reading
"CICS Performance Analysis Using SMF 110 Records"
SHARE conference presentation covering SMF 110 record extraction, field interpretation, and common performance analysis patterns. Includes sample SAS and REXX code for processing SMF 110 data. → Chapter 17 Further Reading
"CICS Recovery: Myths and Reality"
SHARE Conference presentation. Addresses common misconceptions about CICS recovery, including the myth that cold start is safe, the myth that LOGDEFER has no risk, and the myth that indoubt transactions resolve themselves. → Chapter 18 Further Reading
"CICS Region Design Patterns"
IBM Systems Magazine archives. A series of articles by CICS architects covering common topology patterns, anti-patterns, and migration strategies. The article on "Evolving from Monolithic to Multi-Region CICS" is particularly relevant. → Chapter 13 Further Reading
"CREATE FUNCTION (external table)"
Covers the complete syntax for scalar and table UDFs, including SCRATCHPAD, FINAL CALL, and DISALLOW PARALLEL options. - IBM Documentation: DB2 13 for z/OS > SQL Reference > CREATE FUNCTION → Chapter 10: Further Reading
"CREATE PROCEDURE (external)"
The definitive reference for all CREATE PROCEDURE options. Pay particular attention to the interaction between PARAMETER STYLE, LANGUAGE, and WLM ENVIRONMENT clauses. - IBM Documentation: DB2 13 for z/OS > SQL Reference > CREATE PROCEDURE (external) → Chapter 10: Further Reading
"DB2 for z/OS RUNSTATS: Best Practices"
IBM Support technical note. Covers statistics profile design, frequency statistics selection criteria, and column group recommendations. Updated periodically as new DB2 function levels add RUNSTATS capabilities. → Chapter 6 Further Reading: DB2 Optimizer Internals
"DFSORT Performance Tips"
IBM Support article with specific recommendations for SORTWK placement, MAINSIZE/HIPRMAX settings, and parallel I/O configuration. Includes benchmark results comparing serial vs. parallel sort configurations. → Chapter 25 Further Reading
"How the DB2 Optimizer Estimates Filter Factors"
IBM developerWorks technical article by Terry Purcell. Provides the exact formulas DB2 uses for filter factor calculation, including edge cases for LIKE, IS NULL, and BETWEEN with host variables. The most precise public documentation of DB2's filter factor arithmetic. → Chapter 6 Further Reading: DB2 Optimizer Internals
"IPIC vs. SNA: Choosing the Right ISC Protocol"
IBM CICS Blog. Comparison of IPIC and SNA/APPC for inter-system communication, including performance benchmarks, security features, and migration guidance for SNA-to-IPIC conversion. → Chapter 13 Further Reading
"ISO 20022 Implementation on CICS"
IBM Systems Magazine archives. Case study of a European bank implementing ISO 20022 payment messaging on CICS with SOAP web services. Directly relevant to Case Study 2. → Chapter 14 Further Reading
"JSON Transformation Performance in CICS TS 5.6"
IBM Developer. Benchmark data for DFHJSON transformation at various payload sizes. Includes tuning recommendations for high-volume JSON services. → Chapter 14 Further Reading
"Managing WLM application environments"
The z/OS WLM documentation covering VARY WLM commands, application environment lifecycle, and monitoring. - IBM Documentation: z/OS MVS Planning: Workload Management → Chapter 10: Further Reading
"Migrating from SOAP to REST in CICS"
IBM CICS Blog. Practical guide to running SOAP and REST services side-by-side during migration. Covers the dual-protocol pipeline pattern where both JSON and XML are supported for the same COBOL program. → Chapter 14 Further Reading
"Monitoring stored procedures"
Covers IFCID 0170 (stored procedure detail), SMF 101 subtype 3 (stored procedure statistics), and DSN_STATEMNT_TABLE analysis. - IBM Documentation: DB2 13 for z/OS > Performance Monitoring and Tuning → Chapter 10: Further Reading
"Multi-Row FETCH and INSERT in DB2 for z/OS"
IBM developerWorks (archived). This technical article walks through the complete conversion process from single-row to multi-row operations with COBOL examples, including the indicator array patterns and SQLERRD handling that production programs require. → Chapter 7 Further Reading
"NOEMPTY. Always."
One wrong parameter can delete 30 days of data. 3. **"The right block size is free performance."** — No code changes, just JCL and data classes. 4. **"SHAREOPTIONS 3 is the Wild West."** — Use SHAREOPTIONS 2 or VSAM RLS for integrity. 5. **"Pre-recall, don't auto-recall."** — Proactive HSM recall be → Chapter 4 Key Takeaways — Quick Reference Card
"Parallel Sysplex Batch Processing Patterns"
IBM Systems Magazine article series covering real-world parallel batch implementations at banking, insurance, and government sites. Includes measured performance results and lessons learned from production deployments. → Chapter 25 Further Reading
"Resource Limit Facility (RLF)"
Setting CPU time limits for dynamic SQL, including special considerations for queries that invoke UDFs. - IBM Documentation: DB2 13 for z/OS > Managing Performance > Resource Limit Facility → Chapter 10: Further Reading
"Securing CICS Web Services with OAuth 2.0"
IBM Developer. Integration pattern for OAuth2 token validation in CICS web service pipelines. Covers both API gateway-mediated validation (recommended) and direct CICS validation via Liberty. → Chapter 14 Further Reading
"SMF Type 30: A Deep Dive"
Search IBM Z Content Solutions for detailed technical articles on parsing and analyzing SMF type 30 records. The self-defining section parsing technique shown in this chapter is covered in greater detail. - **"Batch Window Optimization Using SMF Data"** — IBM Systems Magazine periodically publishes → Further Reading — Chapter 27
"The Art of MAXT Diagnosis"
IBM Support technical document describing the common causes of MAXT conditions, the diagnostic methodology, and the resolution patterns. Includes a decision tree for MAXT triage. → Chapter 17 Further Reading
"The Cost of a Stored Procedure Call"
An IBM performance engineer's analysis of the CPU and elapsed time components of a stored procedure call: WLM scheduling, Language Environment initialization, SQL execution, and result marshaling. Essential reading for Section 10.5. → Chapter 10: Further Reading
"TRANCLASS Best Practices for Production CICS"
IBM CICS blog post covering TRANCLASS design patterns for financial services environments. Includes sample TRANCLASS configurations for ATM, web, and batch-initiated workloads. → Chapter 17 Further Reading
"Understanding CICS Storage Domains"
IBM Systems Magazine article providing a visual guide to DSA, EDSA, and GCDSA sub-pools, with practical sizing guidance and SOS prevention strategies. → Chapter 17 Further Reading
"Understanding CICS Two-Phase Commit"
IBM CICS Blog. A practical walkthrough of the 2PC protocol in CICS with sequence diagrams and failure scenario analysis. Covers the indoubt window, commit point, and resolution mechanisms. → Chapter 18 Further Reading
"Understanding DB2 Access Paths"
IDUG (International DB2 Users Group) presentation series. IDUG's annual conferences include sessions from IBM optimizer developers explaining recent changes. The proceedings are available to IDUG members and contain information not available in standard documentation. → Chapter 6 Further Reading: DB2 Optimizer Internals
"Understanding DB2 Query Parallelism"
IBM Developer article explaining the internals of I/O, CP, and Sysplex parallelism, including how DB2 decides the degree of parallelism, what resources constrain it, and how to interpret accounting trace data. → Chapter 25 Further Reading
"Understanding MSU and Software Pricing on IBM Z"
IBM Z Content Solutions publishes periodic articles explaining MSU calculation, SCRT mechanics, and TFP pricing models. Essential reading for anyone involved in mainframe cost management. - **"zIIP Offload Opportunities for COBOL Workloads"** — Search IBM Z and mainframe community sites for articles → Further Reading — Chapter 29
"WLM Tuning for Stored Procedures: Beyond NUMTCB"
Covers advanced WLM configuration including service class goals, importance levels, and the interaction between stored procedure address spaces and DB2 buffer pools. → Chapter 10: Further Reading
"Workload Management for CICS: A Practical Guide"
IBM Developer Works. Covers the interaction between z/OS WLM service classes and CICSPlex SM routing algorithms. Includes worked examples of goal-based routing configuration. → Chapter 13 Further Reading
"Writing external stored procedures"
The programming guide section covering COBOL, PL/I, and C stored procedure implementation patterns, including result set handling and error processing. - IBM Documentation: DB2 13 for z/OS > Application Programming and SQL Guide > Writing stored procedures → Chapter 10: Further Reading
"Writing user-defined functions"
Covers the PARAMETER STYLE SQL contract, scratchpad usage for table functions, and the OPEN/FETCH/CLOSE call-type protocol. - IBM Documentation: DB2 13 for z/OS > Application Programming and SQL Guide > Writing user-defined functions → Chapter 10: Further Reading
0 min
**Job B:** Longest path through B is Path 4 (135 min). Slack = 160 - 135 = **25 min** - **Job C:** On critical path → slack = **0 min** - **Job D:** Longest path through D is Path 4 (135 min). Slack = 160 - 135 = **25 min** - **Job E:** On critical path → slack = **0 min** - **Job F:** On critical p → Appendix J: Answers to Selected Exercises
Rob Calloway, batch operations lead, notices ACCTRCN7 has been running for 88 minutes. Normally it would have completed 66 minutes ago. The downstream jobs — regulatory reporting, GL posting, statement generation — are all queued and waiting. → Case Study 1: CNB's Overnight Plan Change Investigation
Lisa connects to LPAR DB2A (the production DB2 subsystem where ACCTRCN7 runs) from her home workstation via encrypted VPN. She pulls up her diagnostic toolkit — a set of SQL queries she's refined over the years. → Case Study 1: CNB's Overnight Plan Change Investigation
04:22 AM
Lisa restarts ACCTRCN7 from the beginning (it has built-in checkpoint/restart, so she can restart from the last commit point — a design decision from Chapter 10 of this book). → Case Study 1: CNB's Overnight Plan Change Investigation
Normal processing. PNCLAJ25 handled approximately 40-60 concurrent tasks per AOR. Working storage consumption: 60 × 2.4 MB = 144 MB per AOR. Within the 256 MB ECDSA — tight but functional. - **09:45** — Volume increases. Claims processors from the West Coast join. Peak concurrent PNCLAJ25 tasks per → Case Study 2: Pinnacle Health Insurance's CICS Storage Crisis
43 additional U4038 abends in CNBAO03 as users retry the failed transaction. - **08:17** — CICSPlex SM detects the failure rate and routes XVAL transactions to other AORs. But CNBVAL50 is installed in all AORs — the failures follow. - **08:19** — All 8 AORs that serve XVAL are experiencing U4038 abe → Case Study 1: Continental National Bank's U4038 Cascade and LE Governance Overhaul
08:26
Kwame instructed the build team to recompile CNBVAL50 with Enterprise COBOL V6.3. - **08:34** — Recompilation complete. New load module promoted to production. - **08:36** — NEWCOPY issued in all AORs. - **08:38** — XVAL transactions processing normally. → Case Study 1: Continental National Bank's U4038 Cascade and LE Governance Overhaul
09:52
Three more AORs enter SOS: PNCAO02, PNCAO05, PNCAO06. - **09:55** — Diane Okoye receives automated alerts. She begins investigation. - **10:05** — Diane issues `EXEC CICS INQUIRE SYSTEM` commands and reviews CICS statistics. She sees: → Case Study 2: Pinnacle Health Insurance's CICS Storage Crisis
1. B
Multi-row FETCH reduces thread switches between the application and DB2 address spaces. The SQL execution cost per row stays roughly the same; the savings come from eliminating the per-row overhead of crossing the address space boundary. → Chapter 7 Quiz
1. C
SEC=YES is the master switch that enables CICS to use the External Security Manager for all security decisions. XTRAN, XRES, and XCMD are subordinate parameters that control specific security levels, but none of them work unless SEC=YES is set. → Chapter 16 Quiz
Peak TPS per AOR (from SMF 110 aggregates) - Average and P95 response time per transaction type - Peak task count per region (from CICS statistics) - Peak EUDSA usage per region - QR TCB busy percentage at peak - DB2 thread usage at peak → Chapter 17: CICS Performance and Tuning
1. DFHJS2LS (JSON Schema to Language Structure)
Takes a JSON schema and generates a COBOL copybook that maps to it. Use this when the JSON schema is the source of truth (you're implementing an API spec designed by the distributed team). → Chapter 14: CICS Web Services
Meets monthly. Includes architecture lead (Sandra), business representatives, operations, finance. Reviews progress against the roadmap. Approves phase transitions. Resolves cross-team conflicts. Has the authority to kill initiatives that aren't working. → Index
`FOR SYSTEM_TIME AS OF` returns the version that was active at the specified timestamp. Since the row was updated on July 1st, the June 15th query returns the previous version from the history table. → Chapter 7 Quiz
10. C
After -911, DB2 rolls back the entire unit of work to the last COMMIT point. All uncommitted changes are lost, all cursors are closed, and the application must re-read any needed data before retrying. → Chapter 8 Quiz: DB2 Locking, Concurrency, and Deadlock Resolution
10:08
Diane's reaction (later described to Kwame Mensah at a cross-company architecture forum): "I saw 2.4 megabytes per task and I knew exactly what happened. One hundred and twelve tasks times 2.4 MB is 269 megabytes. Our ECDSA is 256 megabytes. The program doesn't fit." - **10:12** — Diane's emergency → Case Study 2: Pinnacle Health Insurance's CICS Storage Crisis
Each UPDATE on a temporal table requires DB2 to INSERT the old row into the history table before applying the update, effectively doubling the I/O for that operation. Real-world overhead is typically 40–60%. → Chapter 7 Quiz
12,000 vs. 3,000 req/sec
COBOL vs. Java for SecureFirst's balance inquiry - **0.8ms vs. 14ms** — p99 latency, COBOL vs. Java for the same service - **60-70%** of rehost projects underestimate total cost by 2-3x (Gartner/Forrester) - **$152.3M vs. $212M** — FBA's 5-year TCO for Refactor vs. Replatform → Chapter 32 Key Takeaways: Modernization Strategy
12. B
A recursive CTE requires an anchor member (the initial query) and a recursive member (the query that references the CTE itself), connected by UNION ALL. → Chapter 7 Quiz
12. C
Accessing resources in the same order eliminates the possibility of circular waits, which is the definition of a deadlock. Increasing timeout just delays the detection. UR sacrifices data integrity. LOCKSIZE TABLESPACE eliminates concurrency. → Chapter 8 Quiz: DB2 Locking, Concurrency, and Deadlock Resolution
127 unnecessary dependencies
jobs that were predecessors only because "they were always run in that order" with no actual data dependency - **43 duplicate dependencies** — Job C depended on Job A both directly and through Job B (if B already depends on A, C doesn't need to depend on A) - **8 phantom dependencies** — references → Chapter 23: Batch Window Engineering
13. B
XUSER=YES enables surrogate user checking in the CICS SIT. When enabled, CICS checks the SURROGAT class whenever a task attempts to run under a userid different from the signed-on userid. → Chapter 16 Quiz
13. C
DB2 does not automatically detect cycles in recursive CTEs. Without a depth limit or cycle detection in the WHERE clause, the CTE will iterate indefinitely until system resources (typically TEMP space) are exhausted. → Chapter 7 Quiz
13. E
All listed strategies are valid. Frequent COMMIT (A) keeps lock count below LOCKMAX. Increasing LOCKMAX (B) raises the threshold. Proactive LOCK TABLE (C) avoids accumulating individual locks. Switching to ROW (D) changes the granularity but note: it increases lock count for the same number of row a → Chapter 8 Quiz: DB2 Locking, Concurrency, and Deadlock Resolution
ROW_NUMBER() assigns sequential integers starting at 1 within each partition. PARTITION BY ACCT_NUM creates a separate sequence for each account, ordered by TXN_DATE. → Chapter 7 Quiz
14. C
SMF Type 110 is the CICS-specific SMF record. It contains transaction performance data (subtype 1) and exception data (subtype 2). SMF Type 80 is the RACF-specific record. Both are important for CICS security auditing. → Chapter 16 Quiz
14:27
Lisa initiates the DB2 REORG on tablespace DSNDB04.GENLGR01. The REORG begins with an initial drain of the tablespace. → Case Study 1: CNB's MAXT Crisis
14:28
The drain lock is acquired. All SQL access to GENLGR01 is suspended during the drain phase. The drain is expected to last 10–15 seconds before the REORG enters its sort-and-rebuild phase (which allows read access). → Case Study 1: CNB's MAXT Crisis
14:29
The drain lasts longer than expected because of the tablespace's size (45 GB after recent growth from the regulatory audit workload). During the drain, every CICS transaction that touches the GL — approximately 35% of the core banking workload — stalls. → Case Study 1: CNB's MAXT Crisis
14:30
CNBAORB1's active task count rises from its normal 160 to 220. Tasks are not completing because they are waiting for the DB2 drain lock. New transactions continue to arrive at normal rates (2,100 TPS per AOR), and each arriving transaction receives a TCA and joins the wait. → Case Study 1: CNB's MAXT Crisis
14:31
Active task count on CNBAORB1 reaches 248. Rob Calloway's monitoring console shows an amber alert. → Case Study 1: CNB's MAXT Crisis
14:32
CNBAORB1 hits MXT (250). DFHZC0101 message appears on the system log. New transactions begin queuing in the TOR. The TOR's dynamic routing algorithm detects the MAXT on AORB1 and begins shifting traffic to AORB2. → Case Study 1: CNB's MAXT Crisis
14:33
CNBAORB2, now receiving the combined load of both AORs, hits MXT (250). Both AORs are in MAXT. The TOR queues all new transactions. Response times visible to customers: 30+ seconds. ATM terminals begin timing out. → Case Study 1: CNB's MAXT Crisis
14:34
Rob pages Kwame, who is in the capacity planning meeting. "Both B-region AORs are in MAXT. No volume spike. Something changed." → Case Study 1: CNB's MAXT Crisis
14:35
Kwame pulls up CICS statistics remotely. He sees the task wait breakdown: 89% of active tasks are in DB2 wait state. He asks Lisa: "Are you running anything on the GL tablespace?" → Case Study 1: CNB's MAXT Crisis
14:36
Lisa confirms the REORG. She pauses it immediately: `TERM UTILITY(DSNUTIL.GENLGR01)`. The drain lock releases. → Case Study 1: CNB's MAXT Crisis
14:37
The backlog of 500+ waiting transactions (across both AORs) begins draining. Tasks that were blocked on the GL tablespace complete within milliseconds. Active task counts drop from 250 to 180 within 15 seconds. → Case Study 1: CNB's MAXT Crisis
14:38
Active task counts return to normal (160 per AOR). Response times normalize. ATM terminals recover. → Case Study 1: CNB's MAXT Crisis
15. B
RANK() assigns the same rank to ties but skips subsequent ranks (1, 2, 2, 4). DENSE_RANK() assigns the same rank to ties without gaps (1, 2, 2, 3). → Chapter 7 Quiz
15. C
PCI-DSS Requirement 10.7 mandates a minimum of one year of audit trail history, with at least three months immediately available for analysis. Many organizations retain for longer based on other regulatory requirements. → Chapter 16 Quiz
16. B
The third argument to LAG() is the default value returned when there is no row at the specified offset (i.e., for the first row in the partition, there is no previous row, so LAG returns 0). → Chapter 7 Quiz
`ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW` accumulates from the first row of the partition through the current row, producing a running total. → Chapter 7 Quiz
18. A
ROWS operates on physical row positions. RANGE operates on the logical value of the ORDER BY column. With duplicate values, RANGE treats all rows with the same value as part of the same frame position. → Chapter 7 Quiz
18. B
AUTHENTICATE(CERTIFICATE) causes CICS to request the client's digital certificate during the TLS handshake and validate it against the trusted CA certificates in the CICS keyring. This is mutual TLS — both sides authenticate. One-way SSL only authenticates the server to the client. → Chapter 16 Quiz
19. A
Single-row: 10M rows × 3 SQL statements × 0.03ms = 900,000ms = 15 minutes. Multi-row (rowset 500): 10M/500 = 20,000 batches × 3 SQL statements × 0.03ms = 1,800ms = 1.8 seconds. But note: the UPDATE cannot be multi-row FETCH in this scenario (it's a positioned update per row), so the actual answer de → Chapter 7 Quiz
19. B
When a transaction is routed via MRO, the user's ACEE (security token) is propagated from the TOR to the AOR. The AOR uses this propagated ACEE for all security checks, maintaining the user's identity across region boundaries. This is fundamental to MRO security. → Chapter 16 Quiz
19. D
Both B and C. Deadlocks can occur even with frequent commits if online and batch access rows in different orders (B is true). Lock escalation is prevented because the batch never holds more than 500 locks, which is well below LOCKMAX of 10,000 (C is true). → Chapter 8 Quiz: DB2 Locking, Concurrency, and Deadlock Resolution
2. B
With XTRAN=YES, CICS checks whether users are authorized to execute transactions. With XFCT=NO, CICS does NOT check file-level authority — any user who can execute a transaction can access any file that transaction opens, regardless of RACF file profiles. This is a common security gap. → Chapter 16 Quiz
2. C
SQLCODE 100 means end of result set. SQLERRD(3) = 283 means 283 rows were placed in the host variable arrays. You must process only positions 1–283. → Chapter 7 Quiz
Takes a COBOL copybook and generates a JSON schema that maps to it. Use this when the COBOL copybook is the source of truth (you're exposing an existing COBOL program). → Chapter 14: CICS Web Services
2. Management Class
Defines *lifecycle* management: - Backup frequency and number of versions - Migration eligibility (days since last use before migrating to tape/VTS) - Retention period or expiration date - Command/auto migrate controls - Partial release settings → Chapter 4: Dataset Management Deep Dive
2. Project growth (Month 2)
Business forecast: projected transaction growth (from business unit, typically 10–15% annually for CNB) - New features: any new transactions planned for deployment (from development team) - Seasonal factors: year-end, tax season, promotional campaigns - Technology changes: CICS version upgrades, DB2 → Chapter 17: CICS Performance and Tuning
2. The Architecture Review Board
Meets weekly during active modernization. Reviews every significant design decision. Ensures consistency across teams. Prevents "shadow modernization" (teams making platform changes without coordination). → Index
API access for mobile/web consumers, CI/CD pipelines for faster delivery, automated testing for quality. The business gets modern capabilities without the risk and cost of platform migration. → Chapter 32 Quiz: Modernization Strategy
20. B
The recommended order is: multi-row FETCH (mechanical, low risk, immediate gain) → multi-row INSERT (same pattern, output side) → MERGE (moderate complexity, requires index verification) → OLAP functions (requires rethinking program structure) → recursive CTEs (most complex, replaces the most COBOL → Chapter 7 Quiz
MQ queue managers started, shared queues available - MQ channels started automatically (previous tests had required manual restart — automated in GDPS policy after 2021 test) - Network team verified ATM routing, Fedwire connectivity, online banking DNS → Case Study 1: Continental National Bank's DR Architecture and Annual Test
DB2 doesn't know the size of your COBOL arrays. It will write 1,000 rows' worth of data starting at the array address, overwriting whatever follows in WORKING-STORAGE. The COBOL compiler and DB2 precompiler don't cross-check array bounds. → Chapter 7 Quiz
Defines *data characteristics*: - RECFM, LRECL, BLKSIZE (defaults if not specified in JCL/program) - SPACE allocation (primary, secondary, directory) - Dataset organization (PS, PDS, PDSE, VSAM types) - VSAM parameters (CI size, free space, share options) - Compaction (hardware compression) → Chapter 4: Dataset Management Deep Dive
3. Model and validate (Month 3)
Apply growth projections to baseline metrics - Identify bottlenecks: which resource hits its limit first? - Validate with performance test environment (replay scaled-up traffic) - Present findings to architecture review board with specific recommendations → Chapter 17: CICS Performance and Tuning
3. The Metrics Dashboard
Published weekly. Shows: - MIPS trend (should be declining as dead code is retired) - API endpoint count and traffic volume (should be growing) - Development cycle time (should be decreasing as CI/CD matures) - Production incident rate (should not be increasing — if it is, you're moving too fast) - → Index
SQLCODE +252 indicates partial completion of a non-atomic multi-row INSERT. Check SQLERRD(3) for the count of successfully inserted rows. → Chapter 7 Quiz
Defines *where data goes*: - Pool of volumes eligible for dataset placement - Volume selection criteria - Threshold management (high/low thresholds for space) - Overflow storage groups → Chapter 4: Dataset Management Deep Dive
With XDFTRAN=YES and no generic default profile, when RACF finds no matching profile, it returns "resource not found." CICS interprets this as "no security restriction" and allows the transaction. This is why XDFTRAN=YES without a restrictive default profile is dangerous — it creates an implicit PER → Chapter 16 Quiz
6. C
SQLCODE -788 means the source of the MERGE contains duplicate values for the columns used in the ON clause. MERGE requires unique join keys in the source. → Chapter 7 Quiz
7. A
When the ON clause evaluates to true (match), only the WHEN MATCHED branch executes. The branches are mutually exclusive per source row. → Chapter 7 Quiz
RESSEC(YES) on a transaction definition tells CICS to perform resource-level security checks for resources (files, queues, etc.) accessed by that transaction. If RESSEC(NO), CICS skips resource checks for that transaction even if XRES=YES in the SIT. This is a per-transaction control. → Chapter 16 Quiz
8. B
System-period temporal tables have their timestamps (SYS_START, SYS_END) managed automatically by DB2. Application-period temporal tables have their period columns managed by the application's DML statements. → Chapter 7 Quiz
9. B
SQLCODE -911 indicates deadlock (reason 00C90088) or timeout (reason 00C9008E). -913 also indicates a resource unavailable condition (timeout). -803 is duplicate key; -904 is resource unavailable (different category); -501 is cursor not open. → Chapter 8 Quiz: DB2 Locking, Concurrency, and Deadlock Resolution
9. C
The maximum timestamp value in SYS_END indicates the row is currently active (it has not yet been superseded by a newer version). → Chapter 7 Quiz
RACF user authentication (unique user identification) - RACF session management (automatic logoff after inactivity) - Dataset encryption + DB2 encryption (encryption and decryption of ePHI) → Index
without it, you're guessing 2. **A seat at the business planning table** — without business input, your technical forecast is incomplete 3. **Budget authority or influence** — the capacity plan must connect to procurement decisions 4. **Credibility with both technical staff and management** — the ca → Chapter 29: Capacity Planning and Growth Management
Account Balance Inquiry
Score: 14. Multiple access paths (CICS, web service, IVR), but data intensity is low (one table). Keep in application with a shared copybook for the validation logic. The overhead of a stored procedure call isn't justified for a single-table read. → Chapter 10: Stored Procedures and User-Defined Functions in COBOL
Accounting Class 1
CPU time is attributed to the stored procedure's own work. - **Accounting Class 2** — CPU time includes wait time. - **Distributed Accounting** — For DRDA callers, CPU is charged to the distributed thread. → Chapter 10: Stored Procedures and User-Defined Functions in COBOL
ACH Inbound Processing
triggered programs that start when ACH file messages arrive, rather than polling on a timer 2. **Wire Transfer Fraud Detection** — events captured from the wire transfer program and broadcast to fraud, compliance, sanctions, and AML systems for parallel processing 3. **Balance Alert Notifications** → Project Checkpoint: Event-Driven Notification Layer for HA Banking System
**Start with Part VII (Modernization), then backfill.** Corporate learners are motivated by immediate relevance. Open with Chapter 33 (API Enablement) to demonstrate what modernization looks like, then cycle back to Parts I-VI for the underlying knowledge. The 10-week syllabus supports this resequen → Instructor Guide Overview
Additional data you've discovered:
Migration project estimated at $380,000 (vendor says $180,000) - Batch window expansion from 3 hours to 7 hours requires larger instances: add $22,000/year - Cloud operations (0.3 FTE new skillset): $51,000/year - Direct Connect for data replication: $36,000/year - Micro Focus maintenance: $16,800/y → Chapter 34 Exercises: COBOL-to-Cloud Patterns
Optimizing EOD-002 (ATM settlement) does *nothing* for the window. It's not on the critical path. - Optimizing EOD-012 (statement generation, 60 minutes) would reduce the critical path by however many minutes you save — it *is* on the critical path. - Adding a new 20-minute job after EOD-009 but bef → Chapter 23: Batch Window Engineering
ANCHOR EXAMPLE
Kwame Mensah designed this topology in 2019 when CNB migrated from CICS TS 5.4 to 5.6. The previous topology was 10 regions across 2 LPARs. The migration to 4 LPARs with 16 regions was driven by the addition of mobile banking (SYSD) and the need to isolate web traffic after a 2018 incident where a w → Chapter 13: CICS Architecture for Architects
COBOL's verbose, English-like syntax, paragraph names, PERFORM structures, and explicit DATA DIVISION definitions give AI models more semantic context to work with than terse languages with implicit types. → Chapter 35 Quiz: AI-Assisted COBOL
Answer: C
AI tools frequently reference features that exist in Micro Focus COBOL but not Enterprise COBOL for z/OS, or vice versa. They may also suggest features from newer compiler versions than the shop uses. → Chapter 35 Quiz: AI-Assisted COBOL
Answer: D
Production deployment includes a manual approval gate (`input` directive in Jenkins) that requires a release manager's authorization. Lower environment deployments are automated. → Chapter 36 Quiz: DevOps for the Mainframe
Answer: FALSE
AI tools cannot understand system-level context like JCL dependencies, batch chain sequencing, or inter-program file contracts unless this information is explicitly provided in the prompt. → Chapter 35 Quiz: AI-Assisted COBOL
Answer: TRUE
After generating 4,200 AI test cases, reducing to 3,100 through expert review, the automated nightly test runs caught three regression bugs in the first month. → Chapter 35 Quiz: AI-Assisted COBOL
https://kafka.apache.org/documentation Comprehensive documentation for Kafka configuration, topic management, consumer groups, and exactly-once semantics. Relevant for the cloud side of the event mesh pattern. → Chapter 37 Further Reading: The Hybrid Architecture
Validates OAuth2/JWT tokens, enforces rate limits, blocks known bad actors. This is the first line of defense and should reject 90%+ of illegitimate traffic before it reaches z/OS. → Chapter 14: CICS Web Services
API management
versioning, rate limiting, analytics - **Data transformation** — JSON ↔ COBOL with a graphical mapping editor - **Multiple backend support** — CICS, IMS, DB2, and MQ - **z/OS-native performance** — runs on z/OS, not through a network gateway → Chapter 14: CICS Web Services
API versioning plan
Design a v2 of the account inquiry API that adds new fields and changes the balance type from string to a structured object with amount and currency. Document the migration path. → Project Checkpoint 21: The API Layer
Application 1: Core Savings Account Processing
280K LOC COBOL on CICS + DB2 - Processes 50,000 transactions/second peak - p99 latency: 0.8ms - Business need: Mobile app needs REST API access for balance inquiry and transfers - Current access: 3270 terminal only → Chapter 32 Exercises: Modernization Strategy
Application 2: Monthly Statement Generation
45K LOC COBOL batch - Generates 2.1 million PDF statements monthly - Runs in 3-hour batch window - Business need: Move to real-time digital statements; reduce paper - Current: Batch-only, outputs EBCDIC print files → Chapter 32 Exercises: Modernization Strategy
Application 3: Internal Branch Lookup Tool
8K LOC COBOL on CICS + VSAM - Used by 50 branch managers for employee scheduling - ~100 transactions/day - Business need: Replace with web-based tool accessible on tablets - Current: 3270 green screen only → Chapter 32 Exercises: Modernization Strategy
Application logging
Your COBOL program should log significant events (successful transfers, validation failures, external service timeouts) to a CICS journal or DB2 audit table. Include the correlation ID from the API gateway (typically passed as an HTTP header) so that end-to-end tracing is possible. → Chapter 14: CICS Web Services
but the program is 95.6% in DB2, so this is only 4.4% 2. **Synchronous I/O not being properly categorized** — possible with buffer pool contention 3. **Page latch contention** — waiting for access to in-memory buffer pages (not lock contention — latch contention) 4. **Prefetch suspension** — DB2 sus → Case Study 2: Pinnacle Health's Claims Processing Performance Crisis
Application-level authorization
The COBOL program can perform additional checks (e.g., user X can only view account Y if they own it). This is business logic authorization, not infrastructure authorization. → Chapter 14: CICS Web Services
Application-Owning Region (AOR)
Runs your COBOL programs. AORs contain the application logic, access databases through DB2 connections, and perform the business processing. They do not own terminals and ideally do not own files. AORs are the workhorses. → Chapter 13: CICS Architecture for Architects
Architecture Decision Records (ADRs)
including retroactive ADRs for past decisions — are the most valuable documentation artifact for knowledge transfer because they preserve decision-making context. - **Decision logs** (lightweight, one-line-per-decision records) accumulate into a searchable history of operational choices. - **Runbook → Key Takeaways — Chapter 40: Knowledge Transfer and Mentoring
Partition TRANSACTIONS by month (12 active + 84 archive = 96 total, or rolling window with detach) - Write the ALTER TABLE ... DETACH PARTITION statement for monthly archival - Write the validation query (compare row counts before and after detach) → Project Checkpoint: HA Banking System — DB2 Architecture
Arrow Key:
**Solid arrows (→):** Hard prerequisites. The target chapter requires understanding of the source chapter. - **Dashed arrows (-.->):** Soft prerequisites. The target chapter benefits from but does not strictly require the source chapter. → Advanced COBOL Programming — Complete Textbook Outline
The WSBIND mapping validates data types (a string where a number is expected is rejected) - VALIDATION(YES) on the WEBSERVICE resource enables schema validation - Oversized fields are truncated or rejected based on mapping rules → Chapter 14: CICS Web Services
Attribution
You must give appropriate credit, provide a link to the license, and indicate if changes were made. - **ShareAlike** --- If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original. → Advanced COBOL Programming
Audit Controls (164.312(b)):
SMF type 80 (RACF decisions) - SMF type 102 (DB2 access) - SMF type 110 (CICS transactions) - Application audit logs for PHI access events - 6-year retention of audit records (HIPAA minimum) → Index
Audit logging:
Define the audit log record format - Specify retention period and archival strategy - Describe at least three audit queries that security/compliance would run regularly → Project Checkpoint 21: The API Layer
OAuth 2.0 client credentials flow for system-to-system (partner banks) - OAuth 2.0 authorization code flow for user-facing applications (portal, mobile) - Mutual TLS for batch transfer endpoint - JWT token validation steps (all five checks from Section 21.6) → Project Checkpoint 21: The API Layer
Automated Restart Rules:
Space abends (x37): Automatic restart with 5-minute delay, maximum 2 attempts. The delay gives SMS time to attempt space reclamation. - Application transient errors (U0100-U0199): Automatic restart from checkpoint, 3-minute delay, maximum 2 attempts. - Virtual storage shortage (S878): Automatic rest → Case Study 1: CNB's Batch Operations Center and Rob's Playbook
https://docs.aws.amazon.com/apigateway Documentation for the managed API gateway used in SecureFirst's architecture. Covers REST API creation, Lambda integration, usage plans, and CloudWatch integration. → Chapter 37 Further Reading: The Hybrid Architecture
B
Banking (US):
**OCC Bulletin 2023-17 (Third-Party Risk Management):** Requires banks to ensure critical third-party services have adequate DR capabilities. - **FFIEC Business Continuity Planning Handbook:** The primary guidance for US bank DR. Requires documented BIA (Business Impact Analysis), BCP (Business Cont → Index
if the compensation itself fails and is retried, it must not double-compensate 2. **Be auditable** — every compensation must be logged with the reason, the original transaction, and the compensation details 3. **Handle the compensation failure** — what happens if the SWIFT cancellation fails? You ne → Chapter 18: CICS Failure and Recovery
Every affinity is technical debt. When you design a new CICS application, your first question should be: "Can I avoid creating any transaction affinities?" The answer is almost always yes, if you use external state stores (DB2, coupling facility data tables, shared temporary storage) instead of regi → Chapter 13: CICS Architecture for Architects
BINQ
Balance inquiry. Reads one DB2 row. Average response time: 30ms. Working storage: 150 KB. 2. **XFER** — Fund transfer. Reads 2 DB2 rows, writes 3 DB2 rows, writes 1 audit record. Average response time: 80ms. Working storage: 300 KB. 3. **STMT** — Statement generation. Reads 50–500 DB2 rows. Average → Chapter 17: CICS Performance and Tuning
BMC Capacity Management for z/OS
Comprehensive capacity planning product that automates data collection, trend analysis, and forecasting. Covers historical data management, what-if modeling, and reporting. Relevant to the data pipeline described in Section 29.2.4. - **Broadcom (CA) Capacity Management** — Capacity planning and opti → Further Reading — Chapter 29
BMC CONTROL-M Documentation
CONTROL-M's monitoring and alerting capabilities, including SLA management, critical path analysis, and automated recovery configuration. The "Monitoring and Alerting" section of the administration guide covers threshold configuration in detail. - **Broadcom (CA) AutoSys/CA-7 Documentation** — CA-7' → Further Reading — Chapter 27
BMC Control-M for z/OS Documentation
Alternative workload scheduler widely used at mainframe sites. Covers parallel job group definitions, resource balancing, and SLA-based scheduling relevant to parallel batch pipeline management. → Chapter 25 Further Reading
BMC MainView for CICS
Commercial monitoring tool with real-time dashboards, automated alerting, and capacity planning features for CICS environments. Supports multi-region correlation for CICSPlex environments. → Chapter 17 Further Reading
BMC MainView for z/OS
Real-time monitoring of batch job performance, resource utilization, and system health. Provides the dashboard capabilities described in Section 27.3. - **Broadcom SYSVIEW Performance Management** — Comprehensive z/OS performance monitoring with historical data analysis. Useful for the Level 4 trend → Further Reading — Chapter 27
Another major workload scheduler with specific support for parallel job streams, cross-job dependencies, and automatic restart/recovery that complements the partition control table approach. → Chapter 25 Further Reading
Broadcom CICS Detector (formerly CA CICS Detector)
Commercial CICS performance monitor that provides real-time and historical analysis of CICS transaction performance. Includes automated bottleneck detection and root cause analysis features. → Chapter 17 Further Reading
number of data buffers (default: 2). Controls how much data VSAM prefetches. - **BUFNI** — number of index buffers (default: 1). Controls how much of the KSDS index stays cached in memory. → Chapter 26: Batch Performance at Scale
Building a Personal Learning Network
Your professional network is a learning resource. Cultivate relationships with architects at other organizations, at IBM, and at ISV vendors. These relationships provide perspectives you cannot get from books — how other organizations solved similar problems, what approaches they tried and abandoned → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
The COVID-era claims surge exposed that the nightly eligibility batch cannot scale beyond 500,000 pending claims without exceeding the batch window - The legislature has mandated a public-facing web portal for claimants within 18 months - A recent audit found 47 SOX-equivalent control deficiencies i → Sample Final Exam
Business Impact Analysis
reviewed annually 2. **DR Plan Document** — updated after every test and significant change 3. **DR Test Calendar** — minimum semi-annual full test 4. **DR Readiness Dashboard** — monitored continuously (replication status, backup currency, team readiness) 5. **DR Audit Trail** — for regulators (rev → Chapter 30 Key Takeaways: Disaster Recovery and Business Continuity
BY THE NUMBERS
CNB's post-incident analysis found that across their 16 CICS regions, 4 had MXT settings that exceeded the storage-bounded limit. Kwame's team corrected all four. The lesson: MXT should be calculated, not inherited from the previous system programmer who set it in 2009 and never revisited it. → Chapter 17: CICS Performance and Tuning
Run MVS 3.8j (a real, if vintage, OS) - Execute JCL, including JOB/EXEC/DD processing - Run COBOL programs (VS COBOL II era) - Practice TSO/ISPF navigation - Run batch utilities (IEBGENER, IEHPROGM, sort) → Appendix F: Environment Setup Guide
Run z/OS (requires IBM license) - Run DB2 (requires z/OS) - Run CICS Transaction Server (requires z/OS) - Run Enterprise COBOL V6 (requires z/OS) - Emulate modern z/Architecture features (z16 crypto, etc.) → Appendix F: Environment Setup Guide
Capacity calculation:
Estimated MIPS per transaction: ________ - Peak transactions per second: ________ - Required MIPS at peak: ________ - MIPS per LPAR: ________ - Peak utilization per LPAR (all LPARs active): ________% - Peak utilization per LPAR (N-1 failure scenario): ________% → Project Checkpoint 1: z/OS Environment Specification
Extracts 36 months of daily capacity data from the DB2 capacity repository (CAPACITY_CPU_DAILY, CAPACITY_WKL_DAILY, CAPACITY_IO_DAILY tables). This produces a flat file with one record per LPAR per day, containing average and peak GP utilization, zIIP utilization, MSU consumption, and EXCP counts. → Case Study 1: CNB's Annual Capacity Planning Cycle
CAPDHRLY
Extracts 90 days of hourly data for detailed peak analysis (CAPACITY_CPU_HOURLY table). This is used to identify within-day patterns and calculate R4HA profiles. → Case Study 1: CNB's Annual Capacity Planning Cycle
MQ channels encrypted with TLS? _______________ - Channel authentication records configured? _______________ - RESLEVEL for application userids: _______________ - RESLEVEL for QM started task userid: _______________ → Project Checkpoint 28: Security Architecture for the HA Banking System
Chaos engineering
Design a chaos test plan that validates your HA architecture. What happens when you kill a z/OS Connect instance? A CICS region? The MQ queue manager? The API gateway? Document expected behavior and recovery time for each scenario. → Project Checkpoint 21: The API Layer
Chapter 1 (COBOL Foundations)
Hard prerequisite. The COBOL programs in this chapter assume familiarity with file handling, working storage, and basic program structure. - **Chapter 5 (Workload Management)** — Soft prerequisite. WLM service classes determine batch job dispatching priority and resource allocation, which directly a → Further Reading — Chapter 27
Chapter 1 (z/OS Ecosystem)
Hard prerequisite. The z/OS architecture, subsystem structure, and LPAR concepts are foundational to capacity planning. - **Chapter 5 (Workload Manager)** — Hard prerequisite. WLM service classes determine workload characterization for capacity planning. WLM capping is a capacity optimization lever. → Further Reading — Chapter 29
Chapter 10: DB2 Data Sharing
Utility coordination across data sharing members. Recovery with TOLOGPOINT instead of TORBA. Cross-member utility scheduling. → Chapter 9 Further Reading
Chapter 11: DB2 Performance Monitoring
DB2 EXPLAIN analysis, DSN_STATEMNT_TABLE, and DB2 statistics are the DB2-side diagnostics that complement the CICS-side diagnostics in Section 17.5. When SMF 110 shows DB2 as the bottleneck, Chapter 11's tools identify the specific DB2 problem. → Chapter 17 Further Reading
Chapter 13
CICS regions host the backend programs your APIs call. TOR/AOR routing still applies. - **Chapter 14** — First-generation web services in CICS. z/OS Connect is the second generation, providing cleaner separation. - **Chapter 19** — MQ enables asynchronous API patterns. Fund transfer APIs use request → Chapter 21: Key Takeaways
Chapter 13 checkpoint
Your CICS region topology defines the backends that z/OS Connect connects to. Reference your TOR/AOR routing decisions. - **Chapter 19 checkpoint** — Your MQ queue definitions support the asynchronous transfer API. Reference your queue names and queue manager configuration. - **Chapter 20 checkpoint → Project Checkpoint 21: The API Layer
Chapter 13: CICS Architecture
Region topology (TOR/AOR/FOR), MRO, and CICSPlex SM routing are the architectural decisions that determine performance boundaries. This chapter tunes within those boundaries; Chapter 13 sets them. → Chapter 17 Further Reading
Chapter 13: CICS Architecture for Architects
Prerequisite for this chapter. TOR/AOR topology, MRO routing, and CICSPlex SM workload management — all directly impact web service deployment. → Chapter 14 Further Reading
Chapter 15: Channels and Containers
The modern CICS data-passing mechanism that replaces COMMAREA. Essential for web services with payloads exceeding 32KB and for passing multiple data segments between the pipeline and the COBOL program. → Chapter 14 Further Reading
Chapter 16: CICS Performance Tuning
Deep dive into performance measurement and tuning for the topology patterns described in this chapter. → Chapter 13 Further Reading
Chapter 16: CICS Security
In-depth coverage of RACF integration, identity propagation, and security exits that complement the web service security architecture described in Section 14.7. → Chapter 14 Further Reading
Chapter 17: CICS Performance and Tuning
Performance tuning (MAXTASK, DSA sizing) interacts with recovery. Over-tuned regions (MAXTASK too high, storage too tight) are more likely to fail. Under-tuned regions (too much headroom) waste resources. The balance between performance and resilience is an architectural trade-off. → Chapter 18 Further Reading
Chapter 18: CICS Failure and Recovery
You will design XA transaction coordination for the fund transfer (DB2 updates across regions) and indoubt resolution procedures. The performance monitoring from this checkpoint feeds directly into failure detection — a transaction that exceeds its alert threshold may be the first sign of a region f → Project Checkpoint 17: CICS Tuning
Chapter 19: IBM MQ for the COBOL Architect
MQ as a 2PC participant in CICS transactions. MQ connection recovery and shared queue architecture for cross-LPAR indoubt resolution. The Pinnacle Health case study foreshadows MQ topics covered in depth in Chapter 19. → Chapter 18 Further Reading
Chapter 1: z/OS Ecosystem and Sysplex Architecture
Foundation for understanding TCP/IP networking on z/OS, Communications Server, and how HTTP requests reach CICS. → Chapter 14 Further Reading
Foundation for understanding coupling facility, XCF, data sharing, and Sysplex Distributor — all referenced in this chapter's Sysplex-aware CICS section (13.6). → Chapter 13 Further Reading
Chapter 21
API mediation layer consumes events from the pub/sub topics defined here > - **Chapter 22** — Data integration patterns build on event-driven feeds > - **Chapter 30** — Disaster recovery design must account for in-flight events, incomplete sagas, and subscription queue backlogs > > **Quiz yourself n → Chapter 20: Event-Driven Architecture with COBOL — MQ Triggers, CICS Events, and Pub/Sub Patterns
Chapter 21: API-First COBOL
Takes web services to the next level: designing COBOL programs specifically for API consumption. Covers API versioning, backward compatibility, and API governance for COBOL-backed services. → Chapter 14 Further Reading
Chapter 23 (Batch Window Engineering)
Critical path analysis, job dependency graph, throughput math. Chapter 23 defines the window; Chapter 26 optimizes the jobs within it. → Chapter 26: Further Reading
Chapter 23: Batch Window Management
Critical path analysis, batch dependency graphs, and batch window calculations provide the framework for designing parallel pipelines. The parallel pipeline's critical path replaces the serial chain analyzed in Chapter 23. → Chapter 25 Further Reading
Chapter 24: Checkpoint/Restart
Partition-level checkpoint/restart extends the single-program checkpoint patterns from Chapter 24. The checkpoint interval calculations, commit strategies, and restart positioning logic from Chapter 24 apply to each partition independently. → Chapter 25 Further Reading
Chapter 24: Checkpoint/Restart for Batch
The batch equivalent of CICS recovery. While the mechanisms differ (checkpoint files vs. system logs), the principles are the same: bound the recovery window, make recovery automatic, test regularly. → Chapter 18 Further Reading
Chapter 25 (Parallel Batch Processing)
Parallel job design, partition-by-key strategies. Chapter 25's parallelization creates the architecture; Chapter 26's tuning maximizes each parallel stream's throughput. → Chapter 26: Further Reading
Chapter 26: Batch Performance Tuning
The next chapter covers optimizing individual programs within partitions. Once you have parallelized the pipeline (this chapter), tuning each partition's program (Chapter 26) provides additional elapsed time reduction. → Chapter 25 Further Reading
Chapter 27 (Batch Monitoring)
Operational monitoring, alerting, trend analysis. Chapter 27 builds the ongoing monitoring framework that sustains the performance improvements achieved in Chapter 26. → Chapter 26: Further Reading
Chapter 29 (Capacity Planning)
MSU forecasting, storage growth, transaction volume modeling. The performance baseline established in Chapter 26 feeds directly into Chapter 29's capacity projection models. → Chapter 26: Further Reading
Chapter 29: Capacity Planning
Extends the CICS-specific capacity planning in Section 17.7 to the full z/OS environment: MIPS, MSU, storage, DASD, and network capacity across the entire Parallel Sysplex. → Chapter 17 Further Reading
Chapter 2: z/OS Storage Management
Understanding virtual storage, address space limits, and above/below the bar storage is essential for DSA and EDSALIM sizing. → Chapter 13 Further Reading
Chapter 30: Disaster Recovery
Extends the recovery concepts from this chapter to site-level failures. GDPS, Sysplex recovery, and site failover build on the single-region and multi-region recovery patterns established here. → Chapter 18 Further Reading
Chapter 33: Strangler Fig Pattern
The architectural strategy for incrementally migrating from monolithic CICS to microservices. Uses web services (from this chapter) as the interception layer for routing between legacy and new components. → Chapter 14 Further Reading
Chapter 3: Language Environment
LE runtime considerations for COBOL programs invoked through web services, including enclave management and storage allocation. → Chapter 14 Further Reading
Chapter 4 (Dataset Management)
BLKSIZE fundamentals, SMS data class configuration, VSAM cluster design. The I/O optimization in this chapter builds directly on Chapter 4's dataset architecture decisions. → Chapter 26: Further Reading
Chapter 4: Dataset Management on z/OS
Utility input/output dataset allocation, space sizing, SMS storage classes, and dataset naming conventions. Directly applicable to COPY datasets, REORG work datasets, and LOAD input datasets. → Chapter 9 Further Reading
Chapter 4: z/OS Datasets and File Processing
Foundation for understanding sequential datasets, VSAM, GDGs, and the file I/O operations used in file-based integration. - **Chapter 19: IBM MQ and Message-Oriented Middleware** — MQ fundamentals including queue managers, channels, persistent messaging, and the COBOL MQ API calls used throughout se → Chapter 22 Further Reading
Chapter 5: Workload Manager and DB2
WLM application environments, service classes, and goals. Required reading before deploying any stored procedure. - **Chapter 6: The DB2 Optimizer** — How the optimizer uses UDF attributes (DETERMINISTIC, NO EXTERNAL ACTION, data access level) to make optimization decisions. - **Chapter 8: Locking a → Chapter 10: Further Reading
Chapter 5: z/OS Workload Manager
WLM service classes, velocity goals, and dispatching priority directly feed CICSPlex SM's goal-based routing algorithm. → Chapter 13 Further Reading
Chapter 6 (DB2 Optimizer)
Access path selection, EXPLAIN analysis, catalog statistics. The DB2 batch performance patterns in Section 26.5 extend Chapter 6's optimizer concepts to batch-specific scenarios. → Chapter 26: Further Reading
Chapter 6: The DB2 Optimizer
Access path selection governs the performance of every cursor in this chapter. Review EXPLAIN analysis and index selection before designing cursor pools. - **Chapter 7: Advanced SQL** — MERGE, INSERT ... SELECT, and set-based operations appear throughout this chapter. Common table expressions are us → Further Reading: DB2 Application Patterns
Chapter 8: DB2 Locking and Concurrency
SHRLEVEL options on utilities interact with application locking. Understanding lock escalation, claim/drain processing, and commit frequency is essential for online utility execution. → Chapter 9 Further Reading
CHAPTER METRICS
This chapter covered the CICS performance model from dispatcher through storage through capacity planning. In the next chapter (Chapter 18: CICS Failure and Recovery), we will shift from performance to resilience — designing CICS systems that recover from failures without losing data or breaking SLA → Chapter 17: CICS Performance and Tuning
**Kwame Mensah** — Chief architect, 30 years mainframe experience. The voice of wisdom. Has seen every failure mode. Calm under pressure. First one called during a Sev-1. - **Lisa Tran** — Senior DBA. Knows DB2 internals better than most IBM Level 3 support. Meticulous. Will not approve a query that → Continuity Tracking Document
Check DSN_STATEMNT_TABLE
Is COST_CATEGORY = 'A'? If 'B', RUNSTATS first. 3. **Read PLAN_TABLE** — Identify ACCESSTYPE, MATCHCOLS, METHOD, PREFETCH for each step 4. **Compare to expected plan** — Do you know what the plan *should* be? If not, work it out from the indexes and predicates. 5. **Check catalog statistics** — Quer → Chapter 6: DB2 Optimizer Internals
each step triggers the next by publishing an event. No central coordinator. Each service reacts to events independently. This is the distributed-systems purist model, but it's harder to reason about in COBOL because the flow of control is implicit in the event subscriptions rather than explicit in t → Chapter 20: Event-Driven Architecture with COBOL — MQ Triggers, CICS Events, and Pub/Sub Patterns
CICS affects WLM
CICS reports transaction response times to WLM via the enclave model. WLM uses these response times to evaluate whether the service class is meeting its goals. If transactions miss their velocity goals, WLM increases the region's dispatching priority — but only if the miss is due to CPU contention ( → Chapter 17: CICS Performance and Tuning
CICS and DB2: The Best of Both Worlds (SG24-7421)
Integration patterns between CICS and DB2, including thread management, connection pooling, THREADSAFE programming, and the performance implications of different DB2 access patterns from CICS. The CMDT sizing methodology in this Redbook informed the formulas in Section 17.2. → Chapter 17 Further Reading
CICS and Parallel Sysplex (SG24-6449)
IBM Redbook covering Sysplex-aware CICS features: shared temporary storage, named counter servers, coupling facility data tables, and VTAM generic resources. Includes practical configuration examples and sizing guidance. → Chapter 13 Further Reading
CICS and the Liberty JVM Server (SG24-8418)
Covers integrating Liberty JVM server into CICS regions for REST/JSON API access. Directly relevant to the SecureFirst case study's API integration pattern. Includes performance tuning and security configuration. → Chapter 13 Further Reading
CICS and the Parallel Sysplex (SG24-6449)
Chapter 7 covers Sysplex-aware recovery features: coupling facility log streams, shared temporary storage recovery, and cross-system indoubt resolution. The coupling facility sizing guidance for system logs is essential for capacity planning. → Chapter 18 Further Reading
The CICS-DB2 connection architecture, including CMDT, THREADLIMIT, THREADWAIT, and the task-related user exit (TRUE) that manages DB2 thread allocation. The section on THREADSAFE programming is essential background for Section 17.2's discussion of L8 TCBs. → Chapter 17 Further Reading
CICS Explorer
IBM's Eclipse-based graphical interface for CICS management and development. Useful for visualizing CICSPlex SM topologies and managing resource definitions. Free download for CICS TS 5.x customers. → Chapter 13 Further Reading
CICS Intercommunication Guide (SC34-7390)
The definitive guide to MRO, ISC, IPIC, function shipping, DPL, and transaction routing. Chapters 1–6 cover the architecture; chapters 7–14 cover configuration. Required reading for anyone designing a multi-region topology. → Chapter 13 Further Reading
CICS JSON Guide
Part of the CICS TS 5.6 documentation. Covers the JSON assistant (DFHJS2LS, DFHLS2JS), JSON transformation configuration, and JSON schema generation from COBOL copybooks. The examples are directly applicable to REST service development. → Chapter 14 Further Reading
CICS Operations and Utilities Guide — DFHRMUTL
Documentation for the recovery manager utility that lists and resolves indoubt units of work. Includes command syntax, output format, and examples of manual resolution procedures. → Chapter 18 Further Reading
CICS Performance Guide (SG24-6530)
Performance tuning for CICS regions, including MRO session sizing, MAXTASK optimization, DSA tuning, and workload balancing. The benchmark data and tuning methodology are applicable to any CICS installation. → Chapter 13 Further Reading
CICS Recovery and Restart (SG24-6843)
An older but still relevant Redbook focused entirely on CICS recovery. Covers failure scenarios, recovery procedures, log stream configuration, and recovery testing methodology. The testing methodology chapter is particularly valuable. → Chapter 18 Further Reading
CICS Recovery and Restart Guide (SC34-7388)
How CICS uses system logs, journals, and the recovery manager to ensure transaction integrity. Understanding recovery is essential for designing topologies that survive region failures. → Chapter 13 Further Reading
CICS Resource Definition Guide — DB2CONN
Comprehensive reference for the DB2CONN resource definition, including RESYNCMEMBER, STANDBYMODE, and THREADERROR parameters that affect recovery coordination between CICS and DB2. → Chapter 18 Further Reading
The PIPELINE and WEBSERVICE resources have associated statistics: request count, average response time, error rate, transformation time. Monitor these through CICSPlex SM or CICS Explorer. → Chapter 14: CICS Web Services
CICS System Definition Guide (SC34-7374)
Comprehensive reference for SIT parameters (DFHSIT), CSD resource definitions (CEDA), and system initialization. Sections on MAXTASK, DSALIM, EDSALIM, and ISC/IRC configuration are directly relevant to this chapter. → Chapter 13 Further Reading
CICS System Definition Guide — Recovery Parameters
Detailed reference for all SIT parameters related to recovery: START, KEYINTV, LOGDEFER, RMRETRY, UOWNETQL, and others. Each parameter includes the default value, valid range, and the impact on recovery behavior. - URL: https://www.ibm.com/docs/en/cics-ts/5.6?topic=tables-system-initialization → Chapter 18 Further Reading
CICS transaction boundaries
route the transaction elsewhere 2. **COMMAREA / channel boundaries** — the service contract 3. **Copybook boundaries** — isolated data structures = clean extraction 4. **DB2 view boundaries** — change what's behind the view 5. **MQ queue boundaries** — change the consumer → Chapter 33 Key Takeaways: Strangler Fig Pattern for Mainframes
Detailed description of CICS Monitoring Facility (CMF) data, including SMF 110 record formats, monitoring control tables, and the relationship between CMF data classes (identity, performance, exception). Required reading for anyone building custom performance analysis tools. → Chapter 17 Further Reading
CICS TS 5.6 Internet Guide (SC34-7379)
Covers CICS HTTP support, TCPIPSERVICE configuration, URIMAP definitions, and the EXEC CICS WEB API. The programming reference for requester-mode COBOL programs that make outbound HTTP calls. → Chapter 14 Further Reading
CICS TS 5.6 Java Applications in Liberty
Covers deploying Java applications in the CICS Liberty JVM server, including JAX-RS REST endpoints, JCICS API for COBOL invocation, and security configuration. → Chapter 14 Further Reading
CICS TS 5.6 Knowledge Center
The authoritative reference for all CICS configuration, commands, and architecture. Start with the "CICS concepts and planning" section for architectural context before diving into reference material. - URL: https://www.ibm.com/docs/en/cics-ts/5.6 → Chapter 13 Further Reading
CICS TS 5.6 Performance Guide (SC34-7385)
The definitive IBM guide to CICS performance tuning. Chapters on dispatcher tuning, storage management, DB2 connection optimization, and workload management are directly relevant to this chapter. The appendix on CICS statistics fields is essential for interpreting SMF 110 records. - URL: https://www → Chapter 17 Further Reading
CICS TS 5.6 Resource Definition Guide (SC34-7375)
Reference for TRANCLASS, TRANSACTION, and PROGRAM resource definitions used throughout this chapter. Includes the CONCURRENCY parameter options (QUASIRENT, THREADSAFE, REQUIRED). → Chapter 17 Further Reading
CICS TS 5.6 SOAP Guide
Covers SOAP pipeline configuration, WSDL processing, DFHWS2LS/DFHLS2WS utilities, and WS-Security integration. Essential reading for implementing SOAP services with WS-Security. → Chapter 14 Further Reading
CICS TS 5.6 System Definition Guide (SC34-7374)
Reference for all SIT parameters discussed in this chapter: MXT, DSALIM, EDSALIM, GCDSALIM, and related storage and task control parameters. The parameter descriptions include valid ranges, defaults, and tuning guidance. → Chapter 17 Further Reading
CICS TS 5.6 Web Services Guide (SC34-7392)
The authoritative reference for CICS web services. Covers provider and requester mode, pipeline configuration, data transformation, and security. Start with Part 1 (Concepts) before diving into Part 2 (Configuration) and Part 3 (Programming). - URL: https://www.ibm.com/docs/en/cics-ts/5.6?topic=serv → Chapter 14 Further Reading
CICS user mapping
The CICS web service infrastructure maps the authenticated identity (from the API gateway header or client certificate) to a RACF user ID. The COBOL program runs under this mapped user ID, inheriting the user's RACF permissions for DB2, VSAM, and other resources. → Chapter 14: CICS Web Services
Covers the CICS-DB2 attachment facility, including thread management, two-phase commit coordination, and indoubt resolution. The sections on RESYNCMEMBER and group resynchronization are essential for Sysplex environments. → Chapter 18 Further Reading
CICS-MQ Adapter Guide
Covers integration between CICS and IBM MQ, including transactional coordination (MQ as a 2PC participant), connection failure handling, and session recovery. The sections on connection recovery and channel reconnection are relevant to the Pinnacle Health case study. → Chapter 18 Further Reading
Practical guide to deploying and configuring CICSPlex SM. Includes step-by-step instructions for CMAS setup, workload management, BAS deployment, and monitoring. Despite the 5.1 designation, most content applies to 5.6. → Chapter 13 Further Reading
CICSPlex SM Managing Workloads (SC34-7382)
Covers CPSM workload management in detail: workload definitions, routing algorithms, affinity management, and WLM integration. The examples are usable as starting points for your own configuration. → Chapter 13 Further Reading
CLAIMS
800 million rows, partitioned by submission month (24 partitions, 2 years of history) - **MEMBER** — 45 million rows, partitioned by state code (50 partitions) - **PROVIDER** — 2 million rows, not partitioned - **PAYMENT** — 600 million rows, partitioned by payment date (24 partitions) → Case Study 2: Pinnacle Health's Batch/Online Lock Contention
passed all 87 rules, ready for transformation 2. **Error records** — failed one or more rules, written to an error file with error codes 3. **Validation summary report** — counts by error type, severity, and program code → Case Study 2: Federal Benefits' Regulatory Reporting Pipeline
https://www.cmg.org CMG focuses on performance and capacity management. Their conference proceedings and journal include technical papers on z/OS WLM tuning, coupling facility sizing, and performance modeling — topics directly relevant to the architecture decisions in this chapter. → Chapter 1 Further Reading: The z/OS Ecosystem
Kwame's team reviews TRANCLASS utilization quarterly. If a class consistently operates below 50% of its MAXACTIVE, the limit may be too generous. If a class frequently hits its MAXACTIVE, either the limit is too low or the transaction volume has grown beyond expectations. Either finding triggers a t → Chapter 17: CICS Performance and Tuning
COBIT's control objectives for IT operations management, including automated monitoring, event response, and operational procedures. Relevant for organizations subject to SOX or similar regulatory frameworks. → Further Reading — Chapter 31: Operational Automation
**(TRAN_DATE, STATUS):** Queries C and E use both. STATUS distribution may vary by date (more 'P' during business hours, more 'C' at end of day). - **(CHANNEL, TRAN_TYPE):** Query D/E use both. Mobile transactions may skew toward certain types. - **(STATUS, CHANNEL):** Query E uses both. Pending tra → Project Checkpoint: Indexing Strategy for HA Banking System
The procedure does not automatically commit when it returns. The calling program controls commit scope. For batch callers that commit every N rows, this is essential. Set this to YES only when the procedure must be an autonomous transaction. → Chapter 10: Stored Procedures and User-Defined Functions in COBOL
COMMIT strategy:
Online: COMMIT after each transaction (CICS pseudo-conversational, one UOW per transaction) - Batch account maintenance: COMMIT every 500 rows - Batch fraud detection: COMMIT every 200 rows - End-of-day settlement: Uses RS isolation, COMMIT after full settlement (this runs during the 1-hour reduced- → Chapter 8: DB2 Locking, Concurrency, and Deadlock Resolution: The Chapter That Prevents 2am Pages
A PERFORM or CALL branched to an address containing data instead of code. - A program was linked with an unresolved external reference (the entry point is garbage). - A table subscript or pointer was corrupted, causing a branch to a data area. - Calling a program compiled with incompatible compiler → Appendix D: z/OS Return and Abend Codes
Common causes:
`REGION` on the JCL JOB or EXEC card is too small. - The program allocates very large Working-Storage areas (multi-megabyte tables or arrays). - A runaway loop is consuming stack frames (recursive or deeply nested PERFORMs). - Multiple large programs are loaded into the same address space. - LE runt → Appendix D: z/OS Return and Abend Codes
COMMON PITFALL
"Just raise MXT" is the most dangerous reflex in CICS operations. Raising MXT without understanding *why* tasks are accumulating is like raising the speed limit on a highway where cars are stopped because of a bridge collapse. You're not fixing the bottleneck — you're allowing more cars to pile up i → Chapter 17: CICS Performance and Tuning
Common student struggles:
Assuming z/OS works like Linux or Windows. Intervention: draw a side-by-side comparison chart of process models, file systems, and job scheduling paradigms early in the lecture. - Underestimating the scale of mainframe workloads. Intervention: use real-world transaction volume statistics from bankin → Teaching Notes: Chapter 1 — z/OS Ecosystem
Communication clarity (6 points):
Well-organized phases with clear boundaries - Dependencies between phases identified - Realistic timeline given organizational constraints → Sample Final Exam
Compensation
Mainframe architect compensation reflects this demand. Senior mainframe architects in financial services routinely earn $180,000–$250,000 in base salary, with total compensation (including bonuses and benefits) exceeding $300,000 at the principal and fellow levels. These figures are competitive with → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
Compiler:
[ ] OPT(2) for all production batch programs - [ ] FASTSRT enabled for programs with SORT verbs - [ ] NOSEQCHK for production (SEQCHK for test) - [ ] NUMPROC(PFD) unless legacy data has invalid packed signs - [ ] SSRANGE on (safety over speed) → Chapter 26: Key Takeaways
Completeness
All six tablespaces have REORG, RUNSTATS, COPY, and recovery strategies 2. **Efficiency** — Utilities run only when needed; inline operations used where appropriate; parallelism exploited 3. **Recoverability** — Copy frequency and retention support the system's recovery objectives (RTO < 30 minutes → Project Checkpoint: DB2 Utility Schedule for the HA Banking System
For banking (PCI DSS, SOX) and healthcare (HIPAA), your CICS security architecture is auditable. Auditors will ask: Who can access which regions? How is user identity propagated across regions? How are privileged transactions (like force-post or override) controlled? Ahmad Rashidi at Pinnacle Health → Chapter 13: CICS Architecture for Architects
a 12-byte structure — carries the severity, facility ID, and message number. LE callable services like `CEEGQDT` (Get Condition Token) allow programs to inspect the condition programmatically, but this is rarely used in COBOL (more common in PL/I). → Index
Configuration containers
Create PERF-CONFIG containers with program name, threshold, and severity for each transaction 2. **TD Queue PFAL** — Extrapartition, routed to the monitoring system (Splunk, IBM OMEGAMON, or REXX-based alerting) 3. **TS Queue PFST** — Auxiliary, batch-extracted every 15 minutes for historical trendi → Project Checkpoint 17: CICS Tuning
Connection failure
The external host is unreachable. EXEC CICS WEB OPEN returns RESP(NORMAL) but RESP2 indicates connection error. 2. **Timeout** — The external service doesn't respond within the timeout. EXEC CICS WEB RECEIVE returns RESP(TIMEDOUT). 3. **HTTP error status** — The external service returns 4xx or 5xx. → Chapter 14: CICS Web Services
Write a Python client library that wraps the banking API. Include authentication, retry logic with exponential backoff, and rate limit handling. → Project Checkpoint 21: The API Layer
A Tier-1 bank processing 500 million transactions per day across a Parallel Sysplex. CNB is the primary reference architecture. When we discuss DB2 optimization, CICS routing, MQ messaging, or high-availability design, we are usually talking about CNB's systems. CNB's core banking platform is the sy → Preface
In 2023, Pinnacle experienced a security incident: a former employee's userid (not yet revoked) was used to access the claims system from a VPN connection. Because all ePHI was encrypted and the former employee did not have access to the CSFKEYS encryption keys (that access had been automatically re → Case Study 2: Pinnacle Health Insurance's HIPAA Security Implementation
Cost of the transformation:
18 months of project work (Diane full-time, Ahmad 50%, 2 additional developers) - 34 COBOL programs modified for DB2 column encryption - All batch JCL updated for userid separation - 200 GB/month additional DASD for enhanced audit logs - Zero production outages during the transformation → Case Study 2: Pinnacle Health Insurance's HIPAA Security Implementation
IBM White Paper on sizing coupling facility structures for CICS shared TS, named counters, and data tables. The formulas in this paper are the basis for capacity planning. → Chapter 13 Further Reading
**UNDERSTAND:** Map every business rule, every edge case, every undocumented behavior. This is the knowledge capture phase. It may be the most valuable output of the entire project. - **SHADOW:** Route copies of production traffic to the modern service; compare responses. Non-negotiable — it finds e → Chapter 33 Key Takeaways: Strangler Fig Pattern for Mainframes
Cross-Job Validation (at pipeline milestones):
Running totals from CLMINTKE through CLMPAYMT must reconcile - Claim count at each stage must be traceable to the original intake count - Financial totals must balance: payments + adjustments + denials = total claims received → Case Study 2: Pinnacle Health's Automated Claims Pipeline Recovery
Cross-Platform Learning
The most dangerous thing a mainframe architect can do is stop learning about non-mainframe technologies. Understand Kubernetes, microservices, event-driven architecture, cloud-native patterns, and AI/ML — not to replace the mainframe, but to integrate with it effectively. Dedicate at least 10% of yo → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
Cross-platform metrics (calculated):
End-to-end transaction latency (API Gateway response time minus CICS response time = integration layer overhead) - CDC replication lag (DB2 commit timestamp minus PostgreSQL apply timestamp) - VPN tunnel health and latency → Case Study 2: SecureFirst's Production Hybrid — Two Years In
CROSS-REFERENCE
Chapter 1 covered z/OS Parallel Sysplex and CF data sharing. DB2 data sharing through the coupling facility enables any region on any LPAR to access DB2 data with no function shipping and no ISC overhead. This is why CNB moved their highest-volume data from VSAM to DB2 — not for relational features, → Chapter 13: CICS Architecture for Architects
Current mainframe costs:
System contributes 800 MIPS to the total mainframe workload - Software licensing cost attributed to this workload: $4.8M/year - 2 FTE mainframe developers maintaining the system: $340K/year total - Hardware allocation (proportional): $600K/year - Operations support (proportional): $200K/year → Chapter 32 Exercises: Modernization Strategy
Current state:
2.8 million lines of COBOL across 1,400 programs - DB2 database with 340 tables, some with 200+ columns - CICS online system for claims intake, eligibility determination, and payment processing (120 transactions) - Batch processing: nightly eligibility batch (4-hour runtime), weekly payment batch (6 → Sample Final Exam
updated monthly, showing all jobs and dependencies 2. **Critical path documentation** — which jobs are on it, what the expected times are 3. **Recovery runbook** — for the top 20 failure scenarios, step-by-step recovery procedures 4. **Capacity model** — current utilization, growth rate, projected w → Chapter 23: Batch Window Engineering
Dashboard specification:
Real-time metrics (request volume, response time, error rate) - Per-consumer breakdown - Backend health (CICS regions, MQ, z/OS Connect instances) - Capacity trending → Project Checkpoint 21: The API Layer
Data architecture
What data flows where, and in what order? - **Systems architecture** — How many initiators, LPARs, DB2 subsystems? - **Application architecture** — How are programs structured for restartability? - **Capacity architecture** — What throughput does the hardware support? - **Organizational architecture → Chapter 23: Batch Window Engineering
Moving 40 years of data from IMS/DB2 to a new platform is not a weekend job. Budget 15-20% of total project cost. 2. **Parallel running** — You'll run both systems simultaneously for months or years during migration. Both cost money. 3. **Performance tuning on the new platform** — The application wo → Index
Data requirements:
Data needed from mainframe: ________________________________________________ - Synchronization pattern: [ ] Batch Extract [ ] CDC [ ] API Real-Time - Acceptable data staleness: _________________________________________________ → Project Checkpoint 34: HA Banking System Cloud Integration
*An open-source textbook for the mainframe professionals who keep the world running.* → Advanced COBOL Programming
Day 1 — API Enablement
Morning: Chapter 33 (z/OS Connect, API mediation, OpenAPI generation). Chapter 34 (event-driven architecture) — condensed overview. - Afternoon: Lab — expose MedClaim claims API via z/OS Connect (or Zowe-based equivalent). Generate OpenAPI spec. Test with Postman or curl. → 10-Week Intensive Syllabus
Day 1 — Architecture Review and Final Prep
Morning: Integration session — review MedClaim end-to-end. Discuss architectural decisions, tradeoffs, and what participants would change. Cover Chapter 38 (enterprise architecture patterns) at a survey level. - Afternoon: Final practical prep. Lab time for participants to polish MedClaim and prepar → 10-Week Intensive Syllabus
Day 1 — Checkpoint/Restart and Performance
Morning: Chapter 25 (checkpoint/restart), Chapter 26 (batch performance tuning). - Afternoon: Lab — add checkpoint/restart to MedClaim adjudication step. Tune BUFNO/BUFND for claims master file. Measure elapsed time before and after tuning. → 10-Week Intensive Syllabus
Day 1 — Embedded SQL and Cursors
Morning: Chapter 7 (static and dynamic SQL), Chapter 8 (cursor processing). - Afternoon: Lab — write MedClaim claims INSERT program with host variables. Write a cursor-based claims listing program. Practice FETCH loop patterns. → 10-Week Intensive Syllabus
Day 1 — Locking, Stored Procedures, Utilities
Morning: Chapter 10 (locking and concurrency), Chapter 11 (stored procedures), Chapter 12 (utilities) — condensed into a single intensive session. - Afternoon: Lab — simulate a lock contention scenario. Write a simple stored procedure. Run RUNSTATS on MedClaim tables. → 10-Week Intensive Syllabus
Day 1 — MQ Integration
Morning: Chapters 20-21 (MQ architecture, MQI calls from COBOL, async patterns). Chapter 22 (poison messages) — condensed to 30-minute overview. - Afternoon: Lab — implement MedClaim pharmacy benefits MQ integration. MQPUT a request, MQGET a response. Handle the no-message-available scenario. → 10-Week Intensive Syllabus
Day 1 — Queues, Web Services, and Diagnostics
Morning: Chapter 17 (channels and containers, TS/TD queues), Chapter 18 (CICS web services) — condensed. Chapter 19 (CICS problem determination) — highlights only. - Afternoon: Lab — add TS queue-based workflow to MedClaim. Expose a read-only claims inquiry as a REST service. → 10-Week Intensive Syllabus
Day 1 — RACF and DB2 Security
Morning: Chapter 29 (RACF fundamentals, profiles, access control), Chapter 30 (DB2 security, grants, roles, trusted contexts). - Afternoon: Lab — define RACF profiles for MedClaim datasets and DB2 objects. Create three DB2 roles (clerk, adjudicator, admin) with appropriate privileges. Test access wi → 10-Week Intensive Syllabus
Day 1 — z/OS Architecture (Condensed)
Morning: Chapters 1-3 condensed — z/OS address spaces, virtual storage, subsystem architecture. Focus on "what you need to know to understand DB2 and CICS behavior," not exhaustive z/OS internals. - Afternoon: Lab environment orientation. Verify LPAR access, dataset naming conventions, DB2 subsystem → 10-Week Intensive Syllabus
Morning: Chapter 13 (CICS architecture), Chapter 14 (BMS maps). - Afternoon: Lab — create MedClaim claims inquiry BMS mapset. Build the map, define the transaction in the CSD. → 10-Week Intensive Syllabus
Day 2 — CICS Security and Compliance
Morning: Chapter 31 (CICS security) — condensed. Chapter 32 (audit and compliance) — condensed. Focus on HIPAA relevance for MedClaim. - Afternoon: Lab — configure CICS transaction security for MedClaim. Write a compliance checklist mapping MedClaim controls to HIPAA requirements. - Assigned reading → 10-Week Intensive Syllabus
Day 2 — CICS-DB2 Integration
Morning: Chapter 16 (CICS-DB2 integration, thread management, DSNCRLI). - Afternoon: Lab — integrate MedClaim CICS transaction with DB2 backend. Test under simulated multi-user load. - **Progressive project checkpoint 1:** MedClaim DB2 tables, static SQL programs, at least one CICS transaction integ → 10-Week Intensive Syllabus
Day 2 — DB2 Performance
Morning: Chapter 9 (EXPLAIN, indexing, access paths). Hands-on EXPLAIN interpretation. - Afternoon: Lab — run EXPLAIN against MedClaim queries. Add indexes, observe plan changes. Write a performance analysis memo. → 10-Week Intensive Syllabus
Day 2 — DevOps Pipeline
Morning: Chapter 36 (testing strategies, zUnit), Chapter 37 (CI/CD, Git SCM, DBB). - Afternoon: Lab — write zUnit tests for MedClaim. Configure a CI/CD pipeline (Jenkins or equivalent) to compile, bind, deploy, and test MedClaim components. - Chapter 35 (migration patterns and cost models): Assigned → 10-Week Intensive Syllabus
Day 2 — Final Assessment
Morning: Final practical exam (2 hours). Timed exercise: participants receive a partially complete CICS-DB2-MQ integration with a batch component. They must complete the integration, fix a security vulnerability, and add a test case. Followed by 30-minute individual oral defense of MedClaim architec → 10-Week Intensive Syllabus
Day 2 — Language Environment and DB2 Concepts
Morning: Chapters 4-5 condensed (LE runtime options that matter for DB2 and CICS programs, key compiler options). Chapter 6 (DB2 architecture, address spaces, packages, plans). - Afternoon: Create MedClaim DB2 tables. Bind a plan. Submit a simple DB2-COBOL program via JCL. - Assigned reading: Chapte → 10-Week Intensive Syllabus
Day 2 — Midterm Practical
Morning: Review session (1.5 hours). Midterm practical (1.5 hours). Timed exercise: participants receive a COBOL-DB2-CICS program with three bugs (a cursor not closed, a locking issue, a BMS map field mismatch). They must diagnose and fix all three within 90 minutes using only the z/OS tools availab → 10-Week Intensive Syllabus
Day 2 — Scheduling and Parallel Processing
Morning: Chapter 27 (workload scheduling, DAG concepts) — condensed lecture. Chapter 28 (parallel processing, sysplex) — overview only, no lab. - Afternoon: Lab — design a scheduling DAG for MedClaim nightly cycle. Document dependencies, recovery procedures, and escalation paths. - **Progressive pro → 10-Week Intensive Syllabus
Chapters on authorization and column access control 4. **z/OS ICSF Administrator's Guide** — Chapters 1-2 (cryptographic architecture and key management) 5. **z/OS Communications Server: AT-TLS** — Configuration chapter 6. **PCI DSS v4.0 Standard** — All 12 requirements (even if your environment isn → Chapter 28 Further Reading: Mainframe Security for COBOL Developers
DB2 Access Pattern:
Tables read: ________________ - Tables written: ________________ (should be NONE for balance inquiry) - SQL complexity (simple SELECT / join / subquery): ________________ - Accessed via view? Yes / No: ________________ → Project Checkpoint 33: HA Banking System Strangler Fig Plan
DB2 and CICS: The Perfect Couple (SG24-7421)
Integration patterns between DB2 and CICS, including connection pooling, thread management, and data sharing implications for CICS multi-region topologies. → Chapter 13 Further Reading
DB2 Connection Statistics
CICS-DB2 thread usage. Key fields: - Current and peak active threads - Thread wait count (tasks waiting for a DB2 thread) - CMDT limit reached count - Average DB2 elapsed time per call → Chapter 17: CICS Performance and Tuning
multiple DB2 subsystems accessing the same data simultaneously through the Coupling Facility's group buffer pool 2. **CICS Sysplex optimized routing** — dynamic transaction routing based on real-time workload across multiple CICS regions on multiple LPARs 3. **Automatic failure recovery** — if an LP → Index
DB2 DRDA distributed processing
queries from remote clients, JDBC/ODBC access - **DB2 parallel query processing** — CPU consumed by DB2 parallelism - **XML processing** — XML parsing and validation within DB2 - **IPSec encryption** — network encryption processing - **z/OS Container Extensions (zCX)** — Linux workloads on z/OS - ** → Chapter 29: Capacity Planning and Growth Management
DB2 for z/OS Administration Guide (SC27-8841)
Chapter on query parallelism covers I/O parallelism, CP parallelism, and Sysplex query parallelism in detail. Includes DEGREE bind option semantics, PARAMDEG ZPARM configuration, and parallelism monitoring through EXPLAIN and accounting traces. - **DB2 for z/OS Performance Monitoring and Tuning Guid → Chapter 25 Further Reading
DB2 thread
a structure that represents the CICS task's conversation with DB2. → Index
DB2 thread limits (CMDT)
Threads exhaust before MXT because most transactions use DB2. 2. **MXT** — Task accumulation hits the MXT limit. 3. **EUDSA** — Storage exhaustion from too many concurrent tasks with large working storage. 4. **QR TCB saturation** — The dispatcher cannot keep up (only if THREADSAFE is not fully depl → Chapter 17: CICS Performance and Tuning
DB2:
[ ] Commit frequency 1,000-5,000 (not every record) - [ ] FOR FETCH ONLY on all read cursors - [ ] DEGREE(ANY) in batch plan BIND - [ ] Sequential/list prefetch verified in EXPLAIN - [ ] RUNSTATS current for batch-accessed tablespaces → Chapter 26: Key Takeaways
The two-phase commit protocol is what distinguishes CICS from a simple program executor. In phase 1 (PREPARE), CICS asks every resource manager: "Can you commit your part of this work?" Each resource manager writes its changes to a log and responds YES or NO. In phase 2 (COMMIT or ROLLBACK), CICS is → Chapter 13: CICS Architecture for Architects
perform the non-reversible action only after the data is committed 2. **Made idempotent** — design the receiving system to detect and ignore duplicates (using a unique identifier like transaction ID) 3. **Performed within the same unit of recovery** — use two-phase commit with MQ Series or other XA- → Chapter 24: Checkpoint/Restart Design — Building Batch Programs That Survive Any Failure
Deliberate Practice
Just as musicians practice scales and athletes drill fundamentals, architects should practice their craft deliberately. This might mean analyzing a design you did not create (read architecture documents from open-source projects or case studies and evaluate them critically), writing an ADR for a hyp → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
DELIVERABLE
Document your topology design in the format shown in code/project-checkpoint.md. Bring your design to the Chapter 14 practical lab, where you'll implement the CSD definitions for your chosen topology. → Chapter 13: CICS Architecture for Architects
Why separate PROD and BATCH catalogs? (Answer: batch creates/deletes thousands of GDG generations nightly; isolating this catalog activity prevents contention on the online catalog) - Why separate UAT from DEV? (Answer: UAT uses production-like volumes and SMS classes; DEV uses cheaper storage) - Ho → Project Checkpoint: HA Banking System — Dataset Naming, SMS Classes, and GDG Strategy
Design rationale for Tier 1:
**LIMIT(14)**: Two weeks of daily generations. Provides enough history for restart/recovery of any day within the past two weeks and for trend comparison. - **SCRATCH**: When a generation rolls off at day 15, delete it. The data has been rolled up into the weekly summary by then. - **NOEMPTY**: Only → Case Study 2: Pinnacle Health Insurance's GDG Strategy for Monthly Claims Processing
Design rationale for Tier 2:
**LIMIT(8)**: Eight weeks of weekly summaries — nearly two months. Covers any month-end processing window and provides quarter-over-quarter comparison capability. - The COBOL rollup program aggregates daily detail into weekly summary records, reducing record count by roughly 5:1 (multiple claim tran → Case Study 2: Pinnacle Health Insurance's GDG Strategy for Monthly Claims Processing
Design rationale for Tier 3:
**LIMIT(24)**: Two years of monthly snapshots. Covers regulatory audit cycles (typically 12-18 months lookback). - **NOSCRATCH**: When a generation rolls off at month 25, it's uncataloged but NOT deleted. DFSMShsm migrates the uncataloged dataset to tape based on the management class. Ahmad Rashidi → Case Study 2: Pinnacle Health Insurance's GDG Strategy for Monthly Claims Processing
Design rationale for Tier 4:
**LIMIT(10)**: Ten years of annual snapshots. Covers the longest regulatory retention requirement (IRS records, 7 years; some state insurance regulations, 10 years). - **NOSCRATCH**: Same reasoning as Tier 3 — data must survive beyond the GDG catalog lifetime. - Annual generations are created during → Case Study 2: Pinnacle Health Insurance's GDG Strategy for Monthly Claims Processing
the one clear win. Three dev environments running on AWS, saving approximately $2.1M/year in mainframe MIPS. 2. **Batch reporting on cloud** — about 40% of the nightly batch (read-only reporting and analytics) successfully running on AWS, saving approximately $1.4M/year in marginal MIPS (these jobs → Case Study 1: MidWest Mutual's Failed COBOL-to-Cloud Migration — The $47 Million Lesson
JSON Schema to Language Structure (generates COBOL copybook from JSON schema) - **DFHLS2JS** — Language Structure to JSON Schema (generates JSON schema from COBOL copybook) - **Runtime transformation engine** — The DFHJSON handler program that performs transformations at request/response time → Chapter 14: CICS Web Services
DFHJS2LS Reference
Detailed parameter documentation for the JSON Schema to Language Structure utility. Covers JSON schema interpretation, COBOL type mapping, and WSBIND generation. → Chapter 14 Further Reading
DFHLS2JS Reference
Detailed parameter documentation for the Language Structure to JSON Schema utility. Covers MAPPING-LEVEL options, field name mapping, and OCCURS DEPENDING ON handling. - URL: https://www.ibm.com/docs/en/cics-ts/5.6?topic=services-dfhls2js → Chapter 14 Further Reading
DFHLS2WS Reference
Detailed parameter documentation for the Language Structure to WSDL utility. Covers bottom-up WSDL generation from COBOL copybooks. → Chapter 14 Further Reading
DFHWS2LS
WSDL to Language Structure (generates COBOL from WSDL/XSD) - **DFHLS2WS** — Language Structure to WSDL (generates WSDL from COBOL) - **Runtime XML transformation** — DFHPITP handler for XML ↔ COBOL conversion → Chapter 14: CICS Web Services
DFHWS2LS Reference
Detailed parameter documentation for the WSDL to Language Structure utility. Covers WSDL interpretation, complex type mapping, and namespace handling. → Chapter 14 Further Reading
DFSORT Application Programming Guide (SC23-6878)
Comprehensive reference for DFSORT control statements including SORT, MERGE, OUTFIL, INCLUDE/OMIT, and ICETOOL. Covers MAINSIZE, HIPRMAX, and parallel I/O configuration for sort performance. - **DFSORT: Getting Started (SC23-6879)** — Practical introduction with examples of OUTFIL for multiple outpu → Chapter 25 Further Reading
DFSORT optimization checklist:
MAINSIZE=MAX (use all available memory) - Work datasets on 3+ separate volumes/CUs - BLKSIZE=27,998 on all datasets - Use SORTOUT rather than OUTFIL for simple output → Example 2: Worked Throughput Calculation Examples
DFSORT's sort algorithm is hardware-aware
it knows the CPU cache line size, the number of available processors, and the memory hierarchy. 4. **DFSORT can exploit zIIP processors** for eligible work, reducing GP (General Purpose) processor cost. → Chapter 26: Batch Performance at Scale
DFSORT:
[ ] All sort/merge/reformat jobs evaluated for DFSORT replacement - [ ] INCLUDE/OMIT used to filter before sort wherever possible - [ ] INREC used to reduce record size before sort where applicable - [ ] MAINSIZE=MAX on all production sort jobs - [ ] DYNALLOC for work datasets (not pre-allocated) → Chapter 26: Key Takeaways
DIAGNOSTIC TECHNIQUE
To identify a storage leak in production, take CICS storage snapshots (CEMT I DSAS) at 30-minute intervals during the degradation. Plot EUDSA current allocation over time. If it is monotonically increasing, you have a leak. Cross-reference with CICS program statistics to identify which program's sto → Chapter 17: CICS Performance and Tuning
Disadvantages:
WITH HOLD cursors retain certain resources across COMMITs, potentially affecting DB2 memory utilization - If the underlying tablespace is reorganized or the index is rebuilt between commits (unlikely during batch, but possible during a long run), the cursor position may be lost - On restart after an → Chapter 24: Checkpoint/Restart Design — Building Batch Programs That Survive Any Failure
Write the YAML registration for each z/OS Connect instance: - Service ID and metadata - Health check URLs - Gateway routing paths - API documentation URL (Swagger endpoint) → Project Checkpoint 21: The API Layer
Show task state transitions (running, waiting, ready) - **File control entries** — Show VSAM I/O timing - **DB2 interface entries** — Show thread allocation, SQL preparation, and execution - **Storage manager entries** — Show GETMAIN/FREEMAIN activity → Chapter 17: CICS Performance and Tuning
Dispatcher Statistics
How busy is the dispatcher? Key fields: - QR TCB busy percentage — if this exceeds 80%, the QR is saturated - Number of task switches per interval - Maximum task count reached (peak active tasks) - Number of MAXT conditions - Total MAXT wait time → Chapter 17: CICS Performance and Tuning
IMS databases reside on VSAM datasets mirrored via GDPS/Metro Mirror - IMS log datasets are mirrored synchronously - IMS recovery requires: (a) restart IMS control region, (b) emergency restart from log, (c) database recovery if needed - **Key risk:** Only Marcus and two contractors understand the I → Case Study 2: Federal Benefits Administration's DR Compliance Requirements
Two minutes. The nightly batch processes long-running units of work. 120 seconds accommodates most batch commit intervals. - **RETRY 5** — Five retries with 30-second delay. Total drain attempt window: 4.5 minutes. If a batch job can't commit in 4.5 minutes, something is wrong with the batch job. - → Case Study 1: CNB's REORG Strategy for High-Volume Tables
DSA (Dynamic Storage Area)
Below the 16 MB line. In 2026, you might think below-the-line storage is irrelevant. It is not. CICS still uses below-the-line storage for BMS maps, some terminal control blocks, and 24-bit AMODE programs. DSALIM controls the upper bound. → Chapter 17: CICS Performance and Tuning
DSALIM
Maximum size of the DSA. Default is 5M. For most modern workloads, 5M is sufficient. Only increase if you have a significant number of 24-bit AMODE programs or heavy BMS map usage. CNB runs DSALIM=5M across all regions. → Chapter 17: CICS Performance and Tuning
E
EDSA (Extended Dynamic Storage Area)
Below the 2 GB bar but above the 16 MB line. This is where the bulk of CICS's work happens: program load areas, task control areas, working storage for most programs, channel data, container data. EDSALIM controls the upper bound. → Chapter 17: CICS Performance and Tuning
EDSALIM
Maximum size of the EDSA. This is the critical parameter. Default is 500M, which is almost always wrong for production. CNB runs EDSALIM=900M on their core banking AORs after careful measurement. → Chapter 17: CICS Performance and Tuning
EIBRESP / EIBRESP2
Response code from the last command. Non-zero responses indicate errors that may be causing retries or fallback logic — a common hidden performance problem. - **EIBTIME / EIBDATE** — Current time and date. Can be captured at transaction start and end to measure elapsed time within the program. - **E → Chapter 17: CICS Performance and Tuning
Encrypt everything in transit
TLS 1.3 for API traffic, AT-TLS on z/OS, IPSec for MQ channels. 2. **Encrypt everything at rest** — DFSMS dataset encryption on z/OS, cloud KMS encryption; keys never cross the platform boundary. 3. **Authenticate every request** — every API call carries a token; every MQ message carries sender iden → Chapter 37 Quiz: The Hybrid Architecture
Capture events from programs that don't use CICS APIs (pure COBOL logic without EXEC CICS commands) - Modify the application's behavior — it's read-only observation - Guarantee delivery in the same unit of work as the application (EP emission is asynchronous by default) - Replace application-level e → Chapter 20: Event-Driven Architecture with COBOL — MQ Triggers, CICS Events, and Pub/Sub Patterns
List all internal fields that must be suppressed (abend codes, program names, SQL codes, etc.) - Define the correlation ID format and logging strategy - Write example error responses for each HTTP error status (400, 401, 403, 404, 429, 500, 503) → Project Checkpoint 21: The API Layer
[ ] Specification is valid OpenAPI 3.0 (validate with Swagger Editor) - [ ] All six operations fully defined - [ ] COBOL data types correctly mapped to JSON types - [ ] COMP-3 fields mapped to `string` for precision - [ ] Error responses use generic messages, no internal details - [ ] Pagination pro → Project Checkpoint 21: The API Layer
Controls who can call it. - **Underlying table privileges** — The procedure's package runs with the authority of the package owner (via BIND PACKAGE with OWNER). Callers don't need direct SELECT/UPDATE on the underlying tables. → Chapter 10: Stored Procedures and User-Defined Functions in COBOL
Existing COBOL program: ACCTINQP
Interface: COMMAREA (256 bytes) - Input: 10-byte account ID, 1-byte request type - Output: Account details including balance, available balance, status, last activity date - Average execution time: 4ms (including DB2 query) → Case Study 1: SecureFirst's Mobile API Layer over CICS
Expected components (minimum):
Online transaction processing (balance inquiry, fund transfer, loan payment) - Batch posting (end-of-day transaction posting) - Interest calculation (daily accrual, monthly posting) - Statement generation (monthly account statements) - ACH/wire transfer processing (incoming and outgoing) - Regulator → Project Checkpoint 32: HA Banking System Modernization Assessment
EXPLAIN(YES): Binds the package AND populates PLAN_TABLE - EXPLAIN(ONLY): Populates PLAN_TABLE without actually binding (useful for what-if analysis) → Chapter 6: DB2 Optimizer Internals
Exposing raw COBOL field names in JSON
Translate `ACCT-CUST-LST-NM` to `accountCustomerLastName` - **Using HTTP POST for everything** — Use GET for reads, POST for creates, PUT for full updates, PATCH for partial updates, DELETE for deletes - **Returning HTTP 200 for errors** — Use proper HTTP status codes; consumers expect them - **Skip → Chapter 21: Key Takeaways
Map every failure domain in your architecture (from Level 1 through Level 7). For each, document the failure impact and the designed survivability mechanism. → Index
Failure symptoms
what the operator sees (abend codes, messages) b) **Diagnostic steps** — what to check before restarting c) **Recovery procedure** — exact steps to restart, including: - Which datasets to delete (if any) - How to modify the JOB statement - How to verify the restart was successful d) **Escalation cri → Project Checkpoint: Checkpoint/Restart Design for the HA Banking Batch Pipeline
A federal government benefits system at Social Security/IRS scale. FBA's systems are the hardest modernization scenario in the book: a forty-year-old codebase with 12 million lines of COBOL, strict security mandates (FISMA, FedRAMP), disaster recovery requirements that assume Washington D.C. is unav → Preface
Federal Government (US):
**FISMA (Federal Information Security Modernization Act):** Requires agencies to implement contingency plans per NIST SP 800-34. - **NIST SP 800-34 (Contingency Planning Guide):** Detailed guidance including BIA methodology, recovery strategy selection, plan testing, and maintenance. The most prescr → Index
Owns VSAM files and other CICS-managed resources. FORs handle file I/O requests from AORs via function shipping. They isolate file access so that file contention, enqueue waits, and file recovery do not impact the application regions. → Chapter 13: CICS Architecture for Architects
**DORA (Digital Operational Resilience Act):** Effective January 2025, DORA requires EU financial entities to maintain and test ICT (Information and Communication Technology) business continuity and DR plans. Includes mandatory annual DR testing and reporting to regulators. - **ECB (European Central → Index
Find the Traceback
read bottom to top (CEEMAIN → main → subprograms → failure) 2. **Find "Exception" status** — that's the failing module and statement 3. **Map statement to source** — use the compile listing 4. **Check Condition Information** — CEE3204S (S0C4), CEE3207S (S0C7), etc. 5. **Check storage values** — if X → Chapter 3 Key Takeaways: Language Environment Internals
IMS recovery still depends on a small team (3 people). While this is improved from the previous single-person dependency (Marcus Whitfield), the IG recommended expanding the trained recovery team to at least 5 people. - API gateway DR documentation is incomplete (the contractor issue) - The annual u → Case Study 2: Federal Benefits Administration's DR Compliance Requirements
Verify all called programs are in the STEPLIB/JOBLIB/link list. - Check that the CALL target is correct (no trailing spaces or invalid characters in dynamic CALL identifiers). - Validate subscript values — an out-of-range subscript can corrupt adjacent storage, including branch addresses. - Recompil → Appendix D: z/OS Return and Abend Codes
For each entry, specify:
Abend code - Context (which jobs/steps it applies to, or ALL) - Recovery action (RESTART_STEP, EXTEND_SPACE, WAIT_RESOURCE, CHECK_DB2, CHECK_MQ, ESCALATE) - Maximum retry count - Escalation trigger (what happens when retries are exhausted) - Special handling notes → Project Checkpoint — Chapter 31: HA Banking Operational Automation Framework
This chapter establishes the architectural foundation for all of Part III. Chapters 14–18 assume you understand region topology, routing, MRO, and CICSPlex SM. If any section here feels unfamiliar after your first read, stop and re-read it before moving forward. The cost of a shaky foundation multip → Chapter 13: CICS Architecture for Architects
Gateway topology
Document the deployment: - Number of gateway nodes and their locations - External load balancer configuration - Failover behavior when a gateway node goes down → Project Checkpoint 21: The API Layer
GCDSALIM
Maximum size of the GCDSA. Default is 256M. Increase for regions that heavily use coupling facility data table caching, or that benefit from above-the-bar program placement (CICS TS 5.5+). → Chapter 17: CICS Performance and Tuning
GDPS Configuration Design
Select the GDPS technologies for each tier. Design the storage replication topology (how many sites, what distance, what replication method). → Index
EBCDIC conversion must handle packed decimal, signed numeric, and redefined fields correctly. A single misalignment in the conversion copybook produces garbage data in every record that follows. - File sizes can be enormous. CNB's nightly extract is 12GB compressed. Transfer over the network takes t → Index
Grading criteria:
Technical feasibility and specificity (10 points): Do the proposed solutions actually work? Are specific technologies named and correctly applied? - Tradeoff analysis (8 points): Does the answer acknowledge risks, alternatives, and constraints? - Organizational awareness (6 points): Does the answer → Sample Final Exam
Grafana Documentation
https://grafana.com/docs Documentation for the unified monitoring dashboard platform. Covers Prometheus integration, custom data sources, dashboard design, and alerting rules. → Chapter 37 Further Reading: The Hybrid Architecture
GRS operates in two modes:
**GRS Ring:** Enqueue requests circulate around a logical ring of all Sysplex members. Every member must acknowledge. Simple but introduces latency proportional to the number of members. - **GRS Star:** A coupling facility structure holds the global enqueue table. Faster — only one coupling facility → Index
GSE (Guide Share Europe) — CICS Working Group
European user group with technical presentations on CICS performance from major European financial institutions. Case studies from banks and insurers with thousands of CICS regions provide real-world validation of the principles in this chapter. → Chapter 17 Further Reading
H
HA Banking Transaction Processing System
Each chapter adds a production-grade component to a high-availability banking transaction processing system. By the end of the textbook, students will have architected a complete system with DB2 persistence, CICS online processing, MQ messaging, batch settlement, security controls, DR capability, an → Advanced COBOL Programming — Complete Textbook Outline
HashiCorp Vault Documentation
https://developer.hashicorp.com/vault Documentation for secrets management that some hybrid architectures use for managing credentials that span platforms. Relevant to the identity and security patterns in Section 37.5. → Chapter 37 Further Reading: The Hybrid Architecture
Define what "healthy" means: - CICS IPIC connections active - MQ connection active - SSL certificates not expiring within 30 days - Available disk space above threshold → Project Checkpoint 21: The API Layer
Healthcare (US):
**HIPAA Security Rule (§164.308(a)(7)):** Requires a contingency plan including data backup plan, disaster recovery plan, and emergency mode operation plan. Testing and revision are required but frequency isn't specified. - **HIPAA doesn't specify RTO/RPO** — but CMS and state regulators expect heal → Index
HEAP parameters explained:
**Initial size (32768):** The first heap segment allocated at program init. Too small → immediate heap expansion. Too large → wasted virtual storage if the program doesn't need it. - **Increment size (32768):** Each additional heap segment. If your program frequently runs out of heap space, LE alloc → Index
HHS HIPAA Security Rule Guidance
The Department of Health and Human Services provides guidance documents that interpret the Security Rule's technical safeguards. These are more practical than the regulatory text. - **NIST SP 800-66 Rev2: Implementing the HIPAA Security Rule** (2024) — NIST's guide to implementing HIPAA technical sa → Chapter 16 Further Reading
BAT-001 (Transaction journal extract): I/O-bound (reading sequential journal) - BAT-002 (Transaction sort): I/O-bound (DFSORT, almost all I/O) - BAT-003 (Transaction validation): Mixed (COBOL logic + reference lookups) - BAT-004 (Fraud detection scan): CPU-bound (pattern matching algorithms) - BAT-0 → Project Checkpoint: Batch Performance Tuning for HA Banking System
Hints:
BAT-001 (extract) has no predecessors — it's the entry point. - BAT-002 (sort) needs the extract output. - BAT-003 (validation) needs sorted transactions. - BAT-004 (fraud scan) needs raw transactions — does it need them sorted? - BAT-005 (posting) needs validated transactions. - BAT-006 (balance ca → Project Checkpoint: Batch Window Design for HA Banking System
HIPAA
Health Insurance Portability and Accountability Act: privacy and security of protected health information (PHI) - **CMS Reporting** — Centers for Medicare & Medicaid Services: quality measures, cost reports, utilization data - **State Medicaid** — Reporting to three state Medicaid programs - **Joint → Case Study 2 — Pinnacle Health's Automated Compliance Reporting
Horizon 1 (0-12 months): Quick Wins and Foundation
Retire dead applications (the 38% from Sandra's assessment) - Establish the modernization toolchain (Git, CI/CD, automated testing — Chapter 36) - Expose 10-20 highest-value transactions as APIs (Chapter 21) - Implement application portfolio management tooling - Begin knowledge capture from retiring → Index
Horizon 2 (12-36 months): Strategic Modernization
Execute the refactoring plan for the "Refactor" applications - Begin IMS-to-DB2 migrations (if applicable) - Implement strangler fig pattern (Chapter 33) for applications being incrementally replaced - Expand API surface area to cover all externally-consumed services - Deploy AI-assisted code analys → Index
Horizontal scaling
Adding another AOR and distributing workload via dynamic routing. More expensive (another region to manage, another set of resources) but provides linear scalability and improved failure isolation. → Chapter 17: CICS Performance and Tuning
the definitive reference showing how your system's z/OS core, cloud periphery, API gateway, event mesh, and unified monitoring work together as a permanent hybrid architecture. → Project Checkpoint 37: Hybrid Architecture Document
[ ] All critical-path datasets use half-track optimal BLKSIZE - [ ] BUFNO=20-30 for large sequential files - [ ] VSAM BUFNI caches full index (or top 2 levels minimum) - [ ] VSAM BUFND ≥ 10 for data components - [ ] No DISP=OLD conflicts between concurrent jobs - [ ] EXCP counts baselined and trendi → Chapter 26: Key Takeaways
IBM API Connect Documentation
Complete reference for API Connect, including the API Manager, Developer Portal, Gateway, and Analytics components. The sections on "Mainframe APIs" and "z/OS Connect integration" are directly relevant. - **IBM Redbook: API Economy with IBM API Connect** (SG24-8430) — Business and technical guide to → Chapter 21: Further Reading
IBM Certifications
*IBM Certified System Programmer — z/OS*: Validates deep z/OS system programming knowledge. Respected in the mainframe community. - *IBM Certified Application Developer — COBOL*: Validates COBOL development skills. Most useful for those early in their career. - *IBM Certified Database Administrator → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
IBM CICS Community
Active community forum for CICS practitioners. Questions about topology design, CICSPlex SM configuration, and MRO/ISC troubleshooting regularly receive expert responses. - URL: https://community.ibm.com/community/user/ibmz-and-linuxone/groups/topic-home?CommunityKey=cics → Chapter 13 Further Reading
IBM CICS Community — Recovery Forum
Active discussion forum for CICS recovery questions. Topics frequently include indoubt resolution procedures, ARM configuration, and emergency restart troubleshooting. - URL: https://community.ibm.com/community/user/ibmz-and-linuxone/groups/topic-home?CommunityKey=cics → Chapter 18 Further Reading
IBM CICS Developer Center
Code patterns, tutorials, and sample applications for CICS web services. Includes a "Hello World" REST service tutorial and a more complex multi-operation API example. - URL: https://developer.ibm.com/components/cics/ → Chapter 14 Further Reading
IBM CICS Performance Analyzer (CICS PA)
IBM's primary tool for CICS performance analysis. Processes SMF 110 records and produces reports on transaction performance, resource utilization, and exception conditions. Supports historical trending and cross-region comparison. → Chapter 17 Further Reading
IBM CICS Security Verification Tool
Automates the verification of CICS security configurations against best practices. Available as a SupportPac. - **IBM zSecure Admin** (formerly Consul zAdmin) — RACF administration tool that simplifies RACF profile management, auditing, and compliance reporting for CICS and other z/OS subsystems. - → Chapter 16 Further Reading
IBM Data Studio
Free IDE for working with DB2 on z/OS, including stored procedure development for API-based data access. → Chapter 22 Further Reading
IBM Developer — CICS
Code patterns, tutorials, and API documentation for CICS TS. Particularly useful for Liberty JVM server integration (relevant to the SecureFirst case study). - URL: https://developer.ibm.com/components/cics/ → Chapter 13 Further Reading
IBM MQ and CICS Integration Patterns (SG24-8374)
Covers MQ as a 2PC participant in CICS transactions, MQ connection recovery, and shared queue architectures. The shared queue chapters are directly relevant to the Pinnacle Health corrective action (MQ shared queues for cross-LPAR indoubt resolution). → Chapter 18 Further Reading
IBM MQ for z/OS Programming Guide
Covers the MQPUT, MQGET, and MQOPEN calls used in the COBOL examples in section 22.3. The chapters on publish/subscribe and message properties are essential for implementing content-based routing and topic hierarchies. - **IBM MQ for z/OS System Administration** — Queue manager configuration, channe → Chapter 22 Further Reading
IBM OMEGAMON for CICS
Real-time CICS monitoring tool that provides graphical dashboards for task counts, storage usage, dispatcher performance, and DB2 connection health. Supports automated alerts based on customizable thresholds. → Chapter 17 Further Reading
IBM OMEGAMON for DB2 Performance Expert
Real-time and historical DB2 performance monitoring including thread-level analysis, lock contention detection, and parallelism monitoring. Essential for production parallel batch DB2 workloads. → Chapter 25 Further Reading
IBM Support — CICS Recovery APARs
Search for APARs related to CICS recovery to stay current on known issues and fixes. Recovery-related APARs are among the most critical to apply promptly. - URL: https://www.ibm.com/support/pages/cics-transaction-server → Chapter 18 Further Reading
IBM Support: DFSORT FAQ
Frequently asked questions about DFSORT including MERGE syntax, OUTFIL for multiple outputs, ICETOOL patterns, and hiperspace configuration. A practical quick-reference for the sort parallelism techniques in this chapter. → Chapter 25 Further Reading
IBM Systems Magazine (archived)
formerly IBM Systems Magazine, now IBM Z and LinuxONE Community Published technical articles on Parallel Sysplex architecture, WLM tuning, and DB2 data sharing. The archives contain decades of practitioner-written content. Search for articles by Frank Kyne (Sysplex), John Campbell (WLM), and Chris C → Chapter 1 Further Reading: The z/OS Ecosystem
IBM TechU — API Economy Sessions
IBM's technical conference includes sessions on API exposure from z/OS, including live demonstrations of CICS REST service creation and z/OS Connect EE configuration. → Chapter 14 Further Reading
IBM TechU — CICS Advanced Recovery Sessions
Deep-dive sessions on CICS recovery internals, two-phase commit optimization, and Sysplex-aware recovery features. IBM CICS Level 3 support engineers often present, providing insight into common recovery problems they see across their customer base. → Chapter 18 Further Reading
IBM TechU — CICS Deep Dive Sessions
IBM's technical conference includes multi-hour deep dives on CICS internals, including dispatcher mechanics, storage management, and DB2 connection architecture. The "CICS Performance for Architects" track is particularly relevant to this chapter. → Chapter 17 Further Reading
IBM Z and LinuxONE Community
https://community.ibm.com/community/user/ibmz-and-linuxone/home IBM's community platform for z/OS practitioners. Discussion forums, blogs, and technical content from IBM staff and experienced users. → Chapter 1 Further Reading: The z/OS Ecosystem
IBM Z Content Solutions: z/OS Batch Modernization
IBM's curated collection of articles, Redbooks, and tutorials on modern batch processing patterns including parallel execution, container-based batch, and integration with cloud schedulers. → Chapter 25 Further Reading
IBM Z Security Community
https://community.ibm.com/community/user/ibmz-and-linuxone/communities/community-home?communitykey=5e427e50-2f98-4cb4-abe7-ece6fdd1c0e4 IBM's community for z/OS security practitioners. Discussion forums, blog posts, and technical articles on RACF, ICSF, AT-TLS, and compliance topics. → Chapter 28 Further Reading: Mainframe Security for COBOL Developers
IBM Z Software Pricing Reference
IBM's official documentation of MLC and sub-capacity pricing mechanics. Updated periodically. Understanding the SCRT calculation and R4HA mechanics described in Section 29.5 requires familiarity with this document. - **IBM Tailored Fit Pricing for z/OS** — IBM's documentation of TFP/ECS and Enterpri → Further Reading — Chapter 29
IBM z/OS Connect Documentation
Getting Started guide (ACL implementation) 3. **IBM MQ Kafka Connector Documentation** (event mesh implementation) 4. **IBM InfoSphere Data Replication Documentation** (CDC implementation) 5. **"Site Reliability Engineering" (Google)** — Chapter 6 (monitoring golden signals) 6. **IBM Redbook: Accele → Chapter 37 Further Reading: The Hybrid Architecture
IBM z/OS Connect EE Documentation
The complete reference for z/OS Connect EE installation, configuration, and administration. Start with the "Getting Started" section, then read "Creating APIs and services" for the hands-on workflow. Available at the IBM Documentation site under z/OS Connect EE. - **z/OS Connect EE API Toolkit User → Chapter 21: Further Reading
Strategic overview of exposing mainframe capabilities as APIs, including business case analysis, architecture patterns, and implementation approaches. Useful for making the case to management. → Chapter 22 Further Reading
IBM. "IBM InfoSphere Data Replication for z/OS"
Product documentation for IBM's log-based CDC solution. Covers DB2 log reading, change capture configuration, and replication topology options (unidirectional, bidirectional, fan-out). → Chapter 22 Further Reading
IBM. "z/OS Unicode Services"
Documentation for z/OS Unicode conversion services, including support for UTF-8, UTF-16, and various EBCDIC code pages. Relevant for modern API-based integration where UTF-8 is the standard. → Chapter 22 Further Reading
Identification Section (all subtypes):
Job name, job number, JES job ID - Step name and program name - System ID (critical in sysplex environments) - Job class and service class - Start time and date, end time and date - Completion code (condition code, abend code, or system abend) → Chapter 27: Batch Monitoring, Alerting, and Incident Response
idug.org
IDUG's technical library contains thousands of presentations from DB2 practitioners. Search for "optimizer," "access path," and "EXPLAIN" for directly relevant content. The annual North American and European conferences include hands-on labs for EXPLAIN interpretation. → Chapter 6 Further Reading: DB2 Optimizer Internals
Elapsed time: 2:47 (unchanged from pre-checkpoint; the 4-minute overhead was offset by the better commit behavior reducing lock contention) - Recovery time on restart: tested at 4 minutes (vs. 6+ hours previously) - Online system impact: zero timeouts (down from occasional timeouts caused by the lon → Case Study 1: CNB's Checkpoint/Restart Redesign After the Six-Hour Batch Rerun
IBM MQ on Amazon ECS (containerized queue manager): `SFCLOUD01` - Inbound queue: `SF.NOTIFY.INBOUND` (receives messages from z/OS) - MQ Consumer: Java/Spring Boot application running on ECS, consuming from `SF.NOTIFY.INBOUND` - Amazon SNS: Distributes push notifications to iOS (APNs) and Android (FC → Case Study 2: SecureFirst's MQ-to-Cloud Bridge for Mobile Notifications
Incident response:
Define severity levels (P1-P4) with response time requirements - Runbook for common API incidents (gateway down, CICS region down, certificate expiry, rate limit storm) → Project Checkpoint 21: The API Layer
6 Azure VMs: Standard_E16s_v5 (16 vCPU, 128 GB RAM) running RHEL 8 - Micro Focus Enterprise Server licenses: 6 × 16-core = 96 cores licensed - Azure DevTest Labs for environment management (auto-shutdown, auto-startup) - Azure Managed Disks (Premium SSD) for VSAM-equivalent files - Azure Database fo → Case Study 2: Pinnacle Health's Hybrid Success — Dev/Test on Cloud, Production on Mainframe
Infrastructure investment:
Raleigh data center: two z14 LPARs (CNBDR01, CNBDR02) with 60% of Charlotte's processing capacity - Storage: IBM DS8880 with 47 TB of mirrored DASD - Network: four 16 Gbps FICON links between Charlotte and Raleigh (43 km), diverse path routing through two separate fiber providers - GDPS/Metro Mirror → Case Study 1: Continental National Bank's DR Architecture and Annual Test
Infrastructure:
Two IBM z16 Model A01 frames (production + DR) - Parallel Sysplex: CNBPLEX with four LPARs (CNBPROD1-4) - Coupling Facility: Two CF LPARs (primary + alternate) on each frame - DB2 13 for z/OS, data sharing group DB2A with four members - CICS TS 5.6: 30 CICS regions across all LPARs (TORs, AORs, FORs → Index
The history of CICS architecture is a 50-year lesson in the same principle that drives microservices: decompose monoliths into specialized, isolated components. The mainframe community was doing this in the 1980s. The patterns are identical; only the vocabulary differs. → Chapter 13: CICS Architecture for Architects
Nightly batch extract for regulatory reporting data (Pattern 1) - CDC for analytics data warehouse and fraud model data (Pattern 2) - z/OS Connect APIs for mobile banking (Pattern 3) - MQ bridge for fraud scoring (mainframe sends transaction event to cloud ML model, receives score back) → Index
Integrity Controls (164.312(c)):
RACF dataset profiles preventing unauthorized modification - DB2 referential integrity and check constraints - Application-level validation in COBOL programs → Index
Interest Calculation
Score: 18. Single access path (nightly batch), but high data intensity and used by regulatory reporting. Move the calculation formula to a scalar UDF so both the batch program and reporting can use it. The batch program calls the UDF inline in an UPDATE statement. → Chapter 10: Stored Procedures and User-Defined Functions in COBOL
The international standard for financial electronic data interchange. The pain.001 (customer credit transfer) and pacs.008 (interbank credit transfer) message types are referenced in Case Study 2. - URL: https://www.iso20022.org → Chapter 14 Further Reading
ISO 8601: Date and Time Format
The standard your APIs and file exports should use for date representation. Eliminates the ambiguity of MMDDYYYY versus DDMMYYYY versus YYYYMMDD. → Chapter 22 Further Reading
ITIL v4: Service Operation
The ITIL framework for IT service management includes Event Management and Incident Management processes that directly align with z/OS operational automation. Understanding ITIL terminology helps communicate automation value to management. → Further Reading — Chapter 31: Operational Automation
J
JESMSGLG
System messages, including security (RACF) failures 2. **JESJCL** — Expanded JCL (with all symbolics resolved and procs expanded) 3. **JESYSMSG** — Allocation messages (look for IEF244I, IEF272I, IEF285I) 4. **Step condition codes** — In JESMSGLG, look for IEF142I messages 5. **SYSPRINT** — Program- → Appendix B: JCL Quick Reference
Four parallel jobs, each running program ACCTPROC with its partition number in the PARM. Each job reads its partition input file, accesses DB2, and writes a partition output file. → Chapter 25 Exercises: Parallel Batch Processing
JSON Schema
Standard for defining JSON document structure. Useful for formalizing your canonical data model and validating API request/response payloads. → Chapter 22 Further Reading
**Distance:** Because replication is asynchronous, XRC can operate over any distance — continental or intercontinental. There's no speed-of-light latency penalty on application I/O. - **Performance:** Zero impact on primary site write latency. The application writes to local DASD at local speed. Rep → Index
Key constraints:
**Distance:** Metro Mirror is synchronous, meaning every write must complete on both the primary and secondary storage before the application receives confirmation. The speed of light imposes a hard limit: at 300 km of fiber, round-trip latency is approximately 2 milliseconds. Most deployments keep → Index
Key decisions:
SCHABKHI gets Continuous availability because the transaction journal and CICS-accessed VSAM files must survive a single volume failure without outage. - Batch datasets don't need guaranteed space — they can wait for space constraint relief or extend to another volume. → Project Checkpoint: HA Banking System — Dataset Naming, SMS Classes, and GDG Strategy
Key design choices:
**Group buffer pool sizing:** Kwame worked with Lisa Tran to size the group buffer pools (GBPs) based on the expected cross-invalidation rate. For heavily updated tables (like the ACCOUNTS table), a larger GBP was allocated to reduce castout frequency. Initial sizing: 8 GB total GBP space in the cou → Case Study 1: Continental National Bank's Parallel Sysplex Migration
Key design decisions:
**SCPRODHI gets Continuous availability**: If the primary volume is unavailable, z/OS automatically fails over to a duplex copy. This is essential for CICS — a volume failure shouldn't take down online banking. - **SCBATCHCR vs. SCBATCHSTD**: Not all batch is equal. The transaction extract and GL re → Case Study 1: Continental National Bank's Dataset Management Strategy
Key disadvantages:
**RPO > 0:** You will lose the transactions that were committed at the primary site but hadn't yet been replicated to the secondary. In practice, this is seconds of data, but "seconds" can mean hundreds of transactions at a high-volume site. - **Consistency window:** The consistency group timestamp → Index
Key implementation considerations:
**Event schema versioning.** Events emitted from COBOL programs will evolve as the COBOL programs change. Use a schema registry (Confluent Schema Registry or similar) with backward-compatible schema evolution. The ACL layer handles translation between COBOL data layouts and the event schema. → Index
Key implementation details:
**Orchestration vs. Choreography.** In orchestration, a central saga orchestrator (typically a cloud-based workflow engine like AWS Step Functions or a custom orchestrator) coordinates the steps. In choreography, each step emits an event that triggers the next step. For hybrid COBOL-cloud sagas, *or → Index
Key management rules:
Master keys: dual control, annual rotation - Data encryption keys: ICSF CKDS, quarterly rotation, RACF CSFKEYS protection - TLS certificates: RACF keyrings, annual renewal - Never embed keys in COBOL source or copybooks → Chapter 28 Key Takeaways: Mainframe Security for COBOL Developers
Key People:
**Kwame Mensah:** Chief Systems Architect, 30 years on the platform. Started as a COBOL programmer in 1996, moved through systems programming, DB2 administration, and CICS systems programming before becoming architect. Kwame thinks in subsystem interactions. His mantra: "Show me the address spaces." → Index
Key reference points:
SecureFirst TCPIPSERVICE: Port 8443, MAXPERSIST(120), SOCKETCLOSE(00,00,30) - SecureFirst pipeline: JSON provider pipeline with DFHJSON handler - SecureFirst wrapper pattern: Thin COBOL wrapper + EXEC CICS LINK to legacy program - SecureFirst external call pattern: 3-second timeout, DB2 cache fallba → Project Checkpoint: Web Service Interfaces
Key services:
`beneficiary-inquiry` — Full beneficiary demographics and enrollment - `benefit-calculation` — Current benefit amounts and calculation details - `payment-history` — Payment records for a specified date range - `eligibility-check` — Real-time eligibility determination - `enrollment-status` — Current → Case Study 2: Federal Benefits' API Modernization for Inter-Agency Data Sharing
Key Terms:
Address space - Dispatching priority - JES2/JES3 - System services (SVC) - Program Properties Table (PPT) - Initiator - Authorized Program Facility (APF) - z/OS Sysplex → Advanced COBOL Programming — Complete Textbook Outline
https://docs.konghq.com Documentation for the Kong API gateway used in CNB's reference architecture. Covers routing, authentication plugins, rate limiting, and analytics. → Chapter 37 Further Reading: The Hybrid Architecture
L
L8 TCBs
For programs defined as CONCURRENCY(THREADSAFE). These run on open TCBs that operate concurrently with the QR TCB. A THREADSAFE program making a DB2 call runs on an L8 TCB; the DB2 call executes without blocking the QR TCB. This is the single most impactful performance optimization available in mode → Chapter 17: CICS Performance and Tuning
IBM's processor benchmark data, published for each hardware generation. This is the source for MSU/MIPS ratings and cross-generation performance comparisons. Available through IBM's Z systems performance website. - **IT Financial Management** by Maxime Sottini (Van Haren Publishing, 2012) — Covers I → Further Reading — Chapter 29
Learning Path Annotations:
🏃 **Fast Track:** If you're an experienced systems programmer moving into architecture, focus on Sections 1.4 and 1.5 — you already know the batch and online paths. The Sysplex architecture and system services sections are where architects separate from programmers. - 🔬 **Deep Dive:** If z/OS intern → Index
Legal authority
A specific section of federal law authorizing the data exchange - **Data sharing agreement (DSA)** — A formal document specifying what data could be shared, with whom, for what purpose, and under what restrictions - **Technical implementation** — Ranging from encrypted FTP drops to SFTP batch transf → Case Study 2: Federal Benefits' API Modernization for Inter-Agency Data Sharing
Level 1 — Console Automation Rules:
Capture all abend messages for batch jobs in the HABK* job name prefix - Automatically restart eligible jobs (per the restart table) - Hold downstream dependents when a critical job fails - Alert the on-call team for Tier 1 events → Chapter 27: Batch Monitoring, Alerting, and Incident Response
Number of production LPARs: _______________ - Can N-1 LPARs handle full workload? _______________ - Normal per-LPAR utilization (to leave headroom): _______________ - Recovery mechanism: _______________ - RTO: _______________ → Project Checkpoint 30: DR Design for the HA Banking System
Number of CFs: _______________ - Which structures are duplexed? _______________ - Which structures are NOT duplexed (and why)? _______________ - Recovery mechanism: _______________ - RTO: _______________ → Project Checkpoint 30: DR Design for the HA Banking System
Reference for Liberty features available in CICS: cicsts:link-1.0 (COBOL invocation), cicsts:security-1.0 (RACF integration), and cicsts:jndi-1.0 (resource lookup). → Chapter 14 Further Reading
KEYINTV=60 → maximum 60 seconds of log records to scan - Transaction volume: ~3,200 TPS with 3 records per transaction → ~576,000 records in 60 seconds - Actual records between last keypoint and failure: 487,319 records (52.3 seconds of activity) - Log scan rate: ~65,000 records/second - **Log scan → Case Study 1: CNB's CICS Region Failure and Recovery
Chapter 14 takes you from architecture to implementation. You'll define CSD resources, configure SIT parameters, establish MRO connections, and bring up a multi-region topology. The design you created in this chapter's project checkpoint becomes the blueprint you build from. → Chapter 13: CICS Architecture for Architects
the platform that processes 95% of ATM transactions, runs the core systems of every Fortune 100 bank, and has maintained continuous availability through half a century of technological change. The z/Architecture is the most reliable, secure, and high-throughput general-purpose computing platform eve → Acknowledgments
Mainframe Security: Protecting Your Environment
IBM Redbook SG24-6803 Covers z/OS security architecture, RACF configuration, and compliance from a practitioner perspective. The chapters on RACF health checks and security configuration best practices complement this chapter's content. *Available at:* IBM Redbooks (https://www.redbooks.ibm.com/) → Chapter 28 Further Reading: Mainframe Security for COBOL Developers
Are you getting the matching columns you designed for? 2. **ACCESSTYPE** — Is DB2 using your index or scanning? 3. **PREFETCH** — 'S' (sequential) is normal; 'L' (list) suggests poor clustering 4. **COST_CATEGORY** — 'B' means default statistics — run RUNSTATS immediately 5. **CLUSTERRATIO** — Below → Chapter 6: DB2 Optimizer Internals
MAXACTIVE
Maximum concurrent tasks in this class. When reached, new tasks in this class queue. - **PURGETHRESH** — If set to a number, CICS purges tasks in this class when the queue depth reaches the threshold. Set to NO to queue indefinitely (up to MAXT overall). → Chapter 17: CICS Performance and Tuning
Merge scan join is not inherently bad
it's optimal when both tables are large and no useful index exists. But when you can restructure the query to make nested loop viable (through better indexing or query consolidation), nested loop with a good index often wins. → Case Study 2: Pinnacle Health's Claims Query Optimization
acquire late, commit early, don't hold locks during non-DB2 work. - **Use the minimum necessary isolation level** — each step up holds more locks longer. - **Handle -911 and -913 in every program** — retry with full re-read of data (the entire UOW was rolled back). → Chapter 8 Key Takeaways
2 LPARs (minimum for hardware failure survival) - 2+ TORs (one per LPAR minimum, more if channel separation is needed) - 4+ AORs (active/active pairs, at least one pair per primary channel) - 1+ FOR (if VSAM is used; optional if all data is in DB2 with data sharing) - 2 CMASs (one per LPAR for CPSM → Project Checkpoint: CICS Region Topology Design
Misconceptions to surface:
"Mainframes are just old servers." Clarify the architectural differences (I/O channels, SYSPLEXes, specialized processors). - "Nobody writes new mainframe code." Show examples of recent z/OS features and modern COBOL toolchains. - "Cloud will replace mainframes." Discuss hybrid strategies and why la → Teaching Notes: Chapter 1 — z/OS Ecosystem
MLC vs. WLC Pricing
Monthly License Charge (MLC) software pricing is based on the rolling four-hour average of the highest CPU utilization in a month (R4HA). This means a single batch job that spikes CPU at 3 AM on one Saturday can increase your software bill for the entire month. Architects must design workloads with → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
Mobile banking app
connects via CTG, serves 50,000 end users 2. **Online banking portal** — connects via CICS web services, serves 200,000 users 3. **Third-party API gateway** — connects via REST API, serves 100 partner organizations → Project Checkpoint: HA Banking System — CICS Security Architecture
The procedure can execute INSERT, UPDATE, DELETE. Options are NO SQL, CONTAINS SQL, READS SQL DATA, and MODIFIES SQL DATA. Be honest — if you say READS SQL DATA and then execute an UPDATE, you'll get SQLCODE -577. → Chapter 10: Stored Procedures and User-Defined Functions in COBOL
[ ] SMF Type 30 performance baseline for all critical-path jobs - [ ] Performance dashboard reviewed daily - [ ] Trend analysis reviewed weekly - [ ] Quarterly performance review for critical-path jobs - [ ] Performance checklist for all new batch programs before production → Chapter 26: Key Takeaways
Month 1-2: Infrastructure.
z/OS Connect EE deployed on both production LPARs - API Connect deployed in the FBA's secure cloud enclave (FedRAMP High) - mTLS infrastructure: FBA certificate authority established, pilot agency certificates issued - Network paths: dedicated VPN tunnels to each pilot agency's network → Case Study 2: Federal Benefits' API Modernization for Inter-Agency Data Sharing
Month 2–3 (November–December): Business Input.
Meet with business unit leaders to gather growth projections (account growth, transaction volume, new products) - Meet with application teams to gather the capacity events calendar (new deployments, migrations, retirements, DB2 changes) - Meet with the modernization team to understand planned platfo → Chapter 29: Capacity Planning and Growth Management
Month 3-4: API development.
Five internal services built on z/OS Connect (the services listed in Tier 1) - Three agency-specific APIs designed, reviewed, and approved by each agency's technical team and privacy officer - Response transformation policies implemented in API Connect - Audit logging framework deployed → Case Study 2: Federal Benefits' API Modernization for Inter-Agency Data Sharing
Month 4 (January): Review and Approval.
Present the capacity plan to IT leadership and finance - Obtain budget approval for planned capacity investments - Secure Capacity on Demand authorizations for seasonal peaks - Publish the plan and distribute to operations, application teams, and business units → Chapter 29: Capacity Planning and Growth Management
writes the event to an MQ queue (most common for z/OS integration) - **HTTP adapter** — posts the event to an HTTP endpoint (for distributed consumers) - **TS Queue adapter** — writes to a CICS temporary storage queue (for debugging) - **Custom adapter** — your own COBOL program that receives the ev → Chapter 20: Event-Driven Architecture with COBOL — MQ Triggers, CICS Events, and Pub/Sub Patterns
Framework for organizing APIs into system, process, and experience layers. While vendor-specific in implementation, the three-layer model maps well to the mainframe architecture: system APIs (z/OS Connect), process APIs (gateway), and experience APIs (consumer-facing). - **Postman: "2024 State of th → Chapter 21: Further Reading
Multi-channel notification
email, SMS, and mobile app push notifications to members 3. **Provider portal updates** — real-time status visible to healthcare providers 4. **Customer service dashboard** — representatives see real-time status without calling the batch team 5. **No modifications to the adjudication engine** — all → Case Study 2: Pinnacle Health's Claims Status Notification System
MVS JCL Reference
IBM Publication SA23-1385 While JCL is covered in your prerequisite knowledge, the reference manual's chapter on dataset disposition (DISP parameter) is worth reviewing in light of the GRS and Sysplex serialization discussion in this chapter. → Chapter 1 Further Reading: The z/OS Ecosystem
N
Native JSON handling
No WSBIND files, no assistants. Java code handles JSON serialization/deserialization with standard libraries (Jackson, Gson). - **JAX-RS annotations** — Standard REST API development with `@GET`, `@POST`, `@Path`, `@QueryParam`. - **Connection pooling** — Liberty's thread pool handles connection con → Chapter 14: CICS Web Services
written entirely in SQL PL, compiled by DB2 into a package. No COBOL involved. 2. **External stored procedures** — written in a host language (COBOL, PL/I, C, Java), compiled by the language compiler, and called by DB2 at runtime. → Chapter 10: Stored Procedures and User-Defined Functions in COBOL
commit frequency is an architecture decision - **DISP=SHR unless you genuinely need exclusive access** — unnecessary DISP=OLD creates Sysplex serialization bottlenecks - **Every address space is a failure domain** — design for the failure of any single component - **WLM classification is invisible t → Chapter 1 Key Takeaways: The z/OS Ecosystem
Never run AORs or FORs with SEC=NO
internal regions are where privilege escalation succeeds - **XDFTRAN=YES without a restrictive default profile is an open door** — undefined transactions will be allowed - **TSQ security is often overlooked** — TSQs frequently hold sensitive data during multi-screen transactions - **Certificate expi → Chapter 16 Key Takeaways
Nightly Batch Extract
CNB's regulatory reporting data replicated to S3 at 01:00 for the cloud reporting batch at 02:30. (2) **Change Data Capture (CDC)** — Pinnacle Health's claims status table replicated from mainframe DB2 to Azure PostgreSQL with 8-15 second lag for fraud detection models. (3) **API Real-Time** — Secur → Chapter 34 Quiz: COBOL-to-Cloud Patterns
NIST SP 800-53 Rev5: Security and Privacy Controls
The comprehensive catalog of security controls. Map CICS security features to NIST controls for a framework-agnostic security architecture. - **CIS Benchmarks for z/OS** — The Center for Internet Security publishes hardening benchmarks for z/OS that include RACF and CICS security configuration basel → Chapter 16 Further Reading
the date validation is pure computation with no database access. These attributes let the optimizer cache results and potentially parallelize execution. For a UDF that is called millions of times in a batch with many duplicate date values, the caching of DETERMINISTIC results can reduce invocations → Chapter 10: Stored Procedures and User-Defined Functions in COBOL
This procedure may return different results for the same input (because account data changes). If a procedure always returns the same result for the same input, mark it DETERMINISTIC so the optimizer can cache results. → Chapter 10: Stored Procedures and User-Defined Functions in COBOL
OCC: 30 days advance notice (regulatory requirement for Tier-1 bank DR test) - ATM network (STAR/Pulse): 14 days advance notice - Wire transfer networks (Fedwire, SWIFT): 14 days advance notice - Customer notification: None (test during low-volume window, no expected customer impact) - Board of dire → Case Study 1: Continental National Bank's DR Architecture and Annual Test
Aggregate spending by program, demographic category, and geographic region. Fixed-width ASCII format, SFTP delivery. - **Government Accountability Office (GAO)** — Individual-level transaction records for sampled beneficiaries (approximately 420,000 per quarter). XML format, Connect:Direct delivery. → Case Study 2: Federal Benefits' Regulatory Reporting Pipeline
On AWS:
Regulatory reporting batch (the 47-program suite that started this journey) - Dev/test environments (3 environments, 8 developers) - Analytics data warehouse (Aurora PostgreSQL replica, CDC-fed) - Mobile banking API gateway (API Gateway → z/OS Connect over Direct Connect) - ML fraud model training ( → Index
On z/OS (Parallel Sysplex):
All CICS OLTP (account inquiry, fund transfer, ATM authorization, wire transfer) - Core batch processing (nightly posting, interest calculation, GL balancing) - DB2 system of record (accounts, transactions, balances) - MQ messaging hub (inter-system communication) - Real-time fraud scoring (CICS pro → Index
On z/OS:
Queue manager: `SFPQM01` (SecureFirst Production Queue Manager 01) - Outbound notification queue: `SF.NOTIFY.OUTBOUND` (local queue, persistent, triggered) - Sender channel: `SFPQM01.TO.SFCLOUD` — TLS-encrypted, connected to the cloud-side MQ instance - Transmission queue: `SFPQM01.TO.SFCLOUD.XMIT` → Case Study 2: SecureFirst's MQ-to-Cloud Bridge for Mobile Notifications
https://www.openmainframeproject.org The Linux Foundation's Open Mainframe Project publishes open-source tools and best practices for mainframe modernization. The Zowe project (open-source z/OS interface framework) and COBOL Programming Course are relevant community resources. → Chapter 37 Further Reading: The Hybrid Architecture
OpenAPI Specification 3.0
The standard for REST API documentation. z/OS Connect EE generates OpenAPI specs from COBOL copybooks. Understanding OpenAPI helps you review and customize generated API documentation. - URL: https://spec.openapis.org/oas/v3.0.3 → Chapter 14 Further Reading
OpenAPI Specification 3.0.3
The version most widely supported by tools and recommended for new mainframe API projects. - **JSON Schema (2020-12)** — The schema language used within OpenAPI for defining request/response structures. Understanding JSON Schema is essential for accurately representing COBOL data types. - **RFC 6749 → Chapter 21: Further Reading
OpenAPI Specification 3.1
The latest version, which aligns JSON Schema support with JSON Schema 2020-12. If your organization is adopting 3.1, note the changes to `nullable` handling and discriminator behavior. - **Swagger Editor** (editor.swagger.io) — Online tool for writing and validating OpenAPI specifications. Useful fo → Chapter 21: Further Reading
Opening — 10 min
Ask how many students have used an ATM, booked a flight, or filed insurance this week. Reveal that mainframes processed those transactions. Establish relevance. 2. **z/OS history and design philosophy — 20 min** — Cover backward compatibility, workload isolation, and hardware/software co-design. Emp → Teaching Notes: Chapter 1 — z/OS Ecosystem
Opening — 15 min
Present the capstone project options and requirements. Explain grading criteria: technical depth (40%), architectural reasoning (30%), communication quality (20%), and feasibility/realism (10%). Show exemplar projects from prior cohorts (or create sample descriptions). 2. **Scoping workshop — 20 min → Teaching Notes: Chapter 38 — Capstone
Create a new copybook with names designed for JSON mapping, and write a thin wrapper COBOL program that copies data between the legacy copybook and the wrapper. This is more work but gives you complete control over the API contract without touching the legacy program. → Chapter 14: CICS Web Services
Three retirements create urgency for knowledge capture — specific strategies (pair programming, documentation, video walkthroughs) mentioned - Workforce strategy includes hiring junior developers, partnering with community college programs, and cross-training existing team on modern tooling - Politi → Sample Final Exam
Syntax validation, object resolution 2. **Semantic check** — Authorization, data type compatibility 3. **Query rewrite** — Predicate pushdown, subquery transformation, view merge 4. **Access path selection** — This is where the optimizer lives 5. **Code generation** — Build the executable section → Chapter 6: DB2 Optimizer Internals
Payment calculation
"If payments are late, we make national news." 2. **Eligibility determination** — "If eligibility is wrong, payments are wrong." 3. **OPM regulatory reporting** — "Hard 10:00 AM deadline, fines for late filing." 4. **Enrollment processing** — "Must complete daily or call center cannot function." 5. → Case Study 2: Federal Benefits Administration — When Every Batch Job Thinks It Is Critical
PDSLIB
Points to the PDS containing the COBOL copybook - **REQMEM / RESPMEM** — The 01-level names for request and response data structures - **PGMINT=COMMAREA** — The program interface. Use COMMAREA for existing programs that use COMMAREA, or CHANNEL for programs that use channels/containers - **MAPPING-L → Chapter 14: CICS Web Services
Excellent sequential prefetch utilization (32-page or 64-page reads) - Predictable elapsed time proportional to tablespace size - CPU cost for evaluating predicates on every row → Chapter 6: DB2 Optimizer Internals
Performance depends on:
MATCHCOLS (more matching = narrower search = fewer leaf pages scanned) - CLUSTERRATIO/CLUSTERED (determines whether base table access is sequential or random) - Number of qualifying rows (each non-index-only row requires a base table page fetch) - Buffer pool hit ratio (higher hit ratio reduces phys → Chapter 6: DB2 Optimizer Internals
Performance model
Given the following assumptions (500 API calls/second peak, 200ms average backend response time, 10% write operations), calculate the required z/OS Connect capacity (instances, connection pool sizes, thread pool sizes) and the expected mainframe CPU impact. → Project Checkpoint 21: The API Layer
Wrap the existing BALINQ CICS transaction as a REST web service using z/OS Connect (you built this in Chapter 21's project checkpoint) - Deploy an API gateway (Kong on OpenShift or AWS API Gateway) - Set up CDC from DB2 z/OS to PostgreSQL on the target platform - Define the API contract (OpenAPI 3.0 → Kong API Gateway — Balance Inquiry Strangler Fig Routing
What immediate actions address the batch window crisis and the security audit findings? - How do you begin knowledge transfer before the three retirements? → Sample Final Exam
Implement the balance-inquiry microservice in the target language/platform - Use BigDecimal (or equivalent packed decimal) for all monetary calculations - Implement the same COMMAREA-equivalent contract as the CICS service - Unit test against the BALINQ copybook's field specifications - Integration → Kong API Gateway — Balance Inquiry Strangler Fig Routing
Phase 1: Declaration (0-5 minutes)
Confirm site failure (not just a network issue that makes the primary appear down) - Declare disaster — this is a management decision, not a technical one - Activate the DR command center (conference bridge, war room) → Index
Phase 1: Detection (0-15 minutes)
Security monitoring tool generates alert - On-call security analyst validates the alert (true positive vs. false positive) - If true positive: declare incident, assign severity level → Index
Phase 2 (Months 7-12): Expose and Extend
How do you deliver the web portal within the 18-month mandate without rewriting the backend? - What integration architecture connects the web tier to the mainframe? → Sample Final Exam
Severity 1 (active data exfiltration): RACF ALTUSER REVOKE the compromised userid immediately - Severity 2 (unauthorized access attempt): increase monitoring, do not revoke yet (preserve evidence) - Severity 3 (policy violation): document and investigate during business hours → Index
GDPS controlling system at DR site takes control - Metro Mirror pairs are broken; DR volumes become primary - DR site LPARs are IPLed - Subsystems started in dependency order: TCP/IP → DB2 → CICS → MQ → batch → Index
Phase 2: Shadow Mode (Weeks 11-14)
Deploy the modern service alongside the legacy - Configure the facade to shadow all balance-inquiry traffic to the modern service - Run the comparison engine, targeting 99.99% financial field match - Investigate and fix all discrepancies - Minimum duration: cover one full month-end cycle → Kong API Gateway — Balance Inquiry Strangler Fig Routing
Phase 3 (Months 13-24): Optimize and Sustain
How do you introduce CI/CD and automated testing for a team that has never used either? - What is your long-term workforce strategy? → Sample Final Exam
Ring 0: Internal users, 2 weeks - Ring 1: 5% of external users (lowest balances), 1 week - Ring 2: 25%, 2 weeks - Ring 3: 50%, 2 weeks (with comparison logging) - Rollback triggers defined and tested → Kong API Gateway — Balance Inquiry Strangler Fig Routing
Phase 3: Investigation (1-24 hours)
Collect SMF type 80 records for the affected period - Collect CICS journal records for affected transactions - Collect DB2 audit trace for affected tables - Reconstruct the sequence of events - Determine scope: what data was accessed or compromised? → Index
Run validation transactions against each critical subsystem - Verify data currency (last transaction timestamp on DR matches expected) - Verify external connectivity (ATM network, wire transfer network, internet banking) - Declare DR site operational → Index
Remove the vulnerability that enabled the incident - Rotate any compromised credentials or keys - Apply patches or configuration changes - Verify through security scan → Index
100% of traffic to modern service - Legacy CICS BALINQ on standby (still receiving shadow traffic for comparison) - CDC pipeline continues (other services still use DB2 master) → Kong API Gateway — Balance Inquiry Strangler Fig Routing
Phase 4: Stabilization (40 minutes - 4 hours)
Resume batch processing (assess which jobs need restart from checkpoint) - Verify regulatory reporting capability - Test all critical interfaces (ACH, Fedwire, SWIFT) - Capacity assessment — DR site may run at reduced capacity → Index
Phase 5: Decommission (Week 24 + 90 days)
After 90 days of standby with no issues, decommission the CICS BALINQ program - Archive source code and COMMAREA copybook - Update CSD, RACF profiles, and documentation - Remove the z/OS Connect service definition for balance inquiry - Celebrate — but quietly, because fund transfer is next → Kong API Gateway — Balance Inquiry Strangler Fig Routing
Restore normal operations - Re-enable any revoked access (with corrected permissions) - Increase monitoring for 30 days post-incident → Index
Phase 6: Lessons Learned (within 2 weeks)
Post-incident review with all stakeholders - Update security controls, monitoring rules, or procedures - Update the incident response plan itself → Index
A health insurance consortium running a claims adjudication engine that processes 50 million claims per month. Pinnacle's systems demonstrate batch/online integration at scale: real-time eligibility checking against a batch-processed claims pipeline, complex DB2 queries across normalized and denorma → Preface
Takes patient ID, plan year, and claim amount. Returns the deductible applied to this claim. Reads from DEDUCTIBLE_TRACKER and PLAN_DEDUCTIBLE_TABLE. This is the most complex function because it must account for the patient's year-to-date deductible consumption. → Case Study 2: Pinnacle Health's Claims Calculation UDFs
https://planetmainframe.com Industry news and technical articles about mainframe technology. Covers z/OS releases, IBM hardware announcements, and mainframe modernization strategies. → Chapter 1 Further Reading: The z/OS Ecosystem
Technical articles on DB2 performance, including practical guides to RUNSTATS scheduling, EXPLAIN interpretation, and plan regression prevention. Written by practitioners for practitioners. → Chapter 6 Further Reading: DB2 Optimizer Internals
PORTNUMBER
The TCP port. Use 8080 or higher for non-SSL, 8443 or 443 for SSL/TLS. At SecureFirst, the API gateway connects to CICS on port 8443 with TLS mutual authentication. - **PROTOCOL(HTTP)** — Tells CICS to parse inbound traffic as HTTP. The alternative is IIOP (CORBA), which you won't use for web servic → Chapter 14: CICS Web Services
Post-Processing Validation (after each major job):
Output record count within expected range of input - Output control totals reconcile with input (claims in = claims adjudicated + claims rejected + claims pended) - No orphaned records (every input record accounted for in output) - Output file characteristics match expected format → Case Study 2: Pinnacle Health's Automated Claims Pipeline Recovery
RACF IRRDBU00 output from the prior day's unload is available - SMF data for the full reporting period is on DASD (not migrated) - DB2 catalog tables have current statistics - Authorized user list was updated within the last 30 days (flag if stale) - Previous month's report is archived (for trend co → Case Study 2 — Pinnacle Health's Automated Compliance Reporting
Pre-Processing Validation (before each major job):
Input file record count within tolerance band - Control totals match trailer record - Sample validation of key fields (provider ID format, claim amount range, date validity) - Output space availability confirmed - All required reference files present and current → Case Study 2: Pinnacle Health's Automated Claims Pipeline Recovery
Pre-REBIND EXPLAIN comparison
mandatory for all packages. Diane Chen writes a COBOL comparison program (similar to Pinnacle's existing report programs) that reads PLAN_TABLE rows for the current and proposed package and produces a difference report. → Case Study 2: Pinnacle Health's Claims Processing Performance Crisis
Precompile
DB2 precompiler processes EXEC SQL statements, generates a DBRM and modified COBOL source. 2. **Compile** — Enterprise COBOL compiler produces an object module. 3. **Link-edit** — Linkage editor produces a load module. Place it in the STEPLIB of the WLM address space. 4. **BIND PACKAGE** — Bind the → Chapter 10: Stored Procedures and User-Defined Functions in COBOL
PREREQUISITE CHECK
This chapter requires solid understanding of CICS region topology and MRO (Chapter 13), DB2 locking and commit scope (Chapter 8), and z/OS system architecture (Chapter 1). If you don't understand what a syncpoint is, what a two-phase commit does, or how MRO connects regions, stop and review those ch → Chapter 18: CICS Failure and Recovery
Never write a COBOL program that loops without issuing a CICS command. A PERFORM VARYING loop that processes 100,000 records from a working storage table will hold the QR TCB for seconds. Every other transaction in the region starves. If you must process large in-memory data, insert periodic EXEC CI → Chapter 17: CICS Performance and Tuning
Production standard
batch update + CICS reads | | 3 | No VSAM integrity | Only with external serialization — **avoid** | | 4 | Buffer invalidation | Rarely used; VSAM RLS is the modern alternative | → Chapter 4 Key Takeaways — Quick Reference Card
Production statistics (first 3 months):
36,000 loan applications processed through the saga - 34,800 completed successfully (96.7%) - 1,040 rejected at credit check step (2.9%) — normal business rejection, no compensation needed - 140 failed at Step 4 (0.4%) — DB2 constraint violations, compensating transactions executed for Steps 1 - 20 → Case Study 2: SecureFirst's Production Hybrid — Two Years In
PRODUCTION WARNING
In textbook architectures, the three-way TOR/AOR/FOR split is clean. In production, you'll encounter hybrid regions, especially AORs that own some files directly. This is a pragmatic compromise — function shipping adds overhead, and for low-contention files accessed by a single AOR, the overhead isn → Chapter 13: CICS Architecture for Architects
Profile of CICS workloads that can work on cloud:
Transaction volume under 100 TPS (transactions per second) - Latency requirements above 50ms per transaction - No cross-region data sharing (no MRO/ISC between the cloud CICS and mainframe CICS) - No CICS event processing or business event integration - Standard CICS API usage (READ/WRITE/LINK/XCTL, → Index
PROGRESSIVE PROJECT
The HA Banking Transaction Processing System. In Chapter 1, you designed the Sysplex infrastructure. In Chapter 5, you defined WLM service classes. Now you design the CICS topology that will host the banking application. → Chapter 13: CICS Architecture for Architects
PROJECT CHECKPOINT
In Chapter 13, you designed your HA banking system's CICS region topology (TOR/AOR/FOR with MRO). In Chapter 15, you designed the channel/container architecture for the multi-step transfer transaction. In Chapter 16, you designed the CICS security model. Now you will tune that topology for performan → Chapter 17: CICS Performance and Tuning
routes to the AOR with the shortest task queue. Best for general-purpose workloads where transactions have similar resource requirements. - **Goal algorithm** — routes to the AOR most likely to meet a response-time target. Integrates with z/OS Workload Manager (WLM) service classes. This is what CNB → Chapter 13: CICS Architecture for Architects
Define at least four RACF user IDs for API consumer roles - For each: CICS transaction authority, VSAM file access, DB2 privileges - Document the SAFCredentialMapper configuration (OAuth scope to RACF user ID) - Explain least-privilege rationale for each role → Project Checkpoint 21: The API Layer
RACF resource security
The COBOL program accesses DB2 tables and VSAM files under the mapped user ID. RACF controls access at the table and dataset level. → Chapter 14: CICS Web Services
RACF transaction security
The CICS transaction associated with the URIMAP (e.g., AINQ) has a RACF profile. Only mapped user IDs with READ access to the transaction profile can execute the transaction. → Chapter 14: CICS Web Services
RACF user/group hierarchy
Define the complete group structure, user roles, and access levels 2. **Dataset security** — RACF profiles for all production datasets, with encryption designations 3. **DB2 security** — Connection control (DSNR), authorization model (GRANT/REVOKE), column-level encryption for sensitive data 4. **CI → Index
decisions across different technology domains and business areas 2. **Impact** — decisions that delivered measurable business value 3. **Judgment** — decisions where you chose the less obvious but ultimately better path 4. **Learning** — post-implementation reviews that show growth 5. **Communicatio → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
Define rate limit policies: - At least three consumer tiers (external partner, portal/mobile, internal service) - Requests per minute and burst limits for each tier - 429 response format with Retry-After header - Dynamic rate limiting triggers (if implementing the mainframe utilization-based approac → Project Checkpoint 21: The API Layer
Rationale:
Two physical frames provide hardware-level redundancy. A total frame failure (extremely rare but possible) leaves two LPARs running on the surviving frame. - Four LPARs provide capacity headroom. With all four active, each LPAR runs at approximately 45% CPU utilization at peak. If one LPAR fails, th → Case Study 1: Continental National Bank's Parallel Sysplex Migration
Read-heavy
reads transaction data, calculates aggregates, produces reports - **Tolerant of higher latency** — a report that takes 3 hours instead of 2 hours is acceptable - **Independent of CICS** — no online transaction dependencies during execution - **Produces output, doesn't mutate core data** — worst case → Index
Reading
Read broadly. Technical books, yes, but also books on organizational behavior, negotiation, systems thinking, and leadership. The architect's job is fundamentally interdisciplinary. Kwame maintains a reading list that alternates between technical books (one per quarter), business/strategy books (one → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
or indicates that the page is not in real storage (it's been paged out to auxiliary storage). 5. If the page is in real storage, DAT combines the real page frame address with the byte offset to produce a **real address**. The memory access completes. 6. If the page is *not* in real storage (a **page → Index
prevents U4038; captures optimizer improvements - **CEEUOPT over PARM** — CEEUOPT travels with the program; PARM can be lost - **TRAP(ON) always** — without it, no CEEDUMP, no diagnosis - **STORAGE(00,FE,00) everywhere** — 2-5% overhead catches real bugs - **RPTOPTS(ON) on first production run** — v → Chapter 3 Key Takeaways: Language Environment Internals
Recovery for common failures:
SMF data partially migrated: automated recall and retry (up to 60-minute wait) - DB2 timeout during extraction: retry with larger sort work area allocation - Cross-reference mismatch exceeds threshold (>5% unmatched): hold for human review rather than producing a potentially incorrect report - Repor → Case Study 2 — Pinnacle Health's Automated Compliance Reporting
**CICS:** If you've designed your region topology properly (Chapter 13), the TOR detects that the AOR is down and routes transactions to a surviving AOR on the same or different LPAR. CICS auto-restart brings the failed AOR back. Users see a brief delay but no outage — if you have enough AOR capacit → Index
Reference material:
Section 33.3 (Extraction Scorecard) - Section 33.4 (Facade Layer Implementation) - Section 33.5 (Data Synchronization) - Section 33.6 (Testing the Transition) - Section 33.8 (Applying the Strangler Fig to the HA Banking System) - `code/example-01-facade-pattern.cbl` (COBOL facade program) - `code/ex → Project Checkpoint 33: HA Banking System Strangler Fig Plan
the core banking program needs to know whether the payment was accepted - **Message expiry** — requests expire after 15 seconds; if FedNow hasn't responded, the transaction is flagged for investigation - **Idempotency** — every FedNow message carries a unique payment ID; the FedNow interface checks → Case Study 1: CNB's MQ Infrastructure — 47 Connected Systems and Inter-Bank Messaging
Requirements (from the project brief):
100 million transactions per day (funds transfers, inquiries, loan payments) - 99.999% availability (five nines — max 5.26 minutes unplanned downtime/year) - 2,000 concurrent online users - 4-hour nightly batch window - Regulatory: no single point of failure → Project Checkpoint 1: z/OS Environment Specification
Requirements from the project brief:
100 million transactions per day (PCI-DSS scope: cardholder data present) - 99.999% availability (security controls must not compromise availability) - PCI-DSS Level 1 compliance required - Regulatory: no single point of failure (including security infrastructure) - Online fund transfers, batch sett → Project Checkpoint 28: Security Architecture for the HA Banking System
Requirements:
Process 100 million transactions per day (funds transfers, inquiries, loan payments) - 99.999% availability (five nines — no more than 5.26 minutes of unplanned downtime per year) - Support 2,000 concurrent online users - Nightly batch window of 4 hours for end-of-day processing - Regulatory require → Index
**Month 1-2:** Portfolio inventory and dead code identification (deliverable: retire X batch jobs, save $Y in MIPS) - **Month 2-4:** First API endpoint (expose highest-value CICS transaction via z/OS Connect; deliverable: working REST API in production) - **Month 3-5:** Developer tooling modernizati → Chapter 32 Quiz: Modernization Strategy
Architecture Decision Records written to document past decisions before the decision-maker retires or departs. It extends the standard ADR format (introduced in Chapter 39) with fields that capture the historical context, hindsight assessment, and institutional knowledge that make retroactive ADRs u → Example 2 — Architecture Decision Record Template for Knowledge Transfer
junior professionals teaching modern technologies to senior professionals — builds mutual respect, demonstrates bidirectional learning, and improves both parties' capabilities. - **Cross-generational teams** that mix experience levels in daily work produce continuous, organic knowledge transfer that → Key Takeaways — Chapter 40: Knowledge Transfer and Mentoring
The security foundation for SFTP. Understanding SSH key exchange and encryption helps with troubleshooting SFTP connectivity issues. → Chapter 22 Further Reading
RFC 959: File Transfer Protocol (FTP)
The foundational FTP specification. Understanding the protocol helps diagnose transfer issues, particularly around ASCII/binary modes and SITE commands for mainframe-specific behaviors. → Chapter 22 Further Reading
What was the immediate cause? (The corrupt data in the input file.) - What was the contributing cause? (The input-producing job doesn't validate data.) - What was the systemic cause? (There is no pre-flight validation for data quality.) → Chapter 27: Batch Monitoring, Alerting, and Incident Response
Classify your system's business processes into tiers and assign RTO/RPO/RLO to each. → Index
Running
actually executing on a processor (dispatched by the CICS dispatcher, which in turn was dispatched by the z/OS dispatcher) - **Ready** — waiting for the CICS dispatcher to give it control - **Waiting** — suspended on an I/O operation (DB2 call, file read, MRO request, GETMAIN, etc.) → Chapter 17: CICS Performance and Tuning
catalog statistics updated 2. **Package remains bound with old access path** — until: - Manual REBIND - AUTOBIND triggered (if package is invalidated) - Next dynamic SQL PREPARE (for dynamic SQL) → Chapter 6: DB2 Optimizer Internals
S
Sample temporal queries:
Account balance as of a specific date (FOR SYSTEM_TIME AS OF) - All changes to an account in a date range (FOR SYSTEM_TIME BETWEEN) - Audit query: who changed what, when (joining temporal data with audit log) → Project Checkpoint: HA Banking System — DB2 Architecture
Satisfactory findings:
BIA is current (updated 2022, reviewed 2023) - Contingency plan is current (updated 2023, reviewed quarterly) - Testing program meets NIST SP 800-34 requirements - Cross-training program has eliminated single-person dependencies for CICS/DB2 recovery - GDPS automation reduces reliance on manual proc → Case Study 2: Federal Benefits Administration's DR Compliance Requirements
Run the program, and after the first or second checkpoint, simulate a failure. - Verify the restart table shows RUN_STATUS = 'C' with the correct key and counts. - Restart the program. - Verify it resumes from the checkpoint position. - Verify final control totals match Scenario 1. → Chapter 24: Checkpoint/Restart Design — Building Batch Programs That Survive Any Failure
Rewrite core banking in cloud-native over 7 years. - Year 1-10 total cost: $1.7B (including $680M migration cost, $320M in parallel running costs, $700M in cloud operating costs) - Risk: 40-60% probability of project failure based on industry track record; estimated 18-month period of degraded capab → Case Study 1: Continental National Bank's 10-Year Hybrid Architecture Vision
Scenario C: Designed Hybrid
Core transactions stay on z/OS; operational and peripheral workloads migrate to cloud; integration infrastructure built for permanent coexistence. - Year 1-10 total cost: $1.1B (including $180M integration infrastructure, $120M cloud migration for suitable workloads, $800M in operating costs for bot → Case Study 1: Continental National Bank's 10-Year Hybrid Architecture Vision
Schedule:
02:00: Incremental COPY (TSACTTXN, TSAUDIT, TSACCTMS — parallel, 15 min) - 02:15: RUNSTATS with profile (TSACTTXN, TSAUDIT — parallel, 10 min) - 02:25: REBIND all affected packages (5 min) - 02:30: Conditional REORG (metric-gated, only if thresholds breached, up to 90 min) - 04:00: Buffer for REORG → Project Checkpoint: DB2 Utility Schedule for the HA Banking System
Score:
Meets all 14 criteria: **Architect-ready** — your hybrid architecture is production-grade - Meets 10-13 criteria: **Strong foundation** — address gaps before the capstone - Meets fewer than 10: **Revisit Sections 37.2-37.6** — critical patterns are missing → Project Checkpoint 37: Hybrid Architecture Document
Scoring:
16/16: Production-ready security architecture - 13-15: Strong design, address gaps before proceeding - 10-12: Significant gaps — re-read Sections 28.2-28.6 - Below 10: Start over — security architecture is foundational → Project Checkpoint 28: Security Architecture for the HA Banking System
By account number (exact match, primary key index) - By customer name (last name exact, first name LIKE, name index) - By SSN hash (exact match, SSN hash index) - By date range + account type (range scan, composite index) → Project Checkpoint: HA Banking System — DB2 Architecture
Internal admin tools → Cloud (12 transactions, 200/day — low-volume CICS success story) - Mobile API gateway → Hybrid (cloud gateway, mainframe backend via z/OS Connect) - Core banking OLTP → Mainframe (Carlos's big-bang proposal was killed for good reasons — Chapter 32) - Dev/test → Cloud (already → Index
SecureFirst Digital
A retail bank modernization project wrapping COBOL services behind APIs for a new mobile banking application. SecureFirst represents the most common real-world modernization pattern: a strangler-fig migration where new mobile and web channels consume mainframe services through z/OS Connect and an AP → Preface
IBM Redbook SG24-7023 A comprehensive security reference covering RACF, ICSF, AT-TLS, and z/OS communications security. Particularly relevant: the chapters on cryptographic services and network security. *Available at:* IBM Redbooks → Chapter 28 Further Reading: Mainframe Security for COBOL Developers
Self-assessment — you should be able to:
[ ] Draw a z/OS address space diagram from memory, labeling system region, private region, and common storage areas - [ ] Explain why a COBOL program compiled with RENT behaves differently from one compiled with NORENT - [ ] Describe what happens when you submit a JCL job: initiator selection, step → Self-Paced Learning Guide
**Book 1:** *Learning COBOL Programming* --- The Foundation - **Book 2:** *Intermediate COBOL: Beyond the Basics* --- The Craft - **Book 3:** *Advanced COBOL Programming* --- The Architecture (this volume) → Advanced COBOL Programming
server.xml
Liberty server configuration including: - Feature list (z/OS Connect, CICS service provider, MQ service provider, security, SSL, monitoring) - HTTPS endpoint (no HTTP — TLS only) - SSL/TLS configuration with keystore and truststore references - Three CICS IPIC connections (LPAR-A, LPAR-B, LPAR-C) wi → Project Checkpoint 21: The API Layer
Serves:
Query B: MATCHCOLS=2 (ACCOUNT_ID equality, TRAN_DATE range). TRAN_TIME in key enables sort avoidance for ORDER BY. INCLUDE columns cover SELECT list except DESCRIPTION. Not fully index-only (DESCRIPTION not included) but eliminates most column fetches. - Query C: After partition pruning on TRAN_DATE → Project Checkpoint: Indexing Strategy for HA Banking System
For each of the six API operations, document: - Service archive name and description - Backend type (CICS COMMAREA, CICS channel, MQ) - COBOL copybook reference and COMMAREA/container sizes - EBCDIC code page (1047 for proper character handling) - Timeout value with justification - Response code map → Project Checkpoint 21: The API Layer
extraction scorecard with scores and rationale 2. **Seam analysis** — where are the clean extraction points in the COBOL code? 3. **Facade design** — which implementation option (A, B, or C from Section 33.2.2) and why 4. **Data synchronization strategy** — which pattern, CDC tool selection, latency → Chapter 33 Exercises: Strangler Fig Pattern for Mainframes
copy and redistribute the material in any medium or format - **Adapt** --- remix, transform, and build upon the material for any purpose, including commercial use → Advanced COBOL Programming
SHARE Association (share.org)
The premier z/OS user group. Annual conferences include multiple sessions on automation, REXX programming, and operational best practices. Presentation archives are available to members. → Further Reading — Chapter 31: Operational Automation
SHARE Conference Proceedings
https://www.share.org SHARE, the oldest and largest IBM user group, publishes conference presentations from its semi-annual meetings. Presentations on Parallel Sysplex, DB2 data sharing, and CICS performance are presented by IBM developers and experienced practitioners. Search the proceedings archiv → Chapter 1 Further Reading: The z/OS Ecosystem
SHARE Conference — CICS Performance Track
The annual SHARE conference includes dedicated sessions on CICS performance tuning, THREADSAFE conversion, and capacity planning. Presentations from IBM CICS developers often include preview information on upcoming performance features. Archives available at share.org. → Chapter 17 Further Reading
SHARE Conference — CICS Recovery Track
Annual presentations on CICS recovery architecture, testing methodologies, and real-world incident analysis. The "CICS Recovery War Stories" sessions are particularly valuable — production architects share anonymized failure scenarios and recovery procedures. → Chapter 18 Further Reading
SHARE Conference — CICS Track
The annual SHARE conference includes a dedicated CICS track with presentations from IBM CICS developers and enterprise architects. Presentations on multi-region topology design, CPSM best practices, and Sysplex integration are recurring topics. Archives available at share.org. → Chapter 13 Further Reading
SHARE Conference — CICS Web Services Track
Annual presentations from IBM CICS architects and enterprise customers on web service implementation patterns. Recent sessions have covered JSON transformation optimization, Liberty JVM server deployment, and z/OS Connect EE migration strategies. Archives available at share.org. → Chapter 14 Further Reading
The SHARE user group archive contains numerous presentations from mainframe security practitioners. Search for "CICS security" and "RACF CICS" in the SHARE presentation archive. → Chapter 16 Further Reading
share.org
SHARE sessions cover DB2 optimizer topics in the context of z/OS system-level performance. Presentations on zparm tuning, buffer pool sizing, and I/O subsystem configuration provide the system-level context that affects optimizer cost calculations. → Chapter 6 Further Reading: DB2 Optimizer Internals
no automatic space management, no overflow capability 2. **Inadequate error handling** — program abend on a recoverable error 3. **CICS capacity misconfiguration** — MAXTASK/thread limit mismatch 4. **Insufficient monitoring** — 1 hour 50 minutes before the operations team was notified 5. **No queue → Case Study 2: Lessons from a Payment System Failure — The Meridian National Incident
Six patterns that work until they don't:
The universal cursor (defeats the optimizer) - The uncommitted marathon (triggers lock escalation and log exhaustion) - Dynamic SQL string concatenation (SQL injection vector) - Unbounded scrollable cursors (workfile exhaustion) - The thread hog (holds DB2 threads during non-DB2 work) - Fatal-error- → Key Takeaways: DB2 Application Patterns
CICS writes SMF 110 subtype 2 records for every web service request. These contain: URI, HTTP method, response code, response time, bytes in/out, client IP, and user ID. At CNB, these records feed a Splunk dashboard that provides real-time API analytics. → Chapter 14: CICS Web Services
Traditional SNA communication. Reliable, well-understood, but requires VTAM definitions and network configuration. - **IP interconnectivity (IPIC)** — TCP/IP-based communication introduced in CICS TS 4.1. Simpler to configure, lower overhead, and increasingly preferred. → Chapter 13: CICS Architecture for Architects
CICS suspends new task creation for transactions that require below-the-line storage. Existing tasks continue but may wait on GETMAIN requests. The dispatcher prioritizes task completion to free storage. → Chapter 17: CICS Performance and Tuning
Before proceeding, briefly recall: > - **From Chapter 1:** How does z/OS networking work? TCP/IP in the z/OS stack, the role of TCPIP address spaces, and how the Communications Server handles inbound connections. Your web services will arrive as TCP/IP packets on a z/OS network interface. > - **From → Chapter 14: CICS Web Services
SPACED REVIEW — Chapter 13
Recall from Chapter 13 that MRO connections create cross-region dependencies. In a multi-region topology, a compensating transaction might need to execute across multiple regions — compensating a DB2 update in one AOR, a VSAM update in a FOR, and an MQ message in a third. The compensating transactio → Chapter 18: CICS Failure and Recovery
SPACED REVIEW — Chapter 8
Recall from Chapter 8 that DB2 locks are held for the duration of the unit of work. In a CICS environment, the unit of work boundary is the EXEC CICS SYNCPOINT. If a CICS region fails with 500 active tasks, each holding DB2 locks, those locks remain held until CICS restarts and resolves each UOW. Un → Chapter 18: CICS Failure and Recovery
SPACED REVIEW: CHAPTER 5
WLM service classes for CICS. Review how you defined service classes, classification rules, and velocity goals. Those definitions directly feed CPSM's goal-based routing algorithm. The routing is only as good as the WLM configuration. → Chapter 13: CICS Architecture for Architects
Move dev/test to cloud - Build team's cloud skills - Establish network connectivity (Direct Connect / ExpressRoute) - Learn the cloud's operational model - Deliverable: cloud landing zone, first dev/test environments running → Index
Stage 2: Cloud Capable (12-24 months)
Migrate first batch workload (reporting or analytics) - Implement CDC for near-real-time data replication - Build monitoring and incident response for cloud COBOL - Measure actual TCO (not projected) - Deliverable: first production workload on cloud, validated TCO → Index
Stage 3: Hybrid Optimized (24-48 months)
Multiple workloads running on cloud - Mature data synchronization (batch + CDC + API) - Integrated monitoring across mainframe and cloud - Team operates both environments confidently - Clear policies for what runs where - Deliverable: documented hybrid architecture, operational runbooks for both env → Index
Stage 4: Strategic Hybrid (48+ months)
Workload placement decisions are routine, data-driven - New workloads are deployed to the optimal platform from inception - Cost optimization is continuous (reserved instances, right-sizing, Tailored Fit Pricing) - The organization doesn't think about "mainframe vs. cloud" — it thinks about "where d → Index
they have simpler data synchronization and higher risk tolerance - **Use the extraction scorecard** to choose candidates based on priority (business value and change frequency divided by technical complexity and data coupling), not just business value alone - **Shadow mode testing with production tr → Kong API Gateway — Balance Inquiry Strangler Fig Routing
**PLANNO 1, METHOD 0:** EMPLOYEE is the outer table (METHOD 0 = first table accessed). ACCESSTYPE = I means index access. MATCHCOLS = 2 means two leading columns of IX_EMP_DEPTDT match predicates in the WHERE clause. INDEXONLY = N means DB2 must access the base table data pages (the index alone does → Appendix J: Answers to Selected Exercises
How much storage is in use? Key fields: - Current and peak allocation for each DSA sub-pool - Number of GETMAIN requests and failures - Number of SOS events and duration - Storage cushion (free space) for each domain - Program compression count (indicates storage pressure) → Chapter 17: CICS Performance and Tuning
STORAGE(xx,yy,zz) explained:
`xx` = initial value for heap storage. `00` fills with binary zeros. Helps catch uninitialized data bugs during testing. - `yy` = value to fill freed storage. `FE` fills freed storage with X'FE'. If a program accesses freed storage, the data is obviously invalid — `X'FEFEFEFE'` is unmistakable in a → Index
Every critical structure (DB2 lock, SCA, GBPs, GRS star, XCF signaling) has a primary allocation on one CF and an alternate allocation on a CF on the *other* physical frame. - If CF01 fails, structures automatically rebuild on CF03 or CF04 (the alternate CFs on the surviving frame). - If an entire p → Case Study 1: Continental National Bank's Parallel Sysplex Migration
Subscription queue depths
all five subscription queues are monitored with alerts at 5,000 messages. The analytics queue tolerates higher depths (batch consumer), but the notification and dashboard queues should be near-zero during business hours. → Case Study 2: Pinnacle Health's Claims Status Notification System
Summary of what you'll design:
REST API endpoints for balance inquiry, fund transfer, transaction history, and payment scheduling - JSON schemas derived from existing COBOL copybooks - TCPIPSERVICE, URIMAP, PIPELINE, and WEBSERVICE resource definitions - External service requester configuration for credit score lookup - Security → Chapter 14: CICS Web Services
Balance inquiry (CICS → DB2): 500 transactions, 100% success, avg response 12ms - Fund transfer (CICS → DB2 → MQ): 200 transactions, 100% success, avg response 45ms - ATM authorization: 100 simulated ATM requests, 100% success, avg response 85ms → Case Study 1: Continental National Bank's DR Architecture and Annual Test
System requirements (from Chapter 1):
100 million transactions per day - 99.999% availability (five nines — max 5.26 minutes unplanned downtime/year) - 2,000 concurrent online users - 4-hour nightly batch window - Regulatory: no single point of failure → Project Checkpoint 30: DR Design for the HA Banking System
`LOCKSIZE ROW` — Minimizes false contention between online transactions - `LOCKMAX 10000` — High threshold (batch will COMMIT well before this) - Partitioned by account-number range (12 partitions) - Batch processes one partition at a time, partitions in sequence - Online uses CS isolation with curr → Chapter 8: DB2 Locking, Concurrency, and Deadlock Resolution: The Chapter That Prevents 2am Pages
Table: HTXN_HISTORY (transaction log)
`LOCKSIZE PAGE` — Insert-heavy, row locking overhead not justified - `LOCKMAX 5000` - Partitioned by date (monthly) - Online inserts into current partition only - Batch reads from previous partitions (no contention with online inserts) - Online reads use UR (historical queries don't need current acc → Chapter 8: DB2 Locking, Concurrency, and Deadlock Resolution: The Chapter That Prevents 2am Pages
a value from 0 (lowest) to 255 (highest), assigned by the TRANCLASS or the transaction definition's PRIORITY parameter 2. **Within the same priority** — first-in-first-out (FIFO) → Chapter 17: CICS Performance and Tuning
Teaching
The best way to solidify your understanding of something is to teach it. Write blog posts, present at user groups, mentor junior developers, create internal training materials. Teaching forces you to organize your knowledge and identify your gaps. It also builds your professional reputation, which i → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
Team:
Test director: Kwame Mensah - DB2 recovery lead: Lisa Tran - Batch recovery lead: Rob Calloway - CICS lead: Sarah Kim (CICS systems programmer) - MQ lead: David Park (MQ administrator) - Network lead: James Wright (network engineer) - GDPS operator: Maria Santos (storage/GDPS specialist) - Observers → Case Study 1: Continental National Bank's DR Architecture and Annual Test
Technical feasibility and specificity (10 points):
**Phase 1:** Batch window crisis addressed with specific optimizations (DB2 buffer pool tuning, SORT preprocessing, possible partitioning of the eligibility batch by claim type or region for parallel execution). Security findings addressed with RACF profile cleanup, automated access review tooling, → Sample Final Exam
Terminal-Owning Region (TOR)
Owns the connection to the end user. Whether that connection is a 3270 terminal, a web service request via CICS Web Services, or a JSON call from a mobile app through CICS TS's Liberty JVM server, the TOR is the front door. TORs do not run application logic. They accept requests, route them, and ret → Chapter 13: CICS Architecture for Architects
describe the test dataset (how many records, what characteristics) b) **At least 8 test scenarios** covering: - Fresh start, normal completion - Failure in each of the four steps (at different points: early, mid, late) - Multiple consecutive restarts - Failure before first checkpoint in STEP030 c) * → Project Checkpoint: Checkpoint/Restart Design for the HA Banking Batch Pipeline
The benefits calculation engine contained 2,847 distinct business rules (identified by systematic code review, not automated analysis) - 340 of those rules implemented benefits formulas that had been superseded by subsequent legislation but were retained to handle grandfathered beneficiaries — peopl → Case Study 1: Federal Benefits Administration's Modernization Assessment and Strategy
The Dead Code Problem:
1,847 programs (38%) were dead — never executed in production, or executed but producing output nobody consumed - 1,200 batch jobs ran nightly but their output files hadn't been accessed in 2+ years - 312 copybooks were duplicates with minor variations (created when developers copied and modified ra → Case Study 1: Federal Benefits Administration's Modernization Assessment and Strategy
The Dependency Web:
The benefits calculation engine (FBACALC, 47,000 LOC) was called by 347 other programs - 23 programs had undocumented dependencies on Marcus's personal knowledge - The IMS database schema had evolved through 312 schema changes over 40 years, creating a layer-cake of segment types where some segments → Case Study 1: Federal Benefits Administration's Modernization Assessment and Strategy
The facade
a stateless, observable, reversible routing layer that sits in front of both legacy and modern services 2. **The routing engine** — the decision-making component that controls which service handles each request 3. **The extraction pipeline** — the lifecycle from identification through shadow mode, p → Kong API Gateway — Balance Inquiry Strangler Fig Routing
The Financial Analysis
For each option, estimate: - Capital expenditure (hardware, software licenses, infrastructure) - Operating expenditure (staff, maintenance, support contracts) - Implementation cost (development, testing, deployment, training) - Ongoing cost (annual maintenance, support, operational overhead) - Total → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
Layer 1: Parameter markers for all values - Layer 2: Input validation (format, range, whitelist) - Layer 3: DYNAMICRULES(BIND) to restrict authorization scope - Layer 4: Audit logging of all dynamic SQL executions - Layer 5: Prepared statement caching to fix SQL structure after first preparation → Key Takeaways: DB2 Application Patterns
The Java rewrite argument (must include):
Risk 1: 1,400 programs x 2,000 average LOC = 2.8 million lines. Industry data suggests COBOL-to-Java conversion at 10-20 LOC/hour when accounting for testing and business rule validation. At 15 LOC/hr, that is 187,000 person-hours or ~90 person-years. With a team of 20 developers, that is 4.5 years, → Sample Final Exam
The Java Rewrite Question:
Provide a structured argument for why a full rewrite is or is not appropriate for this system. Your argument must include at least three specific risk factors and two cost considerations. You may recommend a partial rewrite if justified. → Sample Final Exam
What business problem does this initiative solve? Frame it in business terms, not technical terms. Not "Our CICS regions are at 85% CPU capacity" but "Our customer-facing transaction processing system will be unable to handle projected growth within 18 months, risking service degradation during peak → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
Vendors selling cloud migration will compare their annual cloud cost to the mainframe's annual cost and declare savings. Architects must ensure apples-to-apples comparisons that include migration cost, application rewrite cost, testing cost, training cost, performance differences, security implicati → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
The team:
**Yuki Nakamura** — DevOps lead. Brought Jenkins, Git, Zowe, and VS Code to the mainframe team. Former distributed systems engineer who learned to respect the mainframe's strengths. Her mantra: "Measure everything, assume nothing, automate anything that hurts." - **Carlos Vega** — Mobile API archite → Case Study 1: SecureFirst's Strangler Fig for Mobile Banking
THEME: Knowledge is retiring
Marcus Whitfield has 30 years of IMS recovery experience that exists nowhere in documentation. The procedures he follows are a combination of documented steps and undocumented judgment calls accumulated over decades of production incidents. Sandra's modernization effort includes not just technology → Chapter 18: CICS Failure and Recovery
THEME: The best architects understand both worlds
Carlos's initial assumption ("the backend handles recovery") is common among distributed-systems architects encountering mainframe transaction processing for the first time. The mainframe does handle recovery — but only within its transaction boundaries. When the transaction boundary ends at an API → Chapter 18: CICS Failure and Recovery
This chapter
conceptual foundation and architectural perspective 2. **ABCs of z/OS System Programming Vol. 10** — hands-on ISPF panel walkthrough 3. **z/OS MVS Planning: Workload Management** (Chapters 2-4) — detailed configuration reference 4. **RMF User's Guide** (Chapter 6) — learning to read WLM reports 5. * → Chapter 5 Further Reading: z/OS Workload Manager
Dedicated Redbook on converting CICS programs to THREADSAFE. Covers prerequisites, testing methodology, common pitfalls, and performance benchmarks. Essential reading before undertaking the THREADSAFE conversion described in Section 17.2 and Case Study 2. → Chapter 17 Further Reading
Three-year impact:
CBNC4500 has been restarted 9 times. Average recovery: 4 minutes. Zero downstream impact. - The CNB framework is now used by 67 batch programs. - Two additional major incidents occurred where checkpoint/restart prevented SLA misses — both involved hardware failures similar to the original CBNC4500 i → Case Study 1: CNB's Checkpoint/Restart Redesign After the Six-Hour Batch Rerun
THRESHOLD CONCEPT
CICS is a transaction manager, not an application server. Once you internalize this distinction, everything about region topology, routing, MRO, and recovery design clicks into place. Until you internalize it, every architectural decision will feel arbitrary. → Chapter 13: CICS Architecture for Architects
Tier 1 Critical (37 jobs):
Account posting chain: ACCTEXTRT, ACCTVALID, ACCTPOST, ACCTAUDIT - GL chain: GLEXTRACT, GLTRANSF, GLBALANCE, GLREPORT - ATM/card chain: ATMEXTRT, ATMREFRESH, CARDBATCH - Regulatory chain: REGDAILY, REGCOMPLY - Statement chain: STMTGEN, STMTPRINT, STMTARCH - All checkpoint/restart-critical jobs → Case Study 1: CNB's Batch Operations Center and Rob's Playbook
Tier 1 — Critical (Immediate Response Required):
Any abend in a Tier-1 job (defined list of ~40 critical jobs) - Batch window SLA milestone missed or projected to miss within 30 minutes - Dataset space abend (B37/D37/E37) in any batch job - Security violation (RACF denial) in batch execution - JES spool utilization exceeds 85% - DASD volume utiliz → Chapter 27: Batch Monitoring, Alerting, and Incident Response
Tier 1 — Immediate (within 4 hours):
GP utilization exceeds 90% for any 1-hour period - R4HA exceeds planned Aggressive scenario for the month - zIIP utilization exceeds 85% for any 1-hour period - Any LPAR hits defined capacity ceiling → Chapter 29: Capacity Planning and Growth Management
GP utilization exceeds 85% for any 4-hour period - R4HA exceeds planned Expected scenario by more than 5% - Batch window elapsed time exceeds 95% of available window - Storage growth rate exceeds forecast by more than 20% → Chapter 29: Capacity Planning and Growth Management
Tier 3 illustrative examples
composite fictions based on common industry patterns. They are not real companies. But every architectural challenge they face is drawn directly from challenges that real organizations face every day. → Preface
Tier 3 — Informational (Review Next Business Day):
Any job elapsed time exceeds baseline by 25% - Condition code non-zero but within acceptable range - Dataset created larger than expected - New job detected (not in baseline database) - Successful automated restart → Chapter 27: Batch Monitoring, Alerting, and Incident Response
Tier 3 — Weekly Review:
Monthly R4HA trend deviating from forecast by more than 3% - Any workload category growing faster than projected - zIIP utilization trending higher than forecast - CoD usage exceeding budget → Chapter 29: Capacity Planning and Growth Management
When did the problem actually begin? (Not when it was detected — when did the underlying condition first manifest?) - When was it detected? - When was diagnosis complete? - When was it resolved? - When were all downstream effects cleared? → Chapter 27: Batch Monitoring, Alerting, and Incident Response
Timeline:
**6:00 PM** — Nightly batch cycle begins. Job ACCRPOST runs first, posting daily interest accruals to 800,000 savings accounts. Each posting is a DB2 UPDATE to the ACCOUNT_MASTER table. - **6:12 PM** — CDC pipeline begins replicating the accrual postings to PostgreSQL. Normal lag: 2-3 seconds. But w → Case Study 1: SecureFirst's Strangler Fig for Mobile Banking
TLS mutual authentication
The API gateway presents a client certificate to CICS. CICS validates it against the RACF keyring. This ensures only the authorized API gateway can connect to CICS. → Chapter 14: CICS Web Services
Tradeoff analysis (8 points):
Acknowledges that batch partitioning trades complexity for throughput - Discusses API gateway placement (cloud vs. on-prem DMZ) - Weighs risk of CI/CD adoption against cost of manual deployment errors → Sample Final Exam
Traditional COBOL batch processing
your mainline batch jobs run on general purpose (GP) processors - **CICS COBOL transactions** — CICS application processing runs on GPs - **DB2 locally attached processing** — when CICS or batch COBOL calls DB2 through a local thread, the DB2 work runs on GPs (mostly) → Chapter 29: Capacity Planning and Growth Management
Per-transaction-type aggregates. Key fields: - Transaction count (number of completions) - Average, minimum, maximum response time - Average CPU time (QR and open TCB) - Average wait time (broken down by wait type: dispatcher, DB2, file I/O, MRO) - Average storage used - Abend count → Chapter 17: CICS Performance and Tuning
Transmission Security (164.312(e)):
AT-TLS for all ePHI in transit - MQ channel encryption for inter-system ePHI transfers - VPN or dedicated circuits for ePHI transmission to external partners → Index
MQ fires a trigger for every single message that arrives. If 10,000 messages arrive in a burst, MQ generates 10,000 trigger messages, and CKTI tries to start 10,000 instances of your transaction. This will overwhelm your CICS region. Use TRIGTYPE(EVERY) only for low-volume queues where each message → Chapter 20: Event-Driven Architecture with COBOL — MQ Triggers, CICS Events, and Pub/Sub Patterns
TRIGTYPE(FIRST)
MQ fires the trigger only when the first message arrives on an empty queue. After the first trigger, no more triggers fire until the queue goes back to empty (depth = 0) and another message arrives. This is the standard choice for high-volume queues. Your triggered program should process *all* avail → Chapter 20: Event-Driven Architecture with COBOL — MQ Triggers, CICS Events, and Pub/Sub Patterns
TSO/E REXX Reference (SA32-0972)
The definitive REXX language reference for z/OS. Essential for OUTTRAP, LISTDSI, SYSVAR, and all TSO/REXX-specific functions. Keep this bookmarked. - **TSO/E REXX User's Guide (SA32-0982)** — Practical guide to writing REXX execs under TSO. Covers host command environments, ISPF service calls, and b → Further Reading — Chapter 31: Operational Automation
Type 1 (Transaction Performance)
One record per transaction completion. Contains response time, CPU time, wait times (broken down by wait type), storage used, DB2 call counts, file I/O counts, and hundreds of other fields. This is the richest source of individual transaction performance data. - **Type 2 (System Exception)** — Writt → Chapter 17: CICS Performance and Tuning
Shared on-call rotation with cross-platform capability - Joint architecture reviews for all cross-platform features - Shared dashboards visible to both teams - Blameless post-incident reviews - Single documentation repository → Chapter 37 Key Takeaways: The Hybrid Architecture
This URIMAP is for provider mode. USAGE(CLIENT) would be for requester mode. - **PATH** — The URI path pattern. The `{accountId}` is a path variable. CICS extracts it and makes it available to the program. - **PIPELINE(JSONPIPE)** — The pipeline resource that defines how request/response data is tra → Chapter 14: CICS Web Services
Multiple consumers need the same data - The producer doesn't need a response before continuing - You need to add consumers without modifying the producer - Different consumers process at different speeds - Audit logging, analytics, and monitoring are needed alongside primary processing → Chapter 20 Key Takeaways: Event-Driven Architecture with COBOL
Use Request/Reply When:
The sender needs a response before proceeding (authorization, balance inquiry) - There is exactly one consumer - The interaction is inherently synchronous (ATM: dispense cash only after approval) - Strong transactional coupling is required between request and response → Chapter 20 Key Takeaways: Event-Driven Architecture with COBOL
Non-null, positive amount, source != target 2. **Validate source account** — Exists, status is 'AC' (active), currency matches 3. **Validate target account** — Exists, status allows deposits (not 'CL' or 'FR'), currency matches 4. **Check available balance** — Current balance minus holds minus pendi → Project Checkpoint: HA Banking Stored Procedure Layer
Variations by MATCHCOLS:
MATCHCOLS = 0: Non-matching index scan — DB2 reads the entire index leaf chain. This happens when the index has useful screening columns or when the index is much smaller than the tablespace (scanning a 2-GB index is faster than scanning a 180-GB tablespace, even without matching). DB2 evaluates pre → Chapter 6: DB2 Optimizer Internals
*TOGAF Certified (The Open Group)*: The most widely recognized enterprise architecture certification. It provides a framework and vocabulary for architectural practice. Critics note it can be overly bureaucratic, but the framework is useful and the certification is widely respected. - *AWS/Azure/GCP → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
Increasing limits within a single region (raise MXT, raise EDSALIM, raise CMDT). Cheaper but has diminishing returns. Each limit increase moves you closer to the next bottleneck. → Chapter 17: CICS Performance and Tuning
On restart, the VSAM account master may have partial updates. Since HAPOSTING updates account balances by adding/subtracting amounts, the VSAM updates since the last checkpoint must be reversed. - Strategy: Store the keys and amounts of all VSAM updates since the last checkpoint in a DB2 staging tab → Chapter 24: Checkpoint/Restart Design — Building Batch Programs That Survive Any Failure
GDPS/HyperSwap manager deployed on the GDPS controlling system - Metro Mirror configuration updated to support HyperSwap (requires specific configuration attributes on the Metro Mirror sessions) - Testing: simulated primary storage controller failure — HyperSwap completed in 1.8 seconds. Application → Case Study 1: Continental National Bank's DR Architecture and Annual Test
What CNB had to solve:
Data replication: Nightly extract from mainframe DB2, convert from EBCDIC, load to cloud database (PostgreSQL on RDS). Initial implementation took 90 minutes; optimized to 35 minutes. - GDG handling: Seventeen of the forty-seven programs used Generation Data Groups. Micro Focus JCL interpreter suppo → Index
What was good:
RACF was active with PROTECTALL(FAILURES) — no unprotected datasets - CICS transaction security was enabled for the primary claims processing transactions - DB2 connection control via RACF DSNR class was properly configured - SMF recording was active for types 30, 80, and 102 → Case Study 2: Pinnacle Health Insurance's HIPAA Security Implementation
What was not good:
No encryption — neither dataset encryption nor DB2 column encryption for ePHI - No AT-TLS — EDI transmissions (837/835 claims files) from providers used FTP over unencrypted TCP - DB2 authorization was table-level, not column-level — anyone with SELECT on the CLAIMS table could see all columns, incl → Case Study 2: Pinnacle Health Insurance's HIPAA Security Implementation
When chosen:
No suitable index exists - Filter factors estimate a large fraction of rows will be returned (typically >20-25%) - CLUSTERRATIO of available indexes is low, making index access expensive - Table is small enough that a scan fits in the buffer pool → Chapter 6: DB2 Optimizer Internals
zparm OPTIQP is not set to YES - zparm MAXTEMPS too small for hash table materialization - Non-equi-join predicates (hash join requires equality on at least one join predicate — you can't hash a range comparison) - The build table's qualifying result set is too small (optimizer chooses nested loop a → Chapter 6: DB2 Optimizer Internals
*Any* application that depends on CICS transaction management, IMS, or Parallel Sysplex capabilities - High-throughput online transaction processing — the I/O architecture difference between z/OS and Linux is not marginal, it's fundamental (Chapter 1, Section 1.2) - Applications with deep z/OS depen → Index
When it works:
Simple batch programs with minimal z/OS dependencies (no CICS, no IMS, limited DB2 usage or DB2 replaced with PostgreSQL) - Read-heavy reporting workloads that don't require mainframe transaction integrity - Applications where the primary driver is MIPS cost reduction and the workload profile matche → Index
When sorts become critical path items:
File sizes exceeding 50 GB - Inadequate MAINSIZE (forces more sort passes) - Work datasets on the same volume (eliminates parallel I/O) - Record sizes > 2,000 bytes (fewer records fit in memory) → Example 2: Worked Throughput Calculation Examples
CICS emulation does not cover the full CICS API surface. Missing or limited: EXEC CICS SIGNAL EVENT, some TS queue recovery semantics, CICS channels across MRO regions, Sysplex-wide CSD operations. If your CICS programs use advanced features, test exhaustively. - JCL interpretation has edge cases: D → Index
Where it's strong:
The most mature COBOL-to-x86 rehosting platform, with 30+ years of development - Broad Enterprise COBOL compatibility — handles most COBOL syntax including reference modification, intrinsic functions, XML GENERATE/PARSE, and JSON GENERATE/PARSE - CICS emulation covers the most commonly used API comm → Index
Why shared-nothing is mandatory:
**Coupling creates fragility.** If your cloud microservices query DB2 on z/OS directly, a network hiccup between cloud and mainframe takes down every cloud service. Shared-nothing means each platform can operate independently during transient failures. - **Performance isolation.** A cloud analytics → Index
FF for `TRAN_DATE = :WS-PROCESS-DATE`: 1/1095 = 0.000913 - FF for `ACCT_STATUS IN ('A', 'P', 'H')`: 3/6 = 0.50 - Combined FF: 0.000913 * 0.50 = 0.000457 - Estimated rows from DAILY_TRANSACTIONS: 500,000,000 * 0.000457 = 228,500 - But the optimizer compared this against the tablespace scan cost... → Case Study 1: CNB's Overnight Plan Change Investigation
With COLCARDF = 365 (correct):
FF for `TRAN_DATE = :WS-PROCESS-DATE`: 1/365 = 0.00274 - FF for `ACCT_STATUS IN ('A', 'P', 'H')`: 3/6 = 0.50 - Combined FF: 0.00274 * 0.50 = 0.00137 - Estimated rows from DAILY_TRANSACTIONS: 500,000,000 * 0.00137 = 685,000 - Index access cost (MATCHCOLS=4, CLUSTERRATIO=95%): mostly sequential I/O - → Case Study 1: CNB's Overnight Plan Change Investigation
WLM affects CICS
A CICS region in a high-priority WLM service class gets more CPU dispatching priority. If the region is CPU-bound, this directly improves response times. If the region is I/O-bound, WLM priority has minimal impact (the region is waiting for I/O, not for CPU). → Chapter 17: CICS Performance and Tuning
WLM Application Environment
Defined in the WLM ISPF panels or policy. Specifies the JCL procedure to start the address space. 2. **JCL Procedure (typically in PROCLIB)** — Defines STEPLIB (where your COBOL load module lives), DBRMLIB, and other DD statements. 3. **Service Class** — WLM assigns the address space to a service cl → Chapter 10: Stored Procedures and User-Defined Functions in COBOL
don't wait for the 80A - **CICS working storage: multiply by concurrent tasks** — the batch programmer's blind spot - **RPTSTG quarterly** — track storage growth before it becomes a crisis - **STORAGE(00,FE,00) in all environments** — 2-5% overhead buys enormous diagnostic value - **Do the arithmeti → Chapter 2 Key Takeaways: Virtual Storage Architecture
Working storage requirements:
Transaction validation reference table: How large? (Hint: estimate the number of accounts and the bytes per account lookup entry) - Accumulator tables for reconciliation: How many categories × bytes per accumulator? - I/O buffer areas: Based on your DD statement design from Checkpoint 1 → Index
Workload Manager (WLM)
the z/OS component that decides how much system resource your COBOL programs receive. If this chapter taught you how z/OS manages your data, Chapter 5 teaches you how z/OS manages your execution. You'll learn how WLM service classes, classification rules, and resource groups determine whether your b → Chapter 4: Dataset Management Deep Dive
Written for 3 AM execution
clear, unambiguous, numbered steps 2. **Verification after every major action** — "Start DB2. Verify: `-DIS DDF` → `STARTD`" 3. **Decision points** — "If X succeeds → step 7. If X fails with code Y → Appendix C" 4. **Estimated times** — "Step 5: IPL LPAR. Expected: 8-12 minutes" 5. **Escalation path → Chapter 30 Key Takeaways: Disaster Recovery and Business Continuity
WS-Security (OASIS)
The standard for SOAP message-level security. Covers XML digital signatures, encryption, and security token profiles. Referenced in CNB's RPCN implementation. - URL: https://www.oasis-open.org/standards#wssv1.1.1 → Chapter 14 Further Reading
WSDL 1.1 Specification (W3C)
The specification for Web Services Description Language. Understanding WSDL structure helps you interpret and customize DFHLS2WS-generated WSDLs. - URL: https://www.w3.org/TR/wsdl → Chapter 14 Further Reading
WTO messages
captured by the z/OS automation product (IBM System Automation) for immediate operator notification 2. **SMF 110 records** — forwarded to Splunk for historical analysis and trending 3. **SNMP traps** — sent to the network operations center's monitoring dashboard for real-time visibility → Chapter 13: CICS Architecture for Architects
Eclipse-based tooling for creating REST APIs from COBOL copybooks. Includes a graphical data mapping editor that generates the z/OS Connect service archive. → Chapter 14 Further Reading
z/OS Connect EE V3.0 Documentation
IBM Knowledge Center. The definitive reference for exposing COBOL programs as REST APIs. Pay particular attention to the service archive (SAR) creation process, JSON schema generation from COBOL copybooks, and the interceptor framework for logging and security. - URL: https://www.ibm.com/docs/en/zos → Chapter 22 Further Reading
z/OS Connect Enterprise Edition Documentation
Covers installation, configuration, API creation, and management of z/OS Connect EE. The "Creating APIs from CICS Services" section is directly relevant to this chapter. - URL: https://www.ibm.com/docs/en/zos-connect → Chapter 14 Further Reading
z/OS DFSMS Access Method Services for Catalogs
IDCAMS documentation for DEFINE GDG, including LIMIT, EMPTY/NOEMPTY, and SCRATCH/NOSCRATCH parameters. Section on relative generation numbering clarifies the (+1), (0), (-1) behavior. → Chapter 22 Further Reading
z/OS Implementation:
z/OS Communications Server IP packet filtering (IPSec policies) - VLAN segmentation isolating the Cardholder Data Environment (CDE) LPARs - AT-TLS for all inbound connections to the CDE - z/OS Intrusion Detection Services (IDS) for network anomaly detection → Index
The z/OS WLM reference, relevant to Section 17.7's discussion of WLM and CICS interaction. Chapters on service class design, velocity goals, and the enclave model for CICS are directly applicable. → Chapter 17 Further Reading
z/OS MVS Setting Up a Sysplex (SA38-0680)
Covers ARM policy definition, restart element registration, cross-system restart, and restart group coordination. Chapter 6 covers ARM in detail. → Chapter 18 Further Reading
z/OS PKI Services: A Practical Guide
IBM Redbook SG24-7603 Covers certificate management on z/OS, including RACF keyrings, digital certificate configuration, and integration with AT-TLS. Essential if you are implementing mutual TLS authentication as described in the Pinnacle case study. *Available at:* IBM Redbooks → Chapter 28 Further Reading: Mainframe Security for COBOL Developers
z/OS System Logger Best Practices
IBM's guidance on configuring z/OS Logger for CICS system logs, including coupling facility structure sizing, staging dataset configuration, and offloading policy. → Chapter 18 Further Reading
Zero API endpoints
the entire system was accessible only via CICS 3270 terminals and batch file interfaces → Index
zIIP Eligibility
Work that runs on IBM Specialty Engines (zIIPs) does not count toward MLC pricing. Architects who can shift workloads to zIIP-eligible processing (Java, XML parsing, DB2 stored procedures, encryption) can deliver dramatic cost savings. This is one reason the hybrid approach is often financially attr → Chapter 39 — The Mainframe Architect's Career Path: From Senior Developer to Technical Fellow
Zowe CLI
Open-source CLI for z/OS interactions. The CICS plugin allows you to manage web service resources from the command line, which is essential for CI/CD integration (Chapter 36). - URL: https://zowe.org → Chapter 14 Further Reading
Zowe Documentation: API Mediation Layer
Official documentation for Zowe API ML, including the API Gateway, Discovery Service, and API Catalog. The "Getting Started" tutorial walks through deploying all three components. Available at docs.zowe.org. - **Zowe GitHub Repository** — Source code for the Zowe API Mediation Layer. Useful for unde → Chapter 21: Further Reading