Conference iosg::all-in-1_v30

    
    Steve,
    
    When CM is initialized, we wanted to make sure that we (aka the user)
    would work from a known environment. That included (SITE)MEMRES and
    (SITE)OAFORM. These entries have been added to the templates you
    mentioned in .0. 
    
    During initialization a new string of form libraries
    is build (the ones from the template) and is then merged with the
    current value of OA$FORM_SEARCH_ORDER. The form libraries mentioned in
    the new string 'move place' when they're also found in the old
    value. All libraries in the old string which are not mentioned in the
    new string will be put at the end. So the CM library search is put on top
    of the current search order, (SITE)OAFORM included.
    
    Now anyone can argue that (SITE)MEMRES and (SITE)OAFORM will be open at
    all times so that CM is too cautious. But again, we wanted a known
    environment.
    
    To avoid (SITE)OAFORM to be up front the libraries in the FRMLIB field,
    delete both entries (OA$LIB:SITEOAFORM and OA$LIB:OAFORM) from your
    personal template (personal = template in OAUSER:). 
    
    HTH,
    
    	Simon
    

    
    Thanks Simon...
    
    Steve

  
    Does the option SSO (Set Search Order) from the Set Customization 
    Environment work?  If I specify a search order name that has been 
    established for an element search order only (with no corresponding 
    form library search order of the same name), the operation won't 
    complete...the message returned is
    
    "Search order not modified"
    
    If I create a new form library search order (for example, use
    CM_MANAGER as a point of departure, and insert USER.FLB before 
    the SITEOAFORM/OAFORM pair, then attempt to Restore this order, or 
    institute it with the SSO option, the operation still won't complete, 
    rather, that puzzling boxed message displays indicating 
    
    "OA$LIB:CM.FLB will not be in your library search order.  This will 
    make Customization Management unavailable..."
    
    In the latter case, the search order will get set, but I get kicked 
    out of CM...(without actually having removed CM.FLB from the search 
    order).
    
    Is this behavior also a function of what's described in .1 ?
    
    Thanks,
    
    Steve

    Re .3,
    
    Well Steve just walked over to my desk and we couldn't reproduce this
    one on either of my machines so it's possible it just might be another
    of those 'been through too many baselevels of DIAMOND' ones unless
    there's something else setup on these systems that we didn't spot.
    
    Regards,
    
    Andrew.D.Wicks                                                   

    OOPS I lied ... and I just know that Faith is going to give me a hard
    time for not using STARS to look it up (:==:)
    
    A variation of this has been reported during FT and  has a number
    THR-15702 try typing:
    CM SCE MEO
    CN
    GOLD F
    SAVED
    EXIT SCREEN
    SCE
    SSO
    SAVED
    
    Gives Search Order not modified.
    
    Regards,
    
    Andrew.D.Wicks
                        

    
    Steve,
    
    Re 1st part: Yes, THR-16702 is still there. The SSO option sets the
    element search order only if there is a valid library search order.
    Untill fixed in a PFR, the workaround is to either set an element
    search order only from the MEO menu or to create a library search order
    with the same name as the element search order, and then use option
    SSO. SSO looks for both (but you will not experiencce the problem if
    only a library search order exists).
    
    The second part:
    
    How is your template entry for CM.FLB? OA$LIB:CM, OA$LIB_LLV:CM? The
    SSO code checks for OA$LIB:CM.FLB (not too clever). The option RS
    (Restore saved order) on the MEO is correct. It strips logicals and
    extensions from an entry and then checks it against "CM".
    We know about this.
    
    HTH,
    
    	Simon

    
    
        Simon/Andrew,
    
        Thanks for the help!
    
        The record listed was indeed OA$LIB_LLV:CM....I edited out the 
    	"_LLV" and that fixed the problem.
    
        If I've figured this correctly, one of the instances in which the
        OA$LIB_LLV logical will get used is if the  manager/programmer
        /maintainer has an entry for OA$LIB:CM.FLB specified in 
        PROFIL.FRMLIB - that was true in this case.  
    
        Steve

    
    
    All of this valuable information is now available in STARS! Thanks
    to all for contributing.  Stay tuned to STARS for more juicy
    tidbit.
    
    Faith Donohue