Git Product home page Git Product logo

zowe-cli's Introduction

Zowe CLI

codecov OpenSSF Best Practices

Zowe CLI is a command-line interface that lets you interact with the mainframe in a familiar format. Zowe CLI helps to increase overall productivity, reduce the learning curve for developing mainframe applications, and exploit the ease-of-use of off-platform tools. Zowe CLI lets you use common tools such as Integrated Development Environments (IDEs), shell commands, bash scripts, and build tools for mainframe development. Through its ecosystem of plug-ins, you can automate actions on systems such as IBM Db2, IBM CICS, and more. It provides a set of utilities and services that help developers, DevOps engineers, and more become efficient in supporting and building z/OS applications quickly.

This repository also contains the Zowe Node Client SDK. The SDK lets you leverage the underlying APIs to build applications that interface with the mainframe.


Contents


Documentation

For information about how to install, configure, and use Zowe CLI, see Zowe CLI Quick Start Documentation. For more detailed instructions, see Zowe CLI Documentation, which also includes examples and tutorials for how to contribute to Zowe CLI and develop CLI plug-ins.

Engineering design documentation is contained in the 'docs' directory in this repository. To view the Web Help for all Zowe CLI commands and contributed plug-ins, see the Zowe CLI Web Help. To view all locally accessible commands, run zowe --help-web. For more use cases and tutorials visit Medium.com/zowe.


Contribution Guidelines

The following information is critical to working with the code, running/writing/maintaining automated tests, developing consistent syntax in your plug-in, and ensuring that your plug-in integrates with Zowe CLI properly:

For more information about ... See:
General guidelines that apply to contributing to Zowe CLI and Plug-ins Contribution Guidelines
Conventions and best practices for creating packages and plug-ins for Zowe CLI Package and Plug-in Guidelines
Guidelines for contributing to Zowe SDKs SDK Guidelines
Guidelines for running tests on Zowe CLI Testing Guidelines
Guidelines for running tests on the plug-ins that you build Plug-in Testing Guidelines
Documentation that describes the features of the Imperative CLI Framework About Imperative CLI Framework
Naming CLI commands and developing syntax Command Format Standards
Versioning conventions for Zowe CLI and Plug-ins Versioning Guidelines
Miscellaneous tips for development Development Tips

Tip:


Building Zowe CLI From Source

Zowe CLI requires NPM version 8 and Cargo version 1.72.0 (or newer) to build from source. Before proceeding, check your NPM version with npm --version and if it's older than 8.x, update with npm install -g npm. To check your version of Cargo, run cargo --version. Cargo can be installed using rustup: https://rustup.rs/. To update Cargo, run the rustup update command.

For developers using Linux, the following packages are required to build Zowe CLI from source:

  • Debian/Ubuntu:
    • sudo apt install build-essential libsecret-1-dev
  • Red Hat-based:
    • sudo dnf group install "Development Tools"
    • sudo dnf install libsecret-devel
  • Arch Linux:
    • sudo pacman -S base-devel libsecret

The first time that you download Zowe CLI from the GitHub repository, issue the following command to install the required Zowe CLI dependencies and several development tools:

npm install

To build your code changes, issue the following command:

npm run build

When you update package.json to include new dependencies, or when you pull changes that affect package.json, issue the following command to download the dependencies:

npm update

Tip:

  • When necessary, you can run the install command again to update dependencies changed in package.json.

Installing Zowe CLI From Source

From your copy of this repository, after a build, navigate to the packages/cli directory, then issue the following command to install Zowe CLI from source:

npm install -g

Notes:

  • Depending on how you configured npm on Linux or Mac, you might need to prefix the npm install -g command or the npm uninstall -g command with sudo to let npm have write access to the installation directory.
  • On Windows, the npm install -g command might fail several times due to an EPERM error. This appears to be a bug that npm documented in their GitHub issues. This behaviour does not appear to be specific to installing the Zowe CLI package. Unfortunately, the only solution that we know of is to issue the npm cache clean command and the npm install -g command repeatedly until it works.

Uninstalling Zowe CLI

From your local copy of this repository, issue the following command to uninstall Zowe CLI:

npm uninstall --global @zowe/cli

Configuring Zowe CLI

Zowe CLI configuration is made up of different profiles. The profiles contain the information that Zowe CLI needs to communicate with the mainframe system. For example, credentials and z/OSMF host name. If you try to use Zowe CLI functionality and you get an error message that Zowe CLI failed to load any profiles, see the zowe profiles create --help command for the group of commands that you are trying to use (if any) to initialize your configuration.

The most fundamental Zowe CLI profile is a zosmf profile. Issue the following command to understand how to create a zosmf profile in Zowe CLI:

zowe profiles create zosmf-profile --help

After you create your profile, you can confirm that the properties of your profile can connect to and communicate with your mainframe system successfully by issuing the following command:

zowe zosmf check status

For detailed information about creating service profiles, creating base profiles, or integrating with Zowe API ML, see Using Zowe CLI.

Tip:

  • When you confirm that your profile connects to and communicates with your mainframe system successfully, you can issue the same command at any time to verify the availability and status of the z/OSMF subsystem on your mainframe.

Zowe Node Client SDK

The Zowe Node Client SDK consists of APIs that enable you to build client applications that interface with the mainframe. Use the APIs to build your own client applications or automation scripts, independent of Zowe CLI.

For information about downloading and getting started with the SDK, see the Zowe Docs. To view the Zowe Node.js SDK doc, see Zowe SDK Docs.

Tip:

  • Alternatively, you can import Zowe CLI into your project to call the Node APIs. However, importing all of Zowe CLI will increase the size of your project. For example, use the following statement to import packages from Zowe CLI:

    import { <interfaceName> } from @zowe/cli
    

    Where <interfaceName> is the name of an interface that you populate (i.e. IIssueParms) or a function that submits requests (i.e IssueCommand).


