Blog ready for OMP/LF promotion.

BUPT Introduces Zowe Innovation Project.docx

Photo 3: Group photo after the mainframe tour in CSC (Dean Kuang, students & IBMers)

Photo 1: IBM Z expert is introducing IBM Z14 and Storage DS8000 to Dean Kuang & students

Several users and interested clients have been asking for a recorded demo to see the different Zowe components. Can we produce a new 5-7 min Zowe Overview demo that highlights the key capabilities and features of the Zowe components.

An example of an old recorded demo is below, but it needs to be shortened quite a bit.
Link to sample: https://ibm.box.com/s/b1ddp6ph7h0y6bznu7gdrs2wsqdg7gjj

Instructions for submitting this video to the OMP youtube channel is here: https://ibm.box.com/s/8l1im9dyfcf5muejrrrlb22g7ok27jhk

Create a consistent issue submission interface across all Zowe repositories. Some domain-specific information may be included in bug/feature request on a repository-by-repository basis, but the look-and-feel should be consistent.

Is your feature request related to a problem or limitation? Please describe.
There are a number of issues that have been identified with the current way that Zowe is packaged and installed for its z/OS components.

Describe the experience you'd like
We are documenting the install issues here"
https://github.com/zowe/zowe-install-packaging/wiki/Install-Experience

Our first deliverable is a playback deck and material and giving that to audience(s) to validate and refine

• Complete license/legal documents.
• Have license agreement and contract signed.

Change the download and install for Zowe by separating the zOS components and the Zowe CLI so that user can download the latter separately.

