johnsson@chalmers.UUCP (Thomas Johnsson) (02/16/88)
I'm in dire need of some help from the PCDOS expertise out there ...
When issuing a read or a write to a diskette station or the printer
and the output unit in question is not ready (e.g. the diskette
station has its gate open, or the the power to the printer is off),
one get the message on the screen
device not ready: abort, retry, or ignore?
Now I would like to disable this, and simply let the read or write
operation return with an error indication. (I'm using the DOS file
handle operations, if that's of any help.)
Had any one out there in netland succeded in this?
Help would be greatly appreciated!
--
Thomas Johnsson
UUCP: johnsson@chalmers.uucp, CSNET: johnsson@chalmers.csnet
Dept. of CS, Chalmers University of Technology, S-412 96 Goteborg, Sweden
phone: dept: +46 (0)31 721040.nather@ut-sally.UUCP (Ed Nather) (02/22/88)
In article <2358@chalmers.UUCP>, johnsson@chalmers.UUCP (Thomas Johnsson) writes: > I'm in dire need of some help from the PCDOS expertise out there ... > > When issuing a read or a write to a diskette station or the printer > and the output unit in question is not ready (e.g. the diskette > station has its gate open, or the the power to the printer is off), > one get the message on the screen > > device not ready: abort, retry, or ignore? > > Now I would like to disable this, and simply let the read or write > operation return with an error indication. (I'm using the DOS file > handle operations, if that's of any help.) > > Had any one out there in netland succeded in this? > Help would be greatly appreciated! > Well, you can do it, but it isn't easy. What you must do is to write a "critcal error handler" in assembly code that intercepts the interrupt generated by the error, and returns control to the calling program. I wrote one that is dead simple -- it just moves the error status information to locations available to the main program, and then exits. For this to work, though, you must change the interrupt vectors so they point to your routine and not DOS's when you start up your program(s), and restore them when you exit. Here's the code I use: --------------------------------------------------------------------- EXTRN _errax:word, _errdi:word, _dskerr:word crit1 dw ? ; save orig int vectors here crit2 dw ? ;code to intercept critical error vectors push es . . . mov ax,es:90h ; int 24h - critical error mov crit1,ax mov ax,es:92h mov crit2,ax lea ax,crerr ; point to critical error handler mov es:90h,ax mov ax,_TEXT ; code segment set by C compiler mov es:92h,ax . . . pop es . . . ; code to uninstall the intercept push es . . . mov ax,crit1 ; remove crit error intercept mov es:90h,ax mov ax,crit2 mov es:92h,ax . . . pop es ; the interrupt service routine crerr PROC FAR ; disk error handler push ds push ax mov ax,DGROUP ; to get at variables mov ds,ax pop ax mov _errax,ax ; save causes mov _errdi,di mov _dskerr,1 mov al,20h ; end-of-interrupt to 8259 out 20h,al mov al,0 pop ds iret crerr endp --------------------------------------------------------------------- The error information is in the AX register and the DI register in a weird format described in the IBM PC Tech Reference manual, and is also listed in Norton's book for programming the IBM PC. These are just saved (and a flag is set) so the C program can take whatever action it wishes. It must define the variables (same name sans the underscore) as globals. It's ugly, but it works. It was also much too much trouble to do such a simple thing. -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather@astro.AS.UTEXAS.EDU
richh@pnet02.cts.com (Rich Herzog) (02/22/88)
PC Magazine presented a utility to address this problem a couple of
issues ago. They called it 'SAFARI' for 'stop all f* abort-retry-
ignore' Actually, it's kinder than that, but the ARI part is the
same. Anyway, if this utility can't be used directly, it does
show in graphic detail how to muck about in the critical-error
handler and do whatever you need. It'll get yopu on your way...
UUCP: {ihnp4!scgvaxd!cadovax rutgers!marque}!gryphon!pnet02!richh
INET: richh@pnet02.cts.commrk@gvgspd.GVG.TEK.COM (Michael R. Kesti) (02/26/88)
In article <2358@chalmers.UUCP> johnsson@chalmers.UUCP (Thomas Johnsson) writes: >[under some conditions] one gets the message on the screen > > device not ready: abort, retry, or ignore? > >Now I would like to disable this, and simply let the read or write >operation return with an error indication. The 10 NOV 87 issue of PC Magazine presents this topic in the Productivity section. It presents a program called SAFARI (Stay Away From Abort Retry or Ignore. Get it from their BBS's at 212-696-0360 or 415-598-9100. (BTW, does anyone else think that the PC Mag board has a screwy menu structure?) Michael -- ============================================================================ Michael Kesti Grass Valley Group, Inc. | "Like one and one don't make two, P.O. Box 1114 Grass Valley, CA 95945 | one and one make one." UUCP: ...!tektronix!gvgpsa!gvgspd!mrk | - The Who, Bargain
lowey@sask.UUCP (Kevin Lowey) (02/28/88)
In article <2358@chalmers.UUCP>, johnsson@chalmers.UUCP (Thomas Johnsson) writes: > When issuing a read or a write to a diskette station or the printer > and the output unit in question is not ready (e.g. the diskette > station has its gate open, or the the power to the printer is off), > one get the message on the screen > > device not ready: abort, retry, or ignore? > > Now I would like to disable this, and simply let the read or write > operation return with an error indication. (I'm using the DOS file > handle operations, if that's of any help.) Version 4.0 of Turbo Pascal allows you to trap these critical errors as normal run-time errors. It does this by trapping interrupt 24h (the critical error handler) its self. What they do is have a variable which is set whenever a critical error is found, then reset when the error status is checked, called IORESULT. This variable contains a number specifying what kind of error occurred. If you are a programmer, and you are not using Turbo 4.0 (or any other language which has this capability), then you will have to write your own Interrupt 24 handler to override the default MS-DOS Abort-Retry-Ignore message. Make sure you handle all the error conditions which can arise (write protected disk, drive door left open, disk not formatted, etc.) If you are not a programmer, you will have to get one to write a TSR program for you to do the above function. This may not be advisable however because you would lose the ability to re-start after an Abort-Retry-Ignore message by fixing the problem and typing R for Retry. If you are having this problem with a serial printer, or a communication port, you can use the MS-DOS MODE command to tell the computer to keep re-trying, rather than give the error message. You do this by adding ",P" at the end of the mode command used to initialize your serial port. Eg: MODE COM1:9600,8,n,1,P Hope this helps: ______________________________________________________________________________ | Kevin Lowey |The above is the personal opinion of Kevin | | University of Saskatchewan |Lowey. It does not reflect the position of| | Computing Services |the University of Saskatchewan in any way. | | SaskTel: (306) 966-4826 | | | Bitnet:LOWEY@SASK. (preferred) |I am in no way affiliated with any of the | | UUCP: ihnp4!sask!lowey.uucp |above mentioned companies other than U of S| |________________________________|___________________________________________|
lowey@sask.UUCP (Kevin Lowey) (02/28/88)
Oops, I forgot one important point in my last message about trapping the Abort Retry Ignore message. If you do install your own interrupt handler so you can avoid this message, don't forget to re-install the original critical error handler when your program terminates. This includes when your program terminates abnormally, like with a control-C or other runtime error. Again, Turbo Pascal 4.0 does this automatically, and also allows you to add your own cleanup routines which are executed when the program terminates (no matter HOW it terminates). The new Turbo version 4.0 interrupt routines and error handling stuff is quite impressive when compared to the old 3.0 routines. In case you are interested, I posted a TSR program in COMP.LANG.PASCAL a while back which takes over Interrupt 10h (video I/O). Many of the principles in there also apply to this problem of taking over interrupt 24 (the critical error handler). The nifty thing is it is all Turbo 4.0 code, no inline code or assembler required. ______________________________________________________________________________ | Kevin Lowey |The above is the personal opinion of Kevin | | University of Saskatchewan |Lowey. It does not reflect the position of| | Computing Services |the University of Saskatchewan in any way. | | SaskTel: (306) 966-4826 | | | Bitnet:LOWEY@SASK. (preferred) |I am in no way affiliated with any of the | | UUCP: ihnp4!sask!lowey.uucp |above mentioned companies other than U of S| |________________________________|___________________________________________|