Zowe: How to save connection parameters: zowe CLI client configuration files

A Zowe client needs information to be able to invoke a service on Zowe on z/OS. Typically these are

  • host address
  • the host port
  • the service
  • the client public key .pem file
  • the client private key .pem file
  • whether to not allow self signed certificates sent from the host
  • the file containing the CA from the host servers.

These options can be given on the zowe cli command, or can be stored in profile files.

You can have multiple profiles, for example, tso, ssh, z/OSMF, production z/OSMF and test z/OSMF.

The above information may be different for different Zowe server instances- such as development, test and production, and for different applications within a Zowe instance.

Some configuration files are stored in the directory pointed to by the environment variable ZOWE_CLI_HOME, on Linux this defaults to ~/.zowe. These files are available where ever your working directory is. You can also have a configuration file in your working directory so is “application specific”.

Zowe supports a hierarchy of configuration files.

  • zowe.config.json within the current directory. If you change directory you will not use it.
  • zowe.config.user.json , the global user file in the ZOWE_CLI_HOME environment variable ( or it might default to ~/.zowe ). This is used for any user specific options (if any)
  • zowe.config.json the global file in the ZOWE_CLI_HOME environment variable ( or it might default to ~/.zowe ). This is used for project wide options.

The Zowe CLI command will start at the top of the hierarchy and go down until it finds the attributes. If it cannot find an attribute it may have a default.

Within the configuration file are different sections, for example

  • a base section with common parameters,
  • ftp, with specific parameters such as the FTP port number,
  • zOSMF, with with specific parameters such as the z/OSMF port number

You can edit the files manually, or use the Zowe config command to make changes.

Sigh

To specify a Certificate Authority(CA) certificate to a zowe cli command, you have to use an environment variable, for example

export NODE_EXTRA_CA_CERTS=/home/colinpaice/ssl/ssl2/doczosca.pem

You need to allow for this when writing your scripts, because different backend servers may have different CA certificates.

See here.

Getting started

Once you are familiar with Zowe and have a better idea of your Zowe configuration, you can develop the various configuration files; what information is user specific, what information is project specific, and what information is Zowe instance specific. Some files are stored in the direction in the ZOWE_CLI_HOME environment variable which defaults to ~/.zowe (on Linux).

If you may have more than one Zowe instance, you may decide NOT to use ~/.zowe, but have directories like ~/.zoweproduction and ~/.zowetest. This means you have to explicitly specify the location.

Get started by creating zowe.config.json in your working directory. See below, or use cut and paste from here, step 3. If you use an IDE such as slickedit or vscode, these have syntax assist, and can highlight errors as you type.

This is a good blog post on initial configuration. But does not cover use of certificates.

The Zowe config command

You can use the zowe config command to create and update the configuration files. The command has options including

This page has a good description of the options.

  • –dry-run : display the changes, but do not apply the changes
  • –edit and –editor name : this opens the file in the specified editor.

Create a zowe.config.json in the current directory

The command

zowe config init

will create a file zowe.config.json in the current directory.

I created a minimum (hand crafted) file to illustrate how the zowe config commands work.

{
"$schema": "./zowe.schema.json",
"profiles": {
"zosmfcp": {
"type": "zosmf",
"properties": {
"port": 443
},
"secure": []
},

"project_base": {
"type": "base",
"properties": {
"host": "10.1.1.2",
"rejectUnauthorized": true
},
"secure": [
"user",
"password"
]
}
},
"defaults": {
"zosmf": "zosmfcp",
"base": "project_base"
},
"autoStore": true
}

Key elements of this file

  • “defaults”:
    • zosmf : For a z/OSMF request,if --base-profile is not specified, use the referenced profile – zosmfcp.
    • common parameters are defined in the base: profile -> project_base
  • “profiles”: There are two profiles defined
    • zosmfcp with the zosmf specific parameters
    • project_base with the common parameters.

When a zowe command is used, the parameter –base-profile can specify which profile to use.

Commands to display and set profile information

My working directory is /home/colinpaice/ssl/ssl2/ .

zowe config list –locations –root

This lists the only the file names used by Zowe CLI.

/home/colinpaice/ssl/ssl2/zowe.config.json
/home/colinpaice/.zowe/zowe.config.json

zowe config list –locations

This shows the file names and their contents

