Zowe CLI: Getting started with Team Config.
{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:
- create a Zowe CLI team config
- extend the config for additional system access
- 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:
zowe.config.json
zowe.schema.json
(not meant for direct edits but assists w/JSON editing)
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:

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:
- manually change the
defaults
setting inzowe.config.json
from"zosmf": "sys1",
to"zosmf": "sys2",
- issue a command to change the default,
zowe config set defaults.zosmf sys2
- specify the different connection on a zowe CLI command via the
--zosmf-prof
option:

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:

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:

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
:

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.