Conference iosg::all-in-1_v30

    
    Hello Sunil,
    
    Hereby a list of executables on a 3.0 English system after 
    a new installation.
    
    The fact that OA$SAM_REORG_SHARED_DIRS.EXE is missing is described
    in note 318 and STARS "After ALL-IN-1 V3.0 Installed: Executable MUST
    Be Linked Manually For RSD".
    
    Regards,
    
    Jan 
    
Directory USER1:[ALLIN1.LIB_ENGLISH]

CM$PARSE.EXE;1       12-MAR-1992 09:38:02.77
OA$SM_MESSAGE_FILE.EXE;1
                     12-MAR-1992 10:01:52.70

Total of 2 files.

Directory USER1:[ALLIN1.LIB_SHARE]

A1ENCODE.EXE;1       12-MAR-1992 10:08:28.65
CM$CART$SCAN.EXE;1   12-MAR-1992 10:06:06.27
DISPLAY.EXE;1        12-MAR-1992 10:20:57.56
FDNDEDT1.EXE;1       12-MAR-1992 10:34:53.85
FDNDEDT2.EXE;1       12-MAR-1992 10:34:56.51
FDNDREORG.EXE;1      12-MAR-1992 10:34:59.08
FETCHCHECK.EXE;1     12-MAR-1992 10:36:10.58
FLUSHDM.EXE;1        12-MAR-1992 09:37:59.61
FLUSHUSER.EXE;1      12-MAR-1992 09:38:12.69
MAILCOUNT.EXE;1       4-MAY-1992 18:22:49.56
MUA_RENAME_PENDING.EXE;1
                     12-MAR-1992 10:13:52.34
OA$MAIN.EXE;2         5-MAY-1992 08:57:16.08
OA$SAM_BALANCE_USERS.EXE;1
                     12-MAR-1992 10:20:08.43
OA$SAM_CHECK_MAIL_AREA_DELETE.EXE;1
                     12-MAR-1992 10:20:11.36
OA$SM_FCVR.EXE;1     12-MAR-1992 10:21:32.87
OA$SUBMIT.EXE;1       4-MAY-1992 18:22:43.11
OA$TPU.EXE;1         12-MAR-1992 10:22:50.73
OAFCV.EXE;1          12-MAR-1992 10:25:34.20
REMOVEND.EXE;1       12-MAR-1992 10:36:00.12
SENDCHECK.EXE;1      12-MAR-1992 10:02:21.54
SMNETPRGE.EXE;1      12-MAR-1992 10:10:48.02
SMNETUPDT.EXE;1      12-MAR-1992 10:10:55.45
SM_CNV_ARCHIVE_FORMAT.EXE;1
                     12-MAR-1992 10:22:12.66
SPLFORMAT.EXE;1      12-MAR-1992 09:42:14.11
TIME_DIFF.EXE;1      12-MAR-1992 10:25:19.08
TMSV.EXE;1            4-MAY-1992 18:22:31.26
TRIM.EXE;1           12-MAR-1992 09:39:12.00
WPSLP.EXE;1          12-MAR-1992 09:46:09.81
WPSSORT.EXE;1        12-MAR-1992 09:45:52.43

