Zowe CLI: Getting started with Team Config.

Dan Kelosky
Zowe
Published in
5 min readDec 11, 2023

--

{Core} When a Zowe CLI (or Zowe Explorer) connects to a z/OS server system, it needs to know information about how to reach the endpoint.

  • host
  • port
  • user
  • password
  • etc…

This info is captured into a profile, which also defines the type of the server such as zosmf , ssh , or one of the other 21 Zowe CLI extensions. Profiles are stored in team config files. This blog shows how to get started with team config files. We’ll show examples of how to:

  1. create a Zowe CLI team config
  2. extend the config for additional system access
  3. build scripts to run commands against multiple mainframe systems

Creating a Team Config

The full details for creating Open Mainframe Project’s Zowe CLI configuration are found here.

A quick way to get started is by running the zowe config init command. This command will prompt you to input your mainframe host, user, and password. After answering the prompts, Zowe CLI will create two new files in your current working directory:

Once these files exist, you can manually edit the zowe.config.json file to input/alter additional connection details.

Here’s a minimal example:

{
"$schema": "./zowe.schema.json",
"profiles": {
"sys1": {
"type": "zosmf",
"properties": {
"port": 1443,
"host": "sys1.mainframe.net"
},
"secure": []
},
"base": {
"type": "base",
"properties": {
"rejectUnauthorized": true
},
"secure": [
"user",
"password"
]
}
},
"defaults": {
"zosmf": "sys1",
"base": "base"
},
"autoStore": true
}

To test your config (and connection), run a simple zowe command, e.g. zowe jobs list jobs:

Tip: To debug or troubleshoot your command, append the --show-inputs-only flag:

Example output to see what values are used on a given command

Adding Systems to a Team Config

After creating a working team config, you can add additional system definitions by manually updating zowe.config.json. For example, you can add a second system, sys2, immediately after the closure of the sys1 definition:

        "sys1": {
"type": "zosmf",
"properties": {
"host": "sys1.mainframe.net"
},
"secure": []
},
"sys2": { // <<< added new system here
"type": "zosmf",
"properties": {
"host": "sys2.mainframe.net"
},
"secure": []
},

Then, to run a command against sys2, you can do any of the following:

  1. manually change the defaults setting in zowe.config.json from "zosmf": "sys1", to "zosmf": "sys2",
  2. issue a command to change the default, zowe config set defaults.zosmf sys2
  3. specify the different connection on a zowe CLI command via the --zosmf-prof option:
Targeting different systems via command line

Adding New Profile Types to Team Config

In addition to adding another system to a team config, you can also add additional profile types, such as ssh. For example, after the closure of the sys1 profile, you can add a ssh profile, such as sys1-ssh:

        "sys1": {
"type": "zosmf",
"properties": {
"host": "sys1.mainframe.net"
},
"secure": []
},
"sys1-ssh": { // <<< added new profile type here
"type": "ssh",
"properties": {
"host": "sys1.mainframe.net"
}
},

Then, within the defaults property of zowe.config.json, you can specify the default for ssh to point to the value sys1-ssh . The default profile is the one used if no -p argument is used (as we did earlier with --zomsmf-p or for ssh we would do with --ssh-p to override to a specific profile)

    "defaults": {
"zosmf": "sys1",
"ssh": "sys1-ssh",
"base": "base"
},

With this new profile type, you can now run the zowe uss ... command group:

Example z/OS Unix command “sysvar” and the response when run on a system: SYS1

Similar to above, you can add additional ssh definitions. That is, you can add a sys2-ssh definition and use the --ssh-p command option to target a second system:

Example targeting a second system via ssh

Running Commands Against Multiple Systems

You can display you config options via the zowe config list profiles command:

Since all zowe commands support a --response-format-json (or --rfj for short) you can also obtain this output in JSON (which is easily parseable).

Knowing this, you can write a script to loop through all of your profiles of any type, and run a command against each profile.

This simple Node.js script, called runall.mjs, loops through all ssh profiles and issues a sysvar SYSNAME command against each system:

import { execSync } from "child_process";

const profiles = JSON.parse(execSync(`zowe config list profiles --rfj`)).data;

Object.keys(profiles).forEach((profileName) => {
if (profiles[profileName].type === `ssh`) {
console.log(`running on system : ` + execSync(`zowe uss issue command "sysvar SYSNAME" --ssh-p ${profileName}`).toString())
}
});

You can run the script via node runall.mjs:

Output of the command

Summary

Here we looked at minimal examples of Zowe config targeting one service. We then extend the config to target additional services and then extended it further to target additional systems.

For more information on team profiles, especially how to share userIDs and passwords between multiple profiles using nested and base profiles, checkout the blog post ‘Password Management for Zowe CLI Profiles’.
As you scale up across enterprise deployment also be sure to check out ‘Enterprise rollout of Zowe CLI’

Finding out more

If you enjoyed this blog checkout more Zowe blogs here. Or, ask a question and join the conversation on the Open Mainframe Project Slack Channel #zowe-cli or #zowe-onboarding. If this is your first time using the Open Mainframe Slack Channel register here.

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

--

--

Dan Kelosky
Zowe

Likes programming/automation in mainframe (assembler, C/C++), distributed (Node.js), and web development (Firebase, Angular).