25 wishes for the mainframe anno 2023

I listed my wishes for the mainframe. Can we have this please ? For our software and hardware suppliers: Continuous testing, at reasonable cost. Continuous testing is not an option anymore. For the speed that modern agile software factories need, continuous functional, regression and performance testing are mandatory. But with mainframes, the cost of continuous testing quickly become inhibitive. Currently all MSUs are the same, and the new testing MSUs are driving the hardware and more importantly the MLC software costs through the roof.  Please not through yet another impractical License model (see later). Real Z hardware for flexible Dev & Test.  For reliable and manageable regression and performance testing, multiple configurations of test environments are needed, on real Z hardware. The emulation software zPDT or zD&T is not fit-for-purpose and not a manageable and maintainable solution for these needs. Some problem, same solution for our software suppliers. Customers do not want to notice that development teams of IBM / CA/Broadcom / Compuware / BMC / HCL /  Rocket / ... are geographically dispersed (pun). Please let all your software developers in your company work the same way, on shared problem.  Sysplex is not an option but a given. Everything sysplex-enabled by default please. Meaning, ready for data sharing, queue sharing, file sharing, VIPA, etcetera. Cloud is not an option but a given. I do not mean Saas. I mean everything is scripted and ready to be automated. Everything can be engineered and parameterised once and rerun many times. Open source z/OS sandbox for everyone (community managed– do we want to help with this?). Want to boost innovation on the mainframe? Let's have a publicly accessible mainframe for individual practitioners. And I mean for z/OS!    Open source code (parts) for extensions (radicalize ZOWE and Zorow like initiatives). Give us more open source for z/OS. And the opportunity for the broad public to contribute. We need a community mainframe for z/OS open source initiatives. Open APIs on everything. Extend what z/OSMF has given us: APIs on everything you create. Automatically.  Everything Unicode. Yes there are more characters than those in codepage 037,and they are really used on mainframes outside the US. Automate everything. (everything!) Fast and easy 5 minute OS+MW installation (push button), like Linux and Windows. Ok make it half an hour. Still too challenging? Ok, half a day. (Hide SMP/E for customers?) Clean up old stuff. There is a lot of things that are not useful nowadays anymore. For example, ISPF is full of it. For example Primary ISPF screen ISR@PRIM Option 1, 4, 5 7 can go. Many other things (print and punch utilities, really).  Standardized z/OS images. Remove customization options. Work on a standardized z/OS image. We don't need the option to rename SYS1.LINKLIB to OURCO.CUSTOM.LINKLIB. Define a standard. If customers want to deviate, it is their problem, not all ours. Standardized software distribution. My goodness everyone has invented something to get code from the installation to their LPARs because there's nothing there. Develop/define a standard. (Oh, and we do…

Provisioning z/OS

This week I entertained a little talk about provisioning automation for z/OS. IBM has created a provisioning tool for z/OS that is part of the z/OS base. I talked about our experiences with the tool. It is changing to Ansible technology now. Next technology hop. Let's talk tech again to refrain from doing things. Later that same day I started a course called Google Cloud Platform Essentials. Auch!! We are somewhat behind on z/OS. That is a major understatement. We done do tapes anymore, and MVSGENs, but it still feels like an upgrade from a horse to a steam engine. Yet, I believe if done well the z/OS tools available today should allow us to catch up quickly. There's no technical obstacle. It's only mindset.

Modern mainframe application development

  • Post category:DBAOTM
  • Reading time:6 mins read

