Published: July 31 2009, 11:09 AM | 1 Comment(s)
by Reg Harbeck

Wow: I was just reminded that CICS is now 40 years old, thanks to an article at http://www.eweekeurope.co.uk/news/ibm-touts-cics-relevance-40-years-on-1475 which mentions that it was first released on July 8, 1969 - just on time for the first steps on the moon.

Being relatively young for a mainframer, back then I was barely old enough to grasp what was going on as everyone sat glued to their TVs. And I certainly had no idea about CICS.

That changed in June of 1987 when I went from being a PC-AT C programmer to becoming a brand new mainframer and CICS Systems Programmer. I had to translate all of my understanding from ASCII and keyboard macros and graphical interfaces to EBCDIC and 3270 BMS and CICS. And the tables - oh, the tables: everything about CICS was tables, and still mostly assembled using macros back then.

Not to mention that everything began with "DFH" whether it was macros, load modules or message IDs. They tell me it stands for "Don't Forget Hursley" which is still in many ways the home of CICS. (For more about this, and how to pronounce "CICS," see my blog entry of November 24, 2008 about How to Talk Like a Mainframer.)

As my career progressed, all those tables started to go online using RDO (Resource Definition Online) or become superseded - especially in the case of the DFHSNT, or SigNonTable, which was effectively replaced by external security.

Still, before all that happened, one of my favorite techie memories is changing someone's password in a running production region. For various reasons, we weren't able to wait for the next restart, which occurred nightly; in fact, we had to do it immediately. So, I used what I knew about CICS control blocks and tracked down the DFHSNT in memory, then used my recently-acquired knowledge of EBCDIC to modify the password using a hexadecimal replace command. It was a small and very nerdy thing to do, but to this day I still remember the feeling of victory at having been able to do it so quickly and exactly.

Of course, being a new mainframer, I also made my mistakes, including accidentally causing a restart of a critical production CICS region right in the middle of the day. I reloaded a buffer pool module that had all kinds of active pointers in it, and CICS immediately cratered. Believe me, I didn't do that twice.

Today, I still have a nerdy affection for CICS, my first mainframe focus and still a great system. In fact, I even have a light blue CICS golf shirt from SHARE, and I look forward to singing, "These are a few of my favorite CICS!" at the JES2 sing-along Thursday evening every SHARE.

So, happy XL, CICS: may you continue to XL well beyond C!

Share this post:  Email

Share

Published: July 24 2009, 08:11 AM | no comments
by Reg Harbeck

I remember in the mid-1980's when I was taking my Computer Science degree and I learned about one of the original debugging tools.

Back then, I was writing "C" which is the opposite of a self-documenting language. If you don't document your code properly, and sometimes even if you do, it can start to look like a foreign language if you come back to it sometime after first writing it. And even when you are writing it, it may stubbornly refuse to do what you want it to, insisting instead on the picky letter of what you actually told it to do.

To make matters worse, there wasn't any tool available to me to step through the code, examine memory, make changes, restart it, and watch how it behaved. My best option was to use a bunch of printf's (the "C" alternative to COBOL DISPLAY or EXEC CICS SEND statements) peppered throughout the code to see where it went and what values the variables managed to get assigned. Which still didn't make infinite loops much more fun.

That's when I learned about the ten-to-twelve-inch circular debugger. It was the best tool in my arsenal for solving intractable bugs. Here's how it worked:

   Bug:    Try to debug code

                If success then exit

                If something_else_might_work = true then proceed to next method; go to Bug

                If all_possibilities = exhausted then call circular_debugger

                Go to Bug /* this normally works; if it doesn't, you'll be here until dawn */

What made this magical tool so special? The toppings, the mozzarella, and the sauce. It was, of course, a pizza, and in my university days, it was my last best resort to finding and fixing bugs when all else failed.

Then, I joined the mainframe world and began programming in CICS COBOL. And I discovered a product now known as CA InterTest. Suddenly, I could eat pizza for leisure again, and I had time for it, too! As many mainframers now know, it made debugging into an efficient, scientific process that made program development and testing a pleasure.

So, of course, I've been a fan of CA InterTest for a long time - both in its CICS and Batch versions.

