[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

2609.0. "Size of LIB_SHARE.DIR issue" by WOTVAX::DORANA (Confuse-a-cat Ltd) Fri Apr 23 1993 15:20

Hi,

VMS stops caching directory files at >127 blocks (I think that's the number).
This leads to a degradation in performance when accessing files within that
directory.

I have just installed a fresh, clean ALL-IN-1 V3.0-1 system and the directory
file LIB_SHARE is 125/186 blocks.

Looking on our office system, the LIB_SHARE.DIR is 170/177 blocks

And on a new installation of a version of ALL-IN-1 I can't mention here, the 
LIB_SHARE.DIR is 126/186 blocks.

Are we heading for a problem with the number of files in this directory?

As a fair number of these files are System Management, or Customization
management files (530+ CM, 170+ SM) could System Management and Customization
Management be taken out of OA and given application areas of their own to help
reduce the files in this directory?

We don't want to give system managers another reason to bemoan ALL-IN-1
performance, do we ?? ;^)

Just interested....

Andy
T.RTitleUserPersonal
Name		DateLines
2609.1A fix would be hard....IOSG::PYEGraham - ALL-IN-1 Sorcerer's ApprenticeFri Apr 23 1993 17:0717
    Andy,
    
    Fair comment. Although I understand the 128 block limit is much less
    serious nowadays than it used to be.
    
    We are intending to take the .EXE files out of OA$LIB in a PFR (that
    you can't talk about :-) ) but that won't help much.
    
    Perhaps we can just do some tidying of redundant files to get the size
    down a bit.
    
    I'm reluctant to propose any large scale move, since we'd need to do
    large scale updates to the CM data files that point to the files, move
    any site versions of files to corresponding directories, etc. all of
    which would create a lot of customer confusion.
    
    Graham
2609.2No problemIOSG::DAVISMark DavisFri Apr 23 1993 17:3121
    
    
       To expand on the  last reply, the 128 block limit only affects 
       performance of wild card lookups, which I don't believe ALL-IN-1 does. 
       For normal actions there is a very gradual affect on performance as the 
       number of files in the directory increases. I think this applies from 
       VMS V5.2 onwards.
    
       In the case of files in OA$LIB there will be very few file accesses 
       requiring directory look-ups anyway in the normal course of events - 
       you only need a directory look up when you open a file and files such 
       as the form libraries are only opened once during an ALL-IN-1 session.
    
       What do you mean by 
    
       "We don't want to give system managers another reason to bemoan 
       ALL-IN-1 performance, do we ?? ;^)" Surely they don't have any reasons?
    
    
       				Cheers	
       					Mark
2609.3A suggestion for other candidatesAIMTEC::WICKS_Aon the Streets of San FranciscoMon Apr 26 1993 23:029
    I realise that this getting a bit too 'futuristic' but what do the
    gurus think of this as a suggestion...
    
    moving the FDLs to another directory might help and i'd definitely
    consider moving those **** .EPS files somewhere else.
    
    Regards,
    
    Andrew.D.Wicks