Hi, Yes, you are wrong. You are still focusing on too small of a picture and missing the "greater view". My example used TCP/IP, VTAM and CICS as individual entities to make the concepts easier for people to comprehend, not to hide the fact that they are made up of TCBs.
First, for the past 10 years or so the SMP effect has been negated to the point that it is "almost" not worth figuring, especially for anything under 10 engines. Second, It's the overhead to constantly PC switch between the various TCB's that gives you all of the overhead, more engines = less TCB's need to be exchanged. The problem you are letting yourself in for is that you can't compare this properly with a single transaction, and you don't operate that way in the "real world" anyway, (do you:)). The "demanding application" point you made is well taken, as a concept only, and you have to be aware of what you need (at a minimum) for each of your engines so that you don't run into that problem. Very few large subsystems still operate in a single TCB environment. CICS has multiple kernels (has since CICS/ESA) and will take advantage of multiple engines (if they are available), if not, then you run into the problem that you outlined where you don't have enough vertical space to operate effectively, but you are actually causing that problem yourself by not having multiple engines available. So again, there is no benefit to a single engine for CICS, (DB2 also runs multiple TCB's and actually multiple address spaces, so you can see where multiple CP's would be a good thing). When we speak of the vertical space for a subsystem like CICS, we are talking about the amount of work that can be accomplished within a single CPU of the overall complex at a time. Obviously, you wouldn't want 16x10mip CPU's, when you can have 2x80mip or 4x40mip ones. If you have an application that can't fit into a single CPU to execute effectively, then it's time to look into another application, or re-write it to take advantage of subtasking, because you will ALWAYS be hitting your head against that "next" vertical CPU size bump unless you do. So do you see where I'm going with this? There just aren't any sites that should be running a "business" machine (as opposed to a scientific process) who will perform as well with a single CPU as they would with multiple CPUs of a comparable size. Especially not on the z/series processors, you have to understand how they are built and how the processors are "really" operating to understand why your points are invalid. I think, based on your comments, that you do have some idea of how the physical processors "really" operate and if you thought about that, you would see why multiple processors that are "capacity limited" to a certain speed will "ALWAYS" be better than a single one for "business applications". If all else fails, think of simple physics, (this is a simplistic, but basically accurate example, so don't get upset) you have a single chip capable of about 2 to 3 GHz, compared to 4 other chips operating at the same time (also in the 2 to 3 GHz range), but they are "limited" to a "capacity" of 1/4 of the single chip. Remember, we are talking SPEED not CAPACITY on a z/series processor complex, and as long as you don't exceed the capacity, you will have "effectively" 4 times the single CPU speed (4 simultaneous instructions). You have to look at how the z/series processors execute individual instructions to get a better view as well, do you think that a single processor z/series box can execute a BR(anch) instruction any faster than a 4 CPU one? Obviously not, they are basically the same physical CPU's that have been capacity limited. Unfortunately this example, while accurate, gets me down to even a smaller picture than I accused you of looking at, but I felt it was necessary to get the point accross. Do you see what I mean yet? Brian ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
