During the 1980, I worked as a Systems Engineer at HP. The HP 3000 and its operating system MPE became the center of my work and interest. 

I saved the most interesting programs I had written at HP. These were two 1600bpi open-reel tapes, which I could read 32 years after they had been written. WoW! So I re-built the my account structure on a PC and started to get re-aquainted with the programs. It helped tremendously that I found HP3000-simh, an simulator of an HP3000 Series III. 

The programs I saved are now running (partially) on the simulator. Some of them were written when MPE V/E git released, and I tried to understand the extended table layouts. Of course, these programs do mot make sense on a Series III simulator.

Early 2018 I came in touch with the owner of an HP 3000/52, who allows ma to use this system for some tests. It took me a while until I got the I/O confifuration right, but now the system is up and running.

 

Here are some examples:

7945A disc drive performance

When the /37 was first released together with the 7945A disc drive, there was some customer feedback about "slow performance". Now, this was an entry level system! But nevertheless, I started some test and found that performance greatly varied when connecing a 7945A or a 7933A disc drive. The 7933A showed significantly better results - much bettter then the theoretical figures - but only (mostly) on database or swapping I/O. 

I wrote some programs doing low-level disc I/O and after some tinkering, I found that the 7945A lost a complete revolution when switching from one disc head to the next. And due to the smaller number of sectors per track (than on the 7933A) the probability of such a switch to happen was much higher on the small disc drive. Had the start-of-track being staggered a bit more, the head switch time would not have caused the disc to need a full revolution until all electronics was ready for reading the first sector on that track.

 

Image Database System Performance

The Image DB system's master data sets used a hashing algorithm to calculate a record number from a given key value. This caused so called "synonyms" to appear: Different key values which hashed to the same record number in the master data set. That condition cause synonym chains to be constructed so that all these records coul b found even when they did not occupy their original hashed record number.

I became intereted in the duration of certain Image funtion calls. One possibility was to adopt the application program which issued the function calls, but this was not possible when a third party application was used. So I took the Image function call definitions and wrote my own set of functions (with the same defintion) where each funciton contained just a call to the respective Image function and a time measurement, and compiled it into an SL. If this SL was added to the "run" command for the application program, "my" functione whould have been called, and then had called itself over and over again until a stack overflow occured.

Instead, I did not use the original Image function calls but slightly "distorted" ones. And after compiling the program, I used another self-written program to correct the external symbol table in the SL to have the function calls in ther point to the real Image functions....