Extent Q and could be possible architecture Q

This is not a newbie FAQuack! Obnoxio need not get grumpy, nor start a new wantonly useless but amusing thread, ending in some gross observations about, well, you get the drift. Yes I researched the FM, still acronym'ed at RTFM, but technically I did not R E A D it. :-))) (that's my quivering double chins in case you are a newbie and need the verbal cue) What are the benefits and drawbacks of re-mapping table/extents using the various methods: 1. This lists regularly expounded method of export, re-size the first and next extent, import. (results in complete extent re-mapping) 2. Issuing a cluster index (to remove non-contiguous space), issue alter fragment on table xxx in dbspace xxx, issue uncluster index. (results in approx 50% reduction in extents but no change to initial or next extent). 3. Using ontape to drop and restore the db (in my small 4 g production db > test db results in all fragments fitting into one extent but next size still remains at old setting and must be changed manually). Will the use of #2 result in integrity problems or anything unusual? Are there any reasons #2 is not used except that it is a kind of uncool and cludgy work around and doesn't result in a oh so pure all data fits into one extent solution? Am I ignoramously deceived that #3 solves all problems except it is only viable for small dbs because of the downtime associated with it? For the sadly lazy dba (who said that!), #1 is a pain to alter all those ddl statements...all work and no play makes you obnoxio...oops, sorry, it makes you say adios! What am I missing besides more money, better chair, a 21" flat panel, the combined wisdom of this crowd? Ooze onward wise gurus and keepers of the informix flame of knowledge! tia, maybe, depending on the response. p.s will summarize if I garner anything useful