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

List:       racf-l
Subject:    Re: RACF Parameter List Considerations
From:       Hayim Sokolsky <hsokolsky () DTCC ! COM>
Date:       2010-03-24 17:26:00
Message-ID: OF7C587C20.45647F0E-ON852576F0.005EB907-852576F0.005FC1F6 () dtcc ! com
[Download RAW message or body]

Phrased differently....

You should always generate a LIST form of the macro, and copy it to your
work area, then fill in the blanks using the MODIFY form, and pass it to
RACF using EXECUTE...

As in:

     LA   R0,WRACF      Target address
     LA   R1,L'WRACF    Target length
     LA   R14,LRACF     Source address
     LA   R15,LRACFL    Source length
     MVCL R0,R14        copy for use

     RACROUTE REQUEST=...,  update parmlist
          other stuff ....,
          WORKA=WWORKA,
          RELEASE=....,
          MF=(M,WRACF) call RACF

     RACROUTE REQUEST=...,  call RACF now
          other stuff ....,
          RELEASE=....,
          MF=(E,WRACF) call RACF

LRACF RACROUTE REQUEST=...,  Static list
          WORKA=*-*,
          RELEASE=....,
          MF=L
LRACFL EQU *-LRACF

WORKAREA DSECT
WRACF    DS   XL(LRACFL)
WWORKA   DS   XL512

It is possible to "hand generate" the whole parameter list. However, you
would have to ensure that both the SAFP (the SAF header for the request)
and the associated RACF parameter list do not contain an garbage - in any
place that RACF is checking. If you fail to initialize any critical field,
you will cause abends. If you fail to zero out pointers that will be used,
you will cause abends.



Hayim
_____________________________________
Hayim Sokolsky, CISSP
    Mainframe Security Architect
    DTCC Corporate Information Security
    18301 Bermuda Green Dr, MS 1-CIS
    Tampa FL 33647-1760

    Tel. (813) 470-2177



Russell D Hardgrove <hardgrov@US.IBM.COM>
Sent by: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU>
2010.03.24 12:25
Please respond to
RACF Discussion List <RACF-L@LISTSERV.UGA.EDU>


To
RACF-L@LISTSERV.UGA.EDU
cc

Subject
Re: RACF Parameter List Considerations






John,

A certain amount of syntax checking is done by the assembler when a
RACROUTE passes through it.     Certain params require a certain REL=
level...     Totally bogus params (example, ENVRIN on an AUTH call) should
fail assembly with an mnote.   (I'd epxect but have not tested)

If the caller SPECIFIES (for example) ACEE=(Rx) on an AUTH or a FASTAUTH
yet when the call occurs Rx is a FULL word of zeros, we ignore it.  If it
is the address of an INVALID ACEE, the results are 'unpredictible'. Or if
the storage is inaccessible a protection exception WILL occur.


If odd and unusual bits are ON in FLAG fields the results are (or most
likely could be) EQUALLY not as expected.




.
--------------------------------------------------
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:
"John P. Baker" <jbaker314@COMPORIUM.NET>
To:
RACF-L@LISTSERV.UGA.EDU
Date:
03/24/2010 11:58 AM
Subject:
RACF Parameter List Considerations



All,



Does RACF have any requirements in respect to parameter list bits and
fields
that are inapplicable to the request being issued?



Do these bits and fields need to be set to zero?  Are they simply ignored?



And yes, I know that a "clean" parameter list is preferable.



John P. Baker



<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>
[prev in list] [next in list] [prev in thread] [next in thread]