After looking through IBM’s announcements and others’ reactions to them, let’s take a look at some of the “hidden technical gems” that might not yet be receiving fair attention. In no particular order:

  • IBM and Splunk are working together more closely so that Splunk shops can easily incorporate mainframe-generated data into their operational analytics. The key enabler is IBM’s Common Data Provider for Z.
  • It’s now possible to license z/VM and related products one engine at a time, in sub-capacity form. For example, you can add one z/VM engine and create a z/OS private cloud so developers (among others) can spin up/down their own z/OS instances. Sub-capacity z/VM licensing also applies to Linux and IFLs, of course, and that offers some greater flexibility if you want to have “anchor tenant” Linux LPARs alongside Linux guests on z/VM. z/VM sub-capacity licensing is also useful if you’ve still got some lagging operating system that starts up in ESA/390 mode. The IBM z14 doesn’t support ESA/390 IPL, but z/VM offers a possible workaround (SET MACH ESA) in certain cases, notably for unsupported z/VSE Version 4.
  • IBM instantly released open source patches to support the IBM z14, including patches for the LLVM Clang compiler stack.
  • IBM’s redbook, IBM z14 Technical Introduction, contains a lot of useful details. (A special shout out to Esra Ufacik, one of the authors and a teammate, for her hard work on that book.)
  • There’s been plenty of buzz about the pervasive encryption capabilities in the IBM z14, and rightly so. However, there are lots of other security improvements that are well worth implementing. As a notable example, the Hardware Management Console (HMC) has some beefed up security attributes, including support for multi-factor authentication. The HMC has been available in 1U rack mount form for a while, and that’s handy. If you’re placing a z14 order this’d be a good time to get some new HMCs to pick up the security improvements, too. I believe you can also order new HMCs separately for z13, z13s, and LinuxONE machines if you wish, perhaps in anticipation of a machine order or model upgrade, since the updated HMC works with those models, too.
  • IBM has taken a couple steps to make the z14 at home in a wider variety of data centers. The z14 now shares the z13s’s environmental rating, to tolerate a wider temperature range and potentially save even more on cooling costs. You can also order a z14 with flat doors if you prefer a slimmer machine profile, although the acoustic doors are still preferable if anybody will be in earshot for extended periods and if the rest of the data center is relatively quiet.
  • The IBM z14 is the last “high end” machine to support 100BASE-T Ethernet. Try to get all your physical network connections up to at least 1000BASE-T as soon as you reasonably can. The IBM z14 drops support for 2 Gb/s FICON and FCP storage device connections unless you upgrade (“MES”) a machine to z14 and carry forward FICONExpress8S adapters. And the z14 will be the last “high end” server to allow FICONExpress8S carry forward. The retirement of 2 Gb/s storage links is probably OK. IBM DS6000 (DS6800) Disk Storage supports a maximum of 2 Gb/s, but that particular combination (z14 plus DS6800) probably isn’t too common. The IBM 3592-J70 Tape Controller also tops out at 2 Gb/s, but I don’t think that’ll be common either. Anyway, it’s something to be aware of if you’ve got some now ancient storage devices lying about. You’re OK for now if you upgrade (MES), but it’s “last call” for these slower links.
  • There’s a tantalizing analytics-related “Statement of Direction” in IBM’s z14 announcement suggesting future delivery of a DB2 Analytics Accelerator “onboard,” on the IBM Z machine itself. IBM is careful to characterize this future option as a third option, in addition to the IDAA appliance (PureData System for Analytics) and cloud options.
Posted in IBM.

It’s July 17, 2017. Happy New Mainframe Day, everyone!

Like clockwork, at about 12:01 a.m. New York time, IBM issued this press release to kick off New Mainframe Day. I’ll have more details and comments to offer in due course. In the meantime, it’s clear what IBM is emphasizing: security. The new IBM z14 is designed to encrypt everything, all the time, in multi-layered fashion. The world is far more dangerous than ever, with businesses (and arguably even some governments) literally dying because of security breaches. This new machine hugely helps.

If you have a mainframe, fantastic! Please keep it current. Use it more effectively and more fully to protect your business (or government) from current and emerging threats. ┬áPut your mainframe in full charge of protecting your organization’s vital information and associated information services. And get on board the IBM z14 as soon as you can.

