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.

Back in February, 2017, IBM announced “Multi-Version Measurement” for all its z/OS and z/VSE customers. It’s available now. If you are a z/OS or z/VSE licensee, here’s what you should do: order every new release through IBM Shopz.

Why do I recommend an “order everything” strategy? It’s simple. MVM abolishes the infamous “Single Version Charge” (SVC) period. Let’s suppose for example you currently run DB2 Version 11 for z/OS. IBM released DB2 Version 12 not too long ago. Before MVM, if you ordered DB2 Version 12 you would start a 12 month SVC “countdown clock.” You would have 12 months to migrate from DB2 11 to DB2 12, machine by machine, Sysplex by Sysplex, while paying only for the new version. By the 13th month, if you had not completed your migration, IBM had the right to send you a bill for both DB2 versions based on your peak four hour rolling average utilization of each version. A lot of people mistakenly thought that the DB2 bill would double in that event. No, that didn’t happen. Not often, anyway. However, some materially higher charge was likely if you exceeded the SVC period.

I think the original intention behind SVC was a noble one. It’s in everyone’s interest to keep pushing forward, to keep delivering new and better software versions with new and better capabilities. That makes business sense for all concerned, including especially software consumers. In practice (and guessing a bit), SVC might have had the opposite effect to some extent. Migrations take however long they take, even with intense focus and discipline. With a firm deadline, many mainframe software customers understandably did not want to order new versions until they were absolutely sure they were ready. A journey starts with the first step. If you don’t take that first step, you don’t start your journey. If you delay your first step, your at least arrive at your destination later.

Now? No problem! SVC is dead, thank goodness. You can order any/all new versions of IBM mainframe software products right away, and you should. For Monthly License Charge (MLC) products you already license, go right ahead. For One-Time Charge (OTC, a.k.a. IPLA) products, you’ll need to have active Subscription and Support (S&S) to be entitled to new versions. With that understandable caveat, go right ahead. Order every new version that IBM introduces, as soon as IBM introduces it. There’s no additional charge for electronic delivery through IBM Shopz. (There may be an additional charge for ordering on media, so please avoid that. IBM is steadily removing tape media delivery anyway, in favor of DVD media and electronic delivery.)

Once you get your new software releases, install them in at least one development/test LPAR (or z/VM guest) as soon as you can, and start exploring. Your journey can begin without any financial deadline pressure….

….There are still some non-financial deadlines, of course. IBM still has support lifecycles for its products. When there’s a new version, the previous version won’t be IBM supported forever. Please don’t run previous versions forever, or even for very long if you can avoid it. MVM should mean that you move forward faster, not slower, so that you stay at least reasonably current with your software releases. There are also “value deadlines.” The sooner you can put new capabilities to productive use, the sooner you can derive business benefits from them.

Several years ago IBM removed another objection to ordering new software versions: price increases. In the past, IBM sometimes increased the unit prices of new software versions but kept the same unit prices on previous versions. Predictably, perversely, many mainframe customers delayed placing orders for the new versions for that reason alone. They tried to delay version upgrades as long as possible, to delay the corresponding price increases as long as possible. Never mind that the new versions were often more resource efficient than the old versions. Nowadays that doesn’t happen. IBM maintains the same unit price across all software versions of the same product. If there’s a unit price increase or decrease, the price change applies to all versions.

MVM could have been “Double-Version Measurement” (DVM), I suppose. It isn’t. Yes, you can run three, four, or however many software versions you want. Multi means multi. As long as you’re licensed for the product, any number of versions is OK. Sometimes that flexibility makes sense, for a while anyway. For example, if you’re a software vendor then maybe you need to maintain at least one LPAR with all IBM supported releases of WebSphere MQ for z/OS, to support your customers at whatever pace they move forward (hopefully reasonably quickly). With MVM, you can do that.

IBM has extended MVM terms to every z/OS and z/VSE licensee around the world. As far as I know there’s nothing to sign. You can (and should) take full advantage of your new MVM freedoms.

Posted in IBM.