copy data-set opstion should have replace option and list of members

[Joe-Winchester]

@zszabo14 commented on Thu Aug 13 2020

Is your feature request related to a problem or limitation? Please describe.

1. currently when you copy a PDS member if it has to be replaced error message generated: ISRZ002 Members not replaced - 1 members not replaced, 2 members copied 2, with one command you can only copy one member or all xxxx.yyyy(*)

Describe the experience you'd like

• copy-dataset option must have a --replace yes/no option
• there should be a new option like copy-members --list "member1, membe2, ...memberX"

Describe alternatives you've considered

Additional context if you have to copy multiple members you should initiate multiple commands, I don't know, but this could be an overhead as each command initiates an API connection, maybe does a login also.

I don't know how the ZOWE works in the background, but form login point of view maybe you should consider to:

• use a "session". have an "zowe init-session --profile " option, which logs in and keeps the ZOWE session alive until "close-session"
• ability to list multiple set of parameters for a command, like: zowe zos-files copy data-set ["USER.FROM.SET1" "USER.TO.SET1", "USER.FROM.SET2" "USER.TO.SET2", ... "USER.FROM.SETX" "USER.TO.SETX"]

---

@Joe-Winchester commented on Fri Aug 14 2020

Hi @zszabo14 - this sounds like a great suggestion for an enhancement. I'm moving this to the github repository that the Command Line Interface (CLI) squad use to track and plan their work, where you'll be able to get on their radar.

[zszabo14]

btw, the second option could be implemented for more commands. like: zowe [ zos-files create data-set-classic .... , zos-files copy data-set .... , zos-files copy data-set .... , zos-jobs submit data-set ... , zos-tso send address-space ... , cics install ... , db2 call procedure ... , ] There could be conditions for each command based on the previous return code... ... so, we ended up implementing the complete JCL functionalities for nodeJS :D

[zszabo14]

@Joe-Winchester any update here?

[Joe-Winchester]

Hi @zszabo14. This is a great feature request and apologies there's been no github issue update since you raised it last August.
The CLI squad do prioritize issues to work on based on github upvotes and I know they have a backlog they're working down but I'm not sure where this is in their list. @MikeBauerCA may have more information.

[zszabo14]

@Joe-Winchester How can I open an issue directly for them?

[MikeBauerCA]

@zszabo14 you are in the correct place. As @Joe-Winchester mentioned, increasing the number 👍 will increase the likelihood an enhancement gets picked up. However, I took a quick look. We do now support a --replace option on the zowe files copy ds command when copying PDSs. Can you grab the most recent version from npm and let us know how it works for you? npm install -g @zowe/cli@zowe-v1-lts

It was resolved by this PR -> https://github.com/zowe/zowe-cli/pull/867 and closed this issue -> https://github.com/zowe/zowe-cli/issues/808

[zszabo14]

@MikeBauerCA Hi Any update on the other two enhancements? Maybe I should open them separately?

• copy multiple members
• zowe "batch"-es (login once, execute multiple commands)

[MikeBauerCA]

Separating them would give a little more visibility and clarity. You could also encourage folks to upvote the issue to raise its priority (👍).

For zowe "batch" -es (login once, execute multiple commands), what are you trying to achieve? Are you seeking more abstracted commands (e.g. similar to copy multiple members), or increase speed of execution (I would recommend trying out our daemon mode early access feature), or a single sign-on experience (we offer that for core CLI + Zowe API Conformant services that have CLI extensions) or something else entirely?

[zszabo14]

@MikeBauerCA Hi, Thank You for your response. What I would like to achieve is, to increase performance. But this is a bit different than daemon mode. As I understood each zowe command logs in, executes, logs out. So, If I have a script where I execute large number of zowe commands, each will do this which is just waste of time an unnecessary use of resources. So, if a script (batch, bash, jenkins pipeline...) can start with a kind of zowe init --zosmf-profile MYPROFILE command which opens a session and all the others can use this ans just execute, this will save lot of time. In this case you have some other commands between zowe commands AND / OR If you want to execute several zowe commands after each other, you just list them inside one main zowe command, like zowe [ zos-files create data-set-classic .... , zos-files copy data-set .... , zos-files copy data-set .... , zos-jobs submit data-set ... , zos-tso send address-space ... , cics install ... , db2 call procedure ... , ]

[MikeBauerCA]

For the first case (login once to not waste resources), if you login to API ML via CLI, you would received back a JWT token. When this token is used, it does save login instructions. I'll defer to @dkelosky for more details.

For the second case, I do like the idea of being able to store sequences of commands and execute them. This seems like a built-in scripting store within Zowe CLI. It may help folks get started writing scripts. However, I typically guide folks towards other scripting solutions like NPM scripts as described in tip 3 of this blog. This would also allow you to combine Zowe CLI commands with other commands you may wish to run even outside of Zowe.

[zszabo14]

@MichaelABroadcom Thanks NPM scripts are good solutions for web apps. But for operational tasks batch, bash or in pipelines how can it be used?

I will open an other issue, let's keep this for the original topic

[MikeBauerCA]

Here is an example of leveraging a package.json in the development of a Jenkins pipeline - https://github.com/zowe/zowe-cli-sample-scripts/tree/master/use_cases/CI_pipeline. I used gulp for most of the automation in this particular sample. I don't have an open source example of a CI pipeline using only NPM scripts, but that is what I use now instead of gulp.

[zszabo14]

@MichaelABroadcom Thank You! I use groovy inside the pipeline script, like

pds_list.each { pds_name -> env.PDS_NAME = pds_name println("Creating: $HLQ.$PKG_NUMBER.$PDS_NAME") def res = execZOWECommand("create_package") result = res.get("success").toString().trim() if (result == "true") { println("Package PDS created successfully.") env.RC_CREATE_PDS = "success" } else { def ret_code = res.get("message").toString().trim() if (ret_code.contains("-26868")){ println("Package PDS already exists.") env.RC_CREATE_PDS = "success" } else { println("Package PDS creation failed.") env.RC_CREATE_PDS = "failure" result = res.get("stderr") println(result) currentBuild.result = 'failure' failed_stage = 2.4 } } }

execZOWECommand:
case "create_package" : def rc_create_pds = sh (returnStdout: true, script: '''\

!/bin/bash

            STATUS=$(zowe zos-files create data-set-classic "$HLQ.$PKG_NUMBER.$PDS_NAME" --rfj)
            echo $STATUS
            '''.stripIndent())
        def statusJSON = new JsonSlurper().parseText("${rc_create_pds}")
        return statusJSON
        break;

[dkelosky]

You're correct each zowe command must re-establish a connection which will result in verifying credentials via SAF on the server (mainframe) side. Tokens would save time by bypassing the need to go to SAF.

There is also overhead in starting up of Node.js runtime itself. If you measure clock time, I think Node.js startup is longer than the SAF check. Daemon mode helps eliminate the Node.js startup time.

To use tokens and maintain a session, I think we have a few options right now:

• use APIML and Zowe login tokens on commands (we don't support direction-to-z/OSMF tokens)
• use the Node.js Zowe SDK and write custom scripts; when using these methods you can preserve the "session" across operations
• maybe zowe-cli-tasks-plugin could help, but I'm not clear if it saves sessions across each operation. It may save on startup time as well.