Table of Contents

Latest Announcements General Information Coming changes to the functionality Changes to the Conformance Criteria Office Hours Frequently Asked Questions Frequently Asked Questions - CLI Frequently Asked Questions - API Mediation Layer Download Availability

Latest Announcements

Starting from 12/08, the Zowe Onboarding Squad will hold the Office Hours to discuss the details about the upcoming V2 release. More information can be found in the Office Hour section.

The V2 documentation site is available at V2 Docs Site Preview

General Information

If you want to learn more about what you can expect compatibility wise, the statement is here

Coming changes to the functionality

Zowe API Mediation Layer
Breaking changes
  • Removed the support for the old path pattern (#1770)
  • Removed the support for different authentication schemas for different instances of service (#1051)
Important updates
  • Moved to the Material UI from Mineral UI (#1169)
  • New change password as a part of the API Catalog (#1531)
Zowe CLI

Breaking changes for Zowe CLI end users

  • zowe config no longer manages app settings (Imperative & CLI)
  • fail-on-error default changed to true for zowe plugins validate (Imperative & CLI)
  • Default Imperative and CLI log level changed from DEBUG to WARN (Imperative & CLI), which potentially changes troubleshooting steps for providing information to support.

Breaking changes that could prevent a V1 plug-in (or SDK) from working in V2

  • CLI package should be removed as a plug-in peer dep (Imperative)
  • AbstractRestClient.mDecode defaults to true so any plugin with custom RestClient implementation that adds gzip decompression may break
  • The return value for PluginManagementFacility.requirePluginModuleCallback changed. 
    Context:
    Application (and Plugin) developers requiring a module from a plug-in’s relative path using the requirePluginModuleCallback function no longer need to provide the plug-in name in a separate variable this.pluginNmForUseInCallback = pluginName
    before binding the class this.requirePluginModuleCallback.bind(this).
    Instead they can call this.requirePluginModuleCallback(pluginName).

    Common usage: ConfigurationLoader.load

    Before:
    this.pluginNmForUseInCallback = pluginName
    ConfigurationLoader.load(null,pkgJsonData,this.requirePluginModuleCallback.bind(this))

    After:
    pluginConfig = ConfigurationLoader.load(null,pkgJsonData,this.requirePluginModuleCallback(pluginName))

The following changes were marked for deprecation in the zowe-v1-lts release. These changes are also less likely to impact plug-ins.

  • AbstractRestClient.performRest → AbstractRestClient.request 
  • AbstractSession.HTTP_PROTOCOL → SessConstants.HTTP_Protocol 
  • AbstractSession.HTTPS_PROTOCOL → SessConstants.HTTPS_Protocol 
  • AbstractSession.TYPE_NONE → SessConstants.AUTH_TYPE_NONE 
  • AbstractSession.TYPE_BASIC → SessConstants.AUTH_TYPE_BASIC 
  • AbstractSession.TYPE_BEARER → SessConstants.AUTH_TYPE_BEARER
  • AbstractSession.TYPE_TOKEN → SessConstants.AUTH_TYPE_TOKEN 
  • ICliLoadProfile.ICliILoadProfile → ICliLoadProfile.ICliLoadProfile 
  • IImperativeErrorParms.suppressReport → removed 
  • IImperativeConfig.pluginBaseCliVersion → removed 
  • CliUtils.promptForInput → CliUtils.readPrompt 
  • CliUtils.promptWithTimeout → CliUtils.readPrompt 
  • (zosmf) IZosfmMessages → IZosmfMessages  
  • (workflows) listWorkflows → getWorkflows 
  • (workflows) getResourcesQuery → getResourceQuery 
  • (workflows) archiveWorfklowByKey → archiveWorkflowByKey 
  • (uss) createBasicSshSession → createSshSessCfgFromArgs 
  • (uss) createBasicSshSessionFromArguments → createSshSessCfgFromArgs 
  • (zosmf) createBasicZosmfSession → createSessCfgFromArgs 
  • (zosmf) createBasicZosmfSessionFromArguments → createSessCfgFromArgs 
  • (files) bufferToUSSFile → bufferToUssFile 
  • (files) streamToUSSFile → streamToUssFile
  • (files) fileToUSSFile → fileToUssFile 

Breaking changes for Zowe CLI & Imperative plug-in developers (V2-V2 - these changes only impacted early adopters of @next as these are breaking changes made during the technical preview validation phase - thanks to the community for their feedback)

  • tokenType and tokenValue were combined into authToken and we later reverted this change (Imperative & CLI) 
  • Options in zowe config group renamed: --user → --user-config and --global → --global-config
  • Zowe.schema.json format changed a few times (version 2, version 3): ConfigSchemas.loadProfileSchemas → ConfigSchemas.loadSchema

    Config.set no longer coerces string values to other types unless parseString = true (potential SDK impact - not CLI Plug-in impact)

Zowe Explorer
Systems
  • CI/CD
    • Define new FMID AZWE002 for Zowe v2
    • Start building 'v2' Zowe
    • Zowe v2: Review usage of z/OS system resources
  • Install and Packaging
    • New Feature: Introduced a new server command “zwe” to balance between simplification and flexibility on installation and configuration.
      • Almost all Zowe utility scripts in v1 are consolidated into new “zwe” server command. This new command defines consistent help messages, logging options, and so on.
        • You can type `zwe -h` to get help messages anytime you feel lost.
        • Consistent `-log-dir|-l` to allow you to write logs to the target directory.
      • Provides shell function library to help extensions to achieve common tasks. For example, execute TSO command, operator command, submit job and check job completion, and so on.
        • Keep away from commands/functions marked as experimental and internal.
      • Installation / Configuration changes
        • During installation, no new runtime directory will be created.
        • A zowe.yaml file can be used to centralize all configuration options. This configuration is compatible with all Zowe use cases (including high availability and containerization).
        • For almost all Zowe configuration steps, an automation option “zwe init” command is provided.
        • You can still choose to run all steps one by one.
        • The `--security-dry-run` mode allows you to generate security commands and pass along to your system admin.
        • You can run all steps from USS now.
    • New Feature: A Zowe component or extension can use manifest.yaml to define how it interacts with Zowe and other components.
      • The component or extension must define a manifest.yaml or manifest.json file to describe itself.
      • The manifest allows you to define:
        • how to register on Zowe APIML Discovery
        • how to register under Zowe Desktop
        • whether it’s Java extension library for APIML, and so on
      • Components can define their own `configs` in manifest.yaml which shows the user how to customize this component and provides default value if they are not defined.
        • This option is compatible with Zowe running in high availability mode.
    • New Feature: Introduced new data sets to better organize the contents.
      • Added `SZWEEXEC` to contain few utility tools.
      • You can customize your own PARMLIB, APF Authorized LOADLIB and APF-authorized ZIS plug-ins library.
      • `CUST.JCLIB` is a data set where Zowe will store temporary JCLs.
    • Breaking changes
      • You must pass `-ppx` when you unpax the Zowe convenience build to preserve extended file attributes.
      • All utility scripts, like `zowe-install.sh`, `zowe-install-xmem.sh`, `zowe-install-proc.sh`, `validate-directory-is-accessible.sh`, and so on, are removed and migrated to the new `zwe` server command format.
      • If you rely on some of the scripts, please find the alternative new “zwe” command or shell library functions.
      • `ZWESVSTC` is removed and `ZWESLSTC` will replace it to start Zowe.
      • Must use the `P` command to terminate Zowe instead of using the `C` cancel command.
      • `instance.env` is deprecated and replaced by `zowe.yml`.
      • Zowe now allows fine-grained customization of log, workspace, and configuration directories. By default, these directories remain grouped under an `instance` directory (same as Zowe v1).
      • Environment variables are reorganized to better describe itself. All zowe.yaml configuration entries will be automatically converted to environment variables for easy consumption.
      • Check with the community what the new alternative variable names are.
      • During Zowe configuration, redundant `ip` fields will be removed or consolidated in favor of `hostname` or `domains`.
      • Component or extension manifest is mandatory. End user must use the `zwe components install` command to install the extension.
Application Framework
New features

Summary: Major install & configuration simplication due to various improvements. Reduced overhead and increased performance due to reduction in server count, optimised networking, and 64 bit ZSS

  • Consolidation of Web Explorer Servers: Explorer USS, MVS, and JES no longer have node servers (3 less servers), due to utilizing app-server for hosting.Consolidation of web explorer servers
  • Jobs & Datasets APIs now disabled by default (2 less servers), and Explorers do not rely on them
  • Replace referrer security check with 'samesite' cookie option: No longer need to specify external hostname to pass security check
  • Remove "loopback routing" in app-server: Resolves bugs around use of a loopback IP when running app-server
  • Can specify advanced app-server & zss config in zowe.yaml: Simplify/Unify app framework configuration by using 1 config file rather than 2 (instance.env, server.json)
  • Contiguous default ports: App framework ports (formerly 85xx) now follow APIML ports (75xx)
  • App-server bind to IP_ADDRESS by default: Instead of '0.0.0.0', app-server now uses same IP as rest of Zowe servers
  • Consistent environment variable names: Standardize environment variable names around ZWED_, and ZWES_ prefixes for consistency. Aliases to previous names
  • Informative desktop login messages: Desktop login failures now print useful troubleshooting details about server communication issues
  • ZSS 64 bit: ZSS 64 bit version now exists alongside prior 31-bit version. Better performance and higher memory limit. Now utilizes 64-bit cross-memory to ZIS
  • New desktop library versions: Angular 6->12, Corejs 2->3, Typescript 2->4
Breaking changes

Some configuration, such as port and IP values, are different by default but can be reconfigured to old values. But, some app framework extensions may not work in v2 without enhancements.

  • Consolidation of Web Explorer Servers: Bookmarks to USS, MVS, JES explorers will be broken, due to URL change
  • "loopback routing" disabled: Loopback routing alternative may not be 100% compatible, can be disabled via config parameter node.internalRouting=false
  • Server.json removed: The now-mandatory zowe.yaml can contain the same content as server.json, within the objects components.app-server and components.zss
  • Scripts that wrote to server.json will be broken, adapt them to write to zowe.yaml instead
  • Incompatible desktop library version upgrades: Angular 12, corejs, and typescript were updated in the Desktop, and non-iframe plugins that depend on them may break
  • ZSS cookie name change: ZSS cookie name now includes a suffix of either port name or HA/FT ID to distinguish between unrelated ZSS servers
  • Internationalization, using Angular, has changed from 6 (TranslationService etc.) to 12 (L10TranslationService etc.). For help in updating your Desktop apps to match new internationalization usage, please reference: Sample Angular App example

Changes to the Conformance Criteria (For Extenders)

All the changes are available here: Box Excel Sheet

Zowe API Mediation Layer
The API Mediation Layer related conformance Criteria are on: Box Excel Sheet on the tab V2 ZOWE API-ML Conform (xx)
Zowe CLI
The CLI related conformance Criteria are on: Box Excel Sheet on the tab V2 Zowe CLI Conformance (29)
Zowe Explorer
The Explorer related conformance Criteria are on: Box Excel Sheet on the tab V2 ZOWE Explorer Conform (16)
Systems
The packaging related conformance Criteria that are newly added to V2 are on: Box Excel Sheet on the tab V2 ZOWE Packaging Conformance
Zowe Application Framework
The Application Framework related conformance Criteria are on: Box Excel Sheet on the tab V2 ZOWE AppFramwk Conform (xx)

Office Hours

Check out the OMP Calendar for specific time of the V2 office hours.

Date Topic Link to the meeting Link to the recording Links to the materials
12/08/2021 12PM - 1PM ET Kickoff https://zoom.us/j/94312528890 Zoom recording Presentation
01/05/2022 12PM - 1PM ET CLI https://zoom.us/j/94312528890 Zoom recording Presentation
01/12/2022 12PM - 1PM ET API Mediation Layer https://zoom.us/j/94312528890 Zoom recording Presentation
01/19/2022 12PM - 1PM ET Explorers https://zoom.us/j/94312528890
01/26/2022 12PM - 1PM ET Web UI (Zowe Application Framework) https://zoom.us/j/94312528890
02/02/2022 12PM - 1PM ET Systems / Install https://zoom.us/j/94312528890
02/09/2022 12PM - 1PM ET *Optional:* General Information https://zoom.us/j/94312528890
02/16/2022 12PM - 1PM ET *Optional:* General Information https://zoom.us/j/94312528890
02/23/2022 12PM - 1PM ET General Wrap-up https://zoom.us/j/94312528890

Frequently Asked Questions

   The official date is TBD, the target is Feb 28, 2022; look for the official announcement at Zowe.org landing page announcement banner.

   The Zowe Squads have prepared XLS spreadsheets with conformance criteria for all Zowe extensions including: CLI, APIs, App Framework, and Explorerfor VS Code. The spreadsheets clearly show the prior / V1 criteria alongside the new / V2 criteria. Please be aware, there are additions, deletions, and CHANGES to the criteria. In some cases the change is simply that a BEST PRACTICE has been deemed REQUIRED. Use the light-GREEN highlights to easily identify the changes. See the Changes to the Conformance Criteria section at Zowe.org/vNext.

   NO. We recommend testing all V1 conformant extensions. See the Coming changes (For Users) section at Zowe.org/vNext.

   See the recommendations in the Coming changes section at Zowe.org/vNext.

   Obtain the pre-GA Zowe V2 release; for details see the pre-GA Download Availability section at Zowe.org/vNext.

   YES, we expect the Zowe V2 Conformance program to be available in early Feb 2022. We will announce when extenders can pre-apply in the LATEST ANNOUNCEMENTS section at Zowe.org/vNext.

All Zowe V1 conformance badges will remain at the Open Mainframe Project Interactive Landscape; we recommend documenting a Zowe compatibility matrix to ensure clients are aware of any/all compatibility issues between your V1 conformant apps and Zowe V2.

Yes, We will announce when extenders can pre-apply in the LATEST ANNOUNCEMENTS section at Zowe.org/vNext.

   Anytime. Zowe is an open source project managed by a transparent, open source community.

   The V1 LTS Maintenance timeline runs through July 2024. See RELEASE TIMELINE at Zowe.org/download.

   You have several options:

  1. Notify your customer base and advise them to remain on Zowe V1 LTS until you are able to make the necessary modifications to satisfy all of the new requirements (Note: extenders can choose NOT to be “day-1” V2 conformant )
  2. Notify your customer base of V2 compatibility concerns (or lack thereof) and advise accordingly (e.g. extension operates but will not leverage V2 features etc.)
  3. Replace your extension with a V2 conformant extension and indicate it as such

   You have several options:

  1. Attend one (or more) of the (7) bi-weekly Zowe V2 OFFICE HOURS meetings offered on Wednesdays at 12pm ET. Kickoff is scheduled for 12/8. Following (6) meetings are scheduled for: 1/05, 1/12, 1/19, 1/26, 2/2, 2/23 There are 2 more optional meetings plannes for 2/9, 2/16
  2. Interact with a Zowe Community Member via SLACK. Click on the COMMUNITY tab at Zowe.org, navigate to the SLACK box and click #zowe-onboarding
  3. Join a Zowe Squad call. Click on the COMMUNITY tab at zowe.org, navigate to the JOIN A SQUAD CALL section on this page. Click on one of the calendar entries for Zoom meeting links.

   Yes. Recordings can be provided on request. Click on the COMMUNITY tab at Zowe.org, navigate to the SLACK box and click #zowe-onboarding and request the recording.

   Yes, we plan to introduce a "zowe config convert-profiles" command, which will be available in the v2 release.

   This work is still in progress-we are working on a "zowe daemon enable" command to make the daemon installation process as seamless as possible. Daemon mode will be disabled by default, the command must be run to enable it.

   The recommended approach for editing the config file is to launch it in VS Code from Zowe Explorer and make modifications there. The designated user responsible for creating and maintaining the config (we recommend a team lead or Administrator) will be able to leverage the built-in “intellisense” when editing the file. Note: Team Config fundamentally changes the paradigm on profile creation & management. Prior to Team Config, all users were required to understand, create, test, trouble-shoot, and manage their own profiles. Team Config was designed to scale all of these tasks back, remove the burden from individual users and centralize it. Once the config is distributed most users should not need to make any significant edits.

   Join the discussion on this topic here: https://github.com/zowe/vscode-extension-for-zowe/discussions/1535

No, team config will be reloaded for every command

Team Config will likely support alternates defined in the settings json file, administrators will probably need to hand-edit the configuration file to set a new credential manager

A migration utility is available - it will translate profiles (1 for 1) to new  (team config) format AND (optionally) clean-up old profiles and old SCS entries.

Migration to the new profile format is NOT required immediately - the old profiles will work UNLESS a team config is created - that said, the old profiles will not be used if a new team config is available. Simply stated - if a team config is not located, CLI will fall back to using the prior profiles

Yes - CLI can read the old and the new format

Yes (recommend this is cleaned up)

CLI option name is "base-path", property name in config is "basePath"

Yes

The BCM prefix for V2 is required

Yes, this a requirement for V2 conformance, however Pass Tickets can be used and it is possible to leverage the basic authentication to properly participate. The configuration is here: https://docs.zowe.org/stable/extend/extend-apiml/api-mediation-passtickets/#api-services-that-support-passtickets The API ML will issue a passticket for the user when service is accessed as long as the user provides a valid JWT token. We recommend this route (minimally) to give the users a seamless signon experience.

Yes

It is part of your configuration yaml - it is a unique identifier for your service that helps to identify your service and uses the format: companyprefix.productname (Note: it is used for documentation only, has no impact on interacting with API-ML)

TBD

Cross-version compatibility may be possible but is not guarenteed; recommend upgrading both

Existing (V1) APIs will continue to work 

Download Availability

The Pre-GA V2 Zowe package is available only for CLI (Zowe v2 LTS Preview section on Download) and Explorers (Zowe Explorer section on Download) at the moment. The Server-side PAX availability will be announced here and on Slack.