Re: Client/Server Fujitsu Cobol appplications
From: jason (vyjs2m_at_hotmail.com)
Date: 15 Apr 2004 05:38:12 -0700
riplin@Azonic.co.nz (Richard) wrote in message news:<firstname.lastname@example.org>...
> "Euromercante" <email@example.com> wrote
> > 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?
> 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.