/home/colinpaice/ssl/ssl2/zowe.config.json: 
$schema: ./zowe.schema.json
profiles:
zosmf:
type: zosmf
properties:
port: 10443
secure:
(empty array)
project_base:
...
/home/colinpaice/.zowe/zowe.config.json:
$schema: ./zowe.schema.json
profiles:
zosmf:
type: zosmf
properties:
port: 10443
secure:
(empty array)
tso:
type: tso
....
global_base:
type: base
properties:
host: 10.1.1.2
rejectUnauthorized: true
user: (secure value)
password: (secure value)
secure:
- user
- password
defaults:
zosmf: zosmf
tso: tso
ssh: ssh
base: global_base
autoStore: true

Change a parameter in the file in the current directory

zowe config set “profiles.zosmf.properties.port “30443”

Change/Add a profile (and content) to the the file in the current directory

zowe config set “profiles.zosmf2.properties.port” “40443”

If the profile zosmf2 did not exist before, it will create it, and add the property port

{
"$schema": "./zowe.schema.json",
"profiles": {
...
"zosmf2": {
"properties": {
"port": 40443
}
}
},
...
}

Set a parameter in the file in the user configuration file

zowe config set “profiles.zosmf2.properties.port” “40443” –user-config

set a parameter in the file in the global configuration file

zowe config set “profiles.zosmf2.properties.port” “50443” –global-config

Example of using the set commands

zowe config set “profiles.zosmf2.properties.port” “50443” –global-config
zowe config set “profiles.zosmf2.properties.port” “4444” –user-config
zowe config set “profiles.zosmf2.properties.port” “1111”

  • file zowe.config.user.json has zosmf2.properties.port:4444
  • file zowe.config.json: has zosmf2.properties.port: 1111
  • file ~/.zowe/zowe.config.json: has zosmf2.properties.port: 50443

Using the list commands, and displaying only the above fields I have

zowe config list gives

profiles: 
...
zosmf2:
properties:
port: 4444

zowe config list –locations gives

/home/colinpaice/ssl/ssl2/zowe.config.user.json: 
profiles:
zosmf2:
properties:
port: 4444
defaults:
/home/colinpaice/ssl/ssl2/zowe.config.json:
profiles:
...
zosmf2:
properties:
port: 1111
...
/home/colinpaice/.zowe/zowe.config.json:
$schema: ./zowe.schema.json
profiles:
...
zosmf2:
properties:
port: 50443

So we can see the profile /home/colinpaice/ssl/ssl2/zowe.config.user.json: provided the port value 444.

If I use –base-profile zosmf2, the port used will be 4444.

If I add

zowe config set “profiles.zosmf2.properties.ca” “MYCA”

This create property zosmf2:properties:ca:”MYCA” in file zowe.config.json.

zowe config list gives

profiles:
zosmf2:
properties:
port: 4444
ca: MYCA

so we can see what is being used.

If I use zowe config list –locations I can see the definition is in /home/colinpaice/ssl/ssl2/zowe.config.json

display profiles

zowe config profiles gave

zosmf
tso
ssh
global_base
zosmf2

What are the valid options?

If you used the zowe config init command, then this generated a schema file.

For zosmf this schema has

  • “host”: “The z/OSMF server host name.”
  • “port”: “default”: 443
  • “user”: “Mainframe (z/OSMF) user name, which can be the same as your TSO login.”
  • “password”: “Mainframe (z/OSMF) password, which can be the same as your TSO password.”
  • “rejectUnauthorized”:”Reject self-signed certificates.”, “default”: true
  • “certFile”: “The file path to a certificate file to use for authentication” “certKeyFile”: “The file path to a certificate key file to use for authentication”
  • “basePath”: “The base path for your API mediation layer instance. Specify this option to prepend the base path to all z/OSMF resources when making REST requests. Do not specify this option if you are not using an API mediation layer.”
  • “protocol”: “The protocol used (HTTP or HTTPS)” “default”: “https”, “http”, “https”
  • “encoding”: “The encoding for download and upload of z/OS data set and USS files. The default encoding if not specified is IBM-1047.”
  • “responseTimeout”: “The maximum amount of time in seconds the z/OSMF Files TSO servlet should run before returning a response. Any request exceeding this amount of time will be terminated and return an error. Allowed values: 5 – 600”

