Conference iosg::all-in-1_v30

    Kevin,
    
    You can't fool me that isn't one quick question it's about 6 questions
    (:==:)
    
    As Simon is probably at home watching the football let me start off the
    answer and then let him correct me later...
    
    You say you're changing some of the TXL type scripts - if you mean 
    an ALL-IN-1 Base script then you can still do those as customisations
    to the OA application as you did before and it will work as before. If
    you take the conscious decision to move them into a separate
    application area then they appear as new site elements and not
    customisations of base elements and when defining your applications you
    use the AM MAL option to determine whether a particular live location
    is a valid TXL location (CM$AUTH$LOCATIONS dataset).
    
    Your script when it is live is in the application area - it doesn't get
    moved back to the OA area to go into the TXL. the TXL compiler is smart
    enough to loop through CM$MAF and CM$AUTH$LOCATIONS looking for
    elements to compile into the TXL. remember they still is only one CM
    TXL - application specific TXls didn't make it into DIAMOND.
    
    Since there is still one TXL I don't understand what you mean about the
    search list - it still takes a value 0,1 .. which says whether the
    A1TXL comes before or after the CMTXL
    
    If the script is in the TXL then I don't see that user search times
    will be affected - since there is still one TXL - the TXL compile may
    take longer since it has more directories to scan but that's a one-off
    hit for the Application Manager/Maintainer
    
    And finally, CM$SITEHIST isn't transferred when transporting an
    application (CM$SDC, CM$APP, CM$MAF, CM$AUTH$LOCATIONS and CM$SITELOG
    are) and I don't follow why you'd want it to be. You're receiving a
    new copy of an application so you get a set of SITEHIST records that
    say something "application FRED update v2.0 applied to system" and
    that's all you need isn't it - you wouldn't really want it to write 37
    records to your system that were just the interim changes to the
    developer's system.
    
    regards,
    
    Andrew.D.wicks
    
                                            

    Kevin,
    
    Andrews reply is correct. I'd just like to reiterate that the TXLs (CM
    and A1) are system-wide objects although their contents can be from
    differetn application areas.
    
    If, therefore, you have the same named element in more than one TXLable
    area (for example WPPRINT in EARS_SHARE and WPPRINT in SHARE) then you
    need to decide on a system-wide basis which one takes priority and will
    therefore be used for everyone. The TXL compile code will only compile the
    'first' one it encounters. The PRIORITY fields in CM$APP and CM$MAF are
    checked to determine which order the TXL compile code will scan TXLable
    directories.
    
    HTH,
    Kevin

We had a problem today when compiling the A1TXL which had three elements
from two base areas with the same name.

This is what we did:
We moved elements MAILMEMO1.BLP, MAILMEMO2.BLP and MAILATT2.BLP from the OA 
base area into our own application (e.g. CARS) development area, customised
them, and then moved them to the BASE area of our application 
(CARS) because we were the original engineering group.

We compliled the A1TXL because we wanted our base elements to be included 
in the A1TXL. The TXL procedure then proceeded to search for TXL elements 
system wide. When the TXL procedure was compiling the elements, it encountered 
our base elements first (as suggested in the reply below) and "ignored" the 
OA elements when it encountered them (it displayed information messages). But, 
at the end of the compilation we got the following messages:

TXL compiled with 3 duplicate elements
TXL compiled successfully
Press RETURN to continue

When we pressed RETURN, it said "Error compiling the TXL"

When we tested our customisations, our customisations did not work
so and I presume the compilation and installation of the TXL failed
(even though we got the above messages).

The solution was to move the 3 elements from the CARS BASE area to the CARS 
live area and therefore include them in the CMTXL. Our customisations then 
worked. But the point I'm making is that the TXL compilation and installation
failed when elements with the same name were encountered - it was nothing to 
do with whether they were encountered first. Can I disagree with the reply 
    below ?
    
-- Dave


================================================================================
Note 850.2                      Application areas                         2 of 2
FAILTE::LAAHS "An accumulation of Celts"             16 lines  11-JUN-1992 11:26
                  -< Take care with duplicate TXL elements. >-
--------------------------------------------------------------------------------
    Kevin,
    
    Andrews reply is correct. I'd just like to reiterate that the TXLs (CM
    and A1) are system-wide objects although their contents can be from
    differetn application areas.
    
>>    If, therefore, you have the same named element in more than one TXLable
>>    area (for example WPPRINT in EARS_SHARE and WPPRINT in SHARE) then you
>>    need to decide on a system-wide basis which one takes priority and will
>>    therefore be used for everyone. The TXL compile code will only compile the
>>    'first' one it encounters. The PRIORITY fields in CM$APP and CM$MAF are
>>    checked to determine which order the TXL compile code will scan TXLable
>>    directories.
    
    HTH,
    Kevin
    

Actually, your A1TXL compile probably completed.  It's just that without making
some modifications to CM_CTX.SCP it won't re-install the new TXL if there are
ANY "errors" during the compile, including duplicates.

See note 141.*

/Marty

    
    Dave,
    
    Re 1194.0 (which suddenly disappeared):
    
    > ...but is something being done about it
    
    The problems has been reported under THR-16305 (TXL compilation fails
    on duplicates) so work is being done.
    
    I would still point you to note 141.10 for a possible workaround. 
    
    Ciao,
    
    	Simon.
    
    
    PS > This looks like a gap in the functionality
    
       I'm not too sure if GAP wants to be associated with us ;-)...