I don't think there is a structural difference between GENERAL and DATASET profiles for these reports.
Now that you've established that GENERAL profile access lists the $ENVGEN value, can you tweak the newlist and (for this test) remove the SIM_ fields from the sortlist command? If my hypothesis is right, $ENVGEN will be empty again. If that's the case, remember that ACCESS_PROFILE lists the profile as logged in the ACCESS record, and SIM_PROFILE is the profile that matches RESOURCE in the current RACF database. The SIM_VIA and SIM_VIA_GROUP fields (and your $ENVGEN value) rely on the SIM_PROFILE value.
If there is no profile matching RESOURCE in the (current) RACF database, the SIM_ values and the corresponding lookups will be empty.
Original Message:
Sent: Fri August 09, 2024 10:30 AM
From: Linnea Sullivan
Subject: TYPE=ACCESS and CSDATA Fields
Rob, Well I thought I tried :$envgen before on the SORTLIST and it did not work. But today it works.
sortlist,
class,
access_profile(25),
resource(40),
:$envgen("Environment",12),
userid userid:name,
last_datetime,
intent(9),
access_allowed,
rectype,
req_status_access(6,hb),
access_result(5,"AccRC",dec),
system(8),
sim_via,
sim_via_groups
So we are good for General Resources.
I tweaked the SELECT / SORTLIST for Datasets but the $envdsn field does not report anything:
select,
rectype=(auth,fast,def),
access_result=0,
class=dataset access_profile=:syssa
sortlist,
class,
access_profile(25),
resource(40),
:$envdsn("Environment",12),
userid userid:name,
last_datetime,
intent(9),
access_allowed,
rectype,
req_status_access(6,hb),
access_result(5,"AccRC",dec),
system(8),
sim_via,
sim_via_groups
Would there be anything different about datasets compared to resources?
------------------------------
Linnea Sullivan
------------------------------
Original Message:
Sent: Fri August 09, 2024 05:02 AM
From: Rob van Hoboken
Subject: TYPE=ACCESS and CSDATA Fields
Have you tried if the proper UACC shows up when you add :UACC in the sortlist line?
if $ENVGEN is the name of a CSDATA field (including the $), then an object property lookup is supposed to work according to manual
The optional base field is followed by one or more levels of lookup. If you omit the base field, the operation is called an object property lookup or implicit lookup. If the base field is present, the operation is an explicit lookup. Explicit lookups can be an ID lookup, a general lookup, or a deftype lookup. If there is more than one lookup operator (:), the operation is a multi-level lookup. Since release 2.5, the target field can also be a custom field name as defined in the CFIELD class in a RACF database.
For the Object property lookup, information about the main object in the current record (most often an SMF record) is automatically determined as the base for the lookup in the security database.
The object property lookup is supported only:
- To default (no targettype specified) from ACCESS, AS_DD, COMPLIANCE, DSN, ID, RACF, RACF_ACCESS, RACF_ACCESS_ID, REPORT_SCOPE, RESOURCE, SENSDSN, SMF, and TRUSTED newlist types.
...
I'm just guessing, but perhaps the object lookup works off the SIM_PROFILE field. If adding :UACC does not add a valid UACC value in your report, can you also add SIM_PROFILE to check my guess? So
sortlist,
class,
resource,
access_profile,
sim_profile,
:uacc,
:$envgen("Environment",10)
And... you are running 2.5.0 or 3.1.0 of course?
------------------------------
Rob van Hoboken
------------------------------