Conference iosg::all-in-1_v30

    Tony,
    
    OK I'll open the batting with a question about status K.
    
    The Note: in the book says "You must resolve the conflict manually
    BEFORE you install ALL-IN-1 version v3.0"
    
    Even I understand that but then about 4 paragraphs down it says:
    
    "if the conflict has arisen because you have customised an element 
    supplied with a K patch, or with WPS-PLUS version 4.0 compare the
    element supplied with ALL-IN-1 version 3.0 and use customisation
    management to apply any changes necessary"
    
    Given that at this stage the customer hasn't upgraded to v3.0 s/he
    will be unable to compare the element and resolve the conflict and this 
    sort of contradicts the earlier section.
    
    I'm guessing and I know you'll correct me that what this really means
    is that in the case where you are unable to fully resolve the conflict
    it is sufficient to just Remove the element from live, do the upgrade
    and then resolve the conflict immediately after the conflict.
    
    What do you think?
    
    Regards,
    
    Andrew.D.Wicks
                            

    Resolving the conflict (to me) means that you remove the element out of
    harm's way and allow the ALL-IN-1 V3.0 upgrade to proceed unhindered.
    Moving mandatory elements out of the live area back into development is
    the best way to resolve the problem. Another way is, of course, to
    extract the element from the V3.0 kit and print the differences, but
    this is too hard to do for anything but a few elements, so I'd steer
    away from it.
    
    After the upgrade the elements can be compared and full resolution
    performed. Normally this will mean checking the contents of the V3.0
    element, seeing where they differ with the site version, and deciding
    which version you want to continue to use (or which bits from both you
    want to combine into a new site version).
    
    Tony 

    
    After running the CART today, I was surprised to see the number of
    CBIxxxx (approx 75), CMxxxx (70ish), SAxxxx (40ish), and SMxxxxx
    (approx 80) elements with status A (i.e. ALL-IN-1 v3.0 don't
    use this anymore!). Can anyone confirm the rough number of these
    elements I *should* be seeing please?
    
    Also an element X400.CMU (type CMU) comes out a status R, i.e. type
    unsupported in v3, is this true? I thought i saw CMU in the standard
    types...
    
    

    I believe that there are about 500 elements in status A, in other
    words, those that have been removed from the kit.  Lots of CBI
    elements, all the old TM (V2.0) interface and the old EMD (DECmail)
    interface are gone now.
    
    Status R are elements that weren't supported before. They could be now
    (as in the case of CMU), but maybe they have been added in such a way
    that our support (in V3.0) doesn't work (for example, if CMU was
    something different to what we expect a CMU to be), so flagging it as
    status R makes you check... OAET.MAR will be reported under status R
    for all WordPerfect sites - we don't support MAR element types in V2.4
    or V3.0, just another example to play with.
    
    Tony

    
    Andy,
    
    Keep in mind that only when the CART runs from the ALL-IN-1
    installation menu you would see *.CMU appear with status R. At that
    time we know that you come from V2.*, and we supplied a stripped
    version of CM$ETYPES.
    
    However, once in V3.0, this won't be the case any longer. If you ran
    the CART before the upgrade, you performed the necessary actions, you
    upgraded to V3.0 and then you run the CART again from the CM CART menu,
    the element won't have status R again as it is 'supported' now. 
    
    Preventing confusion...
    
    Ciao,
    
    	Simon

    Hi CART Team,
    
    A customer has had problems with the execute procedure from the
    Applications Maintainer's menu (AM) when the CC option was selected.
    The appropriate Cart ID was selected and the CC option on the Conflict
    Checking menu was selected.
    
    The customer reported that the process went into a loop (process had
    been running for 20+ hours) and never updated the elements in
    CM$SITE_HIST.DAT.  Are there circumstances that would produce this type
    of behaviour again I find myself in a dificult situation with a
    Government site that is unwilling to let me dial-in or have any form of
    access to the system.  Any pointers would be useful in diagnosing this 
    problem.
    
    Thanks for your advice in advance
    
    Sunil

    
    Hi Sunil,
    
    I'm a bit confused what option is selected now. You refer to 2
    different options:
    
    Clear is: AM CC,the Conflict Checking menu.
    
    Then, is the customer running:
    
    	CC	Check conflicts
    or
    	EP	Execute procedure
    
    Option CC will create a resolution procedure, which can be called via
    the option EP. EP will update CM$SITELOG.DAT and CM$SITEHIST.DAT.
    Option CC definitely won't update these data sets.
    
    We know about a possible CPU loop when running the CART (equivalent to 
    option CC) from the installation procedure (note 957), but that piece
    of code is not called when using option CC.
    
    The option EP modifies information in CM$SDC.DAT, CM$SITELOG.DAT and
    CM$SITEHIST.DAT (all in OA$DATA_SHARE). Can you check if:
    
     	- these data files are there (with those names)
    	- they aren't corrupt (like sequential)
    	- the procedure CM_CART_SCRIPT_<Run-Id) DO <app area> is in CM
    	- if possible, get a TRACE (but that's the ultimate, as I
    	  understand that they're not quite willing to let you dial in)
    
    Ciao,
    
    	Simon
    
    
    

    Sunil,
    
    A $SHOW DEV/FILES on the ALL-IN-1 disk would probably be helpful.
    whilst it's still looping of course.
    
    I think you're running EP because otherwise you'd have told us what the
    last line on the screen was (e.g Scanning for element MAILMEMO1)
    wouldn't you?
    
    also even though i'm not going to blame this on the disk controller
    (:==:) could you tell us whether you are running any strange dialect
    of the AMERICAN ENGLISH language such as BRITISH or AUSTRALIAN
    (this is honestly a serious question)
    
    Regards,
    
    Andrew.D.Wicks
                  

    Hi CART Team,
    
    The customer solved the problem magically and was not sure how !  I
    wonder if it's got anything to do with me asking such questions as
    below that I got from the replies here ?
    
    The option EP modifies information in CM$SDC.DAT, CM$SITELOG.DAT
    and CM$SITEHIST.DAT (all in OA$DATA_SHARE). Can you check if:
    
            - these data files are there (with those names) 
    
    		they were there
    
            - they aren't corrupt (like sequential) 
    
    		customer did not answer this question
    
            - the procedure CM_CART_SCRIPT_<Run-Id) DO <app area> is in CM
    
              customer did not answer this question
    
            - if possible, get a TRACE (but that's the ultimate, as I
              understand that they're not quite willing to let you dial in)
    
              The trace did not produce anything the A1TRACE.LOG was empty.
    
    Sorry I could not shed more light on the subject I just thought that I
    would fill you in.  I hate leaving loose end.
    
    Sunil