1. October 2020
Quarterly Update
Zowe Webinar Series
Zowe™, the Zowe™ logo, and the Open Mainframe Project™ are trademarks of The Linux® Foundation

2. Agenda
• Quarterly Update Intent
• Zowe Update
• Focus Topic
• Squad News
• Recent & Upcoming Events
• Polls
• Q/A

3. Series Overview
Rose Sakach, Zowe Onboarding

4. Meeting Goals
• Forum for information exchange
• Regular cadence
• Focus topics / guest speakers
• Zowe Squad Focus
• Upcoming events
• Feedback

5. Zowe Update
Bruce Armstrong, Zowe Leadership
Committee (Acting Chair)

6. Zowe Joint
Community Q4 2020
Planning Summary
Presenter: Bruce Armstrong (armstrob@us.ibm.com)

7. Themes for Zowe Community 4Q
Development Activities
Zowe is a collection of teams (we call “squads”) – each with their own
development actions AND with “cross squad” activities
• Squad names typically go by the technology they develop:
– Zowe Explorer
– Zowe CLI/Client SDK
– Zowe API Mediation Layer
– Zowe Desktop/Application Framework
– Zowe Systems Team
– Zowe Onboarding
– Zowe Documentation
• The community gathers quarterly to plan the next development activities –
recording of October specifics here:
https://github.com/zowe/community/blob/master/Project%20Management/PI%20Planning/20PI4%20Planning/README.md

8. Zowe Explorer
• Continuation of
Conformance Criteria
development
• Profile experience
improvements
• Improved experience
searching and working with
data sets and members
Zowe Client SDK
• Validate Zowe CLI on Node v14
• Allow for a single profile that stores
information commonly needed for core +
plug-ins
• Ensure documentation ensures successful
installation of the Zowe CLI in
environments with proxies
• Allow for recently run commands to be
easily recalled

9. API Mediation Layer
• x.509 client certificate
authentication support for API ML
• API versioning support reflected in
the Zowe API ML Catalog
• AT-TLS aware API ML
• High-availability support
implementation - Caching API and
Dynamic Registration related
works
• API ML Metrics dashboard
Web UI
Zowe Application framework
Containerization
• Launch a beta of both Linux & zLinux docker
images + begin work to support ZCX
High Availability
• Finish implementing the auto-restart tool for
Zowe components
• Implement a state storage tool
• Package both into release
• Update servers to utilize state storage tool
Editor Unification
Package manager UX improvements
• Using Conda

10. Systems Team
Performance
• Enhance Performance Test Coverage
High Availability
• Create Caching API with VSAM support
• Implement Zowe Launcher
• Update Zowe and component packaging to
support High Availability
CI/CD
• Automated testing catch-up
• More dashboarding of component, build and
test status
Onboarding
Conformance Process Maturity
• Develop a process for updating the Conformance
Criteria for all components
Improve initial Onboarding
Experience
• Better direct Onboarders to appropriate areas
within the Zowe Community
Extend OUTREACH efforts
• Increase focus on ISVs and Community members
in general
Manage Production of and Leverage
Statistics
• Help all squads to identify Zowe Interest,
Experimentation,and Challenges - Continue
maturing statistics process and reporting

11. Documentation
Persona/Interest-based doc
• Zowe users can get and browse a list of interested topics
within a few clicks by selecting an area of interest, role, and
skill level
Improve contribution doc
• Zowe contributors can begin contributing to
documentation, code, and test by reading the contribution
guide on the doc site
Content analytics
• Analyze the docs web data and user feedback to gather
more insights about doc enhancement
Github Wiki Doc Integration
• Find an efficient way to migrate information being written
on the wiki (by devs) into the doc site
Reimaging zowe.org home page
• Add Zowe Explorer
• Update terminology to latest
description of Zowe
• New overview video
• ….

12. 350+ Registered Attendees
All 37 talks are available on YouTub
19 talks had Zowe content
Please rate how the event improved your understanding of
the Zowe Project. Very useful (41%) Extremely useful (31% )
How likely are you to start a Zowe project or PoC in the
next 6-12 months? Very likely (28%) Extremely likely (31%)

13. https://www.share.org/page/the-latest-news-to-exploit-zowe-in-products-or-your-
enterprise-parts-1-3
152 Attendees
SHARE Participation

14. Focus Topic
Zowe ZSS
Joe Devlin, ZOSS Team, LLC

15. Focus Topic
• Zowe ZSS
• Learn how we are extending the Zowe ZSS (z/OS back-end) to facilitate
building in-depth (cross-memory, privileged, system-level) mainframe
products with little-to-no assembler code required

