Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Fujitsu COBOL decrease performance when opening file 2

Status
Not open for further replies.

jglathar

Programmer
Jun 1, 2004
8
US
We are migrating from the MBP 32-bit compiler to the Fujitsu NETCOBOL for Windows compiler.

In doing so we are seeing a decrease in performance when the files are being opened and closed.

For example we can take the same source program and only have it open and close 16 files, and there is a definate performance difference.

The MBP program does this in 0.2 seconds and the Fujitsu program takes any where from 1.3 to 2 seconds. This may not seem like a big difference, but the user will definately feel it, especially when switching from program to program.

We have all of the Fujitsu patches installed, the virus scan is diabled or not installed. Everything is also local on the machine, programs, datafiles and run-times. And it appears to be an issue more with XP that anything else. I have even asked other fellow Fujitsu developers to review this and with the same programs and source they say the definate performance difference.

I was wondering if anyone else may have experience a decrease in performance with Fujitsu ISAM files.

Thank you,

Jason

 
>And it appears to be an issue more with XP that anything else.

Non-XP platforms do not exhibit this problem?
 
This appears to be correct. Windows 2000 was slightly slower than Windows 98, but no where near the difference of Windows XP.
 
If it was a caching issue with Windows XP, I assume that other COBOL compilers, such as RM/COBOL also have a similar issue, is this correct?

Although, a program compiled with our other compiler does not have this issue.

 
It has to do with the mechanisms used to keep the data on the disk up-to-date, i.e. writing through the operating system's cache.

And, yes, for some wild reason ([smile]) RM/COBOL will exhibit this behavior as well. You may download a program from Microsoft that will change an OS setting, asserting that the disk controller has a power-protected write cache. Your slowness will then disappear.

I think xyzzy will drop in the appropriate web address soon...

Tom Morrison
 
As Tom mentioned the problem has to do with the way Microsoft handles write-caching to disk drives.

I got a hotfix from Search for "DSKCACHE.EXE" on this page. The Dskcache.exe Tool is used to Configure the "Power Protected" Write Cache Option.

Microsoft's support page also has this tool at I would recommend reading this page.

It can also be used to set the "Enable Write Cache" option. This option can also be set manually on the policies tab on the properties page of the disk drive.

You must have Service Pack 2 on Windows XP in order to configure the "Power Protected" option.

dskcache.exe /? (will display help)

dscache.exe +w +p (will enable the options)

I have been using this option for weeks and have not encountered any problems. Performance for File Open/Closes was greatly improved.

Robert Heady
Liant Software Corp.
 
Thank you all very much for the information. I wil definately be trying this. :)
 
Your test that you mention only opens/closes 16 files, and is therefore suspect. It is possible that the MBP runtime does not actually open the file until the first read/write, whereas the NetCOBOL runtime will open the file when the OPEN is encountered in the source. You might change your test to have at least one read or write, as this would eliminate this possibility.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top