MVS TOOLS AND TRICKS OF THE TRADE AUGUST 2002 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. POSITIONS, AND THE DIVISION OF LABOR Today I'm going to talk about a general principle more than usual, with some of its ramifications. The reason is, that if we all review these ideas and let them "knock around inside our heads" for a while, they'll eventually cause a lot of improvement in our quality of life, both as "MVS System Doctors", and in other ways. We'll eventually stand to get a lot more satisfaction, on many fronts. This idea revolves around the general concept of dividing big jobs into many little jobs, but there's a lot more to it. All of you know that MVS is a big operating system. And just about everyone in a corporate organization, or who has ever been a part of one, knows that big corporations do a big job. And there is one basic way that the big job gets done. That is, the big job is broken up into smaller pieces. Each piece is broken into even smaller pieces, and finally, there are bite-sized pieces that one person can handle. When everybody covers his/her own piece, the corporation functions well. Otherwise, problems result. Similarly, the MVS operating system does a big job. And just like the big corporation, this big operating system is broken into smaller components, which handle smaller portions of the big job. Finally, all of the components are broken into bite-sized pieces--executable modules, which form the individual units of execution, in this huge MVS system. For the MVS system to function well, each module (i.e program) has to do it's own job, and all the programs have to work together. If one program is remiss in its duties, problems result. This is very obvious to most people in the modern world, and why does the world's big business, and the MVS operating system, work in this way? I'll give the obvious reason--it is due to physical limitations. This is easy to see. Let's ask an appropriate question: How high can a person jump in one bound? The world record at this time, is held by a man named Javier Sotomayor, who jumped eight feet high in a single bound, perhaps a handful of times. Quite a few other people have jumped over seven feet, but nine feet--not one! Yet, people walk up flights of stairs every day, and the total amount of height they have scaled, is much more than nine feet. What's the difference? They broke the big "jumping job" into bite-sized pieces--each piece, the height of a step on a staircase! And scaling each step, is a job that can be handled. LEARNING TO GENERALIZE THE PRINICPLE I want to take a few moments to digress from MVS in particular, and talk about the ramifications of the idea of dividing big jobs into bite-size tasks. It's not the "division of the labor" that's the most important thing. It's the "division of the people who do the labor", so that the appropriate people do the appropriate jobs, and the jobs get done! Many people know the joke: "How do you fit six elephants into a Volkswagen?" Answer: "Three in the front, and three in the back!" Why is this a joke? Because everybody knows it can't be done, unless you have very miniature elephants. So we see that "dividing big jobs into little ones" is not the main trick. The trick is "finding the right people who can actually accomplish each small job", after the task list has been determined. Everybody who works for an organization has (hopefully) learned the lesson of "teamwork". Each person inside the organization does a job, and all of the people, doing their jobs at least reasonably well, allow the corporation as a whole, to function and achieve its goals. But there is a lot more potential in this principle. It also works in a direction that has become very obvious in today's Internet-connected world. Cooperation and position-playing often cross organizational boundaries! OPEN-SOURCE EFFORTS vs. CORPORATIONS Let's look across organizational boundaries. For example, in an "Open-Source" software development effort, this principle is just as true. A big goal is determined. People want to develop a piece of software that does a big job. And then, the big job is divided into necessary smaller jobs, and anybody who can do one of the smaller jobs, takes a piece of the work. Even though a person is not "hired" by an open-source effort, each person who "takes a piece of the job" usually does the piece that he/she is good at, and is suited for. When they all work together, the result can be a very good one. Why is this so? It is because each person in life, is given a set of capabilities and abilities, different from everybody else's. And the tendency of each person is (more or less) to gravitate to the things he/she likes, and is good at doing. At this point, you can notice a key difference between commercial organizations and Open-Source development efforts: Within a commercial organization, the abilities of the different people dovetail. Each one is hired for a job that he/she is good at. But in commercial organizations, there is a "Personnel Department" that oversees the picking of people for tasks. The overall purpose of the Personnel Department is to make sure that each task which the organization needs done, will be covered by the appropriately skilled people. But in an Open-Source development effort, the difference is that there's no "Personnel Department" to hire, fire, and assign people to their tasks. It seems to happen "by itself", but it happens nevertheless. It's amazing how Open-Source development actually does work: People get the idea that it'd be a nice thing to get a big job done. They get together and try--each one does a piece, the best he/she can. There is a coordinator, who plans the tasks, and then they start working. A prototype product is created by the initial developers. Other people try to use the "product" that results. It needs improvement. The appropriate people are notified through the "news group" that serves as a unifier and "central nervous system" for the effort. And the effort goes on, each contributor adding his own personal pieces. New contributors come on board. And the product develops and grows, until (hopefully) it becomes very good. IMPLICATIONS FOR US AS THE "MVS DOCTORS" Now that I've spoken "in general", I'd like to talk about some immediate implications as to how these concepts affect us. Most of us occupy positions in servicing the MVS Operating System (OS/390, z/OS, or whichever version). So every once in a while, we should think about where our position is, in the larger scheme of things, and whether we can do more. Of course, in our own job and organization, we perform our required tasks, and keep the system running. But while we have been doing this, usually for many years, we're writing programs, REXX execs, CLISTs, and whatever tools we need, to get the job done. We're accumulating techniques, and (some of us) write them down. Hopefully we save all this stuff and keep it with us as we proceed in our careers. (That's good advice.) It can be safely stated that each of us has developed a niche (the kind of jobs we're skilled at doing) and also, a personal collection of techniques, programs, and tools. But each of us can become more aware of our position in the general "world system programmer picture". One of the things we can do, is to communicate more with the other MVS (VTAM, CICS, TCPIP, etc.) systems programmers of the world. An easy way to do this, is by using the Internet news groups. There are now news groups which cover just about every specialty. (See my April 1998 column on the IBM-Main LISTSERV-based news group.) And it's easier, by participating in a news group, to get all your (work) problems solved, and to get the enormous satisfaction that comes with helping others, too. This is actually a direct benefit of the idea of looking at yourself as "part of the whole world". Another benefit of "MVS Global Awareness" comes from hooking into the large free MVS software collections such as the CBT MVS Tape collections, which are available on the Internet (www.naspa.com has a link to the CBT Tape web site.) Enormous numbers of MVS tools can be had there, for free. And by contacting the contributors of the individual files personally, you can develop a friendship with many of the other MVS practitioners, asking them for help, if you need some, and providing help to them, if you can. Under many circumstances, there is a tremendous advantage to using tools from the CBT Tape collection when your shop needs a job done. The job can usually get done without the shop having to buy anything. And it'll save you personally, that you don't have to write the code yourself. Other people have already invented the wheel! You'll look very good at work, when you can come up with a solution to a problem fast, especially if it doesn't cost the shop money or much coding time. A new advantage from the CBT Tape collection is the swapping of techniques. There is a new file on the CBT Tape, File 570, which contains people's tips on "how to do things". The first contribution was a piece of advice about where to look, when your JES2 spool fills up. There have been quite a few more contributions, but in my opinion, that file, while already very useful, should be bigger. Please send me your collections of pieces of "how to do it" advice (I'm in charge of updating that), and I'll add them to File 570. Another related idea, is that many of you will be able to get enormous personal satisfaction in life, if you'll contribute from your experience (and tool and tip collections), to some piece of public work, such as a software development effort, or a public software collection like the CBT Tape, yourselves. Helping other people is a good thing. Some folks don't realize how much of a mistake it is for them, to hold back from helping other people. I've seen how much a person short-changes HIMSELF by being "selfish" and holding back from giving. The best way to have friends is to "be a friend", and to "not hold back", but to give something of yourself to another person who needs it NOW. Life has shown, over and over, that the benefit of giving something will eventually come back to you, in spades! It's an under-used principle in life. More people should know it. Sorry for the generalities this month. But I've been an MVS systems programmer for many years. And these ideas have helped me more, to be a good MVS systems programmer, than many others. I think that they are relevant to our job, and they should be specifically expressed at least once. Best of luck to all of you, and I hope to see you again, next month.