16. ZOWE:ZSS and
ZIS
• Privileged ZOS Programming in C
• Joe Devlin, ZOSS Team, LLC, October 2020
• (joe.devlin@gmail.com)

17. Disclaimers
• ZOSS Team, LLC is dedicated to making open
source software work on ZOS
• Opinions are solely those of the author and
ZOSS Team, LLC
• We are only talking about ZOS, not Linux on
IBM Z
• Linux on IBM Z is just Linux and does all the
great things that Linuxes do!
• If any other Marketing has blurred this
distinction, they must answer to their own
gods.

18. Business
Problem
Statement
• ZOS will be a major enterprise platform for 1-2 more decades at least
• Very few programmers can program internals or write privileged code
• The programming community is largely an Assembler Community
• Post Unix/Linux the OS and Tools community is 99% C/C++ code.
• Data and Tools Are API-ified or given new UI’s (thx, Zowe!)
• BUT… what if you want to build something new, build a better
mousetrap?
• Training Time for ZOS programmers
• 5 years to be a journeyman
• 10-15 years to be a real senior or principal software engineer
• Many tools are painfully old and suffer from dire usability issues
• Z Hardware continues to evolve
• Code needs to be improved to take advantage

19. The Goal: Build Privileged ZOS Applications
• Examples
• Monitoring Programs
• Debuggers
• Connectivity extensions: Cloud storage, new device drivers
• System Tailoring (ie. Exits)
• Log Data Access
• Profilers
• Configuration tools and analyzers
• Virtualization and Containers
• Openness, in general

20. Why is ZOS so %^&#@ Different?
• Z started as OS360 in 1964
• Almost every idea originated or on Z
• Virtual memory
• Multi-tasking
• Virtualization and Hypervising
• Stable ABI’s and backward compatibility
• All the evolutionary stages are simultaneously present
• All the good and all the bad since 1964 still work
• It’s a 24/31/64 bit OS
• Two Completely different data storage systems
• Catalogs/Volumes/Datasets and Filesystems/Files
• Awkward and outdated Unix-ish overlay (USS)
• It feels like Linux, until you want to do anything

21. Privileged code
• Essentially an OS Extension, can do anything the OS can do
• Secure, only execute what the caller is allowed to do
• No info leakage
• Bug-free, especially overlays/overflows
• Must provide logging
• Must clean up all resources explicitly (no process tear-down to fix
everything)
• Version aware, work with callers of compiled over many API versions

22. Partial Glossary: (nothing’s really exactly equivalent)
LINUX/UNIX ZOS
Process Address Space
Daemon, Server Started Task (STC), Subsystem
Thread TCB, SRB (Dispatchable Units)
Root / Superuser/ UID=0 APF Authozation, Supervisor Mode
Kernel Mode/ <n/a> / User Mode Key 0 / Key 1-7 / Key 8
Filesystem and Files Catalogs and Datasets
Syscall SVC, PC-call
Path STEPLIB, Concatenation
Conf File PARMLIB
Signals, Exception ABEND, Program Interrupt
n/a Memory Subpools
n/a, and that’s a good thing! AMODE (24/31/64)
n/a AR-Mode, ALET’s and ASC Modes

23. Privileged Programming in Linux
• Examples
• The Kernel
• Drivers
• Kernel Extensions (LKM’s)
• Semi-privileged code
• System calls that require rood (uid == 0)
• It is rare to write privileged code
• But if you do there are 1000’s of examples
on the net
• System Calls are the standard interface
• SYSCALL, SYSENTER in X86
• IOCTL’s

24. Privileged
Programmin
g on Z
• OS Extension: None officially
• Privileged started tasks and subsystems
• Many/Most traditional product on Z has privileged started tasks (!)
• Any thing that is not business logic and for batch and TX processing
• Platform is not secure, but securable
• Security is assumed or “grandfathered” for these products
• Pen testing is continuing to find *MANY* vulnerabilities in
extremely common products
• Hazards: Key 0 code, Privilege-escalating SVC’s and PC’s
• Many kinds privileged code needs
• Many OS API’s require privileged callers (SUP or key 0-7)
• Many OS Data structures are published
• And many that are not published are accessed, too
• System Exits
• Interrupt Request (IRB’s)
• Service Request Block (SRB’s)
• Supervisor Calls (SVC’s)
• Program Calls (PC’s)
• IO Appendages
• Etc…

