I have heard of a couple of folks retiring at Rocket. I hope you guys passed on all your great knowledge of the DBMS' internals :)
On Tue, Mar 5, 2013 at 10:50 PM, Wally Terhune <wterh...@rocketsoftware.com>wrote: > almost. > March 19 will be my final day. > thanks > > Wally Terhune > Technical Support Engineer > Rocket Software > 4600 South Ulster Street, Suite 1100 • Denver, CO 80237 • USA > t: +1 720 475 8055 • e: wterh...@rocketsoftware.com • w: > u2.rocketsoftware.com > Rocket U2 Support: +1.800.729.3553 > ** Please note that I am only available on Tuesdays and Wednesdays. ** > > ________________________________________ > From: u2-users-boun...@listserver.u2ug.org [ > u2-users-boun...@listserver.u2ug.org] on behalf of Jeffrey Butera [ > jbut...@hampshire.edu] > Sent: Tuesday, March 05, 2013 3:26 PM > To: U2 Users List > Cc: U2 Users List > Subject: Re: [U2] Unidata RESIZE CONCURRENT > > Thanks Wally. Shouldn't you be on a sunny beach already? > > Jeff Butera > -- > A tree falls the way it leans. > Be careful which way you lean. > The Lorax > > On Mar 5, 2013, at 4:39 PM, Wally Terhune <wterh...@rocketsoftware.com> > wrote: > > > You may want to review the following problems that have been addressed. > If you > > are running the Recoverable File System (RFS), you will probably want to > be at UniData > > release 7.3.3 before using RESIZE CONCURRENT on RFS files. This list was > extracted > > from the publically available 7.3.3 and 7.2.13 release notes: > > > > 7.3.3 ----------------------------------------------------- > > > > Issue UDT-8887 - Problem Description > > > > RFS -- When resizing a recoverable file with the CONCURRENT option, > UniData > > may not have removed the filename.resize work file when the RESIZE > process > > completed. The file was no longer visible at the operating-system level, > but > > the disk space used by the file was not released and made available. > > > > This problem occurred because one or more of the RFS daemons did not > close > > the filename.resize file at the operating-system level. The problem was > easily > > encountered if the udtconfig N_SYNC parameter was set to a value greater > > than 0. This problem has been fixed. > > > > Issue UDT-9393 - Problem Description > > > > RFS -- Prior to this release, UniData would not remove the temporary > 'rsz' > > file associated with the CONCURRENT RESIZE of a recoverable file until > all > > tm processes and UniData daemons released had closed their handle to the > file. > > The file will be now be removed within two cycles of cleanupd after the > RESIZE > > completes. > > > > 7.3.2 and 7.2.13 > ------------------------------------------------------- > > > > Issue UDT-8069 - Problem Description > > > > UniData -- Prior to this release, when performing RESIZE CONCURRENT on a > > file in another directory on the same server (not located in the same > > directory as the account's VOC file), an error message similar to the > > following example was displayed: > > > > EDEVdefault > > Error when trying to rename the source file before move > > back to the working tmp file. > > Intact records can be found in /home/udtacct/TEST.resize > > In case source file is damaged, it can be recovered from > > /home/udtacct/TEST.resize. > > > > This behavior required the user to use the RESTORE option to make the > file > > accessible again. This problem has been fixed in this release, which > means > > that RESIZE CONCURRENT can be run against these files. The error is no > > longer displayed and the RESTORE option is no longer needed. > > > > > > > > Issue UDT-8521 - Problem Description > > > > UniData -- When resizing an encrypted file with the CONCURRENT option, > the > > resize operation failed and displayed an error message similar to the > > following example: > > > > In BP/_TEST2 at line 8 1:Grpno error. blkbuf->group=0, U_groupno=21, > error > > in U_blkread for file 'TRIGFILE3', key '', number=21 > > > > This problem occurred because an internal variable was overwritten, and > has > > been resolved. > > > > > > UDT-8757 - Problem Description [7.3.x only - problem does not exist in > 7.2.x] > > > > RFS -- Before this release, all trigger information for a recoverable > file > > was lost after performing a RESIZE CONCURRENT. This problem has been > fixed. > > > > > > 7.3.1 and 7.2.13 > -------------------------------------------------------- > > > > Issue UDT-4352 - Problem Description > > > > UniData -- If you issued the dbpause command while a recoverable file was > > being resized with the CONCURRENT option, the dbpause command appeared to > > hang and the following message appeared: > > > > # dbpause > > CheckPoint time before ForceCP: Mon Feb 13 13:22:51 2012 > > > > This problem has been fixed. > > > > > > 7.3.0 and 7.2.13 ------------------------------------------------------ > > > > UDT-4295 - Problem Description > > > > UniData -- Before this release, if you specified an incorrect blocksize > of > > 512 for a recoverable file when using RESIZE CONCURRENT to resize the > file, > > the resize process stopped, but the file remained in a resize state. Now, > > UniData checks to make sure the blocksize specified is valid before > beginning > > the resize process. > > > > > > 7.2.12 ----------------------------------------------------------------- > > > > Issue UDT-4124 - Problem Description > > > > UniData -- Before this release, if a dynamic file was being resized with > > the RESIZE CONCURRENT command and the file contained many parts, a > > message similar to the following example appeared and the resize > operation > > failed: > > > > RESIZE CONCURRENT failed to set the FL_RESIZE_DONE bit > > > > This problem occurred because UniData tried to set the resize done bit > > in the file header, but the file had been temporarily closed. This > > problem has been resolved. > > > > > > > > Wally Terhune > > Technical Support Engineer > > Rocket Software > > 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA > > t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w: > u2.rocketsoftware.com > > > > Rocket U2 Support: +1.800.729.3553 > > ** Please note that I am only available on Tuesdays and Wednesdays. ** > > > > > > -----Original Message----- > > From: u2-users-boun...@listserver.u2ug.org [mailto: > u2-users-boun...@listserver.u2ug.org] On Behalf Of Jeffrey Butera > > Sent: Tuesday, March 05, 2013 1:43 PM > > To: U2 Users List > > Subject: [U2] Unidata RESIZE CONCURRENT > > > > So is anyone using Unidata's RESIZE CONCURRENT in production > environments? I have a dedicated maintenance window, so performing regular > file resizing usually isn't a problem here but I'm considering moving over > to using the CONCURRENT feature - particularly if a fire crops up in our > production environment. > > > > Just curious about people's experience with it and the possible impact > on performance in a production environment. > > > > -- > > Jeffrey Butera, PhD > > Associate Director for Applications and Web Services Information > Technology Hampshire College > > 413-559-5556 > > > > http://www.hampshire.edu > > http://www.facebook.com/hampshirecollegeit > > > > _______________________________________________ > > U2-Users mailing list > > U2-Users@listserver.u2ug.org > > http://listserver.u2ug.org/mailman/listinfo/u2-users > > _______________________________________________ > > U2-Users mailing list > > U2-Users@listserver.u2ug.org > > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > -- John Thompson _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
