Hi Matt, 


I suggest taking a look at syslog for an early IPL message like this one - 


*01 IOS120D I/O TIMED OUT FOR DEVICE 0B06. REPLY 'WAIT' FOR I/O 
 COMPLETION OR 'CONT' TO CONTINUE WITH DEVICE OFFLINE           
 R 01,CONT                                                      


If somebody replied WAIT instead of CONT, that will cause start pendings on the 
waiting LPAR.  From the displays aleady posted, looks like there is a hardware 
reserve pending on this volume, which normally happens very briefly during 
startup while the system reads the volser.  So, I surmise that the other system 
was already up when your IPLed this one, AND someone repled WAIT to the IOS120D 
message, else the I/O Time Out for device would not have happened, .  



If you have a two LPAR monoplex, Just  re-ipl your sandbox .  If the message 
was posted on production, production will be satisfied and all will be well.  
Re-ipl your sandbox and be sure to reply CONT.  



We do not share any JES2 resources between prod and sandbox, so we the IOS120D 
message every time we IPL on which ever system comes up second.  



HTH, 



Linda 

----- Original Message -----


From: "Matt Dazzo" <[email protected]> 
To: [email protected] 
Sent: Tuesday, February 18, 2014 11:59:14 AM 
Subject: Re: IEF196I Message 

Wondering if this could be related to BMC Autooper. I noticed when I varied 
another volume online to our sandbox a minute later the start pending came up 
for the 4299 addr. Before the start pending message there some BMC messages. 
Anybody have any ideas? Thanks Matt 

V 4001,ONLINE                                                             
IEE302I 4001     ONLINE                                                   
SVM0021I POOL TABLE REBUILD DUE TO ENF REQUEST                           
SVM2046I CONFIGURATION COLLECTION/REFRESH SUCCESSFULLY COMPLETED         
SVO5052W ERROR ENCOUNTERED IN COSSI423: NO VOLUME LEVEL STATISTICS       
EXIST                                                                     
SVO5053I RC=04, RS=017                                                   
SVM2019W UNABLE TO ACCESS DATA SET COUNTS IN VTOC SCAN MASTER DATA SET   
SVM2042W NO VOLUME LEVEL STATISTICS EXIST                                 
SVM2042W RC=04, RS=017                                                   
SVM2042W SRI VTOCSCAN_VOLSTAT RC=00000004, RS=00000011                   
IEF196I IEF237I 497A ALLOCATED TO SYS00077                               
IEF196I IEF285I   SYS1.CMDLIB                                  KEPT       
IEF196I IEF285I   VOL SER NOS= TZ13P1.                                   
IEF196I IOS071I 4299,**,*MASTER*, START PENDING                           
IOS071I 4299,**,*MASTER*, START PENDING 156                               
IST663I CDINIT REQUEST FROM PCH1CDRM FAILED, SENSE=087D0001 158           

-----Original Message----- 
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Staller, Allan 
Sent: Tuesday, February 18, 2014 1:22 PM 
To: [email protected] 
Subject: Re: IEF196I Message 

Not arguing that point.   

All of this conversation stems from the Other Image attempting to contact 
device 4299 and did not get a response in a timely manner. A "timely manner" is 
defined by the MIH values in IECIOSxx on the "other system". This is mostly a 
good thing, but carried to extremes causes this issue. 

1) for whatever reason, MVS1 indicates to other images that device 4299 is 
busy. This can come from a variety of sources. 
2) The other images MIH is waiting for a response. If this response is not 
received, the MIH causes the Start Pending message to be issued. 

>From the viewpoint of MVS1: 

1) JESCKPT (if not tuned), hangs a never-ending reserve on the CHKPT volume. 
This will cause the other systems to see a continuous device busy and 
eventually, MIH will trip and the Start Pending message will be issued on the 
other image. 
2) As previously noted, SMF19 processing will attempt to contact the device, 
regardless of the online/offline status. If the device is marked busy either by 
reserve processing or just general activity, this will also cause the Start 
Pending. Normally this will occur at startup/shutdown time. 
3) BROADCAST uses a very old technology and is a known contributor to excessive 
Device Busy. 

In short, when the device is  *very* busy to MVS1, the OTHER SYSTEM(s) will 
tend to generate start pendings. 

The solution is to reduce the DEVICE Busy on MVS1 so that it can respond to the 
other image in a "timely" manner.  The other choice is to "live with it". 
   
As indicated above, my plan of attack would be to adjust the MINDORM/MAXHOLD 
values in the JES CKPTDEF, followed by relocating datasets and then the SMF 
processing. 

HTH, 

</snip> 
Allen, this volume is supposed to be online and used to the lpar you asked 
about. It's the sandbox where the IOS071I 4299,**,*MASTER*, START PENDING 680 
occurred. That is where the volumes is offline and not used but where the 
message appeared. Thanks Matt 
<snip> 

---------------------------------------------------------------------- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to [email protected] with the message: INFO IBM-MAIN 

---------------------------------------------------------------------- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to [email protected] with the message: INFO IBM-MAIN 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to