Example API Usage

For example usage syntax, see the readme for each API package in this repository:

  • Provisioning: Provision middleware and resources such as IBM CICS, IBM Db2, IBM MQ, and more.
  • z/OS Console: Perform z/OS console operations.
  • z/OS Data Sets: Work with data sets on z/OS.
  • z/OS Jobs: Work with batch jobs on z/OS.
  • z/OS Logs: Interact with logs on z/OS.
  • z/OS TSO: Interact with TSO/E adress spaces on z/OS.
  • z/OS USS: Work with UNIX system services (USS) files on z/OS.
  • z/OS Workflows: Create and manage z/OSMF workflows on z/OS.
  • z/OSMF: Return data about z/OSMF, such as connection status or a list of available systems.

Running System Tests

In addition to Node.js, you must have a means to execute .sh (bash) scripts, which are required for running integration tests. On Windows, you can install "Git Bash" (bundled with the standard Git installation - check "Use Git and Unix Tools from Windows Command Prompt" installation option).

After downloading/installing the prerequisites, ensure that you can execute the following commands and receive success responses:

1. `node --version`
2. `npm --version`
3. On Windows: `where sh`

To run Zowe CLI system tests, you need a configured properties file with proper system information present.

A dummy properties file is present in the __tests__/__resources__/properties folder, default_properties.yaml. Using this file as a template, you should create a custom_properties.yaml file within the same directory. Git is configured to ignore all properties files in the properties folder, except for the default_properties.yaml file. If the custom_properties.yaml file cannot be found or loaded, an error with relevant details will be thrown when attempting to run tests.

You can then run the system tests by issuing the following command:

npm run test:system

IMPORTANT! Do not commit configured properties files because they contain security principles and other critical information.


Frequently Asked Questions

How can I install Zowe CLI as a root user on Mac/Linux?

  • You can install the CLI as root so that all users can access the CLI without installing it individually on their user account. As the root user on Mac/Linux, issue the following command:

    npm i -g @zowe/cli@latest --ignore-scripts
    

    WARNING! If you use this method, plug-ins that are installed as root can only be accessed as root. Users must install plug-ins on their user account or share all profiles/plugins/settings/logs with root. You also might encounter npm errors if you install as root. We recommend that Linux administrators implement a user/group environment where permissions can be more carefully controlled.

What is the difference between V1 and V2?

  • V2 uses team profiles and deprecates the Secure Credential Store (SCS) plug-in.

    Connection details can be managed efficiently within one file, promoting a global configuration that can be shared across teams and mainframe services. For more information on how to use profiles, visit Zowe Docs.

    Secure credential encryption is included in the core CLI.


Don't see what you're looking for? Browse questions from the community or ask your own in the Q&A section of our repo.

Project Structure and Governance

Zowe CLI is a component of the Zowe Open Mainframe Project, part of the Linux Foundation.

To learn more about how Zowe is structured and governed, see the Technical Steering Committee Structure and Governance documentation.

zowe-cli's People

Contributors

abastyr avatar atorrise avatar awharn avatar brandonjenkins14 avatar cforrest97 avatar chrisboehmca avatar colin-stone avatar cycaoecw avatar dkelosky avatar ericliuatibm avatar gejohnston avatar giza-jenkins avatar jace-roell avatar katelynienaber avatar kevinloesch1 avatar kristinochka avatar matthewpwilson avatar melvl01 avatar muzikovam avatar namanpatel1112 avatar nike682631 avatar pranay154 avatar sarthakjdev avatar t1m0thyj avatar traeok avatar tucker01 avatar uzuko001 avatar uzust01 avatar zfernand0 avatar zowe-robot avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

zowe-cli's Issues

Technical Currency: Node.js Updates

Personas:
All
Use Case:
To keep brightside current with changes in the Node.js domain
Research Acceptance Criteria:

Acceptance Criteria:

nsp is removed from brightside and imperative devDependencies and replaced by npm audit in test automation
Brightside and plugins are compatible with Node 10 LTS (October 2018): https://github.com/nodejs/Release
Notes:
https://blog.npmjs.org/post/175511531085/the-node-security-platform-service-is-shutting

Parent of #5
Parent of #12

Child of https://rally1.rallydev.com/#/106710376756d/detail/portfolioitem/feature/249706992048

Generalize provisioning automated tests to be system-independent

From @ChrisBoehmCA on September 6, 2018 12:26

Currently the provisioning tests only pass on a certain system that has been pre-configured with a provisioning workflow. It would be ideal to be able to run these tests on any system

Maybe we could store the workflow XML in the test resources directory and call the z/OSMF REST APIs to define the workflow, then delete it at the end of the tests so that it could be run on any system?

Copied from original issue: gizafoundation/brightside#233

Allow output list to be passed to delete jobs

From @tucker01 on October 1, 2018 11:15

I'd like the jobs delete job command to accept a \n delimited list of jobs:

$ zowe jobs ls jobs --rff jobid
JOB00597
JOB00595

So I can perform command substitution to delete/purge a set of jobs:

zowe jobs delete job $(zowe jobs ls jobs --rff jobid)

Copied from original issue: gizafoundation/brightside#270

Improve syntax and usage diagram

From @MikeBauerCA on September 4, 2018 15:15

Canonical
As Michelle, I want clear diagram that shows how to complete my Brightside command so that I can quickly understand how to issue Brightside commands.

bright files create -h 

USAGE 
---- 
bright files  <group>

Where <group> is one of the following: 

GROUPS
---- 

create
....
bright files create -h 

USAGE 
---- 
bright files create <command>

