Session 3065 - DFSMS Optimizer Release 2: The All-New HSM Monitor/Tuner

SHARE 90
February 22-27, 1998


John Tyrrell is the original architect for DFSMS, TMM and now the DFSMS Optimizer. He came to discuss this add-on product for DFSMS, and the new features in it.

(I guess it's a sign of the new IBM, but he was wearing an outfit that I would probably use for yard work. Sigh... I kind of miss the days when we dressed for business.)

The HSM Monitor/Tuner is IBM's response to complaints that HSM is too big and hairy and complicated. It runs under MVS and monitors HSM events and provides automation for HSM operations. It contains offline statistical analysis and report generators that can tell you what HSM is spending its time doing.

The Optimizer eats and enjoys a number of logs and statistics sources. SMF record types (14, 15, 62 and 64), RMF volume statistics, Cache Reporter records and HSM logs are all summarized and merged into a specialized database. This database in turn can be queried and "What If?" types of questions can be asked. One example of the sort of query you can enter is "What would happen to I/O response time if I doubled the cache memory on this particular control unit?"

The "Analyzer" function produces a proprietary "chart file", which you can download to a desktop computer in the usual way, or you can . There a companion program interprets the file and produces a variety of charts and graphs. In the new release of the optimizer, the PC code is being rewritten in Java; his will mean that it can execute on lots of platforms, and not simply on an OS/2 machine.

Also in this new release IBM is dumping APPC! They are only supporting TCP/IP for communications with the host. What a Brave New World this is.

In the old version of this product, you needed to dedicate an OS/2 station to it. The "monitor" half ran under OS/2, and REXX programs that you wrote to handle the events also ran on that OS/2 station. Now the monitor runs as an MVS address space, and HSM events are communicated internally to the monitor. Of course, this means that you have to convert all those REXX handlers you wrote for the OS/2 platform to MVS REXX. Oh well...

Every time a workstation program tries to communicate with the monitor, a "communications address space" is created - sort of like what happens when a TSO user logs on.


Back to session index
Back to index of SHARE meetings
Read the disclaimer