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
