Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!DRCVAX.ARPA!graham From: graham@DRCVAX.ARPA Newsgroups: comp.os.vms Subject: RE: IMPROVING RESPONSE TIME ON A MICROVAX II Message-ID: <8707221511.AA00852@ucbvax.Berkeley.EDU> Date: Tue, 21-Jul-87 08:19:00 EDT Article-I.D.: ucbvax.8707221511.AA00852 Posted: Tue Jul 21 08:19:00 1987 Date-Received: Fri, 24-Jul-87 04:47:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To:Distribution: world Organization: The ARPA Internet Lines: 24 Probably the greatest item affecting the response time for you is Datatrieve itself. Neither Datatrieve nor Rdb were designed for long text record processing. They do not function optimally in this mode. Because of the string matching you are doing, there is little that can be done to change the number of disk I/O. You might try distributing the data files on different disks, thus minimizing the I/O to any one disk. The real slowdown place is in the activation of Datatrieve. Because of the way Datatrieve works, with several different files being accessed each time it is activated, it starts slowly, and that's pretty fixed in concrete. Good Luck, Hackito, ergo sum. Dan Graham, Dynamics Research Corporation, (617) 475-9090 Ext. 2352 GRAHAM@DRCVAX.ARPA Hoc est meum hackum. Ideas and opinions are mine, not my employers. In fact, my employer barely claims to know me at all. I make no claim to sanity in any form or on any level. ------