<<< VAXAXP::NOTES$:[NOTES$LIBRARY]VMSNOTES.NOTE;1 >>> -< VAX and Alpha VMS - Digital Internal Use Only >- ================================================================================ Note 938.2 Problem with SCH$QAST 2 of 2 MUTEX::LIU 29 lines 24-MAY-1996 14:35 -< re .1 [from Oasis] >- -------------------------------------------------------------------------------- Thanks for the reply. > > The priority increment value is not something you can set to > any particular value in SCH_STD$QAST. 31 is not a valid value; > PRI$_NULL and PRI$_TIMER are. I tried PRI$_NULL before with similar effect. I was trying to recreate a sub-condition where the two programs work under a high priority and a quantum condition. > > There are routines in the executive to > get the PCB from a PID; EXE_STD$CVT_EPID_TO_PCB for example. > The example code does not look correct for this operation. > The user can get their own PCB value from CTL$GL_PCB. > I will try EXE_STD$CVT_EPID_TO_PCB however the routine in place so far has always returned the correct PCB, I know because I have save that value in a variable to have something to look at after the crash. > Why do they need cross-process ASTs anyway? There may be routines > that exist already to accomplish what they want. > Many of TMX's services call upon a process to signal another and execute a function within another processes address space. One of these service for instance the DECLARE_AST service which lets you execute a function in another processes address space that has been declared within the group. The programs provided perform this function with all of the overhead bells and whistles of the rest of TMX.