I also worked in a shop that had a 158, and upgraded it to an AP, with a total of 6 MB of main storage (4 MB was Memorex add-on memory).? It also worked well for MVS.? IIRC, it also worked reasonably well if you ran VM on the main processor, and ran MVS in a favored virtual machine and dedicated the AP side to that MVS virtual machine.
The reason it was not as helpful for? normal VM/370 Rel. 6 use was because of the locking that is needed in CP between the main processor and the code running on the AP side.? The issue has to do with the design of the locking hierarchy.??
As you may recall, MVS has a hierarchy of locks, starting with the LOCAL lock, then the CMS lock, etc. for various parts of the OS.? You had to always obtain the lower level locks before you could obtain the next higher level, e.g. you always had to obtain the LOCAL lock, then the CMS lock, and so on.
But, for VM/370, AP support implemented essentially just a single GLOBAL lock for all of CP.? So, there was quite a bit of contention for this one global lock, between the main CPU and the AP side, for doing pretty much anything in CP that required updating various control blocks, etc. There was also extra overhead because each processor has its own TLB, so paging was more complex.
With VM/SP, VM/HPO and later releases (VM/ESA, etc.), they addressed various performance related issues.? But, it was a matter of "expediency" to get VM/370 to support the AP hardware at all ... once the AP hardware was available.
There was a good article in the IBM Systems Journal that explained the complexities of dealing with AP and MP configurations for VM's CP.
I put a copy of that article in the H390-VM "Files" area ... for those interested ...