Today's problem is yesterday's solution.
I have been away from ServerPac for over six years, but I was the
original designer of the RACFDRV and RACFTGT jobs, so I will take full
credit (or blame) for how they were intended to work.
The problem they were meant to solve was that the RACF definition
documentation was virtually *never* correct, and this was borne out by
innumerable PMRs when installation jobs failed. Worse, it was not
really practical to test it all because it was too manual, and even when
we tried to do that, typos and such caused endless grief.
So we created two jobs, with an overall z/OS section for each job, and
then subsections for other things you could order along with z/OS to be
included if you ordered them. The result *was* (at the time) tested
against new, empty RACF databases and any bugs found were fixed. That
structure virtually guaranteed some duplication in things like SETR
commands, but because of how the internals of ServerPac production
worked at the time there was no good way to prevent that.
The result was:
- Really unwieldy (we knew that going in)
- Not something anyone sane would ever actually run (ditto)
- Likely not done using anyone in particular's approach to security
definitions (ditto again)
- Intended as a *sample* one could pass off to a security administrator
so that any appropriate additional definitions could be done to allow
the jobs to run and the system to IPL.
- Something that could be tested so that omissions were found at IBM
rather than in the field.
PMRs related to missing documentation about security system definitions
dropped precipitously after the jobs were added to ServerPac, so we at
least accomplished the original goal.
If the jobs will not run against a new, empty RACF database (that is,
essentially used to create a brand new test system, on which security
definitions will be extended soon afterward), then in my opinion you
should open a PMR. If you just don't like the way they work and want
them to improve, you should open a requirement instead.
Then and now, the ServerPac team does understand the strong desire to
find the needed deltas for an upgrade rather than always seeing the full
set of minimally-required profiles for a new system. On my wish list
for "someday" back then was a way to go determine what things were not
defined (profiles, entries on access lists, etc.) and then create new
*sample* (again!) definitions for people to give their security
administrators, but other things intervened.
None of this changes anything, of course, but I thought some might want
to know how we got here in the first place.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
