Zowe v2 is NOW LIVE - please visit the [Download](https://www.zowe.org/download.html) page for the latest artifacts and documentation.
The V2 documentation site is available at [V2 Docs Site](https://docs.zowe.org/).
The V2 Conformance Criteria are available at [Conformance program page](https://www.openmainframeproject.org/all-projects/zowe/conformance)
If you want to learn more about what you can expect compatibility wise, the statement is [here](https://www.zowe.org/download.html#compatibility-extensions).
**Breaking changes**
- Removed the support for the old path pattern ([#1770](https://github.com/zowe/api-layer/issues/1770)). This includes the changes to the endpoints used in ZAAS client. If your application uses ZAAS client please verify whether the configuration properties use the new path pattern (/gateway/api/v1 instead of /api/v1/gateway)
- Removed the support for different authentication schemas for different instances of service ([#1051](https://github.com/zowe/api-layer/issues/1051))
**Important updates**
- Moved to the Material UI from Mineral UI ([#1169](https://github.com/zowe/api-layer/issues/1169))
- New change password as a part of the API Catalog ([#1531](https://github.com/zowe/api-layer/issues/1531))
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)
- Changes to settings keys - automated migration of settings when user opens Zowe Explorer v2: (includes documentation) ([#PR 1450](https://github.com/zowe/vscode-extension-for-zowe/pull/1450))
- [Using Global Profile Configuration](https://github.com/zowe/vscode-extension-for-zowe/blob/next/docs/Early%20Access%20-%20Using%20Global%20Profile%20Configuration.md)
- [Changes Affecting Extenders](https://github.com/zowe/vscode-extension-for-zowe/blob/next/docs/Early%20Access%20-%20Changes%20Affecting%20Extenders.md)
- **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.
- **New Feature**: Use PARMLIB to configure Zowe.
- With traditional PARMLIB concatenation, system programmers can plan their Zowe rollout more like other z/OS products.
- Multiple YAML configurations will be concatenated and merged.
- JSON Schema is introduced to help on validating user customized configurations.
- We are also investigating full Non-USS ways to install/configure Zowe for SMPE users.
- **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.
**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](https://github.com/zowe/sample-angular-app/pull/69/files)
Changes to the Conformance Criteria (For Extenders)
The final version of V2 Conformance Criteria is published here. Each of the section links to th PDF for the specific criteria.
Zowe API Mediation Layer
The API Mediation Layer related conformance Criteria are [here](https://ibm.box.com/s/rdb7zfkcxzzbiro4idat9o7xd0qig3mt)
Zowe CLI
The CLI related conformance Criteria are [here](https://ibm.box.com/s/st4jkk6xmughrg8ngcefvgt7fczicrk7)
Zowe Explorer
The Explorer related conformance Criteria are [here](https://ibm.box.com/s/euros5vvutyvk6ixih7vixwhxvuuog4n)
Zowe Application Framework
The Application Framework related conformance Criteria are [here](https://ibm.box.com/s/1om2ruoi8g2c8cjsh976q9cpg2vfbgl3)
Office Hours
Check out the OMP Calendar for specific time of the V2 office hours.
The official date is TBD, the target is April 25, 2022; look for the official announcement at [Zowe.org](/) landing page announcement banner.
We are sorry for the delay and any inconvenience coming out of it.
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](#conformance-changes) section at [Zowe.org/vNext](/vNext).
NO. We recommend testing all V1 conformant extensions. See the [Coming changes (For Users)](#coming-changes) section at
[Zowe.org/vNext](/vNext).
See the recommendations in the [Coming changes](#coming-changes) section at [Zowe.org/vNext](/vNext).
Obtain the Zowe V2 LTS release
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](#latest-announcements) section at [Zowe.org/vNext](/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](#latest-announcements) section at
[Zowe.org/vNext](/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](download.html).
You have several options:
- 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 )
- 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.)
- Replace your extension with a V2 conformant extension and indicate it as
such
You have several options:
- 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
- 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
- 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](https://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](https://github.com/zowe/vscode-extension-for-zowe/discussions/1535)
Frequently Asked Questions - Extenders Focused
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](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)
Yes
Cross-version compatibility may be possible but is not guarenteed; recommend upgrading both
Existing (V1) APIs will continue to work
Yes
No. Zowe CLI offers more robust functionality for Team Configuration initialization specifically when configuring for MFA/token support, however it is NOT required. Zowe Explorer users interested in configuring for MFA/Tokens can manually update their Team Configuration
No. The Zowe Explorer download experience will not change.
No. Users must plan to convert to the Team Configuration (profiles) format.
The V1-style profiles will remain backward compatible for the duration of the Zowe V2 ACTIVE and MAINTENANCE time period (~4 years), however they will be identified as “deprecated” in Zowe V2 which means they will not be backwards compatible with Zowe V3 and beyond. The same is true for Zowe CLI profiles.
The presence of a Team Configuration renders all V1 profiles unusable. When you opt in to the V2 Team configuration, you cannot revert back.
Yes, as long as there is no team config file present.
Zowe Explorer users may not know. In the CLI, if a V2 profile is found, and a V1 profiles command is issued, an error similar to the following will be displayed:
-> zowe profiles list zosmf.
An error occurred trying to list profiles.
'Profile IO Error: A Zowe V1 profile operation was attempted with a Zowe V2 configuration in use.'
'Warning: The command 'profiles list' is deprecated.'
"Recommended replacement: The 'config list' command"
'If only V1 profiles exist, the command will work, but a deprecation warning will be displayed:'
-> zowe profiles list zosmf
sys1_zosmf
sys2_zosmf (default)
sys3_zosmf
"Warning: The command 'profiles list' is deprecated."
"Recommended replacement: The 'config list' command"
Yes, the CLI has a conversion utility. At the present time, Zowe Explorer users who wish to convert over and do not use Zowe CLI will need to create their profiles from scratch OR install Zowe CLI and use the Zowe CLI conversion utility.
Zowe Explorer is available for download at the VisualStudio Marketplace:
[https://marketplace.visualstudio.com/items?itemName=Zowe.vscode-extension-for-zowe](https://marketplace.visualstudio.com/items?itemName=Zowe.vscode-extension-for-zowe)
and the Open VSX Registry:
[https://open-vsx.org/extension/Zowe/vscode-extension-for-zowe](https://open-vsx.org/extension/Zowe/vscode-extension-for-zowe)
For Zowe CLI Extensions: the JSON schema file is automatically updated when a Zowe CLI plug-in is installed; more specifically the global schema is dynamically updated -- individual project schemas are not). For Zowe Explorer Extensions: we have plans to automatically insert configuration information into the schema, but at the current time this information will need to be manually added.
For Zowe CLI, the global schema is updated when the new plug-in is installed. New init commands will include the new plug-in profile(s) in the generated zowe.config.json. Project-level schema is not updated at plug-in install time. To update, run zowe config update-schemas. The plan for Zowe Explorer is similar but is still being discussed.
Yes.
Yes, specifying individual ports will continue to be supported
Yes, should be able to run via SHELL or via a batch job
Most-likely, yes (will need to be confirmed)
Yes
Zowe.yaml is a centralized file containing parameters utilized by the ZWE command - you determine where it resides. V2 no longer requires an instance directory.
There is LTS version available under Downloads section.
Zowe Slack Channel: openmainframeproject.slack.com #zowe-user OR Sean’s email address: sgrady@rocketsofware.com
NO, that is an error. We will correct this!
At present time, adding components/plug-ins to the manifest.yaml will require a restart of the [corresponding] Zowe server. We will plan to enhance Zowe to offer a more dynamic approach (i.e. automatically re-read the manifest.yaml for any server that can handle changes without requiring a restart).
Yes, they can be defined in zowe.yaml as `zowe.setup.security.stcs` which lets you set their names, e.g. `zowe.setup.security.stcs.zowe: ZWEMYSTC`.
Yes, all data set names used by Zowe are configurable in zowe.yaml so you can configure your multiple-run scenario with multiple zowe.yaml files where each has its own stc and data set names.
Allowing PARMLIB doesn't change the way how Zowe uses zowe.yaml behind the scene. It's more like a new user interface to configure Zowe. The content in PARMLIB will be concatenated, merged into a temporary zowe.yaml and fed to Zowe. That means it won't change the way how components / extensions read configurations. On the other side, since we may enhance the configuration interface like allowing PARMLIB, it's not recommended for a component installer to read or update zowe.yaml directly. Instead, a component installer should read `ZWE_` environment variables to understand configurations, and use relevant zwe commands or library functions to update. For example, `zwe components enable` can be used to enable your component, and it's compatible with both USS zowe.yaml or PARMLIB configuration.
We can review with IBM - that said, we also have plans to help prevent accidental “C”- cancel commands. Why did we do this? Zowe components need specific resource and recovery management handling - the “P” command sends the proper signal to Zowe to ensure all components are shut down appropriately. We'll investigate this more so many thanks for the feedback.
The LTS release is available now.
Use this SLACK CHANNEL for interacting with the team:
[#zowe-install-rework](https://openmainframeproject.slack.com/archives/CH9R3FD1V)
Use this GitHub repo for posting issues:
[https://github.com/zowe/zowe-install-packaging](https://github.com/zowe/zowe-install-packaging)
We recommend extensions create a dedicated package for Zowe v2 - this is the most straight-forward way to address all of the breaking changes. We recognize this presents the challenge of maintaining 2 sets of packages. If you prefer not to maintain 2 sets of packages, we believe it's possible to maintain one version of an extension which works for both Zowe v1 and v2. However, the lifecycle code will be complicated - comprehensive testing should be performed.
**PLEASE BE AWARE** The Zowe V2 app framework desktop upgraded from angular version 6 to angular version 12 for support & security - websites have a “1 version of a library” limitation. This means that *plugins dependent upon angular must be coded for either v6 or v12* [not both] thus **the single version approach is not applicable.**
If the lifecycle scripts are the main concern, the following steps outline requirements and our recommendations for the single version approach:
1. Package manifest.yaml is required. This is a hard requirement for Zowe v2. If you define lifecycle scripts with default names, for example, use bin/start.sh as `commands.start`, it should work for v1.
2. Revisit all environment variables used in the lifecycle scripts and apply fallback variables. For example, if you use $ROOT_DIR in Zowe v1, this should be changed to ${ZWE_zowe_runtimeDirectory:-${ROOT_DIR}} to make it compatible with both versions. Other variables like $EXPLORER_HOST should be changed to ${ZWE_haInstance_hostname:-${EXPLORER_HOST}} or ${ZWE_externalDomains_0:-${EXPLORER_HOST}} based on purpose.
3. A Zowe v2 recommendation is defining extension configurations in the manifest.yaml "configs" section and use ${ZWE_configs_*} variables to access them. This feature does not exist in Zowe v1. So if you use ${ZWE_configs_*} variables, it should fall back to the matching environment variable used in v1.
4. For installation, Zowe v2 recommends defining a "commands.install" lifecycle script to handle Extension installation. This lifecycle script will be executed by `zwe components install`. In v1, this also exists if the end-user uses zowe-install-components.sh utility to install an Extension. So if we consider one Extension package working for both Zowe v1 and v2, this install lifecycle script should also be compatible with both v1 and v2. Or consider instructing the user to not use zowe-install-components.sh with Zowe v1.
5. As discussed in slack, a new v2 variable ${ZWE_VERSION} may help you determine if the user is using Zowe v2 or v1. This variable does not exist in Zowe v1.
- By knowing the Zowe version, the lifecycle scripts can implement logic to source v1 or v2 dedicated scripts to avoid handling fallbacks in the same script. This could be a cleaner way to avoid complicated compatibility version checks, and it could be easier in the future should you decide to drop Zowe v1 support.
6. We are planning to release a comprehensive “migration guidance” section on docs.zowe.org to help Extenders facing these challenges. Your feedback on this section is greatly appreciated.
Frequently Asked Questions - Users Focused
The API-ML uses the first certificate found in the keyring if the details about the certificate aren't supplied
"Not really, if properly onboarded, they would be mentioned in the Swagger DOC but you’d have to first locate the appropriate tile (via the API catalog); There is a feature/request in the backlog that may satisfy this request - if you would like this prioritized please review and upvote this github issue: [https://github.com/zowe/api-layer/issues/647](https://github.com/zowe/api-layer/issues/647) and possibly [https://github.com/zowe/api-layer/issues/1129](https://github.com/zowe/api-layer/issues/1129)"
'There are several ways to confirm API-ML is ”up and running”:'
- Manually via the catalog, all services will show “green”
- And endpoint is available for API access that can be leveraged for automation use-cases
- 'There is a feature/request in the backlog for a WTO message - if you would like this prioritized please review and upvote this github issue: [https://github.com/zowe/api-layer/issues/1633](https://github.com/zowe/api-layer/issues/1633)'
The main use case we were unable to address due to technical limitations is the ability to detect an upcoming expiration and immediately offer a password change action, ahead of the actual expiration event. We have two other password change related enhancements as yet unplanned. Please review and upvote if you would like these prioritized: [https://github.com/zowe/api-layer/issues/2020](https://github.com/zowe/api-layer/issues/2020) and [https://github.com/zowe/api-layer/issues/2018](https://github.com/zowe/api-layer/issues/2018).
No. There is a feature/request in the backlog for such a capability - if you would like this prioritized please review and upvote this github issue: [https://github.com/zowe/api-layer/issues/647](https://github.com/zowe/api-layer/issues/647) and also consider this one: [https://github.com/zowe/api-layer/issues/2059](https://github.com/zowe/api-layer/issues/2059)
VS Code extensions and code pack solutions that rely on the Zowe Explorer (mainframe files and jobs) are interested in and have added capabilities that leverage Team Config. Recommend attending/reviewing the Zowe Explorer V2 office hours (scheduled for 4/20) for further details.
If USER & PASSWORD are already stored in profiles for authentication and the User tries to use a token for login, Zowe Explorer will issue a message indicating *“This profile does not support token authentication”*. In order to enable token authentication the SECURE array in the the configuration file (*either zowe.config.user.json* OR *zowe.config.json*) needs to be updated with tokenValue in place of USER & PASSWORD. Default authentication is USER & PASSWORD
No, there is no visual / decoration indicating authentication method. In general if USER & PASSWORD is configured, the User will be prompted for them.
The Zowe Explorer (for VS Code) Squad has added usability features throughout the Zowe V1 (continuous delivery) LTS release, including adding commands and functions to process multiple items, adding progress bars, and refresh capabilities. The comprehensive list of features can be viewed in the changelog at the VS Code Marketplace: [https://marketplace.visualstudio.com/items/Zowe.vscode-extension-for-zowe/changelog](https://marketplace.visualstudio.com/items/Zowe.vscode-extension-for-zowe/changelog) ; it is important to note that a new LTS release gives all squads the opportunity to introduce changes that may require an upgrade or result in a significant change in behavior - the Zowe community refers to these as “breaking changes”. In the case of Zowe V2 LTS, the significant change for Zowe Explorer is the introduction of and support for Team Profile Configurations & setting updates as well as.
Provided the User has not changed the auto update (extensions.autoUpdate) default setting in their Zowe Explorer USER SETTINGS to false, Zowe Explorer will automatically be updated to V2. If the auto update setting has been changed to “false”, the user can decide when to update Zowe Explorer - they do this manually by clicking the “UPDATE” button. (The UPDATE button will show once Zowe V2 LTS is available).
Ideally, for Team Configuration a designated Administrator who has access to the appropriate connection information and is familiar with configuring profiles - this will enable developers to get started with Zowe Explorer without having to learn about profiles and will ensure all developers are configured with their organizations required authentication policy.