The CA certificate to use is specified by an environment variable, and is not a parameter in the profiles.


Zowe: Changing trace on z/OS

Trace within Zowe is a bit confusing. Different components, such as Gateway and Application-Server seems to have different ways of tracing.

As I understand it, you set a global switch for a components trace, restart Zowe, then use a REST API to set or reset subcomponents.

It took me a day or so to be able to change the trace of Zowe components!

There is Zowe documentation on Troubleshooting Zowe API Mediation Layer. Which is incomplete, and missing useful documentation.

The syntax of the logging commands is here

List the existing traces

The documentation says

GET scheme://hostname:port/application/loggers

This didn’t work for me because I was using port 7554. After I tried all of the Zowe ports, the following worked

"https://10.1.1.2:7558/application/loggers"

Where 7558 is the port for zaas.

This returned one long string, with many logical lines of output. For example:

{
"levels": [
"OFF",
"ERROR",
"WARN",
"INFO",
"DEBUG",
"TRACE"
],
"loggers": {
"ROOT": {
"configuredLevel": "INFO",
"effectiveLevel": "INFO"
},
"_org": {
"configuredLevel": null,
"effectiveLevel": "INFO"
},
"_org.springframework": {
"configuredLevel": null,
"effectiveLevel": "INFO"
},
...

},
"groups": {
"web": {
"configuredLevel": null,
"members": [
"org.springframework.core.codec",
"org.springframework.http",
"org.springframework.web",
"org.springframework.boot.actuate.endpoint.web",
"org.springframework.boot.web.servlet.ServletContextInitializerBeans"
]
},
"sql": {
"configuredLevel": null,
"members": [
"org.springframework.jdbc.core",
"org.hibernate.SQL",
"org.jooq.tools.LoggerListener"
]
}
}
}
  • 434 lines for org.springframework….
  • 36 lines for com.netflix….
  • 286 line for io….
  • 63 lines for org.apache…
  • 57 lines for org.hibernate
  • 68 lines for org.ehcache
  • 109 lines for org.zowe.apiml.

Selecting one record type

I used a Bash script

#!/bin/bash 
url="https://10.1.1.2:7558/application/loggers/org.zowe.apiml.zaas.security"
certs="--cert colinpaice.pem --cert-key colinpaice.key.pem"
verify="--verify no"
https GET ${url} $certs $verify

gave

{
"configuredLevel": "null",
"effectiveLevel": "DEBUG"
}

This means org.zowe.apiml.zaas.security was configured as null, but one of org.zowe, org.zowe.apiml, or org.zowe.apiml.zaas was set to DEBUG, and all of the definitions below it were set to DEBUG.

If I set the value of org.zowe.apiml.zaas.security to WARN, then set the value of org.zowe.apiml.zaas to DEBUG, the value of org.zowe.apiml.zaas.security stayed at WARN.

{
"configuredLevel": "WARN",
"effectiveLevel": "WARN"
}

Updating a value

It took me a while to get a script to update the value.

url="https://10.1.1.2:7558/application/loggers/org.zowe.apiml.zaas.security"
certs="--cert colinpaice.pem --cert-key colinpaice.key.pem"
verify="--verify no"
echo -n '{"configuredLevel": "WARN"}' | https POST ${url} $certs $verify
echo "================="
https GET ${url} $certs $verify

This pipes the update {“configuredLevel”: “WARN”} into the https command. This returned no data. If it fails it may return a message.

Changing the hierarchy

Logically changing a value for a.b.c to ZZZZ works as follows

for every element under a.b.c
   if the element's value is null 
   then set element's value = ZZZZ
   else do nothing 

Zowe: What should I used on my client to talk to z/OS?

There are different ways of accessing the z/OS server.

  • You can use a web server. You will need to configure the certificates.
  • You can write your own program, for example in C or Java.
  • cUrl is a very common tool. Handy for small tasks.
  • HTTPie is an easy tool to generate one of commands. The output comes back nicely formatted, with colour. HTTPie is written in Python.
  • Python has good support for TLS and working with back send-servers. You can capture the data in a dictionary to make it easy to process.
  • You can use zowe Command Level Interface (CLI). This uses the best bits of all of the above.

Which is best?

The answer is the old phrase “horses for courses”.

