The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
New Member.
6644 views

## slow performance with concurrent users

Hello,

I'm developing in an application installed in a Windows 2003 server. The users connect to the application with mapped drives from their Windows pc's. The trouble occurs when two or more users access simultaneously to the same vision file. The first one, can runs the whole file in about 2 seconds, but the second one runs the file in about 1 minute.

I'm using 8.1.3.1 version and executing cobol programs with wrun32.exe

The mapped drive seems to work fine, i can open the folder, copy files and open them with no retard.

How can I solve this?

Tags (3)
10 Replies
Absent Member.

## RE: slow performance with concurrent users

Couple of suggestions for testing:

1)  Install AcuServer and test.

2)  You didn't mention your open method but I would suggest testing with the file open input.

Absent Member.

## RE: slow performance with concurrent users

It sounds like you may need to disable "opportunistic locking" and/or change the runtime's "SAFE" file mode access.  We have a program called "WINREG" that we call when our main program starts.  It checks the Windows registry to make sure these are set.  We added these starting with the 5.2.1 runtime to address file access speed issues in a Windows multi-user, mapped drive configuration starting with Windows 2000.  I'm not sure how to attach a file to a post, so I'll just post the source code for the program we use below.

We ran into rare instances where customers had security settings that were so strict that the normal user could not change the registry.  As you can see in the code, we added an environment setting that can be set to tell the program not to run for that user.

Also, this isn't an issue when access remote files using thin client or when not on a Windows computer, so the program checks for these conditions as well.

In addition, I don't remember when we needed "safe" mode enabled, but there is an environment setting that will re-enable/keep "safe" file access enabled.  By default, the program configures the runtime for "fast" file access.

Finally, "opportunistic locking" didn't exist on Windows ME, 98 or 95 (we've been using this program for quite a while), so it confirms the program is running on a Windows NT platform before disabling this feature.

Hope this helps!

IDENTIFICATION DIVISION.

************************************************************************

PROGRAM-ID.  WINREG IS INITIAL PROGRAM.

************************************************************************

AUTHOR. SHANE PRICE.  Bookstore Manager, Inc.

*

* Change the Windows registry to disable "opportunistic locking"

* in Windows NT-based systems (Windows 2000, 2003, XP, etc.)

*

* Change the Windows registry for the 5.2.1 and later runtime's

* "SAFE" file mode access

*

************************************************************************

DATA DIVISION.

************************************************************************

WORKING-STORAGE SECTION.

************************************************************************

COPY "\SOURCES\DEF\ACUCOBOL.DEF".

COPY "\SOURCES\DEF\ACUGUI.DEF".

COPY "\SOURCES\DEF\WINVERS.DEF".

********************************

* Registry variables

01  REGISTRY-SUBKEY-HANDLE     USAGE UNSIGNED-LONG.

01  REGISTRY-SUBKEY-NAME       PIC X(100).

01  REGISTRY-CLASS-NAME        PIC X(100).

01  REGISTRY-SAM-DESIRED       USAGE UNSIGNED-LONG.

01  REGISTRY-SAM-TEMP          USAGE UNSIGNED-LONG.

01  REGISTRY-DATA-TYPE         USAGE UNSIGNED-LONG.

01  REGISTRY-DATA-SIZE         USAGE UNSIGNED-LONG.

01  REGISTRY-VALUE-NAME        PIC X(100).

01  REGISTRY-VALUE-DATA.

03 VALUE-DATA-ORIG                         PIC X(100).

03 VALUE-BINARY  REDEFINES VALUE-DATA-ORIG PIC X(100).

03 VALUE-DWORD   REDEFINES VALUE-DATA-ORIG USAGE SIGNED-LONG.

01  REGISTRY-STATUS-CODE       PIC 9(5).

01  REGISTRY-DISPOSITION       USAGE UNSIGNED-LONG.

01  REG-COUNT                  PIC 99.

********************************

01  IGNORE-REGISTRY-UPDATE     PIC X.

************************************************************************

PROCEDURE DIVISION.

************************************************************************

MAIN-LOGIC.

************************************************************************

* if this is being called automatically when the application starts,

*   "IGNORE-REGISTRY-UPDATE" can be used as a fail-safe to allow

*   the application to start, in case the registry updates fail

ACCEPT IGNORE-REGISTRY-UPDATE

FROM ENVIRONMENT "IGNORE-REGISTRY-UPDATE".

IF IGNORE-REGISTRY-UPDATE = "Y"

EXIT PROGRAM

STOP RUN

END-IF.

ACCEPT SYSTEM-INFORMATION FROM SYSTEM-INFO.

ACCEPT TERMINAL-ABILITIES FROM TERMINAL-INFO.

* meaningless outside of Windows

* don't want to run from Thin Client

*    either way - exit program

IF IS-REMOTE OR NOT OS-IS-WIN-FAMILY

EXIT PROGRAM

STOP RUN

END-IF.

Absent Member.

## RE: slow performance with concurrent users

Just to be clear, the settings described previously for opportunistic locking, etc. need to be applied on the client machines that are running the programs and accessing the data - not on the server itself.

Your testing results with I\$IO are not surprising, as it is just another programming method to access the runtime's Vision file handler. The actual file handler is exactly the same as the one used with standard COBOL I-O syntax.

The Windows networking protocol (SMB) was designed and optimized for things like browsing files, and opening/saving documents (Word, Excel, etc.). It was not designed for multi-user concurrent file access.  That is exactly what AcuServer was designed for.

Other options you might explore would be running the programs directly on the server, and have the client PCs connect to the server using either the Acu Thin Client, Windows Terminal Services, or Citrix.

Absent Member.

## RE: slow performance with concurrent users

hI!

can post WINVERS.DEF". i dont have library

Micro Focus Expert

## RE: slow performance with concurrent users

what version are you working with and on which O/S ... the def files we provide are in the standard install AcuGT\sample\def directory.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.