[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

628.0. "MCC_QIO routines in SRM 1.1" by CCIIS1::ROGGEBAND (_ �hili��e _) Wed Jan 16 1991 11:30

    Hello, 
    
    I have a question concerning differences between the SRM 1.0 and 1.1. I
    have been unable in the 1.1 SRM to find references to the MCC_QIOW and
    MCC_DA routines. Does this mean these are no longer supported?  If that
    is the case, which set of routines are we supposed to use for I/O's ? 
    
    Or did I look in the wrong place ? QIO routines used to be included in
    the framework routines. 
    
    Amicalement,
    
    Philippe.

T.R	Title	User	Personal Name	Date	Lines
628.1	Obsolete!	PETE::BURGESS		`Thu Jan 17 1991 10:16`	25
	MCC_QIOW, MCC_RMS_xxxx, and the MCC_DA routines have been removed from the SRM for several reasons: (1) to support platform independence. (2) value. These routines have been obsolted in MCC v1.0 and v1.1 by the framework revectoring of all the VMS composite services (asynch-op; followed by sys$synch) and the RMS services to mcc thread-synchronous framework services. This revectoring operation is performed transparently at execution time. This VMS solution allows programs to continue to use standard VMS and RMS interfaces. In the future MCC plans to use DECthreads to provide multi-threading support. At that time the MCC_QIOW, MCC_RMS_xxx, and MCC_DA_xxxx routines will no longer be included in the MCC kit.
628.2	More questions	CCIIS1::ROGGEBAND	_ �hili��e _	`Thu Jan 17 1991 10:35`	27
	re : .-1 ? (1) to support platform independence. I thought one of the ideas behind using "jacket routines" was to make sure there were no direct OS calls in modules so that they would be portable to other (U**X ?) platforms. If we are now allowed to used VMS system services, don't you think this will create rather than support platorm independence issues ? My understanding was that modules would be portable at source level to Ultrix environment. Does that mean that DECmcc/ultrix will support SYS$QIOW calls ? (2) value. These routines have been obsolted in MCC v1.0 and v1.1 by the framework revectoring of all the VMS composite services (asynch-op; followed by sys$synch) and the RMS services to mcc thread-synchronous framework services Have all system services be re-vectored, or just those which "appear" useful in a MM development context ? Is this documented anywhere? Regards, Philippe.
628.3		TOOK::SWIST	Jim Swist LKG2-2/T2 DTN 226-7102	`Thu Jan 17 1991 15:21`	9
	The calls to MCC_DA_xxxxx were very thin jackets ontop of VMS QIO. Given that explicit revectoring is no longer necessary, those routines provided no added value or portability so we removed them. A new set of MCC_DA routines will be written (someday) that don't have parameters like mailbox channels, or pass parameters with IOSBs in them, etc, etc.