RE: RE: LIBL limitation of 25 libraries

Hello Tim,

I agree that the limit of 25 libraries in the user portion of the library list 
is NOT really a limit at all.  
Running into it is an application design issue.  I also agree that the number 
of libraries in the library 
list should be minimised and optimised so the most accessed objects are found 
earlier in the list. 

However, I do want clarification of your statements.  I find the statements to 
be a little misleading due to 
the way the library list is implemented.

As I'm sure you know, finding an object on the AS/400 generally involves 
passing the object's name to the 
Resolve System Pointer (RSLVSP) MI instruction -- assuming one wants to use the 
found object and not merely 
verify its existence.  RSLVSP is quite an expensive operation.  It is a little 
difficult to determine how 
RSLVSP is implemented but it probably uses the Materialise Context (MATCTX) MI 
instruction.

Now let's assume the requested object does not exist to ensure the same search 
path length.

Example 1:  Searching 1 library containing 1000 objects.
                1 resolve to the library
                1 resolve to find the object
                -------------
                2 resolves (and possibly one MATCTX)
                =============

Example 2:  Searching 100 libraries containing 10 objects
                DO 100
                1 resolve to find the library
                1 resolve to find the object
                ENDDO
                -------------
                200 resolves (and possibly 100 MATCTX)
                =============

Therefore example 2 will take longer to complete because more work is involved. 
 Exactly how much longer is 
hard to determine because not all entries in the library object need to be 
searched.  The search can be a 
subset of:
         object type/object sub-type/object name
However it is still roughly 100 times longer.

So on the face of it, your statements are correct but the library list in a job 
is not a list of names.  It 
is a list of resolved pointers to the library (context) objects (known as the 
name resolution list or NRL).  
Therefore the additional library resolution is not necessary.  A simple loop 
through the NRL will suffice.  

                DOUNTIL object found OR no more NRL entries
                1 resolve to find the object
                ENDDO
                -----------
                43 resolves (and possibly 43 MATCTX) at most (15 QSYSLIBL, 25 
QUSRLIBL, 1 CURLIB, 2 PRDLIB)
                ===========


While there is overhead involved in the loop it is considerably less than the 
overhead involved in resolving 
to 43 library names as well.  That is the raison d'etre for the NRL -- to avoid 
resolving to commonly used 
libraries every time an unqualified object is referenced.  None of this 
obviates the need for an optimised 
(and minimal) library list to reduce the search path and therefore the number 
of resolves.

It should be clear that a direct comparison between searching one library or a 
number of libraries cannot be 
made if the NRL is involved although the more libraries the more resolves and 
therefore the more time.

Now having got this far I think this is exactly what you meant and I am no 
longer as confused by your 
statements as I was!  Is this what you were trying to explain?

Regards,
Simon Coulter.

//----------------------------------------------------------
// FlyByNight Software         AS/400 Technical Specialists
// Phone: +61 3 9419 0175      Mobile: +61 0411 091 400
// Fax:   +61 3 9419 0175      E-mail: shc@flybynight.com.au
// 
// Windoze should not be open at Warp speed.
//--- forwarded letter -------------------------------------------------------
> X-Mailer: Internet Mail Service (5.5.1960.3)
> Date: Fri, 27 Nov 98 15:31:20 -0500
> From: "Tim McCarthy" <TimM@softwarejungle.com>
> To: "'MIDRANGE-L@midrange.com'" <MIDRANGE-L@midrange.com>
> Reply-To: MIDRANGE-L@midrange.com
> Subject: RE: RE: LIBL limitation of 25 libraries

> 
> The overhead _IS_ linked to the number of entries in the LIBL and to a
> lesser extent the number of objects in each library. It's much quicker
> to search one library of 1000 objects than to search 100 libraries with
> ten objects. I sympathize with your problem but I've seen too many
> instances of what I'd deem library list abuse to agree that an increase
> in the maximum libl size is warranted. 
> 
> > -----Original Message-----
> > From:       Denis Robitaille [SMTP:DRobitaille@cascades.com]
> > Sent:       Friday, November 27, 1998 1:33 PM
> > To: MIDRANGE-L@midrange.com
> > Subject:    Re: RE: LIBL limitation of 25 libraries
> > 
> > I would think that the overhead is not linked to the number of entries
> > in the libl but to the number of object the system have to go trought.
> > I think that there is not a big difference when searching in one
> > library with 1000 object or in 10 libraries with 100 object. We would
> > also nee to add to every program the logic to handle the add and
> > remove of entries in the libl. And they are the occasional instances
> > when an application need to call programs from another application
> > which complicates even further the logic involved.
> > 
> > Denis Robitaille
> > Cascades inc.
> > Tel: 819-363-5187
> > DRobitaille@cascades.com
> > 
> > >>> Tim McCarthy <TimM@softwarejungle.com> 11/27 12:25 pm >>>
> > Most people don't appear to consider the overhead involved if the
> > system
> > is searching for objects using *LIBL. The bigger the LIBL the greater
> > the overhead. The LIBL should not be something recklessly thrown
> > together ("just add it to the library list") and libraries should be
> > added and removed as applications are entered and exited. 25 entries
> > is
> > more than enough - if it appears not to be, you need to reconsider
> > your
> > LIBL design.
> > 

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