Conference iosg::all-in-1_v30

    Kevin,
    
    The SUBSCRIBER dsab has had fields called ORGUNIT1-4 since 1987.
    
    I don't know whether there is a link implied or otherwise to the
    PROFIL fields. 
    
    I thought that PROFIL.DEPART was copied to SUBSCRIBER.ORGUNIT1 at least 
    looking at my scripts in OA$DO from Jan 1988 they are!!
    
    Regards,
    
    Andrew.D.Wicks
                                        

    Hi
    From the Profile viewpoint, to the best of my knowledge no use has been
    made of the orgunit fields. They are in preparation for future use.
    
    DaveT

>    I thought that PROFIL.DEPART was copied to SUBSCRIBER.ORGUNIT1 at least 
>    looking at my scripts in OA$DO from Jan 1988 they are!!
    
Just fyi, this is probably a bad idea, as there's no obvious correlation 
between these two values. 

A customer may well use PROFIL.DEPART as a way of dividing up mail areas or 
housekeeping jobs - there may be very few people in each department.

However, an X.400 Organisational Unit would typically refer to a large part of 
an organisation (!). For instance, it's likely that if/when Digital creates 
its own X.500 database an Org Unit will be used to match a location code, and 
this may well include more than one ALL-IN-1 system.

I'd suggest that anyone thinking of planning for X.400/X.500 doesn't use 
PROFIL.DEPART as part of their o/r addresses.

grahame

    Just a little question, since we're talking about breaking the links.
    
    I've just spent a little while at a customer doing just this very
    thing, they wanted to break the link between PROFIL.DEPART and
    SUBSCRIBER.ORGUNIT1. So where did they want .DEPART putting ? In
    SUBSCRIBER.FFPOSTADDR2 thats where !!!  They also store COUNTRY in
    FFPOSTADDR3 and LOCATION in FFPOSTADDR1. Don't ask why, it's a long story
    - there's no reasoning with some people :-)
    
    So the question is:-
    Apart from all the forms/blp's/help etc. The scripts I modified were
    all the SUBSCRIBER_* and SUBSCRIBER_*_INTERACTIVE ones, I hope there
    aren't any others ??  I had a very good look around and couldn't see
    any.
    
    I hope I'm not the one around when they upgrade to V3.0, on the other
    hand we could do with the consultancy, and I could do with the
    overtime :-)
    
    Stevie.

    At the cost of a fair amount of CPU time and I/O, $SEARCH has found
    the following uses of ORGUNIT1:
    
    SUBSCRIBER_ADD.SCP
    SUBSCRIBER_ADD_INTERACTIVE.SCP
    SUBSCRIBER_CHANGE.SCP
    SUBSCRIBER_CHANGE_INTERACTIVE.SCP
    
    DDS$INDEX$FIND.FLX
    DDS$INDEX$VIEW.FLX
    DDS$INDEX.FLX
    DDS$INDEX_DIR.FLX
    DLEDIT.FLX
    EMAFWD.FLX
    EMEDHD.FLX
    EMFWHD.FLX
    EMHEAD.FLX
    EMSADD.FLX
    NIENTR.FLX
    PROFIL.FLX
    SM$CREATE$PROFILE.FLX
    X400FM.FLX
    SM$PROFILE.FLX
    EMSDDS.FLX
    EMSSRC.FLX
    OLDNIENTR.FLX
    SA$CREATE$DDS$INDEX$VIEW.FLX
    SA$CREATE$DDS$INDEX.FLX
    SM$CREATE$DDS$INDEX$VIEW.FLX
    SM$CREATE$DDS$INDEX.FLX
    
    DDSDISPLAY.BLP
    DDSDISPLAY_X.BLP
    
    As far as I can see, all the references in the forms are read references
    (mostly in /SHOW or /GET qualifiers. The .BLP references are obviously
    reads.
    
    Dave.

    Thanks for your time Dave, it seems like I was right about the forms as
    well.
    Now I'm just going to have a look around here and in STARS to see why I
    can't get the BIND in  DDS$INDEX and DDS$INDEX_DIR to work when using 
     AND  .FFPOSTADDR2:32 ENS DEPARTMENT instead of 
     AND  .ORGUNIT1 ENS DEPARTMENT   
    What happens is; if you only supply the SURNAME and DEPARTMENT what the
    DDS$INDEX/DDS$INDEX_DIR form displays is all subscribers with .SURNAME1
    = SURNAME and ignores the DEPARTMENT field altogether, a bit of a pain
    in the proverbial if the surname is JONES !!!
    
    Actually, don't waste any time on this, I've only really looked at it
    on site.  Usually I think better here [;-)]
    It could possibly be a bug as they're only on 2.4
    
    
    Steve.

    Unfortunately, SUBSCRIBER is not a standard dataset (which is one
    reason why it's never been properly documented).
    
    You can only do BINDs on those fields which DDS defines as "action
    attributes" which essentially means that you can look up with them.
    This is the way DDS works, and isn't under our control.
    
    I assume that FFPOSTADDR2 isn't an action attribute.
    
    Sorry,
    D.
    
    PS - although there isn't any "official" documentation on the DDS
    datasets, there is an excellent "unofficial" document written by David
    Hare which explains all sorts of things about DDS including lists of
    the fields. I'm not sure where you can get a copy, but I dare say there
    are other references in this conference to it.
    
    D.