[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

2666.0. "Using DATATRIEVE to mung PROFILE.DAT?" by CHOWDA::GLICKMAN (writing from Newport,RI) Thu May 06 1993 01:08

    Hi,
    
    	We're merging two VAXclusters into one (and yes ALL-IN-1  is
    on both VAxclusters).  One of the support folks here read the Tony
    Redmond book and and found some information about deleting records
    in the PROFILE.DAT via DATATRIEVE.  We have duplicate users and
    he wants to delete some of them prior to the merge weekend via this
    method.  He doesn't really do DATATRIEVE and I told him I'd check it
    into it.  Anyone tried this before.  Do we need to have the record
    structure for the PROFILE.DAT to do this?  I know this probably
    isn't the ALL-IN-1 preferred method but...
    
    Thanks,
T.RTitleUserPersonal
Name
DateLines
2666.1Why not go native?SWAM2::RHODEWALT_BRPillage pillage, loot lootThu May 06 1993 02:5211
    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
2666.2Why not go even more native?SCOTTC::MARSHALLSpitfire Drivers Do It ToplessThu May 06 1993 13:467
How about:

SM MUA D DP -> Delete profile record

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

Scott
2666.3Replies to .1 and .2CHOWDA::GLICKMANwriting from Newport,RIThu May 06 1993 17:4325
    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,
2666.4How about DCL ?AIMTEC::VOLLER_IGordon (T) Gopher for PresidentThu May 06 1993 19:2116
2666.5Proto-native?SWAM2::RHODEWALT_BRPillage pillage, loot lootThu May 06 1993 21:3120
    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
2666.6Some problems with SORT ...AIMTEC::VOLLER_IGordon (T) Gopher for PresidentThu May 06 1993 22:4715
    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.
2666.7SORT season! CONVERT season! SORT season!!SWAM2::RHODEWALT_BRPillage pillage, loot lootThu May 06 1993 23:3236
    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
2666.8Redmond's viewSIOG::T_REDMONDThoughts of an Idle MindSun May 09 1993 01:079
    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