> 1. I think the physical and NPIV wwpns will continue to be managed by
> firmware for security.  There is definitely value in being able to migrate
> them around a plex though.

This isn't mutually exclusive with telling users "don't be stupid --  using anything other than a NPIV address in a FCP guest will cause you reams of grief. Don't do it.". You can still manage the hardware addresses in firmware as today, until you can come up with a way of migrating the mapping of hw addresses to NPIV or user-managed WWPNs.

> 2.  It isn't very easy to add a channel type.  Firmware is free like device
> drivers ;)  Anyway, that was a good description of iSCSI.  Many things that I
> didn't know.

Since iSCSI semantics are pretty much identical to FCP semantics, I'm not sure why a new channel type would be required -- in fact, since iSCSI is just IP packets, you could get rid of one..8-). Perhaps you could ease the transitions by adding some new options to the FCP channel type -- that option transport could be covered by the current out-of-band-parameter communications that are already present in the existing FCP microcode process.

> 3. I think this is the most popular solution.  I've heard it at least 5 times.  It
> was my idea when I was a an ignorant new hire.  Every time it comes up
> there is some reason not to do it.  Maybe it is time for customers to raise
> the issue in a more official forum.

Been there, done that. 8-)

It came down to "Figure 1: We make a boatload of money licensing FICON and ECKD tech. Don't mess with that. Figure 2:  See Figure 1." IBM owns about 2 dozen different ways to do this (see CKD emulation in the P390 for a reasonably high-performance example), but see Figure 1. Or the XIV box.

> 4. We didn't make a ficon data router for various reasons so I don't see us
> revisiting it in this context.

Not sure what a Ficon router does here. A hw assist for 9336 translation would have to be in the I/O CCW evaluation path to be effective, but that doesn't imply routing function.

> Good point about Tivoli being an added cost, but it shouldn't be an added
> cost to just the mainframe.  The idea was to have a tool to manage wwpns
> across all platforms.

Problem is, most FCP implementations come with one provided by the HW vendor, and the hw vendors start finger-pointing if you don't use their tools. If there is a Tivoli requirement to play nice with the mainframe, that touches a lot more things than just the mainframe, and the assumption is that all tools have complete control -- and knowledge -- of the entire universe before they can make smart decisions fails miserably in a multi-vendor environment -- can't do that if part of the environment is managed by one tool, and another part is managed by another tool, and there are no effective APIs to communicate between tools.

There's a lot of cases where the hw vendor tools are included in the price of the hardware; an additional Tivoli requirement is a non-starter -- unless you guys are willing to go back to the Avanti consortium work and really agree on a toolset that HP and Hitachi and Oracle and ALL the other vendors can use as a common base for management software. That was a promising project -- killed by vendor bickering.  

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.M... 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/