Zowe SDKs and Zowe CLI

{Core} “The Open Mainframe Projext’s Zowe offers modern interfaces to interact with z/OS and allows you to work with z/OS in a way that is similar to what you experience on cloud platforms today.” — zowe.org

One modern way to interact with cloud platforms is through Software Development Kits, (e.g aws, firebase, etc…). Although we (Zowe) don’t yet meet the full definition of SDK, we’re heading there.

The goal of a Zowe SDK is to make the Open Mainframe Project’s Zowe services (and by extension, the mainframe) easier to use by providing reusable code for common mainframe operations in popular languages and runtime libraries.

First Steps: Languages & Runtimes

Since @zowe/cli is a Node.js application, we’ll first work to publish discrete pieces of the library that makes up the CLI as individual npm packages. This will serve as the Zowe Node.js SDK (more on this later).

We also have the beginnings of a Zowe Python SDK thanks to a contribution by Guilherme Cartier.

Beyond that, some Zowe components are written in other languages, like Java and JavaScript / TypeScript (for browsers, not Node.js). The SDKs for these languages may come next in line.

Node.js Example

We already have a write-up on how reusing Zowe code can help you quickly build new applications.

While this is possible today, we want to be more deliberate in describing how to import and reuse Zowe code. The plan is to have looser coupling between packages so that you can cleanly import just the pieces that you need. If you want to write some Node.js code to retrieve a mainframe data set, you should only need to import something like the zowe/zosfiles-sdk (package names subject to change):

See line 2 and line 17

Zowe CLI Repo Updates

The green parts will be new `code`

The Zowe CLI repo and imperative are structured after several popular npm repos:

• angular
• jest
• nestjs

Each of these repos has a higher-level package.json and contains a packages folder. These packages contain reusable libraries for more granular operations. Since they’re each published separately, each package has its own:

• README.md
• .gitignore
• package.json
• tsconfig.json

Likewise, you can expect individual packages in the @zowe/cli repo to be published (using something like lerna) as separate artifacts (although we won’t break @zowe/cli or the way it’s distributed).

So, in the near term, you might see the zosjobs package published as @zowe/zosjobs-sdk. We won’t change the way internal packages import each other (at least not at this time) as we begin to publish these smaller pieces; we plan to focus first on publishing individual pieces.

Lastly, we may adjust the repo name to better reflect its purpose for the Zowe Node.js SDK and CLI.

Contribute

Help us create these!

Since the Zowe SDK effort is just starting to take shape, it’s a great time to join in and contribute!

In the meantime, we’ll be looking:

• if conformance criteria is applicable for 3rd party SDK libraries
• how to establish consistency between SDKs
• where to publish various SDKs (and guidance on how to do this)

Do you have a favorite language and runtime? Reach out to help shape the Zowe SDK effort or contribute code to make mainframe more accessible in your preferred [programming] language.

Zowe is owned and managed by the Open Mainframe Project that is a Linux Foundation project.

Click the links to learn more about Zowe and more Zowe blogs.