Re: V5R2: Source now allowed in the IFS

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
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
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin




rob@dekko.com
Sent by: midrange-l-admin@midrange.com
10/15/2002 02:32 PM
Please respond to midrange-l


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


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

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

5=Display
....+....1....+....2....+....3....+....4....+....5....+....6....+....7.
 ************Beginning of data**************
     F/TITLE ORD500      Customer Order Entry
     F*****************************************************************
     F* COPYRIGHT SYSTEM SOFTWARE ASSOCIATES,INC.  CHICAGO,ILL.  1993
     F*****************************************************************
     F*
     F*   PROGRAM ID   - ORD500
     F*   PROGRAM NAME - Customer Order Entry
     F*
     F*   BMR     Date  Description
     F*  ----  -------  -----------------------------------------------
0000aF*  0000  31Mar93  Version 4.0 (BMR markings removed.)
3612aF*  3612  31Mar93  Correct logic flow to allow the over
3612aF*                 allocated message appear.
1606aF*  1606  10Mar93  Errors proceesing Kits with a free goods
3506aF*  3506  01Apr93  Excessive response time after entering
3506aF*                 a large order and taking F6/Accept.
2317aF*  2317  08Dec92  New parms were added to the call of
2317aF*                 PRO501.  The order number to copy and
...


In my estimation that is less than half the size.  Sure would be a nasty
thing to free up half your disk space.  I remember back in the dark ages
when we were estimating disk space in our migration from the S/36 to the
AS/400.  The amount of space that source physical files consumes is
astronomical.  Don't try to convince me that this space is needed by the
date changed.  There is no way that would eat up more than twice the space
used by the actual code.  Now, I do like that date changed though - but
something else is sucking up disk space like a hoover.

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 02:01 PM
Please respond to midrange-l


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



Why do you think that the IFS is "SO inefficient a user of space"?

It seems to me that the fixed-length source member is inefficient, since
all the blank characters at the end of every line of text are wasted in a
fixed-length system.

So, I'm baffled by your statement.  Is there something about the IFS that
I don't know?  Something that makes it waste even more space than that?


On Tue, 15 Oct 2002, Al Barsa wrote:
>
> I was at the Inge Weiss session yesterday where she indicated that
source
> can be put into the IFS, but the IFS is SO inefficient a user of space,
why
> would I ever want to ever want to waste that disk space?  (PS:  This
> observation was taken in the V4R4 time frame/)
>