Elardus Engelbrecht pisze:
Shmuel Metz (Seymour J.) wrote:
I believe that the point at issue is what happens if you define ICHBLP in the
FACILITY class but do not activate either the TAPEVOL class or DEVSUPxx
TAPEAUTHDSN=YES.
Robert S. Hansel (RSH) wrote:
If you do not activate either the TAPEVOL class or DEVSUPxx
TAPEAUTHDSN=YES, and if you do not also define profile ICHBLP to the
FACILITY class, then RACF is not guarding the use of BLP and anyone
can use BLP with RMM.
What about this JES2 init statement with above combination(s)?
JOBCLASS(?),BLP=YES (or NO)
What will happens when BLP is YES or when it is NO?
Just curious, because I can't test it for a while.
ICHBLP is RACF mechanism, with regular USER/GROUP access lists. In
simple words JOHN has no right to BLP, while FRANK is allowed to use BLP.
JES2 JOBCLASS BLP parameter is "all or nothing". No authorized people.
In case of BLP=YES everyone can use it (but other mechanisms like RACF
still apply!). For BLP=NO every BLP request is chaged to NL. It can be
veeery misleading - BTDT in approx 2002. ;-)
RMM can further add its own BLP protection mechanism...
BTW: IMHO it's good idea to define one JOBLCASS with BLP=YES and protect
the jobclass in RACF using some exit, like IEFUJI. In such scenario BLP
is protected (and available for authorized persons!) despite type of
configuration of RMM (other TMS) and RACF TAPEVOL.
My €0.02
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 16.07.2010 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.248.328 zotych.
----------------------------------------------------------------------
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
