On our production systems, we have several CICS regions running as functional separated regions. We don't have...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
a TOR, AOR, FOR structure (our management didn't want several application systems in the same environment). What would be the benefit of implementing a CICSPLEX? (In the first stage, we will not allow any application changes!)
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.
Dig Deeper on IBM system z and mainframe systems
Related Q&A from Robert Crawford
For better mainframe capacity planning, how do I convert CPU hours to MIPS? And is there a way to calculate the relationship between MIPS and MSUs?continue reading
I have two years of experience in mainframe technology, currently working as a mainframe developer. I want to change to Java technology.continue reading
I want to replicate DB2 from the mainframe to an AIX box since it's cheaper and the copy can be used for testing. Is this possible?continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.