Idea Details

Current TSS environment only supports commands to be commented indirectly but not in the way to be

Last activity 05-31-2019 02:22 AM
markus.grzeskiewicz1.1's profile image
03-11-2016 05:28 AM

As we’re moving away from direct permits, it would be
very helpful being able relating once granted rights. For example:

 

tss per(acid) dsn(one.data.set.name) acc(upd) comment('Temp. permit to solve incident no. 1234567 ')

 

tss
lis(acid) data(a,comment)

 

XA
DATASET = ONE.DATA.SET.NAME       UNTIL(12.03.16) OWNER(ANOWNER )

     ACCESS  = UPDATE
     COMMENT = 'Temp. permit to solve incident no. 1234567'

 

In that way it’s much butter understandable why certain rights had been granted for whatever reason.


Comments

08-26-2018 01:55 AM

Another idea with probably similar underlying intentions: https://communities.ca.com/ideas/235717791?commentID=233902293#comment-233902293

10-13-2016 05:22 PM

I like the capability very much.  But what's the cost to the TSS database, in size and performance?  Seems to me if they were to add this feature, the comments would have to be stored in a separate dataset where TSS could go fetch the comments if asked (eg when creating the CFILE or when asked during a WHOHAS or LIST statement); each installation could then make its own decision about whether to use the feature.  I'm guessing most would not, based on fears about draining MIPS.

 

Still ... sure would be nice to be able to.

09-16-2016 02:12 AM

Hello Josef,

 

that's exactly how it was meant (our partner raised my idea here). I was always annoyed of seeing something not knowing why colleagues granted this or that. And of course someone could argue there is the "comment function /*" but this needs an additional step (the extract of the command log), it's not directly visible _and_ for legal reasons we need to anonymise this data after a while -- so it would be lost. Anyhow I gave and "up" for your idea as well.

 

Best regards!

09-09-2016 08:30 AM

I definitely agree here, especially to the underlying consideration, that the most important thing is the intended permission + reason + circumstances and not the resclass(resname), which is just the mean for the intention.

 

And it is the intention, which should be made as visible as possible!

 

A different or additional idea, but with the same underlying consideration is https://communities.ca.com/ideas/235732292  

A description of the resclass(resname), resclass(resprefix) or resclass(resmask) could be entered once and could be made visible at every reference of this resclass(resname/prefix/mask).

I'd explain it gladly in more detail, if you would like to ...