> > > There should be an IBM > > > product that starts with T to fix this problem across all platforms. > > > > Bleagh. Please, no. Fix the problem, not the symptoms. > That was the original plan, and many ideas have been debated since. How > would you fix the problem?
My suggestions: 1) Focus implementations on user-assigned WWPNs, which are not bound to physical hardware. You're going to end up dealing with virtualization solutions anyway, and that seems to be the direction the discrete world is headed. Same reasoning as why you never hardcoded token-ring addresses in VTAM -- you don't want to have to go back and fix up this kind of stuff during upgrades, and that configuration option can be carried between machines. 2) Add iSCSI support to the device microcode. Converged networks are the goal for most customers, and being ahead of the curve would be smart. iSCSI remedies most of the issues recently discussed in a far more portable way, and leverages a lot of things that would be highly useful in both z/OS sysplex and the VM SSI approach. The work done in the OSA to support some amount of TCP offload would be a good basis to start; completing the IP stack inside the OSA card would provide a basis for using a converged microcode load for both disk and network. Getting the router vendors to do this work for you would be even smarter (compare with router blades in Bladecenter on Intel) -- they already have line-speed converged networking and QoS delivery for 40G and 100G networks as shipping product that you don't have design or maintain. Linux has support for iSCSI baked in, and it is at least (if not more) reliable than FCP. Multipathing concerns go away. It's possible to easily implement iSCSI to FCP bridges in hardware ASICs. Eases the transition to software defined networks. Adds value to z/OS in that it would position z/OS as a leading enterprise OS in converged storage/data networking. 3) On real hardware, push the FCP mappings further into IOCP. Part of the value of the abstract device number concept in the XA I/O architecture was to not have to care about stuff like this in the OS. Expanding the virtual FCP device definition in CP for Linux hosts similar to what was done for virtual MACs would be valuable (again, use the user-administered space for virtual devices and perform transforms in CP space to real hardware). The concept of virtual IOCPs has been discussed in the past, but was deemed not enough business case. This is an example of a good reason to do it. Would make the transition for z/OS to FBA a lot easier (could silently implement CKD translation to FCP w/o z/OS having to know/care) 4) Offloading the transformation process in VM for 9336 emulated devices to the I/O subsystem. Good candidate for a HW assist. This code currently runs on the 390 CPUs. This would be an accelerator that would benefit not just Linux but other OSes -- that's one of the major reasons why people don't run totally FBA systems (other than the missing FBA support in z/OS). Would make #3 lots easier. The reason I don't want a Tivoli solution is that the PHBs need to see the value of how much simpler to manage the 390 iron is -- they would view a requirement for a Tivoli product as another reason why the 390 costs more to run and is incompatible with their other strategic solutions. Tivoli has a bad habit of assuming that it's the whole universe, and it often doesn't play nice with others in terms of API or scalability. ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
