MVS TOOLS AND TRICKS OF THE TRADE APRIL 2004 Sam Golob MVS Systems Programmer P.O. Box 906 Tallman, New York 10982 Sam Golob is a Senior Systems Programmer. He also participates in library tours and book signings with his wife, author Courtney Taylor. Sam can be contacted at sbgolob@cbttape.org. Information about the CBT MVS Tapes can be found on the web, at http://www.cbttape.org. MODULARIZING AN MVS SYSTEM - PART 3 For the last two issues, we've talked about the idea of separating different MVS components by disk pack location. This activity, while not always "the thing to do" in your own data center, provides an incomparably valuable exercise in learning "what makes MVS tick." Today, we'll finish the series with some opposite thoughts and concepts which are related to that general idea. In doing so, we'll touch on a number of valuable topics that every MVS sysprog ought to know about (or at least have an educated opinion about). One of my friends pointed out the obvious fact that if you separate different MVS components on different disk packs, you may use more disk packs than your shop wants to dedicate for system use. So that leads to the opposite plan, the idea of combining different products onto the same disk pack. My idea is that you have to separate the products first, then carefully put them back together, while constantly being aware of their logical separateness. So even if several products or components physically exist on the same volume, they can still be isolated if you have a need to do so. That's a practical compromise. Today, we'll look at this idea of "how to combine" on two different levels. The first is the idea of combining load modules from many different products into one large load library. This is a practice that was commonly done in the past, due to MVS architecture restrictions. But nowadays, with changes in the MVS facilities, I feel that the practice should be carefully eliminated. The second is the idea of combining several separate products, with all their related datasets, on the same physical disk volume. I feel that such combining should only be done after doing a lot of thinking, so the total contents of each disk pack makes some kind of logical sense. The first topic we'll discuss is the "combined load library", because a proper treatment of that topic requires knowledge of some MVS history. I want to give the idea of "the mixed-up load library" adequate treatment, so we'll talk about it first. Then after that, we'll say a few words about which different products to put on the same disk volume, and why. Your shop, especially if it has been in existence for a long time, has inherited its dataset organization for definite historical reasons. But MVS has changed over the years, and even though you may not want to rock the boat, it is very likely that your installation's system datasets and their contents will benefit from some careful review. PROS AND CONS OF THE "COMBINED LOAD LIBRARY" Many shops have combined all, or many, of their non-IBM load modules, into one large load library, often called something like SYS2.LINKLIB. Because of some MVS limitations in the past, this practice used to make sense. But now things have changed. Let's look at the situation. In the old days of MVS, before LLA (Library Lookaside) was invented, there was an efficiency question that had to do with fetching a single load module which was needed by the MVS system. System modules were (and still are) placed in partitioned datasets, load libraries, which are in turn, reported to MVS by a list in PARMLIB called the link list. To find and load one particular load module from the link list, would involve doing many (very inefficient) partitioned dataset directory searches, that had to be repeated each time a new copy of that module was needed by the system. And you would also want to minimize the number of libraries that had to be searched. To add to this, IBM (in the old days) placed an upper limit (quite low) on the total number of dataset extents that could be found in the list of link list datasets. So all those forces pushed the MVS system programmers of that time, to use as few link list libraries as possible. Following later IBM improvements to the MVS system, notably the introduction of LLA, that isn't the case anymore. But many people's thinking processes have not changed to keep pace, despite IBM's repeated announcements and encouragement to the contrary. People tend to think that it's easier not to rock the boat. After all, the production system is still running, and that's what counts. Of course, I have to explain why I think making these "combined load libraries" containing components of many products, is at least partially wrong for current MVS systems. So how does LLA work? How does LLA make a long list of many load libraries in the link list just as efficient as a short list of few? It works this way, simply put. LLA keeps an address space with information about the absolute disk directory location of every load module in the link list. After LLA initialization, when this whole structure is created, LLA has its own very efficient means of searching its address space to quickly find the disk location of any load module which is needed right now. So LLA avoids all the slow partitioned dataset directory searches, and it doesn't matter how many separate load libraries are in the link list. Besides that, IBM also removed the "total number of extents" restriction to the link list libraries quite a while ago. If a module from a link listed load library is replaced by a new copy in a different disk location, of course LLA will go and look at the old disk location in its address space. So if you create a new copy of a load module in the link list, there has to be a way of telling LLA about it. That's why IBM has supplied the ability to do a complete, or partial LLA structure refresh with operator commands, such as "F LLA,REFRESH" which does a complete rebuild of the LLA structure. This, simply put, describes the "change of architecture" which should lead to a change in our thinking. It is now permissible and efficient to put even a very large number of load libraries into the link list, and now we can separate more MVS vendor products and system components into "pure load libraries" that come solely from each vendor. What's the advantage of doing this? We can probably best answer that question by pointing out some disadvantages to the "combined load library" system. The first obvious disadvantage to a combined load library is that you don't know which product a particular load module comes from. You might answer that by saying that all load modules for a given product have a standard naming convention, with perhaps a standard prefix in the module name. But that isn't entirely true. Sometimes there's a system requirement that can't be avoided. For example, CA-1 (tape management) has to supply certain system exits, whose names, OMODVOL1 and EMODVOL1, are required by IBM. So if you see OMODVOL1 in a combined load library, you have no idea where it really came from. You can try browsing the load module, but even then, there might not be a telltale eyecatcher. However if you kept your load libraries "pure", without mixing them up, there would be no such problems. A more subtle disadvantage to combining load libraries, is that you don't know what RELEASE of a certain product that a particular module belongs to. Of course, if the vendor always supplies eyecatchers within ALL its modules (not always the case), you can use the free PDS command package (CBT Tape File 182) to issue a: FIND : /eyecatcher/ THEN SUBLIST subcommand and pick all those modules out. But that's a spotty method that obviously doesn't work in all cases, though it can help you in a particular case where the vendor is always consistently supplying the proper eyecatchers. But obviously, if a vendor drops a certain module name from a later release of its product, the old module will always remain around in the combined library, and it will never be replaced by another copy from a new release, and thus disappear. So the cleanest approach nowadays, is to keep all vendor link list libraries "pure", even if there are a lot of them. In your particular shop there may be other factors which affect a decision of this type, so the bottom line is that you always have to think straight, keep all the factors in mind, and be aware that there are no universal rules that apply to everybody. COMBINING DIFFERENT PRODUCTS ON ONE DISK PACK So now we're coming back to the other question of how to combine different MVS products and components on ONE or a few disk packs, so as to use a minimum of disk volumes for system purposes. This is not necessarily a contradiction to our original aim of separating different MVS components on different disk packs. The idea here, is that if we are limited in the number of disk volumes available to be used for system purposes, we should carefully plan which components or products to put together on each particular pack, but we should also be aware of their separateness. So we should keep each component's libraries and datasets strictly separated as much as possible, even though they may physically reside on the same disk volume. Several factors may enter, when we are making these decisions. I think the primary factor is that when looking at a dataset list of any particular system volume, the list of its contents should make obvious sense. An outsider, trying to figure out how you've organized your system volumes, should have little trouble figuring out why you've put a particular set of components or products on any particular system pack. One obvious method of disk volume organization is to put, say, all CICS-related components on one pack, all IMS-related components on a second pack, and all DB2-related components on a third pack (or set of packs). This is a clear and sensible scheme that makes the products easy to find. Of course in your particular shop, that scheme might not work out, but in many places, it will. The important idea here is to keep the dataset organization as simple and clear as possible, despite an individual installation's peculiarities. Several other factors come to mind when organizing disk datasets. We'll mention what they are, and then say a few words about each one. I'll call these factors: functionality, disk space requirements, replaceability, and unavoidable MVS system requirements. Functionality includes two considerations. The first is that related types of software components should be near each other. The second is that heavily used datasets should not interfere with each other or bottleneck the system. For example, a dataset which gets frequent RESERVEs placed against it, should not be on the same volume with other datasets that are heavily used. Disk space requirements are obvious. If there is a lot of space on a pack--enough to contain several separate components, and they do not interfere with each others' operation, then they can be placed together on the same pack. Replaceability has to do with ease of substituting a new release of the product, or ease of backing the product up. If the components of a product are scattered across several different disk volumes, then synchronized backups and replacements of software intrinsically present more difficulty. Finally, unavoidable MVS system requirements are the kind of thing where you have to put an entry in PARMLIB, or you have to put a library into the LPA list or some place on the main MVS res pack, so that the combination of purely MVS requirements forces you to place different parts of a component or product on completely different packs. With recent improvemnts to MVS, such as the ability to have many libraries in the LPA list instead of forcing you to put all modules into SYS1.LPALIB, the situation has been improved. But it still is not perfect, in this regard, by any means. So for a while at least, MVS requirements may sometimes place restrictions on sensible disk placement. I hope that this mini-series has provided us with food for thought about improving the efficiency of our MVS installations in various ways. As Gerald Weinberg once pointed out his preface to Bill Mosteller's classic 1979 book "The Systems Programmer's Problem Solver", a systems programmer is very much like a soccer goalie. Often, the action is taking place on the other side of the field. But the goalie has to anticipate, worry and plan nevertheleass, about what to do when the action comes to his side. That is the realm of what we've been discussing these last three months. You've got to accumulate the know-how today, to solve or avoid tomorrow's problems. I wish you all the best of everything, and hope to see you here again next time.