25. Privileged
Programmin
g on Z (2)
• Resource Management
• ESTAE’s for Tasks
• FRR for SRB’s
• ARR for PC calls,
• RTMs for Task and Address Space
• Etc.
• Assembly Language (HLASM) Everywhere
• The doc is presented to an HLASM consumer, only
• Most older programmers only think that privileged
programming can happen in HLASM (or PLX if you
worked at IBM)
• There is a project to map all DSECTs to C, but NOT
API’s

26. The ZSS/ZIS Thesis
• Programmers know C and learning the OS is enough work without forcing mastery of
HLASM
• YOU NEED A FRAMEWORK, DON’T GO IT ALONE
• Code Plugins to for both privileged and unprivileged code
• Extensions (ZIS-AUX) to adapt existing code
• Standard MVS command interface
• Standard Recovery and Resource management
• PC-call framework for
• SAF controlled RBAC of all service points
• IBM-approved implementation of security
• https://conferences.gse.org.uk/2019/presentations/FN.pdf

27. ZSS/ZIS is “Opinionated”
• Support key 1-7 programming
• Avoid key 0 for robustness
• Cross memory API
• Aggressively promote 64 bit memory, shared and common
• <2G storage in most shops is running low
• Dataspaces are a programmers’ nightmare
• IARV64 supports 64 private, shared and common to cover all use cases.
• Metal C only for privileged code
• Support or Metal/C in Exits/SRB/IRB
• LE Makes too many assumptions around TCB, LE Anchor Areas (ie Globals)
• What about POSIX?
• LE languages are a bit “sandboxed” in ZOS. The full breadth of variation of the DU is more than what LE
represents
• Problem vs Supervisor state
• Keys, AMODES, fixed vs pageable, many stack locations and formats,
• DU Type: TCB vs SRB

28. What’s in the ZSS/ZIS Box?
• Critical data structures
• ZSS provide thread safe Q, Hashtables
• Logging Framework (Components, Levels, Multiple log targets)
• Started Task Framework
• A general multi-threaded, multi-user-serving server!
• Lightweight Exception handling for TCB and SRB code
• JSON and XML handling
• Memory management, ZOS, not POSIX
• Crypto API’s
• Security (Authentication and Authorization)
• QSAM and VSAM API’s
• …and much, much, more

29. ZSS before ZIS
• ZSS required APF-authorization (not all customers will want to grant it)
• The entire ZSS address space had the ability to elevate privileges (including code exposed to the Web)
• Due to a large code-base, audit process may have taken a lot of time and resources

30. ZSS with ZIS
• ZSS does not require APF-authorization
• All privileged code is isolated in the cross-memory server (ZIS)
• The cross-memory server's code base is much smaller, the source code audit should be easier

31. How do I get started?
• Build or deploy the cross-memory server from binaries
• Create your own plug-in to host privileged services
• Use the client code in your ZSS plug-in or application to drive the services

