I recently came across a piece of mainframe hardware memorabilia while meeting with some coworkers. This piece immediately below caught my attention as I marveled at the craftsmanship of the PC board and cooling towers. “This is Amdahl hardware!” I exclaimed, as I stopped and discussed this with the coworker.

PC board and cooling towers

cooling tower - a closer look

back of PC

Compare this to the current newest mainframe, the IBM z196. The HSB is still there (see section “2.3 Multi-chip module”), but it’s now called “cache” and is many orders of magnitude smaller in size, faster speed, much larger capacity and is contained the Processor Unit (PU) chip itself.

This Amdahl hardware was the newest and state-of-the-art when it was introduced and many of these novel technologies are still in use today, as we can see in the current IBM z196.

It’s also interesting to note that a similar technology is currently used in most any contemporary personal computer (PC) in that most employ an air cooled heat sink and fan to dissipate excess heat.

Abend-AID punch card

Another familiar piece of mainframe hardware that is now obsolete is the punch card. These punch cards were so ingrained in daily computer operations that Compuware used to send Abend-AID maintenance punch card decks to customers, when needed, bound with rubber bands. You can see one of our few remaining Abend-AID punch cards. We haven’t used these punch cards for years before Y2K, but we still certainly cling to that 80-byte image in many of our applications and routines throughout our daily mainframe activities!

I’m sure many of you have access to other mainframe hardware memories. Post your stories and information!

(Photographs courtesy of and with permission by Thomas Marchant.)

File-AID Data Editor formatted data displays

The data displays provide views of the data formatted based on the layout or optionally viewed in hex showing the EBCDIC characters behind each displayed data byte. This is really quite a trick since the Eclipse interface of the Workbench uses UTF-8 for data display.  

Inherent in the connection of the Workbench to a z/OS host is the ability for the user to specify a code page. This capability allows European and Japanese companies to work with different code pages and still view their data (and their column names and field names) correctly. The File-AID Data Editor has built in binary data transfers which enable special support for Unicode and DBCS data and take the code page into consideration. Extra “checks and balances” are built in to avoid collision detection and  ensure that data is not compromised in its transmission to and from the mainframe.  

The new support is incorporated in the Workbench as a context menu option when navigating the z/OS catalog of datasets using the Workbench Host Explorer View. You just point at a dataset of interest, right-click, and select File-AID Data Editor from the menu of actions. 

Host Explorer Navigation - accessing File-AID Data Editor for z/OS file

In order to use the MVS support, clients must install the latest version of File-AID/MVS (9.3.1 or higher). MVS support extends the File-AID Data Editor’s functionality for browsing and editing DB2 tables for sites that have File-AID for DB2. The guiding concept of the File-AID Data Editor is to provide a similar look and feel, and user interface, when accessing data in DB2, MVS or IMS. 

New technology enables multiple edit windows to be simultaneously open against multiple DB2 tables and z/OS VSAM and sequential files. This new capability gives Workbench users a more powerful interface than the old green screen which was essentially limited to only 2 edit windows open at a time.   

Currently, the File-AID Data Editor is a limited subset of the full functionality of the File-AID for DB2 and File-AID/MVS tools. The File-AID tools on the mainframe are very rich and mature and have been enhanced for nearly 30 years. The File-AID Data Editor is just in its infancy. Feedback from clients will help guide the evolution and enhancement priority for the File-AID Data Editor.  

For example, Compuware Workbench release 3.1.8 was announced on Feb 2, 2012 and contains a new Zoom feature for viewing data in the File-AID Data Editor as well as other improvements. Right click on a character data value and select Zoom from the context menu to view your field in the Zoom dialog.

New Zoom dialog

Later in 2012, look for the introduction of IMS database browse and edit support in the File-AID Data Editor, as well as the inclusion of other highly requested enhancements.

Both the railroad and mainframe each began a new industry. While the railroad opened land-based transportation, the mainframe ushered in the information technology era. Initially, they were both the primary providers in their markets. Their ability to handle the vast volumes of payload – freight and data, respectively – at a relatively low cost placed them each in the leadership position within their industries.

