|
At 07:21 PM 02/25/2000 -0800, you wrote: Well, here's what I remember, and I'm not positive that my memory is absolutely correct. Symptom: I did a SAVE Option 21, and noted that it took 4-3490E compressed tapes to save the IFS. This lead me to believe that I must have had about 10 GB of stuff in my IFS. (2.4GB 4 = 9.6GB). So I asked one of my people to find out what was in the IFS, and they came up with 2 GB! (*NONTRIVIALDFFERENCE). I reported the problem to Rochester (no, not the guy who used to wash Jack Benney's car), and absolutely everybody started their word's to me with the phrase "Well, there's a tender balance...". So I took my 4 tapes, and did a DSPTAP (no I'm not sure which option - too long ago). DSPTAP of the IFS crap (word used deliberately) gave me sizes when I requested OUTPUT(*PRINT). I took the printout, converted it to a source physical file, cleaned it up (took out garbage like headings, and other subtotals that this printout provides (a feature, not a bog), and then used Text Management/38 to do the totals, and this is where I got my findings from. To reconcile the remainder of the difference 2GB x 2.5 is significantly less than 10GB, there are two comments: 1. I saw that 4 tapes were used. Likely they were not fully used, and it's hard to tell how much of a tape is used for what. 2. I was told (and I fully accept this explanation) that objects in the IFS compress/compact (whatever it is in that format) significantly less well than native objects. This does make sense. BTW, I am actively converting several customers that have extensive help applications written in OV/400 to TM/38, because OV is going away, and Text Management will continue to be supported. Clearly somebody's propeller hat was spinning in the wrong direction! Al >Al, > >Not good news! Unfortuately I'm not going to be able to use the native >DB for this application. > >Are you saying that the size that is reported by WRKLNK, option 8 >(attributes) is not correct? I know the actual size can be different >that the allocated size. For example: > >************************************************** >Size of object data in bytes . . . . . : 464 >Allocated size of object . . . . . . . : 4096 >Size of extended attributes . . . . . : 0 >************************************************** > >But are you saying that objects might be actually larger than the >allocated size? > >Patrick > >"Al Barsa, Jr." wrote: > > > > At 03:30 PM 02/25/2000 -0800, you wrote: > > > > I am having HUGE performance problems with the IFS. We wrote an > > application last summer that wrote/read objects into the IFS, and were > > disappointed with the performance. > > > > So what we did was to take those variable size objects and store them in > > multiple variable length fields in the native database, and got a > > performance improvement of about 9 times! > > > > Also, IFS objects use much more disk and tape space than they say. Our > > calculations last summer showed that (on average) of our objects (and there > > is nothing to say that out objects are average, took about a 150% 0premium > > of disk and tape space. (Read this carefully, not 50% more, 150% more!) > > > > Al > > > > >I have an ILE C application on V4R3 that reads and writes IFS files > > >(root file system) on the AS/400. The performance seems pretty poor. The > > >same application running on a PC runs 10 times faster. The PC > > >application even runs faster when the IFS directory is mapped to the PC. > > >The system load does not seem to be a factor. I thought that the AS/400 > > >64 bit RISC system would blow the socks off of relatively low powered > > >Windows NT PC, but so far I'm wrong. Anyone have any suggestions on > > >improving IFS file system performance? > > > > > >Patrick > > >-- > > >IBM AS/400 communications, FTP automation, and network security > > >software and consulting services. > > > > > >http://www.patownsend.com > > >+--- > > >| This is the Midrange System Mailing List! > > >| To submit a new message, send your mail to MIDRANGE-L@midrange.com. > > >| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > > >| To unsubscribe from this list send email to > MIDRANGE-L-UNSUB@midrange.com. > > >| Questions should be directed to the list owner/operator: > david@midrange.com > > >+--- > > > > +--------------------------------------------------+ > > | Please do not send private mail to this address. | > > | Private mail should go to barsa@ibm.net. | > > +--------------------------------------------------+ > > > > Al Barsa, Jr. - Account for Midrange-L > > Barsa Consulting, LLC. > > 400 > 390 > > > > Phone: 914-251-1234 > > Fax: 914-251-9406 > > http://www.barsaconsulting.com > > http://www.taatool.com > > > > +--- > > | This is the Midrange System Mailing List! > > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > > | To unsubscribe from this list send email to > MIDRANGE-L-UNSUB@midrange.com. > > | Questions should be directed to the list owner/operator: > david@midrange.com > > +--- > >-- >IBM AS/400 communications, FTP automation, and network security >software and consulting services. > >http://www.patownsend.com >+--- >| This is the Midrange System Mailing List! >| To submit a new message, send your mail to MIDRANGE-L@midrange.com. >| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. >| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. >| Questions should be directed to the list owner/operator: david@midrange.com >+--- +--------------------------------------------------+ | Please do not send private mail to this address. | | Private mail should go to barsa@ibm.net. | +--------------------------------------------------+ Al Barsa, Jr. - Account for Midrange-L Barsa Consulting, LLC. 400 > 390 Phone: 914-251-1234 Fax: 914-251-9406 http://www.barsaconsulting.com http://www.taatool.com +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.
midrange.com
