Conference iosg::all-in-1_v30

    Sunil,
    
    NETWORK doesn't have a field called ORGUNIT1 so how could the dsab
    return it??? 
    
    The SUBSCRIBER dsab is the only dsab I know of that has such a field
    so out of interest why are you expecting something like NETWORK
    or PROFIL to return it?
    
    The fields returned out of PROFIL, NETWORK are the same as they have
    always been aren't they?
    
    Regards,
                                   
    Andrew.D.Wicks

    Hi Andrew,
    
    I know that NETWORK and PROFIL do not have ORGUNIT1 and it's part of
    the SUBSCRIBER dsab.  However what is a bit confusing is the named data
    in EMHEAD
    
    ;;TO;;
    
    /PRE='GET #CASE = 1'
    /OPTIONAL/SCROLL=,,,MAIL$SCL_FUNCTION:TO
    /RSE_RECOG=OA$MAIL_ADD_ADDR WITH .USER = TO;GET TO = OA$SEL_BINARY_ADDRESS
    /SHOW='.USER:18 "  " .ORGUNIT1:25 "  ( " .FULNAM:22 ")"'/USE_FORM=EMSREC
    
    ;;CC;;
    
    /PRE='GET #CASE = 2'
    /OPTIONAL/SCROLL=,,,MAIL$SCL_FUNCTION:CC
    /RSE_RECOG=OA$MAIL_ADD_ADDR WITH .USER = CC;GET CC = OA$SEL_BINARY_ADDRESS
    /SHOW='.USER:18 "  " .ORGUNIT1:25 "  ( " .FULNAM:22 " )"'/USE_FORM=EMSREC
    
    EMSADD
    
    SELECT FOR OA$MAIL_ADD_ADDR WITH .USER = #EMDADDRESS
     DO SEL_CHOICE  OA$SEL_LINE:2 "  " .USER:18 "  "
     .ORGUNIT1:25 "  ( " .FULNAM:22 " )"
    
    ORGUNIT1 refers to the PROFIL field DEPART to prove this I did a
     
    <FOR OA$MAIL_ADD_ADDR WITH .USER = $sm_account do get .ORGUNIT1:25

    This displayed "Customer Support Center"
    
    MBMAN> sel dds subscr/name="Sunil Sethi"/orgunit="Customer Support Center"
    MBMAN> MODIFY DDS subscr /ORGUNIT="DEC ALL-IN-1 CSC"
    MBMAN> add dds modified_object
    
    <FOR OA$MAIL_ADD_ADDR WITH .USER = $sm_account do get .ORGUNIT1:25
    
    This displayed "Customer Support Center"
    
    <FOR OA$MAIL_ADD_ADDR WITH .USER = $net_record do get .ORGUNIT1:25
    
    This displayed nothing.
    
    Can my findings be confirmed please, I suspect that the profile record
    for the user's department is being displayed and the network record is
    not being searched.
    
    Thanks in advance
    
    Sunil

Hi Sunil,

I'm not quite sure what point you're trying to make.

There is no ORGUNIT field in NETWORK, so

    /SHOW='.USER:18 "  " .ORGUNIT1:25 "  ( " .FULNAM:22 ")"'

doesn't display an ORGUNIT for network records.  What else can it do?  What are
you suggesting it should do?  I guess the reason the
ORGUNIT is there is so that you can see it when an address is fetched from a
'directory' (eg DDS, profile, etc) that has a suitable field.

>> Can my findings be confirmed please

Well, your findings seem pretty straightforward and consistent with above.

>> I suspect that the profile record for the user's department is being
>> displayed and the network record is not being searched.

I'm not sure which of your examples this refers to, so I'm not sure what you're
getting at...

