Re: V5R2: Source now allowed in the IFS

["Al Barsa" <barsa@xxxxxxxxxxxxxxxxxxx>]

Check out the size of the object that "reports" on disk, versus the size of
the object that "reports" on tape.  I do not remember if the DSPTAP option
was *SAVRST or *DATA, but I think that it was *DATA.

Not having an available system here ti play with, I can't do a test.

Al - at COMMON

Al Barsa, Jr.
Barsa Consulting Group, LLC

400>390

914-251-1234
914-251-9406 fax

http://www.barsaconsulting.com
http://www.taatool.com






                      rob@dekko.com
                      Sent by:                  To:       
midrange-l@midrange.com
                      midrange-l-admin@m        cc:
                      idrange.com               Subject:  Re: V5R2:  Source now 
allowed in the IFS


                      10/15/2002 04:28
                      PM
                      Please respond to
                      midrange-l






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.



_______________________________________________
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.