Well, it turns out that, like the rest of the mainframe, development and testing tools have continued to advance and enhance since I first used them, too. In fact, the graphical Eclipse environment is available for them as well now - along with many other innovations.

What's the problem, then? Nothing: specifically, like so many other aspects of the mainframe, it's too easy to forget just how powerful and useful it is, because it works so well. But since it keeps getting better, and since we have such a great, complete suite of Mainframe Application Quality & Testing Tools, I thought this would be a good opportunity to highlight this important part of CA's full suite of Mainframe 2.0 management software.

For more about our latest innovations in this area, check out http://www.ca.com/us/webcasts/ondemand/item.aspx?e=200449&eis=2.

Share this post:  Email

Share

Published: July 23 2009, 08:47 AM | no comments
by Reg Harbeck

Before the Internet era, there were two famous characters from Greek mythology associated with Troy: Helen of Troy, the "face that launched a thousand ships," and the Trojan Horse, a hollow wooden statue of a horse that had Spartan soldiers hidden inside, waiting to attack once the horse was brought inside the walls of Troy. (See http://en.wikipedia.org/wiki/Trojan_War or the works of Homer for more details. Note that this Troy should not be confused with CA DB2 Tools Product Manager Troy Coleman, noted blogger and author.)

Today, I'd venture to guess that many more people have heard of Trojan Horses than of Helen, though I also suspect that a significant number of them don't know the origin of the term. Because, of course, as used today, Trojan Horse has come to mean a very specific type of malicious software, or malware - namely, software that appears to offer some benefit, but actually does harm once given the opportunity. (I'll let others philosophize about whether any distributed operating systems would fit this definition.)

None of which changes the fact that people continue to be taken in by Trojan Horses, and Trojan Horses continue to be taken in to people's computers and given the opportunity to do their worst.

Of course, the attitude, culture, practices, hardware and software that make the mainframe such a trusted and secure platform for business computing are also good ways to avoid such invasions.

The problem is, while the people who run mainframes are trusted expert technologists, anyone can, and does, run PCs, leading to all kinds of exposures.

So, it seems like a good way to complete this series of ten mainframe cartoons, with a reminder that scrupulousness always trumps naïveté as an approach to business computing.

Share this post:  Email

Share

Published: July 22 2009, 08:24 AM | no comments
by Reg Harbeck

One of the many things I like about mainframes is how well they work together. Whether you're talking about a geographically distributed DR configuration (e.g. http://www.emc.com/products/detail/software/emc-geographically-dispersed-disaster-restart.htm), using the Coupling Facility to share data between images, or having a full MIMPlex and/or Sysplex environment, if you want to take your processing to the next level, you can bring multiple mainframes together in ways that are even more powerful and functional than a single mainframe.

That's such a great idea that it seemed appropriate to have a cartoon about it:

Share this post:  Email

Share

Published: July 21 2009, 09:15 AM | no comments
by Reg Harbeck

There's a funny sort of dysfunction that is ruling many of today's IT departments. They're so busy dealing with all the squeaky wheels of distributed computing that their staffing levels have gotten completely out of balance. On the mainframe, which is often still handling a majority of their production data and processing, staffing levels have remained the same or gone down, while the staffing levels have gone through the roof for the many distributed computers that handle the remaining minority of data and processing.

This is a problem for a number of reasons.

First, since universities and colleges are not producing IT graduates at a rate that can keep up with exploding demand, it means that it will be harder and harder to find enough qualified people to run the distributed part of an IT organization's computing environment.

Second, it means that, in these times of financial austerity, there is a disproportionately high requirement for expensive staff to handle a small portion of the processing requirements.

Third, in a political worst-case scenario, the exaggerated staffing levels required by distributed IT gives non-mainframers a majority when it comes to political and strategic decisions, which can easily lead to a money-and-functionality-losing downward spiral as the mainframers' voice of reason gets progressively drowned out.

Fortunately, like Winston Churchill (one of my personal heroes), we mainframers "never give up."

But it's also nice to have a bit of encouragement, such as this cartoon offers:

Share this post:  Email

Share