What You Need to Know About JavaScript on the Mainframe
Strategy| by Jerry Rackley

In 2017, the rumors about Node.js on the mainframe were confirmed! Since then, there’s been a crescendo of interest and information about JavaScript on the mainframe. HostBridge has a strong vested interest in JavaScript on the mainframe, having pioneered the use of JavaScript on the host over 10 years ago as a CICS integration and orchestration layer. Now that Node.js has joined us on the host, we’re getting questions: are these two instances of mainframe JavaScript interchangeable? When would a shop use one over the other? These are excellent questions, and this post will describe the current state of JavaScript on the mainframe in hopes of bringing some clarity to the current options.

The above-referenced post on the IBM blog announcing the availability of Node.js on z/OS includes this statement: “Enterprise developers can now take advantage of the enormously popular and growing technology on IBM Z.” We’re delighted that JavaScript’s prominence as a mainframe solution is growing – but – JavaScript has been available on z/OS from HostBridge for more than a decade. HostBridge customers are using the HostBridge JavaScript Engine (HB.js) to integrate CICS applications with middle-tier apps, and to do orchestration with them (watch our technical JavaScript coding tutorial by clicking here). Our customers are running hundreds of millions of transactions a day through HB.js-created scripts that provide an API to CICS applications or make them available as services. To understand how well this integration strategy performs, read the results of a recent, customer benchmark.

Regardless of who you choose to award bragging rights to for getting JavaScript on the mainframe, it’s a win for everyone to have the ability to leverage it on the Z platform. Enterprises can use JavaScript on the host, in the middle-tier, on the client, in the browser, or anywhere in the hybrid IT ecosystem. There’s a lot of potential energy for the enterprise to exploit where JavaScript is concerned. With HB.js and now Node.js on the mainframe, enterprises have powerful options at their disposal for enabling the mainframe to exist as a fully-functioning member of a hybrid IT strategy. So which instance of JavaScript on the mainframe should an architect choose? The answer depends on what the requirements are, which the rest of this article will detail.

Competitive or Complementary?

The biggest misunderstanding around HB.js and Node.js is the incorrect assumption that they compete with one another. In reality, they are suited for different tasks, because they have different architectures and functions. Yes, both are JavaScript, and developers writing scripts have very shallow learning curves moving between these solutions. But the ideal uses for each solution are quite different. So HB.js and Node.js are in fact quite complementary, and it is very likely that an enterprise will use both to facilitate its hybrid IT strategy.

Ideal Uses

What are those ideal uses? The best way to think of Node.js is as an application server on the host. If you have need to run a JavaScript application on the mainframe, Node.js provides a great platform for doing that. The best way to think about HB.js is as an integration and orchestration layer on the host. When your requirement is to make CICS applications available via an API or as services, HB.js makes it easy to develop and deploy high-performing integrations in JavaScript. The compelling reason to have either instance of JavaScript on your mainframe is the same: keeping the application or integration layer close to the data minimizes latency and improves performance.

There are a few key differentiators that reveal why HB.js is the preferred integration and orchestration solution:

  • HB.js supports integration with a broader range of applications. Node.js provides an Invoke Service function that enables calls to CICS COMMAREA programs. For visual CICS applications, however, HB.js provides functions and to integrate them without screen scraping. For example, HostBridge supports even the use of OCCURS DEPENDING ON when it is part of an application’s source code.  Whether COMMAREA or visual CICS transactions, HB.js can handle a much wider variety of data types.
  • HB.js is zIIP-enabled. Why should you care? A concern we often hear from IT organizations is that they don’t want to add workload to the host, for reasons of cost or capacity. Even when performance gains and latency reduction are significant, there is sometimes still reluctance to use general processor cycles for integration and orchestration work. The scripts created with HB.js will run on the zIIP, eliminating the need to use general processor cycles. Node.js is not currently zIIP-enabled.
  • HB.js architecture exploits the open transaction environment (Open TCB). Because HB.js exploits Open TCB, it can have any number of threads active at the same time. Node.js has a single-threaded architecture. Developers who write JavaScript using Node.js must stay aware of its single-threaded nature, but this is not an issue for HB.js.

A summary of differences between Node.js and the HostBridge JavaScript Engine on the Mainframe.

In summary, the ideal applications for HB.js and Node.js on the mainframe are different. HB.js is the best solution for making CICS applications available via a JavaScript-created API or exposing them as a service. Node.js is the best choice for running Node.js applications on z/OS. Enterprises that have IBM mainframes are operating in hybrid IT environments, where integration is a critical requirement. Both HB.js and Node.js are important technologies to enable the mainframe’s full participation in hybrid IT.

Try HB.js on your mainframe for free: read about our no-cost, Pilot Application Program that lets you test HB.js on your system and with your applications. To learn more, reach out to us using the contact information found at the bottom of this page.