DB2 - L

 View Only
  • 1.  Protected entry threads

    Posted 11 days ago

     Good morning everyone,

    I have a question, I notice that we do not have 'protected threads' active in CICS for connecting to DB2;


    Protected entry threads

    Protected entry threads are defined with the following DB2ENTRY parameters: PROTECTNUM and THREADLIMIT
    Protected entry threads are recommended for:
    • High-volume transactions of any type
    • Terminal-oriented transactions with many commits
    • Non-terminal-oriented transactions with many commits (if NONTERMREL=YES is specified in the DB2CONN)
    Protected entry threads are created, used, and terminated as follows:
    TCB attach
    When CICS is connected to DB2, and is using the open transaction environment, a new or existing open TCB is allocated to the CICS task before calling the CICS DB2 attachment facility. If the limit set automatically by CICS for the number of L8 and L9 mode open TCBs is reached, no more open TCBs can be created, and the task enters a CICS dispatcher wait until an open TCB is available. At the end of the task, the open TCB is returned to the pool of open TCBs managed by the CICS dispatcher.
    Thread creation
    A thread is created only if an existing thread is not available. If no thread is available for a task, a new thread is created and related to the task's open TCB, provided THREADLIMIT is not exceeded. If TCBLIMIT is reached, no more open TCBs can be used as thread TCBs for the DB2ENTRY.
    Thread termination
    If the current number of protected threads is less than the PROTECTNUM value when the thread is released and there is no new work queued, the thread is marked as protected. Otherwise it is terminated. A protected thread is terminated if it is unused for two consecutive purge cycles.
    Thread reuse
    Other transactions using the same DB2ENTRY may reuse a thread, if it is available. This is likely because the threads remain active for about 45 seconds after being released, depending on the PURGECYCLE value.
    Overflow to pool
    If THREADWAIT=POOL is specified, requests for threads are transferred to the pool when the value of THREADLIMIT is exceeded. When a transaction overflows to the pool, the transaction is now controlled by the PRIORITY, THREADLIMIT, and THREADWAIT attributes that are specified for pool threads in the DB2CONN definition, and those attributes in the DB2ENTRY definition are ignored. The remaining attributes that are specified in the DB2ENTRY definition for the entry thread still apply to the transaction, that is, ACCOUNTREC, AUTHID or AUTHTYPE, DROLLBACK, and PLAN or PLANEXITNAME. The PROTECTNUM attribute in the DB2ENTRY definition is no longer relevant for a transaction that overflows to the pool, so this setting is ignored.

    This, I understand, has advantages on performace and since the conn is left open in a cics buffer

    I found the following link, a bit dated, with some considerations, what do you think?



    While in the following they deactivate the protected threads for the post-tp phase to avoid problems during lock commands for loads.



    I honestly find both pros such as cpu savings and cons for storage stress cases.


    Kindly share your experiences with me?


    Thank you


    Best regards






    ThomasGallioRaiffeisen Information Service KonsGmbH

  • 2.  RE: Protected entry threads

    Posted 11 days ago
    Hi Thomas,
    This is probably a better discussion for the CICS List, but at my site the impact is about 20% cpu savings. We came up with that number after the DBA's ran some standard REORGs, which has the remove Protected threads as the first step, and then got an error and didn't run the re-activate of the Protected threads, and before we realised, we started seeing alerts for Production CICS regions using 20%+ more cpu than normal. The re-activate is now scheduled to always run.

    We only have a small percent of COBOL code that is Threadsafe, so that probably affects the cpu impact.

    I prefer to have CICS Transactions run in specific Transaction DB2Entry pools and not the Default POOL so I check the CICS Stats report occasionally to see if any transactions are using POOL thread and determine if a DB2ENTRY is warranted.

    As per usual, your site may have different results and needs.

    Regards, Tony

  • 3.  RE: Protected entry threads

    Posted 10 days ago
    Our cpu savings due to cics protected threads weren't as high as Tony's but there is some benefit. You definitely will need to disable thread protection at times; thread protection causes issues with batch jobs and locking.  We have a cobol program that will generically set all thread protection to zero and execute that program via batch every evening prior to nightly batch processing. We have another cobol program that resets the thread protection and execute that program via batch each morning before business hours. So cics thread protection is disabled overnight.
    On the other hand, we also have high performance dbats defined which are similar to cics protected threads but are used for dynamic threads. That gave us a much higher cpu savings. We do not disable the high performance dbats during batch processing and rarely have any locking issues due to the high performance dbats.

    RussellPetersCentral Technology Services