Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ucla-cs!sdcrdcf!burdvax!bpa!cbmvax!carolyn From: carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner CATS) Newsgroups: comp.sys.amiga Subject: Re: Printer bug Message-ID: <1793@cbmvax.cbmvax.cbm.UUCP> Date: Thu, 30-Apr-87 11:17:23 EDT Article-I.D.: cbmvax.1793 Posted: Thu Apr 30 11:17:23 1987 Date-Received: Sat, 2-May-87 14:40:43 EDT References: <1610@rutgers.RUTGERS.EDU> Reply-To: carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) Organization: Commodore Technology, West Chester, PA Lines: 37 In article <1610@rutgers.RUTGERS.EDU> RFORSTER@UNCAEDU.BITNET writes: >From: > >Subject: printer device bug (I think) >[] >It seems that the printer device keeps using something in the messages >you send it EVEN AFTER it has replyed to them! I was trying to abort a >graphics dump that had been started by the dump raster port command and >which was in the process of writing on the printer with either the >FLUSH, AbortIO(), or RESET commands (I tried all three ways separately) >and kept getting unpredictable GURUs. I say unpredictable because >sometimes the abort would work and I could sometimes do several attempts >aborting each one successfully, however eventually I would get a >VISITATION. >[] There may be problems in the printer's handling of aborted requests, but the GURU should only be visiting if you failed to remove the request. To abort an asynchronous (SendIO()'d) printer request, try: if(!Checkio(ioreq)) { AbortIO(ioreq); } WaitIO(ioreq); <--- Removes the request Your GURU problems should disappear. Unfortunately, some memory will also disappear since the current printer.device is unable to de-allocate graphic buffers when a DUMPRPORT request is aborted. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=