z/VM directions, an interesting subject that we also discussed at the Technical University in Vienna, where I also got the tip to join this list.
As a long time z/VM user my main concern is NOT exploiting new areas and new technologies, it is rather exploiting existing or new hardware functions and making them available for the guest systems. I do not know of many users that use an LPAR, run z/VM under it, and then run z/OS guests, but that is where the problems for us begin. z/VM exploits the hardware but in several cases can not pass this information to a guest z/OS system. For example: z/VM supports hyperpav and hyperpav aliases, even if they use the same address (using channel subsets) but can not pass channel subsets to the z/OS guest. I can understand that there is pressure to allow new work loads to run under z/VM, but the current work loads and work cases must also be supported. When I asked why our main shop does not try to do anything with z/VM the answer was shot back - because z/OS capacity pricing is not supported under z/VM, be that by z/VM or by vendors that do not even offer licenses for hard capped guests under z/VM. I would like to add that we discussed these issues in Vienna, and I have high hopes that these hindurances for z/VM will be resovled, hopefully before I retire. Being a long time user I love the stability and ease of use of this great product, z/VM, and am looking forward to its future. Regards, William Kim Mongan ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________