MVS TOOLS AND TRICKS OF THE TRADE April 1996 Sam Golob MVS Systems Programmer sbgolob@cbttape.org Sam Golob is a Senior Systems Programmer THE PLACE OF FREE SOFTWARE IN TODAY'S MVS SHOP. We've probably noticed that our profession is changing, and it's debatable whether the change is for better or for worse. Seemingly gone are the days when a systems programmer actually made modifications to the operating system, and coded in assembler language on a regular basis. The truth of the matter is that I know some systems programmers who still code extensively in assembler, and who know very much about how the MVS operating system works. But by and large, on the strictly MVS side and excluding some of the newer specialties, such as LAN and client server work, there is a tendency toward hiring less skilled systems programmers who could more be termed "installers". As part of this trend, the responsibility for debugging is being thrown more to the shoulders of the vendors, and less trouble shooting responsibility is being given to the systems programming staff. Many myths accompany this trend, and today we're here to discuss sayings and thoughts which are true and false. Or more accurately, they are more true in one environment and less true in another. My hope is that this debate will focus our thoughts more clearly on activities which will be beneficial both to our shops and ourselves. We should proactively watch and shape the trends that are happening in our work places, rather than passively allow them to erode and degrade the environment we work in. Our first task in this matter is to try and discern the overall forces at work which are affecting us. Then, we can attempt to find ideas and policies that can help us to adjust, while maintaining our considerable skills and our usefulness to the installation at the same time. Newer people who are more highly affected by these changes can use this knowledge to plan their careers and get better experience. I guess we can call the first force, the "vendorization of software". We can call the second force, "reduction and reshaping of our employment slots". In this discussion, I think that the first force weighs more heavily, so we will talk about that. Let's take a look now at what "vendorization of software" means. It used to be that when a shop needed some functionality, their system programmers would write it themselves. The OS and MVS operating systems in the past were not so well developed and "feature packed" as they are now. Also, there was not so much vendor activity which filled our needs. Therefore, we had to do much of the work ourselves, and IBM (to their credit) gave us the leeway to do it. We had microfiche listings of operating system modules and logic manuals to show us how the different functional parts worked. Many user groups in addition to SHARE and GUIDE helped us to spread "user knowledge" of the system and make it more commonly known. This has changed with greater "programming perfection" in the MVS operating system and the incorporation of many more features into the MVS system itself (data management being included). Parallel to that, there has also been an enormous proliferation of vendor software writing activity. Functionality that formerly had to be "custom built" can now be "bought off the shelf". Although there are advantages to this change: new releases of software can be more easily migrated to, and the compatibility problems between products have been shifted to the vendors, there is considerable fallout regarding personnel, and the structure and morale of systems programming staffs. "Vendorization" has tempted the management of some companies to scuttle the skill functions of their systems programming staffs entirely. "Installers" get paid less than seasoned systems programmers who know how to code, diagnose, and fix software. And as their older staff leaves, some installations feel they can get away with hiring far less skilled "replacements" for them. While there is some validity to this argument, there are also several flaws in it. First, some really hard problems can occur once in a while, which could badly cripple a shop. Often, this might happen when one vendor's product tramples part of another vendor's product. You can't rely on the vendors in such a case, because each one will point a finger at the other products, and neglect to face the part of the problem which is truly theirs. In such a situation, your highly skilled people will invariably grasp more of the picture, to "cut through the fog" in a small fraction of the time that the less skilled people would take. The money earned by the shop's production and reliability, will then easily outweigh the difference in the salaries. Second and not so easily noticeable, are the morale problems in the personnel. The job isn't so interesting anymore. And the new people have far less opportunity and incentive to learn. The vendors (including IBM) are covering up the guts of their products, and are giving us "black boxes" to shuffle around. Again, the more skilled professionals among us, who know how to code, can often read between the lines, when a vendor changes a product. They can figure out the kind of coding which the vendor had to do, to come up with such a result. On the other hand, the less experienced people have far less of an opportunity to learn, because they don't have the background to understand the internals from looking at the externals. These people generally don't have a clue to how the internals work, at all. For the installation, the result is less support, and less control. For the employees, there is far less stimulation and growth in knowledge. Systems programmers have historically been highly creative individuals, but "vendorization" is causing this creativity to decline. HOW ACCESSIBLE SOFTWARE CAN COUNTERACT THIS TREND. I call free (public domain) MVS software by a different name: "accessible software". It is possible to contend that accessible software has benefits and drawbacks, and we will try to make both of these 2ore clear. The idea is to help every shop and its employees to benefit from a compromise. People's attitudes can then be adjusted, and the place of accessible software in today's MVS shop will be better understood. How can you get accessible software? The "granddaddy" of free software tapes is the CBT MVS Utilities Tape, which can be obtained through the NaSPA office. The CBT Tape is a vast repository of a lot of other people's work. There are highly complex utility packages on it, along with many systems programmer helpers of every description. NaSPA itself puts out its own public domain MVS VIP software tape, which has other goodies. SHARE puts out a cumulative software CD ROM after every SHARE meeting, twice a year. On the CBT tape, there is a description of other tapes on File 001, and there is an index to the contents of the other tapes on File 071. This will give you a good start in finding accessible software. I myself can do all sorts of jobs with accessible software, which would be difficult even with vendor software. For example, using the Fullscreen Zap program from File 134 of the CBT MVS Tape, I can look at a disk pack and examine the IPL text online, to see which packs have IPL text, and if it is the correct version. With the free "PDS" product from File 182, I can expand the number of directory blocks in a pds in place, without reallocating the pds and copying the members. "PDS" now has a successor vendor product called "PdsTools" from Serena International (Burlingame, California) which is much better, but either package can do some jobs that almost no other utility can do. Changing the DCB attributes of an existing dataset (on the fly) accurately, without opening and closing the dataset, is a piece of cake with the CDSCB TSO command from File 300 of the CBT Tape. And so on, almost forever. By looking at the source code, you can learn how all this is done. Once you have the CBT Tape, you'll never be able to complain that there was no place to learn how to write assembler code. Accessible software has several obvious advantages. First, your shop doesn't have to go through an elaborate and expensive acquisition process. The stuff just has to be assembled, installed, and possibly customized a bit. Then, it's there to be used. Another advantage is that the source code is available to learn from. The code can be studied as it is, but it is often accompanied by the phone number of one or more authors, who can be called for help, although this service is not guaranteed, of course. I personally have never gotten a discourteous response from any software author I have ever called for help. The learning experience from accessible software is very very valuable. If you want to know how something was done, you can just look at the code. On many occasions, if I needed to access a control block while I was writing an exit or another program, I would look at a program from the CBT Tape which does a similar job, and obtain working code. The proximity to assembler source code which you get as an installer of these tools, affords an opportunity that is almost unparalleled nowadays, to hone your assembler language skills and add to your knowledge of the MVS system. What are the objections to accessible software? One of them is the supportability. The argument is that you have to support the code forever, in your own shop. I have several answers for this. My friend Bruce Bordonaro, who is a Systems Software Manager, told me that he advocates a sort of compromise, as follows: You can use the programs in your own group. Since it's internal, it is understood what the status of these tools is. As far as giving them out to the public, it depends. If your shop has the technical expertise and management commitment to continue support for a tool, then fine, give it out. Otherwise, it's probably best not to. Another answer applies to a product like QUEUE, which is a JES2 spool browsing program akin to SDSF. Versions of QUEUE, a free product which is user-supported, are available on the CBT Tape for all versions of JES2 from 1.3.6 to 5.2.0. JES3 users need not worry. The free JES3 spool browsing program called SDF can be obtained for all recent versions of JES3 through 5.2. SDF is distributed on the JES3 SHARE-GUIDE tape which can be obtained from Alan Field, 612-828-4979. These products are needed by many shops. Therefore the job of upgrading them from release to release is undertaken by knowledgeable people who feel the need, and who do it for the public and for themselves. Although technically true, it's hard to make a statement that such products are "not supported". Practically speaking, they are supported. This process is aided by the proprietors of the various free tapes, who try and accumulate the updates as users fix things. If your shop has upgraded some free tool to fit a later release of the operating system or some component, please send it in to the proprietor of a public tape, so the tape can be updated, and everyone will benefit. You can contact me through the NaSPA office for more information. SMALL SHOPS, LARGE SHOPS, AND INCENTIVES. I once worked for a shop that had to resist something like eight outsourcing attempts in eight years. In order to run our place on a lower budget than the vendors wanted to charge, we made enormous use of accessible software, which has the advantage that it is free. We used TSSO (CBT Tape file 403) for console automation, and several other tools such as Dave Cole's automatic job scheduler (File 388) to assist in the process. Many other tools were available for diagnosis purposes, such as the CMD1 subsystem (File 261) which provides multiple system-level services, such as making non-cancelable started tasks cancelable, etc. Although we also bought vendor products, we only bought what we really needed, with the extra peripheral functions being provided by free software tools. Because we were able to resist the outsourcing, all our jobs were saved, literally. That was a relatively small shop. Large shops have to buy more vendor software to help them with their larger workload. But this does not mean that systems programmers can't have handy tools which do necessary jobs quickly, sometimes a lot quicker than the vendor products can. Since many of these tools are used in a great number of shops, any problems generally get reported to the proprietors of the free tapes where the tools are distributed, after they've been fixed by a user. Many "standard" tools from the CBT Tape are very reliable indeed, because a large number of people actually use them. In the case of larger shops, Bruce Bordonaro's advice is very much in order: For internal Systems Support, use and learn from all the tools you need. If there is management commitment and technical expertise in the shop to continue the support of a product, it is OK to give it out to the user community. If the commitment and expertise aren't there, it's probably best not to. The case of each tool should be considered on an individual basis. This minimizes the risk involved. A decently skilled systems programmer (armed with source code) generally can estimate how safe a product is. For example, TAPEMAP (File 299 of the CBT Tape) tells you what's on a tape, and it cannot do any damage, because all it does is read tapes and it cannot write. Therefore, my friend Rick Fochtman, who is very careful, gives TAPEMAP out to his user community on a non-supported basis, and he gets a lot of "thank you's" from them. Before closing, I have a few more thoughts. One argument against accessible software, is that if you don't pay for something, you don't have a contract, and therefore you don't have anyone to sue if something isn't right. To this I answer: Don't sue, fix the darn thing and avoid the hassles. Another answer, from Rick Fochtman, is that if you find, for example, a copy program to substitute for IEBGENER which is better in some way, perhaps it produces record counts and runs faster, and the program doesn't work right, you can always go back to IEBGENER. Looking for a second way to do something better, when IBM provides a "first" way, always leaves you the guaranteed fall back to the old program. One final thought is about systems programmer pride. Systems programmers thrive on the thought that they've done something to save the company money. There is always the hope of a bonus or some direct reward. But even if that isn't forthcoming, one realizes that when you have the skills to save one company money, these skills will carry over to another company too, and they will make you more marketable. Somehow, accomplishment will pay you back. One of the thrills of this job is the opportunity to find new ways to "establish your worth" to the operation. Companies should realize that systems programmers can improve their computing efficiency, and this will reflect in the bottom line. If you give your systems programmers the incentive to learn and grow in the job, they will certainly save your company money in the long run, because they are motivated to. I know I haven't mentioned all the arguments on all sides of these matters. But in this attempt to lay out the substance of these issues which are on our minds, I hope to stimulate your thoughts and help you establish a better relationship between management and staff on the subject of incentive to learn, personal growth, bottom-line computing efficiency, and staff morale. Good luck. See you next month.