In my previous post I suggested that I was still thinking about reasonable use cases for Unicode 8.0 on z/OS. I’ve got some ideas now. Here are a few:

1. It will be quite some time before all Web and mobile devices will support all the glyphs in the Unicode 8.0. One useful option is to use Unicode 8.0 font support on z/OS to render a graphical representation of an unsupported glyph (such as a new emoji character) and deliver that graphical rendering to a client device. That substitution approach works beautifully in WebSphere Liberty Profile for z/OS and WebSphere Application Server for z/OS, as examples.

2. Likewise, you can take the same approach when generating billing statements, financial statements, etc. (whether printed or, increasingly, electronic) processed on z/OS. Yes, your monthly bank statement can include new Unicode 8.0 emoji characters, for example.

3. Both of the approaches above can be combined with a persistent BLOB datastore, specifically DB2 for z/OS, so that graphical representations of new characters can be generated once and persisted for better performance and throughput.

On June 17, 2015, the Unicode Consortium released the final Unicode 8.0 specification. The Unicode Standard defines how text (and text-like elements: glyphs, symbols, characters, etc.) ought to be encoded. Unicode 8.0 adds 7,716 characters versus its predecessor version. Among those new characters are several emoji.

In a rush to get your z/OS system emojified? Need to process Cherokee language data next fiscal quarter? No problem! z/OS is open for business. Here’s how you can add a Unicode 8.0 typeface to Java on z/OS (in outline):

1. Download your preferred GNU Unifont font file onto your z/OS system in binary mode. You should place the desired uncompressed/extracted .ttf file in a convenient location in a zFS directory. (/usr/lpp/fonts/unifont would probably be a good location.) Choose a path that is unlikely to be inadvertently overwritten with product installations and updates. Make sure the permissions are set to something reasonable (i.e. read-only).

2. Make sure you have a supported Java Standard Edition release for z/OS installed, preferably the latest. I prefer the 64-bit edition, but the 31-bit edition is also fine.

3. Refer to the “Using non-default system fonts” part of IBM’s SDK Java Technology Edition for z/OS Knowledge Center. (The direct link for SDK Version 8 is here.) Also refer to IBM PM05140. These instructions provide general guidance on how to add fonts (typefaces) to the Java runtime on z/OS.

All you have to do is add the Unifont typeface to the configuration file for your Java installation(s). You’ll find that configuration file in the lib directory within your Java installation path. Within that configuration file you should see a section that begins with this comment:

# Font File Names

Add another line to the configuration file below that section, for example:


Obviously you should make sure you use an appropriate text editor that preserves that configuration file’s character encoding. IBM Explorer for z/OS works well here.

4. Test your configuration. Start by listing all the fonts that Java knows about using this simple Java program. If you see “Unifont” on the list when you run that program on z/OS, you’re off to a great start.

Any program or environment that can take advantage of Java-based services can take advantage of this Unicode 8.0 support. That’s pretty much everything including WebSphere Application Server for z/OS, CICS Transaction Server for z/OS, IMS Transaction Manager for z/OS, DB2 for z/OS, etc. All major programming languages on z/OS can invoke Java code, too.

Please note that IBM doesn’t support the GNU Unifont typefaces. If something breaks you can always let IBM know, but you might be on your own. The ability to add and use non-standard fonts is a supported, documented feature, however. Nonetheless, if the font file you choose is broken, IBM can’t fix that. Also be careful that you understand Java’s font selection algorithms, especially before you put anything into production.

Thanks to Roman Czyborra, Paul Hardy, Unifoundry, and all who devote their time and expertise to develop GNU Unifont.

Admittedly I don’t have many use cases in mind yet for Unicode 8.0 typeface support on z/OS. Maybe you do. Success stories and other reports are welcome in the comments, but please avoid rude emoji.

From time to time I check in to offer brief comments on the state of IBM’s mainframe business when IBM releases its quarterly earnings reports. Unfortunately we can only get an incomplete view since the IBM z ecosystem is much, much larger than server hardware revenues alone suggest. Even so, the server hardware revenues in the earnings reports may offer some clues.

IBM reported a massive increase in IBM z Systems sales in the first quarter. Sales more than doubled versus the year ago period, up 118% (130% at constant currency). Capacity deliveries increased 95%. These are phenomenal results, no question.

These results are partly explained by the fact the first quarter of 2015 was the first quarter of availability for the new IBM z13. IBM only started shipping z13 machines last month (March) in any sort of volume, but even with a partial quarter the results were astounding, even considering that the year ago quarter was well along in the previous model cycle. The results suggest IBM will have strong mainframe momentum into the second quarter and beyond.

It’s fair to say that IBM is becoming (or rebecoming?) more of a full scope mainframe company, partly as a consequence of divestitures and acquisitions. But it’s a new mainframe company because it’s also a cloud company. Becoming both simultaneously is not a coincidence; they’re quite related. The IBM mainframe is the original and best-of-breed cloud services environment, and the mainframe is capitalizing on (and driving) industry trends. Most importantly customers are buying, and how.

Simple math suggests that price per unit of capacity increased a bit versus the year ago quarter. That’s obviously good news for IBM since that means the company had huge sales without resorting to discounting. (Anybody can give away a product, especially a great product, but that’s not a sustainable business.) There is a reasonable explanation, though, and it’s one we’ve seen before. Capacity shipments at the beginning of a mainframe model cycle are heavily physical, weighted toward whole new machines and processors. To some extent capacity pricing inevitably reflects the more physical character of those shipments. In fact some mainframe customers don’t add capacity at all when they order the new model, but they still obviously pay for the machine. Later in the model cycle capacity shipments tend to be less physical, more focused on machine upgrades rather than whole machines, and in the past capacity pricing has reflected that shift to some extent. (We could also be seeing product mix effects within “mainframe capacity.”)

While I think we will see some lower capacity pricing consistent with past model cycles, at this point in history my preference would be to see surging capacity demand (check) and gently declining capacity pricing, model cycle to model cycle. That result is good for IBM, but it’s also good for IBM customers who rightly demand continuing innovation. We’ve reached a point where hardware, including mainframe hardware, no longer represents the lion’s share of IT budgets. It’s more like a mouse’s share, so even if hardware prices fall further IT budgets just won’t materially budge. Moreover, given the increasing difficulties working around the limits of physics and IT budgetary math, I don’t think we can reasonably expect hardware prices to continue falling so far quite so fast. Those increasing hardware design challenges should favor mainframes, as it happens.

Posted in IBM.