Blog Archives

As you may already know, on a Windows PC, everything goes through the registry. So, whenever you want to run an application the registry must be referenced. In very simple terms, this is exactly what a catalogue does under MVS or z/OS. All datasets are accessed through a catalogue.
Furthermore, there a two very big differences between a catalogue and the Windows registry. The first difference is that mainframes are built to support high availability in a 24/7 environment, whilst your average PC’s aren’t built for this purpose. The other big difference is that with a mainframe you can have multiple catalogues as opposed to one registry on the Windows PC.
However, there is one more similarity between the Windows registry and the mainframe catalogue: They can both get damaged and they can both certainly break. Even worse, catalogues break far more often. And in an even more serious scenario, the majority of companies are completely blind to this. Only a handful of companies only consider catalogues when building disaster recovery plans. Companies that leave themselves exposed to this danger are placing themselves in serious danger before they even start.
There are a number of reasons for this. Firstly, you cannot, using IBM’s native facilities, re-distribute datasets across catalogues without taking the original catalogue down for a long period of time, which in most companies shoes, simply cannot afford to do so. In addition to this, IBM provides the ability to split catalogues but it can only carry out this task if the catalogues are clean. However, in order to ensure that the catalogues are clean, you need a diagnostics facility.
As a result of this, it is very rare for companies to create whole new catalogues and even when they do, most datasets still go through the first of those catalogues. Yes, indeed, it is quite normal for tens or even thousands of datasets to be going through one single catalogue.
In turn, this creates a problem of its own. Due to this, a much bigger strain is forced onto the catalogue especially for shared access, controls blocks and so on, that are being accessed by more and more applications. Furthermore, performance starts to decrease. Because IBM never really designed catalogues for these sorts of volumes, IBM were forced to introduce new code to increase catalogue performance.
As I mentioned previous, many companies fail to notice that these threats exist, and potentially, they are very serious ones. There are options available, however. These tools allow you to do online dataset re-distribution, split catalogues, diagnose, and analyse the structure of catalogues. You’ll need these tools anyway to help decide dataset re-distribution. In addition to these tools there are others like advanced back-up and recovery. IBM offers basic forward recovery capability.
The leading vendor today is Mainstar, with their Catalogue Recovery plus product, having some 200 users worldwide. You may not know of Mainstar, and if not, that’s because they haven’t been big in the market, out of the US anyway. Mainstar now feel ready to bring catalogue breakage to a wider audience. Expect to hear more about this company in due course.