Conference iosg::all-in-1_v30

    API to DDS.
    
    Correct: Undocumented.  The closest thing to a documented interface is
    SUBSCRIBER, and the only reason why it is available to the field is
    that ALL-IN-1 can't hide very much in forms and scripts.
    
    NOX400SEND.
    
    I don't know the answer to this, but it would be simple enough to send
    a command to a privileged account to update this field from DCL.
    
    Performance.
    
    DDS uses its own key into the database - DDSID, that fairly horrible
    value which is dumped into users' profile records.  Apart from that I
    believe it's pretty well the same for all the other fields, although it
    would be logical to have surnames available as a keyed lookup.
    
    Action attribute fields.
    
    I don't know.  Maybe Andrew Wicks can cast some light here.
    
    Remote access to DDS.
    
    You can access a remote DDS server from a DEC MAILworks client, but
    only if a mail server is running on that system.  The clients access
    DDS via the remote mail server.  As far as I am aware ALL-IN-1 does not
    support this kind of setup, but it's always possible that I am wrong.
    
    Cache refresh.
    
    I believe it updates the entry in the cache.  Why would it delete them?
    
    Some help, not much, you clearly need someone who has implemented DDS
    on a large scale.  I haven't had this "opportunity".
    
    Tony

    Helene,
    
    /X400SEND was only added in MBMAN 3.2 so I doubt whether ALL-IN-1
    supports it - do you know what DDS field it maps to as I don't see one
    with this name in my copy of the callable interface.
    
    As Tony says the API was never published either to the SUBSCRIBER Dsab
    (apart from Sir David's book) or to DDS itself as that interface is
    protected with zeal by the nice MR people.
    
    As for the performance and action attribute questions I think the
    information on that was not made public either - sorry but that 
    wasn't my decision either.
    
    Cache refresh is a function of the Application calling DDS and is
    implemented differently be ALL-IN-1 and DEC MAIlworks so if both are
    present on a system you can see some very eccentric behaviour
    
    Was any of that helpful i'm typing from a very fading memory....
    
    regards,
    
    Andrew.D.Wicks
    
    

	I have a customer trying to READ the DDS field FFPOSTADDR
	from the DSAB SUBSCRIBER.

	Can anyone tell me the corresponding field name in the 
	DSAB ?! Is it possible to read this DDS field ??!!

	Thanks in advance.
	Ian.

There are 8 fields that you require:

FFPOSTADDR1
FFPOSTADDR2
     to
FFPOSTADDR8

Have a look at the script SUBSCRIBER_ADD for more details of the PROFIL to
DDS (the SUBSCRIBER DSAB) mapping.

mb

        OK, fine. I can get to .FFPOSTADDR1, but why does the first of 
        these examples work and the second not. The "containing" 
        example is even stranger ? Am I going crazzy ??
        
        1) This works...
        
        FOR SUBSCRIBER WITH -
         .SURNAME1 = "Flack" AND .FFPOSTADDR1 = "" -
         DO GET ":" .FFPOSTADDR1 ":"
        
        Result...
        :Gateway House.:
        
        2) This does NOT work...
        
        FOR SUBSCRIBER WITH -
         .SURNAME1 = "Flack" AND .FFPOSTADDR1 = "Gate" -
         DO GET ":" .FFPOSTADDR1 ":"
        
        Result... Nothing (No match)
        
        3) But this does work...
        
        FOR SUBSCRIBER WITH -
         .SURNAME1 = "Flack" AND .FFPOSTADDR1 <=> "Gate" -
         DO GET ":" .FFPOSTADDR1 ":"
        
        Result...
        :Gateway House.:
        
        Help ??!!
        

Hi,

I wouldn't worry too much about this.

ALL-IN-1 RSEs are designed to work with RMS files, which have simple things
like key-fields.  DDS doesn't have keys, it has action-attributes (or whatever
they're called), which work differently.

Applying this to your example:

>> FOR SUBSCRIBER WITH -
>>      .SURNAME1 = "Flack" AND .FFPOSTADDR1 = ""

.FFPOSTADDR1 = "" is a no-op; it is always true.  So this is basically a search
for .SURNAME1 = "Flack", which works as you'd expect.

>> FOR SUBSCRIBER WITH -
>>       .SURNAME1 = "Flack" AND .FFPOSTADDR1 = "Gate" -

In this case, the RSE code tries (I think, and skipping a lot of the detail) to
get SUBSCRIBERS to perform a keyed lookup using both fields.  As DDS doesn't
work like this, it goes wrong.  I don't guarantee that's what's happening, but
it seems the most likely to me.

>> FOR SUBSCRIBER WITH -
>>       .SURNAME1 = "Flack" AND .FFPOSTADDR1 <=> "Gate"

The "containing" operator can't be used for keyed lookups, so the RSE code
just asks SUBSCRIBERS for .SURNAME1 = "Flack".  It then gets back one or more
records, and filters out any that don't match .FFPOSTADDR1 <=> "Gate"

I hope that helps.

Scott

    I've just reported a bug on this. However, it's likely to be answered
    as a restriction, as there's a workround:
    
    If you BIND a phantom to SUBSCRIBER, and then do your FOR loop on the
    phantom, you should find it'll work.
    
    BIND *FRED TO SUBSCRIBER [ with ... if you like ]
    
    FOR *FRED [ with ... if you like ] DO ...
    
    Dave.