The initial markets for both industries grew and fragmentation occurred. Competition increased and the demise of both mainframe and railroad were predicted. Instead, these market pioneers changed and adapted, and both became the backbone of their respective industries.

The railroads didn’t fade away; rather, they are the core infrastructure of complex freight distribution system. Similarly, the mainframe also is neither dead nor dying. It too is part of the core IT infrastructure of our e-commerce economy. Both the railroad and the mainframe are taken for granted, but quietly continue to carry the majority of the workloads for their industry.

It shouldn’t be surprising that Warren Buffett invested $26b in the railroad industry (Nov. 2009) and $10.7b in IBM, including its mainframe business (Nov. 2011). 

…just additional evidence that there is big money involved with these Big Irons.

 Check out Changepoint’s announcement at www.changepoint-blog.net for more information.

Of course, the 21^st century and all the changes in technology have presented us with countless new normals such as how we communicate with each other, pay our bills and tell time. Being in the technology industry for nearly 30 years, as cliché as it sounds, change has been the only constant. Sometimes I long for the days when work was presented to us in a linear fashion, face to face versus the bombardment of emails with requests for multiple, new projects in a single day. The new normal of work life often means spending more time answering e-mails than actually getting anything done. Work/Life balance? I don’t think so.

But there’s a new normal in the Mainframe IT industry, too…

The Internet not only changed the way we go about our daily lives –  it also changed the nature and importance of mainframe applications. In the 70s and 80s, mainframe applications ran internal back end systems like payroll. Large organizations – the ones that manage our money, handle our insurance claims and process our credit card transactions for example – still store data, and the applications that process that data, on the mainframe for scalability, privacy and financial reasons.

In the new normal of mainframe, web and customer-facing applications interface with legacy applications – making them even more critical and complex. With customer expectations higher than ever and the proliferation of social media, it’s even more important to ensure those applications deliver the quality and performance expected. However, at the same time, the very people who know how to ensure the quality and performance of those applications are facing retirement.

IT managers need to make sure they can continue to maintain and enhance the ever changing mainframe environment by properly staffing and equipping mainframe development resources. Check out Compuware’s latest announcement and new product releases to find out how we can help.  And let us know – how would you define the new normal of mainframe?

Well maybe not that far back. But we will go back to a time in the mid-sixties.

IBM had just come out with System 360 and people had to migrate from the 1401. My understanding of that transition was that it was very hard on those moving to the new hardware. So hard in fact, that IBM made a decision that no one would go through that type of upgrade process again! I don’t think they knew what a big deal that was going to be. But for those of us who’ve been around a while, we know that decades old programs are still running!

They may not have been recompiled in all that time and they still run on the latest hardware using the most current operating system. What a monumental achievement! We all have had the experience where Windows 3.1 programs did not run on Windows 95; Windows 95 programs did not run on Windows 98; Windows 98 programs did not run on Windows NT; and so on. On a mainframe, you can write once and run forever!

And before anyone piles on; yes there were some interesting side-effects of this capability. But that’s another story. Oh…hats off to Jimmy Castor.

The simple answer is — if you have committed to Java applications and want them to perform like non-Java applications on your mainframe, then YES!

Let me provide a real-life example that we experienced.

While testing a new Java release, the programmer received the following error message:

 JVMJ9VM082W – Unable to switch to IFA processor – issue “extattr +a libj9ifa%s.so”

The program continued to run without the zAAP engine on regular non-zAAP processor engines.  However, it ran so slowly that the programmer stated that it would have been better if the program had not run at all! 

Performance is so poor when there are no zAAP engines because (1) the Java program must share the non-zAAP CPUs with other programs. There are usually a lot more of these non-Java programs and because these are shared, elapsed time dramatically increases; and (2) the Java program runs much slower on these non-zAAP CPUs since our z10-BC R03 is a ‘knee-capped’ system. The zAAP CPUs on this system run about than 2.5x faster than non-zAAP CPUs.

The result is orders of magnitude of elapsed time and moreover, since the Java program now runs on the non-zAAP CPUs, your CPU bill will be a lot larger!

