I should make a few more points about z/OSMF release levels and prerequisites.
The z/OS Management Facility is (or was) available separately at no additional charge for z/OS 2.1 and prior releases of z/OS, as far back as z/OS 1.10. Starting with z/OS 2.2 the z/OS Management Facility is included at no additional charge in the base z/OS operating system. Over time the z/OS Management Facility is acquiring more capabilities. The first set of RESTful APIs for system-level functions debuted in z/OSMF 1.13 and z/OS 1.13. If you look at the z/OSMF Programming Guide (and other z/OSMF documentation) for prior and current z/OSMF releases, you can see how the RESTful APIs have grown to provide today's much richer set of functions. As with any/every other remote API choice, you have to use it -- you have to turn it on, secure it, manage it, etc. If you need a remote API, you have to use a remote API. With z/OSMF that's easy to do, and it's especially easy to do in z/OS 2.2. There are also excellent z/OSMF security controls available, recommended, and well documented. Of course z/OSMF supports HTTPS. By the way, "remote" doesn't necessarily mean "another physical server." The remote API "client" for these RESTful APIs can even be on the very same machine, running on z/OS or Linux. "Remote" only means logically remote. No, you do not need a zIIP or CryptoExpress to use the z/OSMF. Both are often nice to have, but they're certainly not mandatory. If that's what you're waiting for, don't wait. If you're "kicking the tires" with z/OSMF, don't have a zIIP, and are (overly?) concerned about your peak four hour rolling average utilization, then test z/OSMF in a development LPAR (or z/VM guest), use softcapping, and/or place z/OSMF into an appropriate service class for your tire kicking. Avoiding z/OSMF because you don't have a zIIP seems completely backwards to me. Try z/OSMF (or try the latest release if it's been a couple years), *then* decide whether a zIIP has merit. Otherwise, will you ever get a zIIP? Avoiding z/OSMF because you don't have a zIIP is much like avoiding drinking water because you don't have a straw. A(nother) zIIP has merit when you have "non-trivial," CP-dispatched, zIIP-eligible workload that affects your peak 4HRA and/or that could enjoy better zIIP-enabled service characteristics (faster response times, shorter execution times) with associated business benefits. z/OSMF workload might be "trivial" and/or might be substantially or fully sub-peak. It depends. I don't prejudge, and neither should you. There's a lot of confusion, that zIIP-eligible workloads must only run on zIIP-equipped machines. That's a myth or, at the very least, a massive overgeneralization. As another analogy, remember when Intel offered math coprocessors for PCs? They were the 8087, 80287, and 80387 math coprocessors, available as options for IBM PCs, PC/ATs, and other PCs. (After the 386 Intel incorporated the math coprocessor into the main processor itself. For a while you could buy a 486SX that did not contain the math functions, but you could upgrade it to a 486DX that did.) Well, should you have waited to run the revolutionary Lotus 1-2-3 spreadsheet program (for example) until you added a math coprocessor to your PC? No, that would have been silly. In fact, many 1-2-3 users never bought a math coprocessor. Yes, the math coprocessor accelerated mathematical calculations in 1-2-3, but for some users that didn't matter (or didn't matter enough). It depended on how and how intensely they used 1-2-3. You don't know what you don't know. If you never used Lotus 1-2-3 then you never *enjoyed* the benefits of Lotus 1-2-3, to any degree, whether or not a math coprocessor had merit. That's silly! Please don't be silly. In this case, unlike Lotus 1-2-3, you don't even have to buy the software. You already have it (or can get it) if you're a z/OS licensee. Cheryl Watson has written extensively on z/OSMF. I think her comments and advice are well worth reading. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
