[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

189.0. "Disable PROFIL.DAT search in TO: and CC: fields?" by MSAM00::SHELL (Go the distance...) Sun Mar 08 1992 04:15

    I placed this in the ALL-IN-1_V24 conference, just when it went out of
    vogue.  This is still an important issue when considering our
    directions toward integration of DDS (and eventually X.500) into all of 
    our mail products.  An SPR is on it's way, but in the mean time can 
    anyone help me out with this.
    
    My customer found that in searching for mail addressees in the TO:
    field, with OA$DDS_PRIME = 2, that after finishing the DDS search, some
    kind of sequential search was performed on PROFIL.  After reviewing 
    note #163.* in the ALL-IN-1_V24 conference, we patched their system 
    with K601/K602, thinking that this was related to the Sequential 
    Search Vs. Keyed Search problem.
    
    After we patched, we found that searches are still performed
    sequentially against PROFILE.DAT.
    
    Ultimately, we would actually prefer not to even see PROFILE.DAT
    searched at all...there is essentially nothing there the customer wants
    searched against...it's all in DDS.
    
    Is it perhaps possible to disable searching on PROFILE.DAT from the TO:
    or CC: field?  Or is there an existing patch to the above problem?
    
    Doug Burke
    Consulting Services
    Digital Equipment (Malaysia)
T.RTitleUserPersonal
Name		DateLines
189.1The short version of the excuse!AIMTEC::WICKS_AVote Bill'n'Opus for a weirder USASun Mar 08 1992 18:1834
    Doug,
    
    The basic answer is No. But I suspect you want a little more than that
    
    OK what happened back in the dim and distant past of AMETHYST was we ran
    out of time/money/sanity to implement or test OA$DDS_PRIME set to 2
    but because some people actually tried to use it we had to bend a few
    rules.
    
    Anyway, one of the field test sites found out that using this set-up
    you couldn't get to the X400 form - which is of course a Profile entry
    and they weren't too happy. Then when we thought about it we discovered
    that any other special mail destination would also be broke because
    Profile wasn't being searched at all. So AMTS and DDS didn't cohabitate
    very well. Then after a few more pints of beer we realised that ANY
    entry in the Profile that had MDFLAG set to N (for whatever reason)
    wouldn't be found also - and before you could say OECD we would have
    had a CLD from Europe. 
    
    So given there were so many exceptions and it was very complex we
    dusted off Grahame Ash, gave him a coding pencil and well the only way
    to fix it was a sequential serach looking for MDFLAG == N. The rest is
    history...
    
    We always meant to go back and do something better but Vid left then
    Grahame left and then finally Chris and I left and well it still works
    that way in DIAMOND.
    
    Sorry.
    
    Regards,
    
    Andrew.D.Wicks
189.2Workaround - a Super Search KeyCOPCLU::VAGNVagn Eisensee @DMOTue Mar 17 1992 11:3923
    I have recently developed a workaround for the problems described in 
    .0. 
    
    It is called a SUPER SEARCH KEY. It works with OA$DDS_prime set to 1, 
    and allows the user to validate against DDS by pressing GOLD SEARCH. In 
    this way we have combined the ordinary facilities for validation with 
    the option of a user controlled searching of DDS.
    
    The To or CC fields can be filled in with beginning of last name , 
    beginning of first name. GOLD SEARCH will search DDS for the 
    combination of first and last name, and if just one match the TO or CC 
    field will be expanded with name and adressing info from DDS. If more 
    names satisfy the search the DDS$INDEX shows up with the ordinary 
    facilities for selecting one or more addresses.
    
    By instructions on the EMHEAD form the users are adviced to primarily 
    use the SUPER SEARCH KEY, and thereby obtain the same facilities as 
    intended with OA$DDS_PRIME set to 2.
    
    17-mar-1992
    
    Vagn Eisensee
189.3I know we don't talk futures here, but...MSAM03::DOUGLASBURKEYou're a smart girl, Gay!Fri Mar 27 1992 04:0510
    Re: .1
    
    Andrew, I don't suppose you know if this is going to be fixed in some
    future release?  *;'>
    
    Re: .2
    
    Vagn, are the customizations too voluminous to post here?
    
    Doug
189.4Is this vague enough?AIMTEC::WICKS_AVote Bill'n'Opus for a weirder USAFri Mar 27 1992 14:189
    Doug,
    
    Unfortunately the information I have on post DIAMOND releases is very
    sketchy (:==:) so I probably wouldn't be able to tell you more
    in A1INFO
    
    Sorry
    
    Andrew.D.Wicks