If you don’t have a mainframe, now’s the time to take a fresh look if you want to survive. That might be a mainframe in the cloud (such as IBM’s High Security Business Network for Blockchain) or in a hybrid cloud deployment. Either way, IBM Z is a big part of the answer to the world’s information security calamities.

There are a couple speed bumps on the computing horizon: the years 2038 and 2042. Specifically, January 19, 2038, and September 17, 2042 (UTC dates). How dangerous these speed bumps will be depends on you, dear Millennial Mainframers. Maybe your parents had fun (or “fun”) getting ready for Y2K. Now it’s your turn to help keep the modern world modern.

The 2038 problem is rooted in the classic UNIX time epoch. UNIX and UNIX-like operating systems, and more than a few UNIX-influenced programmers, decided to represent time in the form of a 32-bit signed integer. This integer (time_t) expresses the number of seconds since 00:00:00 UTC on January 1, 1970. (Bell Labs gave birth to UNIX close to that date, and 32 bits seemed like enough back then.) Negative integers are allowed and represent times and dates before 1970. That 32-bit signed integer can represent time up through and including 03:14:07 UTC on January 19, 2038. After that, the 32-bit time_t will wrap around to a negative value representing the very early part of the 20th century. Which won’t be so much fun in 2038, of course.

The 2042 problem is conceptually similar but is, as far as I know, unique to IBM mainframes. In that case a 64-bit unsigned integer counting the number of 2-12 microseconds since January 1, 1900, will wrap.

These two problems are quite close together chronologically, so you ought to view them as two parts of the same basic problem. Fortunately, the 2042 problem should be easier to avoid. IBM expanded the time of day clock in mainframe hardware starting with the Generation 6 ESA/390 processors first introduced nearly 20 years ago. That means every 64-bit IBM mainframe also includes the expanded TOD clock at the system level. There is still some software, including operating system software, that only “sees” the 64-bit fragment of the expanded TOD integer. That’s now changing, so all you should need to do in terms of operating systems and middleware is to stay at least relatively current in your operating system and middleware release levels. Then you simply check code, such as tools and applications, to make sure they also “see” beyond the 64-bit TOD value. IBM has some tools that can help you identify TOD-challenged code, such as this one.

The “bigger fish” is the 2038 problem. UNIX and the classic UNIX time format have spread practically everywhere, and they keep spreading, mostly in the form of the 32-bit Linux kernel on other architectures that are popular for embedded devices. In 2013 the OpenBSD community decided to break strict compatibility and expanded time_t to 64 bits in that operating system. NetBSD took a slightly different approach, preserving compatibility with existing binaries that expect a 32-bit time_t but not allowing any new binary compilations except with a 64-bit time_t value. The Linux kernel is still a work in progress but will likely adopt a similar approach to NetBSD. And that’s just at the operating system level. There is undoubtedly a lot of middleware, tool, and application code inspired by or derived from UNIX (and UNIX-like projects) that adopted the heritage UNIX time format.

The 64-bit Linux kernel uses a 64-bit time_t value, so 64-bit Linux distributions should be safe as far as the operating system goes. The Linux community discontinued support for 31-bit Linux kernels on IBM z Systems and LinuxONE servers a couple years ago, and now only the 64-bit kernels are available. As long as you retire any residual 31-bit Linux instances before 2038, preferably well before, you should be OK from an operating system point of view.

z/OS is a fully certified UNIXTM operating system, but again as long as you stay at least reasonably current you should have no operating system-level problems. You’ll still have due diligence to perform on other code (middleware, applications, tools, etc.) It’s the same with other operating systems (z/VM, z/TPF, z/VSE, etc.)

Unlike the Year 2000 problem, the 2038 and 2042 problems probably will not cause many difficulties before the wraps actually happen. That’s both good news and bad news. The good news is that there shouldn’t be much breakage until then. There’s a lot of bad news: the risk of complacency, the near simultaneous onset of any breakages, and the world’s progressively greater dependence on computing technologies that might break.

I wish you all the best of luck in keeping the world running smoothly.