Syncpoints and Units of Work
In the past we've been working on projects where syncpoints and units of work have been issues. But let's face it: these recovery subjects can be boring, and it's easy to just assume that the software we're using will handle it. But understanding syncpoints and units of work is essential if you want to develop a resilient, robust system. So this issue, we've decided to take a look at them: without the boring bits.
In our first technical article, we get straight into it, and explore if we can improve performance for 'background' tasks by batching up syncpoints. Although we talk about CICS, this is relevant for other environments as well.
In our second technical article, we backup our first article with a refresher about units of work, syncpoints and two-phase commit. The difference is that we try to explain it in clear English.
In our final article, we hop on our soap box for our opinion article. We argue that we can't have resilient systems and applications without the right attitude, ability and assets.
Finally, we're presenting at the Share Virtual conference this winter. Join us on 17-Mar-2021 where we talk about our experiences implementing VSAM RLS at a client site.
We hope you enjoy this issue.
technical: Batching CICS Syncpoints for Performance
Can we improve performance by 'batching' our syncpoints? Or in other words, processing several units of work before issuing each syncpoint command?
technical: Refresher: Syncpoints and Units of Work
Over the past couple of years, I've been on projects where transaction resilience and recovery have been big issues. Terms like "unit of work" and syncpoint have been creeping into reports, and I've needed to dig deeper into two-phase commit processing, and how it affects the processing.
So, in this article, I'm going to give a quick refresher on syncpoints and units of work. I'll talk about mainframes and z/OS, but the concepts apply to any platform.
opinion: We Can't Have Resilience Without Attitude, Ability and Assets
We can certainly talk more about resilience, and ideas on improving it. But the bottom line is that for a computer system to be truly resilience, we need three things: attitude, ability and assets.