Important Dates: z/OS Red Alert, z/OS 1.13 EOS, zBC12/zEC12 EOM, and 2038/2042

by | May 3, 2016 | Cheryl's List

Here’s a Red Alert and some important dates that should be on your calendar:

Immediately: zEDC Red Alert

As our regular readers will know, Cheryl and I are big fans of zEDC (zEnterprise Data Compression). All of my experience with it has been positive, and all of the feedback we received from our customers has been positive. Sadly, however, we all know that no software is perfect, and zEDC is no exception.

On March 14, 2016, IBM issued a Red Alert for a data loss problem with zEDC. The potential exists for data loss when writing to a zEDC-compressed data set if all the following conditions are met:

  • The program is using QSAM to write to the sequential data set.
  • A CLOSE is issued and there exists a partial QSAM buffer that has not yet been written.
  • All allocated space in the data set is filled.

In this case, the unwritten partial buffer may not be written after CLOSE processing obtains the new extent for the data set. The problem is unique to QSAM; it does not apply to BSAM or other access methods. It applies to z/OS 1.13, 2.1, and 2.2.

The problem is described by APAR OA50061, and the PTFs are available, but an IPL is required to implement it. So if you’re using, or planning to use, zEDC, now is the time to install the PTFs.

Very Soon: zBC12 and zEC12 End of Marketing

On February 16, 2016, IBM announced (US 916-037) the end of marketing for the zEC12 and zBC12 processors. June 30, 2016 is the last date for ordering the processors in RoHS-compliant countries (which include most, if not all, countries in Europe), while December 31, 2016 is the last date to order these processors from the US. These dates also apply to upgrades that require new parts. LIC upgrades (for example, to enable an existing, but uncharacterized, PU) can be ordered up until December 31, 2017.

Soon: z/OS 1.13 End of Support

The end of support (EOS) date for z/OS 1.13 and z/OSMF 1.13 is fast approaching – September 30, 2016. If you still have any z/OS 1.13 LPARs still running, you should have definite plans to complete your migration to z/OS V2. You can pay IBM for a ‘Lifecycle Extension’ agreement for z/OS 1.13, but why would you pay extra to stay on an old release, rather than moving to z/OS V2 with additional function and save the additional cost? If you have a choice, we recommend that you upgrade to z/OS 2.2 instead of 2.1. z/OS 2.2 has many significant new features, and it’s had a very high and successful migration record. “Easiest migration ever!” said one of our readers. While confirming the EOS dates at http://www-01.ibm.com/software/support/lifecycle/index_z.html, we also noticed that z/VM 5.4 has an EOS date of December 31, 2016.

Someday: Who’s worried about 2038 or 2042? You should be!

Most of you will remember the Y2K meltdown that had some people thinking that the world would end when all computers stopped working on midnight December 31, 1999. Well, we have another of those dates coming up on September 17, 2042 (just before midnight, to be precise) when the 8-byte TODSTAMP will wrap. But the world won’t end because IBM kindly provided a 16-byte Extended Time of Date (ETOD) timestamp in 1998 that will take us far into the future. Certainly, by now, IBM and most ISVs have converted over to using the ETOD. But you might have some old home-grown programs that will need some updates, or you might need new releases of software in order to support ETOD. We’ve been seeing changes in SMF records for the past 17 years that provide dates and times in ETOD instead of TOD, and expect more to come. Now all you need to do is start using the new fields. J

2038 is known as the UNIX Y2K problem, because the time_t values used in UNIX are signed 32-bit integers that are the number of seconds since 00:00:00 UTC on January 1, 1970, which will wrap (and become negative) on January 19, 2038. IBM notes that all AMODE 31 C/C++ programs will be affected because they use time_t directly. AMODE 64 C/C++ programs are not affected because the compiler generates a signed 64-bit integer for time_t (type long). z/OS 1.9’s Language Environment (the C run-time library) provided a ‘constructed time’ to allow referencing dates beyond 2038 (such as for 30-year mortgages).

So, that’s it. Don’t forget to update your calendars. And stock up on Bitcoins in September 2042, just to be on the safe side!

Subscribe to Cheryl's List