Re: V5R2: Source now allowed in the IFS

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Scott,

There was a difference in the two numbers, but not much.
Size of object data in bytes . . . . . :   94000
Allocated size of object . . . . . . . :   98304

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin




Scott Klement <klemscot@klements.com>
Sent by: midrange-l-admin@midrange.com
10/15/2002 03:21 PM
Please respond to midrange-l


        To:     midrange-l@midrange.com
        cc:
        Fax to:
        Subject:        Re: V5R2:  Source now allowed in the IFS



I guess, if we're talking about disk space efficiency, we should be taking
into account how much disk is reserved for the file, rather than how many
bytes of data there is.

Therefore, I would suggest using the 'Allocated size of object' from the
WRKLNK/8 display rather than the 'Size of object data in bytes'.

But, aside from that, I think you're testing it just as I would.   And, as
I suspected, the IFS is much more efficient on disk space, because it
doesnt have to pad each record out with wasted spaces.

And, the efficiency of the IFS is not something new.  It was also more
efficient (I just tested it) way back in V3R2...  So I'm not sure what
Mr. Barsa is referring to, unless he's worried about speed (but I thought
he said disk space!)


On Tue, 15 Oct 2002 rob@dekko.com wrote:
>
> About the only concern with this test, is I should probably check for a
> list of members.  The overhead of the object itself, without any
members:
>
> RMVM FILE(ROB/SCOTT) MBR(*ALL)
> DSPOBJD OBJ(ROB/SCOTT) OBJTYPE(*FILE)
> Object      Type      Attribute               Size
> SCOTT       *FILE     PF                      8192
>
> ADDPFM FILE(ROB/SCOTT) MBR(ORD500)
> DSPOBJD OBJ(ROB/SCOTT) OBJTYPE(*FILE)
> Object      Type      Attribute               Size
> SCOTT       *FILE     PF                     24,576
>
> Oh well, plugs that gap.  The overhead is definitely in the member data.
> Not in the file.  Not in the member header.  But the member data.
>
> Rob Berendt
>
> Good question.  Is the following a valid test?
>
> CRTSRCPF FILE(ROB/SCOTT)
> CPYF FROMFILE(BPCS405CDS/QRPGSRC) TOFILE(ROB/SCOTT) FROMMBR(ORD500)
>      TOMBR(*FROMMBR) MBROPT(*ADD)
>
> DSPOBJD OBJ(ROB/SCOTT) OBJTYPE(*FILE)
> Object      Type      Attribute               Size
> SCOTT       *FILE     PF                   2,220,032
>
> CPYTOSTMF FROMMBR('/qsys.lib/rob.lib/scott.file/ord500.mbr')
>           TOSTMF('/rob/scott.rpg')
>
> WRKLNK OBJ('/rob/scott.rpg')
> 8=Display attributes
> Size of object data in bytes . . . . . :   993,443
>

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.