Conference iosg::all-in-1_v30

    Don't redefine the OA$LIB logical search list, that's for sure. OA$LIB
    is for the OA application area, so it shouldn't be used for other
    applications.
    
    If you do set up an application, you'll have a set of logical names
    that map the authorized locations within the application. You can then
    either:
    
    o Use explict references to the logical names
    
      i.e.  DO XYZ$LIB:MY_SCRIPT
    
    o Include the live locations into the TXL
    
    o Redefine the default search order by including the logicals for the
      application int the list defined by OA$FILE_SEARCH_ORDER
    
    Tony

    
    Kevin,
    
    Also depends whether or not you mean Users or Programmers with 'select
    users'. In case of Programmers, add the Development area and form
    libraries, and the Live area and form libraries to the private search
    orders (CM SCE MEO/MLO). 
    
    In case of users, I think numerous ways of invoking an application have
    been described here (or in archived conferences). In addition to .1
    don't forget to give access to the form libraries, either by opening
    them via OA$FLO_OPEN or add them to the OA$FORM_SEARCH_ORDER special
    symbol.
    
    Ciao,
    
    	Simon

    But ...
    How can we reference each source object ?
    (i.e.: if I've a menu form that calls a script XXX, in the named data I
    write "DO XXX", without logical)
    
    Any programmer can easily modify the "private search order". 
    
    So, how is it possible to modify the user's "private search order" ?
    (in OAINI.SCP   or from ALL-IN-1 MGR account ?)
    
    Thanks in advance
    
    Roberto AGIP Colombo
    

    
    Roberto,
    
    .1 explained the 3 different ways of how users can access the 'source
    objects', be it procedures. 
    
    However, the more we think about it, the more the profile field XOWN
    gets 'in the way'. When set to 'N' (refer to note 34) every call to user
    specific procedures/forms is dicarted. 
    
    The symbols OA$FILE_SEARCH_ORDER will NOT include '[]' any longer, as
    to be expected. That same symbol and OA$FORM_SEARCH_ORDER become
    Read-only symbols, and cannot be changed. This means that redefining
    the OA$FILE/FORM_SEARCH_ORDER to include your applications files (as
    in V2.*) will not work...
    
    A partial solution to this is for the TXL elements and the form
    libraries:
    
    	BLP, SCP and DO into the TXL
    	Form libraries to be referred to (via system exec logicals) in 
    	   PROFIL.FRMLIB
    
    Calls to any other file should then include the location specification
    (COMMAND AGIP$LIB_AGIP:AGIP_DOCCREATE.COM), but that's just what you
    try to prevent.
    
    Now, everything works fine for all elements of the OA application when
    the XOWN field is set to 'N'. However, for other applications the XOWN
    field definitely implies restrictions. We'll have to check this
    further.
    
    When the XOWN flag is set, then consider one of the following
    solutions:
    
    Create a system element/library search order. This can contain the
    actual order to be used with a number of applications included. Or
    create 1-n search orders, e.g. for specific situations (a number of
    people can use onlu applications A, B and C, other can only use A, C
    and D, etc.). Then, from OAINI.SCP check which search order is valid
    for the user (PROFIL flags?, any other mechnism?), load the search
    orders and voila.
    
    Another way could be a menu with 'account' dependent menu options,
    referring to the different applications. When starting an application
    the former search orders might be reset (e.g. GET OA$FORM_SEARCH_ORDER
    = "" -> (SITE)MEMRES and (SITE)OAFORM reside), call an initialization
    procedure which will add the necessary search orders and the
    application can be used.
    
    Then,... 
    
    So, there are a number of solutions, but the XOWN field value becomes a
    critical issue here.
    
    Ciao,
    
    	Simon

RE: the last four notes, I'm confused.

In V2.4, you added customisations to SITEOAFORM etc., made them live, & users 
could see them no problem.

So now in V3.0, I to create an standard Application Area, as described in the 
documentation (what little details there is), create new application elements, 
make them live, do a CCM, & PCF on the new form library, and now I finally 
want to MAKE THE CUSTOMISATION AVAILABLE TO ALL USERS (highlighting not 
SHOUTING).

Q1	 If the answer lies with OA$FILE/FORM_SEARCH_ORDERs, as discussed in 
         746.1,2,4, then how should I do this ?

Q2	 I have followed 746.4's "rules", except the "directory reference" 
         bit.  Does it mean that I should create my own list e.g.

	 OAX$FBS points to:
	      FBS$SITE_LIB_FBS_BRITISH
	      FBS$SITE_DO_FBS_BRITISH
	      FBS$SITE_BLP_FBS_BRITISH
	      etc.

Thanks in advance for any help,

Confused-of-Bristol

    Hold on a minute...
    
    You do not need to create application areas to allow customizations to
    occur in ALL-IN-1 V3.0.
    
    Application areas should only be created when:
    
    -- You have a discrete application
    -- That application is composed of files which are stored in 
       directories that are not part of the standard ALL-IN-1 directory
       structure.
    -- The directories are mapped by system logical names defined in
       executive mode.
    
    Standard customizations, in other words, customizations of base
    elements or add-ons which will be made available to all users can
    continue to be made in exactly the same way as V2.3/V2.4.  You make the
    customization (element is stored in ENGLISH (or LLV area), or SHARE),
    and the move to live places the customized element into one of the
    standard site locations, for example SITEOAFORM.FLB.
    
    If you decide to create a new application area then you take
    responsibility for managing the contents of that area as well as the
    need to make the application available to users.  Remember, your
    application is separate to standard ALL-IN-1, the OA application.
    
    So you have to include some sort of initialization procedure that
    allows users to access your application.  The procedure should open the
    application-specific form libraries, install any AIM images that are
    required, and play with OA$FILE_SEARCH_ORDER if necessary.  The last
    point is optional because you can always use explicit calls to the
    application elements.  For example,
    
    DO OAX$MYAPPL_LIB:APPLICATION_START.
    
    I know the documentation isn't great at this point, but it is a
    reasonably complex area and not many people really need to create new
    application area (and accept all the management responsibilities that
    go along with that decision).  Note that I said "really need" rather
    than "really want".  The desire to create application areas is, in my
    opinion, higher than the actual need.
    
    Anyway, FWIW, the whole topic is discussed elsewhere in this conference
    and will be covered in the new book.
    
    Hopefully this helps, 
    Tony