Ummmmm -- I'm somewhat surprised that your configuration has lasted so long. You definitely need to move to a situation where your CICS regions are split into functional areas.
It appears to me that you have a set of end users who know which CICS region their application resides, and then use a session manager or multiple TN3270 windows to go into the relevant place. Alternatively, maybe you are duplicating things for capacity/performance reasons.
If this is the case, then 1st thing I'd do is split these unique regions into a TOR-AOR arrangement. I know this will effectively double the number of CICS regions you have active -- but this should only be an intermediate solution. In these TORs, you just have all the user transactions statically defined as remote to the existing regions. In effect, you are adding MRO support to these existing regions and removing all terminal related activity. You end up with CICSTOR1 -> CICSAOR1 & CICSTOR2->CICSAOR2. Any security concerns related to sharing are not relevant - you are merely separating function.
The next step will be to get rid of the session hopping for the end users. If you can arrange things so that the transactions in run in your existing AOR are not duplicated (so XXXX always runs in CICSA and XXYY always runs in CICSB) then you can start to get rid to of all these additional TORS, and simply get the users talking to one TOR ( you might want to duplicate these TORs for reliability purposes). Thus CICSTOR1 -> CICSAOR1 & CICSAOR2 depending upon the transaction id.
I don't think you will have any transaction affinities to worry about, so the existing applications should be unchanged. I say this because if your existing applications are doing XC STARTs, these will run in the same region. Thus there seems not to be any possibility of a transaction being required to run in a different AOR. Security sharing should still not be relevant -- the transactions are still only doing their own accesses.
Now, you can start to do more interesting things like load balencing and hot backup -- all of which will de done in the TORs, so the applications should still be unaltered.
Once all that's working, then you may want to consider implementing some FORs -- but probably not in your environment due to the tied nature of your existing setup. Additionally, there should be scope to reduce the number of these AORs as spare capacity can be more easily used.
You might also want to give some consideration about driving these existing
applications through the Web interface or using EJBs or other such
technologies. The roadmap I've suggested gives you a good platform to
embark on these voyages.
This was first published in December 2002