Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!uwvax!tank!eecae!dsacng1!dsacg1!dsacg3!vfm6066
From: vfm6066@dsacg3.UUCP (John A. Ebersold)
Newsgroups: comp.databases
Subject: Re: ACCELL/CP - Any users with thoughts!
Message-ID: <1468@dsacg3.UUCP>
Date: 27 Apr 89 17:18:43 GMT
References: <7495@charlie.OZ> <7139@mrspoc.UUCP>
Reply-To: vfm6066@dsacg3.dla.mil.UUCP (John A. Ebersold)
Organization: Defense Logistics Agency Systems Automation Center, Columbus
Lines: 59

In article <7139@mrspoc.UUCP> itkin@mrspoc (Steven List) writes:
>In article <7495@charlie.OZ> wayne@libra.cc.deakin.OZ () writes:
>> Are there any users of ACCELL/CP that can give me
>> feedback as to its performance (good/bad?). Does it free
>> the processor of I/O significantly to improve database
>> performance?
>> 

Some nice stuff about ACCELL/CP deleted....

>This is largely a
>function of the fact that the PC is performing much of the local field
>editing and cursor movement.

Offloading the need to do single character reads.

>The cost, however, is that the PC MUST
>communicated with the host EACH TIME YOU MOVE BETWEEN FIELDS!  Thus, for
>one user, there is still a noticeable pause when you press RETURN before
>the cursor moves to the next field.

Have you tried making the packet the PC sends, small like 96 bytes
or less?  (Aside: This is configurable at each PC using ACCELL/CP.) 
I looked at this problem a while back and concluded that 96 or
less was a good figure.  It provided a good balance bewteen field to field
movement and updating a record.  In my tests at 9600 baud, I noticed a
SLIGHT pause before the cursor moved to the next field - very livable (sp?).

>Where I think there is the potential for far better gains will be the
>networked version of ACCELL/CP whenever that becomes a reality.

I believe - a networked version of ACCELL/CP is available with ACCELL/SQL.

>I think that the biggest problem with ACCELL/CP is that cost of
>communicating between host and PC at terminal speeds (9600 or 19200).

Could you expand upon this statement please?

>There is one other problem that we experienced with ACCELL/CP: it was
>apparently not well tested with multi-occurrence forms (one of my
>favorite feature of ACCELL).  It frequently bombs out with messages
>about the "host not cooperating".

If the host is very busy a timeout can occur, try adjusting the packet
timeout values.

>
>For me, the net is that I don't plan to use ACCELL/CP until and if the
>performance is reasonable with ONE user.

I suggest that by adjusting the packet size and timeout values you can get
things to work the way you want.


-- 
John A. Ebersold  at  Defense Logistics Agency   osu-cis!dsacg1!dsacg3!vfm6066  
Unify Corporation     System Automation Center   Columbus, Ohio 1-614-238-5923
Me?  Speak for anyone else?  Don't be ridiculous!                  AV 850-5923
Systems with poorly understood requirements cannot be developed in a crunch.