|
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/) > _______________________________________________ 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.