An absolutely essential course for all z/OS Systems Programmers, this four-day course is a complete introduction to the use of SMP/E for installing new software and applying changes to existing software (PTFs, APARs, etc.) for the z/OS environment.All the important aspects of using SMP/E are covered, including a detailed explanation of what. 14.1 Introduction to Oracle Solaris Zones. Oracle Solaris Zones, also known as Oracle Solaris Containers, are used to virtualize operating systems and provide an isolated and secure environment for running software applications. A zone is a virtualized operating system environment created within a single instance of the Oracle Solaris operating system.
- Introduction
SMP/E elements; how products are packaged; system modifications; the SMP/E database; sysmod: receiving, applying, accepting, restoring; System Generation; CSI; CSI configuration options; invoking SMP/E.
- Receive processing
The Receive process; Modification Control Statements; MCS: header statement functions, software environment statement; the Global Zone definition entry; GZONE entry example; Global Zone options entry; options entry example; Global Zone utility entry; Utility entry example; SMP/E allocation; Global Zone DDDEF entry; DDDEF entry example; review of Global Zone entries; creating Global Zone entries – UCLIN; relative file packaged tapes; receive processing; Global Zone sysmod entry example; Exception sysmods; held sysmod entry example; Holddata example; the RECEIVE command; Sysmod entry with SOURCEID example; REPORT SOURCEID output examples; SMP/E dialogs primary option menu & query selection menus.
- Apply processing
Product function & installation methods; Target Zone definition entry; TZONE entry example; Target Zone DDDEF entry; Target Zone DDDEF entry example; Target Zone DDDEF PATH entry; Target Zone DDDEF PATH entry example; MAC, SRC, and MOD element MCS; Data Element MCS; Program Element MCS; identifying the target system structure; how JCLIN processing works; JCLIN processing example; JCLIN report example; JCLIN: MAC and ASSEM entries, MOD and LMOD entries, DLIB entries; Invoking JCLIN; the save control dataset; determining target libraries; apply processing; concatenating macro libraries for assemblies; SYSLIB DDDEF example; the APPLY command; Target Zone SYSMOD entry example; element service level; Target Zone MAC and SRC element entries; Target Zone MOD and DATA element entries; base and dependent functions revisited; replacing an existing product; Sysmod installation via the SMP/E dialogs; SMP/E dialogs: sysmod management options.
- Accept processing
Function installation methods; Distribution Zone definition entry; DZONE entry example; Distribution Zone DDDEF entries; Distribution Zone DDDEF entry example; Accept processing; concatenating macro libraries for assemblies; the ACCEPT command; Distribution Zone SYSMOD entry example; Distribution Zone MAC and SRC element entries; Distribution Zone MOD and DATA element entries; Sysmod installation via the SMP/E dialogs; SMP/E dialogs – sysmod management options.
- Product maintenance
Product maintenance (service); product maintenance sysmods; product maintenance sysmod naming convention; product maintenance ++VER statement; updating MAC and SRC elements; updating MOD (and LMOD) elements; Sysmod relationships; the prerequisite relationship; the requisite relationship; the supersede relationship; the negative prerequisite relationship; TZONE sysmod entries; related APPLY command parameters; element service level; tracking the service level of an element; element entries; exception sysmods; resolving error holds; resolving system holds; the RELEASE MCS statement; maintenance exposure; the REPORT ERROR SYSMODS command; Sysmod regression; Sysmod construction rules; managing regression; restore processing; concatenating macro libraries for assemblies; the RESTORE command; Sysmod relationships and restore; Reject processing; the REJECT command; service delivery mechanisms used by IBM; the Recommended Service Upgrade.
- Additional SMP/E features
The conditional requisite relationship; the REPORT CROSSZONE command; cross product 'borrowing'; cross zone 'borrowing'; callable services support; processing SYSLIB in JCLIN; CALLIBS in LMOD element entries; installing LMODs that use CALLIBS; the zone management commands; installing SYSGEN and SMP/E products; the GENERATE command; the CLEANUP command; descriptive MCS statements; product and feature entries.
- Installing products and service
Reporting problems to the vendor; preparing for installation; installing maintenance; product delivery mechanisms used by IBM.
Have you installed software on a Mac? How about Linux? To install git on my Mac, I type:
Easy stuff is easy on a Mac… Unfortunately, it isn't that easy on z/OS.
z/OS is a multi-tenant system used by lots of people, so of course it won't be quite as simple as a Mac, but it sure seems complicated.
So we are trying an experiment: create an install on z/OS that is as easy as brew on the Mac. Being unoriginal, I called it zbrew (actually, I had a worse name, but another IBMer suggested zbrew, which I liked).
Since easy stuff should be easy, we decided to tackle installing and configuring the COBOL 6.3 compiler. I know compilers a bit, and I figured it was the easiest product I could think of to install and configure.
Search
The first step was to find the COBOL compiler in ShopZ. I wasn't sure what to look for, so I looked at ShopZ Application Development software. From this list, I created a really simple tab-separated list of some products, then wrote a simple search verb for zbrew:
which just does a grep for the keyword against the list.
Now I had an IBM product identifier I could use for installation and configuration. In this case, the COBOL 6.3.0 compiler is identified with IGY630.
Order
Unlike the git example for Mac above, IBM Software is licensed, and you need to order it through ShopZ. I did this step manually and got the information needed to download the software. This information gets put into a simple key/value pair file with the license information required.
Now the real work begins. What does it mean to installand configure software on z/OS, and how to make it easy? I want to use the standard software installation mechanism of SMP/E, because it takes care of important things like product pre-requisites. I want to have more of a cloud install, using a prescriptive approach, with the goal of drastically simplifying installation and configuration. But it needs to work within the confines of how other software is already installed on the system. Most importantly, it needs to be something that can be automated. The days of people reading multi-page program directories needs to be behind us. This led me to the following philosophy:
zbrew Development Philosophy
- Automation is paramount. The only way to achieve drastic time reduction is through automation
- Since our philosophy is to work with an automated, prescriptive approach, zbrew must define it's own set of Best Practices for z/OS Automated Software Installation and Configuration to achieve #1
- zbrew will not be useful with an all-or-nothing approach. zbrew needs to interact with traditional software installation and configuration
- zbrew needs feedback to ensure these Best Practices can be applied to real-world shops
Some of the Best Practices that I used were:
- Product datasets are all prefixed by ZBREW.product. So COBOL 6.3.0 compiler datasets are all under: ZBREW.IGY630. This make it easy for automation tools to find.
- Products are installed into their own SMP/E global, target, distribution zones. Global zone datasets are prefixed by ZBREW.productG, distribution zone datasets are prefixed by ZBREW.productD and target zone datasets are prefixed by ZBREW.productT. So the COBOL SMPE/ zone datasets are under ZBREW.IGY630G, ZBREW.IGY630D and ZBREW.IGY630T respectively.
- Hierarchical files are installed under /zbrew root. This makes it easy for automation tools to find. So the COBOL directory created is: /zbrew/usr/lpp/IBM/cobol/igyv6r3/
These Best Practices will change – this is an experiment after all. And that's why point #4 above is important. I'd love to hear from folks on the viability of this experiment.
Install
Installation of a software product consists of a few different steps:
- receive: the receive step downloads the software from ShopZ using the ORDER key/value pair file. Receive uses standard SMP/E RECEIVE processing, leveraging mvscmdauth in the IBM Z Open Automation Utilities to avoid JCL.
- product-prereq: check the pre-requisites for this software to ensure it can be installed (for example, the level of the operating system or any PTFs that might be required with other software)
- product-install: run any product-specific installation that is necessary
- apply: the apply step uses standard SMP/E APPLY processing, again leveraging mvscmdauth.
For the COBOL compiler, I needed to write the prereq script to check that the system was at least z/OS 2.2 and that specific LE PTFs had been applied. I needed to write the install script to allocate datasets to be used and to allocate a zFS file system, mount it, and create some directories in the file system. I used a variety of tools from the IBM Z Open Automation Utilities for this.
Configure
On a Mac, installation and configuration might be lumped into one step. On a multi-tenant system, or set of systems, it's entirely likely that you will want to install a base product image and then configure multiple instances of the product image to run on multiple target systems.
So I separated configuration out from installation, enabling you to ship the code associated with the install to another system, or use shared DASD between systems to access the install on another system.
Configuration is very similar to install, and zbrew itself does not do much:
- product-configure: run any product-specific configuration that is necessary
For COBOL, the configuration is actually really easy. It involves submitting JCL to do a compile/bind/run and verify that it works correctly. Most products have more complex configuration than the COBOL compiler.
The configuration code provides a nice example of the new JES support in IBM Z Open Automation Utilities. To see a nice flask example, check out Kaleb Porter's recent article.
Here's the interesting piece of code:
At (1), the JCL is submitted, with the job id being written to job.
The code then loops while running is true.
At (2), the 4th field of the jls output for the job is written to status. The docs describe the different types of job status, but we're after something other than AC. AC indicates the job is still active (running). We wait a second and try again if the status is indeed AC. This isn't great – it could be an infinite loop if the job was hung up somehow. But – it's an experiment…
At (3), the 5th field of the jls output for the job is written to status. This is a character representation of the overall job status.
Fitting the Pieces Together
I organized the code to have zbrew do the general purpose installation and configuration tasks, then delegate product-specific work for pre-req checking, installation, and configuration to the product being installed. So far, all I've done with my experiment is to set up code to install the COBOL 6.3.0 compiler. I expect if I move on to more complex products, things will need to be reworked a bit, but the intent is that each product would provide it's product-specific pre-req, installation, and configuration scripts.
Mac Os Mojave
So… after all that, to search for, install and configure the COBOL 6.3.0 compiler, you do the following:
- zbrew search cobol <– this says the COBOL 6.3.0 compiler is called IGY630
- zbrew install igy630 <– take all the defaults and install the compiler
- zbrew configure igy630 <– take all the defaults and configure the compiler
Mac Os Versions
If you want to try out zbrew but don't want to (or can't) get a COBOL compiler from ShopZ, you can run a hello-world example with the same steps:
- zbrew search hello <– this says the hello application is called ZHW110
- zbrew install zhw110 <– take the defaults and install the hello application
- zbrew configure zhw110 <– take the defaults and configure the hello application