× 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? (The answer / not a rant)
  • From: John Myers - MM <jmyersmm@xxxxxxxxxx>
  • Date: Tue, 29 Feb 2000 14:39:32 -0500

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

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.