> > Except there's nothing supplied that's capable of exploiting it, so it's > > pretty useless. Attaching a virtualized VT220 to the HMC isn't all that > > useful either given the arcane and fragile nature of the HMC. > 1. z/VM 5.3 allows you to ATTACH the real HMC ASCII console to a guest.
I guess I don't consider the HMC a component that common citizens should be permitted to manipulate. It certainly isn't something that the unwashed masses should be permitted to touch, and it's not part of the VM environment. > I don't understand your point about nothing exploiting it; > it's for people. There are no tools within a VM system that can drive or manipulate data streams to the virtualized VT220 console. The HMC is not a VM component (in fact, it is deliberately OUTSIDE the scope of any operating system by design), and the assumption that anyone needing that VT220 console access should ALSO have either a) physical access to the HMC or b) network access to the HMC is optimistic, IMHO. It's not unusual these days for the machine to be several hundred miles away from the people, and/or physically inaccessible to even the systems people. ATTACHing a process that runs only on a closed box with no external integration points isn't (at least IMHO) exploitable. I'd also really hesitate to allow your average Unix administrator access to something like the HMC; the access controls exposed in the HMC UI are just not manageable at any scale. If there's a way to integrate access control via external sources into the HMC *that IBM is willing to support*, I'd sure like to know where to read about it. >From a usability standpoint, it'd be my expectation to AT MINIMUM be able to do SSL-protected telnet to a concentrator of some time and select a connected system to interact with. > 2. I don't understand the "arcane and fragile" comment. [snip] > Maybe you're referring to the "F-R-A-G-I-L-E" on the shipping container? > That's the country of origin, pronounced "fra-gee-lay". :-) Nyet. It is trivially easy to close a window and lose it in the HMC GUI. It is trivially easy to generate a situation where you cannot open an important HMC application you need to correct a problem because the HMC GUI insists that a window for that application is already open somewhere. It is trivially easy to cause assorted remote access failures to the HMC GUI from external sources. It is trivially easy to replay session streams back to an HMC if it is network accessible. I could continue, but confusing UIs or those kinds of reliability issues constitute fragility. I don't disagree that the HMC has improved a LOT since the MP2k days. I do contest that it constitutes a good design management goal to have it in the loop for things that are in normal operations for virtual machines. An HMC can do way too much harm to have that be attractive. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
