Conference iosg::all-in-1_v30

    Grazielle / Andrew,
    
    The rename updates the DDS subscriber entry partially.
    
    The code in SM_RENAME.SCP shows that only the useridi is modified,
    oa$lib:subscriber_change will exit at ones because oa$dds_prime = 0.
    

.TEXT "Updating the Mail Directory entry"
	  WRITE change subscriber -
	    useridi = #a1_username, useridi = #new_a1_username 
	  GET #dds_account = #new_a1_username 
	  DO oa$lib:subscriber_change
    
    
        Regards,
    
        Jan

    
    I've seen this mentioned in note 1243, but nothing came of the
    discussion in there, so here goes.
    
    When renaming a user, the DDS entry for that user doesn not get
    updated, because the SUBSCRIBER_CHANGE.SCP is never executed to
    completion. In the command procedure OA$LIB:SM_RENAME.COM, there is a
    section which reads:
    
    $!
    $! Turn off DDS for when we send out mail at the end of the script
    $!
    $	DEFINE/PROCESS/EXECUTIVE OA$DDS_PRIME 0
    $!
    
    but later, in OA$LIB:SM_RENAME.SCP, it calls the script
    SUBSCRIBER_CHANGE.SCP, where one of the first things it does is check
    the value of OA$DDS_PRIME, and exit if it's set to zero, as this means
    that we're not using DDS:
    
    .IF oa$dds_prime ENS "0" THEN .EXIT
    
    so the users details will never get updated in DDS.
    
    Why was OA$DDS_PRIME set to 0 at the top of OA$LIB:SM_RENAME.COM? Can
    it be safely commented out, so that the users details will be changed
    in DDS, or should we temporarily turn it on and off (and if so, where?)
    
    Help?
    
    Steve.
    

    The reason DDS is turned off is, as the comment vaguely explains, so
    the mail sending of the logs works properly. What happens in a real DDS
    network is that there are several systems each with the MANAGER account
    geting an entry in DDS, so when the code tries to send a message to
    MANAGER, it gets looked up in DDS and doesn't necessarily find the
    MANAGER on this node!
    
    Hence the turning off of DDS to make the address translation happen
    from the local profile only. It would seem sensible to move this
    logical definition down to the place where the mail is actually sent.
    Of course there may be several places where this happens, and that's
    why the logical was defined at the top of the file.
    
    Graham

   Hello again,

   ... I confirm that the RNA option doesn't update the DDS entry...
   also the userid, after the account rename,  doesn't change!

   I think that is a bug.

   Any infos about this problem are more than welcome!

   		Bye

		Graziella   
  


....how the Rename was specified	

Existing ALL-IN-1 account : TEST_DDS
New ALL-IN-1 account name : TEST_DDS_DEC   
     New VMS account name : Set up auto-forward account ? : N

New user details:

Surname:	Duck
Given name:	Donald
Full name: 	Donald Duck
Initials:	DD	   Generation:

Other names (or spellings) people might use for this user:

Given name:
Given name:
Surname:
Surname:
Initials:

Enter new details and press RETURN, or press EXIT to leave the name 
unchanged


...how the DDS entry appears after the account rename


	Given name			: Digital
	Surname				: Test
	Initials			: DT
	Name				: Digital Test
	Proxy user agent		: OA$AGATA$ALLIN1
	Master copy owning node		: AGATA
	MHS/VMS address number		: 1
		MHS User ideentifier	: TEST_DDS
	Access Time			: 15-SEP-1992 13:49:02.56
	Update Time			: 15-SEP-1992 13:49:02.56
	DDSID				: 21280A8000960A86102EDB0023840000

Rename User Not Updating Mail Directory Subscriber Entry As Expected


COPYRIGHT (c) 1988, 1989, 1990 by Digital Equipment Corporation.
ALL RIGHTS RESERVED. No distribution except as provided under contract.


PRODUCT: ALL-IN-1 IOS V3.0

OP/SYS: VAX VMS

SOURCE: Customer Support Center / USA


PROBLEM:

When an account is renamed in ALL-IN-1 V3.0 using the RNA option,
the corresponding subscriber entry for the user in the Mail directory
(DDS) is not renamed.


ANALYSIS:

The rename command procedure SM_RENAME.COM sets the logical for DDS
prime to 0 (turning DDS off) right in the beginning.  This is done
for when the rename script (SM_RENAME.SCP) needs to send mail.  However,
turning off DDS causes the update in DDS not to occur.


SOLUTION:

As an alternative to avoid this problem comment out the define
statement in the SM_RENAME.COM as follows:

Change the line:

$       DEFINE/PROCESS/EXECUTIVE OA$DDS_PRIME "0"

to:

$!      DEFINE/PROCESS/EXECUTIVE OA$DDS_PRIME "0"

Change the lines in SM_RENAME.SCP :

!+
! Now issue the failure message to the Administrator and the MANAGER:
!-

to:

!+
! Now issue the failure message to the Administrator and the MANAGER:
!-
GET OA$DCL = "DEFINE/PROCESS/EXECUTIVE OA$DDS_PRIME 0"