On Tuesday, 09/12/2006 at 11:53 CDT, Ron Greve <[EMAIL PROTECTED]> wrote:
> Since we had RSCS, VTAM and JES working with SCTC device/links > we thought these links would also work with TCP/IP. (and it sounds > like it would have if we were talking from Z/OS TCP/IP to Linux TCP/IP) > > What I think I'm hearing is that VM TCP/IP only supports BCTC (Parallel > Basic Mode CTC support over ESCON). Not. VM TCP/IP supports 3088/ESCON/FICON CTCAs in extended mode. You must code one end of the connection as TYPE=CTC and the other end as TYPE=CNC. Code UNIT=SCTC on both ends. If you code UNIT=BCTC, then the attempt by TCP/IP to switch the adapter to extended mode is ignored (no-op) and things will go rapidly downhill. No I/O error (i.e. Command Reject), but a link that doesn't operate correctly. The above applied to z/OS and Linux, too. > I think the ccw_chan_mode parm in SLES specifies the type of CTC > link. I think "0" would correspond to BCTC. > > >CCW_CHAN_MODE="0" Nope. CCW_CHAN_MODE corresponds to the specific link-layer protocol to be used by CTC device driver, not to the channel mode. Code 0 for VM and VSE, 1 for Linux, and 3 for MVS. Since physical connections don't have the convenient "cross-coupling" of even-to-odd addresses used in guests, you must instruct VM TCP/IP to write to the channel Linux is listening on. Do this by coding '1' as the CTC's DEVICE statementin the VM TCP/IP configuration. Alan Altmark z/VM Development IBM Endicott
