On Aug 16, 2020, at 1:41 PM, Mark Post wrote:
> If you mean you're running SLES9 GA, with no service packs, then some of
> what I'm going to say may be wrong. I only have a SLES9 SP4 guest
> running. However, if you look in /sbin/, there should be a
> dasd_configure command that may or may not produce different results
> than what you're seeing.
dasd_configure is what yast uses under the covers to bring the device online
(with `echo 1 >online`), among other things. I've played with it a bit and it
doesn't matter whether it's dasd_configure in yast or me running
dasd_configure, or me doing the echo >online, it always hangs up the same way,
when it gets to echo >online
>> CNTLUNIT CUNUMBER=232F,PATH=(10),CUADD=2,UNIT=SCTC, X
>>
>> UNITADD=((00,16))
>>
>> CNTLUNIT CUNUMBER=233E,PATH=(11),CUADD=3,UNIT=SCTC, X
>>
>
> I don't know that it makes any real difference, but why is this 233E,
> and not 233F?
Because that wasn't the whole story. In order to get a CTC and CNC devices
distributed among the LPARs, with each being able to address each other LPAR
(by CTC or CNC as necessary), this is what I have (and believe to be required -
though, yes, this is definining more than just one CTC/CNC connecting two
LPARs):
CNTLUNIT CUNUMBER=231F,PATH=(10),CUADD=1,UNIT=SCTC, X
UNITADD=((00,16))
CNTLUNIT CUNUMBER=232F,PATH=(10),CUADD=2,UNIT=SCTC, X
UNITADD=((00,16))
CNTLUNIT CUNUMBER=232E,PATH=(11),CUADD=2,UNIT=SCTC, X
UNITADD=((00,16))
CNTLUNIT CUNUMBER=233E,PATH=(11),CUADD=3,UNIT=SCTC, X
UNITADD=((00,16))
*
IODEVICE ADDRESS=(2310,16),UNIT=SCTC,CUNUMBR=(231F), X
UNITADD=00,STADET=Y,PART=(IZXD,IZXL)
IODEVICE ADDRESS=(2320,16),UNIT=SCTC,CUNUMBR=(232E), X
UNITADD=00,STADET=Y,PART=(IZOD)
IODEVICE ADDRESS=(2320,16),UNIT=SCTC,CUNUMBR=(232F), X
UNITADD=00,STADET=Y,PART=(IZXL)
IODEVICE ADDRESS=(2330,16),UNIT=SCTC,CUNUMBR=(233E), X
UNITADD=00,STADET=Y,PART=(IZOD,IZXD)
> Doesn't this mean that 2330 is TCPIP's read channel? (I'm not a z/VM
> networking type, so I don't know.)
>
>> ===== LINK IZXL2320 CTC 1 IZXL /* I've tried this with both CTC 1 and CTC
>> 0 */
>
> Or does this statement say which of the two is used for read versus write?
The CTC 1 makes 2330 the write channel, and 2331 the read. CTC 0 would make
2330 the read. If I've read the VM TCP guide correctly. I tried it both ways
because I don't know if the IOCP does the crossover for me or not.
>> List of first 10 CTC Channels that were detected:
>> Device Channel type
>> 0.0.0e20 3088/01
>> 0.0.0e21 3088/01
>> 0.0.2310 3088/1f
>> 0.0.2311 3088/1f
>
> OK, I'm not seeing the device addresses you said you were going to use.
> That is, 2320 and 2321. Where did 2310 and 2311 come from?
I cut out some of the list, and it's a list of only the first 10 detected
channels. 2320 would be the 19th (of 34 total defined).
> Well, to me, where you're going wrong is not defining the Linux system
> as a guest of your z/VM system. :)
Well, if this were an official project and not a learning one, I'd agree
unreservedly. Eventually I'll have linux guests under VM, too. But not at this
moment.
> Beyond that, I think that you need to be using the same CTC devices in
> both LPARs. Otherwise, how is the system supposed to know that traffic
> on 2320 goes to 2331, and 2321 to 2330?
I believe (this is the part of the EMIF CTC section in the IOCP User's Guide I
think I understand pretty clearly) the CUADD and third digit of the real device
number (23x0) indicates the LPAR number of the other end. My (less clear)
understanding is that IOCP generates pseudo control units based on this, which
perform the role of the 'CP COUPLE' command. I have assumed, but am not yet
confident, that the last digits are what tie both ends together. e.g. in LPAR
3, 2310 would connect to 2330 in LPAR 1, and 2320 to 2330 in LPAR 2. -- "A
corresponding pair of CTC devices can have different device numbers, but they
must use the same unit address."
ok
bear.
--
until further notice
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390
