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 
release 7.3.3 before using RESIZE CONCURRENT on RFS files. This list was 
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 

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:

        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

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

        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: **w:

Rocket U2 Support: +1.800.729.3553
** Please note that I am only available on Tuesdays and Wednesdays. **

-----Original Message-----
[] 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 

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

U2-Users mailing list
U2-Users mailing list

Reply via email to