32. Source code
• github.com/zowe/zowe-common-c/
• c/crossmemory.c – core low-level code (global resource allocation, PC routine
handlers, core command handler)
• github.com/zowe/zss
• c/zis/* - management code (config, plug-in system)
• c/zis/client.c – code used by client application (service wrappers)
• c/zis/services/* - core services
• plugins/zis/* - plug-in examples

33. Server installation
• ZWESIS01 load module:
• APF-authorized
• Runs in key 4
• Non-swappable
• ZWESIP00 PARMLIB member:
• Can be in a system defined PARMLIB or a user PDS dataset
• Started task:
• The STC user must have an OMVS segment
• Security:
• ZWES.IS in FACILITY
• Callers must have READ access

34. What is a ZIS plug-in?
• A load module with the following requirements:
• AMODE 64
• Reentrant
• The entry point returns the plug-in descriptor data structure

35. Writing a plug-in
• In your entry point code use the following functions:
• zisCreatePlugin – creates a plug-in descriptor
• name – a unique 16 character name for your plug-in
• nickname – a unique 4 character name used for sending modify commands
• initFunction – the function called when the plug-in get installed
• termFunction - the function called upon ZIS termination
• commandFunction - the function called when a command is sent to the plug-in
• zisCreateService – creates a service descriptor
• name – a unique 16 character name for your service
• initFunction – the function called when upon ZIS startup
• termFunction - the function called upon ZIS termination
• serveFunction – the function called when the service gets invoked
• zisPluginAddService – adds a service to your plug-in
• plugin – your plug-in descriptor
• service – the service to be added
• Finally, return the plug-in descriptor using a “return” statement

36. Deploying a plug-in
• Put the load module in the ZIS STEPLIB dataset
• Add the following line to the ZIS PARMLIB member
ZWES.PLUGIN.plugin_name=module_name

37. Calling a service
• Calling a core service
• Use cmsCallService or the wrapper functions from zss/h/zis/client.h
• This requires passing a hardcoded service ID
• Calling a plug-in service
• Use zisCallService from zss/h/zis/client.h
• In order to call a service you need to know its plug-in and service names

38. ZIS architecture

39. Invocation path

40. What’s Next?
• 64 Bit ZSS Server (ZIS is already)
• Per ZIS-Service SAF Security
• General SRB Support in Metal C
• General IRB Support in Metal C
• Extensible Shareable Object Graphs
• Rich data from SRB’s and Exits thru ZIS-ZSS-
WebServices
• Project InZpect
• Open Source Debugger/Inspector/DumpAnalyzer
written on ZSS/ZIS

41. Focus Squad
Zowe CLI
Michael Bauer, Zowe CLI Squad Lead

42. Focus Squad
• The Zowe CLI – Team Enablement
• The Zowe CLI Squad is working on features to enable team usage. Take
this opportunity to share your feedback on this capability and on any of
your challenges in using Zowe CLI.

43. Profile Basics
• Profiles allow you to store default command options so that you do not
need to specify them on each command
• Sample command without profiles:
zowe files list data-set “CUST001.*” --host myLPAR.comp.com --port 443
--reject-unauthorized false --user username --password password
• Same command with profiles set:
zowe files list data-set “CUST001.*”
• You can change default profiles to easily target different services without
having to change scripting logic.

44. Profile Management
• Profiles are fairly easy to manage today as long as the number of services
you are interacting with is small and you are not frequently targeting
different services of the same type.
• However, the growing Zowe ecosystem influenced us to introduce base
profiles. Base profiles can contain information applicable to all profile
types. These properties include hostname, port, username, password,
reject-unauthorized.

45. Base Profiles
• Sample profile creation commands without base profiles:
zowe profiles create zosmf demo --host myLPAR.comp.com --port 443
--reject-unauthorized false --user username --password password
zowe profiles create endevor demo --host myLPAR.comp.com --port 6000
--reject-unauthorized false --user username --password password
• Sample profile creation commands without base profiles:
zowe profiles create base demo --host myLPAR.comp.com
--reject-unauthorized false --user username --password password
zowe profiles create zosmf demo --port 443 --dd
zowe profiles create endevor demo --port 6000 --dd

46. Profile Challenges
• Today, profiles are user based. Each user needs to set up their own
profiles on their client. In addition, if you are targeting different systems
when working on different projects, you need to remember to set your
default profiles appropriately.
• Profiles are stored in multiple folders making them more difficult to share.
• Automating profile creation can aid in team adoption:
https://medium.com/modern-mainframe/zowe-cli-tips-tricks-79607b8dbd4e
(See Tip #5). However, someone needs to setup this custom automation
and each team member must invoke it.

47. Profile Direction
• Represent all profile information in a single document that can be easily
shared and maintained alongside projects in source control.
• When a team member checks out a project with a zowe.config.json file,
their client will respect those settings.
• Another file, zowe.user.json, can be added alongside zowe.config.json for
user-specific options that should not be shared with the team or checked
into source control (user preferences, credentials, etc.).

48. New Command Line Order of Precedence
1. Command Line Options (--host myLPAR.comp.com)
2. Environment variables (ZOWE_OPT_HOST=myLPAR.comp.com)
3. zowe.user.json settings (user specific settings for a project)
4. zowe.config.json settings (shared amongst the team for a project)
5. User profiles
Note: within each level (zowe.user.json, zowe.config.json, and user profiles),
service profile information overrides base profile information.

49. Upcoming Events
Rose Sakach, Zowe Onboarding

50. Save / Be Aware of These Dates
• Zowe System Demos
– Sep29
– Nov09
– Dec07
– Jan04
• Zowe PI Planning
– 21PI1 Dates TBD
– Jan07-08 (tentative)
• Zowe-related Webinars
– SHARE (3-part Zowe Replay)
– DevOps.Com
Current PI Ends

51. Zowe Calendar
• OMP Calendar: https://lists.openmainframeproject.org/calendar
• Calendar URL: https://lists.openmainframeproject.org/g/zowe-
dev/ics/3109196/317992940/feed.ics

52. Engage with us!
• Popular Channels:
– # general
– # zowe-onboarding
– #zowe-user
– #zowe-cli
– #zowe-explorer
– #zowe-api
– #zowe-doc

53. • Mark your calendars!
– Wed Jan 20, 2021, 11:30 ET
– Register Today!
• https://www.openmainframeproject.org/events/category/all
Next Quarterly Webinar

54. Questions?

55. Thank you!