I see one possible problem right off the bat; we now have a new lpar
that is not mentioned in the policy at all. This new sandbox lpar is the
one we have been ipl'ing during the day and causing the timeouts for
other lpars - production. 

/* Active Policy: NAME(KFBPS2) CONNFAIL(NO)          
   Defined:   07/27/2006 17:12:09.236924 User:BHD2160
   Activated: 07/27/2006 17:12:52.474340             
  SYSTEM NAME(*)                                     
    WEIGHT(5)                                        
    ISOLATETIME(0)                                   
  2 System Definitions in this Policy                
  SYSTEM NAME(PRODP1)                                
    WEIGHT(200)                                      
    PROMPT                                           
  SYSTEM NAME(TESTT1)                                
    WEIGHT(10)                                       
  0 Reconfig Definitions in this Policy              
   End of Active Policy */                            

I'll check into init and tuna and see what these long gone sysprogs were
intending to do. We have nothing remotely like "exspat" in our parmlib. 

Was fuer Suessigkeiten essen Sie am liebsten? What kind of cookies do
you like, Barbara

Ken Klein
Sr. Systems Programmer
Kentucky Farm Bureau Insurance - Louisville
[email protected]
502-495-5000 x7011

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Barbara Nitz
Sent: Thursday, July 09, 2009 1:07 AM
To: [email protected]
Subject: Re: Sysplex timeout problems.

I was going to ask Mark how (and if) fencing works in a basic sysplex
when Skip (very oblingingly) provided the answer that it doesn't. :-(

So, in Kens case, he will always get IXC102A. 

>A strong word of caution:
>DO NOT automatically reply DOWN.

Mark, does this apply to a basic sysplex, too? Or would Ken be safe
having automation reply to it? 

Ken, from your couplexx, it appears that you do have an SFM CDS. You
will need to run this job to see what was defined as a policy.
//STEP1    EXEC PGM=IXCMIAPU     
//SYSPRINT DD   SYSOUT=*         
//SYSIN    DD   *                
  DATA TYPE(SFM) REPORT(YES)     

Then you need to read up on *what* is defined and what is defaulted, and
check against the values I mentioned before and how they work together. 

EXSPAT is excessive spin parmlib member, decribed in Init&Tuna.

My word of advise is to remove the parms INTERVAL, OPNOTIFY and CLEANUP
from your couplexx and have them default to whatever IBM thinks it
should be. 
Same goes if you have an EXSPATxx parmlib member defined and active.

If this gives you the longer interval before TCPIP starts complaining,
then all is fine. Otherwise you will need to 'tweak' the values for the
above parms.

Best regards, Barbara

----------------------------------------------------------------------
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

Reply via email to