Top Secret

Expand all | Collapse all

Why are there cat-1 and -2 transactions in our CICS BYPLIST?

  • 1.  Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Dec 20, 2017 05:35 PM

    In my previous question, Joe Porto turned me on to the existence of the BYPLIST in TSS, a list of transactions defined in a CICS facility that are to be allowed without consulting TSS.  Thanks to Joe and to Josef Thaler for pointing me to this.


    Now I've examined the sample listing in the TSS manual, and I see that it includes many CICS-supplied transactions that IBM defines as category 1 or category 2.  If I were to believe the documentation I should immediately remove those transactions.  I'd rather check, though.  Can anyone explain why these transactions are in the bypass list?




    The cat-2 transactions included in the r15 manual's sample BYPLIST are CDBT CECS CEHP CEHS CEPT CKAM CKTI CPIH CPIL CPIQ CPMI CRTE CSGM CSHR CSM1 CSM2 CSM3 CSM5 CSMI CVMI.  These transactions, also according to IBM, are powerful transactions for the use of some users but not all.


    As I understand the TSS CICS BYPLIST, it's to bypass security checking for the named transactions.  Should I not remove from it all of the above?

  • 2.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Broadcom Employee
    Posted Dec 21, 2017 04:05 PM



    The requirement to have them on the bypass list is not a TSS requirement but an IBM. Need to find the where this is  documented in the IBM doc and get back to you.


    These transactions are used by CICS and not users at terminals. If you look at the link in your post, it states that. It also says that unpredictable results can occur if users attempt to use those transactions.




    Joseph Porto - CA Level 1 Support

  • 3.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Dec 21, 2017 04:19 PM

    Interesting.  I'm aware of the IBM documents I linked to above (you saw those links, right?), but they contradict putting cat-1 and cat-2 transactions in a bypass list.  If IBM says otherwise in other documents, and you can find those other documents, I have a question to bring to the IBM documentation team.  They're a lot slower to respond than your guys :-), but they do usually respond eventually.


    (You say "These transactions are used by CICS and not users at terminals", but don't mix them up:  I spoke of both category 1 and 2 above, and it's the cat-1 transactions that are for CICS usage only.  The cat-2 transactions are for users, according to IBM.)

  • 4.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Broadcom Employee
    Posted Dec 21, 2017 04:47 PM



    I vaguely remember looking into this question once an long time ago. Its not a question we get too often.


    I did a quick search and didn't come up with anything. Need to dig deeper. Will let you know once I find something.




    Joseph Porto - CA Level 1 Support

  • 5.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?
    Best Answer

    Broadcom Employee
    Posted Dec 21, 2017 06:03 PM



    Spoke with Bob Boerum who has looked into the catergory 1, 2 and 3 transactions on the bypass list and referred me to the following guidelines for them.


    Here are guidelines regarding category 1, 2, and 3 transactions in CICS.

    (TSS does not have a say into what category a CICS transaction is         
    Category 1 transactions are system transactions that should never                       
    be initiated from a terminal. If a Category 1 transaction               
    is associated with a terminal, it will fail with an AEY7 abend.         
    These transactions seem to only be used by the CICS region acid and     
    DFLTUSER. TSS is distributed with the Category 1 transactions in the    
    bypass list. Since an AEY7 abend occurs if these transactions are       
    associated with a terminal, users won't be able to execute them.        
    If these transactions are removed from the bypass list, they should     
    be permitted to the CICS region acid and DFLTUSER.                      
    Category 2 transactions are system transactions that CAN be initiated   
    from a terminal. These transactions are not in the bypass list          
    and can be protected at the site's discretion.                          
    Category 3 transactions are either initiated by the terminal user or    
    associated with a terminal. All CICS terminal users, whether they are   
    signed on or not, require access to transactions in this category.      
    For this reason, category 3 transactions are exempt from any security   
    check, and CICS permits any terminal user to initiate these             

    For category 3 transactions, sites are recommended to specify                    
    RESSEC(NO) and CMDSEC(NO) on the CICS transactions resource definition.          
    These transactions should be defined to RACF, but this definition does           
    not affect actual task attach-time processing. It is used only for               
    QUERY SECURITY purposes.                                                         
    Here is a list of the category 1 transactions from IBM's website:                
    The transactions that have operator interfaces are marked by an asterisk (*).    
    The remainder therefore have no operator interface.                              
    Transaction   Description                                                        
    -----------   -----------                                                                                     
    CATA          Defines autoinstall automatic terminal                            
    CATD          Deletes autoinstall terminal                                      
    CDBD          DBCTL disable function                                            
    CDBF          CICS DB2  attachment facility shutdown force transaction          
    CDBO          DBCTL control function                                            
    CDBQ          CICS DB2 attachment facility shutdown quiesce transaction         
    CDTS          Provides remote single delete transaction                         
    CEPD          Event processing dispatcher                                       
    CEPF          Event processing deferred filtering task                          
    CEPM          Event processing queue manager                                    
    CESC*         Processes timeout and signoff for idle terminals                  
    CEX2          CICS DB2 protected thread purge mechanism and other CICS DB2      
    CFCL          CFDT load                                                         
    CFOR          RLS offsite recovery                                              
    CFQR          RLS quiesce receive                                               
    CFQS          RLS quiesce send                                                  
    CFTL          Shared DT load                                                      
    CFTS          Provides remote mass flag transaction                                      
    CGRP          Provides z/OS Communications Server (previously called VTAM )              
                  persistent sessions                                                        
    CIS4          IPIC External Security Interface (ESI) transaction                         
    CISB          IPIC release IPCONN on the server side of a connection (BIS                
    CISD          IPIC release IPCONN on the client side of a connection                     
    CISE          IPIC error and message program                                             
    CISM          IPIC remote scheduler                                                      
    CISP          IPIC connection heartbeat control transaction                              
    CISQ          IPIC local queue processing                                                
    CISR          IPIC request/response receiver                                             
    CISS          IPIC acquire IPCONN on the server side of a connection                     
    CIST          IPIC terminate IPCONN                                                      
    CISU          IPIC recovery transaction                                                  
    CISX          IPCONN recovery and resynchronization transaction for XA                   
    CIS1          IPIC connection heartbeat requester transaction               
    CITS          Provides remote autoinstall transaction                       
    CJSL          JVM server listener (autoinstalled by CICS)                   
    CJSR          CICS JVM server resolution transaction                        
    CJTR          Object Transaction Services (OTS) resynchronization transaction
    CMTS          Remote mass delete transaction                                
    COVR          Provides open z/OS Communications Server retry transaction    
    CPIR          Pipeline resolution transaction                               
    CPIS          WS-AT transaction that is attached when resynchronization is  
    CPLT          Initializes PLT processing                                    
    CRLR          Bundle resource resolution transaction                        
    CRMD          Provides remote mass delete transaction                       
    CRMF          Provides remote mass flag transaction                         
    CRSQ          Remote schedule purging (ISC)                                 
    CRST          Region Status long running task                               
    CRSY          Resource manager resynchronization                            
    CRTP          Persistent sessions restart timer transaction                 
    CSFR          RLS cleanup                 
    CSFR          RLS cleanup                                                   
    CSFU          File open utility                                             
    CSHA          Scheduler services (autoinstalled by CICS)                    
    CSHQ          Scheduler services domain long running task                   
    CSKP          Writes system log activity keypoint                           
    CSNC          Interregion control program (MRO)                             
    CSNE          Provides z/OS Communications Server (previously called VTAM)  
                  node error recovery                                           
    CSOL          TCP/IP listener (autoinstalled by CICS)                       
    CSPQ          Terminal page cleanup (BMS)                                   
    CSQC          CICS quiesce after system log failure                         
    CSSY          Provides entry point attach                                   
    CSTE          Processes terminal abnormal conditions                        
    CSTP          Provides terminal control transaction                         
    CSZI          Front End Programming Interface (FEPI), only active if FEPI   
    CTSD          Temporary storage delete recoverable queue                    
    CWBG          CICS web support cleanup transaction                          
    CWXN          CICS Web support attach transaction       
    CWXU          CICS Web support USER protocol attach transaction              
    CXCU          Performs XRF tracing catchup                                   
    CXRE          Reconnects terminals following XRF takeover                    
    The signon and signoff transactions are CESN and CESF. (CSSN and CSSF        
    are signon and signoff transactions for the old CICS releases but remain     
    in the default bypass list.)      


    Please let us know  if there are any questions.




    Joseph Porto - CA Level 1 Support


  • 6.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Dec 22, 2017 10:28 AM

    Right, the information you provide above is found at the IBM links that I cited in my first post.  They list each CICS-supplied transaction, group each into one of three categories, and describe each category.


    ...Which brings me back to my original question:  There are many cat-1 and cat-2 transactions in the standard CICS BYPLIST as described in the TSS manuals.  But given that IBM says cat-2 transactions are to be handed out to users only carefully, and cat-1 never, why would any of them be in the BYPLIST?  Should I not remove them at my installation, and shouldn't CA remove them from TSS as shipped?  Joe, you said "The requirement to have them on the bypass list is not a TSS requirement but an IBM", but where is that documented?  The IBM web pages you and I are both looking at say the opposite.

  • 7.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Dec 23, 2017 07:04 AM

    I think too, that the provided bypass list could be reworked, at least could be reviewed and confirmed, that it is up to date! 

  • 8.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Dec 27, 2017 11:36 AM



    One additional note to add to Joe's comment. In TSS R16 one can specify on the facility matrix entry for CICS BYPLIST(NO). This will disable the TSS BYPLIST. Remember if you specify BYPLIST(NO) one must authority these transactions and resources  that are needed.  Inorder to help one remove the byplist one can set the BYPLIST facility option to AUDIT.


    This option will allow one to still use the BYPLIST and see which ACIDs are using the transactions and resources. Then one can permit the ACIDs the transactions or resources and set the BYPLIST(NO).


    When one reviews the TSSUTIL report when specifying AUDIT. One will see a '+' sign in front of the transaction or resource that need to be permitted to the ACID.


    Sample entry from the TSSUTIL:

    12/27/17 11:15:49 XE58 CICSDEF CTS520T CICSPROD FAIL DFHGMM OK+A LCF S880029




    Brian Luger TSS SE Level Two  

  • 9.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Dec 29, 2017 03:20 PM

    Ah, I didn't know that.  Thanks, Brian.  The client I'm thinking about just now is using r15, but I don't plan to disable the BYPLIST in any case.  What I may find useful is this AUDIT feature; it'll help me figure out whether any of the cat-1 and -2 transactions that I envision removing from the bypass list (because I think they never belonged there in the first place) are being used.

  • 10.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Feb 02, 2018 04:45 PM

    I'd like to emphasize, that BYPLIST(AUDIT) activates audit only for TRANIDs in the BYPLIST. This was clearified in a CA support case by that time. Bypasses caused by TRAN(S) or probably other entries of the bypass list do not result in an audit record. 

  • 11.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Jan 03, 2018 11:13 AM

    In the context of this question, I'd like to ask:


    What is the advantage of a byplist over security-admin by the *ALL*-record?

  • 12.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Jan 03, 2018 11:23 AM



    The bypass list  has a shorter path length, then using the *ALL* record. One does not need to issue security call

    if the transaction is in the TRANID bypass list. 

  • 13.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Jan 03, 2018 07:05 PM

    Many thanks, Brian for your indication!

    Are the savings of cpu cycles when using the bypass list still relevant? Or, in other words: how many k instructions can be saved per „avoided“ security call?

  • 14.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Feb 02, 2018 05:15 PM

    Are there same points of reference about the pathlength of a BYPLIST-bypass and the pathlength of a regular security call? Or how to determine it on site? 

  • 15.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Jan 03, 2018 02:17 PM

    Josef (and maybe Brian too), you may be missing something more fundamental, here.  Both the BYPLIST and the ALL record have the effect of permitting all users to use a transaction.  But what I'm proposing is not that I should move some transactions from the BYPLIST to the ALL record, but that I should remove access to them entirely.  According to IBM's documentation, many of the transactions listed in the standard bypass list ought not be permitted to any user—and many others should be permitted to only a few.  The bypass list, as far as I can see, contains many, many transactions that should not be there at all.

  • 16.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Jan 03, 2018 07:28 PM

    Many thanks Bob for your statement. I see what you mean! There is a kind of „price“ to be payed, when you continue to use the bypass list versus conventional security administration.


    And that’s why I’m asking for the gain of using the bypass list.


    Of course just to move the bypass trans to the all record would not yet result in a proper security admin, which has to be according to the cics categories and to the policies of the installation.

  • 17.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Jan 04, 2018 03:22 PM

    Josef, I may have misunderstood you but I think I haven't made myself clear yet.  I'm not planning to move any transactions from the BYPLIST to the ALL record; I agree with you and Brian that it would slow the system down without providing much benefit.


    My complaint here is that almost 100 of the transactions in the BYPLIST shouldn't be allowed to users at all; they're in the standard BYLIST by error, and should be removed.  Well, about 75 shouldn't be allowed to users; another 20 or so should be permitted only to selected users.

  • 18.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Jan 07, 2018 03:21 PM


    I really would like to learn the benefit (in pathlength - cpu) of the bypass-list compared to "regular" security-admin, because I perceive the bypass list as somehow "disturbing" proper security. (Effective permissions do not appear as such in the security set of a user, TSSSIM ?, Audit ?, SECPRFX-compliant ? etc. ...)


    In either case the BYPLIST should be reworked, if the performance impact is not that relevant could be renounced.


    btw.: Do you know the CICS SIT parameter SECPRFX ? In my understanding it could make security-admin clearer, easier and more flexible ...


    Kind regards,


  • 19.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Jan 12, 2018 08:40 PM

    In that case—not conflating it with my question about the actual contents of the BYPLIST—I would have to assume it's more efficient than normal OTRAN permissions in TSS because it bypasses the normal TSS algorithm.  I gather than if transaction ABCD is in the BYPLIST, then when a user invokes ABCD, CICS won't even ask TSS about it, it'll just allow the access.


    This can be good or bad.  If you really want anyone to be able to run a transaction, no matter what ID he used to log on or even if he's not logged on at all, then it seems to me the BYPLIST is the place for it.  Off-hand that might be a transaction that displays the time of day, or your company's current price on the NYSE.  (At least, it is right up until some ill-natured person uses such transactions to launch a DoS attack, slowing your system with lots of such invocations.)


    You wouldn't want to use it for very many transactions, in my opinion.


    You mention "the CICS SIT parameter SECPRFX", but I'm a RACF/ACF2/TSS jock; I've sort of looked at CICS parms, a little, but I'm not familiar with any of them.

  • 20.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Feb 02, 2018 05:11 PM

    SECPRFX is a CICS SIT (system initialization table) parameter-option. By definition it prefixes the CICS-Region-Id or a site specified string (could correspond to "facility") to the resnames being checked in security calls done by/within CICS.


    I have to take note from a clearifying support case, that top secret does not support this CICS option, resp. neutralizes the effect of this CICS-parameter-option. I'm awaiting a technote about this with some explanations and reasons.


    Resnames with such prefixes would offer a single-system-scope of CICS-ressources and could be used advantageously by powerful and standard features like best-match-algorithm, masking, auditing and so on.

  • 21.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Apr 04, 2018 10:42 AM

    Dealing with SECPRFX I had to take note, that Top Secret nullifies the SECPRFX


    This has also been cleared in a support case.

    As a result of this support case a technote was written. 


    Because I consider SECPRFX as a real enhancement for CICS security-administration, I submitted


    You might want to share your opinion there.

  • 22.  RE: Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Broadcom Employee
    Posted Dec 21, 2021 04:20 PM

    Looked further into your question with Level 2.

    Top Secret currently supports multiple release of CICS. Throughout the years, IBM keeps changes what transactions should be bypassed and protected. Since Top Secret supports multiple CICS releases, we tried to construct a bypass list for all of the releases. In a perfect world, everyone would be running on the latest z/OS release and CICS, but reality we have to support multiple releases of z/OS and CICS. Fortunately, the bypass list can be modified to meet security requirements.

    Please submit an enhancement request that multiple bypass lists be supported depending on the CICS release, so it can be considered by the community and Broadcom for a future release of TSS.

    Joseph Porto - Broadcom Level 1 Support

  • 23.  RE: Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Dec 21, 2021 06:38 PM
    Wow, that was a while ago! Thanks, Joseph.

    Let's see, four years ago I was probably at Comerica Bank on their big RBAC project. I'm working on audit issues for an insurance company now, and I haven't looked at the BYPLIST in a couple years, but unless I've forgotten something important here's what I think I know:

    IBM divides the IBM-supplied transactions into three categories (see

    Cat-1 transactions are never to be used by end users; they're to be called only by CICS itself. These should never by on the BYPLIST. Or I guess they could be on the BYPLIST set to prevent access, rather than allow it; that can be done, right?

    Cat-2 are extra powerful and generally should be restricted to specific users, such as the CICS systems programmer. It's up to the individual installation, of course; some of them want all CICS developers to have additional power, at least in the non-prod LPARs. But the BYPLIST is exactly the place they probably shouldn't be, since then any permissions written to restrict access to (for example) CEMT will be ignored.

    Cat-3 transactions are always available to all users. These transactions DO NOT ASK the security product before executing -- they just do what they do -- so no installation rule against access to them will be honored or even noticed, and any of them in the BYPLIST is simply a waste of space.

    If the BYPLIST were set up to restrict some access, then I think I could see some sense to your explanation: It would be cutting off access to sensitive transactions for more than one release of CICS. (It still wouldn’t be smart -- it would prevent admins from allowing access even to powerful users.) But since the default BYPLIST bypasses the permissions and ~allows~ access, this explanation doesn't make sense to me: Broadcom is including transactions as they change from one implementation to the next, sure, but they're mostly transactions that should ~not~ be universally permitted. It feels more like whoever set up the default BYPLIST, back in the dim mists of time, misunderstood the purpose and put in exactly the wrong ones.

    What TSS needs is not that the BYPLIST be examined and split up (so to speak) among different CICS versions, but that it be scrapped entirely and repopulated from the beginning.

    Bob Bridges,, cell 336 382-7313

    /* Miss Manners has also observed that when children are truly allowed to express their preferences, uninfluenced by the dreary adult expectation that they must all be artistic and original little noble savages, they come out resoundingly in favor of rigid traditionalism. The devotion to ritual exhibited by the average toddler in regard to his bedtime routine would make a nineteenth-century English butler look like a free spirit. -from "Miss Manners' Guide to Rearing Perfect Children" by Judith Martin */

  • 24.  RE: Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Broadcom Employee
    Posted Dec 22, 2021 11:06 AM
    Another client asked a similar question while doing our search for an answer, we came across your post. 

    So, when I got my answer from Level 2 for our other client, I also though it would be a good idea to share it in communities just in case someone else had a similar question and it will pop up in searches like it did for us.

    Written 20-30 years ago the TSS CICS bypass list hasnt changed much. Having multiple bypass list based on CICS release is a great idea and would recommend submitting it as an idea on Ideation so it can be considered and voted upon by the community and Broadcom for a future enhancement in Top Secret.

    Have a great holiday and Happy 2022!!!

    Joseph Porto - Broadcom Level 1 Support

  • 25.  Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?

    Posted Jan 17, 2018 11:50 AM

    Many thanks to those of you who replied to my questions.  For anyone still interested, I just had a phone call with two CA guys who answered my questions definitively — and, I hope and believe, accurately :-) — and I thought I'd pass along what I learned:


    1) All category-1 transactions, as defined by IBM, must not be invoked from a terminal.  (CICS gurus among you should forgive my inexact terminology.)  I gather CICS calls TSS about some of these cat-1 transactions; others it does not.  All 70 cat-1 transactions are in the TSS BYPLIST.  But: Each transaction in the BYPLIST is accompanied by an internal flag that we as TSS admins cannot see; it indicates whether the transaction can be invoked from a terminal.  All the cat-1 transactions that trigger a call to TSS have that flag set to forbid connection by a terminal.  So (according to the CA guru who called me this morning) even though the BYPLIST appears to allow users to call CFCL, for example, an invisible flag would cause the code to check whether the caller is attached to a terminal and then respond to CICS "not allowed".  So for my part, I intend to leave all the cat-1 transactions in the list.


    2) Category-2 transactions should be handed out to humans on a restricted basis.  Some are appropriate for the systems programmers who support CICS, some for applications developers, and so on, but none of them are for just anyone.  The two CA guys, when we started looking at the 20 cat-2 transactions in the BYPLIST, seemed surprised and puzzled; I expect they're currently writing notes for a change.  But meanwhile they assure me that I can remove them from the BYPLIST in favor of more explicit TSS rules, which is what I intend to do.