Explained: MQ on z/OS

A customer submits a mortgage application on a bank's website. The web server accepts it immediately and shows a confirmation. Behind the scenes, that application needs to pass through a fraud check, a credit bureau lookup, an underwriting system, and a document management platform. Each of those systems runs on different infrastructure, at different speeds, and is maintained by different teams. The web server cannot wait for all of them. It… Read More

Explained: CICS Error Handling

A CICS transaction reads a customer record. The record does not exist. The program does not check the response code. It continues with uninitialised Working Storage, writes garbage to a VSAM file, and returns a confirmation to the screen. The customer's record is now corrupt. Nobody knows yet. Error handling in CICS is not optional. Every CICS command can fail. Files return `NOTFND`. DB2 returns lock timeouts. Programs abend with `ASRA`. The … Read More

Explained: CICS Storage Management

It starts as a performance problem. Response times climb. Tasks start queuing. Then a message appears on the operator console: DFHSM0133 CICS is under stress (short on storage above 16MB) . New transactions are refused. The region grinds to a halt and has to be recycled. Short on storage is one of the most disruptive CICS failures in production, and unlike most failures it builds gradually. A storage leak in one transaction, a DSA limit set too co… Read More

Explained: CICS Link Modules

A CICS transaction arrives. It validates the input, applies some business rules, looks up a customer record, and calculates a result. If all of that logic lived in one monolithic COBOL program, changing the business rules would mean recompiling and redeploying the entire thing. Testing the calculation in isolation would be impossible. Sharing the customer lookup with ten other transactions would mean copying the code ten times. This is why CICS p… Read More