Scott

    Sunil,        
    
    I'm afraid you've completely lost me too! can you try again with
    pictures and words of two syllables or less.
    
    Regards,
    
    Andrew.D.Wicks

    H i  A n d r e w  a n d  S c o t t ( t h a t 's  m e  s l o w e d  d o
    w n ;-),
    
    Now back to normal sorry if I have lost you both and other okay here is
    my exaple.
    
    1. EM C
    
    2. I entered "S" in the TO: field and did a gold l and this is what I get
       for an entry in the PROFILE (by the way that's "S" for Super Sunil
       :-) 
       
                                  ALL-IN-1 Directories
    
     Select an addressee from the following:
    
     1   SUBSCRIBERS:                                ( All ALL-IN-1 users on )
     2   SETHI               CSC - ALL-IN-1 support  ( Sunil Sethi )
    
    
    3. I entered "T" in the TO: field and did a gold l and this is what I get
       for an entry in the NETWORK.DAT ( A "T" for The problem)
       
    
                                  ALL-IN-1 Directories
    
     Select an addressee from the following:
    
     1   TEST SHARE          IO support                 ( Share Test )
     2   TEST NETWORK@A1@RA                             ( Test Network )
     3   TEST NETWORK@A1@RA                             ( Test Network )
    
    What the customer is complaining about is the missing (department or
    the ORGUNIT1 field).  The NAMED DATA for the form is 
    
    Form:    EMSADD
    Library: DISK$OFFICE_DISK:[ALLIN1.LIB_BRITISH]OAFORM.FLB;
    -------------------------------------------------------------------------
    
    ;;.TYPE;;
    
    SELECT FOR OA$MAIL_ADD_ADDR WITH .USER = #EMDADDRESS
     DO SEL_CHOICE  OA$SEL_LINE:2 "  " .USER:18 "  "
     .ORGUNIT1:25 "  ( " .FULNAM:22 " )"
    
      ^^^^^^^^^^^^
      ||||||||||||
    
    There is the ORGUNIT1  it displays the department field in PROFILE but
    not if it is a NETWORK.DAT entry.  The customer has said it's
    impossible to distinguish between the two users unless all or most of
    the USER field is displayed.
    
    I hope this is clear otherwise I am goin to stop goin to school where
    they teach me Stralian !!!  Well that's a Fair Dinkum outline of the 
    problem I hope.
    
    Thanks for your patients and help
    
    Sunil

Hi Sunil,

Well, I see your problem, but as stated in earlier replies, there is no
solution.  To recap:

The SEL_CHOICE has an ORGUNIT field, so that those address-repositories that
have an ORGUNIT field can display it.

However, NETWORK does not have an ORGUNIT or DEPARTMENT field, so there is no
data that can be displayed in that field.  Hence the field is blank.

In your customer's case this is a pain, I agree, but that's the way it's always
worked, and I don't think it's likely to change.

I can't even suggest customising NETWORK to add an ORGUNIT field, as the code
for the OA$MAIL_ADD_ADDR dataset is in uncustomisable base code.

A possible customisation would be to change USER:18 to USER:30 (eg), but you
could rapidly run out of room on the screen, and this still isn't foolproof.

So sorry, I guess you're stuck in the dunny with this one...

Scott
(showing his mastery of the Australian language :-)

    G'day Scott,
    
>However, NETWORK does not have an ORGUNIT or DEPARTMENT field, so there is no
>data that can be displayed in that field.  Hence the field is blank.
    
    Well that's not really correct mate NETWORK does have a DEPARTMENT
    field just like PROFIL.  The OA$MAIL_ADD_ADDR dataset does not pick up
    the DEPART field from NETWORK, so looks like it's not working as
    expected.
    
    I am sure this customer is going to have it SPR'd I had told him that
    he could customise the form to change USER:18 to USER:<what ever>.  
    This customer is the largest customer for ALL-IN-1 and would like his
    solutions like yesterday hence my note to confirm things.  
    
    Thanks for your help 
    
    Scott
    
    PS - I had to read your 'Stralian it's not bad mate good on ya !!! 

Wait a minute.  Here's one more try before throwing in the towel:

    ;;.TYPE;;
    
    SELECT FOR OA$MAIL_ADD_ADDR WITH .USER = #EMDADDRESS
     DO .IF .ORGUNIT NES "" THEN
             SEL_CHOICE  OA$SEL_LINE:2 "  " .USER:18 "  "
             .ORGUNIT1:25 "  ( " .FULNAM:22 " )"
        ELSE SEL_CHOICE  OA$SEL_LINE:2 "  " .USER:18 "  "
             .DEPART:25 "  ( " .FULNAM:22 " )"

