Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!sri-spam!ames!pioneer!pstevens
From: pstevens@pioneer.arpa (Paul Stevens RCE Sterling)
Newsgroups: comp.os.vms
Subject: User Supplied System Services
Message-ID: <3009@ames.arpa>
Date: Tue, 6-Oct-87 15:29:48 EDT
Article-I.D.: ames.3009
Posted: Tue Oct  6 15:29:48 1987
Date-Received: Fri, 9-Oct-87 06:49:35 EDT
Sender: usenet@ames.arpa
Reply-To: pstevens@pioneer.UUCP (Paul Stevens RCE Sterling)
Distribution: world
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 29
Keywords: System Services, QIO

This is a question regarding using the user supplied system service
mechanism.  A user here set up his own system service using the dispatcher
template found in SYS$EXAMPLES.  He was then trying to make a QIO call
from within the system service routine (executing in kernel mode) in 
which it would use the Connect-to-Interrupt driver for controlling a
KW11 clock (convoluted huh?).  The purpose of all of this was to let
users who create many different executable images using the CONINTTER
code to use it without having to grant them all CMKRNL priv. (note that
the CONINTER code has a start-IO routine which implies CMKRNL needed)
and without having to install each new image with priv's.

The idea was that once in kernel mode the CMKRNL priv would be given
(temporarily) since kernel code has SETPRV by default and then the QIO
would be issued.  However, a crash would result apparantly in ASTDEL
after the QIO.

The question is...Is it possible to issue a QIO after having been
dispatched through a CHMK inst to the user routine (using the negative
code value).  I'm sure that the dispatching was occurring correctly.
I seem to vaguely remember that it is not possible to call QIO from within
kernel mode.  Anybody remember for sure? and if not what is the problem?

As this is rather limited in general interest you might want to email.

Thanks

Paul Stevens	NASA Ames Research Center
		Moffett Field CA 94035
		(415)694-4887