Re: Volume Problem - z/OS 1.4
If you can determine which products or functions in your environment can dynamically alter UCB info, you could start there and place slips traps on them. The first step I would take is to set up an automatic display command (D U,,,xxx,yy) to display all UCBs that have been affected starting at once per hour (or whatever level you are comfortable with) on all LPARs. Then when you get a hit, review syslog and see when the corruption occurred. That way you can narrow the time frame. Next go see what batch jobs or onlines were running during that time frame. What was starting up, shutting down, connecting (like FTP or servers), and what message were produced. Then begin to setup up traces for those functions. Then after you eliminate one, go to the next. Very time consuming but it will eventually shed light on the culprit. The IBM UCB Sniffer is very helpful. If you have products that assist SMS in managing DASD, like PROSMS, you could check with those vender(s) first. Lizette Koehler -- 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: Volume Problem - z/OS 1.4
In a message dated 6/9/2005 8:29:53 A.M. Central Standard Time, [EMAIL PROTECTED] writes: How could the volser get messed up on one LPAR like that? TTOP04 is the correct volser but the first LPAR doesn't indicate that. Anyone seen this before? Somethings overlaying it! Guess I'd start with EREP to see if there were any hardware or software hits in the window. Then check with DASD vendor on uCode levels or known problems relating to VOLSER with SHARED DASD. How current is your Maint? -- 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: Volume Problem - z/OS 1.4
This may seem like an obvious solution, but have you tried to vary the unit offline and online again on the LPAR in error? Richard Habres AVP; Enterprise Storage Technology Merrill Lynch -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Finnell Sent: Thursday, June 09, 2005 10:35 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Volume Problem - z/OS 1.4 In a message dated 6/9/2005 8:29:53 A.M. Central Standard Time, [EMAIL PROTECTED] writes: How could the volser get messed up on one LPAR like that? TTOP04 is the correct volser but the first LPAR doesn't indicate that. Anyone seen this before? Somethings overlaying it! Guess I'd start with EREP to see if there were any hardware or software hits in the window. Then check with DASD vendor on uCode levels or known problems relating to VOLSER with SHARED DASD. How current is your Maint? If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ -- 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: Volume Problem - z/OS 1.4
Bill, looks like the first 4 bytes of UCBVOLI (volume serial in UCB) have been overlaid. IBM info APAR II13210 describes various UCB overlay problems in IBM and ISV code. APAR OA01712 describes a UCBVOLI overlay. If you can vary the device offline and back online on the problem LPAR it will probably resolve the prroblem. However, I see it is allocated, so you may need to see if it is possible to shutdown the applicaitons which have it allocated or tell them to free the device. You can identify them with D U,,ALLOC,3169,1 -- 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: Volume Problem - z/OS 1.4
That is how we solved the problem short term to prevent further batch problems. It happened 2 days in a row on 2 different volumes. Luckily not on volumes that are high impact, yet. EREP is clean. We just applied maintenance 2 months ago. (RSU 1104 plus some additional PTF's beyond that) Bill Johnson Systems Programmer Antares Management Solutions 23700 Commerce Park Rd. Beachwood, Ohio 44122 216-292-0400 x3478 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Habres, Richard (IDS ECCS) Sent: Thursday, June 09, 2005 11:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Volume Problem - z/OS 1.4 This may seem like an obvious solution, but have you tried to vary the unit offline and online again on the LPAR in error? Richard Habres AVP; Enterprise Storage Technology Merrill Lynch -- CONFIDENTIALITY NOTICE: This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure by law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are strictly prohibited from printing, storing, disseminating, distributing or copying this message. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature, unless a specific statement to the contrary is included in this message. Thank you, Antares Management Solutions. == -- 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: Volume Problem - z/OS 1.4
on 6/9/05 9:35 AM, Ed Finnell at [EMAIL PROTECTED] wrote: In a message dated 6/9/2005 8:29:53 A.M. Central Standard Time, [EMAIL PROTECTED] writes: How could the volser get messed up on one LPAR like that? TTOP04 is the correct volser but the first LPAR doesn't indicate that. Anyone seen this before? I have seen this before. Usually an OEM vendor has overlayed a UCB... It used to happen often, haven't seen it in years. Ed ' -- 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
