Conference iosg::all-in-1

Well...

It looks like I'm the only one having that problem or the only one using a 
FOR loop to access remote subscribers... 

Should I raise an IPMT for thsi problem?????

Best regards

Pierre

    Have you asked the DDS people in FORTY2::MAILBUS if they have any
    ideas? Otherwise, I guess you're right, no-one here has heard of the
    problem so you'll need to raise an IPMT so that someone can be
    allocated time to look into it, and more to the point, set-up a
    suitable system to recreate it!!
    
    Can you split the loop into smaller parts as a workround? I expect you
    already thought of that :-)

    Asking "the DDS people" won't do much good unless someone can translate
    the gobbledygook in .0 into the resulting sequence of DDS API calls/ops
    requested/generated by ALL-IN-1 when it processes that script.
    
    Dave

    Dave, be nice to me :-)
    
    I was hoping that you could probably guess what sort of calls we were
    making and thus avoid me having to look at the code... Or, that it
    might ring a bell with you.

    Graham, be nice to me!  :-)
    
    I don't do scripts; what is .0 doing? The only character strings in .0
    that mean anything to me are "FOR" (some kind of loop construct?) and
    "DDSID" (the primary key to a DDS entry). Oh and "SUBSCRIBER", but that
    is a vague word that seems to mean differant things in various contexts.
    
    Dave

    Dave,
    
    Ok, I apologise, after ten years or so, you get to finally believe that
    ALL-IN-1 script *is* intuitive!!
    
    I think that the script is basically just going to DDS 10,000 times,
    and saying, "here is a Given Name, what's the DDSID?"
    
    Presumably, one of us has some sort of memory leak or other resource
    problem that causes the process to hang.
    
    If that's not enough to make you say that you don't have any ideas
    either, then .0 will have to submit an IPMT for us both to look at it!
    
    Graham

    Ugh; 10000 remote searches in a tight loop.
    Yeah, I suspect it will need to be IPMT'd. 
    
    A question/suggestion to .0
    
    Given the relative expense of a remote DDS search vs the expense of 
    finding an entry in your input data file, perhaps flipping the logic 
    around would make more sense. IE do one search against DDS for all 
    the objects, and then walk down the DDS result list, saving the ddsid 
    for each entry that is also in your input data file. 
    
    Another suggestion; If possible, try executing your script from a 
    batch/detached/NON-interactive process. The DDS remote client code
    brings up/tears down the decnet link for each search (interactive 
    users don't typically do 10000 searches back-to-back; their fingers 
    get tired) whereas it holds the link up for non-interactive processes 
    (they tend to be servers [eg AIDA] or doing bulk processing tasks).
    
    Dave

RE -.1
>>    Ugh; 10000 remote searches in a tight loop.
>>    Yeah, I suspect it will need to be IPMT'd. 
  
If fact , I simplified the script to keep only the FOR loop part. 
   
>>    Given the relative expense of a remote DDS search vs the expense of
>>    finding an entry in your input data file, perhaps flipping the logic 
>>    around would make more sense. IE do one search against DDS for all 
>>    the objects, and then walk down the DDS result list, saving the ddsid 
>>    for each entry that is also in your input data file. 

Good idea, I will give it a try

    
>>    Another suggestion; If possible, try executing your script from a 
>>    batch/detached/NON-interactive process. The DDS remote client code
>>    brings up/tears down the decnet link for each search (interactive 
>>    users don't typically do 10000 searches back-to-back; their fingers 
>>    get tired) whereas it holds the link up for non-interactive processes 
>>    (they tend to be servers [eg AIDA] or doing bulk processing tasks).

The script is executed in a batch/detached/NON-interactive mode, as I'm using
the ALL-IN-1 SCRIPT Queue. I tried also this interactively but the result
was the same.


Many thanks for your help, I will try it at the customer site, and I'll keep
you informed of any improvment/findings

Best regards

OA$BACK_TO_MY_FOR_LOOP

Pierre

    <<<< The script is executed in a batch/detached/NON-interactive mode,
    <<<< as I'm using the ALL-IN-1 SCRIPT Queue.
    
    I wonder if that looks like an interactive job or not? I think F$MODE
    returns 'other' for symbint jobs.
    
    Out of interest, how does DDS decide if it's a batch job?
    
    BTW, Dave, I think that's a very neat optimisation for batch jobs!!

    We do a LIB$GETJPI for JPI$_MODE and test for JPI$K_INTERACTIVE
    
    So it's either interactive or it's not. There is also a logical 
    you can set in dds$config.com that will override this behaviour
    (undocumented, and only one customer has ever had a need for it).
    
    Dave