the error as SyncLost.
The ESS 800 side comes up and the switch shows the shark connected
with Port Type F, Speed 2GBps and indicates Sync Acquired
IBM hardware support said the IOCP is correct and that the correct
microcode is in the z800.
Thanks
Ron Greve
>--
that (even though none of the examples show this)
and got an IOCP error indicating that SWITCH= is not an option
on a CHPID type of FCP. We're cross posting this to the LINUX-390
list to see if there are any other suggestions before we go up the
HW support ladder.
Ron Greve
Admin an
for any suggestions.
Ron Greve
SDSU Admin and Research Computing
running 4.4 TSM under 5.2 while we finish the move to
Z/OS? Will 5.2 accept the "Enablement" of TSM?
Ron Greve
SDSU Admin and Research Computing
is using and defined them for
RSCS links and they connect fine. It must be something with how
TCP/IP uses the Read and Write pairs instead of multiplexing them
like RSCS does.
We also know the TCP/IP's are physically seeing
each other because activity on one end (pinging etc.) sets off the
Units checks on the other end.
Ron Greve
the IOCP
etc. (which is giving us the unit
checks) from our original posting?
If not, what are we not seeing?
Thanks for trying to untangle my old synapses. ;-)
Ron Greve
Here are our current IOCP definitions again along
he VM TCP/IP in the non IFL LPAR should be able to
communicate with a LINUX quest in the IFL LPAR.
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"
If we're still off base we are op
RSCS's and JES2's successfully. Two of these go between
Lpar ESA11 and Lpar IFL and both are operating.
Thanks
Ron Greve
CHPID PATH=02,TYPE=CNC,PARTITION=(ESA11,ESA12,IFL),SHARED
CHPID PATH=03,TYPE=CTC,PARTITION=(ESA11,ESA12,IFL),SHARED
CNTLUNIT CUNUMBR=0401,PATH=(02),UNIT=SCTC,UNITADD
>try setting the adapter number on the LINK statements to be the same: =
>Both 0s or both 1s
>David
>
David
We set them both to 1 as show below. We now get a configuration
error DTCCTC059 (TCP/IP recognizes link adapter address is invalid.)
We set them back to 0 and 1 and we can get the links
>could you post your DEVICE/LINK pair from PROFILE TCPIP?
>David
To simplify testing we set up a second tcp/ip in the second
lpar and connected the two over a real ctc. We saw the same
failures as we saw by using SLES in the second lpar.
lpar one
--
attach 448 tcpip 720
attach 449 tcpip
>
>could you post your DEVICE/LINK pair from PROFILE TCPIP?
>David
>
>
To simplify our testing (taking out any LINUX issues) we set up
a second tcp/ip in lpar 3 that we connected to the stack in Lpar 1
Here are the device/links from the two lpars.
; lpar one tcp/ip device/link
DEVICE CTCVDE
RSCS links work
fine. Is there something unique in TCP/IP
with real CTC links that we may have missed?
Thanks for any help.
Ron Greve
SDSU Admin and Research Computing
ly as VLAN unaware)
Any pointers for them would be appreciated.
Ron Greve
Admin and Research Computing
SDSU
[EMAIL PROTECTED]
<<<<<<<<<<<<<<<<<<<<<<<<<<<<
<<<<<<<<<<<<<<<
>On 19 Jul 2006 at 9:50, Alan Altmark wrote:
>
>> > Yup. the 2 commands you want are STOP and START.
>> > You use an OBEYFILE to run them.
>>
>> How quaint. :-) Try NETSTAT OBEY STOP and NETSTAT OBEY START
>> .
My aging mind must be getting vapor lock again. I kept thinking HALT
instead S
IODEVICE ADDRESS=(0540,32),CUNUMBR=(0503),UNITADD=00, X
UNIT=SCTC,PART=(IFL)
>
Again, thanks for the help in getting this thing connected.
Its been a while since we've run LPARs. The IFL and some isolation
issues on Z/OS forced us back to LPAR&
e Lebowitz notes (good examples of
defining the IOCP) but there were no
examples of how to use the IOCP CTCs after they are
defined in the IOCP so we did some guessing.
Any pointers on where to get a handle on how to do this would
be appreciated.
Ron Greve
SDSU Admin and Research Computing
[EMAIL P
16 matches
Mail list logo
