> > 1) The major difference between RACF and the alternatives is that all of > > the alternatives are easier to use, administer, operate and understand. > z/OS shops who bring in > Linux and z/VM usually prefer RACF on z/VM as it is much easier for them > to use, administer, operate, and understand. Why? Because RACF is > extremely popular with z/OS customers.
A koan for Considering the Presence of Buddha-Nature in ESMs: I hit myself on the head with a hammer. It hurts. I hit myself again. It still hurts. I hit myself with a padded hammer. It hurts less, but it's still being hit with a hammer -- but it's a familiar pain and I know what to do to treat it. I hit myself on the head with a empty bleach bottle. It still hurts, but it's a different kind of hurt. Here endeth the tale. If you're familiar with RACF elsewhere, then yes, you've already taken the first blow to the head, and it's a familiar pain (but not to the head, or at least not immediately). There are net-new Z sites that don't have RACF/zOS. Considered in the abstract (ie, without a pre-existing RACF investment), RACF *is* really, really ugly compared to VM:Secure or even ACF2. The reasons the alternatives exist is to ameliorate that ugly nature. I've managed systems with all three tools installed at various times. IMHO, RACF's principal advantages are that popular presence on the Other Side, and that you (IBM) own it and can decide to supply it by default if you choose to do so w/o dealing with an outside entity. You can put a lot of lipstick on that pig with RACTOOLS and some front-end execs, but it's still a pig deep down.
