T.R | Title | User | Personal Name | Date | Lines |
---|
2666.1 | Why not go native? | SWAM2::RHODEWALT_BR | Pillage pillage, loot loot | Thu May 06 1993 02:52 | 11 |
| 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.2 | Why not go even more native? | SCOTTC::MARSHALL | Spitfire Drivers Do It Topless | Thu May 06 1993 13:46 | 7 |
| How about:
SM MUA D DP -> Delete profile record
This saves you having to worry about PROFIL or any other nasties...
Scott
|
2666.3 | Replies to .1 and .2 | CHOWDA::GLICKMAN | writing from Newport,RI | Thu May 06 1993 17:43 | 25 |
| 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.4 | How about DCL ? | AIMTEC::VOLLER_I | Gordon (T) Gopher for President | Thu May 06 1993 19:21 | 16 |
2666.5 | Proto-native? | SWAM2::RHODEWALT_BR | Pillage pillage, loot loot | Thu May 06 1993 21:31 | 20 |
| 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.6 | Some problems with SORT ... | AIMTEC::VOLLER_I | Gordon (T) Gopher for President | Thu May 06 1993 22:47 | 15 |
| 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.7 | SORT season! CONVERT season! SORT season!! | SWAM2::RHODEWALT_BR | Pillage pillage, loot loot | Thu May 06 1993 23:32 | 36 |
| 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.8 | Redmond's view | SIOG::T_REDMOND | Thoughts of an Idle Mind | Sun May 09 1993 01:07 | 9 |
| 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
|