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 fontconfig.properties.src 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:

filename.Unifont=/usr/lpp/fonts/unifont/unifont-8.0.01.ttf

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.

As yet more evidence that mainframes are popular, at the DEF CON 22 “Hacker Conference” Philip Young presented techniques to break into (mostly carelessly managed or unmanaged to the point of IT malpractice) z/OS systems. He describes many of his findings on his blog.

I agree with his central point: many, many organizations are performing horribly when it comes to IT security, including mainframe-related security. And he’s got some solid data to back up his critique. For example, in his survey of Internet-connected, TN3270-accessible mainframes, 53% don’t even bother to TLS/SSL-encrypt connections. Yes, that’s right: RACF (or ACF2, or TopSecret) user IDs and passwords, along with everything else, flies across the public Internet in clear text to/from over half the mainframes he surveyed. (And those are the mainframes that are Internet-reachable. I would strongly argue that it’s IT security malpractice not to TLS/SSL-encrypt TN3270 connections across “internal” WANs.) Moreover, among the 47% that do TLS/SSL-encrypt TN3270 connections, only 49% of those have proper server certificates signed by a valid, well-known CA.

I’ll just go ahead and say it: that’s pathetic performance.

It is true that a fraction of the z/OS systems identified in the survey are truly public. For example, there are a few public and university library catalogs on mainframes that are Internet-reachable. There are also some non-mainframes: individuals running usually obsolete and unlicensed z/OS releases on machine emulators without permission. That said, Young’s survey found several major corporations and government organizations with real mainframes that flunked this oh-so-basic security check. Shame on them, really.

I recall helping a particular government get their mainframe services Internet-reachable securely 15 years ago. It’s 2014! WTF? You know when IBM added SSL encryption to TN3270 (and FTP), at no additional charge? Nearly 20 years ago, way back in the OS/390 releases, way before even z/OS 1.1. IBM even added TLS/SSL client certificate authentication to RACF back in the late 1990s. RACF passphrases? z/OS 1.8 (with TSO exploitation of passphrases soon after).

So why are over 75% of Internet-reachable z/OS systems not properly using what IBM has provided in z/OS (and its predecessors) for nearly two decades?

Pathetic. Sorry, but that’s the demonstrated reality. On this point (at least) I agree with Young — or at least heavily sympathize. There’s just no valid excuse here.

So, as a friendly reminder, here are two basic steps you must take, immediately, if you have not done so already:

1. Survey all the connections to your enterprise servers (including mainframes) that are directly or indirectly (via a proxy, for example) Internet- or WAN-reachable, especially (but not exclusively) via TN3270/TN3270E and FTP. Turn on TLS, and turn off the unencrypted ports. (Make sure you have CPACF enabled on your machine at least, and consider getting a CryptoExpress adapter.) Use signed certificates from well-known certificate authorities, and put in place operational procedures for rotating and revoking those certificates. Yes, that includes development, test, “demo,” and training LPARs. (Users are unfortunately likely to have common passwords across systems, so you must take at least basic steps to protect the “softer” systems, too.)

2. Turn on passphrases in RACF (or ACF2, or TopSecret, as applicable), and manage them well.

There are other steps to take, but considering there are so many mainframe operators that haven’t implemented these two very basic security features, I’m addressing a large audience right now.