Error with chvg -B

[gatetec]

I am getting errors below:

chvg -B mockvg
0516-1224 chvg: WARNING, once this operation is completed, volume group mockvg
cannot be imported into AIX 431 or lower versions. Continue (y/n) ? y
0516-012 lchangevg: Logical volume must be closed. If the logical
volume contains a filesystem, the umount command will close the LV device.
0516-732 chvg: Unable to change volume group mockvg.

The vg has all raw LVs:

lsvg -l mockvg
mockvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
mock_0128_000 raw 5 5 1 open/syncd N/A
mock_0192_000 raw 6 6 1 open/syncd N/A
mock_0192_001 raw 6 6 1 open/syncd N/A
mock_0512_000 raw 16 16 1 open/syncd N/A
mock_1024_000 raw 32 32 1 open/syncd N/A
mock_0064_026 raw 2 2 1 open/syncd N/A
bla......

Is there a way to execute 'chvg -B mockvg' without closing the LVs?
There is no mt pts off of this vg.
There are 255 LVs, so I am looking for a quick and simple way of doing 'chvg -B'.

thx much

 

[khalidaaa]

IMO I think you need to close the LVs first!

Did you check all the possibility of this command:

-B Changes the volume group to Big VG format. This can accommodate up to 128 physical volumes and 512 logical volumes. 
Notes:
The -B flag cannot be used if there are any stale physical partitions. 
Once the volume group is converted, it cannot be imported into AIX 4.3.1 or lower versions. 
The -B flag cannot be used if the volume group is varied on in concurrent mode. 
There must be enough free partitions available on each physical volume for the VGDA expansion for this operation to be successful. 
Because the VGDA resides on the edge of the disk and it requires contiguous space for expansion, the free partitions are required on the edge of the disk. If those partitions are allocated for user usage, they will be migrated to other free partitions on the same disk. The rest of the physical partitions will be renumbered to reflect the loss of the partitions for VGDA usage. This will change the mappings of the logical to physical partitions in all the PVs of this VG. If you have saved the mappings of the LVs for a potential recovery operation, you should generate the maps again after the completion of the conversion operation. Also, if the backup of the VG is taken with the map option and you plan to restore using those maps, the restore operation may fail since the partition number may no longer exist (due to reduction). It is recommended that backup is taken before the conversion, and right after the conversion if the map option is utilized. 
Because the VGDA space has been increased substantially, every VGDA update operation (creating a logical volume, changing a logical volume, adding a physical volume, and so on) may take considerably longer to run.

Regards,
Khalid