Conference iosg::all-in-1_v30

    RE question 1:
    
    The FCS is designed to be a high performance, high troughput server and
    is implemented using multi-threading. This means that provided adiquate
    memory is available and the server is busy enough to always have
    something to do then it's performance will be bound by the amount of
    CPU it can get.
    
    If the existing server does not have enough work to keep it busy there
    is obviously no point adding another one.
    
    If the existing server does not have enough memory then the solution
    is to get it more memory, adding a second server will increase the
    memory requirement and hence make the situation worse not better.
    
    If the existing server has all the memory it needs and is being kept
    busy then it will be bound by the amount of CPU time it can get, if the
    VAX is a multi-CPU box then having a second server will increase the
    theoretical maximum CPU the server processes could get (assuming all
    the CPUs are not already 100% busy). If there is not a second CPU in
    the box then adding another server will increase the overhead with
    little or no gain in performance (2 servers will be competing for the
    same CPU resource).
    
    Other than to make use of a second CPU I can not think of a reason to
    have a second server on a single node.
    
    Multiple servers on multiple nodes in a cluster makes sense as you can
    spread the load between the nodes in the cluster.
    
    If DECnet Phase IV naming is in use then ALL-IN-1 will always connect
    to DECnet object 73 unless the logical name OAFC$SRV_OBJ is defined to
    be another valid DECnet object number (73 and 128 thru 255 are valid).
    The definition of this logical needs to be done on a per-process basis
    (unless you want all users to use a different DECnet object). The
    management of the value of this logical name is entirely up to the
    system manager.
    
    If DNS naming is used then each partition in DNS has a list of one or
    more servers that service it and the load is more-or-less evenly spread
    between the servers.
    
    There is more information on server performance and DNS and DECnet
    Phase IV naming in my FCS doc. This document is restricted distribution
    so I can not post it's location in an open conference, but if you send
    me mail I will let you know where to copy it from (I have to maintain a 
    list of who has a copy). If you have access to the A1INFO notes
    conference then the location is posted there.
    
    Terry

    Terry,
    
    Thanks very much for the info.  I've got a copy of the document
    already, just haven't had the time to really dig into it.
    
    Another question which just came up was, How much space does a co-exist
    install need?
    
    Thanks,
    
    Kevin

>    5. Is there a seperate utility needed in order for V3.0 to print to
>    POSTSCRIPT?	
    
No.  

DEC sells a product called the 'DECprint utility for PostScript to Sixel 
printing' (otherwise known as PSPRINT) which allows PostScript files to be 
printed on DEC Sixel Printers.  ALL-IN-1 V3.0 includes support for PSPRINT.


Richard

    
    Kevin,
    
    > 4. Is there any reason why OA$NOMINATE_NAM_username.LOG files would be
    >    in the [ALLIN1.MGR.OA$TEMP] area?  Why not in OA$LOG?
    
    The file is created in OA$TEMP first. When an error occurs, the log
    file will be 'LISTed' to your screen. Aftering you finished reading, we
    try to copy the file to OA$LOG:. However, if that fails, for whatever
    reason (diskspace, quota), we keep the error log in OA$TEMP. The
    message displayed after reading the error log will indicate where the
    error log is to be found. Either in OA$LOG: or OA$TEMP:. 
    
    HTH,
    
    	Simon   

    Kevin,
    
