Several people asked off-list just what I had in mind wrt to emulated tape and disk over SCSI/FCP. Attached below is a draft of what I've got so far. If this is something you could support (and your company would support), please let me know.
-- db SCSI Support Extension Proposal Desired Action: Complete the emulated device over SCSI/FCP support introduced in z/VM to include both ECKD disk emulation on SCSI/FCP and emulation of channel-attached tape to generic SCSI/FCP tape devices. If possible, the tape emulation should also support a remote tape server option, mapping the emulated device to a user specified process over a network connection. Business Justification: 1) In many small to medium-sized shops, the amount of money available to invest in mainframe technology is limited compared to the funding accessible to the open systems environment. Often, significant disk and tape resources are duplicated or over-provisioned in the open systems environment, but are not accessible for reuse in the mainframe environment due to the requirement for specialized interfaces and separate management to support mainframe-specific environments. Enabling software emulation of mainframe devices on top of a generic SCSI/FCP infrastructure would allow System z infrastructure to leverage these existing enterprise infrastructure investments directly, improving the TCO argument for maintaining System z-based infrastructure. (It is clearly acknowledged that software emulation has a performance impact compared to native ECKD over FICON. In many cases, this performance vs cost tradeoff is acceptable in that the development curve for device and storage area network performance often offsets the disadvantage within a relatively short period of time, and the cost savings is often an acceptable tradeoff vs execution time delays due to longer I/O delays. ) 2) Even given the recent price reductions for the System z BC and EC machines, in some cases, the cost differential to implement separate disk for a System z environment (or add specialized interfaces to support FICON attachment of an existing disk array) is such that disk pricing is a deciding factor to preserve a System z environment. Similarly, environmental issues (floor space, power consumption, heat dissipation) may dictate that additional disk units to support only a single platform argue against retaining the System z solution as a "difficult to interoperate with" solution. 3) Additional disk volume formats and attachment methods complicate storage management discipline, adding additional training costs for storage administrators and possibly additional costs for software implementation to manage the FICON-attached arrays (not all vendors support FICON-attached volumes in their basic management software, but market that support as a enhanced feature). This increase in complexity further impacts the ROI and TCO of the System z solution. 4) Currently, only VSE, Linux and VM fully support FBA DASD. We are aware of work being done to z/OS to tolerate FBA disk, but until this work is completed, ECKD disk is required. If IBM is to open up additional market opportunity for z/OS or other ECKD-only systems in the short term, ECKD emulation is necessary to open those opportunities. It is important to note that ECKD emulation on SCSI disk has been done in the past for the P/390, R/390, and Multiprise systems, and it is clear from a cursory examination of the z/VM EDEV SCSI stack that these previous attempts could be used as a starting point to provide this type of emulated function. 5) With regard to tape, currently the largest supported FICON-attached tape unit supports a 40G uncompressed volume. Open systems tape units regularly support 200G or greater volume sizes. With the dramatic increase in data volumes, the inability of System z to access these commonplace devices argues significanly against adoption of a System z based solution in place of a Intel or other platform solution. 6) Similar to the ECKD disk emulation code mentioned above, tape emulation code for 3420 and 3480/90 tape over SCSI also exists, and offers direct support for all System z operating systems currently supporting tape without additional development. Emulated tape devices could easily be mapped to higher-capacity SCSI devices, providing direct benefit for backup/DR and data exchange purposes. 7) Adding ECKD and tape emulation would allow dramatic simplification of software distribution for System z operating systems, allowing applications to be directly supplied as disk images on inexpensive media (CDROM vs tape cartridges). This simplification would allow inexpensive distribution methods to be used in the future, as well as sophisticated verification tools that are not possible with tape-based installation today. 8) VSE users have had the option of supporting a remote tape server for some time now. This option has proven to be very flexible and helpful to control the costs of a System z solution, and allow considerable customer control of their data processing solution. Extending this support to all System z operating systems via a emulated tape device would be very desirable. Suggested implementation: 1) Provide a 3390 ECKD EDEV device type for z/VM Guests Similar to the 9336 FBA EDEV, providing a 3390 ECKD EDEV would permit defining SCSI targets to map to a ECKD emulation layer provided in CP. Large device support is already present in CP and in most guest systems, allowing the guest OS to sense the appropriate model of 3390 and build a real device support block as appropriate. 2) Provide a emulated 3422, 3490 or 3590 to SCSI tape device type for z/VM Guests The access model and tape handling model used by the typical SCSI tape drive are most similar to the 3420 and 3422 devices in that the 342x media have no defined cartridge size, and rely on the device to notify the OS of the end of media and other important details. Defining a emulated 3422 tape device would allow guests and CMS users to directly manipulate SCSI tape using all the existing tools without modification. The 3490 and 3590 emulation would allow 3490 and 3590 drives in libraries shared with non-System z systems to be defined physically as all-SCSI devices, allowing workload to be dynamically shifted between operating environments w/o partitioning libraries or separate device management. 3) Provide a emulated tape to remote tape server option over TCP Providing a standardized ability to intercept I/O to a emulated tape and redirect it to a remote tape server would be very helpful for Linux and other guests to interact with tape managed by a host VM system (both SCSI and channel-attached). Mapping the emulated device to a IUCV service and having a CMS or Linux virtual machine multiplex the tape I/O to a remote system would be very desirable.
