George, That had occurred to me as well, but this section of code is definitely executing in user mode. The job can be manually removed using an S*BASIC RJOB command or from the QPAC Jobs list. However, I'm sure the clue does lie in the fact that the trap is not guaranteed atomic.
Adrian -----Original Message----- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of gdgqler Sent: 30 January 2011 10:37 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing On 30 Jan 2011, at 10:25, Adrian Ives wrote: > I am in the process of rewriting the USBWiz driver to get around the > problems with supervisor mode that I encountered last year. > > > > The new driver spawns independent jobs to handle reads and writes > asynchronously in the background (because it has to invoke serial IO). > I'm doing the work in QPC2 and I've encountered a problem with calls > to MT.FRJOB. > > > > This is the code that I'm using at the end of my USB_RD (and USB_WR) job: > > > > moveq #mt.frjob,d0 > > moveq #me,d1 > > moveq #0,d3 > > trap #1 ; > Remove ourselves! > > > > The only problem is that it doesn't work! It actually returns err.nc > (Not > Complete) and the job continues executing. Calls to mt.susjb and > mt.prior succeed (d0 is zero on return) but don't actually do what they should. > > > > I'm beginning to think it's a QPC2 thing, but before I unpack the > Aurora QL from its hermetically sealed casket in the garden shed, can > anyone shed any light on the reasons why these traps should fail in this way? > > mt.frjob may not work in supervisor mode. The manual (Dickens) says "this trap is not guaranteed atomic". Could this be the problem? George _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
