Performance Cobol Files

Which the best form to increase the access speed the COBOL files in a
Windows net.

The application is developed in Fujitsu  Power COBOL V7

The access is very slow when many users try to accede the same file (OPEN
INPUT).

Use Lock "mode automatic"



Many thanks

"Euromercante" <eurogest@euromercante.pt> wrote in message
news:newscache$s6yjoi$at$1@newsfront4.netvisao.pt...
> Which the best form to increase the access speed the COBOL files in a
> Windows net.

Use better programming techniques along with better design.

Seriously, there is no 'generic best way'  to improve performance of any
kind. Every situation is different and every situation is
application-dependent.

The only thing which is constant is the first step: identify what is taking
the time.

The notorious bank robber Willie Sutton was once asked, "Why do you rob
banks, Willie?"

Mr. Sutton gave a good answer: "Because that's where they keep the money."

Same thing here: you have to know *where* your programs are using up time
before you can intelligently try to improve the performance.


In your specific case, here's something obvious:
>The access is very slow when many users try to accede the same file (OPEN
INPUT).
> Use Lock "mode automatic"

If the file is opened (by all users) only for input, why are you even
bothering with LOCK? If a lock is actually occurring, that's controlled by
your compiler. It really shouldn't issue a LOCK on access of this file, but
it may be checking for locked and/or retrying, which it shouldn't do if the
open mode is input only. But... you'd have to check what your compiler is
actually doing.

Simple enough to test: change lock mode to  manual and see what happens.

Less obvious:
If all the users are reading the whole file sequentially every time, I'd
check to see why they need to do that. Maybe indexed I-O would be better if
the user only needs one or two records from the file at any one time.

See what I mean? First I say there is no such thing as 'generic'
improvements. Then I get an idea that, well, maybe there are... but then
both these ideas end up getting qualified with application-specific
conditions.  (i.e., I should have quit while I was ahead).

MCM

Euromercante wrote:
> Which the best form to increase the access speed the COBOL files in a
> Windows net.
>
> The application is developed in Fujitsu  Power COBOL V7
>
> The access is very slow when many users try to accede the same file
> (OPEN INPUT).
>
> Use Lock "mode automatic"

The cheapest and easiest-to-implement way is to get faster computers for the
users.

"HeyBub" <heybubNOSPAM@gmail.com> wrote in
news:11la0gtlafobc4@news.supernews.com:

> Euromercante wrote: 
>
> The cheapest and easiest-to-implement way is to get faster computers
> for the users.
>
>

With Microfocus, you could try leaving the "mode" keyword
out of the select altogether.  This gives you "Deny write" mode,
which is MANY times faster than "mode is manual".

This would be worth trying in Fujitsu as well.

What mode are you using anyway?

On Tue, 18 Oct 2005 11:53:34 +0100, "Euromercante"
<eurogest@euromercante.pt> wrote:

>Which the best form to increase the access speed the COBOL files in a
>Windows net.
>
>The application is developed in Fujitsu  Power COBOL V7
>
>The access is very slow when many users try to accede the same file (OPEN
>INPUT).
>
>Use Lock "mode automatic"
Where is the file located?
what access type are you doing (sequential, indexed)
What is the size of the file, and how many indexes does it have (if
indexed).
Are you using the VERY LARGE file DLL or the normal one?


If using a Windows server and with the file located on the server how
is the file being accessed (UNC or mapped drive)
How are file caching parameters set to both the server and the
workstations?

How are opportunistics locks set (hopefully OFF!!!)

And how many users are we speaking of?



Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Thank for the tips!
I altered the program for "LOCK MODE MANUAL", the speed improved some thing.
However the program in cause should also have influences,  use many
"PERFORME XXX THRU XXX.
What I notice is that compiling with the option "optimize" or without
"optimize" i do not notice any difference.
Regards,

JM



"Euromercante" <eurogest@euromercante.pt> wrote in message
news:newscache$s6yjoi$at$1@newsfront4.netvisao.pt...
> Which the best form to increase the access speed the COBOL files in a
> Windows net.
>
> The application is developed in Fujitsu  Power COBOL V7
>
> The access is very slow when many users try to accede the same file (OPEN
> INPUT).
>
> Use Lock "mode automatic"
>
>
>
> Many thanks
>
>
>
>

Olá Frederico!

> If using a Windows server and with the file located on the server how
> is the file being accessed (UNC or mapped drive)
F:\XXX\...
(mapped drive)

> How are file caching parameters set to both the server and the
> workstations?
server : System cache
workstation: programs
(I don't know if I am  understand the question)

>
> How are opportunistics locks set (hopefully OFF!!!)
>

> And how many users are we speaking of?
+ or - 40 users

>
>
>
> Frederico Fonseca
> ema il: frederico_fonseca at syssoft-int.com

> The access is very slow when many users try to accede the same file
> (OPEN INPUT).

> The cheapest and easiest-to-implement way is to get faster computers
> for the users.

That is the fastest way to get no improvement at all.  It is most
likely that the problem is the network where the file records are
transferring between machines, the next likely cause is the fact that
it is Windows on the server. The speed of the user machines is likely
to be irrelevant.

> Which the best form to increase the access speed the
> COBOL files in a Windows net.

> The access is very slow when many users try to accede
> the same file (OPEN INPUT).

How are the files read ? Are the users reading the whole file or is it
just reading a few records by key ?  If the whole file then how big is
it ?  The data needs to travel over the network.

You need to check the speed of the network cabling and measure the
traffic over the network. If you have only got 10 Mbit network you need
to replace the network cards in each machine and the hub with 100 MBit
or Gigabit network.

It seems that the file will be on a Windows machine (_there's_ the
problem!!). Is it using FAT or NTFS ?  FAT will be quite slow for large
files.  Are there lots of files in the directory ?

"Euromercante" <eurogest@euromercante.pt> wrote in message
news:newscache$nqekoi$1fb$1@newsfront4.netvisao.pt...
> What I notice is that compiling with the option "optimize" or without
> "optimize" i do not notice any difference.

And what does that tell you?

What it should tell you is there is nothing in your code technique which is
an obvious source of problems; i.e., your problem is elsewhere: File access,
network access or (my personal candidate) a 'less-than-optimal' design.
(Because design is always my prime candidate, that's why).

MCM