If you want to do a one-of then the above tools are all very similar.

If you want to use multiple back ends, for example production and test, then you need to have code which selects the host, port, certificates, and applications within a z/OSMF or Zowe instance, then you will need to have code which handles this. Zowe CLI has this code built in.

I could write some basic code in about 100 lines of Python to do this – but why bother?

A Zowe developer’s view

I asked a developer what is good about zowe CLI.

The most common use case I see with Zowe CLI is for use in automation/Jenkins. It saves you the trouble of having to write code to handle the REST requests. It also supports the use of plug-ins for other products or services running on z/OS, like Endeavor, ChangeMan, Db2, CICS, etc. to do more than just download/upload files or submit jobs (e.g., you could also interact with a version control system, issue Db2 queries, deploy changes to a CICS region, and so on). 

Regarding output/data types, Zowe CLI commands can also provide json output (by specifying the `–response-format-json` or `–rfj` flag on commands), which is pretty easy to work with in bash scripts using something jq on Linux to parse the output and extract fields that you need.

For example

With –response-format-json

zowe zos-files list data-set ‘COLIN.Z*’ … –response-format-json

Generated

{
"success": true,
"exitCode": 0,
"message": "",
"stdout": "COLIN.ZCONNECT.BETA.ZFS\nCOLIN.ZCONNECT.BETA.ZFS.DATA\nCOLIN.ZFS\n...
"stderr": "",
"data": {
"success": true,
"commandResponse": null,
"apiResponse": {
"items": [
{
"dsname": "COLIN.ZCONNECT.BETA.ZFS"
},
{
"dsname": "COLIN.ZCONNECT.BETA.ZFS.DATA"
},
...
"returnedRows": 44,
"JSONversion": 1
}
}

Without –response-format-json

COLIN.ZCONNECT.BETA.ZFS
COLIN.ZCONNECT.BETA.ZFS.DATA
COLIN.ZFS
COLIN.ZFS.DATA
COLIN.ZFS.DSFS
COLIN.ZFS.DSFS.DATA
...

The first output is easier to post-process.

Some articles on Zowe CLI

Zowe: What does this message mean?

You can use your favourite search engine to look for the message. If it is not found, you can search within the open source.

Thanks to Martin Zeitham for the following.

Each message has prefix, which indicates the server or component. For example ZWEL* is Launcher etc.
There is a command ./zwe diagnose -e messageID to get more details:

./zwe diagnose -e ZWED0020I

gave

This code corresponds to the errors related to the Zowe Desktop and the App Server.

To find the description of this error code, refer to the:

Zowe documentation for Application framework
https://docs.zowe.org/stable/troubleshoot/app-framework/appserver-error-codes

You may also explore reports from other users experiencing the same error by searching
https://github.com/search?q=org%3Azowe+ZWED0020I&type=discussions

I found it quicker to look in the Zowe bin/commands/diagnose/index.js file, which has

And note the ability to see any discussion on the message ZWED0020I in the git repository using

https://github.com/search?q=org%3Azowe+ZWED0020I&type=discussions

Zowe: Problem determination

This is a work in progress as I learn more about debugging Zowe

Startup and processing the zowe.yaml file.

Troubleshooting Zowe Launcher. Creates a trace of the parsing of the Zowe.yaml file.

It is verbose;only use when necessary.

For example

It displays the contents of the zowe.yaml file

MapStart                                                 
zowe:
MapStart
runtimeDirectory:
Scalar: (len=13)/u/tmp/zowep/
logDirectory:
Scalar: (len=17)/u/tmp/zowec/logs
workspaceDirectory:
Scalar: (len=22)/u/tmp/zowec/workspace
extensionDirectory:
Scalar: (len=23)/u/tmp/zowec/extensions

and

path:                                                             
validate JSON value->type=4 specTypeMask=0x4
typeCode=2 shifted=0x4 mask=0x4
validateJSONObject required=[]
accessPath (top is blank):
validate object pname=zowe

Component loggers

I found this doc, I haven’t used it

Customizing Zowe API Mediation Layer logging for Specifies one of the following services: zaas, gateway, discovery, api-catalog, caching-service.

ZSS https trace

In the zowe.yaml

zss: 
enabled: true
port: 7557
crossMemoryServerName: ZWESIS_STD
agent:
jwt:
fallback: true
64bit: true
https:
trace: true

produces a trace in the logs directory

zssServer-2025-05-29-08-39.log.tlstrace

use gsktrace zssServer-2025-05-29-08-39.log.tlstrace >gsktrace.txt

What are my Java options?

See Specifying Java overrides

Zowe tracing.

See Enabling tracing for app-server and zss.

Zowe: Specifying Java overrides

As part of my configuring Zowe, and using Java shared classes, I’ve needed to change the Java parameters in Zowe. I know there is a plan to provide this support – but this is what I’ve done.

Find the start up script.

If you use the Unix command

find zowe/components -name startup.sh

This will list the scripts for the components.

I edited zowe/components/gateway/bin/start.sh and inserted at the top

 COL="/u/tmp/zowec/" 

TAG="GW"
fn="${COL}/java.options.${TAG}"
if [ -f "${fn}" ]; then
set -x
export
exec 1>>${COL}start.log1${TAG} 2>>${COL}start.log2${TAG}
COLIN="-Xoptionsfile=${fn} -XshowSettings "
else
COLIN=""
fi

and at the bottom of the file

    -Dloader.path=${GATEWAY_LOADER_PATH} \ 
${COLIN} \
-jar ${JAR_FILE} &

This code

  • checks for a file java.options.GW in the Zowe instance directory.
  • If this file exists
    • Create log files in the directory
    • Create an override variable (COLIN), specifying the file name, and telling Java to print out the settings.
  • If it doesn’t exist, set the variable (COLIN) to blank
  • When the Java command is issued, substitute the variable COLIN – which is either blank, or the options file and display Java options command.

Create the java options file.

You can use

touch java.options.GW

or edit the the and add content.

The output

It produced output like

VM settings: 
Min. Heap Size: 32.00M
Max. Heap Size: 512.00M
Using VM: IBM J9 VM

Property settings:
XcompilationThreads3 =
Xhealthcenter =
Xjit:count = 0
...
JRE 21 z/OS s390x-64-Bit Compressed References 20241024_16 (JIT enabled, AOT enabled)
OpenJ9 - f45de8e9eb0
OMR - 55ddfd47ab0
IBM - 3c87141
JCL - df334d2be4a based on jdk-21.0.4+7
java.home = /Z31B/usr/lpp/java/J21.0_64
java.io.tmpdir = /tmp
....
xcom.ibm.java.diagnostics.healthcenter.headless.output.directory = /u/tmp/zowec

Locale settings:
default locale = English (United States)
default display locale = English (United States)
...
Security settings summary:
See "java -X" for verbose security settings options
Security provider static configuration: (in order of preference)
Provider name: OpenJCEPlus
Provider name: IBMZSecurity
Provider name: SUN
Provider name: SunRsaSign
...
May 29, 2025 9:30:25 AM sun.security.ssl.SSLLogger log
WARNING: No AlgorithmParameters for sect163k1
May 29, 2025 9:30:27 AM sun.security.ssl.SSLLogger log
WARNING: No AlgorithmParameters for sect163r1
...
Security TLS configuration (SunJSSE provider):
Enabled Protocols:
TLSv1.3
TLSv1.2

Zowe: Planning: How do I protect what Zowe users can do on z/OS?

As part of my planning for Zowe, I wanted to know how I could control what Zowe users can do on z/OS. I could not find any definitions for security profiles, so how do I do it?

It took a few days thinking about this to realise I was looking a the problem the wrong way. The correct way of looking at it, is that Zowe is a transport system for getting requests from a user’s work station to z/OS. This is similar to a 3270 emulator connection to z/OS. You control what the userid can do, and do not try to control what the 3270 emulator can do.

When a userid logs on to TSO through a 3270 emulator, z/OS knows the userid of the address space, and can control access to what resources the userid can access.

When a userid logs on to Zowe there are two paths that can be taken:

  • Zowe can create a TSO address space for the userid, using the CEA facilities. The z/OS® CEA TSO/E address space manager provides services to programmatically start and manage TSO/E address spaces and provides a communications mechanism for use between the caller and the programs running in these managed address spaces.
  • A thread within Zowe can use the pthread_security and change the userid of that thread. It can use your certificate, or a userid and password to validate the user. At the end of the request it resets the userid back.

From a permissions perspective, it does not matter if request came into a TSO address space or as a result of the pthread_security request. The userid is extracted and normal SAF processing is used to manage access to a resource.

But…

Your system may have IPSEC rules which police traffic into and out of TCP/IP on z/OS, for example allow traffic from these external IP address during 0900 to 1700 Monday to Friday, and deny access at any other time.

You might need to have similar rules for connectivity through Zowe. There are several ports used by Zowe and z/OSMF. You need to review what controls you need for these ports to stop unwanted traffic from accessing your system.

Zowe: Which messages to automate

In the Zowe.yaml file is a section sysMessages. This is a list of the messages that are displayed on syslog. You can add messages to these.

The provided list is

  • ZWEAM000I %s started in %s seconds, giving the component and the duration of the startup
  • ZWED0031I The appServer is ready at ipAddress, Plugins successfully loaded: percentage% (successful/total)
  • ZWEL0001I component %s started. A start request was issued for the component
  • ZWEL0002I component %s stopped. A request was made to stop the component
  • ZWEL0006I starting components. A request was made to start the component specified as enable: true in the zowe.yaml file.
  • ZWEL0008I stopping components. A request was made to stop Zowe, and Zowe is shutting down.
  • ZWEL0018I Zowe instance prepared successfully. The pre-starting checks have been completed. This message is followed by ZWEL0006I starting components.
  • ZWEL0021I component %s stopped
  • ZWEL0022I Zowe Launcher stopped. This is the last message that Zowe emits.
  • ZWES1013I ZSS Server has started. Version ‘%s’ ‘%s’
  • ZWES1601I ZSS Server is ready to accept JWT with|without fallback to legacy tokens

Zowe: messages on z/OS when using Zowe

ZWEAO503E The server is not ready to handle the request: /apicatalog/api/v1/

I got this when the ZAAS service was stopped, use the f zowe,appl=DISPLAY to display the status of the various tasks.

You can use f zowe,appl=start(ZAAS) to start it. Check the zowe sysprint data set for any error messages.

I also got the following message in the z/OSMF logs

CWWKS2907E: SAF Service IRRSIA00_CREATE did not succeed because user adcdb has insufficient authority to access APPL-ID IZUDFLT. SAF return code 0x00000008. RACF return code 0x00000008. RACF reason code 0x00000020.

BPXTLS failed: rc=-1, return code=143, reason code=0x0be80000


Error: service has no impersonation; make sure process user has sufficient authority:
z/OS: program control flag must be set, UPDATE access to BPX.SERVER and BPX.DAEMON SAF resources is required
Other platforms: impersonation is not supported

This is actually from BPX1TLS, phread_security_np. There are not many cases where 0be80000 is mentioned. This link mentions PTKTDATA profiles.

LoadBalancer does not contain an instance for the service zaas

This was a tricky one to track down.

Zowe works with z/OSMF. They communicate with certificates. This means the z/OSMF trust store keyring needs the CA of the Zowe server certificate, and the Zowe trust store keyring needs the CA of the z/OSMF server key.

Not only that , if verifyCertificates STRICT is specified in the zowe.yaml file, then Zowe will check the server’s certificate sent from z.OSMF. This includes the altname or altIP, the altIP is the IP address of the connection. An internal IP address is 127.0.0.0. An external IP address is almost anything else. On my system I have addresses 127.0.0.1 and 10.1.1.2 and 10.1.2.6. You can display them using the TSO NETSTAT HOME command.

The zOSMF certificate did not have an altip specified, and so failed the Zowe checks. I had to set the Zowe option verifyCertificates NOSTRICT for it to work.

You can also get this message when the system is partially up.

ZWEAM701E; InvalidKeyException: Unrecognized RSA or RSASSA-PSS key algorithm name

The request to the URL ‘/zaas/api/v1/auth/login’ has failed: SignatureException: Unable to compute RS256 signature. Cause: Unrecognized RSA or RSASSA-PSS key algorithm name. caused by: InvalidKeyException: Unrecognized RSA or RSASSA-PSS key algorithm name. messageAction:Refer to specific exception details for troubleshooting.

It looks you Zowe server needs an RSA key for use with JWT. I changed from an Elliptic key to an RSA and it worked.

Using the web browser

403 Impersonation error

  • Error: response status is 403
  • Download
  • Impersonation error

In the logs/zssServer….log it has

BPXTLS failed: rc=-1, return code=139, reason code=0x0be803d1
Error: service has no impersonation; make sure process user has sufficient authority:
z/OS: program control flag must be set, UPDATE access to BPX.SERVER and BPX.DAEMON SAF resources is required

This is because Zowe does not have access to the profiles.

Action:
Check the profiles are defined, and the Zowe userid has UPDATE access to them.

Header X-Zowe-Auth-Failure: ZWEAG160E No authentication provided in the request.

I actually got the message ZWEAG160E No authentication provided in the request 5 times.

The header is collecting all errors during the treatment of the request. Because the response was 503 the Gateway retries it 5 times. This is strange, but expected behaviour.

I also got an error message in the z/OSMF log /global/zosmf/data/logs/zosmfServer/logs/trace.log

CWWKS2907E: SAF Service IRRSIA00_CREATE did not succeed because user colin2 has insufficient authority to access APPL-ID IZUDFLT. SAF return code 0x00000008. RACF return code 0x00000008. RACF reason code 0x00000020.

Give the userid access to the profile. It may be easier to connect the userid to the group. In my case to group IZUUSER.

I gave the userid access and then got

IYUCM0008W: The user ID colin is not authorized to resource type Navigation Task, resource name Software Services

X-Zowe-Auth-Failure: ZWEAG160E No authentication provided in the request

{
“additionalInfo”: null,
“debug”: null,
“httpStatus”: 403,
“messageID”: “IYUCM0008W”,
“messageText”: “IYUCM0008W: The user ID colin is not authorized to resource type Navigation Task, resource name Software Services.”,
“requestMethod”: “GET”,
“requestUri”: “/zosmf/provisioning/rest/1.0/scr”
}

X-Zowe-Auth-Failure: ZWEAG160E No authentication provided in the request.

I’m not sure about this. Certificate authentication should work, but I needed to specify

–basic –user colin2:password

Python

Fatal (HANDSHAKE_FAILURE): Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16)

This post said

I got the Insufficient buffer remaining for AEAD cipher fragment error when trying to use the Python client (browser and curl worked normally). After lots of trial and error, it seems the error was related to the SSL certificates not having properly configured extension fields, especially keyUsage and extendedKeyUsage, and the fact that urllib3 doesn’t include /etc/ssl/certs/ca-certificates.crt by default.

Another post said “This is an OpenJDK issue with TLS 1.3 “occurring between the OpenShift default route and Mule applications with re-encypt route enabled.”

Keystore file message is confusing

I saw the following in a GW trace record

[35mZWESVUSR [0;39m [36mINFO [0;39m((o.a.t.u.n.N.certificate)) Connector
[https-jsse-nio-0.0.0.0-7554], TLS virtual host [default], certificate type [UNDEFINED] configured from keystore [/u/tmp/zowec/.keystore] using alias [CONN1.IZUDFLT] with trust store [null]

it was confusing because I was not using a keystore file. This looks like a bug in Spring, and can be ignored.

ZWEAG121E Authorization header is missing, or the request body is missing or invalid for URL ‘/zaas/api/v1/auth/login’

  • messageAction: Provide valid authentication.
  • messageReason: The authorization header is missing, or the request body is missing or invalid.

I got this when trying to do a certificate login – and no password.

  • The certificate used did not have a mapping to a userid.
  • The userid was revoked

ZWEAO500E: The service has encountered a situation it doesn’t know how to handle.

Please contact support for further assistance. More details are available in the log under the provided message instance ID.

Case 1

I got this when I changed the a logging value using the REST API. I had

“configuredLevel”: “WARN2″‘

which is invalid.

Case 2

In the log I got

java.lang.ClassCastException: com.ibm.crypto.plus.provider.ECPublicKey incompatible with java.security.interfaces.RSAPublicKey

This is because the key type in my keyring was an Elliptic curve, but the code assumesit is RSA, and uses an RSA function – which does not work with an Elliptic key.

HTTPIE: Https error: ConnectionError: HTTPSConnectionPool(host=…, port=…)

Max retries exceeded with url: … (Caused by NewConnectionError(‘: Failed to establish a new connection: [Errno 111] Connection refused’)) while doing a GET request to URL: https://…

The back end was not active so the TLS hand shake failed.