Re: Real size vs. Allocated size...

What version are you running??  If you are at V5R1+ you can utilize the
*TYPE2 directory format.

V5R1 requres PTF's  here is one:
http://www-912.ibm.com/a_dir/as4ptf.nsf/a18db68aae4a7d81862566ba005d145c/8943c32b70479e0a86256e4400529082?OpenDocument&Highlight=2,cvtdir


if v5r2 here is some more info.
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/cl/cvtdir.htm


LAtest PTF's here:
http://www-912.ibm.com/n_dir/nas4apar.nsf/c79815e083182fec862564c00079d117/8ec569406141de0786256b5700420f74?OpenDocument&Highlight=2,II13161


additional reading material:
http://www.itjungle.com/tfh/tfh082902-story05.html



----------------------------
Bryan Dietz
Aktion Associates


----- Original Message -----
From: "Graap, Ken" <keg@xxxxxxxxxxxxx>
To: "'Midrange'" <midrange-l@xxxxxxxxxxxx>
Sent: Monday, January 24, 2005 10:36 AM
Subject: Real size vs. Allocated size...


> We are storing "millions" of small TIFF images in the IFS.
>
> After doing this for a couple of months we have noticed that they are
> taking
> up much more space than originally planned...
>
> When I look at the attributes for one of them I see this:
>
> Size of object data in bytes . . . . . :   33936
> Allocated size of object . . . . . . . :   65536
>
> OS/400 HELP tells me that "allocated size" is:
>
> The number of bytes that have been allocated for the object.  The
> allocated size varies by object type and file system.  For example, the
> allocated size includes the object data size as well as any logically
> sized extents to accommodate anticipated future requirements for the
> object data.  It may or may not include additional bytes for attribute
> information.
>
> I'm not completely sure if the allocated size is taking up "real" disk
> space...
>
> These files do not need additional space allocated. There are what they
> are
> and will not grow in size...
>
> Does anyone know how I can make the allocated size equal to the real
size,
> when I create new objects like this in the IFS or do I even have to worry
> about this?
>
> Kenneth