Filter
Top Products
96257 Sun Confidential: Internal Only B-77
Revision A
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.