Conference iosg::all-in-1_v30

    If they're both the same version of ALL-IN-1, wouldn't it be simpler
    to USE ALL-IN-1? You can open the source file (where you will be
    filtering records) using PROFIL, and open the destination file using
    some temporary copy of PROFIL, such as NUPROFIL.FRM, and then do a 
    FOR PROFIL rse DO WRITE ADD NUPROFIL etc. 
    
    Folks, what kind of complications are the idiosyncrasies of PROFIL
    going to throw into this plan, such as /ALIAS and whatever else is new
    that I haven't caught up with?
    
    Bruce

How about:

SM MUA D DP -> Delete profile record

This saves you having to worry about PROFIL or any other nasties...

Scott

    re .1 
    
    >>> You can open the source file (where you will be filtering recrods)
    >>> PROFIL, and open the destination file using some temporary copy of
    >>> PROFIL, such as NUPROFIL.FRM, and then do a FOR PROFIL rse DO WRITE
    >>> ADD NUPROFIL etc.
    
    	Can you give more details about what this means?  I'm very rusty
    in ALL-IN-1 scripts (try version 1.0) and the other system person 
    involved here doesn't know any of the internals of ALL-IN-1.
    
    re .2
    
    >>>  SM MUA D DP -> Delete profile record
    
    The other system person is really working on this part of the project
    and what he really wants to do is work on a copy of the PROFILE.DAT
    from the VAXcluster going down first but while users are still active
    in ALL-IN-1 (like the day or two before the shutdown will take place).
    So there is no impact on these active users.  This is to save time on 
    the other side when there is only one VAXcluster.
    
    Hence, maybe .1 is the way to go here if you can provide more details.
    
    Thanks,

    Hi,
    
    � and what he really wants to do is work on a copy of the PROFILE.DAT
    � from the VAXcluster going down first but while users are still active
    
    It may be easier just to delete records from the COPY by using DCL. Ie:
    
    	$ OPEN/READ/WRITE/SHARE prof_cop PROFILE.COP
    	$ READ/DELETE/KEY="duplicate-to-be-deleted" prof_cop prof_rec
    		.
    		.
    		.
    
    Cheers,
    
    Iain.

    re: .4
    
    For that matter, maybe the simplest way to do this would be using SORT,
    or does it still make its own decisions about throwing away duplicate
    records. (I haven't used it for this purpose since V3.7.)
    
    You would take both data files and merge them together using the DCL
    SORT command. You will have to take special care to select the right
    qualifiers and definitely check the new file by hand and by eye using
    ALL-IN-1 (after pointing PROFIL to the new file, by defining a process
    logical to point OA$DATAxxx to the new location?).
    
    We _are_ talking about profiles from identical versions of ALL-IN-1,
    aren't we? It's important, since it changed with V3.0.
    
    I'll get out to my ALL-IN-1 system and have a couple stabs at this
    right now. Is this urgent? If so, are there others out there who can
    shoot some holes in my plan?
    
    Bruce

    Bruce,
    
    	Yes this would work. 
    
    	However,
    
    		o You have no control over which duplicate record is
    		  discarded. 
    
    		o You can't keep any discarded records in an exceptions
    		  file. See CONVERT instead.
    
    Cheers,
    
    Iain.

    Iain,
    
    You raise a good point. You and I are operating under different
    assumptions, and whichever is correct the original questioner (he's
    still around somewhere, right?) might want to play with both CONVERT
    and SORT. To test safely, this would require lots of disk space, a safe 
    work area, backups of the profiles in question, and lots of purging.
    
    Assumptions:
    
    	o You don't care which duplicate record gets thrown out (i.e.,
    James Polk has an account on each system, each username being
    POLK.JAMES, but records differ slightly: fulnam "James K. Polk" vs.
    "James Knox Polk").
    
    	o You don't want to see a report of discarded duplicates.
    
    	o You have a copy of each profile, called PROFILE1.DAT and
    PROFILE2.DAT.
    
    These commands worked for me on a V2.4 system (username field hasn't
    changed length, right?):
    
    	$CREATE/FDL=OA$LIB:PROFILE OUTPROFILE.DAT
    	$SORT/KEY=(POS:1,SIZ:30) PROFILE1.DAT,PROFILE2.DAT/NODUP -
    		OUTPROFILE.DAT/OVERLAY
    
    As Iain points out, CONVERT will work similarly, and will print an
    exceptions file. This would work something like this (UNtested):
    
    	$CREATE/FDL=OA$LIB:PROFILE PROFILE1.DAT,PROFILE2.DAT -
    		OUTPROFILE.DAT/EXCEPT=PROFILE.XPT
    
    Good luck, dude. Post your results for posterity.
    
    Bruce

    The Redmond recommendations around DTR/Profile munging is to use the
    product to compare the two profiles (to be meregd) in order to locate
    potential duplicates.  You'll always have a few (MANAGER, POSTMASTER,
    X400, etc.) and once you find them I normally use DTR to blow one (of
    each set) away before merging with CONVERT.  As others say, you could
    also use DCL or ALL-IN-1 (WRITE DELETE PROFIL) as well.  The important
    thing is to remove duplicates before the merge commences.
    
    Tony