Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!ucbvax!YKTVMH.BITNET!PERSHNG
From: PERSHNG@YKTVMH.BITNET ("John A. Pershing Jr.")
Newsgroups: comp.lang.asm370
Subject: (none)
Message-ID: <9001031423.AA23670@brazos.rice.edu>
Date: 3 Jan 90 14:07:48 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: IBM 370 Assembly Programming Discussion List <ASM370%UCF1VM.BITNET@ricevm1.rice.edu>
Distribution: inet
Organization: The Internet
Lines: 31

There is really no substitute for reading the manual:

         SA22-7091 -- IBM Channel-to-Channel Adapter

Chan-chans (virtual or otherwise) are a bit tricky to deal with, and have
a somewhat higher "entry cost" in terms of programming than, say, a
unit-record device such as a reader or a punch.  When the X Side starts
up a channel program it posts some sort of "status pending" condition on
the Y Side, which I believe needs to be cleared with a SENSE operation
before you can successfully execute the matching channel program on the Y
Side.  I can't provide the exact details, as I gave my copy of SA22-7091
away to somebody and haven't gotten a replacement yet.

Try writing a test driver that issues a WRITE on the X Side, and another
test driver that waits for the unsolicited ATTN interrupt on the Y Side,
then puts up a SENSE that is command-chained to a READ and see what (if
anything) happens.

However...

If your interest is figuring out how to do I/O programming, then the
chan-chan is probably the *worst* choice of a device:  start with
unit-record devices, and then move up to disks.  If your interest is
inter-machine communication, then use APPC/VM, IUCV, and/or VMCF:  these
are all easier to use than a virtual chan-chan.

I only recommend chan-chan programming for applications that are going to
be forced to use a *real* chan-chan (e.g., a 3088).

      John Pershing
      IBM Research, Yorktown Heights