In the previous DBAOTM article on DevOps I have introduced the traditional development process, which is often still used in a mainframe environment. In this post I will present a modern approach to development on the mainframe. Modern development processes for the mainframe Requirements for the development process have changed. Applications must be built faster and it must be possible to change applications more often and quicker without impacting the quality of the application. In other words, agile development is needed. The only way to address today business needs into modern agile development processes is to automate all build and deploy processes. A set of principles can then be derived for modern mainframe develops processes. All application artefacts are managed in the (or a) Source Code Management tool.The build processes for all artefact are automated, and can be coherently executed.A build can be deployed in any environment. A build has no environment or organization-specific dependencies.The deployment process for a build is fully automated. Including the fallback procedure. The deployment process is a coherent process for all application artefacts. These principles need to be supported by tools and processes that are (re)designed for these purposes. Of course this is not something specific to z/OS applications, but is true for any modern IT solution. But with the background I have sketched in the previous section, there is a legacy of development processes and tools to take into account and in many organizations this implies significant technical and organizational changes. The modern SCM for z/OS The modern SCM tool for z/OS needs to support all kinds of application artefacts. For the mainframe this means for one thing that not only traditional MVS-type artefacts must be supported, like COBOL programs, COPYBOOKS and JCL, but also Unix type artefacts like Unix scripts and configuration files in z/OS Unix directories. The tools and processes should allow for EBCDIC type artefacts to be created or the z/OS runtime environment, as well as ASCI, Unicode and binary artefacts. Modern SCM tools that can manage z/OS artefacts, are ISPW from Compuware, RTC form IBM, and a new option nowadays is Git, or GitHub. Build automation The modern DevOps process automates the creation of a build. The build process takes the required versions of the application artefacts from the source code management repository and creates a coherent package of these artefacts. This package, also called the build, is deployed in a (test) environment. The build could be deployed in any runtime environment, even outside your organizations. This principle not only enforces standardization of processes and infrastructure in your IT organization, it also allows any future deployments in yet unknown environments – for example in the Cloud. The automated build process itself should be callable through some generic API, so it can be integrated into other automated processes when needed. Build automation on z/OS can be accomplished with a number of tools. Some of these tools are able to handle the z/OS specific needs. IBM has two solutions: Rational build engine…

DBAOTM Operating systems for the big mainframe box

In the previous posts I have given an overview of the most important mainframe hardware components. In this article I will summarize what operating systems you can run on this hardware. But first… This post appears as part of a number of articles in the category “Don’t Be Afraid Of The Mainframe”. What is actually a mainframe A little late to answer this question, but I thought it was good to address this here. A mainframe is a large computer that is designed to run many different computing tasks at the same time. A mainframe stems from the time where hardware was expensive, and a single central solution for computing was the only way to economically run computing tasks. A lot of characteristics of that design point are still prevalent today. Hence it is good to understand this background. z/OS and Linux, and then some… A number of operating systems can run on the mainframe. I will give a short description here of the operating systems you can run on a mainframe. For the rest of the series of articles I will focus on the two most important ones today. z/OS is the most important mainframe operating system, but also the most different from today’s mainstream operating systems. I will discuss z/OS most extensively.  Linux for the mainframe is the second most important operating system and has gained popularity over the past decade. I will discuss Linux for the mainframe in a separate chapter Linux for the mainframe. z/OS IBM often calls z/OS their flagship mainframe operating system. The roots of z/OS date back to 1964, when the operating system OS/360 was designed for the System/360 computer, the predecessor of IBM’s modern mainframe computers. In the early 70s the successor of the OS/360 operating system was developed, and named MVS (it stands for Multiple Virtual Storage, but you can forget that immediately). MVS has evolved further into OS/390 and now it is called z/OS. The name changes may suggest fundamental different systems, but these are in fact only marketing-driven name changes for MVS and the technology base is still the same, although it has very significantly evolved. z/VM, the mother of all hypervisors z/VM, or VM (VM stands for Virtual Machine) as it was originally named, used to be a full-fledged operating system that was design to run business applications. The operating system included a unique technology that allowed users to virtualize the mainframe hardware and split it up into small virtual machines. Nowadays we have VMWare, KVM, Xen, Hyper-V and others that do the same for x86 and other platforms. But the technology in VM was developed in the 1960s. It was far ahead of it’s time. z/VM can be considered the mother of all hypervisors. z/VM is nowadays it is only still used as a hypervisor for the mainframe, and is no longer as an operating system for business applications. z/VSE The z/VSE operating system is the small brother of z/OS. It was developed in parallel to MVS,…

Compile and run a COBOL program on z/OS – A mini-tutorial

  • Post category:COBOL
  • Reading time:1 min read

With this mini-tutorial you may get a quick start with COBOL on z/OS. It gives you a handson overview of the process to get a COBOL program running on z/OS. The tutorial will show you how to create a Hello World COBOL program on z/OS, compile it and then run in. You can find the program itseld and the JCL scripts for the compilation and run attached below to this post. The following video describes the process https://youtu.be/jLv4Wia-05M The following assets are used in this mini-tutorial. The Hello World COBOL program COBPROG The JCL to compile the program COBCOMP The JCL to run the program COBPROGJ /* Niek de Greef