CA Top Secret

Expand all | Collapse all

interpreting TSS LIST outputs

Jump to Best Answer
  • 1.  interpreting TSS LIST outputs

    Posted 07-03-2018 05:52 PM

    Is there a good site that explains output from TSS LIST commands?

    In particular:


    1)   when listing a TYPE=PROFILE, it lists the associated acids at the bottom.  I notice some have -SC at the end of the acids, wondering what SC means...e.g.   ABCDEF -SC


    2)   when listing a TYPE=USER I see some 'XA' statements...e.g.  XA DATASET =; XA TSOACCT = abcd;  XA OTRAN = 1234.    Does XA means "direct permits" to that resource?



  • 2.  Re: interpreting TSS LIST outputs

    Posted 07-03-2018 06:04 PM

    The XA  DATASET= means a TSS PER(prof) DSN( was done.


    Same with other resources or ACID (TSS PER(prof) ACID(ABCD)


    TEST99  -SC means a type acid

    you may also see 

    LSCA1   -LC



    Just issue a TSS LIST on the ACID and you will get you answer

  • 3.  Re: interpreting TSS LIST outputs
    Best Answer

    Posted 07-04-2018 03:26 AM



    I can recommend, some answers to your question you could find for example there:


    In docops there is also a search function. 


    When you are signed-in, you can submit comments and questions at the bottom of a chapter, which are handled by alert CA people! And I'd like to encourage you to feedback, if anything seems to be unclear or incomplete; clear and improved docs are a benefit for you and all other users !


    Best regards,


  • 4.  Re: interpreting TSS LIST outputs

    Posted 07-13-2018 01:32 PM

    Bobs, to answer your two specific questions:  1) Yes, the XA is permission to a resource.  If it's in the user ACID I would call the permission "direct", but you'll also see them in profiles.  If instead of "XA DATASET" you see just "DATASET" (for example), it means the ID owns the resource...which, as in RACF, implies full access to it as well.  (For that reason CA mostly recommends that you not give ownership of a resource to a user ACID, although of course there can be exceptions.)  And 2) as Robert Lynch partially said, "-SC" is an abbreviation that tells you the ACID is an SCA, a central security admin.  ("Central" corresponds to system-level SECURITY, as opposed to group-level.)     The other security admin types are:


    MSCA: The master ACID (like IBMUSER, only in TSS you can name it anything)

    ZCA: An user ID with administrative authority over every ID in its zone

    VCA: An user ID with administrative authority over every ID in its division

    DCA: An user ID with administrative authority over every ID in its department

    LCA: The 'L' stands for "limit"; I've never used or created one, but the manual says "An LSCA is not associated with any specific zone, division, or department. It has the same capabilities as an SCA but rules of scope checking apply."

  • 5.  Re: interpreting TSS LIST outputs

    Posted 08-20-2018 01:37 PM

    I was under impression if a user has SCA they can manage any TSS record but I'm finding this untrue as our new SCA user is getting:




    the following 2 commands was executed to give SCA access, thinking the DATA(ALL) covers all profile types, but it appears its only to  "list" all profiles?


    TSS MOVE(abcd) TYPE(SCA)                          


    instead of granting every resource types, is there a command to grant a new SCA user to administer all profiles in TSS? 

  • 6.  Re: interpreting TSS LIST outputs

    Posted 08-20-2018 02:53 PM

    The SCA has SCOPE to "manage any TSS record" however the ADMINISTRATION AUTHORITIES defines what the SCA can do.

    For example site may have Help Desk SCA's and limit them to Unsuspend and Reset Passwords only.

    But as a SCA they can perform this to all Users.


    You can list out the SCA and see what Admin Auth it has, and tweak accordingly

    Refer to the Top Secret User's Guide to get details on the various Admin Authorities.


    ACID = *ALL*
    MISC1 = *ALL*
    MISC2 = *ALL*
    MISC3 = SDT
    MISC4 = *ALL*
    MISC5 = *ALL*
    MISC8 = *ALL*
    MISC9 = *ALL*

  • 7.  Re: interpreting TSS LIST outputs

    Posted 08-20-2018 03:12 PM

    Bobby, I think the key is this:  You're right that making an ACID into TYPE(SCA) will allow it to manipulate all ACIDs, but there's also the question of which manipulations can be performed.  If an administrator can list ACIDs, then being CENTRAL (SCA) means he can list all ACIDs—but it doesn't follow that he can change them.  The TSS manual touches briefly on this under "Using", "Types of Administrative Authorities".  It gives examples under "Using", "Creating Security Administrators", "Assign Administrative Authority".  (Really we need them to number their sections so we can refer to them more easily.)  But if you want a full description of the various authorities I think you have to start with "Using" / "Issuing Commands to Communicate Administrative Requirements" / "Command Functions" / "ADMIN Function—Grant Administrative Authority", which will get you a list of all the types of admin authority (ACID, DATA, FACILITY, MISC1 etc).  Then you look up each of those authorities under "Using" / "Issuing Commands to Communicate Administrative Requirements" / "Keywords" / <ACID, DATA, FACILITY, MISC1 etc> for a detailed description of what each subfunction does.


    For example, Under "Keywords" / "DATA Keyword with ADMIN—Determine the Authority to List Information", it says "Use the DATA keyword with the ADMIN command to give or remove CA Top Secret administrators the authority to list Security File information."  Note it says to list information.  If you want your admin to be able to update something, for example to give an ACID a permission to a resource, I think you need not DATA (or rather not just DATA) but also RESOURCE.  To give an admin authority for a particular resource class you might say




    Or you could say ...DATASET(ALL) for all types of authority in the DATASET class.  To do all resource classes, as you ask, use RESOURCE rather than a particular class name:




    I recommend you look through all the subfunctions to see what each one does.  TSS gives you very granular control over what each admin can do, but that means of course that you have to know more than just a single command to give that authority.

  • 8.  Re: interpreting TSS LIST outputs

    Posted 08-20-2018 03:06 PM


    For the content that Robert Lynch refers to above, you'll find it in the documentation about assigning administrative authority (located under Creating Security Administrators) on the CA Top Secret DocOps space.


  • 9.  Re: interpreting TSS LIST outputs

    Posted 08-20-2018 03:15 PM

    Hi everyone, thank you for your replies…


    I find many instructions on google the commands to give the authorities needed but can’t find a command that lists what authorities they have.


    This info does not appear to be in a simple TSS LIST(userid) DATA(A) command.  Is there a command to list?  regards

  • 10.  Re: interpreting TSS LIST outputs

    Posted 08-20-2018 03:22 PM

    TSS LIS(userid) DATA(ADMIN)


    Documented in the TSS User's Guide

  • 11.  Re: interpreting TSS LIST outputs

    Posted 08-20-2018 03:31 PM

    Robert, that is the command!  Thank you


    Bobby Sagami

    HNA Mainframe Platform security

    Tel:  310-781-4060

  • 12.  Re: interpreting TSS LIST outputs

    Posted 08-20-2018 03:31 PM

    Bobby, when I do TSS LIST(myID) DATA(A)  I see my own admin authorities.  Same when I list someone else's.  What do you see when — no, don't answer that.  If you don't see admin authorities using that command, maybe the ACID doesn't have any.  If you're sure it does, you may have to open a case with CA.  But they wouldn't want you putting sensitive details here in the forum.

  • 13.  Re: interpreting TSS LIST outputs

    Posted 08-20-2018 04:19 PM

    Hey Bob you are absolutely correct…I  do  see it in the  last portion of the TSS LIST(userid) DATA(A) command!


    The TSS LIST( userid) DATA(ADMIN) command from Robert Lynch also comes in handy just to list that portion.


    Thank you guys!

  • 14.  Re: interpreting TSS LIST outputs

    Posted 08-24-2018 12:45 PM

    Hi Bob, a TSS LIST(ALL) shows the following which I couldn’t find much info on. It has access to some resources and facilities..


    Is TYPE=GLOBAL the same as RACF’s GLOBAL class?



    TYPE       = GLOBAL    SIZE       =    14336  BYTES


    Bobby Sagami

    HNA Mainframe Platform security

    Tel:  310-781-4060

  • 15.  Re: interpreting TSS LIST outputs

    Posted 08-24-2018 12:56 PM

    TYPE=GLOBAL indicates that it is a reserved record.
    The TYPE=GLOBAL acids are:
    These acids can not be deleted.


    So TSS LIS(ALL), you are listing what's in your ALL Record

  • 16.  Re: interpreting TSS LIST outputs

    Posted 08-24-2018 03:01 PM

    Right, I think of the ALL record as a "fake ACID", although the TSS developers may not see it that way.  You can treat it as an ACID with the usual commands—LIST, PERMIT and so on (though not DELETE as Mr Lynch pointed out).  I don't suppose it looks like an ACID internally, though, which is why I whisper "fake" to myself when I call it an ACID.  It's purpose, at any rate, is determine access that isn't specified by a user's own ACID or by any of her profiles.  Anything you permit to the ALL record is applied to any user ID unless it's handled by some permission earlier in the search.


    For instance, if I say PER(ALL) OTRAN(BELL), I'm saying anyone can use the BELL transaction.  (EXECUTE access is the default so I don't have to specify it.)  But I can still forbid it to a particular user by saying PER(exception) OTRAN(BELL) ACC(NONE); TSS sees that permission first, and acts on it, without ever getting as far as the ALL record.


    I've never had occasion to use some of the "fake ACIDs" that Robert listed.  But I can tell you that STC is a list of connections between started-task procs and the ACID assigned to each, RDT is a definition of all resource classes (like the dynamic CDT in RACF), FDT is for defining and using installation defined fields (and segments, I think), and the SDT, let's see...oh, I've never used that one either; it's for the calender and some other miscellany.

  • 17.  Re: interpreting TSS LIST outputs

    Posted 08-29-2018 05:45 PM

    In a profile I’m in, I see that it owns dataset ABCD, which means I have all access.


    I need to make it ABCD.123 read access, and everything else ABCD.* all access.


    Is my first step to delete ownership  from this profile and put it somewhere else?  I can’t find the command to delete ABCD as owner.


    Once I delete the owner, where do I assign it as the owner?  I have a profile called ALL, is that an option.


    After owner is defined, then I can define ABCD.123 and ABCD.* at the right level access to my profile?


    Btw I see some profiles defined as 1234. and 1234 without the dot.  Does the dot signify more than 1 qualifier




    Bobby Sagami

    HNA Mainframe Platform security

    Tel:  310-781-4060

  • 18.  Re: interpreting TSS LIST outputs

    Posted 08-30-2018 01:08 PM

    Bobby, I recommend you start a new thread for each new question, unless of course it's a followup to a old one.  This one, I'd say, should be a new topic.


    1) You probably realize it already, but if a profile owns DATASET(ABCD) then everyone in that profile has all access, not just you.  Just sayin'.


    2) There might be another way to do it, but yeah, I'd start by moving that ownership to some other ACID.  If there's no user or group of profiles whom you want to have DATASET(ABCD) ACC(ALL) then move the ownership to a department ACID.  (Definitely do not assign the ownership to ALL.)  You can do this two ways (that I know of):


    tss rem(profilex) dataset(abcd)

    tss add(dept1234) dataset(abcd)


    tss add(dept1234) dataset(abcd) undercut


    The "undercut" argument means "yeah, I already understand that someone else owns that; take it away".  Someone at CA may tell you I don't have the concept quite right, but that's how I understand it.


    3) Yes, once you have the ownership assigned to an ACID without granting any access, you can then handle the permissions as you want to:


    tss per(profilex) dataset( access(read)

    tss per(profilex) dataset(abcd) access(all)


    (You understand that "123" wouldn't be valid for a dataset name.)


    4) IIRC you speak RACF, right?  The matter of the dot in a dataset permission (or in any other class, for that matter) is about what you might expect.  If you permit someone DATASET(ABCD.) (with the period) it's equivalent to ABCD.*.** in RACF; it permits to any dataset that starts with "ABCD.".  (Not quite the same as ABCD.** in RACF, because that includes a dataset with just the HLQ and nothing else, but in TSS if you specify the period then there has to be a period in the DSN.)  Without the period—DATASET(ABCD)—it's equivalent in RACF to ABCD*.**; the dataset must start with "ABCD".  You see?

  • 19.  Re: interpreting TSS LIST outputs

    Posted 08-30-2018 05:53 PM

    Hey Bob, thanks as always!  Agree, should be new topic, got lazy! Lol


    The “tss rem(profilex) dataset(abcd)” worked…somehow I was led to believe to use DSNAME(ABCD)

    Reason I mention give ownership to ALL profile is I saw it as a profile with nobody in access list, made me believe it’s just a “holding” area.  But then the name fields says GLOBAL-RESOURCE so its probably the same as RACF’s GLOBAL…used globally


    The ABCD is owned by us in security so I defined ownership in our user profile reserved for security.  But as owner, I couldn’t specify ABCD.123 READ only.   So I will look into Department ACID as you suggested as I want to avoid creating a profile just for this sole purpose…


    That UNDERCUT is a new concept to me…don’t see anything like that in RACF


    And thanks for pointing out the difference in dataset masking ABCD vs ABCD with the dot…I fully understand…



    Bobby Sagami

    HNA Mainframe Platform security

    Tel:  310-781-4060

  • 20.  Re: interpreting TSS LIST outputs

    Posted 08-31-2018 09:35 AM

    Hi Bobby,

    If you're interested on further reading up on undercutting, you'll find information at the following DocOps locations:


  • 21.  Re: interpreting TSS LIST outputs

    Posted 09-04-2018 01:10 PM

    Hi Kris, thank you for those links!   As a lifetime RACFer it’s a concept I’m not familiar with and this helps, sorta kind of… 


    Bobby Sagami

    HNA Mainframe Platform security

    Tel:  310-781-4060

  • 22.  Re: interpreting TSS LIST outputs

    Posted 10-17-2018 11:48 AM

    I was going over old emails in my In box and realized I meant to reply to this long ago.  By now maybe anything I add is moot, but just in case:


    Just now I don't remember what GLOBAL means in RACF.  In TSS, what happens is that the algorithm looks at the user's permissions for a match to the access request.  Failing a match there, it looks through the user's profiles.  If it still didn't find  match it looks at the permissions in *ALL*.  ALL is a sort of profile-for-everyone.


    Therefore if you put ownership of a resource in ALL, you're giving everyone full owner's access to that resource, which is probably not what you intended.  Although I should add that I've never done that; maybe TSS treats the ALL record differently, prevents you assigning ownership to ALL or something.  But in general CA recommends that you assign ownership to ACIDs that don't confer access, usually to department ACIDs.  I don't hesitate to


      tss add(user2222) dataset(user2222.)


    ...thus giving USER2222 ownership of his own datasets.  But for anything more general than that, not so much.


    UNDERCUT and RACF: As I recall RACF handles ownership differently.  For one thing, it assumes that datasets with an HLQ of "USER2222" belong to USER2222; when USER2222 tries to access such a dataset, RACF doesn't even consult its access rules, it just allows it.  For the rest, ownership is of profiles rather than of resources; the owner of a profile can change the profile, but cannot automatically access the resource itself.  So I think this is another case (like "profile" and "global") where RACF and TSS use the same word but for different concepts; don't be fooled into thinking they're analogous.


    (That gave me fits when I first set out to learn RACF 15 years ago.  The guy who hired me said "sure, you can learn RACF from the manuals", and I said "sure, I can learn RACF from the manuals", and for the first six months I wondered tearfully "what was I thinking?!".  A large part of that problem was the RACF manuals calmly using words such as "profile" and me picturing entirely the wrong entity.  I got over it eventually.  But it would have taken me much less time, and much less emotional wear and tear, had I tracked down someone who speaks both RACF and TSS and gotten him to explain a few things.  It's one reason I like contributing to a conversation like this.)

  • 23.  Re: interpreting TSS LIST outputs

    Posted 10-18-2018 05:33 AM

    Hi Bob,

    I'd like to share some personal statements *), hoping they help to broaden your understanding and to answer some of your questions.

    Kind regards,


    *) Please do not hesitate to feedback, when they would need to be corrected or amended... 


    (1) Keep in mind, that from a certain perspective Top Secret (actually: the security server product, because this is valid also for RACF and also ACF/2) acts as an inqiry system The access to a resource is always
    done by the operating system or the application. The operating system or the application (subsystems or vendor products etc.) just asks Top Secret or does not  ask Top Secret, before it accesses the resource. It is alway up to the operating system or application, whether the access takes place or not.
    (2) Top Secret, if asked, can give principally three different answers like: "granted", "denied" and "do not know that resource". The path, how Top Secret comes to its decision/result is influenced in many ways, not only the specific authorisations permitted to the user-acid, to one of the tss-profiles attached to the userid or to the *ALL*-record. The decision depends among others from TSS-options (e.g. AUTH(...)) privileges of the user-acid (e.g. NODSNCHK), best match-algorithm and much more. @CA Technologies: It would be very interesting to make the complete decision-tree visible in a documentation... maybe it already exists ...


    (3) The permissions in the *ALL*-record are effective according to the AUTH(...) option. Please see I did not try it, but I think, that you can NOT ADD ownership of resources to the *ALL*-record. You could use the '%' masking character to permit access to user specific resources, which contain the userid somewhere in the resourcename. See also


    (4) "Ownership" is a kind of circumstance, which could make the application (or operating system) to even skip the security call to TSS. For example JES2 does not even check access to a job
    (resclass JESSPOOL) when it determines, that the acting userid is "owner" of that job, if think, there is a similar behaviour for some db2 ressourceclasses and also datasets.
    And I guess, that is the reason, why datasets should be owned by a none-user-acid (department, division, ...), so that Top Secret is asked about permissions.


    (5) UNDERCUT has supposably a different meaning in RACF, which I did nor research; in Top Secret it is a suboption, when you establish ownership and you have undercut already existing ownerships. See                   

  • 24.  Re: interpreting TSS LIST outputs

    Posted 10-26-2018 02:38 PM

    Bob/Josef, thank you for taking the time to explain.   I am making progress, it is always interesting learning a new "language" such as TSS.  I have a couple more questions which I will mention on a new thread...regards

  • 25.  Re: interpreting TSS LIST outputs

    Posted 10-26-2018 03:38 PM

    you're welcome, ... and, be prepared ... to experience some surprises ...