Conference iosg::all-in-1_v30

    Bo,
    
    No a System Manager is NOT necessarily an Application Manager, the best 
    explanation in my newly unwrapped doc-set appears on page 4-44 of the 
    Management Guide.
    
    An application manager is basically the person who creates (deletes etc)
    applications and application areas and nominates other programmers
    as Application Maintainers of an Application Area. He/She is also
    the person who restores applications that have been transferred from
    another system.
    
    By default when you upgrade to v3.0 the only Application Manager
    you have is the ALL-IN-1 System Manager and that might be how some
    customers wish to leave it... but if you want to have someone who isn't
    the System Manager manage your applications then you can do it.
    
    So the answer is yes and no - but you expected that from me didn't you?
    
    Regards,
    
    Andrew.D.Wicks

    
    Bo,
    
    The initial confusion might have started because after the (whatever)
    V3.0 installation the ALL-IN-1 MANAGER account is the only CM Manager.
    
    However, as Andrew correctly explained (it seems he's getting a
    specialist ;-)) this does not necessarily be the case. You can still 
    have more than one ALL-IN-1 Manager who doesn't have access to CM 
    (Profile APP flag not set).
    
    There is one gotcha. To nominate an account to be an CM Manager you
    need to be a CM Manager yourself. If by any change noone on the system
    is a CM Manager any longer (due to whatever mistake made by...) you
    need to change the profile of (e.g.) the ALL-IN-1 Manager to become a
    CM Manager again:
    
    	<WRITE CHANGE PROFIL USER="MANAGER",PRVAPP="M"
    
    Ciao,
    
    	Simon
                          

I think I know the answer to this, but just for the benefit of the noting world:

You can be an ALL-IN-1 manager without being an Application Manager, but...

Can you be an Application Manager without being an ALL-IN-1 manager?
IE: do you need SYSPRV and/or the OA$MANAGER identifier to be a CM manager?

Also, is there any difference between an "Application Manager" and a
"CM Manager", or is it just two names for the same thing?

Scott

>Can you be an Application Manager without being an ALL-IN-1 manager?
>IE: do you need SYSPRV and/or the OA$MANAGER identifier to be a CM manager?
    
    Well, it all depends. You do need to have VMS privileges to be able to
    install TXLs or FLCs after compilation, but you don't need OA$MANAGER,
    just OA$MANAPP. This is one of the reasons why form CM$SM was moved
    out of MANAGER.FLB (which requires OA$MANAGER) to CM$MANAGER.FLB. 
    
    One way of looking at it is to say that a CM manager performs all the
    tasks shown on the "Manage a Customized System" menu, whereas an
    ALL-IN-1 manager performs the tasks outlined on the menus in
    MANAGER.FLB. 
    
    In practical terms I believe that ALL-IN-1 Managers (normally one
    person) will continue to work as CM Managers until people start to
    allocate tasks better than is done today (on the majority of sites).
    
>Also, is there any difference between an "Application Manager" and a
>"CM Manager", or is it just two names for the same thing?
    
    Yes there is a difference. Application Maintainers (not managers) deal
    with the elements contained within a single application, for example OA
    (ALL-IN-1 itself) or L123 (Lotus 1-2-3 for ALL-IN-1). A maintainer for
    one application might not have any access whatsoever to other
    applications.  The CM manager on the other hand has access to all
    elements on a system, no matter what application they belong to.
    
    Scott - if you come along to the CM presentation at U.S. DECUS next
    week I'll try and define the differences for you personally.
    
    Tony

    
    Tony,
    
    You do need to have OA$MANAGER to be a application manager.
    When trying to nominate an account as an application manager
    a check is made and you will not be able to do it until the account has
    it.
    
    Interestingly I think that this restriction was added to solve the
    problem of the Script Symbiont problems describe in another note.
    
    I think Simon can take it from here.
    
    Ta,
    
    Mike
    
    PS.  The books brill. Ta
    PPS You can quote me on that on the back of the next one :-)
    

    How many CM "experts" does it take to answer a note?

    Re. 5
    
    Yes, it's true that we check for OA$MANAGER, but that's only because we 
    practice "safe CM" (or maybe "safe ALL-IN-1"?)  Anyway, I still hold to 
    the argument that, in general terms, you don't need the OA$MANAGER 
    identifier to perform the work of a CM manager. 
    
    However, as I pointed out earlier, in most cases the CM manager will be 
    the ALL-IN-1 Manager aka the System Manager and we're all discussing a 
    moot point.
    
    Tony
    
    PS. Mike you're so kind. Does Brill mean "must buy"?

    
    Re .5
    
    Mike, no, the check for OA$MANAGER wasn't added to 'fix' or 'avoid' the
    problem with the Script symbiont. The Script CM_SM_SWITCH_PRVAPP.SCP
    checks for SYSPRV (just like all MUA_*.COM procedures do, only not for
    the full list of privs). However, it only checks SYSPRV and not
    DEFSYSPRV. 
    
    Ciao,	
    
    	Simon