This Content Component encountered an error
Problem solve Get help with specific problems with your technologies, process and projects.

What's the benefit of implementing a CICSPLEX?

On our production systems, we have several CICS regions running as functional separated regions. We don't have...

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.

This was last published in December 2002
This Content Component encountered an error

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.