Make CICS WEB interface threadsafe and optimize throughput and response time in CICS and maybe save a little CPU

IBM has an undocumented fix to the CICS WEB interface that can optimize throughput and response time plus maybe save a little CPU.
The fix is very simple, as it is just a change of the definitions of three WEB interface modules which get added the parameter CONCURRENCY(REQUIRED):

DFHWBA - then main module of the alias transaction
DFHWBBLI - the Business Logic Interface module of the alias transaction 
DFHWBXN - this listener module  

The IDEA is to make a fix for the current release of CICS and make new definitions for future releases of CICS, by making two different RDO definitions for the three modules shown above, so that each installations can choose the definition that suits them:

a. one RDO definition for installations with threadsafe programs and data stored in DB2 or DL/I - with CONCURRENCY(REQUIRED) parameter
b. one RDO definition for installations with non-threadsafe programs and / or data stored in VSAM files - without CONCURRENCY parameter

The experiences with CONCURRENCY(REQUIRED) for the three mentioned modules in a CICS WEB intensive installation running z15 8561-620, z/OS 3.1, CICS TS 6.1 and DB2 version 13.1.0 and all applications coded as threadsafe COBOL programs are the following

1. One extra TCB-change (Change Mode) on listener transaction at initial LINK to DFHWBXN – slightly more CPU-usage
2. No extra TCB-change on alias/business transaction as one added at initial LINK to DFHWBA and one saved later – same CPU-usage
3. Average response time of WEB-transactions in average for all CICS’s – 10 percent lower than ever measured
4. Load of single threaded QR-TCB reduced by more than 30 percent
5. Busy time of single threaded QR-process in most busy CICS in peak period almost reduced by half
6. SMF-113 shows 6 percent less CPU-cycles per instruction in peak hour - CPU-saving     
7. Expect to be able to handle up to twice as many transactions in a single CICS region as before