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