If .DEPART:25 doesn't work, then try PROFIL.DEPART:25[.USER] or
NETWORK.DEPART:25[.USER].  Or both, by sticking another round
of IF-THEN-ELSE in there.

~K.

    Hi,  
    
    As suspected the customer felt that they should not be responsible for
    correcting problems that have been made by Digital.  However he is
    willing to customise the forms.
    
    The customer has asked for this problem to be forwarded to engineering
    as a request for an enharncement (priority 4).  Well more work for you
    all.
    
    Sunil

    
    Can someone please tell me where I can find out what's in the
    OA$MAIL_ADD_ADDR dataset?  I need to know if the SUBSCRIBER DSAB fields
    USERDEF1 - USERDEF5 are part of the OA$MAIL_ADD_ADDR dataset.
    
    Thanks for any response.
    
    Sherald T.
    

    Sherald,
        
    No they aren't - in ALL-IN-1 v2.4 OA$MAIL_ADD_ADDR contains just
    two fields KEY and VALUE (actuallY USER and FOLDER) which change which 
    dsab fields they point to depending on what file is 'active' i.e PROFILE, 
    NICKNAMES etc...
    In v3.0 it is even more complex... and I really don't think you
    want to know!
    
    OA$MAIL_ADD_ADDR remains an undocumented DSAB but a search through this
    conference and its ancestors will find many many discussions on this
    legendary DSAB.
    
    in v23 try notes 494, 3173, 1099 and over 20 others
    in v24 I find another 20 matches
    in this conference a mere 8 matches
    
    but USERDEF1 to 6 only exist in SUBSCRIBER.
    
    Regards,
    
    Andrew.D.Wicks

    Andrew
    
    Would you please tell me how you're searching to find these matches.  I
    can't seem to locate the notes you're talking about.
    
    Are you searching the conference IOSG::ALL-IN-1_V24 for the V2.4 matches?
    
    Also, the USER field in OA$MAIL_ADD_ADDR seems to be the Network
    Address field on my customers V2.4 system.  Is this correct?  I guess
    the questions I have comes to this - how is the OA$MAIL_ADD_ADDR data
    set created (what files and fields is it looking at).  I need enough
    information from the OA$MAIL_ADD_ADDR dataset to pull information from
    the Subscriber dataset to display.  Is this possible?
    
    
    Sherald T.
    
                                     

    Sherald,
    
    sorry but I can't spend any more time on this...
    official support requires either SPRs or calls to the CSC.
    or maybe someone else can help you on this one?
    
    regards,
    
    Andrew.D.Wicks
                                         

OA$MAIL_ADD_ADDR isn't a conventional dataset.  It is a lot of very complex
code designed specifically to do validation and recognition on TO: and CC:
fields.  It combines data from a variety of other datasets, and other sources,
and processes them in a variety of ways.

If you want to pull DDS fields from SUBSCRIBER, I think you'll find it far
easier and better to use the SUBSCRIBER dataset directly.  I know it's not
documented, but there are sufficient scripts that use it to give you the info
you'll need!

Scott

    Thanks for your response Scott.  Substituting SUBSCRIBER for
    OA$MAIL_ADD_ADDR is exactly what I'm considering, with some hesitation.
    
    My hesitation is - not knowing if OA$MAIL_ADD_ADDR and SUBSCRIBER
    contains the very same user list with no exceptions and if using
    SUBSCRIBER will give the mail address I need in the TO and CC fields.
    
    Any ideas?
    
    Sherald T.

>> not knowing if OA$MAIL_ADD_ADDR and SUBSCRIBER
>> contains the very same user list with no exceptions

Strictly speaking, OA$MAIL_ADD_ADDR doesn't "contain" any user names.  As
mentioned before, it is a validation dataset: it takes a username, and looks
up the profile, distribution lists, nicknames, NETWORK, DDS (if applicable),
special addresses (eg "ME"), AMTS addresses, etc, to find a match.

SUBSCRIBER is a dataset that does contain user names, but just DDS entries.

