The European Court of Justice has ruled that “Safe Harbor” provisions as they’ve existed for about 15 years are not adequate to protect Europeans’ data privacy interests. The BBC has posted a fairly extensive story on the ruling, and IBM has an official reaction.

If I understand IBM’s official reaction correctly (and the reactions of other technology companies), there’s great concern about regulatory uncertainties and, in particular, inconsistencies. That’s perfectly understandable and sensible. Nobody wants to deal with 28 or more unique data protection rulesets and legal regimes. According to the BBC’s report, the European Commission seems at least aware of that potential problem, which is encouraging.

In the wake of the ruling, businesses and other organizations must have “model contract clauses” in place (and obey those clauses!) in order to transfer personal data from Europe to the United States (and, I assume, to any other countries outside the EU/EEA/Switzerland). Those model clauses require the parties to take due care in how they use and secure Europeans’ personal data — the “rules of the road” for protecting privacy. For about a decade and a half, between Europe and the U.S. specifically, businesses could rely on a single “master” set of rules called “Safe Harbor,” but no more. Fifteen years ago European regulators feared that commercial entities would abuse personal data, inspiring “Safe Harbor.” Now the ECJ recognizes that governments are potentially or actually infringing individuals’ privacy rights, so the Court ruled that “Safe Harbor” isn’t enough.

So what does all this regulatory turmoil have to do with mainframes? As I’ve written before in various ways, businesses and other organizations handling personal data simply need to become much better stewards and protectors of those data. That was true before the ECJ ruling, and it’s even more true now. Mainframes and their middleware (e.g. DB2 for z/OS) are extraordinarily powerful, effective tools to help protect personal data and only to authorize access strictly according to complex, evolving rulesets. Mainframes uniquely minimize data movement and data duplication since they facilitate complex, concurrent information and application processing across a single instance of data. They are also excellent “cloud outposts” if/when they need to be. A single mainframe, even the smallest zBC12 model, is a whole “data center in a box.” The mainframe uniquely offers strict (and certified) security “zones” to preserve personal data separations within a single footprint. So if you build at least the privacy-protecting “System of Record” parts of your cloud infrastructure on IBM z Systems, you can much more easily and cost-effectively roll with evolving regulatory punches.

That’s not to say people like to have to worry about regulatory turmoil, especially if you already haven’t been adequately protecting personal data. (The IT industry has a lot to answer for in this respect, and so do regulators. There’s much work ahead, though only some of that work is a result of this ruling.) Fortunately there are some powerful tools available, mainframes included. Regulators (and courts) get concerned and act when industry fails, so, first and foremost, let’s not fail. Hopefully everybody can agree that privacy and protection of personal data are really, really important. Consistently important we also hope.

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.