Conference iosg::all-in-1_v30

    Beth,                                                       
    
    Can you explain what you mean by blanked out by 12 spaces from
    postition 28? The address that mail is autoforwarded to doesn't
    actually start until position 40 (aka column 39).
    
    Andrew.D.Wicks                       ( WICKS_A@A1@NODE )
    
    Where the '(' is in column 37. The first 37 characters and the
    pretty-name region and usually just contain Remote Addressee
    
    What does <GET PROFIL.MAIL_FORWARD["username"] show?
    
    Regards,
    
    Andrew.D.wicks

    Andrew -
    re -1
    
    I mean 28 positions relative to the start of the AF address.  Currently
    corrupted case in point:
    <get profil.mail_forward["crewtf"]   ->
    Remote Addressee                     ( CREWTF@3=LAAFB@4=SSD0@5=AFS
    
    When I NEWDIR to CREWTF and type EM, I get the message:
    Forwarding messages to  CREWTF@3=LAAFB@4=SSD0@5=AFSfssd@nc )   $D0#Z@UTILITY
    
    Gold W shows 2 more lines; line 2 starts with the ")" and continues:
    )    $D0#=Z@UTILITY:[MB$.DDS.DB]DDS$IDSEC.DAT
    0#Z@UTILITY:[MB$.DDS.WRK]DDS$LOG.DAT
    
    (note: what actually appears following position 28 varies, depending on
    what I was doing prior - I think maybe the routine that generates the
    "Forwarding messages to ..." gets confused by the blanks (pointers
    screwed up?) )
    
    AF only shows:
    ( CREWTF@3=LAAFB@4=SSD0@5=AFS
    
    A dump of the data file, PROFILE.DAT shows that the record for CREWTF
    has blanks following the AFS.
    
    ----------------------------------------------
    Whenever this problem has occurred, the blanks have been in the same
    place.  I know it's only for 12 positions because those with a long AF
    address have the remainder of the address following the blanks (i.e;
    blanks ERASE the characters, not displace them)
    
    EX: if CREWTF AF had been entered as:
    CREWTF@1=US@2=X400@3=LAAFB@4=SSD0@5=AFSSD@NC
    the corrupted address would be:
    CREWTF@1=US@2=X400@3=LAAFB@4            D@NC
    
    Corruption does not appear when the AF is enterred; only some unknown
    time later.  Note: if I manually generate a corrupted address with
    embedded blanks, the AF shows the ")" at the end; it does not do this
    for CREWTF until her address is expanded with Gold W.
      
    
    *** If anyone has any ideas on what could generate these blanks in the
    mail_forward field, I'd be happy to try test cases on a dummy account.
    
    Thanks much!!
    Beth

If the mail_forward field is being corrupted in the Profile, then it amost 
certainly can't be caused by any message processing, as that will only Read 
the profile, not write to it. So these spaces must be being applied by some 
'profile-update' action. It does look as if there is some mismatch between the 
Profile form and the file itself - can you think of any way that could have 
happened? Is the Profile customised?

grahame

    Grahame -
    re -1
    Yes, the Profile is customized.  We have added a rank field of 10
    positions, following the given name field.  However, for the corrupted
    user I have been looking at (CREWTF), a dump of her profile.dat record
    shows a valid rank (CIV).  However, for other records the next field is
    "ENGLISH".  For this record there is a "B" 6 positions before
    "ENGLISH".  Dump/record on oa$data:profile.dat shows:
    
    
    YYYYRemote Addre 000490
    ssee             0004A0
             ( CREWT 0004B0
    F@3=LAAFB@4=SSD0 0004C0
    @5=AFS           0004D0                 <- remainder blank; no ")"
    
          .
          .
          .
    
                  CI 000710
    V         B      000720                 <- other records have no "B"
      ENGLISH        000730
    
    
    Any ideas?
    :-)
    Beth
    

Is there any job that runs that might be opening up the original version of
the PROFIL form(s)?  If your revised form is in SITEMEMRES, then any job/user
that uses ALLIN1/NOCUSTOM would pick up the original.

Any job that might use the original version of the form and then update some
field could easily clobber the RMS record.

/Marty

    RE -1
    Marty -
    
    Thanks for the tip!!  It seems that rank does not appear in the user's
    record when a new account has been created, although the field appears
    on the form.  Two of the cases I recall having been corrupted had had
    their rank changed.  I'm checking with the ALL-IN-1 system manager
    (DECie) to determine what of the account creation/modification forms
    may be using the original profile.
    
    What puzzles me, though, is that the corruption does NOT occur when the
    account is created.  Humm... maybe only Modify uses the new form,
    rewriting the original record.  We'll try to recreate the problem, with
    trace on.  It may also be that it only occurs if an operator or user 
    modifies a user record while the ALL-IN-1 system manager is modifying the 
    profile form (would he have to remove the form from SITEMEMRES to modify 
    it?).
    
    Any other thoughts?
    Thanks for all your help, folks!
    :-)
    f
    Beth

    
    Beth,
    
    When creating a profile, you use form SM$CREATE (talking from SM point
    of view), consisting of 2 forms, which is used by at least
    MUA_CREATE.COM, together with the template, to finish the profile
    record. 
    
    When editing an account you use form SM$PROFILE. Both forms refer to
    '/DATA=PROFIL'. However, if your field isn't on the SM$PROFILE form, it
    shouldn't be changed in PROFIL either.
    
    Not of much help I think.
    
    Ciao,
    
    	Simon
    
    

    By jove, I think we've got it! (but why is this so...?)
    
    Seems we had customized 2.3 forms for SM$EDIT and SM$CREATE.  When we
    replaced them with re-customized 2.4 forms our problems disappeared. 
    (By the way, the secondary problem, that rank did not get stored on
    account creation, was a result of the template zeroing out the field we
    were using!).
    
    What I don't get is WHY?  If the form merely maps to profile
    (/data=profile), what is the difference between a 2.3 and a 2.4 form? 
    Also, could we have just somehow converted the form vs retyping in the
    customizations into the non-customized 2.4 forms?  Maybe all we needed
    to do was a convert/fdl, using the fdl from the 2.4 forms?
    
    Any thoughts?  Also, is there an easy way to determine if we have other
    old 2.3 forms which might cause problems?  (my guess is to do a
    dir/before=whenever_we_upgraded on the .site directories).
    
    
    Thanks again to all!
    :-)
    Beth