Re: Poor IFS performance?

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
+---