Re: Speed with Fujitsu Cobol

Richard wrote:
On Dec 21, 3:36 am, donald tees <donaldt...@xxxxxxxxxxxxx> wrote:
HeyBub wrote:
Richard wrote:
On Dec 18, 6:39 am, "Euro" <e...@xxxxxxxxxxxxxxx> wrote:
I have a customer that has + or - 40 clients and a server with
windows 2000, HP PROLIANT, dual processor 2,8 MHZ, 2GB RAM to run an
application made in fujitsu powercobol, using indexed files.
The system is very slow.
That configurations recommend to me to improve the situation.
One of the problems of using indexed files on a system like this is
that the client is not just 'reading a record', it is searching the
index and transferring multiple blocks of data across the network so
that it can follow all the index levels and _then_ it reads the
record.
You need to start by analysing the problem. Measure the network
traffic, monitor the disk activity. Check the level of record locks
and collisions.
It may be, for example, that the clients are spending significant
amounts of time waiting for records locked by another client, or it
may be that the network is overloaded, or that the disk is
continuously active.
Some of these may be fixable (eg upgrade to gigabit network, or change
to SATAII or spread the load across more drives), while other problems
will need rewriting the application.
For example if there are a significant number of locked record clashes
do you simply redo the read immediately (and thus overload the network
and disk) or do you 'sleep' for a short time and then retry.
If, eg, you keep filling window lists with all records on each
interaction you may be better to load it once and hold it in an array
in the client to refill the list from the next time.
Performance is a function of application design and not just of
hardware configuration.
Agreed. the PowerCOBOL indexed file system is very efficient (i.e., fast),
but it can't over-ride the programmer's decision on file and record locking.
At the very least, the programs should be locking RECORDS, not FILES.
If the file I-O is sequestered in a subroutine, it's a simple matter to add
a few lines to log how often a lock occurs and the time it takes to resolve
collisions and locks.
The Realia ISAM system kept its own logs which could be accessed via a
stand-alone utility.
Another thought: It is possible, I guess, that the file is so hoplessly
convoluted that a reorganization is appropriate. Fujitsu has a utility
program for that purpose, or the programmer can write a reorg back-pocket
program for infrequent use.
The point on file/record locking is a good one. While the Fujitsu Isam
is very fast, I have found that the MS open/close routines are very
slow. Using file level lockout on a record by record basis will slow a
system to a crawl, and is highly dependent on the number of files in the
directory. That is one of the few things that can be checked without
looking at actual code.

How would you know that it used "file level lockout on a record by
record basis" without looking at the code.

True enough ... though I was saying that the number of files in the directory can be checked without referring to the code. That does affect open/close timing significantly. Vagueness on my part.

In fact Euro said he doesn't do that. He uses READ WITH LOCK (ie
single record lock).

Yes, I read that a couple posts further on.

Donald
.

Relevant Pages

  • Re: Speed with Fujitsu Cobol
    ... One of the problems of using indexed files on a system like this is ... that the client is not just 'reading a record', ... index and transferring multiple blocks of data across the network so ... Fujitsu has a utility program for that purpose, or the programmer can write a reorg back-pocket ...
    (comp.lang.cobol)
  • Re: Speed with Fujitsu Cobol
    ... application made in fujitsu powercobol, ... One of the problems of using indexed files on a system like this is ... that the client is not just 'reading a record', ... index and transferring multiple blocks of data across the network so ...
    (comp.lang.cobol)
  • Re: Speed with Fujitsu Cobol
    ... That configurations recommend to me to improve the situation. ... One of the problems of using indexed files on a system like this is ... that the client is not just 'reading a record', ... index and transferring multiple blocks of data across the network so ...
    (comp.lang.cobol)
  • Re: Speed with Fujitsu Cobol
    ... That configurations recommend to me to improve the situation. ... One of the problems of using indexed files on a system like this is ... that the client is not just 'reading a record', ... index and transferring multiple blocks of data across the network so ...
    (comp.lang.cobol)
  • Re: Should COBOL be lockedUP for good?...
    ... How do you _know_ that the locks will be released automatically? ... If a client machine crashes or just stops then the ... server simply never gets another message. ... gain is saving of network time, disk transfers, head moves. ...
    (comp.lang.cobol)