MVS TOOLS AND TRICKS OF THE TRADE JANUARY 2002 Note: The section on "MVS Zipping Tools" is not copyrighted by "Technical Support" magazine or by NaSPA, and does not reflect their opinion in any way. It is not to be published in the magazine (but it does remain my personal, and very strong, opinion). 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. DOES SOFTWARE USE DEPEND ON SOFTWARE COST? Today I'm going to write about something that most people don't talk about very much. I'm not going attempt to say many "authoritative things", but I do want to contribute some of my own thoughts. These ideas might serve to help people save their installations money, or at least, they might get us thinking in different directions. Maybe, in some way, they'll help folks make better use of both the "free software" and the "vendor software" which has already been installed. It's my point of view that software tools should be used, as much as possible, and as productively as possible. As a longtime sysprog, I've been exposed to a lot of vendor software, and as the proprietor of the CBT Tape collection of free software, I've been exposed to a lot of that, too. My main concern is helping the most people to get the most mileage out of their software tools. That's why I've made these very personal observations. I always ask: "If a tool is installed, how much are the people using it?" Today, I'm also asking the question: "Is there any correlation between the cost of MVS software, how many people are using it, and how often they are using it?" It's a hard question, and I just have some isolated thoughts. But I think that after so many years of thinking them, they are worth mentioning. Just about all MVS installations, of course, buy system and application software from either IBM or from other vendors. It happens to be true that in many cases, the software is under-used. That's why you have "software inventory packages" which monitor the use of the other software packages, within an installation. These software inventory products are used to help an installation's managers determine if a vendor software product should be continued, or whether it should be dropped. Even if a product is free, such as software products which come from the huge CBT Tape collection, it still helps to know if the product is being used. While the free product is not being paid for, it still might be "cluttering up the software table", and sometimes a decision has to be made about it, whether to keep it in the main libraries, or to move it off to the side. There are considerations other than just the volume of software use, that can relate to software cost. I'll give one example. IBM has created a set of "structured macros" for assembler language coding, which they have included in their optional HLASM Toolkit. The HLASM Toolkit is a separately paid-for add-on to the High Level Assembler. These macros add an IF-THEN-ELSE capability to assembler language, and also contribute DO WHILE structures and the like. It is obvious that the set of macros is potentially very useful. However, I, for one, would be afraid to write any code with them. Why? The answer is, that if a person codes Assembler with these macros, the source code will not be portable. Because of IBM's packaging structure for the macros, including them in the optional Toolkit, instead of keeping them with the base HLASM product which everybody has, any source code that uses this set of macros can only be assembled in an installation that has licensed the Toolkit. You can't take the source code with you, or send it out to assemble it at another installation, unless the HLASM Toolkit is there too. Thus, IBM's packaging policy for this useful set of macros has effectively curtailed their use, in a very major way. My suggestion to remedy that situation, and to make the people less afraid to use this tool, would be to include the "structured macro set" in the base HLASM product, and to spread its development cost among the much larger base of purchasers of "base HLASM", which everyone needs to have. Then, any code that uses these macros, will be truly portable in today's MVS environment. And people would be far more inclined to start using these IBM macros, in writing their code. People really prefer to use software that is perceived as "standard IBM", and it's about time that IBM started realizing that too! Meanwhile, as an alternative to using IBM's macros, people could try some of the free sets of structured macros, which appear in the CBT Tape collection. I've made a preliminary search of CBT Tape Files which might contain similar structured macros that are free, and of course, "portable". These are Files 024, 107, 119, 304, 316, 341, 352, 438, and 471. You're welcome to look at these sets of macros and evaluate if they would be helpful for your coding efforts. SOFTWARE DEVELOPMENT COSTS People have to pay bills. Someone who develops software for a living, has to cover expenses, so the software has to be charged for. It would also be nice to make a profit. The profit motive has driven many businesses, all over the world, for as long as anyone remembers. Now let's look at "free software", which is the other side of the coin. How does free software get developed? That's a little different. Usually, free software is developed by people whose primary job is not to write code for a living. They get their paycheck from somewhere else, like doing MVS Systems Programming. In their work, they'll need a software tool, so they code something up, and usually their installation needs it too. So the installation doesn't care that the programmer gives away the tool to somebody else also, because that installation is not in the software development business. And this is the origin of many of the free MVS software tools in the world. People share their useful software creations with others, provided they're not in the primary business of writing the stuff to pay their own expenses. With this in mind, I'm going to give another example about the usage of a tool depending on its cost. This example is of a completely different nature than anything we've mentioned before. MVS ZIPPING TOOLS Practically everyone uses PKZIP or WinZIP or some other file compression tool on the PC, on UNIX systems, or on OS/2. On those systems, the compression tool often is freeware, Shareware, or may cost a maximum of perhaps 50 dollars. Therefore, zipping and unzipping file compression tools on the PC, are used almost universally, by literally billions of computer users. Now consider the "zip" situation on MVS. At a few previous shops, I looked into it. After inquiring at one software manufacturer, I found that for a very moderate-sized shop, their cost for what we wanted to do, amounted to almost forty thousand dollars! I get to talking with MVS sysprogs in a lot of different places. It's no wonder, that only a very small percentage of MVS shops have a mainframe zipping package! It's the cost. And it's the fact that this manufacturer seems to create the impression that if you want to get an MVS zipping tool, you have to come to them. I looked into alternatives, and found that it's not true. Another software manufacturer, in Australia, has a perfectly fine MVS zipping tool that (with a little bothering from me) they made completely compatible with the first tool. (I asked for FB-80 zipped files on MVS, and even though they had previously defaulted to VB, they whipped up the FB PTF over one weekend.) The Australian manufacturer charged eight thousand dollars for our-sized installation, all extras included. This was affordable, and one more MVS installation had an MVS zipping tool in house! My point is not to cause any manufacturer a loss of business. I feel that the more expensive manufacturer is not going to lose any of its customers, because they rely on its solid reputation, and if those customers bought the product in the first place, they are willing to pay for the fine service which that company offers. But my point is, that it would help if this kind of software, which is almost universally used on other systems, were cheaper on MVS. More shops would use it. In this example, it could very well be cheaper. For instance, if a lot of the other shops (that don't have an MVS zipping tool) would look into the Australian alternative (they also provide very decent service, as I've mentioned), a far higher percentage of MVS shops would have an MVS zipping tool in house! This is another, completely different way in which software usage levels can depend on cost. There'd be more customers! By the way, there's also a third MVS "zipping" alternative I know of, which is completely free, called InfoZIP, and while I haven't tried it myself, people tell me that it's also pretty good, though not at the level of the other two. MORE THOUGHTS ON THE USAGE OF SOFTWARE I've subjectively observed, over the years, that if a computer installation has paid a lot of money for a software product, they generally will make sure to use it. There's probably a good reason they ordered it in the first place. I've seen a few examples where this was not true, and the company was wasting their money, but I don't think it happens too often. So I can generally say, that when a company spends a lot of money for software, they will use the software. What about the other side of the coin--free software? Then, it really depends. Many people will install some free software, just because they're curious. The stuff is free and available, and after the person has examined it and fulfilled his curiosity, he (or she) might not feel there's a need to use it anymore. On the other hand, some free software offering might fill a real need, and it'll be used over and over again, as much as the "pay software" is. And of course, there are all of the "middle cases", in which the free software will be used either very occasionally, or quite often. I guess I have a comment about inexpensive vendor software too. Some of that stuff is very good. My take on it, is that if the installation bought it for a need, and it fills the need, it'll generally be exercised quite a lot. If it doesn't perform completely up to expectations, the site will tend to ignore it, or they may only use it occasionally. Since they didn't spend a lot of money on it, they don't care so much. So with regard to "inexpensive software", I think that the usage levels depend directly on the software's perfomance, and the installation's real need for it. This is a case where we really find some genuine correlations. I trust that this month's column, different from most of the others, will still be helpful, because it will get us to think in new directions. In our working lives, we all have installed a lot of software. We're all kind of "flooded" with our installations' software inventory. We all ask ourselves the questions: "Why do we spend time using this package and not that one? Why do we use this feature (of a certain package) and not that one?" Once we start providing ourselves with coherent answers to this category of question, we'll start making better use of our time. Good luck to all of you, and I hope to be seeing you again next month!