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
