IMS’s HALDBA

The Virtual IMS user group at www.fundi.com/virtualims has a regular virtual meetings every other month. In fact, the next one is on 9 October at 10:30 Central Daylight Time. Our guest speaker is Aurora Emanuela Dell'Anno, a Senior Engineering Services Architect with CA Technology, and she will be talking about “IMS performance – taming the beast”. It will be well worth attending – and being a virtual meeting, there’s no need to leave your desk. See the Web site for more details.

Back in February, Neil Price, a Senior DBA and Systems Programmer with TNT Express ICS gave an excellent presentation entitled, “Memoirs of a HALDBA”. Neil first encountered IBM mainframes as a student in 1971 and more recently he has been Chairman of the GSE UK IMS Working Group.

Neil started his presentation by giving the user group a clear idea of what hardware and software TNT Express use. This is relevant because it affects the decisions that Neil and his organization had to make. They have two machines – one hosting the main production LPAR; and the other running the network, testing, and one or two other things. This has a total disk capacity of about 18TB, of which just over 4TB are mirrored to their Disaster Recovery site, about 100 miles away in London.

Neil informed us that they always used OSAM because they believe it’s more efficient. More recently, of course, it gave them the ability to have datasets up to 8GB in size. Very few of their databases ever get disorganized enough to need a reorg unless they’re running out of space. The use of HDAM for all of the most volatile databases is a major factor in this. A few are reorganised weekly, 3 of them in order to remove logically-deleted data with a user exit, and a few quarterly.

In terms of HALDB, Neil told us that since they started investigating and testing HALDB in 2004, they’ve converted 18 HDAM databases, which were getting close to the 8GB OSAM dataset size limit, including the whole of the CCDB (Central Consignment Data Base, consisting of 15 HALDBs of 6 partitions each) and one with an index that was threatening to hit 4GB between weekly reorgs. Just 2 of their HALDBs are partitioned by key range. Most of the HALDBs got up to 16 partitions on model-3 logical volumes over time, but went down to 6 partitions when they moved them to model-9s. Apart from Consignment, each HALDB has at least one index. 5 have 28 indexes between them, and 13 of the indexes are also partitioned.

Neil was pleased to have avoided certain challenges at his site. For example, the DBRC question – they decided to have DBRC forced registration in every system from the very beginning, and, because there’s virtually no DL/I batch, there’s just one copy of each database and it’s permanently online. It didn’t take much thinking to decide that their 14 cloned databases would stay separate when they became HALDBs. Anything else would have involved major application code changes. The databases using a partitioning exit all use the Consignment key, so they’ve effectively had to write only one simple exit routine. They still maintain separate modules, though, just in case they need to vary the logic at any time.

To simplify everything they treat the HALDBs just the same as before except in very exceptional circumstances and haven’t changed their names. In particular, not taking individual partitions offline means that the applications don’t need to handle partitions being unavailable.

In terms of challenges they faced, Neil said that the first database they converted was one using the Consignment key, and it was fairly obvious that they wouldn’t get a predictable spread of data using key ranges. In the end they adapted the example in the IBM Redbook “The Complete IMS HALDB Guide” (SG24-6945) to select a partition based on a portion of the key, in their case the trailing characters of the 9-digit character numeric Consignment number. With equally-spaced “limits”, this has resulted in a very even spread of data across the partitions. They started with 2 digits, but once they went from 10 to 12 and then 16 partitions it seemed sensible to start using 3 digits for a slightly more even spread. Of course the overall physical sequence of records isn’t the same as in HDAM. For databases with key-range partitioning, they used the HALDB Migration Aid utility DFSMAID0 to choose the limits.

When it comes to monitoring challenges, Neil told the group that for non-HALDBs they get a list by e-mail of any thresholds that have been exceeded, for example the number of database records or the number of HDAM roots not stored in their “home” block. This is sent by a simple SAS program that processes a daily report of all metrics and threshold exceptions from their Pointer Checker statistics repository. The statistics are gathered as part of the daily online Image Copy backups. They find the e-mail preferable to having to navigate ISPF panels or a GUI to find out what exceptions have occurred, if any.

HALDB statistics, on the other hand, are written to a completely different repository, which can be viewed through a GUI but didn’t come with facilities to generate reports or e-mails. So they segregated the HALDBs into their own backup jobs, which direct the Pointer Checker report to a file. An additional SAS step then processes the file, writes the results to a SAS database and a summary report, and generates an e-mail if the percentage of usable free space in any partition falls below a hard-coded threshold.

Find out more about Neil Price’s experience next week.