Re: V5R2: Source now allowed in the IFS

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Probably true.  I think we have lots of source.  Multiple versions of
BPCS, Software Plus, numerous custom mods, etc.  Our total source is only
7,890,104,320 (from a query summing up DSPOBJD)

       ODOBNM            LIKE   '%SRC%'
AND    ODOBTP            EQ     '*FILE'
AND    ODOBAT            LIKE   'PF%'

Field             Text
ODLBNM            Library
ODOBNM            Object
ODOBTP            Object type
ODOBAT            Object attribute
SIZE              odsizu*odbpun

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




Douglas Handy <dhandy1@bellsouth.net>
Sent by: midrange-l-admin@midrange.com
10/15/2002 03:35 PM
Please respond to midrange-l


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


Phil/Rob,

>For the IFS, all the 'whitespace' is removed.
>
>Try creating a IFS file with all the lines filled out to 92 chars...

But that is the point; trailing whitespace is not needed with a stream
file in
the IFS.  Not only that, but with a "real" editor <g> you can convert
leading
and embedded whitespace to use a combination of tabs and spaces.  With RPG
source, that leads to some substantial space savings.  Plus any decent
file
viewer, difference compare/merge tool, change mgmt system, etc will still
work
just fine with tabbed source files.

I did this all the time with Flex/Edit.  I'd set it to auto-run "Detab"
when
opening a source flie stored in a PC directory, and run "Entab" when
saving the
file.  Not as efficient as real RLE compression like SSP did for source
members
on the 32/34/36, but still significantly smaller than embedded blanks.
Which
itself is significantly smaller than fixed width statements with trailing
blanks.

That said, although a PF-SRC is not very space efficient, I don't think it
is a
significant factor in the average 400's total DASD consumption.  On every
machine I've checked, the total DASD consumed by all source members was
insignificant compared to data in physical files.

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