See E-mail Thread titled
Re: [zowe/zlc] Allow CLI as separate download (#54)

Plan a community meet up for Zowe development community to discuss and share 2019 goals and to engage the broader open source community.

Work with IBM Ecosystem team to update the hands-on web-UI totrial system with 1.0. Ensure URLs are updated and ZSS component.

Details to be filled out

Is your feature request related to a problem or limitation? Please describe.
A clear and concise description of what the problem or limitation is. Ex. I'm always frustrated when [...] happens, or I wish I was able to do [...] with Zowe.

Describe the experience you'd like
A clear and concise description of what you want to happen when you encounter the prior problem or limitation.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
Hi,

after recycle of ZOWE server USS explorer no longer works.
Whenever I try to open it it gives an error: Fetch children failed for
no matter which path I want to load.

All other functions work just fine, including Editor which is able to open USS files.

Logs
The only related message in log I was able to spot is:
2019-03-28 08:59:33.749 WARN 16778045 --- [0.0-7554-exec-2] o.s.web.servlet.PageNotFound : No mapping found for HTTP request with URI [/error] in DispatcherServlet with name 'dispatcherServlet'
2019-03-28 08:59:33.964 WARN 16778045 --- [0.0-7554-exec-6] o.s.web.servlet.PageNotFound : No mapping found for HTTP request with URI [/error] in DispatcherServlet with name 'dispatcherServlet'
2019-03-28 08:59:34.077 WARN 16778045 --- [0.0-7554-exec-7] o.s.web.servlet.PageNotFound : No mapping found for HTTP request with URI [/error] in DispatcherServlet with name 'dispatcherServlet'
2019-03-28 08:59:34.197 WARN 16778045 --- [0.0-7554-exec-5] o.s.web.servlet.PageNotFound : No mapping found for HTTP request with URI [/error] in DispatcherServlet with name 'dispatcherServlet'

Details
version 1.0.0 #26
RACF, zOS 2.3, JES3

Web Browser Details (if the bug relates to Zowe Desktop usage):
Linux, Chromium, Firefox

Several people are complaining about excessive ZOWESVR CPU and EXCP consumption, particularly on zD&T systems

Link to blog: https://medium.com/@dkelosky/how-to-automate-z-os-data-set-allocation-using-zowe-json-30e70fb960d8

Create a blog with screen shots that covers the story of getting Zowe 1.0.0 and installing all of the pieces.
The end user doc is good but misses screen shots and a narrative describing why certain steps are included so the idea behind a blog is to capture more of the flow and troubleshooting and experience

OMP would like to schedule a series of webinars/tech talks.
List of potential webinars: https://ibm.box.com/s/14yg3r5yfzaxul60uizt71u64i0xv1ni

Blog ready for OMP/LF promotion.

See attached.
Draft Article for DLUT Involvement in Zowe Ecosystem v1.0.docx

Hi,
I started the tutorial (https://developer.ibm.com/tutorials/zowe-step-by-step-tutorial/), but encountered some problems. (Working on Windows 7).

The biggest problem, preventing me to continue the tutorial, is when starting up the zLUX server:

[2019-03-05 11:31:26.801 _zsf.bootstrap WARNING] - Could not spawn {"path":"C:\Temp\Zowe\zlux\zlux-app-server\bin\zssServer.sh","once":true}: spawn UNKNOWN
[2019-03-05 11:31:26.802 _zsf.network INFO] - HTTP config valid, will listen on: 0.0.0.0
[2019-03-05 11:31:26.808 _zsf.network INFO] - HTTPS config valid, will listen on: 0.0.0.0
[2019-03-05 11:31:26.809 _zsf.bootstrap INFO] - Using Certificate: C:\Temp\Zowe\zlux\zlux-app-server\deploy\product\ZLUX\serverConfig\zlux.keystore.cer
[2019-03-05 11:31:32.236 _zsf.proxy WARNING] - Failed to reach the auth services host for address 192.86.32.67:8542
could not start the server: Communication with 192.86.32.67:8542 failed: Error: connect ECONNREFUSED 192.86.32.67:8542

Did the ZSS port number change? or is there another issue?

thanks for considering this problem
Gie

Shell Environment Details (if the bug relates to CLI):

• Technology: powershell and bash
• OS: Windows 7

Here is a blog for a "Hello World" project using Zowe CLI: https://medium.com/@dkelosky/zowe-and-hlasm-hello-world-build-deploy-695be1eb13dc

As interest in Zowe increases a recurring question that comes up is "Where can I host my new service?"

People are unclear on what the options are. Here is my view followed by a suggestion:

View
As Zowe is deployed, there are four primary areas for deploying services / applications.

1. Desktop - Node based runtime. Applications that ship with Zowe mostly run here.
2. Explorer / APIML - Tomcat Servlet based. I think API/ML as a component should remain standalone given its importance to overall functionality of Zowe. Explorer is also a set of services that are part of Zowe (as delivered).
3. ZSS (C based runtime for hosting services)
4. ZWESIS - Zowe System Services (authorized code)

We could open up the Zowe runtimes to host other applications / plugins but that does come at the expense of potential stability of Zowe proper if an application does not behave well. Not sure of the security implications.

I think the ideal option is for Zowe to provide a framework for hosting Java, C and Node runtimes as part of Zowe but in their own "containers" meaning their own runtime instances. This way exploiters could easily deploy their apps and not have to burden themselves with runtimes unless their requirements were unique. this implies:

1. Zowe plugins can start and stop runtimes (K8S would be awesome, but, its not ubiquitous)
2. Support for C, Node and Java would most likely model the existing infra.
3. Authorized services would likely need to be included in ZWESIS by adding DLLs. Lots of things to think about here since we're talking about authorized code. (Of course customers can already add authorized code to their environments so we're not breaking anything, although, we are at risk of poorly functioning components.).

Thoughts / other considerations?

We're using Explorer Server USS REST API to list the files under one USS folder, and want to show their file size and last modification date. Now we use the following API to get the files first.

https://zoslpar:port/api/v1/unixfiles?path=%2Fu%2Fsuser

which returns

{
  "type": "DIRECTORY",
  "owner": "USER",
  "group": "USER",
  "permissionsSymbolic": "drwxrwxrwx",
  "size": 8192,
  "lastModified": "2019-03-29T11:20:04",
  "children": [
    {
      "name": "newDirectory123",
      "type": "DIRECTORY",
      "link": "https://zoslpar:port/api/v1/unixfiles/u/user/directory1"
    },
    {
      "name": "zowe-1.0.1",
      "type": "DIRECTORY",
      "link": "https://zoslpar:port/api/v1/unixfiles/u/user/directory2"
    },
  ]
}

And then do multiple API calls with the link like https://zoslpar:port/api/v1/unixfiles/u/user/directory1to get the file size and last modification date of these files one by one.

It's not efficient. If there are 100 files under this folder, we have to do 100 + 1 API calls.

Can we have the file size and last modification date, or the other commonly used attributes be part of children as follows?

    {
      "name": "zowe-1.0.1",
      "type": "DIRECTORY",
      "size": 8192,
      "lastModified": "2019-03-27T15:22:24",
      "link": "https://zoslpar:port/api/v1/unixfiles/u/user/directory1"
    },

Thanks!

Approach Alex about writing a blog about how he used used Zowe to build his VIVA app.

Note from Daniel Jast (IBM): The official ZOWE documentation on Github I thought was pretty good, but personal documentation has always worked better for me. Helps you throw tips in there to avoid errors and problems later on. If I can help contribute I would be interested as well.

Link to personal doc to contribute to forum: https://ibm.box.com/s/dx96nw1st95qrh651d2obdbigtj41tfy

Update the Zowe community Readme.md to help tie different Repo's together.
Good examples include:
https://github.com/twbs/bootstrap
https://github.com/impress/impress.js

5 new repos were added to the CLI section on the Zowe.org contribute page:

https://github.com/zowe/zowe-cli https://github.com/zowe/zowe-cli-cics-plugin https://github.com/zowe/zowe-cli-db2-plugin https://github.com/zowe/zowe-cli-sample-plugin https://github.com/zowe/vscode-extension-for-zowe

Need to remove the text that is currently says "more repositories will be open sourced in November"

We have and will end up with a bunch of common attributes across zowe such as Jobs, Data-sets, files, address spaces, sysplex, LPARs etc.
In order to let extenders easily work with us in a predictable and relatable way we need to specify these and share them across zowe.

We need a strategy around how we collaboratively define these - how and where are they stored across different languages? (Swagger model?)

I guess this is a 2.0 items as currently I guess that the explorers, zss and cli all have different data models and will need merging together.

History:

Currently, ZOWE user community doesn't have any way to monitor the new developments and enhancements coming in ZOWE.

Problem:

A user needs to keep checking for new code in GIT or check any forum and then if something new comes up then proceed accordingly.

Solution:

As part of plugin definition file, we can have a set of new keys as part of pluginDefinition.json file to publish the same if contributor wants to and the same will be automatically communicated to user by social media channels.

Proposed new keys for the same in pluginDefinition.json:
"newFeature": Value of this key can be the wording about the new feature to be published.
"toBePublished": Value of this key can be Yes/No. If yes the feature key above will be published to below social Media Handles
"publishedTo": Value of this key can be an array of URLs i.e.
"publishedTo": {
"url1":"www.linkedin.com/hgdhjsaf/fdtfdvy24632hshdvhdsfh",
"url2": "www.twitter.com/API/hsdfjkshfkak/sfg656489",
}

The URLs are the Developer API for social media websites to publish the content using code.

How this works?

As soon the contributor/Developer finishes developing a new Plugin or enhancement, he updates the above content for publish and as soon as the ZOWE restarts, it reads the pluginDefinition.json for the plugin and parses the content and publishes the result based on that.

An architecture blog covering the major subsystems and how they link up to each other.

https://zowe.org/contribute/

We need descriptions for the following github repos on the Contribute page: https://zowe.org/contribute/

CLI

GitHub: https://github.com/zowe/zowe-cli
GitHub: https://github.com/zowe/zowe-cli-cics-plugin
GitHub: https://github.com/zowe/zowe-cli-db2-plugin
GitHub: https://github.com/zowe/zowe-cli-sample-plugin
GitHub: https://github.com/zowe/vscode-extension-for-zowe

CI/CD

https://github.com/zowe/explorer-jes
https://github.com/zowe/explorer-mvs
https://github.com/zowe/explorer-server-auth
https://github.com/zowe/explorer-server-tests
https://github.com/zowe/explorer-uss
https://github.com/zowe/zlux-file-explorer

Investigate stack exchange

Due to the Liberty to Tomcat migration, several repos are archived and several are added. Therefore, we need to update the GitHub repo information on the Contribute tab on Zowe.org. Here are the changes that are required.

Remove

Remove the following GitHub links and descriptions in the Foundation (CI/CD) section.

https://github.com/zowe/explorer-model
https://github.com/zowe/explorer-server
https://github.com/zowe/explorer-server-auth
https://github.com/zowe/explorer-server-tests
https://github.com/zowe/explorer-utilities

Add

Add the following GitHub links and descriptions in the Foundation (CI/CD) section.

https://github.com/zowe/data-sets
The Spring Boot based data set APIs.

https://github.com/zowe/explorer-api-common
Common explorer API components.

https://github.com/zowe/explorer-ui-server
A simple HTTPS server to serve Zowe Desktop Explorer plug-ins.

https://github.com/zowe/jobs
The Spring Boot based Jobs APIs.

Ready for edits/promotion:
Zowe_Jupyter blog post.docx

parent of gizafoundation/api-layer#66
parent of gizafoundation/api-layer#48
parent of zowe/zac#17
parent of zowe/zac#24
parent of zowe/zac#25
parent of zowe/zac#26

Link to blog: https://medium.com/@dkelosky/building-mainframe-metal-c-and-testing-with-jest-and-zowe-cli-1ee19bf3cf02

There are more and more applications available within the Zowe ecosystem. As such it would be good to have a single place to find what's available and a simple and reasonable mechanism to deliver and install the applications/extensions.

Promotion

In order to highlight the growing ecosystem of apps leveraging the Zowe framework, the community would like to develop content to describe what is currently available today. To highlight the growing list of open source apps, extensions and plug-ins below, we need help to develop either a short blog/article or even a 3-5min video highlighting the use cases, extensibility, and value that these apps deliver to the framework.

List of apps, extensions and plug-ins needing to be highlighted (in no specific order):

• Sample Angular App: https://github.com/zowe/sample-angular-app
• Sample React App: https://github.com/zowe/sample-react-app
• Sample i-Frame App: https://github.com/zowe/sample-iframe-app
  File Transfer: https://github.com/zowe/file-transfer-app (not ready, WIP)
  z/OS Subsystem Explorer: https://github.com/zowe/zos-subsystems (not currently in Zowe "suite")
• Zowe Jupyter App: https://github.com/zowe/jupyter-app
• DB2 Library for Zowe DB Browser: https://github.com/zowe/db-browser-db2
• VSCode Extension for Zowe: https://github.com/zowe/vscode-extension-for-zowe
• Zowe CLI Db2 Plug-in: https://github.com/zowe/zowe-cli-db2-plugin
• Zowe CLI CICS Plug-in: https://github.com/zowe/zowe-cli-cics-plugin
• Zowe CLI IMS Plug-in: https://github.com/zowe/zowe-cli-ims-plugin
• zTrial Sample CLI Plug-in: https://github.com/zowe/ztrial-sample-cli-plugin
• zLux Editor: https://github.com/zowe/zlux-editor
• USS Explorer: https://github.com/zowe/explorer-uss
• JES Explorer: https://github.com/zowe/explorer-jes
• MVS Explorer: https://github.com/zowe/explorer-mvs
• TN3270: https://github.com/zowe/tn3270-ng2
• VT App: https://github.com/zowe/vt-ng2
• Workflow Editor: https://github.com/zowe/zlux-workflow
• zLux API Catalog: https://github.com/zowe/api-layer/tree/master/zlux-api-catalog

Blogs: If you choose to write a blog you have the option to post it to the OMP blog here and make sure to attach any images you'd like included in your blog.

Videos: If you choose to do a video/demo please follow the submission guidelines here.

Currently the various APIs and UIs have different messaging and logging implementations.
We should create some clear and consistent standards for the apps to use.
We should consider:

• Globalisation - create a common set of message ids so we can do browser based translation independent from the server. I believe Matt has reserved the prefix OMP for this?
• Logging formats and service differentiators.

We should probably make a 'special interest group' or something where we can invite people create some guidelines and standards and possibly libraries and then each component can roll them out

Blog ready for OMP/LF promotion.

Link: https://developer.ibm.com/mainframe/2019/04/01/expose-z-os-connect-ee-apis-in-zowe-api-mediation-layer/

As a potential Zowe user I need it to be easier for me to learn what Zowe really is so that I can decide if it will be of any help to me.

Blog ready for OMP/LF promotion.

Link: https://www.ibm.com/developerworks/community/blogs/5e65990a-9690-42e2-93b1-c2267be7620c/entry/Leverage_Zowe_to_accelerate_and_simplify_problem_resolution_in_IBM_Service_Management_Unite_SMU?lang=en

ZSS is a module required by the Zowe virtual desktop infrastructure. Its source code is currently not available to the community.

Rocket Software plans to make the source code available by March 31st 2019.

In the interim, the binary component will be made available via an alternate download. Details to retrieve the binary module will be made available prior to the Zowe GA announcement in December.

I downloaded Zowe 0.9.4 RC2 and found that MVD is no longer available at:

https://hostname:8544/ZLUX/plugins/com.rs.mvd/web/index.html

I was then informed by another developer that I should instead be going to:

http://host:8544/

which redirects to:

https://hostname:8544/ZLUX/plugins/org.zowe.zlux.bootstrap/web/

The Using Zowe desktop documentation and What's New for Zowe 0.9.4 should be updated to reflect this.

• Parent of #87 - Have License and Contract Signed with Marist College Build Environment
• Parent of zowe/zowe-install-packaging#476 - Install TSS/ACF2 On Marist College Build Environment
• Parent of zowe/zowe-install-packaging#477 - Verify If Zowe Pre-reqs Are Installed Properly on Marist College Build Environment
• Parent of zowe/zowe-install-packaging#478 - Create Snapshot for LPAR from Marist College Build Environment
• Parent of zowe/zowe-install-packaging#474 - Migrating Pax Packaging to Marist College Build Environment
• Parent of zowe/zowe-install-test#79 - Migrating Smoke Test to Marist College Build Environment
• Parent of zowe/zowe-install-test#80 - Improve Smoke Test to Test TSS/ACF2 With Marist College Build Environment

Blog read for OMP/LF promotion.

Link: https://developer.ibm.com/mainframe/2019/04/11/zowe-cli-plug-in-for-z-os-connect-ee/

For the sake of conformance to platform standards, usability and credibility we should adopt standard z/OS packaging practices (SMP/e and Portable Packages) for Zowe's z/OS components like the Zowe Desktop and API Mediation Layer.