The selection mechanism

Let's look at how the selection mechanism works. As we saw, the mechanism is used when CICS needs to know if an incoming request should wait for a more suitable JVM, or when CICS has a queue of requests that do not match a free JVM, and needs to know if one of them deserves to take, destroy and re-initialize the JVM. In these situations, the mechanism looks at the complete picture of the need for different types of JVM in the CICS region. It compares the demand for, and supply of, JVMs with each profile and execution key, by looking at: The selection mechanism uses this data to work out whether a given request should wait for a JVM of the correct profile and execution key, or whether it should be given a free JVM. The same answer is valid for a request that is waiting in a queue for a JVM to become free, or for a request that is made when there are free JVMs but they are not of the correct profile or execution key. In both cases, a request is made to wait if the data indicates that the demand for the type of JVM (that is, a JVM with that profile and execution key) which the request wants, is generally lower than the supply, and so it is not worth destroying and re-creating the free JVM as a JVM of that type. When the selection mechanism is examining a queue of requests, it continues down the queue until it reaches a request where the data indicates that the demand for the type of JVM that the request wants is generally higher than the supply. For this request, the selection mechanism decides that because JVMs of that type are needed in the CICS region, it is worth destroying and re-creating the free JVM as a JVM of that type, and assigns the free JVM to the request. If the free JVM had the wrong profile but the correct execution key, this is a mismatch, and the JVM is re-initialized. If the free JVM had the wrong execution key, this is a steal, and both the TCB and JVM are destroyed and re-created. So although the overhead of re-initializing the JVM, and if necessary re-creating the TCB, has still been incurred, the selection mechanism has ensured that the new JVM and TCB are of a type that is likely to be used in the future.

Under certain circumstances, there could be an unusually large number of requests for JVMs that have been waiting longer than the critical period. For example, this could happen when a system dump has just been taken, which delays all processing. In this case, rather than abandon matching and give each of the waiting requests the next available JVM, as would normally happen when a request has been waiting longer than the critical period, CICS temporarily increases the critical period value for the JVM pool. This enables it to perform matching for the waiting requests, and avoids incurring abnormal overhead. Once the situation has passed, CICS lowers the critical period value again.