Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zos-console issue command ends with Return Code 5 Reason Code 7 #1843

Closed
recaph opened this issue Nov 2, 2023 · 10 comments
Closed

zos-console issue command ends with Return Code 5 Reason Code 7 #1843

recaph opened this issue Nov 2, 2023 · 10 comments
Labels
enhancement New feature or request priority-low Legit issue but cosmetic or nice-to-have Stale

Comments

@recaph
Copy link

recaph commented Nov 2, 2023

Describe the bug
I have two lpars where I am trying to submit commands like following. It seems to work on lpar1 but when I submit on similar command on lpar2 in a few minutes after lpar1 it fails with following error. Either CLI should suggest how to can correct it like additonal parameters or work. Error is confusing.

zowe zos-console issue command 'P JOBNAME'
19:01:13  Command Error:
19:01:13  z/OSMF REST API Error:
19:01:13  Rest API failure with HTTP(S) status 500
19:01:13  reason:      Failed to create console due to TSO/E CONSOLE command got an error. IKJ55303I THE CONSOLE COMMAND HAS TERMINATED.+    
19:01:13  return-code: 5
19:01:13  reason-code: 7
19:01:13  
19:01:13  
19:01:13  Error Details:
19:01:13  HTTP(S) error status "500" received.
19:01:13  Review request details (resource, base path, credentials, payload) and ensure correctness.
19:01:13  
19:01:13  Protocol:  https
19:01:13  Host:      lpar2.net
19:01:13  Port:      1443
19:01:13  Base Path: 
19:01:13  Resource:  /zosmf/restconsoles/consoles/defcn
19:01:13  Request:   PUT
19:01:13  Headers:   [{"Content-Type":"application/json"},{"X-CSRF-ZOSMF-HEADER":true}]
19:01:13  Payload:   { cmd: 'P JOBNAME', async: 'N' }

Describe your environment

  • Zowe CLI version installed (run command zowe --version): latest (7.18.9)
  • Installed plug-ins and their version numbers (run command zowe plugins list --short): @zowe/cli
  • Node.js and NPM versions installed (run node --version, npm --version): NodeJS 16
  • Environment variables in use: CentOS 7
  • Operating system and version: z/OS 2.5
  • Shell/terminal (bash, cmd, powershell, etc...): bash
@recaph recaph added bug Something isn't working new The issue wasn't triaged yet labels Nov 2, 2023
Copy link

github-actions bot commented Nov 2, 2023

Thank you for creating a bug report.
We will investigate the bug and evaluate its impact on the product.
If you haven't already, please ensure you have provided steps to reproduce the bug and as much context as possible.

@gejohnston
Copy link
Member

To get a more clear display of your error, you can set the environment variable named ZOWE_V3_ERR_FORMAT to true.

However the primary information of the error message will remain the same. You are getting an HTTP 500 error code, which indicates that the error occurs on your server. This implies that the problem has to do with your working environment on your z/OS server.

The return-code=5 and reason-code=7 are being returned from z/OS. You will have to identify why your console command fails on your z/OS system. You can look up those z/OS codes to identify more specific details about the error. One guess is that you may not have authority to create a console on lpar2.net?

The command that you issued is correct. When your environment is correct, the following is an example of successful output of this command:

> zowe zos-console issue command 'P JOB91659'
 IEE341I JOB91659          NOT ACTIVE

To further isolate the problem, here are a couple of things to try:

  1. Can you issue a different zowe command to that LPAR? Maybe you will find that the zos-job commands can accomplish your goal instead of using console commands.
> zowe zos-jobs list jobs
jobid    retcode jobname  status
JOB91659 CC 0000 JOBNM1   OUTPUT
TSU91610         JOBNM2   ACTIVE
TSU91433         JOBNM2   ACTIVE
TSU91353         JOBNM2   ACTIVE
TSU90829         JOBNM2   ACTIVE
  1. Can you directly login to the lpar2.net console and issue your command? For a large number of cases, the user cannot natively perform that operation on their mainframe. When that is the case, zowe will never be able to perform that operation for you.

@recaph
Copy link
Author

recaph commented Nov 4, 2023

To get a more clear display of your error, you can set the environment variable named ZOWE_V3_ERR_FORMAT to true.

However the primary information of the error message will remain the same. You are getting an HTTP 500 error code, which indicates that the error occurs on your server. This implies that the problem has to do with your working environment on your z/OS server.

The return-code=5 and reason-code=7 are being returned from z/OS. You will have to identify why your console command fails on your z/OS system. You can look up those z/OS codes to identify more specific details about the error. One guess is that you may not have authority to create a console on lpar2.net?

The command that you issued is correct. When your environment is correct, the following is an example of successful output of this command:

> zowe zos-console issue command 'P JOB91659'
 IEE341I JOB91659          NOT ACTIVE

To further isolate the problem, here are a couple of things to try:

  1. Can you issue a different zowe command to that LPAR? Maybe you will find that the zos-job commands can accomplish your goal instead of using console commands.
