Re: Limits on some object sizes <= 16M

["Larry Loen" <lwloen@xxxxxxxxxx>]

Mark Waterbury asked:

>However, here too, I would like to ask the question,
>why "250" libraries? Why not raise the bar to, say,
>500 or 1000 libraries?  Why place "arbitrary" limits
>on things like the "library list"?

I didn't make this decision, but the answer in this case is simple:
Performance.

Not every resolution of a name to an object is going to succeed.  In not a
few cases, failed resolutions are even planned and the result will be the
creation of the (not existing yet) object.  The classic example of this is
a simple "open for write" in a high level language like C or COBOL.  If the
file doesn't exist, it gets created.  Well, how is create versus reuse
typically found out?  In OS/400, by resolving a system pointer using the
library list.  Five hundred library lookups is, even in 2001, a fair amount
of time spent, especially for something that is reasonably routine.

Now, to state the obvious, I suppose there are ways that the size of the
list could be made unboundedly large.  But, everyone makes decisions about
this sort of stuff all the time whether one designs OS or App code for a
living.  Do we implement a fixed limit (cheaper to code, a bit faster to
run, a bit easier to explain) or some very flexible scheme that is
effectively unbounded, with uncertain or indescribable worst case failure
conditions?  Who really needs the limit "that big?"  Do we do anyone a
favor by inviting "abuse" of a given feature?

Maybe an unlimited library list was the right call, but it wasn't obvious
many years ago when this decision was undoubtedly made.  For instance, VM
had lived with a similar limit for its mini-disks for many years and still
(so far as I know) does so.


Larry W. Loen  -   Senior Java and iSeries Performance Analyst
                          Dept HP4, Rochester MN


Speaking on his own, as always

+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---