Total of 29 files.
	

    Thanks Jan for pointing out note 318: linking the new image should fix
    any oddities that you observe.
    
    As to the BMA problem: BMA "balances" users across mail areas, but all
    users in one department will be assigned to the same mail area.  Thus
    if you have two mail areas and 300 users, 100 of them in department A,
    100 of them in department B and 100 of them in department C, then you
    will get (eg) all 100 users in department A assigned to one mail area,
    and the 200 users from the other two departments assigned to the other
    mail area.
    
    This is the only explanation I can think of for the behaviour you
    describe.
    
    Scott

    Hi Jan and Scott,
    
    I may not have made myself clear in .0. I had realised that I needed to
    relink OA$SAM_REORG_SHARED_DIRS.EXE as per the Stars article and I also
    came across the said note.  The relink has solved the problems with
    RSD customer ran the HK last night.
    
    Okay to make everything clear regarding the BMA problem.  The customer
    has 17 branches (it's a government department) and the summary at the
    bottom of the logfile gives the following breakdown
    
    135 users assigned to OA$SHARA
    
    	86 Aged planning dev and com care
    	2  Aged project & program funding
    	3  Aged standards and validataion
    	16 Aust. govt health services
    
    392 users assigned to OA$SHARB
    
    	185 Commonwealth rehab. serv.
    	10  Corp. exp and rev.
    	24  Corp. management
    	22  Disability programs
    	6   HHCS
    	31  HRM Services
    	4   Health Serv.
    	38  Hearing Serv.
    	12  Housing
    	45  Program Management support
    	1   Program Management Support
    	14  Systems
    
    The customer has said that the manual states that BMA will try to
    distribute the users between mail areas as evenly as possible as per
    page 10-24 of the ALL-IN-1 Managers Guide.  Looking at the logfile this
    does not appear to be happening and the customer has said that the
    SHARB area is getting full.
    
    I have asked the customer to rerun the BMA HK tonight to see if the
    successful completion of the RSD HK, this may make a difference I hope.
    
    The above are the problems the customer has experienced.
    
    My second concern is the .exe's in oa$lib and I am having a mourn as
    you can see from .0, version 2.2 and 2.4 .exe's are still present in
    oa$lib.  Is it possible in future releases to do a bit of a cleaning up
    because having all these old .exe's hanging around causes two problems. 
    The first one being disk space and the secound one being the problem of
    cleaning up oa$lib.  Some customers are concerned because they feel
    that the installation procedure should get rid of the old images or
    give them a list of .exe's to delete.
    
    Thanks for your help I will let you know if the BMA is working now that
    RSD has worked.
    
    Regards,
    
    Sunil

    Hi,         
    
    The customer ran the BMA procedure and it made no difference at all. 
    The following is the breakdown for each mail area.
    
    OA$SHARA						OA$SHARB
    
    Total number of dirs   73				111
    Total number of files  31120			17541
    Total number of blocks 412555	                253016
    
    I have asked the customer to re-run the BMA during the weekend to see
    if it makes any difference.  Does BMA really work under 3.0 ?  If BMA
    does not work during the weekend the customer will run it on Saturday
    and Sunday, I may have to put in a bug report.  This customer site is
    one of those sensitive DEC bashing sites :-( as a good will gesture
    towards them I may have to SPR this problem.
    
    So any input from the developer or team to solve this problem would be much 
    appriciated. I didn't want to say "from the horses mouth", people may get 
    the wrong idea that DEC only employ horses ;-) !!!!!!
    
    Have a good weekend in the snow, ice, cold damp places,
    
    Sunil

    You won't get any input from the developer.  He left IOSG four years
    ago, and left Digital a few months ago.
    
    Nothing has changed in BMA in V3.0.  However, I was the last person to
    touch the code :-( incorporating a V2.3 patch fix into V2.4.
    
    I'll have a look and see if it's doing anything odd.
    
    As OA$SHARB is
    smaller than OA$SHARA, that might explain why it puts more users in
    that area (ie it thinks OA$SHARA is already overloaded).
    
    Scott

    Hi Scott,
    
    I think the problem maybe the customers perception more than anything 
    else.  What the customer expected was that the split should have been 
    even amongst the various shared area's.  But this is not possible 
    because one shared area may fill up quicker than the others departments 
    are reallocated to other shared areas.
    
    What is a bit confusing is that the customer told me that the split was 
    always even and I just want to make sure that nothing has changed.  
    Does the BMA routine check for diskquota allocation as well as the 
    number of files in each shared area before balancing the mail areas ?
    
    The customer has told me that everthing was working fine before the RSD 
    image was relinked and that the split was even.  I am a bit stuck not 
    knowing what the various .exe's are doing, the customer just needs a 
    bit of reassurance.
    
    Thanks for your help,
    
    Sunil

    Sunil,
    
    First, RSD and BMA have nothing to do with each other.  Running RSD
    will not affect the outcome of BMA.
    
    Second, BMA does not look at diskquota, disk usage, or anything like
    that.  It's calculations are based solely on number of users per
    department, and number of users per shared area.
    
    The reason your customer observes the unbalanced split is as follows.
    
    They have 527 users, and two mail areas.  BMA thus works out that there
    should be 264 users per mail area, with the condition that a department
    cannot be split across a mail area.
    
    It allocates the first four departments (86 + 2 + 3 + 16) to SHARA,
    giving 135 users.  The next department has 185 users which would bring
    the total for SHARA to 320 users.  This exceeds the 264 user limit, so
    BAM moves on to SHARB and allocates the 185 users there.
    
    The BMA algorithm does not allow it to go back to a previous mail area;
    now it has moved on to area B, all remaining users must be allocated
    to this or subsequent mail areas.  Unfortunately in your case, there
    are no more mail areas, so all remaining users are allocated to SHARB.
    
    Thus, due to the fact that one department is a lot bigger than most of
    the others, this leads to the observed imbalance.  My recommendation
    to your customer would be to make the departments of more even sizes. 
    Even just splitting the 185 into two departments would help.
    
    There is not a lot of point SPRing this, as it will probably just be
    answered "that's the way it works", but I hope my explanation can help
    you sort things out for this customer.
    
    Scott

    Hi Scot,
    
    Thanks for your prompt reply it helped me convince the customer that 
    they need to split the department containing the 185 users, to obtain 
    the required balance.  The customer said that the documentation was not 
    too clear and your explaination certainly was.
    
    I have to go the extra mile for this customer because they are the 
    largest ALL-IN-1 site in the Souther Pacific Region  and they want to 
    get their support from a 3rd part.  So we are doing everything we can 
    to hold onto this multi-million dollar site, that's why I required the 
    extra info.  An SPR will not be submitted and sorry for any 
    inconvenience that may have been caused.
    
    Regards,
    
    Sunil