>    Another question which just came up was, How much space does a co-exist
>    install need?
    
    Without reading the FM, I would say: the same as a fresh installation.
    
    Regards,
    
    Jan

    

    
    Question 1:
    
    Basically the answer is: "What Terry said in .1"
    
    There are a couple of things I would like to point out though.
    
    The server comes with default parameters in the configuration file. 
    These parameters are based on a user load of 50 users, if you check
    the release notes for the FCS you will set the param settings as
    well as suggested changes based on the number of users you have.
    this is all documented in ch 3 of the release notes. "Tuning the
    server"
    
    For what Terry said:
    
    >The FCS is designed to be a high performance, high troughput server and
    >is implemented using multi-threading. This means that provided adiquate
    >memory is available and the server is busy enough to always have
    >something to do then it's performance will be bound by the amount of
    >CPU it can get.
    
    Gee Terry, you sound like you work for us :-).
    
    >If the existing server does not have enough work to keep it busy there
    >is obviously no point adding another one.
    
    Yup.
    
    >If the existing server has all the memory it needs and is being kept
    >busy then it will be bound by the amount of CPU time it can get, if the
    >VAX is a multi-CPU box then having a second server will increase the
    >theoretical maximum CPU the server processes could get (assuming all
    >the CPUs are not already 100% busy). If there is not a second CPU in
    >the box then adding another server will increase the overhead with
    >little or no gain in performance (2 servers will be competing for the
    >same CPU resource).
    
    There would be a slight increase in performance with a second server.
    With one server, the server gets a single quantum of time before VMS
    swaps it out. Therefore within this quantum, each active thread fights
    for time. If you have 4 threads then each, theoretically, would only
    get 1/4 of the CPU time in the quantum.  With 2 servers, each with 
    two threads, each would get 1/2 the quantum at the CPU. It may make no
    difference or alot of differnce. The thing is that thread context 
    switches also take some time. You can think of them as being swapped
    within the process, just as VMS will swap processes.
    
    >If DECnet Phase IV naming is in use then ALL-IN-1 will always connect
    >to DECnet object 73 unless the logical name OAFC$SRV_OBJ is defined to
    >be another valid DECnet object number (73 and 128 thru 255 are valid).
    >The definition of this logical needs to be done on a per-process basis
    >(unless you want all users to use a different DECnet object). The
    >management of the value of this logical name is entirely up to the
    >system manager.
    
    One other thing to note. THIS IS ENTIRELY SUPPORTED BY THE FCS. It is 
    not documented due to an oversight in the documentation review.
    
    >If DNS naming is used then each partition in DNS has a list of one or
    >more servers that service it and the load is more-or-less evenly spread
    >between the servers.
    
    This only controls brokering. THe original connection to the server is
    based on the filecab name and the value of OAFC$SRV_OBJ (or 73 by
    default).  With DECnet phase IV naming (distribution off/level 0), ALL
    brokered connections go to decnet object 73. With DNS naming 
    (distribution on/level 1), if the partition being brokered to is
    a DNS partition, then the server to broker to is found via a DNS 
    object lookup which contains the server name, hence it can be any
    object number that is available for the server.
    
    That's about it. 
    
    --Bob
    
    

    Kevin,
    
    Well I was hoping a FileCAb type might take number 2 but hopefully my
    attempt at an answering it will stir them into action.
    
    2) When a drawer is deleted the ACL for the deleted user remains, I
    guess that the code takes care of moving the drawer to a different
    location and changing the owner but everytime I try Delete User it
    loops and loops (this has been reported to ENgineering as they say)
    so I can't actually test it for you to see what happens.
    
    3) The "official" recommendation is the same as it always was basically
       a) read the Install Guide, read the release notes
       b) plan, plan, plan
       c) run pre-check - fix anything
       d) run CART -resolve conflicts
       e) do the install
    
    I know that there was a DECUS presentation on this also
    
    Regards,
    
    Andrew.D.Wicks

    The workround for delete user looping is to ensure that the user has at
    least one unread mail.
    
    The script contains a bug whereby it branches to the wrong place if the
    user has 0 unread mail and not only skips the bit that deals with
    unread mail but also skips the bit that deals with non-deletable
    documents. If the user has any undeletable documents (and anyone who
    used spell checker will have at least one) then the loop to delete the
    user's documents fails to delete all of them, and tries again, and
    again, and again ...
    
    The real fix is to change the script, unfortunately I am not at my desk
    and I do not have details of the fix to hand. 
    
    There is also one unresolved question around this, when the V3.0 spell
    checker is used for the first time a system dictionary entry is added
    to the DOCDB and is marked non-deletable (hence the problem). This
    DOCDB entry appears to be non-standard in that it does not point to a
    DAF and hence does not have a usage count (I have not been able to
    check this out flly yet so (hopefully) I am wrong on this). If there is
    no usage count what happens when the DOCDB entry is deleted by the
    janitor, does the file go as well? I hope not if it does spell checker
    will not be too happy :-)
    
    When I get a chance I will look into this in more detail and post the
    results here.
    
    HTH
    
    Terry

    Further discussion of the Delete User loop can be found in note 854.0