Thanks, that sounds like the most likely explanation for an SRB being
delayed. I wonder who would be doing a STATUS STOP,SRB in a CICS region?
Might that be the hypervisor or WLM?
Thanks again,
Dave
--
For IBM-MAIN subscribe /
Dave Stedman wrote:
I don't know whether ASCB in ASCBDSP1 had marked the address space as
non-dispatchable. It was a CICS region. What may cause this bit to be set
on?
STATUS STOP,SRB
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 9
I don't know whether ASCB in ASCBDSP1 had marked the address space as
non-dispatchable. It was a CICS region. What may cause this bit to be set
on?
Thanks,
Dave
--
For IBM-MAIN subscribe / signoff / archive access instruct
>weights of the other LPARs have made any difference?
Yes.
The dispatching of each LPAR is not really any different than the dispatching
of a task.
If your LPAR was/is low on weight, and there is/was CPU contention, it may
matter.
When in doubt.
PANIC!!
-
In a message dated 10/26/2006 3:40:36 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>Can anybody explain why occasionally IEAMSCHD takes several seconds to
>schedule an SRB? Normally this takes microseconds but in one case I am
>looking at it took 61.4 secs!!!
>The environment w
Dave Stedman wrote:
IEAMSCHD returned to its caller within a few microsecs, but then the SRB
did not start for 61 secs!
Any chance ASCB was set in the target address space?
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338
I don't have the weights of the other LPARS. Since this LPAR was very
active during the 61 sec wait with both srb and tcb activity, would the
weights of the other LPARs have made any difference?
Thanks,
Dave
--
For IBM-MAIN sub
IEAMSCHD returned to its caller within a few microsecs, but then the SRB
did not start for 61 secs!
Thanks,
Dave
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message
Dave Stedman wrote:
Can anybody explain why occasionally IEAMSCHD takes several seconds to
schedule an SRB? Normally this takes microseconds but in one case I am
looking at it took 61.4 secs!!!
Are you saying the IEAMSCHD service did not return to its caller right
away? Or that the SRB rou
>The environment was an LPAR with 13 shared engines and zero dedicated engines.
What are the other LPAR's?
Weights?
Also, if you have shared engines you cannot have dedicated ones in the same
LPAR.
When in doubt.
PANIC!!
---
Hi all,
Can anybody explain why occasionally IEAMSCHD takes several seconds to
schedule an SRB? Normally this takes microseconds but in one case I am
looking at it took 61.4 secs!!!
The environment was an LPAR with 13 shared engines and zero dedicated
engines.
The IEAMSCHD was in a DIE and th
11 matches
Mail list logo