In the previous post I highlighted the most common peripherals. In this post I will describe how such a big piece of equipment is chopped up in smaller logical parts.
This post appears as part of a number of articles in the category “Don’t Be Afraid Of The Mainframe.
Logical partitions
We have seen above the mainframe machine can contain a huge amount of computing capacity. You will run all of your development, test, acceptance and production environments on this large box, so you need a way to spread all this computing capacity over these environments. The mainframe technology provides many facilities to achieve this.
One of the main tools to setup the hardware in logical and physical parts is a tool called PR/SM (pronounced as “prism”). With this tool you can chop up the large mainframe box into smaller virtual parts called logical partitions or LPARs. These LPARs are a smaller version of the big hardware box. In an LPAR you can run your test or production system.
A common way to split the mainframe computing capacity is to distinguish separate LPARs for Development activities, for Testing activities, Acceptance activities and of course for production.
In larger computing environments, there may be separate LPARs for different types of applications, or for different business units. A bank may have separate LPARs for their wholesales business and for their retail business. Other organisations may have separate LPARs for their business analytics applications and their logistics applications.
More technical information on PR/SM can be found here
In the previous post I introduced the mainframe server hardware. In this post I will highlight the most common peripherals – other hardware like disk storage, tape and printers.
This post appears as part of a number of articles in the category “Don’t Be Afraid Of The Mainframe.
Mainframe peripherals
There are no hard disks in a mainframe server. This is also the case for some larger x86 servers. In our laptops and PCs, we always have a hard disks – or SSD nowadays – to store our data. Storage of the data for the mainframe is external to the mainframe box. Data is stored in separate equipment, called storage controllers or storage (sub)systems.
A special high-speed network connects a mainframe to its storage. A mainframe needs a lot more disk storage than our laptops. Normal amounts of storage easily exceed 1000 TB.
By the way, a quirky thing: disk storage on the mainframe is often referred to as DASD. This is an old abbreviation for Direct Access Storage Device.
To confuse you further, when mainframers refer to “storage”, they may actually mean memory, the RAM in the box. So be careful with the term storage, and make sure what is meant when it is used.
For backup and archiving of data, many organizations still use storage on tape. Tape units, often including a “library” to register and store the tape cartridges used, are also supplied in separate boxes.
A special fibre-optic network connects the mainframe servers with the storage hardware. For this connection mainframes use a proprietary SAN protocol called FICON.
You may still have printers connected to your mainframe. But you find this not so often anymore. Most printing facilities have been replaced by online applications. Where printing is still needed, this is often done by dedicated printing facilities or printing firms.
In this post and subsequent ones, I will discuss the main hardware concepts of mainframe environments. I will not go into the tiniest detail, but I must be a bit technical. To make things easier to understand, I will compare the mainframe technology with mainstream x86 and Unix technology. You will see there is often a difference in terminology.
The mainframe has a long history. Some hardware terminology is different from what we know. To get some understanding of this hardware we need to talk a little bit about mainframe jargon.
This post appears as part of a number of articles in the category “Don’t Be Afraid Of The Mainframe.
A mainframe is a large refrigerator-size box with computing capacity. The box houses the computing units, the CPUs. These are not x86 CPU’s like in your PC. But a mainframe uses CPU’s build according to the processor architecture called IBM z/Architecture.
In your PC, the CPU, the memory and other chips are soldered on a motherboard. Like in your PC, you find a sort of motherboard in the big mainframe box. The mainframe motherboard is called a drawer. The drawer is a bit bigger than your PC motherboard because it carries more components.
On the drawer the CPU and memory chips for the mainframe are soldered, and some more components. A drawer can have a number of CPU chips. In the z14 model the number of CPU chips in a drawer can be 6.
Each CPU chip on the drawer has a number of processor cores, the actual CPUs. The number of processor cores varies per mainframe model. In the z14 mainframe model there are 10 cores on a chip.
Finally you can have multiple drawers in a mainframe box. In the z14 there can be 4 drawers.
Now let’s count. You can have a maximum of 4 drawers, each with a maximum of 6 CPU chips, each chip with 10 cores. Thus, you can have 240 processor cores in a mainframe box – the z14 model to be precise. The mainframe uses a number of these 240 cores for internal processing. For you as a mainframe user up to 170 processor cores in a single mainframe box.
You also need memory. Every drawer can have a maximum of 8 TB of memory in the z14. So in total you can have 32TB of memory in your z14 mainframe.
Besides the main computing elements, CPU and memory, the mainframe server contains almost everything else needed. Power supplies, network cards, cooling devices, I/O cards, and more .
To make sure the mainframe can continue running when one of these components fails, you find at least two items of these components in a mainframe.
In the picture of Figure 3 you can see the following components:
Processor drawers – as we saw, the motherboard of the mainframe. There can be multiple processor drawers in a machine, depending on the number of CPUs you have ordered.
PCIe Input Output drawers in which cards are configured for networking equipment, IO interfaces (disk, tape, server-to-server connections) and additional facilities such as encryption and compression. PCIe is a standard for interfaces in a computer.
Cooling components to regulate the temperature. A mainframe box can be water-cooled or air-cooled, by the way.
Power supplies to provide power for the components in the machine.
All in all, it looks very much like a normal computer, but a little bigger.
In the picture you also see two laptops. As we will see later, the big box needs to be configured. The two laptops are so-called support elements. With these support elements you can configure the hardware, and also monitor the state of the hardware.
More technical information on mainframe hardware can be found here:
Interesting podcast, in which Reg Harbeck talks with John Mertic about the history, future role and community impact of open-source technology for mainframe clinet and in general.
… their ability to have a technology stack that enables them to execute and serve their customers better, is a competitive advantage. We see open source as kind of as little bit of that leveling appeal. It’s enabling people to get to that point faster than they ever had before. You don’t need a vendor to be that person. Even legacy organizations and companies have turned themselves into software companies because open source has opened that door for them.
In my previous post I shared a way to execute operator command from a batch job using Rexx and SDSF. That is of course a bit cumbersome if you just want to fire off a fixed operator command.
Therefore here the simplest way to execute an operator command:
One of the many way to execute an operator command from a batch rexx program.
With this solution here, with Rexx and SDSF, you can embed the commands in more complex business logic, and use Rexx variables to dynamically establish values for the commands to be issued.
By the way I have started a repository on GitHub on which I will share assets in the future.
Reg Harbeck wrote an excellent article in Destination z, Overcoming IBM Z Inertia, in which encourages IBM Z (mainframe) users to take action on modernizing their mainframe.
The path of action Harbeck describes is to assign new mainframers (RePro’s) with the task to find and document what the current mainframe solutions in place are expected to do, and to work with the organisation to see what needs to retired, replaced or contained.
In other words task a new generation with the mainframe portfolio renewal, and not leave this to the old generation, who are “surviving until they retire while rocking the boat as little as possible” (hard words from Harbeck but it is time to get people in action).
In additional to the general approach Harbeck describes I think it is important to assure senior management support on a level as high as possible. Doing so you prevent that the priority of this program is too easily watered down by day-to-day priorities and you assure perceived or real “impossibilities” and roadblocks are moved out of the way resolutely. So:
Make modernization a senior management priority. Separate it organizationally from task from the KSOR (Keep the Show On the Road) activities, to make sure modernization priorities compete as little as possible with KSOR activities.
Appoint a senior management and senior technical exec with a strong Z affiliation to mentor and support and guide the young team from a organisational and strategic perspective.
Have a forward thinking, strong and respected senior mainframe specialist support the team, with education and coaching (not to do it for them).
It will be an investment and, according to the “survivors” never be as efficient as before, but one very important thing it will be: fit for the future.
This year COBOL was delivered 60 years ago as one of the first general purpose, cross-platform programming languages.
On 8 January 1960 the ‘COBOL Executive Committee’ formally approved the design of the programming language “COBOL 60”.
One of the very early adopters of COBOL in the Netherlands, and long time member of the COBOL standard, Wim Ebbinkhuijsen, did a very nice talk at the event organized by Ordina. He went through the history of COBOL through the past 60 years. As a close observer and influencer of the programming language you get a great insight in this recent history of computing. Slides can be found here.
