|
Al, Wow! It's hard to see how the AS/400 can be a reasonable Notes or Web server with this kind of storage problem. Thanks for your thoughts on this! Patrick "Al Barsa, Jr." wrote: > > 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 > +--- -- 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 +---
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.