Re: Poor IFS performance? (The answer / not a rant) -- MIDRANGE-L

John,

I might not have been clear about what I'm trying to do. Sorry if I
introduced some confusion in the discussion.

There is no EBCDIC to ASCII conversion taking place in my application.
The data is in ASCII in an IFS file system and I'm running an ILE C
application against it. The application takes 4 minutes 14 seconds to
execute on a dedicated RISC AS/400 (model 150, but same results on
larger systems). The very same application compiled on a 200 mhz Dell NT
running against the same file on the local hard drive takes 25 seconds
to execute. Somehow I was expecting better performance on a 64 bit RISC
server system even with the obvious differences in architecture. 

Patrick
-- 
IBM AS/400 communications, FTP automation, and network security
software and consulting services.

http://www.patownsend.com

John Myers - MM wrote:
> 
> At 06:30 PM 2/25/00 , you wrote:
> 
> >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
> 
> Sorry for not responding sooner ... I've been out of town & don't have the
> patience to download all of the mass mail traffic at 56kb (that's the
> purpose of the MM ending the mailbox name.
> 
> Am I dense, or is everyone here overlooking the obvious? ... the fact that
> the IFS is an ACSII file system & the application, in all likelihood, is
> forcing an ASCII to EBCDIC conversion and vice versa (under the
> covers).  Remember that the AS/400 is fundamentally an EBCDIC
> machine.  This is why the application would run much slower on the AS/400
> than on a stand-alone PC.  The mapped drive also does not incur this data
> conversion penalty.
> 
> The best way to improve applications performance is to structure the
> application to reduce the number of ASCII <-> EBCDIC conversions that are
> required.  Perhaps future generations of AS/400-like systems will use ASCII
> as their native data coding (it would be a bear of a conversion, though).
> 
> (For those of you that work just with the AS/400, EBCDIC is an 8-bit
> representation of data used by IBM & ACSII is a 7-bit representation that
> is used by much of the rest of the world (including all PC's).)
> 
> With respect to the storage size issues, I don't have a certain answer.  It
> may be due to differences in the size of "disk clusters" as implemented in
> the IFS.  Larger clusters give better performance, but inject waste in the
> form of unusable space.  This is why a 20 byte file on a PC takes up much
> more space there, as well.
> 
> Rather than using this issue to hammer IBM, let's keep in mind the beauty
> of the IFS.  It allows us to co-exist with a world that is totally
> architecturally different than the environment that we call the
> AS/400.  It's not a replacement for PC servers (& shouldn't be considered
> as one).  It DOES, give us a remarkable middle ground, that is somewhat
> unique in computing!
> 
> To me, the IFS is a vital tool in my IT infrastructure (2 AS/400's, 1
> Novell, & 1 Win NT server), but not the entire toolbox!
> 
> Sincerely,
> 
> John
> 
> Get and route intelligence from your IBM AS/400 web site - WebSurvey/400
>       http://www.WebSurvey400.com
> 
> Systems supporting the distribution operations of Motor Vehicle manufacturers
>      http://www.VehicleSystem.com
> 
> John Myers
> IBM Certified Specialist - AS/400 Technical Solutions
> Strategic Business Systems, Inc.
> 300 Lake Street, Suite B, Ramsey, NJ 07446  USA
> E-mail: mailto:jmyers@sbsusa.com   Phone: +1 (201) EASY 400   x131
> Web:    http://www.sbsusa.com      Fax:   +1 (201) 327-6984
> 
> +---
> | 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
> +---
+---
| 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
+---