[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

129.0. "MCC$DA_xxx I/O Block allocator?" by SMAUG::BELANGER (Quality is not a mistake!) Fri May 11 1990 19:21

    
    	Who allocated the DA IOB for the MCC$DA_xxx routines?  The SRM
    seems to imply it is one of the initiating MCC$DA_xxx routines which
    should return this structure (ie: MCC$DA_CONNECT_INITIATE).  A related
    question is: who is responsible for freeing this memory?
    
    ~Jon.
T.RTitleUserPersonal
Name
DateLines
129.1The user, not DA, provides the structureTOOK::SCHLENERFri May 11 1990 20:1415
    The user of the DA routines must provide the address of an MCC$R_DA_IOB
    structure whether the user defined a structure statically or allocated
    one from "heap".
    
    According to the SRM for MCC$DA_CONNECT_INITIATE (or any of the DA
    routines) the MCC usage is MCC$R_DA_IOB. If the DA services were
    to allocate the iob structure, you would have had to pass in a pointer
    to an unsigned long ( which would contain the address to the iob
    structure). Hence double indirection.
    
    In that case, the MCC usage would have been defined as an unsigned long
    and not the actual structure.
    
    			Cindy
    
129.2TOOK::SWISTJim Swist LKG2-2/T2 DTN 226-7102Mon May 14 1990 12:2510
    Actually, we are probably going to delete these routines from the SRM
    before we ship V1.    They are blatantly non-portable (iosbs,
    mailboxes, ncbs, and the like are all visible) and furthermore don't
    provide access to phase V decnet.   
    
    You probably noticed they don't do much of anything you couldn't do for
    yourself by calling SYS$QIO directly.
    
    A more generic set of decnet interface routines will be developed for
    the 1.1/2.0 timeframe.
129.3Extensibility could be a problem...SMAUG::BELANGERQuality is not a mistake!Mon May 14 1990 15:0222
    
    	I realize they are not portable (I have a portable communications
    interface definition, if you want an example for your definition).
    
    	The problem with the MCC$DA_xxx routines, is that the user is
    explicitly told that he/she does not have to know about this DA_IOB
    data structure, but they have to allocated (which means they have to
    know something about it; the size).  Also, when dealing with these
    types of structures, if the user allocates them, there is now way to
    make additions to the data structure without breaking old code (ie: the
    DA_IOB data structure is 8 bytes long (just a guess) and is sufficient
    for the needs of a Phase IV environment, but in the Phase V environment
    we need a data structure 12 bytes long.  There is a problem with the
    old code being able to migrate without the need to have another release
    to support the new functionality).  Therefore, I would suggest that if
    DECmcc is to be "somewhat" portable and extensible, those data
    structures that are needed be allocated/freed by DECmcc.  This way a
    new release of DECmcc will allocate the data structures properly
    without the need of other products layered on DECmcc also having to
    re-release.
    
    ~Jon.
129.4There is some value.TOOK::SCHLENERMon May 14 1990 15:0611
    However, you should not do a direct call to the QIO services but use
    the MCC QIO services. By doing a call to QIO, you will block the entire
    MCC process. If you use the MCC services, they provide a monitor that 
    will not cause the MCC process to block.
    
    I feel that we should keep the MCC DA routines but perhaps title them
    differently so that it is clear they relate to Phase 4 DECnet access.
    They do provide some value hence saving people some time if they need
    to use Phase 4 DECnet.
    				Cindy
    
129.5MCC$QIOW is obsolete, use SYS$QIOWPETE::BURGESSMon May 14 1990 19:1120
>
>    However, you should not do a direct call to the QIO services but use
>    the MCC QIO services. By doing a call to QIO, you will block the entire
>    MCC process. If you use the MCC services, they provide a monitor that 
>    will not cause the MCC process to block.
>    

	No.

	This restriction vanished by ift of DECember 89 when blocking
	composite system services were intercepted and revectored to thread
	synchronous rtns.

	I am proposing that documentation for MCC$QIOW, MCC$<rms> 
	be removed from the SRM.  The stop-gap routines may live on, but new
	code should use SYS$QIOW, SYS$<rms>, etc!

	
	Kernel developer,
	Pete Burgess