Re: IEA213A DUPLICATE VOLUME
Gil, Please, pay attention to "human-operated". I did not use MTL intentionally, for the reasons described below. ATL means Automated Tape Library. Sometimes people call it "robot". Sometimes it is VTS. Sometimes VTS don't have physical tapes at backend - so there is no physical robot. ATL could also mean IBM tape library - important for system definitions. Other vendors do not make IBM-compatible ATLs and tend to use MTL definition - Manual Tape Library for their robots and VTLs/VTSes. This is because of system management. However there are real MTLs and real installations with so called stand alone tapes - just bunch of drives operated by human operators. And tons of cartridges on shelves. Just like in the old times of open reels. In this case it is up to operator what tape will be mounted. ...and it is up to RMM (or other TMS) to be a supervisor. However it is perfectly possible to mount "this green cart with label LBL001, you know which one". And the green cart (actually green sticker) can be one of dozen carts labeled as LBL001. How to identify them? Very simple: one is green, the second is almost green, third is also green but there is marker sign "not this one", etc. etc. Ridiculous? Well, my colleague used diskettes in that way. No, instead of stickers he used pencil and coffee stains to identify. Was it working? NO! -- Radoslaw Skorupka Lodz, Poland W dniu 22.11.2020 o 03:57, Paul Gilmartin pisze: On Sun, 22 Nov 2020 02:10:45 +0100, R.S. wrote: IMHO it was the same error as nowadays: bad naming. I didn't work with removable DASD, but I worked with physically removable, human-operated tapes. And it was administrator responsibility to have proper naming convention and unique volume serials. Exceptions in justified scenarios only. That uniqueness might have been enforced more automatically for tape than for DASD because the tape volume serial might need to match the numbered slot in the library. The scenario justifying an exception might be for mass production of products distributed to customers: the volser must match that in the README. I once had a conflict between the volser in our README and a DASD volume. Fortunately, ops was able to dismount that DASD logically long enough for me to write a master tape to send to Manufacturing. An organization (SHARE?) once tried to maintain a world-wide registry of tape volser prefixes. They rapidly exhausted the name space. UUID? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
On Sun, 22 Nov 2020 02:10:45 +0100, R.S. wrote: >IMHO it was the same error as nowadays: bad naming. >I didn't work with removable DASD, but I worked with physically >removable, human-operated tapes. And it was administrator responsibility >to have proper naming convention and unique volume serials. Exceptions >in justified scenarios only. > That uniqueness might have been enforced more automatically for tape than for DASD because the tape volume serial might need to match the numbered slot in the library. The scenario justifying an exception might be for mass production of products distributed to customers: the volser must match that in the README. I once had a conflict between the volser in our README and a DASD volume. Fortunately, ops was able to dismount that DASD logically long enough for me to write a master tape to send to Manufacturing. An organization (SHARE?) once tried to maintain a world-wide registry of tape volser prefixes. They rapidly exhausted the name space. UUID? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
IMHO it was the same error as nowadays: bad naming. I didn't work with removable DASD, but I worked with physically removable, human-operated tapes. And it was administrator responsibility to have proper naming convention and unique volume serials. Exceptions in justified scenarios only. Of course nowadays duplicated DASD volsers are usually (not always) result of volume cloning, which is a little bit different animal. -- Radoslaw Skorupka Lodz, Poland W dniu 22.11.2020 o 00:33, Tony B. pisze: Anyone else out there remember removable DASD, Pizza Ovens and 3340? Having duplicate volsers was more prone to human error at the physical level. On Sat, Nov 21, 2020 at 11:48 AM Jesse 1 Robinson wrote: Your DASD managers are the culprits. As I said in another post, this condition could persist for quite some time until an attempt to vary a duplicate volser online or to IPL. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Lee Sent: Friday, November 20, 2020 2:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IEA213A DUPLICATE VOLUME *** EXTERNAL EMAIL - Use caution when opening links or attachments *** Hi Robinson, Good to know the experience you were with. Ops has a enough time to reply the WTORs in those particular lpars. Those Volumes are 3400/3800/4800 strings, not all of volumes but some of ranges. I need to check with Storage if those has been CLIPped. These messages started coming out from a few last IPL cycles, no messages until the last few IPLs which I think Storage made a change before. Possible solution would be that being allowed to indicate that in the case of a dup, either the HIGHER or LOWER address be put offline in IO Configuration part in IODF when a dup is encountered if the CLIPped is a necessity at their end. == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
I remember before removable DASD, although I skipped from 3330-11 to 3350 without ever using 3340 or 3344. Do you remember when arms moved both vertically and horizontally? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tony B. Sent: Saturday, November 21, 2020 6:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEA213A DUPLICATE VOLUME Anyone else out there remember removable DASD, Pizza Ovens and 3340? Having duplicate volsers was more prone to human error at the physical level. On Sat, Nov 21, 2020 at 11:48 AM Jesse 1 Robinson wrote: > Your DASD managers are the culprits. As I said in another post, this > condition could persist for quite some time until an attempt to vary a > duplicate volser online or to IPL. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Steve Lee > Sent: Friday, November 20, 2020 2:13 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: IEA213A DUPLICATE VOLUME > > *** EXTERNAL EMAIL - Use caution when opening links or attachments *** > > Hi Robinson, > > Good to know the experience you were with. > > Ops has a enough time to reply the WTORs in those particular lpars. > > Those Volumes are 3400/3800/4800 strings, not all of volumes but some of > ranges. > I need to check with Storage if those has been CLIPped. > These messages started coming out from a few last IPL cycles, no messages > until the last few IPLs which I think Storage made a change before. > > Possible solution would be that being allowed to indicate that in the case > of a dup, either the HIGHER or LOWER address be put offline in IO > Configuration part in IODF when a dup is encountered if the CLIPped is a > necessity at their end. > > Thanks, > Steve > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
ITYM as old as OS/360, athough the message number seems to have changed. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Saturday, November 21, 2020 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEA213A DUPLICATE VOLUME I believe that this behavior is as old as OS/VS. I don't understand the logic except that it follows the principle that all connected devices are to be brought online unless specifically excluded in the (nowadays) IODF. It's all a bit counter intuitive considering that what *we* want is a particular volume to be online. Achieving that goal in the face of possibly several duplicate volsers can be daunting. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Smith Sent: Friday, November 20, 2020 2:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IEA213A DUPLICATE VOLUME *** EXTERNAL EMAIL - Use caution when opening links or attachments *** I wonder why the message asks for the unit to be kept *offline*. Seems like the inverse would be more logical. And what if you have ten volumes all named the same? Yes, this is merely a Friday curiosity. Presumably, the age-old maxim, "If it hurts, stop doing it" would cover most practical situations. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
Don't go there. Use STARTIO. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Brennan Sent: Saturday, November 21, 2020 2:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEA213A DUPLICATE VOLUME Yep... Surprise! Usually in the middle of the night. I wonder if anyone has written a program that can check for duplicates in advance of the IPL. I would guess such code would have to run its own SSCH instructions. On 11/21/2020 9:48 AM, Jesse 1 Robinson wrote: > Your DASD managers are the culprits. As I said in another post, this > condition could persist for quite some time until an attempt to vary a > duplicate volser online or to IPL. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Steve Lee > Sent: Friday, November 20, 2020 2:13 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: IEA213A DUPLICATE VOLUME > > *** EXTERNAL EMAIL - Use caution when opening links or attachments *** > > Hi Robinson, > > Good to know the experience you were with. > > Ops has a enough time to reply the WTORs in those particular lpars. > > Those Volumes are 3400/3800/4800 strings, not all of volumes but some of > ranges. > I need to check with Storage if those has been CLIPped. > These messages started coming out from a few last IPL cycles, no messages > until the last few IPLs which I think Storage made a change before. > > Possible solution would be that being allowed to indicate that in the case of > a dup, either the HIGHER or LOWER address be put offline in IO Configuration > part in IODF when a dup is encountered if the CLIPped is a necessity at their > end. > > Thanks, > Steve > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
Anyone else out there remember removable DASD, Pizza Ovens and 3340? Having duplicate volsers was more prone to human error at the physical level. On Sat, Nov 21, 2020 at 11:48 AM Jesse 1 Robinson wrote: > Your DASD managers are the culprits. As I said in another post, this > condition could persist for quite some time until an attempt to vary a > duplicate volser online or to IPL. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Steve Lee > Sent: Friday, November 20, 2020 2:13 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: IEA213A DUPLICATE VOLUME > > *** EXTERNAL EMAIL - Use caution when opening links or attachments *** > > Hi Robinson, > > Good to know the experience you were with. > > Ops has a enough time to reply the WTORs in those particular lpars. > > Those Volumes are 3400/3800/4800 strings, not all of volumes but some of > ranges. > I need to check with Storage if those has been CLIPped. > These messages started coming out from a few last IPL cycles, no messages > until the last few IPLs which I think Storage made a change before. > > Possible solution would be that being allowed to indicate that in the case > of a dup, either the HIGHER or LOWER address be put offline in IO > Configuration part in IODF when a dup is encountered if the CLIPped is a > necessity at their end. > > Thanks, > Steve > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
On Sat, 21 Nov 2020 11:23:31 -0800, Tom Brennan wrote: No, I had IBM enhance the DEVSERV command a number of years back so that you can enter a command such as DS QD,,256,OFFLINE to see the volume serial numbers of offline volumes. The corresponding ONLINE command would show the online volumes, so one could check for duplicates. >Yep... Surprise! Usually in the middle of the night. > >I wonder if anyone has written a program that can check for duplicates >in advance of the IPL. I would guess such code would have to run its >own SSCH instructions. > >On 11/21/2020 9:48 AM, Jesse 1 Robinson wrote: >> Your DASD managers are the culprits. As I said in another post, this >> condition could persist for quite some time until an attempt to vary a >> duplicate volser online or to IPL. >> >> . >> . >> J.O.Skip Robinson >> Southern California Edison Company >> Electric Dragon Team Paddler >> SHARE MVS Program Co-Manager >> 323-715-0595 Mobile >> 626-543-6132 Office ⇐=== NEW >> robin...@sce.com >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Steve Lee >> Sent: Friday, November 20, 2020 2:13 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: (External):Re: IEA213A DUPLICATE VOLUME >> >> *** EXTERNAL EMAIL - Use caution when opening links or attachments *** >> >> Hi Robinson, >> >> Good to know the experience you were with. >> >> Ops has a enough time to reply the WTORs in those particular lpars. >> >> Those Volumes are 3400/3800/4800 strings, not all of volumes but some of >> ranges. >> I need to check with Storage if those has been CLIPped. >> These messages started coming out from a few last IPL cycles, no messages >> until the last few IPLs which I think Storage made a change before. >> >> Possible solution would be that being allowed to indicate that in the case >> of a dup, either the HIGHER or LOWER address be put offline in IO >> Configuration part in IODF when a dup is encountered if the CLIPped is a >> necessity at their end. >> >> Thanks, >> Steve >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
Yep... Surprise! Usually in the middle of the night. I wonder if anyone has written a program that can check for duplicates in advance of the IPL. I would guess such code would have to run its own SSCH instructions. On 11/21/2020 9:48 AM, Jesse 1 Robinson wrote: Your DASD managers are the culprits. As I said in another post, this condition could persist for quite some time until an attempt to vary a duplicate volser online or to IPL. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Lee Sent: Friday, November 20, 2020 2:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IEA213A DUPLICATE VOLUME *** EXTERNAL EMAIL - Use caution when opening links or attachments *** Hi Robinson, Good to know the experience you were with. Ops has a enough time to reply the WTORs in those particular lpars. Those Volumes are 3400/3800/4800 strings, not all of volumes but some of ranges. I need to check with Storage if those has been CLIPped. These messages started coming out from a few last IPL cycles, no messages until the last few IPLs which I think Storage made a change before. Possible solution would be that being allowed to indicate that in the case of a dup, either the HIGHER or LOWER address be put offline in IO Configuration part in IODF when a dup is encountered if the CLIPped is a necessity at their end. Thanks, Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
Your DASD managers are the culprits. As I said in another post, this condition could persist for quite some time until an attempt to vary a duplicate volser online or to IPL. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Lee Sent: Friday, November 20, 2020 2:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IEA213A DUPLICATE VOLUME *** EXTERNAL EMAIL - Use caution when opening links or attachments *** Hi Robinson, Good to know the experience you were with. Ops has a enough time to reply the WTORs in those particular lpars. Those Volumes are 3400/3800/4800 strings, not all of volumes but some of ranges. I need to check with Storage if those has been CLIPped. These messages started coming out from a few last IPL cycles, no messages until the last few IPLs which I think Storage made a change before. Possible solution would be that being allowed to indicate that in the case of a dup, either the HIGHER or LOWER address be put offline in IO Configuration part in IODF when a dup is encountered if the CLIPped is a necessity at their end. Thanks, Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
I believe that this behavior is as old as OS/VS. I don't understand the logic except that it follows the principle that all connected devices are to be brought online unless specifically excluded in the (nowadays) IODF. It's all a bit counter intuitive considering that what *we* want is a particular volume to be online. Achieving that goal in the face of possibly several duplicate volsers can be daunting. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Smith Sent: Friday, November 20, 2020 2:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IEA213A DUPLICATE VOLUME *** EXTERNAL EMAIL - Use caution when opening links or attachments *** I wonder why the message asks for the unit to be kept *offline*. Seems like the inverse would be more logical. And what if you have ten volumes all named the same? Yes, this is merely a Friday curiosity. Presumably, the age-old maxim, "If it hurts, stop doing it" would cover most practical situations. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
On 2020-11-20 1:18 PM, Steve Lee wrote: IEA213A DUPLICATE VOLUME 'RP@C03' FOUND ON DEVICES 3404 AND 4802. IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE My memory is that you could even get these messages re duplicate volsers for the IPL volume. 3 guesses as to which one we wanted to keep - the answer being the one we were IPLing from. At least the Fujitsu MVS-like OS would simply issue a message reporting which device was being put offline without requiring human instruction. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
Hi Robinson, Good to know the experience you were with. Ops has a enough time to reply the WTORs in those particular lpars. Those Volumes are 3400/3800/4800 strings, not all of volumes but some of ranges. I need to check with Storage if those has been CLIPped. These messages started coming out from a few last IPL cycles, no messages until the last few IPLs which I think Storage made a change before. Possible solution would be that being allowed to indicate that in the case of a dup, either the HIGHER or LOWER address be put offline in IO Configuration part in IODF when a dup is encountered if the CLIPped is a necessity at their end. Thanks, Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
I wonder why the message asks for the unit to be kept *offline*. Seems like the inverse would be more logical. And what if you have ten volumes all named the same? Yes, this is merely a Friday curiosity. Presumably, the age-old maxim, "If it hurts, stop doing it" would cover most practical situations. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
Note that the prohibition against duplicate volsers affects only *online* volumes. It does not apply to volumes that simply happen to be physically/logically connected. If a volume is CLIPped to a volser matching one already online, there is no error posted at that time. This condition can last indefinitely until V ONLINE is attempted or an IPL in initiated. In the case of V ONLINE, the action will fail and require correction. The insidious problem is attempting to IPL with dups. IPL will stop at each and every dup encountered. I've seen cases where an entire 'string' of DASD was overlooked in the final step of moving DASD volumes from one location to another. Unless you have an already running system to work from, Operator has to reply to IEA213A enough times to get past the dups. If the IPL needs to be restarted for any reason, then the same replies have to be reentered. I have suggested (without a formal requirement) that the installation be allowed to indicate that in the case of a dup, either the HIGHER or LOWER address be put offline when a dup is encountered. That would handle most cases well enough to get a running system. Meanwhile... . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Lee Sent: Friday, November 20, 2020 9:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IEA213A DUPLICATE VOLUME *** EXTERNAL EMAIL - Use caution when opening links or attachments *** Thanks Mark. Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
Thanks Mark. Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
Thanks Mike, I have been waiting for the follow-up steps with Storage guys and will be updated back here. Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
Hi, Thank you for the explanation on this, it's very informative at this moment. I have been waiting for the follow-up steps with Storage guys and will be update back here. Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
W dniu 20.11.2020 o 03:08, Steve Lee pisze: Dear, These messages come out at the time of IPL in past few IPL cycle; IEA213A DUPLICATE VOLUME 'RP@C03' FOUND ON DEVICES 3404 AND 4802. IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE IEA213A DUPLICATE VOLUME 'RP@C04' FOUND ON DEVICES 3405 AND 4803. IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE IEA213A DUPLICATE VOLUME 'RP@C05' FOUND ON DEVICES 3406 AND 4804. IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE ~ ~ My Research: When systems starts initialization after loading it makes some set of volumes needs to be offline due to saem volume label. (In IODF part, all volumes listed above are "Offline=No") Some of the volumes on these system has duplicate volume labels defined to them, While making these volume offline system gets confused and generates these WTORs to ask the operator which one to make offline when it finds two volumes has same volume label. There has not been changes to IODF. Storage team can give more clarification about these volumes gets assigned with duplicate volume labels. But they are also confused why it happens. Any input will greatly be appreciated. Short explanation: During IPL z/OS scan all the volumes defined as ONLINE. Duplicates are not allowed, so operator has to decide which one to KILL (vary offline). Of course at the time there are no ISPF or other means to easily check wich one is "better" or rather which one should be used. Note: duplicate volser could mean just another volume with completely unrelated content, but likely it is a copy of the volume with same name. In this case it is very hard to find out which is copy, which is original and which volume to use. Ask author of the copy! Note: volumes are defined as available and further available volumes are defined as ONLINE in OS Config part of IODF. And this is solution to separate "primary" set of volumes and the clone set. OS Config PRIM will make cloned addresses as unavailable or just OFFLINE. OS Config CLONE will make primary volumes unavailable, but cloned volumes as ONLINE. And voila - simple Flashcopy (Shadowimage, TF/Clone...) and you have clone of your system and the clone can be IPLed with few changes in LOADxx member. Note2: A person who makes volume copies should be aware of OS Config settings and generally should avoid scenarios like yours. It just mistake made by the person. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
You assign the volume label with ICKDSF. If you init two+ different devices with the same volser and the default for both+ is to be online you will get this message. Since these addresses are quite a bit apart, is one production and one a DR test? If so the Production system should set the address offline or not existing, and the DR system should set the production system addresses as offline or not existing. On Thu, Nov 19, 2020 at 8:18 PM Steve Lee <0353a875f81e-dmarc-requ...@listserv.ua.edu> wrote: > > Dear, > > These messages come out at the time of IPL in past few IPL cycle; > > IEA213A DUPLICATE VOLUME 'RP@C03' FOUND ON DEVICES 3404 AND 4802. > IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE > IEA213A DUPLICATE VOLUME 'RP@C04' FOUND ON DEVICES 3405 AND 4803. > IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE > IEA213A DUPLICATE VOLUME 'RP@C05' FOUND ON DEVICES 3406 AND 4804. > IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE > ~ > ~ > > > > My Research: > > When systems starts initialization after loading it makes some set of volumes > needs to be offline due to saem volume label. > (In IODF part, all volumes listed above are "Offline=No") > Some of the volumes on these system has duplicate volume labels defined to > them, While making these volume offline system gets confused and generates > these WTORs to ask the operator which one to make offline when it finds two > volumes has same volume label. > > There has not been changes to IODF. Storage team can give more clarification > about these volumes gets assigned with duplicate volume labels. > But they are also confused why it happens. > > > Any input will greatly be appreciated. > > Thanks, > Steve > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEA213A DUPLICATE VOLUME
Your research is correct. The system is working as designed. Duplicate volumes with the same VOLSER are not allowed to be online at the same time, so it's asking the operator which one needs to be online. As far as your question why are there duplicates, that answer needs to be ascertained from the storage team. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Thursday, November 19th, 2020 at 9:08 PM, Steve Lee <0353a875f81e-dmarc-requ...@listserv.ua.edu> wrote: > Dear, > > These messages come out at the time of IPL in past few IPL cycle; > > IEA213A DUPLICATE VOLUME 'RP@C03' FOUND ON DEVICES 3404 AND 4802. > > IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE > > IEA213A DUPLICATE VOLUME 'RP@C04' FOUND ON DEVICES 3405 AND 4803. > > IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE > > IEA213A DUPLICATE VOLUME 'RP@C05' FOUND ON DEVICES 3406 AND 4804. > > IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE > > ~ > > ~ > > My Research: > > When systems starts initialization after loading it makes some set of volumes > needs to be offline due to saem volume label. > > (In IODF part, all volumes listed above are "Offline=No") > > Some of the volumes on these system has duplicate volume labels defined to > them, While making these volume offline system gets confused and generates > these WTORs to ask the operator which one to make offline when it finds two > volumes has same volume label. > > There has not been changes to IODF. Storage team can give more clarification > about these volumes gets assigned with duplicate volume labels. > > But they are also confused why it happens. > > Any input will greatly be appreciated. > > Thanks, > > Steve > > --- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IEA213A DUPLICATE VOLUME
Dear, These messages come out at the time of IPL in past few IPL cycle; IEA213A DUPLICATE VOLUME 'RP@C03' FOUND ON DEVICES 3404 AND 4802. IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE IEA213A DUPLICATE VOLUME 'RP@C04' FOUND ON DEVICES 3405 AND 4803. IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE IEA213A DUPLICATE VOLUME 'RP@C05' FOUND ON DEVICES 3406 AND 4804. IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE ~ ~ My Research: When systems starts initialization after loading it makes some set of volumes needs to be offline due to saem volume label. (In IODF part, all volumes listed above are "Offline=No") Some of the volumes on these system has duplicate volume labels defined to them, While making these volume offline system gets confused and generates these WTORs to ask the operator which one to make offline when it finds two volumes has same volume label. There has not been changes to IODF. Storage team can give more clarification about these volumes gets assigned with duplicate volume labels. But they are also confused why it happens. Any input will greatly be appreciated. Thanks, Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
