net.digest

Net.digest summarizes significant discussions on the HP 3000-L Internet mailing list and is edited by longtime HP 3000 columnist John Burke who provides commentary on HP 3000 issues. Advice is provided on a best effort, Good Samaritan basis. Test these concepts for yourself before applying them on your systems.

Analysis by John Burke

Gee, I didn't know that
Someone wanted to find out the actual hardware address (MAC) of their LANIC without having to physically open up the 3000 and peer around inside. It was noted that NMMGR doesn't need this, at least when there is only one LANIC. In the box labelled address in the configuration screen, NMMGR is completely happy with a default value of "ff.ff.ff.ff.ff.ff.ff.ff". A couple of people proposed solutions using nettool.net.sys and sysdiag. While they work, it took a surprisingly long time before someone pointed out that there is an MPE command, LINKCONTROL, that will provide this information, and more.

LINKCONTROL is one of those commands that was probably introduced when it was irrelevant to my needs (and many other peoples'), so we don't take note of it. Then when the time comes when it might be useful, we are unaware of its existence. Another good reason to keep up with HP3000-L and post your questions (even using LaserROM's search would not have turned up LINKCONTROL).

TurboIMAGE prefetch
Ever since this feature was introduced, there has been considerable confusion over what it does. Probably because of the terminology. Most of us use the term "prefetch" when referring to a technique for speeding up file I/O or, possibly, instruction processing in a CPU. But as Ken Paul of Adager said in responding to a question about TurboIMAGE Prefetch, "Unfortunately, this is not what is meant by the TurboIMAGE Prefetch flag." Ken goes on to give a great explanation of TurboIMAGE prefetch, well worth quoting extensively:

"First, Prefetch is a flag that can be ENABLED for your database via DBUTIL. It was introduced in TurboIMAGE version C.03.13, which corresponds to MPE/iX version 3.1. By default this flag is DISABLED for your TurboIMAGE databases and must be explicitly ENABLED using DBUTIL.

"TurboIMAGE is currently 'single threaded' when it comes to doing DBPUTS, DBDELETES and most recently Critical Item DBUPDATES. This means that only ONE person is actually adding or deleting or updating a critical item at a time. To accomplish this, TurboIMAGE uses a semaphore lock known as the PUT/DELETE semaphore. This lock is applied at the beginning of the transaction and released at the end while several blocks are updated within the database which ensures data integrity.

"The Prefetch flag tells TurboIMAGE when to apply this semaphore lock. Before Prefetch, and with Prefetch disabled, TurboIMAGE locks the PUT/DELETE semaphore before reading, updating and writing every data block that is modified by the transaction. After this is done, the PUT/DELETE semaphore is unlocked.

"With Prefetch enabled, TurboIMAGE reads all the data blocks that are needed for the complete transaction before the PUT/DELETE semaphore is locked. Once the semaphore is locked, TurboIMAGE updates and writes the data blocks, which are modified by the transaction before unlocking the semaphore.

"It is the holding of the semaphore lock for a shorter period of time that could cause more throughput of data on your system, but it is not guaranteed. There is the possibility that when the data is read or 'Prefetched' before the semaphore lock is applied that it may be flushed out of memory by another process before TurboIMAGE is able to update it. If this is the case, TurboIMAGE must go back out to disc to read in the block again which could have a negative impact on your database performance.

"The Prefetch flag has always been a 'your mileage may vary' flag since its introduction. Certain conditions need to exist on your system in order to possibly gain benefit from turning on this flag.

"First, the system should have 'adequate' (a wonderfully nebulous word) memory available to handle the increased data page locality as well as adequate processor capability to handle increased concurrency of processes. Second, the application should make numerous calls to DBPUT, DBDELETE or, most recently, DBUPDATE to critical items. Third, multiple users must be processing data before a benefit can be realized.

"The HP Database Lab has said that they have seen a 5 to 10 percent improvements in the number of transactions that can be processed in benchmarks as a result of enabling Prefetch. They also mention that it helps in situations where you have excess CPU time and you are running update (I think they mean DBPUT/DBDELETE/CIUDBUPDATE) intensive applications.

"My suggestion on the Prefetch flag is to enable it and see if your environment changes noticeably. It can always be turned off if any problems appear. I would like to thank Marguerite Bryan of the HP Response Center, and Jim Sartain, formerly of the HP Database Lab, for information used in this article."

Hardware vs. software compression on tape:
can I use both?

This question comes up periodically, especially as hardware compression enabled DDS drives become more common. Several people wrote that they understood most drive and backup software vendors recommend against using both. You should try each separately and use the technique that achieves the best result consistently.

Mark Klein of ORBiT Software gave an interesting explanation of what is going on and what the possibilities are:

"Actually, there are cases where multiple levels of compression are useful. But first let me describe the various types of compression available.

"Hardware compression is typically LZW or some variant thereof. This type of compression uses a dictionary of repeating strings that can be dynamically determined on the fly and, as such, doesn't require the dictionary to be stored with the data as with other types of compression. There are other types of hardware compression available, but LZW is the most common found on compressing tape drives. LZW can also be done in software.

"Since the compressibility of the data really depends on the data itself, there are instances where negative compression will be achieved as well as instances where very large files can compress down to almost nothing. In fact, I've seen an instance where a large, multi-Gb database that was mostly empty got compressed into less than 32K using LZW.

"LZW is not effective in trying to compress something already compressed with LZW. This can result in negative compression (the resulting data actually gets larger). For that reason, I wouldn't recommend using LZW software compression on top of LZW hardware compression.

"Another type of compression is called run length compression. This is in essence a combination of a length tag and a string. The length indicates how many times to repeat the following string. For example, a line of 80 blanks would be represented by (80," ").

"Now, using a combination of RLC and LZW one can achieve better levels of compression than with one or the other method. So, if you want to use software compression with a hardware compressing tape drive, I would recommend using RLC compression in software."


Copyright 1996, The 3000 NewsWire. All rights reserved.