> -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of R.S. > Sent: Wednesday May 24 2006 00:10 > > I think it's typical for IBM. Examples:
<snip> > 2. DB2 doesn't (wasn't) check RACF profile when > started/closed. Effect: > everybody (who can issue operator commands) can kill DB2. The > same person can be strictly controlled when i.e. using > DISPLAY command, he could be authorized to D SMF, but not D > IPLINFO. But not -dsn STOP DB2. This sort of makes sense, though, if you think about how the command is being processed. DB2 commands are routed via the SSI prefix character(s), so my take is that this occurs before MVS command SAF (being generic, here) checking. If DB2 did things right (ahem) and used MODIFY (like many other data base, TP monitor, and server products), then SAF could protect through the command facility (thou shalt not perform MODIFY against *MSTR, for example). But because it's the way it is, you have to GRANT/REVOKE in DB2, which puts what I consider not-part-of-data-access-management security in the hands of the DBA, rather than the security administrator. (Disclaimer: I've worn the security administrator hat a couple of times in my career. Caveat utor.) > 3. IND$FILE also uses BLKSIZE of 3200/6160. > There are more examples like the above. At one time, the linkage editor was very touchy about block sizes > 3200 unless you played games with PARM SIZE= and REGION. For many years the distributed compiler procs used block sizes of 3120, which also relates to some of the early TSO defaults for block sizes for 2314? 3330? DASDs (efficiency, you know - anyone got a 2314 or 3330 card lying around?) Later, Ray ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
