Code Change and Resilience

A lot of our projects recently have been all about resilience: strengthening mainframe systems and applications, and reducing outages. So, in this edition, we thought we'd talk about some resilience issues that, well, people often don't talk about. As assembler programmers, we love using eyecatchers for data areas. We talk more about how this can improve the resilience of any program in our first technical article. In our second, we look at options when we're modifying code that is really, really bad.

In our opinion article we argue that change management is good, change management that is too heavy is bad, and counter productive.

In November, we presented at the Perth Z Community Event, discussing some of the z/OS resilience features we see unused, or under-used.

Finally, at TechChannel, we look at five ways to quickly speed up batch jobs.

We hope you enjoy this issue.

technical: Why You Should Use Eyecatchers

If you look around the web, you'll see lots of articles and blogs with ideas on how to improve the resilience of your program. Indeed, you may find a couple of these on the Longpela Expertise website. But there's one technique that isn't really talked about, but can help in making programs more resilience, and debugging of errors easier. Eyecatchers.

...more

technical: Maintaining Code That Sucks

It took me a week. 40 hours poring over a mere 500 lines of code. Just to find out what on earth the module did. And this code was terrible. No comments: NONE. No subroutines. If that wasn't bad enough, it used undocumented APIs. Terrible. Oh yes, and its performance was horrible: my job was to get it to run faster.

..more

opinion: Does Too Much Change Management Actually Reduce Resilience?

At one site I was working, there was little change management. I could basically make any change I wanted, no questions asked. However, with a change in management, change management was introduced. I now had to 'package' up my changes, create batch jobs to implement them, justify the reason for the change, and have someone review it. And something interesting happened: my changes were better. Fewer issues, better tested and reviewed, safer. But can change management go too far?

..more