Friday Fine-Tune: Libraries, Large Disks
September 29, 2017
Where can I find a list of HP DLT libraries and what version of MPE can drive them?
No libraries are supported on MPE in random mode. While autoloaders can easily be made to work quite well on the HP 3000, one requires specialized software in order to make use of the full functionality of a DLT library. What is important from an HP 3000 point of view is as follows:
• The tape drives in the library must be supported on MPE and can be connected to the 3000. This means the drives must be DDS or DLT4000, DLT7000 and DLT8000. If the system is an HSC (pre-PCI) architecture, the drives must be HVD SCSI. If the system is a PCI system (A- or N-Class,) the drives can also be LVD.
• The connection to the library robot or picker, must also be supported on the 3000, again HSC needs HVD and PCI can do LVD or HVD.
• Finally you must have software that will connect to the picker and drive it. This software can either be running on MPE or on another system, to which the picker is connected. MPE itself cannot drive a robotic library.
I want to install disc drives larger than HP's 144GB. What issues should I consider?
The maximum disk size for MPE/IX is theoretically 2^31 sectors. Due to overhead and rounding DISCFREE output will show 2,147,483,632 sectors for such a disk, this is equal to 549,755,809,792 bytes. So, a disk of this size would likely be sold as a 550 GB disk (powers of ten) though it contains 512 GB from an engineering perspective (powers of two).
Even with the Large Disk Patches, MPE/iX users should be cautious when considering the usage of disks larger than 18-36 GB on MPE/iX systems for the following reasons:
MPE/iX transaction throughput increases when MPE is allowed to spread IO across disks. Even though newer disks are faster than older disks there are limits to disk speed and bus speed which must be taken into account.
Moving from nine 2 GB disks to one 18 GB disk, for example, will often create a disk IO bottle neck. For best performance we recommend that the number of MPE LDEVs never be reduced - if one has nine 2 GB disks then they should be replaced with nine 18 GB disks to ensure no loss of throughput.
I've heard about IMAGE/SQL's dynamic rollback recovery, but need to know more about its applicable intrinsics.
Employing DBXBEGIN, DBXEND, DBXUNDO can be used to protect the unloading of millions of database records. Using MPE/iX’s transaction manager (XM), uncommitted logical transactions can be rolled back dynamically (online) while other database activity is occurring. The dynamic transaction can be rolled back in the following ways:
1. Programmatically with a call to the DBXUNDO intrinsic, or;
2. Automatically when the application aborts or a system failure occurs within the transaction.
The SYSINFO program has crashed our N-Class. In the past, HP just told us don’t run the program. It's always seemed to be a useful tool. What should I watch out for?
From Hidden Value editor emeritus John Burke:
SYSINFO is one of those darling little programs that is available from HP on every system but technically unsupported. The Catch-22 comes in when in various documentation HP suggests you run SYSINFO to check something or other, but then will not support you if something goes wrong.
SYSINFO in the past was notorious for crashing loaded, multi-processor systems when “all”, “mem”, “module” or “cpu” commands were called. As far as I know, this is still a potential problem. It also had the nasty habit of breaking mirrors in a Mirror/iX environment though I believe that has been fixed.
As of MPE/iX 6.5, STM introduced additional complications; for example, “mem” can just start looping chewing up CPU time and never returning information if STM is not running correctly. There are other reports about bogus information being returned. SYSINFO can be a very useful program for displaying information about your system. However, it must be run with great care.