IBM Destination Z - Group home

DB2 for z/OS Goes Multilingual

By Destination Z posted Mon December 23, 2019 03:23 PM


More than once in the past 20 years, it has seemed that DB2 and other relational databases would lose relevance as each new revolution in data storage format or programming approach arrived. Object Databases, XML, remote procedure calls and in-memory databases are good examples. Yet with each of these new technologies, the relational database has incorporated them and ultimately exceeded the value of the standalone offering by combining the new features with familiar relational capabilities.

Fast forward a bit: In the past three to four years, the term NoSQL has gone from a curiosity to a must-have component for many database development organizations. This time, the technology brings not only a new storage format, but also new languages for communicating from application to database.

This NoSQL movement has in large part been driven by line of business application development efforts. The easy install and rapid time required to get an application working have obvious appeal to developers. Part of this development agility is due to the schema-less or flexible-schema nature of the storage formats.

An example of this flexible format can be seen in JSON, which has quickly become not only the preferred messaging format for mobile and web applications but also a popular format for NoSQL document databases. In fact, MongoDB’s JSON document store database has become nearly synonymous with the NoSQL database movement.

In February, DB2 10 for z/OS rolled out support for a new API for managing JSON documents. DB2 11 support followed shortly after, becoming available in June. This capability leverages client and application side code provided a few months earlier with the DB2 for Linux, UNIX and Windows (LUW) delivery. Applications using the same JSON API code can connect to DB2 on either platform (see figure below).

Native Java applications are handled a bit differently than applications written in other languages. The core of the JSON API is a set of Java classes, so native Java applications can code directly to those classes and methods.

For applications written in other programming languages, a different approach is used. Much of the DB2 JSON API is conceptually compatible with the workings of the MongoDB JSON database. For other programming languages, you can use a MongoDB-style program, along with the proper language driver that you can download from a MongoDB community site, and then modify the connection properties to point at the DB2 JSON wire listener program. This is a socket-based, daemon program written in Java that understands the network protocol spoken between a client application and a MongoDB server.

This difference between Java applications and other languages means that Java programs will have access to some DB2 capabilities that these other applications cannot. The other applications are limited to the syntax that the client driver understands, so DB2 extensions are not enabled.


The query and data manipulation syntax introduced by MongoDB was already very popular for its simplicity and natural integration into dynamic programming languages. In June 2013, IBM and MongoDB jointly announced an informal partnership to promote and standardize the MongoDB dialect as the lingua franca of NoSQL document databases, and that is the dialect that is adopted by DB2.

It has been noted that the capabilities and syntax have many similarities with SQL itself. Examples include: 
Insert a record, a blog post by Joe:

db.posts.insert({author:"Joe", date:"2012-04-20", post:"..."})

Find all posts by Joe:

Delete all posts of Joe:

DB2 provides a command line processor for performing ad hoc queries and administration commands. The statements above are in the form that would be used in that command shell.

Using DB2 for z/OS for NoSQL and JSON

There are two main reasons to consider running your NoSQL work on a DB2 for z/OS server:

  • If you are already managing a DB2 subsystem, you can avoid provisioning, staffing and managing a new database server—with all of its unique requirements—by hosting that same back end JSON storage functionality using your existing systems, personnel, tools and training.
  • There are capabilities in DB2 that can enhance and extend what is found in other NoSQL databases. MongoDB, for example, does not support multi-statement transactions. Each statement execution is a single atomic unit—similar to running autocommit. When using the DB2 JSON API from a native Java application, you can invoke commands to begin a transaction, and then control the end of the unit of work with a commit or rollback. Similarly, you can leverage forms of batch SQL processing not available in other NoSQL Database Management Systems.
Culture Clash?

As mentioned earlier, one appeal of many NoSQL databases is the development speed and agility that they afford. With this flexibility comes a measure of independence from database and system administrators. Or, in many cases, these developers act as their own administrators during the early development phases.

The DB2 JSON implementation attempts to preserve this ease of use and low-overhead administration experience for developers. Installing a DB2 for z/OS subsystem may not be a click-and-go operation for some time, but assuming that the developer has access to an existing system, the up-and-running experience should be simple. Once the DB2 subsystem is enabled for JSON API work, the developer should be able to quickly create and use a JSON collection—think something like a table. Or, in the MongoDB pattern, not even create a collection explicitly. If a JSON document insert operation is attempted into a non-existent collection name, the system automatically creates the collection.

This behavior is quite convenient for developers, but may run counter to several site standards in your organization. As you might have guessed, the JSON API uses a regular DB2 table to store the JSON documents. By using DB2’s implicit tablespace allocation, several aspects are taken care of automatically.

By default, you get a universal, partition-by-growth tablespace with the necessary backing unique index created, along with the line of business tablespace and associated objects. However, this lack of control over tablespace and use of the default database container and buffer pool may be unwelcome for some. Look for IBM to provide options in the near future to restore some of that control for those that need it. Meantime, you can control some aspects of administration by locating the tablespace chosen for the table and using ALTER TABLESPACE, for example, to alter the buffer pool used.

Once these backing objects for the JSON collection are created in an acceptable way, there should be little need for further intervention by the database administrator. This is again a shift in what your site may be used to. The schema-less nature of JSON allows developers to add, delete and modify fields with the JSON document and collection as needed. The application development group gains a bit of freedom from working in a strict data model, but also acquires the responsibility for keeping that data coherent and ensuring that the application can work with new and old documents that may be in a collection with very different field attributes.

Installation and Component Pieces

There are several components involved in the JSON solution, as suggested in the figure above. In addition to the required DB2 engine support—in the form of APARs—you will also need to make sure that you have installed the DB2 Accessories Suite 3.1 for DB2 10 or the DB2 Accessories Suite 3.2 for DB2 11 bundles

Also, the Java client side pieces shown in the diagram above are delivered by any DB2 for LUW package at the level or higher.

Learn More

The following links will help you get a quick start:

For developers, there is a series of four DeveloperWorks articles that describe various aspects of the solution. Read the first article in the series, “Introduction to DB2 JSON.” You can jump to any of the others by clicking on the link at the top of the first article, “view more content in this series.”

For administrators, read Informational APAR II14727 for information on installing and configuring the JSON support in DB2.

Bill Bireley, IBM senior software engineer, has worked on a variety of application enablement technologies for DB2 including JDBC, SQLJ, pureQuery, and most recently JSON. Previously, he was a developer in the DB2 for z/OS relational engine.