A couple of years ago, while attending an intro to CICS TS session, I seem to recall that one had to be in a TOR/AOR configuration for their CICS/ESA v41 regions. Is this still a requirement for a migration from v4R1 to CICS TS v2.2?
I'm not sure that you got the right message from the dim-and-distant past....... It is absolutely the case that you do not HAVE to use a TOR/AOR configuration for CICS - you can quite happily run with everything in a single region (we do this most of the time in Developing CICS, and I guess you may well have your own coders who have their own CICS regions). HOWEVER, in most customer production configurations it is HIGHLY recommended that you you a TOR/AOR split - and I think the the great majority of CICS Customers are running with TORs/AORs. Indeed, with the way CICS is evolving, there will be many TOR-like regions around talking to loads of AORs (where the real work gets done). The best way to think of a TOR is a front-end router region for 3270-devices, routing interactive work into an AOR for processing. This allows lots of different TORs communicating to many back-ends AORs which do the work. In this way you get an high degree of protection against region abends as work can automatically be shifted from a failed AOR into an active one or the terminal can be connected to another TOR to replace a failed TOR (and a failing TOR is a fairly rare occurance if it's only processing 3270s). The main benefit of this split is that one can share out work between AORs and so get best performance for applications. If you are using CICS' Web Support, you may think it desireable(for security, performance, reliability reasons etc.) that a distinct region is used to cope with the HTTP/HTML/IP traffic so keeping this function away from the AORs which are really doing the work. Thus, you are into having a sort-of-TOR without 3270s but including TCP/IP to handle communications. A similar sort of thing applies to use of the CICS Transaction Gateway. Depending on where the line is drawn between external and internal, the CTG may communicate with a CICS region that does nothing else apart from route the request into an AOR Looking a bit further ahead in CICS TS 2.2, we now have Java facilities within CICS. Now, a JVM tends to take up more resource running a given set of activities than an equivalent COBOL/PL1/Assembler program would do. Therefore, some customers think it desireable to put all java-related work into AORs that do not have traditional application programs running as well. This means that the MVS Workload Manager can then control the oomph given to CICS' Java workload in a different fashion to that given to the traditional CICS regions. So, for Production work a TOR/AOR split is vital!
This was first published in September 2002