Where <command> is one of the following: 

COMMANDS
---- 

data-set-classic
....

Description
Brightside is enhanced to provide a clear and complete syntax diagram

Acceptance Criteria
Syntax diagram is technically accurate... e.g. optional parameters are in []
*Accept feature with PM when complete (both 227 and 225 in this sprint)
5 point story

Tasks

  • Update Imperative
    Assigned: @AHumanFromCA
    Status: Complete
  • Confirm changes with @jelaplan
    Assigned: @AHumanFromCA
    Status: Complete
  • Ensure tests pass in zowe-cli
    Assigned: @ChrisBoehmCA
    Status: Complete

Depends on zowe/imperative#105

Copied from original issue: gizafoundation/brightside#225

Application Deployment for COBOL in IMS

From @JTonda on August 27, 2018 17:44

Personas:
Michelle
Ravi
Use Case:
Michelle is making changes to transaction programs that run in IMS. She would like to use Brightside commands to perform deployment into IMS. She'd prefer to have dedicated commands to do this, rather than use brightside's jobs, tso or console interface to perform this.
Ravi would like to automate the deployment of the changes to an IMS test environment whenever code changes are made.

Research Acceptance Criteria:
How can we support IMS Type 1 commands ?
How can we support IMS Type 2 commands ?
How can we provide a command interface to SPOC?
Are 1-3 enough to support the above use cases?
Create PoC
Acceptance Criteria:
Commands in Brightside support deployment and activation of COBOL transaction programs into IMS
New IMS plugin is built
IMS plugin is in OSG
CI/CD for IMS plugin is built

Child of https://rally1.rallydev.com/#/106710376756d/detail/portfolioitem/feature/215034404392

Remove .nsprc from 1.0.0

From @tucker01 on September 21, 2018 12:44

Forgot to delete .nsprc in the 1.0.0 branch (switching to npm audit)

Copied from original issue: gizafoundation/brightside#260

Allow for plugins to enhance how credentials are stored

Allow plugins to influence how credentials are stored.
Credentials are stored in plain text by default.
Only one plugin that modifies this behavior can be installed at a time.
If credentials are stored securely and no secure credential management plugin is installed, inform the user.

Carried to sprint 2
3 points remaining

*Accept feature with PM

Tasks:

  • Design new PMF architecture
    Assigned: @AHumanFromCA && @gejohnston && @lyzla01
    Status: Completed
  • Load infrastructure plugins prior to the imperative overrides loader
    Assigned: @gejohnston
    Status: Completed
  • Modify the Plugin Management Facility to allow for plugins that don't add groups
    Assigned: @gejohnston
    Status: Completed
  • Defer logging of PMF messages until after the logger has been initialized
    Assigned: @lyzla01
    Status: Completed
  • Load credential manager into config object passed into the overrides loader.
    The order, since we have no config, should be the last plugin wins. This will allow the default to win if there are no plugins. Implement a field changeable config file.
    Assigned: @AHumanFromCA
    Status: Completed
  • Modify installer to write overrides to the settings.json file
    Assigned: @gejohnston
    Status: Discontinued
  • Update system test
    Assigned: @lyzla01
    Status: Completed
  • Create integration test scenarios for Imperative
    Assigned: @gejohnston
    Status: Completed
  • Create integration tests in Imperative
    Assigned: @gejohnston
    Status: Completed
  • Create infrastructure plugin example
    Assigned: @gejohnston
    Status: Completed
  • Create infrastructure plugin doc
    Assigned: @gejohnston
    Status: In Progress
  • Incorporate infrastructure plugin doc into official documentation
    Assigned:
    Status: Not Started
  • Publish new version of Imperative
    Assigned:
    Status: Not Started
  • Bump imperative version in Zowe CLI.
    Assigned: @gejohnston
    Status: In Progress
    Parent of zowe/imperative#21

Allow custom line delimiters/headers in the "view all-spool-content"

From @tucker01 on July 11, 2018 17:40

Using the view all-spool-content command, it would be nice to allow custom DD file delimiters in the output:

Currently:

