[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: RACROUTE Confusion
From:       Russell D Hardgrove <hardgrov () US ! IBM ! COM>
Date:       2011-04-13 19:13:34
Message-ID: OF483057F1.6CE3715B-ON85257871.0069496A-85257871.00699DD8 () us ! ibm ! com
[Download RAW message or body]

Patrick.  if you are doing a VERIFY to create an ACEE.  To pass to the
AUTH, insure that a THIRD call is done.    Another VERIFY to do an
ENVIR=DELETE.   Otherwsie you have a storage leak.

Third party AUTHs do have a performance advantage when the second and
subsequent calls are for the SAME userid.

The STAT=NO helps a lot with your VERIFY by cutting DOWN last access
updates (i.e WRITES) to the RACF DB.





.
--------------------------------------------------
Russ Hardgrove / RACF Lvl2
IBM - z/OS  Software Service
Dept. EC8A   Bldg. 707 - 2/F19
Poughkeepsie, NY  12601
hardgrov@us.ibm.com  845-435-3279
            or  295-3279 (T/L)
--------------------------------------------------
"RACF: Guilty, until proven innocent !!"    RdH 2004
"RACF, praesumitur malus donec probetur bonus"    RdH     MMX
<< Continually proving this (innocence) is not just a JOB, it's an
-ADVENTURE-   :-b  .. >>
...



From:
Patrick Roehl <uga@ROEHL-CONSULTING.COM>
To:
RACF-L@LISTSERV.UGA.EDU
Date:
04/13/2011 02:41 PM
Subject:
Re: RACROUTE Confusion



Walt - Thank you for your suggestions.  They generated a couple of
questions.

>Hayim has already provided the answer to your question, but I thought I'd
>mention that you could do this more easily using a 3rd-party RACROUTE
>REQUEST=AUTH, where you specify the user ID of interest on the AUTH call
>and let RACF worry about doing the VERIFY.

I didn't see how this could be done with one call because the REQUEST=AUTH
doesn't seem to take a password.  Is a user ID alone (with no password)
sufficient?

>But if you do want to issue the VERIFY yourself, you should probably
>specify STAT=NO so you do not make it appear as though the user has
>actually used the system.

STAT=NO is my plan, now that the basic logic is working.

Is there a performance, or any other, benefit to using a separate VERIFY
call or combine it into one AUTH call?

>Also, if the class happens to be DATASET you need more information on the
>AUTH if you want the best chance of getting the correct answer, including
>the proper RACFIND value, the kind of data set (VSAM, or non-VSAM), and
>the proper volser (and it's more complex for tape data sets, and for VSAM
>than non-VSAM).

As it happens, this is not a DATASET class.
[prev in list] [next in list] [prev in thread] [next in thread]