Fred DelGaudio is Infocrossing's Senior Vice President for Product Development. He describes the company's large-scale Tivoli deployment as a multiphase process. "The first challenge was to get the products to work individually. The second challenge was to get them to work together. We wrote some code and some APIs, as well as database translation routines, to make them communicate with one another."

"We'll use distributed monitoring to instrument storage utilization of the server environment, which is pretty typical," says DelGaudio, acknowledging that some of Infocrossing's services are a basic feature of all ASP hosting companies. But he emphasizes that they don't stop there. "When utilization reaches a certain percentage, we'll throw out an alert. What distinguishes us is that we've built integration between the various Tivoli products. That alert goes into Tivoli Service Desk, so I don't need a person to open a trouble ticket. It's automatic. The third component that we've integrated is Tivoli Storage Manager, which can dynamically add storage to the user environment. If that whole process was successful, then that trouble ticket and alert can be automatically closed. If the process was unsuccessful, then it escalates from a yellow to a red [status]. Netview is also integrated into Infocap. If Netview notices a problem with one of the components on the network, it will turn the component red [on the console]."

Graham says that his company's enhancement of the Tivoli management products focuses on closing the feedback loop on resolved problems, not just automating the process of solving them one-by-one. The emphasis is on long-term, evolutionary productivity gains. "We've integrated it [Netview] with the Service Desk component so that a trouble ticket gets written as well. We script what gets written into the trouble ticket, so that if it is something that we've seen before and requires manual intervention, the operator sees the script of what to do. The command center folks are also responsible for maintaining the trouble ticketing script. If they followed the steps and it worked, they have nothing else to do. If they had to add a step, it's their responsibility to add that step to the trouble ticket script as well, so that the next time it will be included. They are part of a very large feedback loop."

Tom Laudati says Infocrossing had a number of solid business reasons for choosing Linux on System/390 over other platforms. Although they still support NT and UNIX as well as their legacy mainframe hosting clients, Laudati says that System/390 and Linux are their preferred platform for most new development. "There are some applications that aren't yet ported to Linux for S/390," he says, "so that would dictate where you would run. Linux for S/390 is certainly our preferred platform. It's much easier to administer and manage than the distributed hardware environments."

Ease of administration is mentioned often by early adopters of Linux for S/390, and in fact has been an argument made by traditional mainframe advocates for decades. Laudati says this was a key factor at Infocrossing as well, adding, "We can build a new Linux environment in about fifteen minutes." Laudati also mentioned the issue of reduced floor space, an expensive commodity in a secured raised-floor data center. Even IBM's largest zSeries mainframe is only about the size of a telephone booth, and large mass storage arrays are similarly sized regardless of the CPU type. Gone are the days of mainframe disks the size of clothes washers; modern mainframes use arrays of small-footprint drives not unlike those connected to high-end Intel or RISC servers. Modern CMOS processors have eliminated the need for large water cooling systems with thick hoses trailing under the floor tiles.

Linux for S/390 can run natively on the physical hardware, just as if the S/390 or zSeries were a big PC, or it can run in an LPAR (logical partition) which is basically an allocated set of CPU and memory resources. Linux can also run under IBM's powerful VM operating system, in which case VM manages anywhere from one Linux instance to several thousand such instances and each Linux instance "thinks" it has an entire multiprocessor machine to itself. Because the S/390 architecture includes specific hardware features for virtualizing the machine's resources, there is very little performance penalty (a fraction of a percent, usually) when running one operating system inside another. It is a capability similar to the "virtual 86" mode of Intel's 386 and newer processors, but it is much more sophisticated and (unlike Intel) the virtualization is at the full level of the newest processor generation, not just backward emulation of an older model.

Next: VM and Linux: Room to Grow, Best of Both Worlds »