Spool file: SYSPRINT (ID # 101)
...
Spool file: SYSPRINT (ID # 102)
...
Spool file: SYSPRINT (ID # 103)
...

Might be good to allow a custom line delimiter/header:

view all-spool-content --delimiter "---"

--- Spool file: SYSPRINT (ID # 101)
...
--- Spool file: SYSPRINT (ID # 102)
...
--- Spool file: SYSPRINT (ID # 103)

This would avoid the (however unlikely) situation that the delimiter text appears in the output AND provides an easy way to filter out the delimiter lines with grep, etc.

Copied from original issue: gizafoundation/brightside#151

Validate that solution works in an hosted IDE environment

As Michelle, I want to ensure profiles function properly in an hosted IDE environment so that I can interact with z/OS from my Eclipse Che terminal.

Validate with Eclipse Che team that this solution allows for profiles to be easily used in a hosted IDE environment.

No need to reproduce in our own environment. Simply work with the other team.

1 point story

Depends on #7

Determine if Zowe CLI DB2 plugin works with Node.js 10

We should identify issues now so we can prioritize the resulting issues appropriately.

Regression tests are performed and problems are identified.

Carried to Sprint 2
Size 3

  • Create docker images to dynamically choose Node.js version for build/test
  • Test DB2 plugin with docker container

Profile Migration Utility

Allow existing profiles to be migrated from a previous version of Zowe CLI where keytar was used. Includes the migration of profiles from .brightside to .zowe.

Package script as part of the package. Update documentation.
Provide alternative instructions to facilitate profile migration.
Provide package to facilitate migration.
Script to remove credentials from secure store.
5 point story

  • Design
    Status: Completed
    Assigned: @PeteSwauger
  • Create package
    Status: Completed
    Assigned: @PeteSwauger
  • Test program on Windows
    Status: Completed
    Assigned: @PeteSwauger
  • Test program on Linux
    Status: Completed
    Assigned: @PeteSwauger
  • Create script to remove secure credentials on Windows
    Status: Completed
    Assigned: @PeteSwauger
  • Create README to document package and script
    Status: In Progress
    Assigned: @PeteSwauger

Pulled from sprint 2 to 3

CLI and APIML integration

From @JTonda on August 27, 2018 17:43

Zowe CLI Core users would like to access APIs through the APIML so that they can benefit from its various features including high-availability, scalability, and dynamic API discovery.

Profiles can alter the base URL that is used to access the service. In this case, the user can change the URL to the gateway URL (e.g. from https://host1:port1/zosmf/ to https://host2:port2/api/v1/zosmf/).

Note:
API mediation layer needed on DE20

*Accept feature with PM
13 point story

Copied from original issue: gizafoundation/brightside#200

Tasks

  • System Tests: update test properties and test environment setup to be able to execute the tests with and without base path
    Status: Not Started
    Assigned: @ChrisBoehmCA
  • Clean up system test doc
    Status: Not Started
    Assigned: @AHumanFromCA
  • Update the RestClient and Session to use basePath in Imperative
    Status: Done
    Assigned: @gejohnston
  • Update zowe-cli to have a CLI option for "--base-path" (and profile field too)
    Status: Completed
    Assigned: @PeteSwauger
  • Doc everything (Not sure what doc everything means, but I know that Zowe CLI user guide needs updated. Likely Imperative updates).
    Status: Not Started
    Assigned: @JamesBauman
  • Manually test command groups provisioning in zowe-cli
    Status: Completed
    Assigned: @tucker01
  • Manually test command groups zos-files, zos-jobs, zos-console in zowe-cli
    Status: Completed
    Assigned: @PeteSwauger
  • Manually test command groups zosmf, zos-tso in zowe-cli
    Status: Completed
    Assigned: @gejohnston @PeteSwauger
  • Verify that imperative changes do not break CICS plugin
    Status: Completed
    Assigned: @PeteSwauger

Migrate Zowe CLI to Zowe Public Repo and update documentation

Collaborate with the ZLC to move each of the following repositories to the public facing space: Zowe CLI, Zowe CLI Sample Plugin and Zowe CLI plugins (CICS, DB2). Also provide the Imperative SDK to Zowe documentation.

*Accept feature with PM
3 story points

  • Coordinate the scan of the repo through OMP
    Status: Complete
    Assigned: @MarkAckert
  • Update the core build to pull from the new repo
    Status: Closed
    Assigned:
  • Update the db2 plugin build to pull from the new repo
    Status: Closed
    Assigned: @AHumanFromCA
  • Update the cics plugin build to pull from the new repo
    Status: Closed
    Assigned: @AHumanFromCA
  • Update the sample plugin build to pull from the new repo
    Status: Assigned
    Assigned: @AHumanFromCA
  • Remove the system tests from the CICS plugin pipeline
    Status: Open
    Assigned:
  • Publish the tutorials to the doc site
    Status: Complete
    Assigned: @BrandonJenkins14
  • Fix links throughout all of the repos and incoming links from other sites
    Status: Complete
    Assigned: @BrandonJenkins14 @lyzla01
  • Copy over Github issues (github issue mover?) + imperative
    Status: Complete
    Assigned: @JTonda

Pulled from Sprint 2 to 3

Improve error message for missing positional argument

From @MikeBauerCA on September 4, 2018 16:29

Canonical Story Form:
As Michelle, I would like the "missing positional" syntax error messages to include a well-formed example that serves as a model, so that I can adjust my command to match the model.

Current Syntax Error Message:

$ zowe zos-files create data-set-binary

Syntax Error:
Missing Positional Option:
dataSetName

Option Description:
The name of the data set that you want to create

Use "zowe zos-files create data-set-classic --help" to view command description, usage, and options.

Proposed Format:

$ zowe zos-files create data-set-binary

Syntax Error:
Missing Positional Argument:
dataSetName

Argument Description:
The name of the data set that you want to create

Example: 

- Create an empty binary partitioned data set (PDS) with
  default parameters:

      $ zowe zos-files create data-set-binary NEW.BINARY.DATASET 

Use "zowe zos-files create data-set-binary --help" to view command description, usage, and options.

Copied from original issue: gizafoundation/brightside#228

Depends on zowe/imperative#71

zos-files Node APIs are inconsistent with other "core" API sets

From @tucker01 on July 17, 2018 13:17

The programmatic Node APIs in the zos-files group are inconsistent with the rest of @brightside/core

  1. Imports don't include the group name (e.g. import { Download } from "@brightside/core";)

  2. Most @brightside/core APIs return either content (e.g. data set member content) OR the z/OSMF response payload (e.g. z/OSMF jobs document). The file APIs contains "meta" information which causes exploiters of the APIs to process them differently.

  3. The "meta" information includes properties such as commandResponse. The term command is meaningless and confusing in the API context.

Copied from original issue: gizafoundation/brightside#156

Should Brightside file operation handle £ (or other currency character)?

From @lyzla01 on August 16, 2018 18:52

Question originated in Uploading directory changes file name by @dkelosky

Conversation Log:

From dkelosky:

@lyzla01 how does this transformation work with file names that contain a £? in a previous version of brightside, users could not upload to members containing £ because of some data set name validation. Is this regex a form of the same problem?

From lyzla01:

The transformation will not work with £. IBM doc does not mention any other currency character beside $ is valid in a node name of a data set. If we decided to support the special currency character, then we might have to revisit the logic and think if there are other currency characters that we missed.

From dkelosky:

We had an issue open about this from validate. They could not upload a local file with a £ symbol. That was on the old code, so there is no test for this scenario.

If my code page is set differently, can I upload to a data set containing £?:

From lyzla01:

Data set naming rules:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjp100/ikjp10056.htm

The question that we needed to answer is how does other currency character other than $ is valid. Does this a special property of QWS? what happen when we view the dataset via zOSMF?

Copied from original issue: gizafoundation/brightside#184

List command throws error when using an hlq with an archived file

From @norjo14 on July 24, 2018 19:44

When trying to use the list command "bright files list ds" in brightside, if the hlq specified includes a data set that has been archived it throws an error and will not list any of the data sets. This is the error:

Command Error:
z/OSMF REST API Error:
Rest API failure with HTTP(S) status 500
rc: 4
reason: 3
details:

  • DMS2987 DATA SET CATALOGED TO CA DISK PSEUDO-VOLUME ARCIVE
  • DMS2987 CA DISK HAS ARCHIVED NORJO14.CA11.SPFLOG1.LIST
  • DMS2971 DO YOU WANT TO RESTORE THE DATA SET? (Y/N)
    category: 2
    message: ServletDispatcher failed - received TSO Prompt when expecting TsoServletResponse

Error Details:
Resource: /zosmf/restfiles/ds?dslevel=norjo14
Request: GET
Headers: [{"X-CSRF-ZOSMF-HEADER":true}]
Payload: undefined

Copied from original issue: gizafoundation/brightside#162

Create.ts API `cmdType`

From @dkelosky on July 20, 2018 17:50

On this API, :

    public static async dataSet(session: AbstractSession,
                                cmdType: CreateDataSetTypeEnum,
                                dataSetName: string,
                                options?: Partial<ICreateDataSetOptions>): Promise<IZosFilesResponse> {

cmdType should probably be dataSetType:
image

However, if I include CreateDataSetTypeEnum and also dsorg in which appear to conflict (PARTITIONED type with dsorg: "PS"), it seems like my data set is not created. How are CreateDataSetType and dsorg intended to be used?

Copied from original issue: gizafoundation/brightside#158

UX Improvements

From @MikeBauerCA on September 4, 2018 14:29

Personas:
Michelle

Use Case:
As Michelle, I would like improved error messages and syntax usage diagrams so that I can easily understand how to use Zowe CLI.

Acceptance Criteria:
Full and accurate syntax diagrams are provided throughout the help
When a sytax error is encountered, offer a suggestion on the available actions and objects if applicable.

Parent of Improve syntax and usage diagram
Parent of Improve error message for invalid action/object
Parent of Improve error message for missing positional argument

Copied from original issue: gizafoundation/brightside#215
Child of https://rally1.rallydev.com/#/106710376756d/detail/portfolioitem/feature/240744126524

Parent of zowe/imperative#105
Parent of #37
Parent of #35

Update build agents to use node 10

From @tucker01 on September 18, 2018 15:7

We should update the build agent images to use node 10 (or ideally, devise a scheme to test under all supported releases of nodejs).

Copied from original issue: gizafoundation/brightside#255

Disable default usage of Keytar in Zowe CLI

The effective requirement of keytar to use Zowe CLI is burdensome to adoption of Zowe CLI. By default Zowe CLI will not use or require keytar to securely store credentials in the operating system specific credential management. Future plugin infrastructure may be created such that keytar could be re-enabled via installing an infrastructure-only plugin.

Personas:
All
Use Case:
To foster adoption of Zowe CLI and reduce required prerequisites
Research Acceptance Criteria:

Acceptance Criteria:
A user can install and use Zowe CLI with plain-text profiles even if the keytar installation fails.
Profile migration guidance is provided
This change cannot alter Zowe CLI 1.0 behavior
Communicate to Che team whenever keytar removal is complete
Ensure Zowe CLI works in Che with non-keytar profiles
Ensure VSCode plugin will continue to function properly

Parent of #7
Parent of #9
Parent of #16
Parent of zowe/zowe-explorer-vscode#1

Child of https://rally1.rallydev.com/#/106710376756d/detail/portfolioitem/feature/249784471708

Improve error message for invalid action/object

From @MikeBauerCA on September 4, 2018 16:26

When a syntax error is encountered, offer a suggestion on the available actions and objects if applicable.

E.g. bright files create file
file is not a valid object to create. Available objects to create are data-set-binary, data-set-c, data-set-classic, data-set-partitioned, and data-set-sequential.
For example, issue "bright files create data-set-binary user.bin" to create an executable data set named user.bin.
Issue bright files create -h for additional help.

*Accept feature with PM when complete (both 227 and 225 in this sprint)
8 point story

Spike Research in Sprint 5 to determine what is possible to implement in Sprint 6. 1 point.

Research concluded that the above request is achievable within the current architecture. Estimate to complete is now at a 5 point story.

Remaining tasks:

  • Implement coding changes
    Status: In Progress
    Assigned: @PeteSwauger

  • Update snapshots
    Status: Completed
    Assigned: @PeteSwauger

  • Integration tests
    Status: Completed
    Assigned: @PeteSwauger

  • Code Review
    Status: Not Started
    Assigned: @ChrisBoehmCA

  • UX Review
    Status: In Progress
    Review: @jelaplan

Copied from original issue: gizafoundation/brightside#227

include npm audit with build

From @tucker01 on September 13, 2018 16:9

After we resolve imperative audit issues, we should probably add audit to the build.

Copied from original issue: gizafoundation/brightside#242

ZosFiles DSOrg options should not have VSAM-only allowed values

From @zFernand0 on June 29, 2018 13:55

Even though the dsorg options is not exposed in any other places than VSAM-related commands, we should not limit it to VSAM-only values since we can conflict with other options when creating NON-VSAM data-sets.


Location of the problem:
brightside/packages/zosfiles/src/cli/create/vsam/vsam.definition.ts

Lines 43 to 46

vsamDsOrg.allowableValues = {
values: ZosFilesConstants.VSAM_DSORG_CHOICES,
caseSensitive: false
};

Values in question:
brightside/packages/zosfiles/src/api/constants/ZosFiles.constants.ts

Lines 92 to 96
/**
* The set of dataset organization choices for VSAM files
* @type {[string]}
*/
VSAM_DSORG_CHOICES: ["INDEXED", "IXD", "LINEAR", "LIN", "NONINDEXED", "NIXD", "NUMBERED", "NUMD", "ZFS"],


Ways we could have conflicts with the DSOrg option:

  • DSNTYPE=(LIBRARY,2),DSORG=PO-E
  • DSNTYPE=HFS,DSORG=HFS

Copied from original issue: gizafoundation/brightside#141

Plugin Warning & Errors After Zowe Update

From @dkelosky on September 26, 2018 15:53

If I upgrade brightside via npm install -g @brightside/core/@latest, I get:

Since you re-installed brightside, we are re-validating any plugins.

Validation results for plugin '@brightside/db2':
___ Error: Configuration file does not exist: 'C:\Users\UID\.brightside\plug
ins\installed\node_modules\@brightside\db2\package.json'
No commands from this plugin will be available for future commands.


Validation results for plugin '@brightside/filemasterplus':
___ Warning: Your @brightside dependencies must be contained within a 'peerDepen
dencies' property. That property does not exist in the file 'C:\Users\UID\.b
rightside\plugins\installed\node_modules\@brightside\filemasterplus\package.json
'.


Validation results for plugin '@brightside/endevor':
___ Warning: Your @brightside dependencies must be contained within a 'peerDepen
dencies' property. That property does not exist in the file 'C:\Users\UID\.b
rightside\plugins\installed\node_modules\@brightside\endevor\package.json'.
___ Warning: The plugin's configuration does not contain an 'imperative.pluginHe
althCheck' property.


Validation results for plugin '@brightside/files-util':
___ Error: The path to the plugin does not exist: C:\Users\UID\.brightside\p
lugins\installed\node_modules\@brightside\files-util
No commands from this plugin will be available for future commands.

What should be my course of action to resolve these? Is there a way to report what the user should do for each of these errors?

Copied from original issue: gizafoundation/brightside#265

Core Command Name Consistency - Provisioning

From @dkelosky on August 29, 2018 15:18

bright provisioning should be bright zos-provisioning to be consistent with other "core" groups in brightside (prefixed with zos-).

We should maintain backward compatibility for anything using the current command names and adhere to UX standards of having at most 1 alias.

Copied from original issue: gizafoundation/brightside#208

Uss Files Upload Command Logs fake response

From @AHumanFromCA on September 28, 2018 18:36

While making a fix for #241 (files upload ftds throws unexpected error), I noticed that the uss files upload command logs a hardcoded response object and not the one actually returned from the API.

const response = await Upload.fileToUSSFile(session, commandParameters.arguments.inputfile,
commandParameters.arguments.USSFileName, commandParameters.arguments.binary);
const formatMessage = TextUtils.prettyJson({
success: true,
from: commandParameters.arguments.inputfile,
to: commandParameters.arguments.USSFileName
});
commandParameters.response.console.log(formatMessage);
return response;

As you can see in the above code, success is always true regardless of what the API call says. This can lead the user into a false sense of security. Furthermore, the API method Upload.fileToUSSFile will format the object that is needed so why was this even hard coded in the first place?

Copied from original issue: gizafoundation/brightside#268

ZosFiles should allow additional values for the DSnType option

From @zFernand0 on June 29, 2018 13:59

Even though z/OS MF prevents us from configuring data sets with different "data-set types" (dsntype), we should allow for more values other than LIBRARY

brightside/packages/zosfiles/src/api/methods/create/Create.ts

case "dsntype":
// Key to create a PDSE. Only valid value is LIBRARY (as far as I know)
switch (tempOptions.dsntype.toUpperCase()) {
case "LIBRARY":
break;
default:
throw new ImperativeError({msg: ZosFilesMessages.invalidDsntypeOption.message + tempOptions.dsntype});
}

Copied from original issue: gizafoundation/brightside#142

Untested and undocumented function: Upload.FileToUSSFile

From @AHumanFromCA on September 28, 2018 18:40

The following function is undocumented and not tested by unit tests.

public static async fileToUSSFile(session: AbstractSession,
inputFile: string,
ussname: string,
binary: boolean = false): Promise<IZosFilesResponse> {
ImperativeExpect.toNotBeNullOrUndefined(inputFile, ZosFilesMessages.missingInputFile.message);
ImperativeExpect.toNotBeNullOrUndefined(ussname, ZosFilesMessages.missingUSSFileName.message);
ImperativeExpect.toNotBeEqual(ussname, "", ZosFilesMessages.missingUSSFileName.message);
const promise = new Promise((resolve, reject) => {
fs.lstat(inputFile, (err, stats) => {
if (err == null && stats.isFile()) {
resolve(true);
} else if (err == null) {
reject(
new ImperativeError({
msg: ZosFilesMessages.missingInputFile.message
})
);
} else {
reject(
new ImperativeError({
msg : ZosFilesMessages.nodeJsFsError.message,
additionalDetails: err.toString(),
causeErrors : err
})
);
}
});
});
await promise;
let payload;
let result: IUploadResult;
try {
// read payload from file
payload = fs.readFileSync(inputFile);
await this.bufferToUSSFile(session, ussname, payload, binary);
result = {
success: true,
from : inputFile,
to : ussname
};
} catch (err) {
return {
success : false,
commandResponse: err,
apiResponse : {
success: false,
from : inputFile,
to : ussname,
error : err
}
};
}
return {
success : true,
commandResponse: ZosFilesMessages.ussFileUploadedSuccessfully.message,
apiResponse : result
};
}

Copied from original issue: gizafoundation/brightside#269

Imperative: Construct option to profile mapping util

Canonical
As Nick, I want to be able to automatically extract and map configuration values persisted in profile properties to command line options not specified by the user, so that I can expose all required options on a command and allow users to choose whether they want to persist their default/preferred values in a profile OR override/specify them on each command.

As Nick, I do not want profiles to be required in the CLI I am developing so that I can make use of existing configuration stores.

Description
The util will accept the command definition options, the loaded profile, and the options map (built by yargs) and for any option that is not specified by the user it will attempt to extract the value from the profile by matching the profile property to the option name. This service is a stepping stone to enable the full "order of option precedence" feature.

Acceptance Criteria
Enable CLI builders to allow any arbitrary CLI option to be specified on the command line OR in a profile if that option exists in said profile
A callable service to map options to profile values

8 point story

See issue zowe/imperative#34

  • Create utility to take an option or profile key and return camel case and dash version
    Status: @AHumanFromCA
    Assigned: None
  • Create utility to take an option name and create the ENV var style
    Status: Not Started
    Assigned: None
  • Update command processor to perform "search order" for arguments - just create a stub for ENV var (for now)
    Status: Not Started
    Assigned: @tucker01 and @ChrisBoehmCA
  • (Optional) Fill in stub for ENV var
    Status: Not Started
    Assigned: None
  • Write integration test - update/add an imperative test CLI to have a command with an option profile
    Status: In Progress
    Assigned: @ChrisBoehmCA
  • Document in Imperative Wiki
    Status: Not Started
    Assigned: None
  • Manually validate that existing plugins & CLIs don't break
    Status: Not Started
    Assigned: None
  • Check existing performance test and process ticks for variance - we'll get "serious" about performance testing in another task/issue
    Status: Not Started
    Assigned: None

Console logging during tests

From @tucker01 on September 17, 2018 15:11

We should remove all logging to stdout during jest test execution (interferes with jest console messages).

Copied from original issue: gizafoundation/brightside#247

Allow persistent setting for --max-concurrent-requests

From @ChrisBoehmCA on October 1, 2018 14:21

The --max-concurrent-requests option on download all members introduced in (Add --max-concurrent-requests option to download all-members command) could have a persistent way to store the setting such as a profile field, especially because a similar option may be introduced on other commands. Or when (Imperative: Allow CLIs to be developed with profiles and command option precedence) is implemented, the user could set an environmental variable to control this setting

Copied from original issue: gizafoundation/brightside#273

Allow CLI Use without creating profiles

Personas:
Michelle
Ravi
Use Case:
Michelle is provided a profile by a brightside admin. She uses brightside with this profile, but realizes that she needs to override some settings in the profile. She overrides the setting by setting an option on the particular command she uses. In time, she realizes that she always performs this over-ride but does not want to change the profile as it is standard and decides to set a local environment variable for it which takes precedence over the profile setting. She likes that she can still override the environment variable using the command option, as it allows her flexibility.

Research Acceptance Criteria:
What is the proper hierarchy?
How do implement this hierarchy?

Acceptance Criteria:
Implement input from environment variables
Implement order of precedence with Brightside honoring the values

Parent of zowe/imperative#34
Parent of #18
child of https://rally1.rallydev.com/#/72170833372/detail/portfolioitem/feature/215011220420

Hidden Alias Support

From @MikeBauerCA on September 4, 2018 14:43

This feature will introduce imperative infrastructure enhancement to support defining an alias with a "hidden" attribute. Aliases with the hidden attribute could be used to invoke commands but would not appear in help menus.

Use Case:
To adhere to UX standards of having at most 1 alias for a command group
To change command names while supporting old commands in a seamless way.

Acceptance Criteria:
imperative users can define group aliases which do not appear in help menu but function as a valid command when invoked.

Parent of Core Command Name Consistency - Provisioning
Parent of Enhance infrastructure to allow for hidden aliases

Copied from original issue: gizafoundation/brightside#216

Enhance infrastructure to allow for hidden aliases

From @MikeBauerCA on September 4, 2018 16:8

Introduce imperative infrastructure enhancement to support defining an alias with a "hidden" attribute. Aliases with the hidden attribute could be used to invoke commands but would not appear in help menus.

Use Case:
To adhere to UX standards of having at most 1 alias for a command group
To change command names while supporting old commands in a seamless way.

Acceptance Criteria:
Imperative users can define group aliases which do not appear in help menu but function as a valid command when invoked.

depends on issue 38 in AML (link)

Copied from original issue: gizafoundation/brightside#226

tso issue command fails with cryptic error

From @tucker01 on September 18, 2018 13:3

If an invalid value is specified on your tso profile (for example columns: 9999) the start address space command returns an error from zosmf:

Command Error:
TSO address space failed to start.
Error Details:
IZUG1115E: The request could not be completed. The common event adapter (CEA) component returned reason code 0x1013, reason "For more information, look up the reason code in the table of CEA reason codes included in IBM z/OS Management Facility Configuration Guide ." , and diagnostic codes 0x20, 0x0, 0x0, 0x0.

However, tso issue cmd returns a cryptic error:

Command Error:
Expect Error: [object Object]No servlet key was supplied.

We should surface the same details (assuming its the same error) if possible.

Copied from original issue: gizafoundation/brightside#249

support response formatter on "files invoke as" command

From @tucker01 on September 13, 2018 15:9

Can we support the response formatter options (--rft, --rff, etc.) on the invoke AMS command?

$ bright files invoke as "SET MAXCC=0"
rc:          0
output:
  - SET MAXCC=0
  -
  - IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0
JSONversion: 1

It would be good to be able to filter just the output.

Copied from original issue: gizafoundation/brightside#240

cleanup test properties

From @tucker01 on September 11, 2018 13:50

The default_properties.yaml file used in system tests contains outdated/unused properties. It should be cleaned up to avoid confusing for contributors.

Copied from original issue: gizafoundation/brightside#234

Download API JSDoc

From @dkelosky on July 13, 2018 19:31

Download.dataset returns a IZosmfFilesResponse object which references "commands". At the API usage, is commandResponse actually the data set content?
image

Copied from original issue: gizafoundation/brightside#153

Replace Keytar - Store creds in plain text

Replace keytar by storing credentials in plain text with the other profile information. Ensure python/C++ are no longer required prerequisites to use Zowe CLI. Update documentation.
8 Story Points

  • Design Session (Add additional tasks after)
    Status: Complete
    Assigned: @AHumanFromCA
  • Run final design by stakeholders
    Status: Open
    Assigned:
  • Moving keytar to devDependency
    Status: Complete
    Assigned: @tucker01
  • Document how to use plaintext and the default to cli implementers
    Status: Open
    Assigned:
  • Use the Managed by instead of securely_stored specified in zowe/imperative#28
    Status: Complete
    Assigned: @lyzla01
  • Default to plain text if credential manager is null and Keytar is not "present"
    Status: Complete
    Assigned: @tucker01
  • Profiles no longer readable by everyone
    Status: Discontinued
    Assigned:
  • Create integration test scenarios for imperative
    Status: In-Progress
    Assigned: @tucker01, @lyzla01
  • Create integration tests for imperative
    Status: In-Progress
    Assigned: @tucker01, @lyzla01
  • Test changes in a sample CLI
    Status: Complete
    Assigned: @ChrisBoehmCA
  • Create sample keytar plugin
    Status: In Progress
    Assigned: @ChrisBoehmCA
  • Remove prereqs from CA Brightside CE and Zowe CLI doc
    Status: Complete
    Assigned: @BrandonJenkins14
  • Adding text to imperative wiki? (on hold)
    Status: Open
    Assigned:
  • General doc review of all content
    Status: Open
    Assigned:
    Parent of zowe/imperative#28

Support Zowe CLI - 18PI4

From @JTonda on August 27, 2018 17:37

Personas:
All CA Brightside users

Acceptance Criteria:
Provide answers and fixes to Brightside users (slack & reddit)
Reserve 10% Darkside capacity for Support
Reserve 5% T&C Brightside capacity for Support

Parent of Login Proc of TSO profile not honored in tso start commands

Copied from original issue: gizafoundation/brightside#197

child of https://rally1.rallydev.com/#/106710376756d/detail/portfolioitem/feature/242525152420
Parent of #86
Parent of zowe/imperative#91
Parent of #101
Parent of #90
Parent of zowe/imperative#96
Parent of zowe/imperative#95
Parent of zowe/imperative#97
Parent of #85
Parent of zowe/imperative#64
Parent of #75

Update zowe-cli to take advantage of option "search order" precedence feature in Imperative

Tasks

  • Design Add option definitions for all zosmf connection options to all z/osmf related commands
    Status: Completed
    Assigned @tucker01 @ChrisBoehmCA
  • Update unit tests
    Status: Completed
    Assigned @tucker01
  • Update system tests (console, jobs, provisioning, tso)
    Status: Completed
    Assigned @tucker01
  • Update system tests (files)
    Status: Completed
    Assigned @PeteSwauger
  • Update system tests (zosmf)
    Status: Completed
    Assigned @gejohnston
  • Update environment variable doc in zowe-cli doc
    Status: In Progress
    Assigned: @BrandonJenkins14

Updated Issue Text

Canonical

As a Michelle/Ravi, I would like to be able provide all required options arguments on zowe-cli commands (i.e. I do not want to create and maintain zowe-cli profiles), so that I can use my own configuration store (e.g. Jenkins secure ENV vars).

Description

Zowe-cli currently requires certain command option values to be placed in a profile. We'd like to eliminate this requirement to facilitate the use of zowe-cli in CI/CD environments where configuration is already available (usually via ENV vars).

zowe/imperative#34 contains the changes to imperative that will make this effort possible.

In summary, option values will be found (in the order listed):

  1. On the CLI ("--") option
  2. From ENV vars
  3. In the profile loaded
  4. Default for the option

We will update zowe-cli with the following changes:

  1. Make profiles optional on all commands
  2. Expose all options required on the command definition (i.e. the profile options)
  3. Update handlers to create sessions from arguments - which will have the profile option values already populated by the imperative changes

After these changes are complete, you will be able to issue commands in the following forms (and any mixture of the following - i.e. some options in profile, some on CLI, some on ENV, etc.):

Using profiles:

zowe tso issue cmd "TSS LIST(USERID)"

Using ENV vars - No Profile Required:

ZOWE_OPT_HOST=hostname ZOWE_OPT_PASS=password ZOWE_OPT_REJECT_UNAUTHORIZED=false ZOWE_OPT_ACCOUNT=IZUACCT ZOWE_OPT_USER=userid zowe tso issue cmd "TS
S LIST(USERID)"

Using CLI Options - No Profile Required:

zowe tso issue cmd "TSS LIST(USERID)" --account IZUACCT --host hostname --user userid --pass password --ru=false

13 point story

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.