RE: V5R2: Source now allowed in the IFS

Rob

There's all kinds of extra stuff associated with the data in a source or
data physical file. Just do a DMPOBJ on any single-member PF, just for
simplicity. You get a spooled file of the object, except you don't see any
of the data, only the various headers. There are cursors, members, formats,
all of which are distinct objects (not visible to regular folk like you and
me).

Using the DMP command on an IFS object generates a spooled file, too. It
shows a "Space Attributes" section, just like library objects - 344 bytes
long on a small *STMF file I have. Owner, usage, archive bits, etc., are in
there, I imagine. There's also a little piece at the end, "Path name". This
will vary in length, of course.

The reported size does not include this overhead data. The allocated size,
which is a multiple of 4096 in the 'root', probably does. Allocated size -
the amount of disk used - has to in multiples of 4096, so boundary
conditions could cause the allocated size to be between, say, 350 and c.
4500 bytes greater than the data size. But there is less overhead in a
*STMF, and records could be variable length. Of course, CPY techniques like
CPYTOIMPF and CPYTOSTMF may or may not strip trailing blanks.

But there was probably a tradeoff in performance between native I/O, for
which the 400 was optimized, and space savings of stream I/O, which was
tacked on later.

Regards

Vern

At 03:16 PM 10/15/02 -0500, you wrote:

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
But would that be a valid test?  The bottom line is that I stored a source
member into the ifs and it took less than half the space that it did in
the qsys.lib directory.