XA VOLUME *ALL*(G) removal/change

[ASHER ATZMONI]

Hi ,

Our auditors have found that one of the profiles assigned to us contains 'XA VOLUME - *ALL*(G)'  rule with ACCESS(ALL) permission .
According to CA TOP SECRET guides , we lowered permission level to 'CREATE' level . However , things started to be disabled due to this change-
ICKDEF , requesting ALL access to volume started to fail , etc. . Other datasets that we were able to process in our volumes were also blocked .
Our main concern is ICKDSF . Does any one have any idea as to how such a bypass can be accomplished without introduction of overhead to TOP SECRET Installation Exit ?

    Thank you ,
           Asher

[Michael Simpson]

Just a suggestion but we have ​the following definitions in one profile.    
 XA VOLUME  = *ALL*(G)
    ACCESS  = CREATE  
 XA VOLUME  = *ALL*   
    ACCESS  = CREATE

[Eileen Becht]

Hi Asher,

Have you looked at:

Volume Access and Data Set Checking (Knowledge Base Articles - 9618)

https://ca-broadcomcsm.wolkenservicedesk.com/wolken/esd/knowledgebase_search?articleId=9618

This explains that if a volume is passed when having the permit, TSS PERMIT(ALL) VOL(*ALL*(G)) ACCESS(CREATE) , in the ALL then Data Set checking is always done.
It sounds to me that these datasets either did not have permits and failed or that the Volume passed actually was requesting ALL access for the volume in which case then you would need permits to allow ALL access to the volume.  I have never heard of this before and the ALL record permit with ACCESS(CREATE) has always worked.  Looking at the chart in article 9618, it does not show a volume of ALL access being sent as the requested access so I think that is very rare.  Have you run a violation report to look at the requested access?

Cheers,
 ~Eileen~

------------------------------
Senior Support Engineer
Broadcom
------------------------------

[ASHER ATZMONI]

​Hi Eileen ,

I had looked in TOP SECRET Guides and then changed ALL access level to CREATE to be dependant on dataset access level . This is ok
for datasets' access . However the issue here is special VOLUMES' access (i.e. IBM ICKDSF , Innovation FDR processing , etc.) .
I will have a look in the article you suggested .

   Thanks ,

          Asher

[ASHER ATZMONI]

Good morning ​ Eileen ,

This article is identical to the Top Secret Guide i acted upon - no new news here ...
This still leaves me  with the ICKDSF issue (and , potentially , other vendors' products that access volumes in ALL access level) .

   Regards ,

          Asher

[Josef Thaler]

​Hi Asher,
just from the top of my head ...
(1) you could look in  "Device Support Facilities (ICKDSF) Version Release 17 User's Guide and Reference" Guide .... authorization .... Maybe for your need of ICKDSF you could use its "offline mode" and avoid the "need" of ALL-access.   
(2) As ICKDSF resides in the linklist, you could try "program pathing" and give only a ICKDSF-privileged user volume-access "ALL" restricted via privileged PROGRAM ICKDSF: -> TSS PER(priv-acid) VOL(*ALL*(G)) PRIVPGM(ICKDSF)  ... I'm not sure, whether this works, nor did I verify it.
Regards,
Josef

[Eileen Becht]

Good day Asher & Josef,

I think Josef may have found a way to do what you need and still protect the dataset access with the permit in the ALL record.
Josef is way more knowledgeable about PROGRAM ICKDSF than I am.  This is where the community board really shows its worth ;-)
Have a wonderful day men!!

Cheers,
 ~Eileen~

------------------------------
Senior Support Engineer
Broadcom
------------------------------

[ASHER ATZMONI]

​Good moning Everyone ,

Josef ,  if "Offline Mode" is ICKDSF environment when you specify VERIFYOFFLINE in ICKDSF control statements then our default usage of
ICKDSF is VERIFYOFFLINE , i.e. UCB MUST be offline across all Sysplex lpars before attempting INIT command . I do not have a z/OS lpar that I can retest ICKDSF with 'XA VOL(*ALL*(G)) access altered to CREATE but I'm sure that was the situation when I opened this ticket .
Once I have such an lpar I will check that again . I will also check PRIVPGM path - this is more likely to suit our installation . 

I'll be back at work on October 8th and check for updates .

   Thanks again ,

       Asher