Hi Kevin, i received an eFix for APAR IT36573 (8.1.11.101).
In addition I assume, you are talking about APAR IT3677: THE IBM SPECTRUM PROTECT SERVER MIGHT NOT START AFTER UPGRADE TO 8.1.12 https://www.ibm.com/support/pages/apar/IT36777?cm_sp=swgtiv-_-OCSSGSG7-_-E&mync=E&mynp=OCSSGSG7&myns=swgtiv Regards, Uwe -----Original Message----- From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of Kevin Kettner Sent: Donnerstag, 13. Mai 2021 17:55 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] spectrum protect 8.1.11.100 strange behaviour with dedup pool I wanted to send you guys an update on this issue. They have now published the APAR: https://www.ibm.com/support/pages/apar/IT36573 I met with our SP Technical Advisor yesterday, and brought this issue up. He told me that there is also a bug in the upgrade from 8.1.10/11 to 8.1.12.000 that can be a big pain and said we should not upgrade until they fix it. I don't have the APAR number for it yet, but his description was something like the upgrade will create some new DB table, which causes a problem. Then you have to manually drop the table, and redo the upgrade. -----Original Message----- From: Kevin Kettner Sent: Friday, April 30, 2021 4:42 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 Thanks for the info! -----Original Message----- From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of Uwe Schreiber Sent: Friday, April 30, 2021 10:54 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] spectrum protect 8.1.11.100 strange behaviour with dedup pool 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
