Re: MIM control file volume DASD lockout
In a message dated 3/7/2007 4:47:23 P.M. Central Standard Time, David.A.Wright @ DOM.COM writes: >We have been getting MIM control file lockouts for almost a year. We have been working with STK (the DASD manufacturer), IBM and CA (MIM). So far, nothing has resolved the problem. I discovered the hard way once that there is no such thing as a "standalone test system." I tested some software on a test system, my code crashed the system just after its JES2 had gotten the checkpoint data set lock, the checkpoint and all SPOOL was shared (of course) with the production systems. You could be having some unexpected interference from any of the systems sharing the device with the MIM data set on it if there is any other allocated data on it. The start pending messages probably mean that some other system has the device reserved. First make sure there are no data sets on the device other than the MIM file. Next try to determine which LPAR has reserved the device, if any. Once you know which LPAR holds the reserve (if any), then you can work on resolving why that LPAR has not released the device. If no LPAR has reserved the device, then I agree with STK - there is/are probably bug(s) in the channel subsystem of one or more of the LPARs. If you can gather a GTF trace of all I/O events involving the device in question from all LPARs during the time of the lockout, I will be happy to study them and try to help resolve the problem. Reply to me privately if interested. Bill Fairchild Plainfield, IL "Criticism and dissent are the indispensable antidote to major delusions." [Alan Barth, 1951; The Loyalty of Free Men] ** AOL now offers free email to everyone. Find out more about what's free from AOL at http://www.aol.com. -- 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: MIM control file volume DASD lockout
>Check the MIM task WLM class. MIM should always at least be in SYSSTC. I worked at one shop where it was 'converted' to SYSTEM using IEFSSN8xx. But, you also have to be aware of it being 'dragged' down by being in an LPAR with a small weight. You can also look at its values for how long and how often it grabs the control file. But, I would tend towards using CTC's, we did that successfully about 5 years ago with two SYSPLEX's: PROD and TEST within the same MIMPLEX. The best approach would be to isolate the PROD and TEST SYSPLEX's. Then, most of this should go away. - Too busy driving to stop for gas! -- 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: MIM control file volume DASD lockout
I would be willing to look at the other side of the MIM-Plex. The Start Pendings are an indication that someone has the volume in reserve status, and the issuer is waiting on the reserve to be terminated. What is going on outside of the TEST-Plex while this issue is happening? On Mon, 26 Feb 2007 15:58:55 -0500, Bruce Black <[EMAIL PROTECTED]> wrote: >> >> The lockout last for either a few seconds, or a few minutes. Never >> >> >> more that 20 minutes. >In that case I agree with Mark Zelden: if the MIM task is not getting >cycles, it could RESERVE the file and then take time to release it. > >Is this test LPAR capped a low value? This limits the cycles available >to the LPAR and if there are other higher priority tasks running it >might have this effect. > >Or, if there is some higher priority task that goes into a periodic CPU >loop, or even a combination of busy tasks, they could prevent the MIM >task from getting cycles. Check the MIM task WLM class. -- 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: MIM control file volume DASD lockout
The lockout last for either a few seconds, or a few minutes. Never more that 20 minutes. In that case I agree with Mark Zelden: if the MIM task is not getting cycles, it could RESERVE the file and then take time to release it. Is this test LPAR capped a low value? This limits the cycles available to the LPAR and if there are other higher priority tasks running it might have this effect. Or, if there is some higher priority task that goes into a periodic CPU loop, or even a combination of busy tasks, they could prevent the MIM task from getting cycles. Check the MIM task WLM class. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: MIM control file volume DASD lockout
Hi Bruce: The lockout last for either a few seconds, or a few minutes. Never more that 20 minutes. We will get the @MIM0100A File 00 - possible lockout 31EA MPM000 messages. Occasionally they are accompanied by IOS071I 31EA,**,*MASTER*, START PENDING messages. Thanks, _ David A. Wright Dominion Resources Services, Inc. One James River Plaza Enterprise Operations-IT Systems Programming IT-DP/OJRP-10 Richmond, VA 23219 Tie Line: 8-736-3354 Pager: (804) 273-3030 #2942 Phone: (804) 771-3354 Fax:(804) 771-6146 Email: [EMAIL PROTECTED] Bruce Black <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 02/26/2007 03:01 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Re: MIM control file volume DASD lockout David, when you say "lockout" do you mean a permanent hang? or does it eventually come out of it by itself? If permanent, what do you have to do to get out of the hang? -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com - CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- 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: MIM control file volume DASD lockout
David, when you say "lockout" do you mean a permanent hang? or does it eventually come out of it by itself? If permanent, what do you have to do to get out of the hang? -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: MIM control file volume DASD lockout
On 26 Feb 2007 06:46:29 -0800, in bit.listserv.ibm-main (Message-ID:<[EMAIL PROTECTED]>) [EMAIL PROTECTED] (David A. Wright) wrote: We have been getting MIM control file lockouts for almost a year. We have been working with STK (the DASD manufacturer), IBM and CA (MIM). So far, nothing has resolved the problem. It usually occurs on the weekends, on our test systems, when all the other systems are fairly quiet. Occasionaly, we will also get start pendning messages. This issue only occurs for a few seconds, or upto a few minutes. It always clears itself up without operator intervention. Here are some elementary questions that you've probably already investigated: Is there any kind of DASD management or DASD cleanup which runs on the weekends that might reserve the volume? Have you tried turning off type SMF records which have been known to cause occasional DASD performance problems? -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur "at" intergate "dot" com -- 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: MIM control file volume DASD lockout
Here is a little procedure how to find who (job) holds a DASD volume RESERVE (that we automated over here): Search for the following msgs pairs on system experiencing delays: IOS071I 09FA,**,*MASTER*, START PENDING IOS431I DEVICE 09FA RESERVED TO CPU=serial9672,LPAR ID=UNKNOWN .Identify the CPU/CPC from IOS431I msg. On every LPAR on that CPU issue command: D GRS,DEV=9FA On LPAR holding the RESERVE you will see msgs like: ISG343I 11.28.13 GRS STATUS DEVICE:09FA VOLUME:TEST06 RESERVED BY SYSTEM sysname S=SYSTEM SYSVTOC TEST06 SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUS sysname MGIP141 00DC 008DB9D8 EXCLUSIVE OWN Hth... -- 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: FW: MIM control file volume DASD lockout
On Mon, 26 Feb 2007 13:29:18 -0500, David A. Wright wrote: >The volume where the control file resides is backed up to tape >once a day with FDR. Why are you backing up the volume once a day when the only thing on it is the MIM control file? The contents of the file should be varying so much that any backup would only provide the VTOC and dataset sizing information (and not really reflect the contents at the moment of any failure). I would just take the most recent backup, declare it to be "forever" and stop taking newer backups. If you feel the urge either (a) take a quarterly backup or better yet (b) lie down & rest until that urge passes. -- Tom Schmidt Madison, WI -- 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: MIM control file volume DASD lockout
Hi Sam: We share DASD across two SYSPLEXs, so the coupling facility won't help us. Thanks, _ David A. Wright Dominion Resources Services, Inc. One James River Plaza Enterprise Operations-IT Systems Programming IT-DP/OJRP-10 Richmond, VA 23219 Tie Line: 8-736-3354 Pager: (804) 273-3030 #2942 Phone: (804) 771-3354 Fax:(804) 771-6146 Email: [EMAIL PROTECTED] "Knutson, Sam" <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 02/26/2007 01:51 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Re: MIM control file volume DASD lockout I don't know much about MIM but as the doctor says "then don't do that"... Have you considered to get away from the DASD control file as the primary control file? If the sharing is all inside the scope of a parallel Sysplex you could use list structures in a coupling facility. This is what we do though admittedly we only use MIA as we are using only GRS for serialization and never used MIC. If not Coupling Facility then perhaps you could use CTCONLY. *==* * FOR COMMUNICATION METHODS DASDONLY AND CTCDASD, * DYNAMICALLY ALLOCATE CONTROL FILES IF MIMTBL00 AND MIMTBL01 * ARE COMMENTED OUT OF MIMPROC, OR USE COUPLING FACILITY * LIST STRUCTURE CONTROL FILES *==* * ALLOCATE XESFILEID=00 STRNAME=(MIMGR#TABLE00) ALLOCATE XESFILEID=01 STRNAME=(MIMGR#TABLE01) ALLOCATE DDNAME=MIMTBL02,DSNAME=SYSOP.MIMGTAF.CF02 ALLOCATE DDNAME=MIMTBL03,DSNAME=SYSOP.MIMGTAF.CF03 * Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David A. Wright Sent: Monday, February 26, 2007 1:33 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: MIM control file volume DASD lockout Hi Mark: We start all of our MIMGR address spaces through MIMASC. We have taken GTF traces, at STKs recommendations. We have not taken a system dump, because STK feels that the problem is in the channel subsystem. Thanks, _ David A. Wright Dominion Resources Services, Inc. One James River Plaza Enterprise Operations-IT Systems Programming IT-DP/OJRP-10 Richmond, VA 23219 Tie Line: 8-736-3354 Pager: (804) 273-3030 #2942 Phone: (804) 771-3354 Fax:(804) 771-6146 Email: [EMAIL PROTECTED] - CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- 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: MIM control file volume DASD lockout
I don't know much about MIM but as the doctor says "then don't do that"... Have you considered to get away from the DASD control file as the primary control file? If the sharing is all inside the scope of a parallel Sysplex you could use list structures in a coupling facility. This is what we do though admittedly we only use MIA as we are using only GRS for serialization and never used MIC. If not Coupling Facility then perhaps you could use CTCONLY. *==* * FOR COMMUNICATION METHODS DASDONLY AND CTCDASD, * DYNAMICALLY ALLOCATE CONTROL FILES IF MIMTBL00 AND MIMTBL01 * ARE COMMENTED OUT OF MIMPROC, OR USE COUPLING FACILITY * LIST STRUCTURE CONTROL FILES *==* * ALLOCATE XESFILEID=00 STRNAME=(MIMGR#TABLE00) ALLOCATE XESFILEID=01 STRNAME=(MIMGR#TABLE01) ALLOCATE DDNAME=MIMTBL02,DSNAME=SYSOP.MIMGTAF.CF02 ALLOCATE DDNAME=MIMTBL03,DSNAME=SYSOP.MIMGTAF.CF03 * Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David A. Wright Sent: Monday, February 26, 2007 1:33 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: MIM control file volume DASD lockout Hi Mark: We start all of our MIMGR address spaces through MIMASC. We have taken GTF traces, at STKs recommendations. We have not taken a system dump, because STK feels that the problem is in the channel subsystem. Thanks, _ David A. Wright Dominion Resources Services, Inc. One James River Plaza Enterprise Operations-IT Systems Programming IT-DP/OJRP-10 Richmond, VA 23219 Tie Line: 8-736-3354 Pager: (804) 273-3030 #2942 Phone: (804) 771-3354 Fax:(804) 771-6146 Email: [EMAIL PROTECTED] This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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: MIM control file volume DASD lockout
Hi Mark: We start all of our MIMGR address spaces through MIMASC. We have taken GTF traces, at STKs recommendations. We have not taken a system dump, because STK feels that the problem is in the channel subsystem. Thanks, _ David A. Wright Dominion Resources Services, Inc. One James River Plaza Enterprise Operations-IT Systems Programming IT-DP/OJRP-10 Richmond, VA 23219 Tie Line: 8-736-3354 Pager: (804) 273-3030 #2942 Phone: (804) 771-3354 Fax:(804) 771-6146 Email: [EMAIL PROTECTED] Mark Zelden <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 02/26/2007 01:26 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Re: MIM control file volume DASD lockout On Mon, 26 Feb 2007 13:17:36 -0500, David A. Wright <[EMAIL PROTECTED]> wrote: >Hi Bruce: > >The control file is on single volume all by itself. > > The problem always originates from one of our test systems in our >Test SYSPLEX. > >The D U command shows nothing. > >MIM and z/OS levels have been verified. > >Thanks, Have you tried taking a dump while the problem was happening? One other thought... is MIM in SYSSTC or started as via MIMASC so it can run in SYSTEM on your test sysplex? In other words, if the test LPARs are running "hot" can MIM get enough cycles to process what it needs to process? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html - CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- 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: FW: MIM control file volume DASD lockout
Hi Jay: No, we don't use HSM, we use CA-Disk. The volume where the control file resides is backed up to tape once a day with FDR. Thanks, _ David A. Wright Dominion Resources Services, Inc. One James River Plaza Enterprise Operations-IT Systems Programming IT-DP/OJRP-10 Richmond, VA 23219 Tie Line: 8-736-3354 Pager: (804) 273-3030 #2942 Phone: (804) 771-3354 Fax:(804) 771-6146 Email: [EMAIL PROTECTED] "Campbell Jay" <[EMAIL PROTECTED]> 02/26/2007 01:24 PM To <[EMAIL PROTECTED]> cc Subject FW: MIM control file volume DASD lockout Do you use HSM and does this pack get backed up ? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David A. Wright Sent: Monday, February 26, 2007 1:18 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: MIM control file volume DASD lockout Hi Bruce: The control file is on single volume all by itself. The problem always originates from one of our test systems in our Test SYSPLEX. The D U command shows nothing. MIM and z/OS levels have been verified. Thanks, _ David A. Wright Dominion Resources Services, Inc. One James River Plaza Enterprise Operations-IT Systems Programming IT-DP/OJRP-10 Richmond, VA 23219 Tie Line: 8-736-3354 Pager: (804) 273-3030 #2942 Phone: (804) 771-3354 Fax:(804) 771-6146 Email: [EMAIL PROTECTED] Bruce Black <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 02/26/2007 12:13 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Re: MIM control file volume DASD lockout > > We have been getting MIM control file lockouts for almost a year. We have > been working with STK (the DASD manufacturer), IBM and CA (MIM). So far, > nothing has resolved the problem. It usually occurs on the weekends, on > our test systems, when all the other systems are fairly quiet. > Occasionally, we will also get start pending messages. > > This issue only occurs for a few seconds, or up to a few minutes. It always > clears itself up without operator intervention. > > We have 8 LPARs, with MIM running on each LPAR. > > We are running on an IBM 2064-105. The DASD is an STK MODEL V2XF. > > Has anyone else experienced this problem? How was it resolved? No, I have never experienced it but I have some thoughts. However, I would be surprised if these haven't been suggested by one or more vendors. * do you have any other datasets on the same volume as the control file? * can you identify the system holding the RESERVE? Is it always the same system? Anything unusual about the z/OS or MIM level on that system? * on the system holding the RESERVE, does a console D U command show the device as RESERVED (-R)? This would imply a software error (RESERVE with no DEQ to release it). -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com - CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- 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: MIM control file volume DASD lockout
On Mon, 26 Feb 2007 13:17:36 -0500, David A. Wright <[EMAIL PROTECTED]> wrote: >Hi Bruce: > >The control file is on single volume all by itself. > > The problem always originates from one of our test systems in our >Test SYSPLEX. > >The D U command shows nothing. > >MIM and z/OS levels have been verified. > >Thanks, Have you tried taking a dump while the problem was happening? One other thought... is MIM in SYSSTC or started as via MIMASC so it can run in SYSTEM on your test sysplex? In other words, if the test LPARs are running "hot" can MIM get enough cycles to process what it needs to process? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: MIM control file volume DASD lockout
Hi Bruce: The control file is on single volume all by itself. The problem always originates from one of our test systems in our Test SYSPLEX. The D U command shows nothing. MIM and z/OS levels have been verified. Thanks, _ David A. Wright Dominion Resources Services, Inc. One James River Plaza Enterprise Operations-IT Systems Programming IT-DP/OJRP-10 Richmond, VA 23219 Tie Line: 8-736-3354 Pager: (804) 273-3030 #2942 Phone: (804) 771-3354 Fax:(804) 771-6146 Email: [EMAIL PROTECTED] Bruce Black <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 02/26/2007 12:13 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Re: MIM control file volume DASD lockout > > We have been getting MIM control file lockouts for almost a year. We have > been working with STK (the DASD manufacturer), IBM and CA (MIM). So far, > nothing has resolved the problem. It usually occurs on the weekends, on > our test systems, when all the other systems are fairly quiet. > Occasionally, we will also get start pending messages. > > This issue only occurs for a few seconds, or up to a few minutes. It always > clears itself up without operator intervention. > > We have 8 LPARs, with MIM running on each LPAR. > > We are running on an IBM 2064-105. The DASD is an STK MODEL V2XF. > > Has anyone else experienced this problem? How was it resolved? No, I have never experienced it but I have some thoughts. However, I would be surprised if these haven't been suggested by one or more vendors. * do you have any other datasets on the same volume as the control file? * can you identify the system holding the RESERVE? Is it always the same system? Anything unusual about the z/OS or MIM level on that system? * on the system holding the RESERVE, does a console D U command show the device as RESERVED (-R)? This would imply a software error (RESERVE with no DEQ to release it). -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com - CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- 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: MIM control file volume DASD lockout
Hi Mark: We have to SYSPLEXs, with a MIM address space running on all 8 LPARs. The control file is on it's own volume all by itself. We share DASD amongst all 8 LPARs. This problem always originates from the test SYSPLEX systems. Thanks, _ David A. Wright Dominion Resources Services, Inc. One James River Plaza Enterprise Operations-IT Systems Programming IT-DP/OJRP-10 Richmond, VA 23219 Tie Line: 8-736-3354 Pager: (804) 273-3030 #2942 Phone: (804) 771-3354 Fax:(804) 771-6146 Email: [EMAIL PROTECTED] On Mon, 26 Feb 2007 08:46:23 -0600, David A. Wright <[EMAIL PROTECTED]> wrote: >Hello: > >We have been getting MIM control file lockouts for almost a year. We have >been working with STK (the DASD manufacturer), IBM and CA (MIM). So far, >nothing has resolved the problem. It usually occurs on the weekends, on >our test systems, when all the other systems are fairly quiet. >Occasionally, we will also get start pending messages. > >This issue only occurs for a few seconds, or up to a few minutes. It always >clears itself up without operator intervention. > >We have 8 LPARs, with MIM running on each LPAR. > >We are running on an IBM 2064-105. The DASD is an STK MODEL V2XF. > >Has anyone else experienced this problem? How was it resolved? > Have not seen this... but we have been running CTCONLY for years. Are the test systems part of the same MIMplex? Are the control files on their own dasd volumes? Do any non-MIMplex LPARs share the same dasd (a sandbox for example)? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html - CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- 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: MIM control file volume DASD lockout
We have been getting MIM control file lockouts for almost a year. We have been working with STK (the DASD manufacturer), IBM and CA (MIM). So far, nothing has resolved the problem. It usually occurs on the weekends, on our test systems, when all the other systems are fairly quiet. Occasionaly, we will also get start pendning messages. This issue only occurs for a few seconds, or upto a few minutes. It always clears itself up without operator intervention. We have 8 LPARs, with MIM running on each LPAR. We are running on an IBM 2064-105. The DASD is an STK MODEL V2XF. Has anyone else experienced this problem? How was it resolved? No, I have never experienced it but I have some thoughts. However, I would be surprised if these haven't been suggested by one or more vendors. * do you have any other datasets on the same volume as the control file? * can you identify the system holding the RESERVE? Is it always the same system? Anything unusual about the z/OS or MIM level on that system? * on the system holding the RESERVE, does a console D U command show the device as RESERVED (-R)? This would imply a software error (RESERVE with no DEQ to release it). -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: MIM control file volume DASD lockout
On Mon, 26 Feb 2007 08:46:23 -0600, David A. Wright <[EMAIL PROTECTED]> wrote: >Hello: > >We have been getting MIM control file lockouts for almost a year. We have >been working with STK (the DASD manufacturer), IBM and CA (MIM). So far, >nothing has resolved the problem. It usually occurs on the weekends, on >our test systems, when all the other systems are fairly quiet. >Occasionaly, we will also get start pendning messages. > >This issue only occurs for a few seconds, or upto a few minutes. It always >clears itself up without operator intervention. > >We have 8 LPARs, with MIM running on each LPAR. > >We are running on an IBM 2064-105. The DASD is an STK MODEL V2XF. > >Has anyone else experienced this problem? How was it resolved? > Have not seen this... but we have been running CTCONLY for years. Are the test systems part of the same MIMplex? Are the control files on their own dasd volumes? Do any non-MIMplex LPARs share the same dasd (a sandbox for example)? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
MIM control file volume DASD lockout
Hello: We have been getting MIM control file lockouts for almost a year. We have been working with STK (the DASD manufacturer), IBM and CA (MIM). So far, nothing has resolved the problem. It usually occurs on the weekends, on our test systems, when all the other systems are fairly quiet. Occasionaly, we will also get start pendning messages. This issue only occurs for a few seconds, or upto a few minutes. It always clears itself up without operator intervention. We have 8 LPARs, with MIM running on each LPAR. We are running on an IBM 2064-105. The DASD is an STK MODEL V2XF. Has anyone else experienced this problem? How was it resolved? Thank you. -- 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
