Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Five Ways To Modernize Your Mainframes: Page 3 of 8

New hardware that achieves storage consolidation is still a big expense for many companies, but its costs are plummeting fast, and the return on investment has been shown to be exceptional. With storage-management software, a small investment in terms of operations cost can even more dramatically reduce crisis-containment costs and downtime, positively impacting the bottom line.

In many IT shops, there's a proliferation of disparate platforms, each with unique classes, manifestations, and eras of software that abound in a haphazard patchwork of functionality. Distributed applications from the '90s are transacting with mainframe database managers from the '80s that navigate through data schematics from the '70s. Then the tracking reports for lost records are examined on 21st century spreadsheets.
The need to manage and regulate all these varieties of incompatible data has led to the creation of what Ron Hankison, CEO of Xbridge Systems Inc., calls "sneaker nets": basically a nonautomated means of moving data from one format to another. Sneaker nets are real cost generators; they require time and human power and don't foster high-data quality.

Savvier companies, of course, rely on variations of the data warehouse, a centralized repository that extends views of a database to a readily accessible cache. What Xbridge offers as either an alternative or a complement to the data warehouse is a lower-cost, intermediate approach called a data mart. Rather than a single repository, a data mart provides compartmentalized subsets of data views that are translated and updated in real time but tailored to the specific needs of certain departments or classes of users. This pre-tailoring, Hankison says, eliminates the need for users to drill down through a massive data hierarchy to extract the views they need, while at the same time triggering updates and other transaction cycles manually.

The data mart can provide integrated views of related data from disparate sources, such as DB2, VSAM, QSAM, and IMS, not only as datasets of records but as relational entities. This way, a large company with data scattered not only across different applications but different countries can present a single, unified view of data to its users, without having to reproduce that data on the back end. With simpler hierarchies, the Xbridge data mart can expose tailored views by way of simpler, more-open channels developed for small systems, including XML, ADO, .Net Web services, and OLE DB. This makes a simpler rendering of mainframe data readily available, in a constantly updated and translated format, for much simpler front ends such as a browser-based application, a Microsoft Access application, or an Excel spreadsheet.

Establishing real-time access to mainframe data doesn't require a sophisticated three-tier architecture. In fact, a temporary solution to a company's short-term needs could be conceived ad hoc. This, plus the elimination of sneaker nets, results in savings that contribute directly to the administration and operations categories of TCO reduction.

Many companies' core business applications aren't commercial packages with version numbers, site licenses, and beta test cycles. Often, they're clusters of thousands of Cobol procedures, nested and nurtured in a 35-year-old garden of business rules, standard procedures, and decision-support principles. More modern permutations involve DB2 procedures, IBM Language Environment modules, and Java components--perhaps migrated there or built there from the ground up. In any event, the entire ecosystem of these little applications has always been the mainframe platform on which they were born.
For most of these applications' life cycles, there has probably existed in some tucked-away corner of the address space an application-performance monitor such as Compuware Corp.'s Strobe or Candle Corp.'s Omegamon. In 1976, during the early days of Candle, the purpose of performance monitors such as Omegamon was to optimize throughput during maximum workloads, enabling administrators to eek out as much from their active capacity as possible, says Pete Marshall, Candle's assistant VP. In the mid-1980s, that purpose changed to lowering users' response times to the green screens with which they were presented. The more active the user, and the less time his or her hands spent off the keyboard, the more productive the application.