So SUBSCRIBER contains a subset of the user names against which OA$MAIL_ADD_ADDR
tries to find a match.  I hope that helps make it clear what's going on!

To get back to your original question:

>> I need to know if the SUBSCRIBER DSAB fields
>> USERDEF1 - USERDEF5 are part of the OA$MAIL_ADD_ADDR dataset

No.  OA$MAIL_ADD_ADDR has only one externally visible field - the mail address.
This can be input in
a variety of forms, and if valid is converted to the "standard" form: ie
the free-form name, followed by the mail address in parentheses.  However,
internally OA$MAIL_ADD_ADDR may well make use of all sorts of fields from other
datasets (eg it uses at least USER, FULNAM and MAIDES from PROFIL for its
validation).

I don't know, and don't really think it would be right to document here, which
SUBSCRIBER fields it uses.  The reason I don't think it would be right to list
them is that it might give you a false idea about what you can do with
OA$MAIL_ADD_ADDR: whatever it does internally with SUBSCRIBER isn't visible to,
or meaningfully usable to, the user of OA$MAIL_ADD_ADDR.

Perhaps if you could explain what you want to do that makes you want this
information, we could work out the best way for you to do it!

Scott

    In reference to note 1745.8 - I modified the named data in form EMSADD
    to look like:
    
    ;;.TYPE;;
    
    SELECT FOR OA$MAIL_ADD_ADDR WITH .USER = #EMDADDRESS
     DO .IF  .SURNAME NES "" THEN
             SEL_CHOICE OA$SEL_LINE:2 "  " .USER:18 " " .GIVENNAME:16 " "
             .INITIALS:1 " " .LOCATION:15 " " SUBSCRIBER.USERDEF5:20[.%KEY]
        ELSE SEL_CHOICE OA$SEL_LINE:2 "  " .USER:18 " " .GIVENNAME:16 " "
             .INITIALS:1 " " .LOCATION:15
    
    This displays the information with some lag in performance (due to the
    access to Subscriber), but when a selection is made, it seems to
    continue through the entire list before it returns.  Even if I hit exit
    screen, it continues through the list before returning to the previous
    screen.
    
    Is there something I can do to avoid the extra processing in this
    situation to help speed things up?
    
    If the "DO SEL_CHOICE" remains in tack without an "IF THEN ELSE", all
    is well, with the exception of blank lines displaying when there is no
    entry in SUBSCRIBER.
    
    This problem is the same in ALL-IN-1 V3.0 and V2.4 with some field
    differences.  Any suggestions?
    
    Sherald T.
     
                      

As a solution to the initial problem mentioned in the note:

The following is what worked for my system:

1)
Update the FDL for NETWORK.DAT (OA$LIB:NETWORK.DAT) with a fourth key:

KEY 3

    CHANGES		     YES
    DUPLICATES		     YES
    NAME		     "NETWORK"
    SEG0_LENGTH		     62
    SEG0_POSITION	     288
    TYPE 		     STRING

2)
Now convert your NETWORK.DAT datafile with this modified FDL.

3)
Modify the named data of EMSADD as follows: (read hash for poundsign!)

;;.TYPE;;

SELECT FOR OA$MAIL_ADD_ADDR WITH .USER = �EMDADDRESS
 DO .IF .ORGUNIT1 NES "" THEN XOP ~~SEL_ORG~~
 ELSE .IF .USER <=> "@" THEN XOP ~~SEL_NET~~
 ELSE SEL_CHOICE OA$SEL_LINE:2 "  " .USER:18
 "                            ( " .FULNAM:22 " )"

;;~~SEL_ORG~~;;

 SEL_CHOICE OA$SEL_LINE:2 "  " .USER:18 "  "
 .ORGUNIT1:25 "  ( " .FULNAM:22 " )"

~~SEL_NET~~

 SEL_CHOICE OA$SEL_LINE:2 "  " .USER:18 "  "
 NETWORK:NETWORK.DEPART:25[.USER] "  ( " .FULNAM:22 " )"


That should do the trick.
If anybody has any better solutions or if this would cause problems 
I can't see, please let me know.

Regards,
Arjen