Hi Roger, The DSFS Overview has the following statement:
--------------------------------------- Security DSFS runs with the requesting application user credentials for all access to data sets. For those cases where DSFS might cache data to reduce access calls to data sets, DSFS will make specific SAF calls to verify that the user has the required authority for all accesses to cached data. DSFS does not use z/OS UNIX security protocols. For JES spool data sets, DSFS only allows users to access data sets from their own jobs. The requesting user ID must match the userid that owns the job. ----------------------------------------- This suggests to me that DSFS does a RACROUTE to check the user's authority and, if the user is authorized, opens the dataset or accesses the cached dataset on the user's behalf. The user who opens the dataset is the one you'll see in SMF records, which in this case it appears to be DSFS, and not the user initiating this action via DSFS. To see the latter, DSFS would probably have to generate its own SMF record, and based on a quick glance at the documentation, I suspect it does not do so. Perhaps an Idea / RFE is in order. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.rshconsulting.com -----Original Message----- Date: Thu, 10 Jul 2025 01:56:02 -0500 From: Roger Lowe <[email protected]> Subject: Auditing/Logging of DSFS activities Trying to find a way to audit/log activities performed by Dataset File System (DSFS).....we are have a zOS dataset managed by DSFS. This dataset has been 'updated' by an id, but all we can see from Type 14/15 SMF records is that it was DSFS. I have also looked at the SMF Type 92 Subtype 14 and again it only shows up as DSFS. I am trying to find the underlying REAL userid that has used DSFS to update the zOS dataset. I am not seeing RACF violation messages as this userid does have sufficient authority to update the dataset in the first place. I also haven't found anything useful in the USS logs. Anyone have any ideas or suggestions? Roger ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
