Hi Kevin, i got following Information from support
--- snip --- IT36573 does not occur in the 8.1.12 GA code so no efix is neeeded. When apar closes it will reflect this --- snap --- I updated two instances version 8.1.12 which had shown this error with 8.1.11.100 and the „move container“ operations completed without crashing the dsmserv. Regards, Uwe > Am 30.04.2021 um 16:15 schrieb Kevin Kettner <kevin.kett...@wisc.edu>: > > That's frustrating, conflicting information... I assume your source is from > IBM? I opened a case with IBM on this to get the e-fix and they said that it > is included in 8.1.12. I questioned that because it's not listed in the fixed > APAR list: > > https://www.ibm.com/support/pages/node/6447173 > > This is what the note from IBM says: > > "There is an efix that solved the move container issue for ISP release > 8.1.11.x and I confirmed with development group that the fix was included on > the new ISP release 8.1.12 ( I already had another case with move container > issue fixed with upgrading the ISP server code to release 8.1.12) . > > I am sorry for the inconvenience all the APAR situation has created, we just > want to assure you that the move container issue is solved with the upgrade > to ver ISP 8.1.12" > > I guess I'll upgrade to 8.1.12 and find out. > > -----Original Message----- > From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of Uwe > Schreiber > Sent: Thursday, April 29, 2021 1:32 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] spectrum protect 8.1.11.100 strange behaviour with > dedup pool > > I received the information, that APAR IT36573 is NOT included in 8.1.12. > It is planned to include that APAR in 8.1.12.100 ... so you have to request > an eFix. > > Regards, Uwe > > -----Original Message----- > From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of Kevin > Kettner > Sent: Dienstag, 27. April 2021 23:17 > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] spectrum protect 8.1.11.100 strange behaviour with > dedup pool > > It's not on the fixes list for 8.1.12.000 so I guess that's probably a no. > > https://www.ibm.com/support/pages/node/6447173 > > -----Original Message----- > From: Kevin Kettner > Sent: Tuesday, April 27, 2021 4:02 PM > To: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> > Subject: RE: [ADSM-L] spectrum protect 8.1.11.100 strange behaviour with > dedup pool > > Does anyone know if this eFix is included in 8.1.12.000 that just came out? > > -----Original Message----- > From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of Uwe > Schreiber > Sent: Friday, April 23, 2021 2:12 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] spectrum protect 8.1.11.100 strange behaviour with > dedup pool > > That is related to APAR IT36573. > Michael already mentioned the eFix versions which provide a fix for that > "feature". > > Regards, Uwe > > -----Original Message----- > From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of Michael Prix > Sent: Freitag, 23. April 2021 08:59 > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] spectrum protect 8.1.11.100 strange behaviour with > dedup pool > > Hello, > > that feature is handled in eFix 8.1.11.101, contact IBM to get access to it. > It also affects 8.1.10.200 and is fixed in eFix 8.1.10.204. > > -- > Michael Prix > >> On 4/23/21 8:52 AM, Tsm Tsm wrote: >> Hello, >> >> on my test servers if you move or defragment (automatic) containers >> the spectrum protect application crashes, DB2 service still alive. >> >> ANR0984I Process 2 for Move Container (Automatic) started in the >> BACKGROUND at 02:02:07. >> >> ANR0984I Process 3 for Move Container (Automatic) started in the >> BACKGROUND at 02:02:07. >> >> ANR0984I Process 4 for Move Container (Automatic) started in the >> BACKGROUND at 02:02:07. >> >> ANR0984I Process 5 for Move Container (Automatic) started in the >> BACKGROUND at 02:02:07. >> >> ANR0984I Process 6 for Move Container (Automatic) started in the >> BACKGROUND at 02:02:07. >> >> ANR9999D_1199904567 SdWriteContainer(sdio.c:1588) Thread<207>: >> Improper setup for writing to container 00000058AE36CFB0 (nil) True >> >> ANR9999D Thread<207> issued message 9999 from: >> >> ANR9999D Thread<207> 7ffb7afe5582 OutDiagToCons()+b2 >> >> ANR9999D Thread<207> 7ffb7afde2c2 outDiagfExt()+122 >> >> ANR9999D Thread<207> 7ffb7ad0c943 SdWriteContainer()+483 >> >> ANR9999D Thread<207> 7ffb7ad0d54e SdWrite()+b8e >> >> ANR9999D Thread<207> 7ffb7acf0969 ProcessDefragData()+219 >> >> ANR9999D Thread<207> 7ffb7acef0f8 ProcessStreamBuffer()+238 >> >> ANR9999D Thread<207> 7ffb7aced8b8 SdCntrStreamThread()+14f8 >> >> ANR9999D Thread<207> 7ffb7a2ad2d3 startThread()+5b3 >> >> ANR9999D Thread<207> 7ffba3cdf4a0 o__realloc_base()+60 >> >> ANR9999D Thread<207> 7ffbaf0b13f2 BaseThreadInitThunk()+22 >> >> ANR9999D Thread<207> 7ffbb14254f4 RtlUserThreadStart()+34 >> >> Entering exception handler. >> >> >> anything known about this? before crash many nondedup files going to >> state unavailable. you can audit them successful but the next move >> runs into a failure or server crashes. >> >> with best regards >> Stefan Savoric