> zowe zos-jobs list jobs
jobid    retcode jobname  status
JOB91659 CC 0000 JOBNM1   OUTPUT
TSU91610         JOBNM2   ACTIVE
TSU91433         JOBNM2   ACTIVE
TSU91353         JOBNM2   ACTIVE
TSU90829         JOBNM2   ACTIVE
  1. Can you directly login to the lpar2.net console and issue your command? For a large number of cases, the user cannot natively perform that operation on their mainframe. When that is the case, zowe will never be able to perform that operation for you.

I do have authority to submit the commands on both the lpars and the specified zowe command works when run in isolation ie after a long time.. only second command fails if submitted on different lpar .. lpar 2 followed by lpar 1 leads to same error…

can you clarify your first point - how zos-job will accomplish my goal… can you suggest what that command will look like.. which is equivalent to mine..

And I don’t understand how list jobs is same as purging or starting a job especially with only job name as input…

@gejohnston
Copy link
Member

I did not mean to imply that list-jobs would accomplish your objective. It was just an example to confirm that you can run zos-jobs commands on LPAR2. You could then review the set of zos-jobs commands to see if any fit your needs (perhaps cancel or delete?).

If I understand your situation correctly, you can successfully issue your console command to LPAR2, but if you first issue your console command to LPAR1, and then issue the same Zowe command that originally worked on LPAR2, it fails on LPAR2. Is that correct?

The only command that you identified in your issue is:

zowe zos-console issue command 'P JOBNAME'

Can you describe or show how you switch from LPAR1 to LPAR2?

@adam-wolfe adam-wolfe added needs-more-info and removed new The issue wasn't triaged yet labels Nov 6, 2023
@recaph
Copy link
Author

recaph commented Nov 6, 2023

@gejohnston issues goes something like below... I am able to download uss files, list jobs etc. Issue seems to be specific to zos-console....

C:\Users\myid>zowe zos-console issue command "P JOBNAME1" --host LPAR1 --port 1443 --user xxx --password xxx
 IEE341I JOBNAME1          NOT ACTIVE


C:\Users\myid>zowe zos-console issue command "P JOBNAME2" --host LPAR2 --port 1443 --user xxx --password xxx
Command Error:
z/OSMF REST API Error:
Rest API failure with HTTP(S) status 500
reason:      The requested EMCS console has already been created in other TSO/E address space
return-code: 5
reason-code: 10


Error Details:
HTTP(S) error status "500" received.
Review request details (resource, base path, credentials, payload) and ensure correctness.

Protocol:  https
Host:      LPAR2
Port:      1443
Base Path:
Resource:  /zosmf/restconsoles/consoles/defcn
Request:   PUT
Headers:   [{"Content-Type":"application/json"},{"X-CSRF-ZOSMF-HEADER":true}]
Payload:   { cmd: 'P JOBNAME2', async: 'N' } 

@gejohnston
Copy link
Member

While investigating similar issues (as I noticed your did also), I found the following two issues with the same root cause:

zowe/zowe-explorer-vscode#523
zowe/zowe-explorer-vscode#1667

z/OS does not permit the same console name to be used against 2 LPARs in the same SYSPLEX. The default console name used by zosmf (and thus by the zowe CLI) is used by both CLI commands. Thus, z/OS detects the same console name on 2 different LPARs.

The existing GitHub issues request that a new console name property be added to the zosmf profile type. No work on that enhancement is currently planned.

A fairly simple alternative exists for CLI users. By specifying the --console-name parameter on your zowe command line, you can specify one console name for LPAR1 and a different console name for LPAR2.

@adam-wolfe
Copy link
Contributor

Because Zowe CLI has the --console-name option, we decided to relabel this issue as an enhancement request with the enhancement being to add a profile property that allows users to specify console name in their profiles/configs.

@adam-wolfe adam-wolfe added enhancement New feature or request priority-low Legit issue but cosmetic or nice-to-have and removed bug Something isn't working labels Nov 8, 2023
Copy link

github-actions bot commented Nov 8, 2023

Thank you for raising this enhancement request.
The community has 90 days to vote on it.
If the enhancement receives at least 5 upvotes, it is added to our development backlog.
If it receives fewer votes, the issue is closed.

@t1m0thyj t1m0thyj moved this to Low Priority in Zowe CLI Squad Dec 26, 2023
Copy link

github-actions bot commented Feb 6, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@github-actions github-actions bot added the Stale label Feb 6, 2024
Copy link

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Feb 20, 2024
@github-project-automation github-project-automation bot moved this from Low Priority to Closed in Zowe CLI Squad Feb 20, 2024
@adam-wolfe adam-wolfe added for-review To be reviewed in an Eng & Prod Mgmt meeting and removed for-review To be reviewed in an Eng & Prod Mgmt meeting labels Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority-low Legit issue but cosmetic or nice-to-have Stale
Projects
None yet
Development

No branches or pull requests

3 participants