Conference iosg::all-in-1_v30

    And the customer is using DDS.
    
    Could it be that when the Meeting is created and sent out first time
    the usernames are validated against ALL-IN-1's profile data, and when
    updated (Meeting Request is edited or cancelled) it is checked against
    DDS?  Incidentally, they seem to use these Norwegian "Extra" characters
    (�, �, �) both in the users username in ALL-IN-1 and as first entries
    for Surname and Given name in DDS.  I know that this sort of thing can
    create problems when for instance sending X-400 mail to other vendors
    gateways and so on, but could it also be causing the problems here?
                                                                      
    
    Cheers,
    
    	Bjarne

    This problem has not been reported as yet. 
    I would guess it is due to the ATTENDEE.DAT file containing uppercased
    information. A code level fix will be required (if possible!).
    
    I assume you can reproduce this.
    Please submit an IPMT report.
    
    Alan

    Alan,     
    
    It appears that the data in ATTENDEE.DAT does not keep the "Extra"
    Norwegial characters.  Doing a search "" of the file on the system I
    just used to test the scenario showed up the following:
    
    Actual ALL-IN-1 username:  		BT� TEST��
    Search of ATTENDEE.DAT:	'number'BTA TESTOA
    
    Actual ALL-IN-1 username:  		�BT ��TEST
    Search of ATTENDEE.DAT:	'number'ABT OATEST
    
    Actual ALL-IN-1 username:  		B�T �TEST�
    Search of ATTENDEE.DAT:	'number'BAT OTESTA
    
    
    So what seems to happen is that the characters �, �, and � (now that
    everyone and everything is restructuring and rationalizing, I think
    that we should do away with them - it would certainly make my life a
    lot easier ....!)is replaced with A, O and A, respectively, in the
    ATTENDEE.DAT file.  Whenever an update is made to the Meeting Request,
    then the info is taken from the ATTENDEE.DAT file and this will of 
    course not check out against the ALL-IN_1 username for that user.
    
    I assume it is allowed to use these "Extra" characters in 
    ALL-IN-1 usernames !?!
    
    How do I go about submitting an IPMT report?
    
    Can anyone think of a workaroud for the customer?
    
    I was planning to submit a CLD, so that engineering could asess the
    problem.  I suppose this will be instead of this IPMT report?
    
    
    Thanks,
    
    	Bjarne
   

    Bjarne,
    
    I cannot reproduce this on my V3.0-1 system. Can you test it on yours.
    
    I created an event inviting �CHAR@NOWHERE
	and the ATTENDEE file contained the correct address
    I do not have access to a DDS machine but I would not expect this to be
    the problem.
    
    By the way I thought the ONLY way of submitting problems to Engineering
    was via IPMT. You may use yor old method(SPR) as a bridge to get the problem
    submitted into IPMT.

    Alan,
    
    The system I did the tests on is an internal installation in Digital
    and it is Norwegian ALL-IN-1 V3.0 (i.e. not upgraded to 3.0-1).
    
    I created 3 test user accounts from ALL-IN-1, all of which with
    �, � and �'s  both in the First - and Surname.  Then, from the
    ALL-IN-1 Manager account I sent out meeting requests to them which
    worked fine - I could use Gold L to find all of them, and they all got
    notified of the meeting.  However, searching the ATTENDEE.DAT file I
    found that all the names had been entered with �, � and � replaced by
    A, O and A, respectively.
    
    Although the system that I tested this on is running ALL-IN-1 V3.0, the
    cutomers system is upgraded to V3.0-1 (Norwegian version).
    
    Should I still send in an CLD?  What can I try next?
    
    
    Cheers,
    
    	Bjarne
              

    Alan,
    
    And, also when I go back in and does a "List" of all meetings, select
    one and does a READ, all attendees have had their characters changed,
    but the other info in the meeting request (like the Reason and Place
    fields) are OK - they keep any �, � and �'s entered during creation or
    modification of the request. 
    
    This is what I get when I do a Read:-
    
    Opprettet av:  MANAGER       (=created by)
    
     Dato:          21.okt.1993       Start kl: 16:00     Slutt kl: 16:30
     Form�l:        BT M�te      (=Reason)
     Sted:          Rom 2        (=Place)
     Konfidensielt: J
    
     Deltagere:                  (=Attendees)
     ABT OATEST                  (ALL-IN-1 Profile: �BT ��TEST)
     BAT OTESTA                  (ALL-IN-1 Profile: B�T �TEST�)
     BTA TESTOA                  (ALL-IN-1 Profile: BT� TEST��)
                                                  
    
    Regards,
    
    	Bjarne
                                

    Have done a trace of my test system when I tried to modify the meeting
    request.  The mail to notify the attendees failed.  I copied the trace
    (A1TRACE.LOG) and also the ATTENDEE.DAT file to SNORRE::.
    
    
    Bjarne

    Bjarne,
    
    PLease only use CLDs for CRITICAL problems. The extra work and
    overheads involved in processing CLDs needs to be considered before
    raising one. If this problem is causing the customer extreme grief and
    you feel a CLD is justified then of course you must do this. However,
    please realise that a CLD is NOT the normal Formal method of reporting
    problems to Engineering. I assume you have a method of submitting
    problems to engineering groups!
    
    I have tried creating a User �BT �TEST on V3.0-1 and inviting them to
    a meeting and it worked O.K. The ATTENDEE file contained an entry
    ....�BT �TEST and the Attendees were displayed correctly when reading
    the Event.
    
    Can anyone else reproduce this on their V3.0 systems???
    
    I am confused in that if your ATTENDEE file is not storing the Attendee
    names correctly then I would assume that Replies to Meeting requests
    would also not work.
    
    Can you test the same problem on an English language system. I do not see
    how translation could have affected this but stranger things have
    happened.  It appears that our test systems are built so that I can
    never reproduce problems! 
    Do you have DDS on the system you tested with??
    
    Also do you have any customizations or Assetts?
    
    Can you test with ALLIN1/NOCUSTOM
    
    Have you any patches installed ?
    $ type oa$build_share:A1PATCH$CONFIGURATION.DAT
    
    
    Regards
    Alan
    

    Bjarne,
    
    If the ATTENDEE file information is incorrect then and changes to the
    Event will be mailed to the wrong ATTENDEES. Thus the trace will
    probably show nothing new. I assume the original Event notification is 
    sent correctly. A trace of this might help.
    
    Regards
    Alan

    Alan,
    
    
    Creating a meeting and notifying the users with these characters in their
    usernames is no problem, that is , the notification is ALWAYS
    successful - they receive the mail (meeting request).  It is only when
    an update like editing the first request is performed the problem
    occurs - the name in the ATTENDEE.DAT file seems to be picked up and
    used when trying to relay the fact that there has been a change to the
    original request - the mail fails and the meeting request gets printed
    out (the PAPERMAIL option).
    
    I have copied a new trace file to SNORRE::(=A1TRACE.LOG;8) which was 
    created during the original creation of a Meeting Request, i.e. a
    successful one.
    
    Just tried something else.  The user that is requested to attend the
    meeting gets his mail request.  If he then replies to the meeting
    invite then the originator of the request gets a reply, AND it appears
    the ATTENDEE.DAT file is updated by the reply to include the users name
    WITH the �, �, and �  in addition to the name with these letters
    replaced by A, � and A (i.e. there are TWO entries in the ATTENDEE.DAT
    file even though the request was only sent to one user - whereas in the
    scenario I have explained earlier (send + modify before reply
    received)) there is only ONE attendee and always without the �, � and �.
    
    P.S. Typed the oa$build_share:A1PATCH$CONFIGURATION.DAT and it appears
    that my test system ahs been upgraded to 3.0-1.  Also did the same test
    under ALLI/NOCUST but exactly the same happened.
    
    As far as I know the customer does not have anything too fancy - only
    LOTUS og RESOURCE SCHEDULER, but since I can replicate the same problem
    here (and I do not have these things) I do not think they can be the
    cause.
    
    I have not logged into the customers system yet, but that would be
    possible.  It would also be possible for you to have a log into the
    customers or my system to do some testing if you'd like.  W.r.t.
    submitting a CLD - I have chacked with our SW "Escalator" and he sais
    that SPR is dead and the only possibility now to reach engineering is
    to send off a CLD (with low priority, probably 4, right enough). 
    Please advice me if there is a better way of doing this.
    
    I'm clocking off in the next 20 minutes or so, so if you want access to
    my system for testing please give me a ring on: 7 872 8449.
    
     
    Hope this helps,
    
    		Bjarne

    Here is what the "READ" option in the appointments menu shows when a
    Meeting Request has been sent and the Recipient has answered the
    request.  
    
                                   Lese avtale
    
     Opprettet av:  MANAGER
    
     Dato:          23.okt.1993       Start kl: 16:00     Slutt kl: 19:01
     Form�l:        Fjerne brukne ribben
     Sted:          Hjemme hos Arne
     Konfidensielt: N
    
     Deltagere:
     ABT OATEST
     �BT ��TEST                     JA    Drikke drikke drikke
    
    
    
    Please note that the 2 participants (=deltagere) is the same person, the
    first entry is written by sending the original request and the second
    one gets written in by the reply to this request (only one person,
    namely �BT ��TEST, was on the recipient list when the meeting request
    was sent by Manager).
    
    Strange, I think!
    
    
    Regards,
    
    		Bjarne
    

    Hi again,
    
    
    Still trying to pin this one down!  Discovered that when I created yet
    another user containing only 2 "Dodgy characters" then it is actually
    written correctly to the ATTENDEE.DAT file.  Blelow is a READ of a this
    test - as you can see the first attendee has had the �, � and � swapped
    for O and A's.  The second one, however, is written correctly to the
    ATTENDEE file!!!
    
    
                                   Lese avtale
    
     Opprettet av:  MANAGER
    
     Dato:          25.okt.1993       Start kl: 18:00     Slutt kl: 18:05
     Form�l:        Trekke alle tennene
     Sted:          Tannlegen
     Konfidensielt: N
    
     Deltagere:
     ABT OATEST   (ALL-IN-1 User Name: �BT ��TEST - VMS U. N.: BT_TEST)
     �RLING �ST   (ALL-IN-1 User Name: �RLING �ST - VMS U. N.: OST)
    
    Maybe the problem is due to some combination (3 or more or two
    together, maybe) of these characters.
    
    I created user accounts with exactly the same names on another 
    ALL-IN-1 V3.0 installation (which had not been upgraded to 3.0-1) 
    and got exactly the there.  Something dodgy must be going on!
                                      
    
    Bjarne 
    
    

    You seem to be finding out that this problem does not allways occur.
    
    I still cannot reproduce this problem on out English systems using 
    Username - �BT ��TEST. I am using a non DDS (OA&DDS_PRIME = "0")
    system and used Compose Character to generate the composite characters
    in the Username.
    
    From the information you have just discovered the problem appears to be
    dependant on the bumber of Composite characters in the Address.
    
    When you submit a Formal problem report please supply full deatails of
    the Address (in pretty name format- Full     (Username)). I believe it
    might be some weird combination of characters that may be causing the
    problem. We need to try to find out exactly what that/those
    combinations are so we can reproduce it on our systems.
    Have you tested this on a NON DDS system??
    
    I am afraid I am currently Busy with several CLDs and thus cannot
    investigate this any further.
    Any help from other Countries might assist us in tracking this down. 
    
    Does Germany, Finland etc. experience this problem ??
    
    I look forward to passing this problem to someone else when we get it.
    
    Regards and good luck
    Alan

    Alan,
    
    
    Thanks very much for taking time to help out!!
    
    I will submit a CLD tomorrow including all my findings.  I agree with
    you.  According to my latest tests it appears to be something to do
    with a weird and wonderful combination of these characters.
    
    Has anyone else had eny problems with this (perhaps on their LLV's).  
    
    I have tried this on two different systems now and I seem to get
    exactly the same results by using the same ALL-IN-1 usernames etc.  1
    name is OK and another is not!  One of these systems is configured with
    DDS and the other one isn't.
    
    I suppose the only way to find out what is causing this problem is to
    make up a whole lot of different accounts containing different
    combinations of these letters.
    
    
    Thanks,
    
    	Bjarne

    Just done some tests on the customers system.  Typing
    A1PATCH$CONFIGURATION.DAT shows the following:
    
    1993-02-27 19:20:52.80 V030_001 EE 005 SHARE          V3.0-1   
    ALL-IN-1
    
    I have also tested against a couple of users on his system and I can
    recreate the problem, although with slight differences from the two
    internal systems I have tried this on.
    
    On the internal systems the problem occured only if EITHER the First
    Name AND/OR Surname contained two or more �, � and �'s (in any
    combination as long as there were two or more).  For instance one of
    these in the Firstname AND/OR one in the Surname would not cause a
    problem.
    
    On the customers system, however, the problem occurs whenever there is
    ONE or more of these characters in either the Firstname OR the Surname.
    Again, A's and O's are written to the ATTENDEE.DAT file and this is
    used to update the user when the Meeting Reques has been modified.  If
    the user replies to the Request, then the correct ALL-IN-1 username is
    written to ATTENDEE.DAT, but this is done in addition to the first,
    erroneous, username (the user has two different entries, one correct
    and one wrong).
    
    I have taken a trace of Creating/Sending a Meeting Request test on the
    customers system.  It is a few hundred lines, so I have not replied it
    into this note.  It can be found on: SNORRE::BT_TM_TRACE.LOG
    
    The user that I called to a meeting has the following data.
    
    	* VMS Username:			LILLEBOE
    	* ALL-IN-1 Username:		K�re Lilleb�
    	* Name written to ATTENDEE file at Request initiation (not a valid
    	  ALL-IN-1 Username):      	KARE LILLEBO 
    
    A CLD is on its way.
    
    
    Thanks,
    
    	Bjarne