Home > Archive > Cobol > April 2004 > Client/Server Fujitsu Cobol appplications
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Client/Server Fujitsu Cobol appplications
|
|
| Euromercante 2004-04-10, 1:30 pm |
| Hi!
I've an application installed in the server (2003 server; 1GB RAM) and
in the clients I've installed the runtime of Fujitsu on PC's with XP up to
40 PC's. We shared a folder with our application (with our cobol database
files) in the server.
I'm having some problems, because sometimes when I run a module of my
application it takes 30 seconds and sometimes it takes more then 5 minutes.
Do you know any similar situations, or why this is happening??
Do you know a better way to configure this "Client/Server" application?
Thanks
JM
| |
|
| riplin@Azonic.co.nz (Richard) wrote in message news:<217e491a.0404061107.216f412@posting.google.com>...
> "Euromercante" <euro@dsdd.com> wrote
>
>
> You are most likely saturating the network with raw file block
> accesses. Running the clients with shared file access on the server
> means that with ISAM file the client will want to read the index
> blocks for each data record read. A random read of one record may
> require a dozen index block accesses. Of course these blocks cannot
> be cached in the client because they may change as records are added
> by others.
>
> It may also be lock contention. If there are a few records that are
> used frequently and these are locked while user do input then the
> programs may be spending long times waiting for locks to become free.
>
> Or it may be that the programs are doing just too much file access.
> They may be reading files sequentially searching for data when they
> should have had an index to get the data directly.
>
> Nothing that a complete redesign can't fix.
Fujitsu Cobol tech. suport says
1)it is better to use
LOCK MODE MANUAL WITH LOCK ON MULTIPLE RECORDS
not AUTOMATIC LOCK
2)Lock a record [read with lock, read next with lock]
only when you want to update/delete a record, and
release it right away when the update work is done.
3) Check the 2-byte file status for record lock ("99")
and return control to your program for proper actions.
These might ease the slow response problem.
good lock,
jason mo
|
|
|
|
|