Conference azur::mcc

    
    
    >>	do {
    >>		mcc_call_function()
    >>		build reply from MCC output parameters
    >>		send reply to requester
    >>    } while (handle is MORE);

    
    The ALARMS FM uses the same algorithm that you describe.  Where
    you "send reply to requestor", ALARMS "queues notification to
    a batch queue".
    
    ALARMS uses SYS$SNDJBCW.  It is recommended that you use the W
    form of asymnchronous services which will make the services
    synchronous.
    
    We have had no problems doing this and we have had hundreds of
    threads calling SNDJBC within seconds.  One of our tests has
    115 threads doing 600 SNDJBCs within 7 minutes.
    
    aud...
    

.0

> Question 1
> Use of asynchronous I/O services when using DECmcc.
> 
> I'll have a bunch of threads doing the following in parallel.
> 
> 	do {
> 		mcc_call_function()
> 		build reply from MCC output parameters
> 		send reply to requester
>         } while (handle is MORE);
> 
> The question deals with the "send reply to requester" fragment. This is
> most likely a qio to DECnet. The question is, "Should I use qio or qiow?"
> 
> There are rumors that suggest MCC and asynchronous services must be
> avoided, in fact, MCC intercepts qio calls and makes them synchronous.
> Any suggested readings covering this subject?
> 
> I believe the requester would perceive an increase in throughput if I used a
> qio at the cost of program complexity. What are your thoughts?
> 

	DECmcc strongly advises not using ASTS.
	For concurrency and overlapping i/o use multiple threads instead of ASTS.  

	#1- Portability
	#2- None of the MCC routines in the SRM are AST-reentrant.
		(well, probably the ILV and ASN rtns are)
	#3- Reduced program complexity


	In DECmcc v1.0 and v1.1 the framework threading package intercepts
	sys$qiow issues a sys$qio blocks the current thread;  runs the next ready thread;
		and later services the ast by unblocking the i/o blocked thread.
		
	Interception is disabled when running with the debugger/pca.

	Later version of DECmcc will use CMA/Posix threads.
	
	So, go standard.
	

> Question 2
> Can MCC and PAMS (DECmessage) coexist? Anyone try it?
> 
	Why not?

	The only conflict that I recall is running DECmcc v1.0, v1.1 with CMA-
	because the two threading packages conflict.



> .1 
	The framework intercepts all the sys$xxxW calls
	as well sys$dnsW, and rms calls.

	
	Pete Burgess

    Warning!
    
    The code fragment you show has some potential pitfalls. I'd like
    to be sure that you understand them before you take any of the
    preceding answers to mean that they agree you are doing the right
    thing.
    
    If each thread issues a QIOW to "send reply to requestor" then the
    requestor is likely to get a series of I/Os in some (pseudo) random
    order. While each thread is orderly, the recipient *must* be able
    to sort out the mess!
    
    This is particularly important if, in order to "send reply to
    requestor" more than one QIOW is required. Then things can really
    get out of hand for the poor "requestor".
    
    One technique that you might consider using, if your requirements
    merit it, is to have a separate thread deal with the sending (and
    coordinating) to the requestor via (one or more) QIOWS, and have
    each processing thread send the "reply" to be transmitted to that
    separate thread.  Again, your particular requirements may obviate
    the need for such a solution - but in general, if a "reply" equates
    to more than one QIOW, you will need to adopt such an approach.
    
    Colin

    Thanks for your concern.  In cases where each thread is actually
    collecting part of an answer (we considered and discarded this idea
    already) the re-ordering of the pieces of the answer at the end are
    really a problem.
    
    Our design will use a single thread to handle one request which may have
    multiple replies.  Each request has a unique identifer that is placed
    in the replies.  We will handle many requests at one time, and so a bunch
    of threads will be doing the same thing and the (carefully!) identified
    replies will get interleaved and require sorting at the other end.
    
    Sally (who works on the same project with Dave Peterson from .0)