Glenn, thanks for the help so far and the info of the duplicate scheme. I have not been able to tes twhat you sent because I had had a bad bout with the flu. I will get to it ASAP. I think the revised DKDRIVERs may be our best solution temporarily. I promise to sstay in touch on this and let you knwo how the V7.0 and V6.2 versions work as soon as I am feeling better. Rick Cadruvi R&D Performance Group, Inc. 1180 E Patricia #102 Simi Valley, CA 93065 (805)520-4170 (office) (805)520-4173 (direct desk) (805)520-4169 (fax) rick@rdperf.com From: SMTP%"everhart@row.enet.dec.com" 24-DEC-1996 12:02:54.08 To: "rick@rdperf.com"@3049.ENET.dec.com CC: Subj: Re: DKDRIVER & Device I/O Intercept Looking quickly over the code, it may be that your UCB duplicating scheme will work on dkdriver. The SCSI structures generally don't keep UCB pointers in them apart from the SCDRPs, which are the scsi variants of IRPs. The basic problem is that dkdriver keeps a bunch of queues with headers in its private UCB extension, and if it couldn't find that, it may just quickly wedge out on you. Also a number of flags about the state of various operations are kept there. (Could be I need to send you a source so you can see this.) If you pass the real UCB to dkdriver, it can find the right places for its stuff. If it is known idle, it would use the copy UCB area and probably would be ok. Finding out that it's idle, though, can be interesting. Some of the flags are set at unit init, others when packack'd, others at other times. But still, if you could relocate them all correctly (the queues are of course set up by unit init, and copies would point at the original UCB, not the copies) things might work. Maintenance nightmare though... you CANNOT count on the DK UCB extension being left in its current order; I can almost guarantee it'll change, possibly drastically. Even at 1H releases!!! I tried the V7.1 version of what I sent and it did boot and ran under as heavy a load as I could give it OK. Wasn't that heavy...backup of a big chunk of disk to nla0: (/nocrc) and simultaneous access from other windows, but it's still just a 3000-400. But not even a hiccup. Booted and ran 7.1 just fine. BTW, DK in 7.1 also has alternate ucb pointers filled in and switching code being developed WILL use them if they are. Don't assume the contrary; I have code that does this now. (Goddam dk is a knotty problem.) Glenn ================== RFC 822 Headers ================== Return-Path: everhart@row.enet.dec.com Received: by spia.rdperf.com (UCX V4.1-12, OpenVMS V6.1 Alpha); Tue, 24 Dec 1996 12:02:48 -0800 Received: from us2rmc.zko.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA18240; Tue, 24 Dec 1996 14:51:51 -0500 (EST) From: Received: from row.enet by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA28608; Tue, 24 Dec 96 14:37:37 -0500 Message-Id: <9612241937.AA28608@us2rmc.zko.dec.com> Received: from row.enet; by us2rmc.enet; Tue, 24 Dec 96 14:51:34 EST Date: Tue, 24 Dec 96 14:51:34 EST To: "rick@rdperf.com"@3049.ENET.dec.com Apparently-To: rick@rdperf.com Subject: Re: DKDRIVER & Device I/O Intercept % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA27371; Fri, 27 Dec 96 17:11:01 -0500 % From: rick@rdperf.com % Received: from SPIA by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id RAA15512; Fri, 27 Dec 1996 17:09:50 -0500 (EST) % Date: Fri, 27 Dec 1996 14:09:34 -0800 % Message-Id: <96122714093452@rdperf.com> % To: row::everhart % Subject: Re: DKDRIVER & Device I/O Intercept % X-Vms-To: SMTP%"everhart@row.enet.dec.com" % X-Vms-Cc: RICK