Conference iosg::all-in-1_v30

OH yeah!

There was nothing interesting in the OA$LIB:*RENA*.* log
files - no error messages and so on.

I have supplied both the log files below (1 for each of the
users they tried to move.....).

*** LOG FILE REMOVED (FOR NOW!) TO IOSG::NOTES$LIBRARY:ALL-IN-1_2454_1.LOG ***
*** GRAHAM

Hi again,


This is the same customer as has the problem described in note 2446 and he 
is starting to get a bit impatient with me.  Please post 
comments/solutions or, at least, a statement to the extent of: "we know 
about the problem and are/will be doing something about it" type of thing!

Waiting ..........


Thanks and regards,

		Bjarne

    Bjarne,
    
    Please remember that we investigate problems mentioned here in our
    spare time between doing other tasks.
    
    Could you please supply:
    1) examples of the exact ALL-IN-1 usernames involved    
    2) examples of the exact VMS usernames involved      
    3) examples of the exact default login directories   
    
    If appropriate, e.g. in the ALL-IN-1 username, please show any
    multi-national characters.
    
    We have an enhanced logging facility here for Rename, and will try to 
    replicate the problem with your examples. 
                                                          
    DaveT

Dave,


Your help is much appreciated, indeed (did not mean to sound ungrateful)!  

Examples of ALL-IN-1 usernames are: 	NFBAERAAS
					NFOPLAND

VMS usernames are the same as the ALL-IN-1 usernames, repectively.


Default login directories are:	DISK2:[NFOPLAND] (from Authorize)
				DISK2:[NFOPLAND.OA] (from A1 Profile)
			and
				DISK2:[NFBAERAAS]
				DISK2:[NFBAERAAS.OA]

These are the details RESULTING from the RNA.  If you need info on what 
these were before the RNA I need to get back to see if the customer can 
remember.  They are, however, going to Rename another one, so if you tell 
me how and what they can do to capture some more info, I'll pass it on to 
the customer.  If they can set verify/trace inside any of the files that 
are part of the RNA process, then we may get some more stuff.  I just need 
to know how.


Cheers,

	Bjarne

    Hi Bjarne,
    
    Thanks for the information. It would be helpful if the customer could
    supply the original usernames from before the RNA, though this may be a
    'red herring'!
    
    Meanwhile, for starters, I will supply you the SM_RENAME.SCP that I am
    using here. It provides much better RNA logging, and perhaps will
    indicate to your customer what is going wrong. If they are using V3.0
    then this should patch easily onto it, by copying it to OA$LIB: (be sure
    to check though, that the file ownership is the same as all the other
    SM scripts and coms in OA$LIB:, otherwise A1SUBMIT will throw up. See
    if you can get it patched before they attempt the next users.   
    
    If, as may well happen, this enhanced log does not show the problem,
    then we will have to do as you suggest, and set some trace and verify
    in the Rename procedure, to investigate further. If the need comes to
    do this, I will show you how and where.
    
    Meanwhile, a colleague is currently tackling a number of known problems
    with RNA. I'll talk to him to see if any that he knows of, could be
    causing your difficulties.
    
    Cheers,                                                   
    DaveT

    Bjarne,
    
    I have sent you a copy of sm_rename.scp that could be patched on their
    system. 
    
    A hunt through our database showed this one:
    
"Title: RENAME ACCOUNT FAILS ON LOGICAL DRIVE                             
                                                                                
Rename of account fails if VMS account is held on a device pointed to by a
rooted logical.

The customer attempted an SM MUA RNA operation on a users account. After the
job completed they found that they still had the old Profile as well as the
newly named Profile, but the new Profile still pointed to the original VMS
account. However there were no errors in the log file.
The customer is now aware that this situation is due to them using rooted
logicals to point to the directory structures' in question. They have been able
to use the workaround of creating a dummy MFD [00000] for the device. However
they find this unacceptable as a long term solution. They have many many
accounts set up in this way (and have had for several versions of ALL-IN-1) and
may need to do large scale Renames. They therefore request that this problem is
rectified in the future."
    
	This may be fixed in a possible future release ;-)
    	DaveT

Dave,


Thanks very much for you help with this!


Details for the old users are:

	TPBAERAAS renamed to NFBAERAAS  
	TPOPLAND renamed to NFOPLAND
	(Same disk for default login =(DISK2)befor and after RNA, VMS 
	directory changed according to name change (i.e. from TP* to NF*, 
	ALL-IN-1 user name same as VMS acc name for each user)

Customer says that he specified passwords for the Renamed accounts that may 
well already have been defined in the VMS PW History file.  Perhaps this 
could affect the RNA?  He was asking,if this was the case, should he expect 
an error message (which he did not get) or could the whole RNA fail?

B.T.W., I can not seem to find the new SM*.SCP file you sent me.  Could you 
please resend to OSL10::BJARNEC_P or copy to OSL10:: and I will give it to 
the customer before he does his next RNA (possibly today).


Thanks,

	Bjarne

Dave,

Forgot to answer your question re. whether or not the device these users 
are on is defined as a concealed device.  It is defined as follows:

	DEFI/SYS/EXEC DISK2 $1$DUA2:

..... so that should not be the problem.


Regards,

	Bjarne