Sun Microsystems 96257 manual General Channel Extension Considerations

General Channel Extension Considerations

■General Channel Extension Considerations

Understand Channel Extension Performance Limitations

Channel extension usually involves using a WAN (wide-area network), which possibly op- erates at slower-than-FICON speeds. At the very least, the addition of channel extenders will cause additional overhead, and will slow down tape I/O processing.

Channel Extenders Are Invisible to Other Devices

By its nature, channel extension must look to end devices (hosts, switches, VTSSs, and/or RTDs) as if those were connected to each other without channel extenders; hence, chan- nel extenders are invisible to FICON devices. Neither software on the host (HSC/VTCS) nor microcode in a VTSS or RTD can sense the existence of a channel extender.

Channel Extenders Can Cause Timing Problems

Since channel extenders can cause delays, adding channel extenders to a configuration that works may cause I/O timeouts or other I/O problems. If channel extenders are used for both tape and disk I/O, the disk I/O can cause further delays for tape I/O, for example.

Channel Extenders Can Insert Fake I/O Errors

Some channel extension products attempt to streamline tape I/O in various ways, includ- ing simulating responses from tape drives or VTSSs. On occasion, a channel extender will encounter a problem, which must be reported back to the issuer of the tape I/O. Since a channel extender is invisible to end devices, it has no way to report errors itself; instead, a channel extender will report a fake I/O error coming from a RTD or VTSS, when the chan- nel extender was actually the source of the problem. These types of errors can be very dif- ficult to diagnose, and may require personnel from multiple vendors for resolution.

Avoid RECLAIMs and DRAINs on Channel-Extended RTDs

Most current channel extension products will attempt to streamline tape write I/O but not read I/O. This means users should avoid long operations that require large amounts of read I/O over channel extenders. There are many different back-end and front-end sce- narios to consider, but one that should definitely be avoided is doing DRAIN and RE- CLAIM operations over channel extenders. DRAINs and RECLAIMs tend to perform many tape read I/Os on input MVC cartridges (as well as tape wirtes to output MVC cartridges).

Avoid RECALLs on Channel-Extended RTDs

Most current channel extension products will attempt to streamline tape write I/O but not read I/O. This means users should avoid long operations that require large amounts of read I/O over channel extenders. RECALL operations cause data to be copied from a MVC cartridge mounted on a RTD back into a VTSS box. If the path between a VTSS and RTD includes channel extenders, such a recall may be very slow. Automatic recalls (which are triggered by a job on the mainframe needing data not available in a VTSS) especially can hold up critical work on the mainframe.

Avoid Syncsort Apps That Use Long Chains on Channel-Extended VTDs

Some Syncsort applications that use long chains (specifically when using sort work files allocated to virtual tape) will not run when using channel extenders between the host and the VTSS (i.e., a remote VTSS), due to protocol timeouts that can occur from WAN de- lays. The application should be evaluated, and dedicated conventional tape drives should be considered for Syncsort applications. If VSM is required, consider running the Syncsort application on local VTSS, rather than a remote (channel-extended) VTSS. Alternatively, if possible, the best option is to configure shorter chains.

96257	Sun Confidential: Internal Only	B-77
	Revision A