Re: CTC Disconnect Time

2008-05-13 Thread Chris Mason
Dave and Magen

This looked interesting so I had a quick chat with a colleague and - guessing a 
bit - we think the measurements you see are a consequence of a particular 
technique used by High Performance Data Transport (HPDT) channel 
programming called a "never-ending channel program", more accurately 
a "seldom-ending channel program". We think that this may well show an 
apparent 100% utilization on the "read" side in the RMF report since it's 
always 
busy looking for work down in the bowels of the channel logic. It's also 
possible that the "Device Disconnect time" is explained by the "seldom-ending 
channel program"; probably I'd be able to be surer if I had more of a clue as 
to 
what "Device Disconnect time" in an RMF report actually meant.

The XCF link using HPDT is necessarily full-duplex. The VTAM SNA subarea link 
using a single subchannel address is necessarily half-duplex that being the 
nature of the beast.

Since you don't actually have a performance problem - and your utilization is 
low - "it ain't broke and it don't need fixing" - and it's very probably quite 
normal.

Perhaps someone who really knows what the RMF reports report on can be 
clearer.

Chris Mason - and, TGCWCID, Kevin Crombie

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



Re: CTC Disconnect Time

2008-05-12 Thread Dave Barry
Off the top of my head, I believe you have to tell VTAM that there are separate 
inbound and outbound paths between the two nodes.  Sounds like you're 
configuration has forced your links to be half-duplex.

db

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
Magen Margalit
Sent: Monday, April 14, 2008 4:29 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: CTC Disconnect Time

Hi list,

I have a situation I don't fully understand...

I have a shared Escon channel used as CTC between 2 Lpars.
The CTC is used for XCF and VTAM communication.
For XCF there are 2 Devices defined on each system (in and out) and for VTAM 
there is 1 device defined on each system.

Looking on RMF report I see the following info:
Channel utilization is low - about 10%
Device Disconnect time for the IN device (on both systems) is huge - about 
5000ms (the out devices numbers are fine).
The in device utilization is almost at all time near 100%.

I don't think that this is a normal situtation, but except from GRS delay for 
XCF (about 5%) It doesn't seemes to have any performance effect or am I wrong?

Any help would be appricated.

Thanks
Magen

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
[EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



CTC Disconnect Time

2008-04-14 Thread Magen Margalit
Hi list,

I have a situation I don't fully understand...

I have a shared Escon channel used as CTC between 2 Lpars.
The CTC is used for XCF and VTAM communication.
For XCF there are 2 Devices defined on each system (in and out) 
and for VTAM there is 1 device defined on each system.

Looking on RMF report I see the following info:
Channel utilization is low - about 10%
Device Disconnect time for the IN device (on both systems) is huge - about 
5000ms (the out devices numbers are fine).
The in device utilization is almost at all time near 100%.

I don't think that this is a normal situtation, 
but except from GRS delay for XCF (about 5%)
It doesn't seemes to have any performance effect
or am I wrong?

Any help would be appricated.

Thanks
Magen

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html