Assuming you have grown your Shared Storage Pool in the past by adding more LUNs and you have say 32 LUNs (twice if mirroring with a failgrp) then you can grow you SSP the easy way and by magic. 

Just get the SAN team (that could be yourself, of course) to expand the size of the Pool LUNs.  Our minimum size LUN policy is 128 GB and our Repository LUNs are 1 or 2 GB.  I tried this experiment based on one line in a presentation on the next SSP release by the developers, where they said "The Share Storage Pool for a few version now supported growth by increasing Pool LUNs" - I nearly fell of the chair.  What! No one told me that!   So I lashed up a quick to LUN plus Repository LUN SSP on a pair of VIOS running 2.2.6 - it only took 10 second plus created a large LU. Then off to my trusty IBM Storwize V7000 and grew both LUNs by 64 GB (only the two SSP data LUNs, of course).

Before the LUN expansion:

$ lssp -clustername alpha
POOL_NAME:       alpha
POOL_SIZE:       261888
MIRROR_STATE:    NOT_MIRRORED
FREE_SPACE:      258104
TOTAL_LU_SIZE:   131072
OVERCOMMIT_SIZE: 0
TOTAL_LUS:       1
POOL_TYPE:       CLPOOL
POOL_ID:         0000000009893E4C000000005583004B

Afterwards . . .  exactly the same, Oh dear!   Don't forget we are running a cluster and clusters should not make rapid changes.

It took me about a 1 minute to add 64 GB to each LUN.  We don't want the SSP to start making changes half way through the two LUN changes.

After about 20 minutes (not measured as I went to make a cup of tea and drank it in the sunshine here in London, UK). I thought I would just check the sizes again, and wow!:

$ lssp -clustername alpha
POOL_NAME:       alpha
POOL_SIZE:       392960
MIRROR_STATE:    NOT_MIRRORED
FREE_SPACE:      388520
TOTAL_LU_SIZE:   131072
OVERCOMMIT_SIZE: 0
TOTAL_LUS:       1
POOL_TYPE:       CLPOOL
POOL_ID:         0000000009893E4C000000005583004B

POOLSIZE Growth = 393960 - 261888  = 131072 MB = 128 GB = two x 64 GB - which is what I added.

Speed? - I don't what to start benchmarking how fast it notices and make the changes as it might depend on things like the number of LUs and the numbers of VIOS in the cluster - lets just say about 20 minutes.

Which VIOS release? - From VIOS 2.2.3.4 Which si so old no one should be running it now!

*** BLUNTNESS ALERT ***

you would be nuts not to have upgraded already to VIOS 3.1+

*** BLUNTNESS ALERT END ***

This feature may work with many earlier releases - it is hard to determine because there is no command involved.

Why grow a SSP this way?

This can make SSP life a lot simpler.  Once you have enough LUNs to spread out I/O then further LUNs don't need to be created along with their mapping to VIOS and Zoning.  Then you don't need to find the LUNs with cfgdev on every VIOS then pv -list -capable to check followed by a pv -add. 

Nope - Just tell the SAN team to double the current LUN sizes = that is a much simpler operation for them and less complex = less risky. And probably less documentation too.  And did you note saying "double the LUN size" sounds like a lot less than "give me another 32 LUNs"

I hope this makes your SSP simpler to operate.