Lockheed Martin Reduces Costs by Improving Critical Transaction Processing Performance
Industry: Technology
Location: Global
Headquartered in Bethesda, Maryland, Lockheed Martin (NYSE: LMT) is a global enterprise principally engaged in the research, design, development, manufacture and integration of advanced-technology systems, products and services. The corporation's core businesses are systems integration, space, aeronautics, and technology services. Lockheed Martin had 2001 sales of $24 billion.
The Challenge
The challenge facing Lockheed Martin was to reduce the total response time in tracking a processing application for interstate trucking. A trucker driving on several interstates logs his/her mileage, fuel data, and load weights. This logging involves the user getting on the Internet and accessing a Lockheed site that interfaces to an OAS server that converts the mainframe
3270 terminal screens into Web browser HTML format. Thus, making the mainframe
application available to the user on the Internet or intranet. The mainframe part
of the process is a legacy system, which processes data for the user utilizing CICS®
and DB2®.
Mirza Baig, Manager of Information Technology for Lockheed Martin Information Systems, wanted to probe more deeply into the transaction in order to determine where the bottleneck existed. The transaction on which the delays were experienced was a complicated one that included processing on the local machine, communications with the mainframe OS/390® host, CICS application transaction processing, a hand over to OS/390, and finally a DB2 database write. Determining which element or elements in this complicated mix was responsible for the delay was a very challenging problem.
The Solution
Baig recognized the need for a comprehensive tool to monitor CICS activity. He
evaluated several different alternatives and selected
ASG-TMON™ for CICS/ESA® because
he felt that this tool provided excellent insight into the behavior of large systems.
TMON for CICS/ESA simplifies and reduces problem resolution time by providing a drill-down approach to system and application tuning that includes system overviews, point-and-shoot zoom, and transaction-level reporting granularity. This saves time by making it possible to quickly scan a wide range of metrics, and then quickly zero in to get more detailed information when a problem is detected. The program’s powerful exception and alert processing also enhances productivity. The systems programmer establishes thresholds for metrics within the monitored CICS regions, which triggers advance warnings before problems become costly outages. He or she can also configure alert targets and define destinations to generate audible and visual alarms as problems occur, improving the staffs’ response time to problems. The program also interfaces to automated operations packages, leveraging existing investments.
"When I first started using the ASG software," Baig said, "it was like taking a course in how our systems were behaving. Where in the past I had to depend on my end-of-day stack and some SMS data to determine performance on a systems level, with TMON for CICS/ESA I can visualize the current status at any point in time. At the individual transaction level, it provides detailed information like how many times the transaction hit DB2 or Adabas and how many cycles were required. This kind of detailed information helped me quickly form a mental picture as to whether each section of the application is performing well or poorly. I can identify code that is in need of optimization in a matter of a few minutes, while in the past it might have taken weeks of investigation. Something as simple as observing that a transaction remains on the screen for a period of time can help to identify runaway code. The tool also provides a wide range of macro-level tools, such as CPU utilization, that help to determine whether coding changes were moving us in the right or wrong direction."
Measurable Results
The transportation system is a good example of how these insights can come together
to quickly solve real world problems. Baig quickly decided that the key to solving the
problem was splitting the transaction into the fractions of time that are being spent
in each environment. He used the DB2 exit of the monitor to determine the flow
characteristics of the application. On the mainframe side, TMON for CICS/ESA resolved
the transaction down to a high level of detail in its timing detail report. This report
indicated that database I/Os were clearly responsible for the majority of the time being
spent by the application.
"Once we had a clear picture of what was happening, solving the problem was fairly straightforward. We didn't have to waste any time in the areas that we now knew were performing well, we were able to zero right in on the DB2 calls,” said Baig. “First, I enlisted the assistance of a systems programmer to rewrite the DB2 calls to reduce the I/O; second, I checked the OS/390 workload manager and noticed that it had been configured to assign high priority to CICS. I adjusted these priorities to provide a bit more CPU to speed up the DB2 process. Once these steps were completed, the transaction time was reduced from 2 to 0.4 second, which made us heroes."
