Summary:
Customer is limited in about 500MB of EDSA and is deployment a new SOA architecture with application size around 2MB each which gives only 250 transactions for CICS regions. Need to expand that
Detail:
The real problem here is the huge number of terminal users that are signed on. When transaction routing is being used a surrogate terminal is created in the AOR. The signon of the surrogate terminal done in the AOR is subject to USRDELAY. Even though there are very few unique userids the fact that this is a terminal being signed on means that the signons all contain an entry_port (netname). The presence of this entry_port makes all the signons unique, requiring their own entry in the CICS user domain and their own ACEE. This is why if you look at the state of the user domain in CICS you can see thousands of entries for userid SIGNATM. If the AOR only ran DPL's and function shipped requests instead of handling transaction routing then there would just be a single SIGNATM userid signed on in the AOR.
The simplest way to resolve the current storage problem is to reduce USRDELAY. A very rough check of some storage pages of the timeout queue from one of the dumps showed that around a third of the userids had not been used for 90 minutes. Just halving the current value would reduce the storage usage by around a third. Lowering USRDELAY even further would provide more storage relief. However, you must remember that USRDELAY is a trade off. You are using storage for the ACEE and associated control blocks to avoid the CPU overhead of a full RACF signon.
In order to reduce USRDELAY even further you would want to do some analysis of the average time between transactions for each signed on user. You want to achieve a balance where the most heavily used terminals never time out and where the CPU overhead (and possible RACF contention) for the less used ones is an acceptable tradeoff for the reduction in storage.
Even making the USRDELAY changes will not completely rule out the case where all 100,000 users have submitted transactions within the USRDELAY period.
A different approach could be to modify how work is routed to different AORs. You could route based on the terminal. This would limit the number of users signed on to a specific AOR, and so limit the amount of RACF storage being used. However, that may affect your overall workload balance if this split is not well chosen.
I discussed 64-bit ACEE's with development. There is no current plan to do this. While it is certainly something that could be done for CICS, it would have a big impact on other products that interact with CICS as ACEEs may be passed on interfaces and they would all have to change to work with a 64-bit address. It is worth raising an RFE for this so it can be looked into in the future.
An alternative to having the ACEEs in 64-bit storage would be to have 64-bit application storage. If the applications were able to be above the bar then there would no longer be a requirement to restrict them to 2M each. There would also no longer be any contention between EDSALIM and other 31-bit storage users such as RACF. This enhancement would seem to give much greater benefit to Bradesco. You should definitely raise an RFE for this.
This RFE is satisfied by CICS TS 5.4 which is generally available from today June 16th 2017.
For more information see the announcement letter https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&supplier=897&letternum=ENUS217-113
The SNPRESET system initialization parameter specifies whether preset userid terminals share a single access control environment element (ACEE) that is associated with the userid, or a unique ACEE for every terminal.
This RFE is satisfied by CICS TS 5.4 which was announced on May 16th 2017 with a planned general availability date of June 16th 2017.
For more information see the announcement letter https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&supplier=897&letternum=ENUS217-113
The SNPRESET system initialization parameter specifies whether preset userid terminals share a single access control environment element (ACEE) that is associated with the userid, or a unique ACEE for every terminal.
The title of this RFE should be changed to "Reduce ACEE storage" to describe the problem which is being looked at for this RFE.
This is something we would like to address in the current release of CICS under development.
Please note:
IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server
For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server
Luiz,
This is a candidate for a future release.
A possible solution would involve reusing ACEEs for all terminals from the same user.
This would only be suitable if terminal security was not required, something that would need to be specified as a global option.
Please let me know if this would be acceptable.
,
Luiz,
This requirement has been re-evaluated. Looking at current plans, it is not likely that this would be implemented in the next two CICS TS releases, so correspondingly this requirement is being rejected. You have an opportunity to resubmit in eighteen months time if you wish it to be considered then.
Luiz,
Thank you for your request.
There are various ways of addressing the ACEE problem which might provide a solution.
One possibility is to try and reduce the number of ACEEs by using a common ACEE for each userid, rather one for each port of entry.
This would only work if you do not make use of the port of entry in your RACF definitions.
Do you use conditional access processing using the terminal on console names?
If not then a solution could be to allow a system wide disablement of this function.
Although this problem and the 64 bit application storage are both storage problem, they are very different in their nature and potential solutions.
Could you raise another RFE for the 64 bit application storage problem so that our application experts can separately discuss this with you.