Recommendation: If you are serious about or going to be running lots of Java on the mainframe, get a zAAP engine and importantly, do some Java capacity planning. You may need more than one. IBM provides tools in z/OS just for this purpose (Google: “SYS1.PARMLIB IEAOPTxx PROJECTCPU”).

Your users will thank you for it!

(Apologies to Tower of Power)

We all know that what’s cool today, can be totally uncool in a few months time. But we’re not talking about hair styles or shoes. We’re talking code. We’re talking Ops. We’re talking UI. Well, not UI so much. As for code we still program in the one true language, assembler. But we also use C, C++ and Java. That’s right, Java on the mainframe. We have a number of products, Test Data Privacy and Fault Manager to name two, that have Java components running on the mainframe. In fact the Test Data Privacy code is so hot; we’ve applied for a patent.

So when you’re thinking cool; when you’re thinking hip – think of the mainframe.

Arguably the most infamous mainframe specific limit that caused the most effort to resolve was the Y2K limit. Billions were spent to resolve this technical problem that could have been mostly avoided by spending mere millions up front — before it was a problem. 

We’re facing a smaller but similar problem with the year 2042. Like the Y2K issue, the implementation is the root cause. This time, the limit is not just a software limit, but a hardware limit, as the mainframe hardware Time of Day clock (TOD) is stored as a 64-bit number. A solution, of course, is to use the 128-bit TOD clock value, but that requires software changes, and of course, is not available on older mainframe hardware. As was with Y2K, this problem is not confined to the mainframe. Unix has an analogous TOD problem (and a similar solution, too), called the Year 2038 problem, also known as the Unix millennium bug or even “Y2K38.” Like the mainframe 2042 problem, the root cause was in the use of a 32-bit time stamp. The recommended Y2K38 solution involves moving from a 32-bit time stamp to a 64-bit time stamp. This is most easily accomplished by migrating from a 32-bit architecture system to a 64-bit architecture system that will use a 64-bit signed integer time stamp.

Testing limits is a business that really became mainstream during Y2K and it didn’t stop there. The Y2K use case was an adventure for many and yes, good to say, we actually learn from our mistakes. Processes at many companies were changed to continually retest “year” limits to ensure that future coding does not reintroduce a similar problem. In fact, Compuware customers still frequently test and retest their applications using our time and date testing product Xpediter/Xchange.

In summary, to avoid these limit problems in the field requires some upfront acknowledgement, design intent and most important, testing implementation to ensure software can work at or near limits.

Have you planned or changed your software to work past 2042? Let us know!

I remember what I did. I cried. Yep, it’s true. I cried and lamented, “I will never be able to learn this!” After awhile (as my mentor from back then likes to remind me) I became quite confident about my mad JCL skills.

I imagine a recent college graduate with coding skills would have a similar onset of emotion when faced with JCL and a green-screen environment for the first time. And while our grad would certainly be capable of understanding the ins and outs of TSO/ISPF, would he or she have the appetite to do so?

InfoWorld reported that a career as a COBOL programmer could be one of the most secure jobs in IT. Because legacy applications power and will continue to power mainly financial, insurance, retail and government systems, developers with COBOL knowledge are highly sought after and well paid. And, folks agree that it’s a fairly easy to learn, straightforward language.

So there’s good reason to learn COBOL. But what about the mainframe environment as a whole?

TSO/ISPF, JCL, CICS, IMS,  needing to know the multitude of mainframe file types, and a whole set of green-screen productivity tools to help with maintaining, debugging, testing and browsing/editing files. Ugh. Newcomers have most likely grown up on click this, drag that. And while learning to code in school, maintaining, debugging, testing, browsing/editing was often as simple as: type the instruction and click “run.”  

Thankfully, there are options. Innovative solutions can help those new to the field work in the modern environment they’re used to. Experienced folks with mad skills can remain productive in their familiar green-screen environment, and ensure that if they spent any time crying over learning it, it didn’t go to waste.

Want to see just how easy it can be? Watch this!