× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Poor IFS performance?
  • From: Patrick Townsend <townsend@xxxxxxxxxxxxxx>
  • Date: Sun, 27 Feb 2000 20:48:07 -0800
  • Organization: Patrick Townsend & Associates, Inc.

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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.