Frequently Asked Questions


Is AcuServer faster or more secure than using mapped drives in Windows environments?


Some operating environments implement aggressive file caching techniques, such as mapped drives, to improve file processing speed. However, errors in these buffering techniques can occasionally lead to corrupted files. AcuServer cannot always match the file processing speeds of the caching methods, but it is faster in certain situations and provides better file integrity. One situation in which the use of file caching techniques (instead of AcuServer) could lead to a caching error and corrupted files is described below.

When an ACUCOBOL-GT runtime asks that a record be rewritten to a file that is shared among multiple clients, the runtime might receive a response indicating that the operating system has correctly rewritten the record, when in fact the record may still be in a memory cache. If a second runtime (on a separate system) then asks for the same record, it will receive a copy of the unchanged record from the shared disk. When this second runtime rewrites the record, the data may actually be cached on this second system, just as it was cached on the first. In this situation, somebody's update to the record is going to be lost when the actual rewrites occur. If the rewrites contain index information as well as data, the problem might include structural file damage, leading to broken files.

Windows-based clients with mapped drives on a Windows NT server can easily fall into this category because of a caching bug. An ACUCOBOL-GT runtime executing on Windows client machines with data files on mapped drives on a Windows NT server can run faster than AcuServer, because the Windows client systems are caching data writes in their local memory. This approach can give increased file performance as long as the number of clients remains small. This file performance advantage begins to disappear as user counts increase. However, at any number of users, this scheme is at risk for data corruption, which is entirely dependent on timing vagaries. Even with a small user count, the scenario noted in the previous paragraph could occur. AcuServer provides better file integrity than the caching approach.

AcuServer can improve file performance in certain situations. AcuServer is faster than shared drives in situations where two or more users are accessing a single file in an interactive mode. This is because Windows caches mapped disk network files if only one user is in the file, but as soon as another user enters the file caching is terminated. Windows does not seem to know when caching can recommence.

In addition, consider the case of a keyed READ or START to a Vision file that has an average index tree height of four. The root node of the index tree is located by a field in the header, so a read of the header is necessary, followed by an average of four reads to move through the levels of index records, finally followed by a read of the data record. If a client runtime is using mapped drives, each of those reads must be transmitted across the network, with possibly hundreds of bytes of information returning to the client runtime for each read. If AcuServer is being used, the client runtime calls the appropriate file routine in AcuServer via one socket call. AcuServer knows how to issue all the reads to find the root node of the indexes, to track the needed record through the index tree and to read the data record, and all of this is done on the server with no network traffic. The requested data record is then transmitted back to the client runtime over the network. This approach represents significantly less network traffic than having the client runtime itself do each of the I/Os across the network.


In my Windows NT environment, I would like AcuServer to serve some of the COBOL objects and data files for my application, but I would also like to access some of the objects and data files via mapped drives. May I do so?


Yes. You can use CODE_PREFIX, FILE_PREFIX, or file aliases in the client runtime configuration file. For example:

CODE_PREFIX @server1:C:\path\sub H:\path\sub
FILE_PREFIX @server1:C:\path\sub H:\path\sub
filea @server1:C:\path\sub
fileb H:\path\sub\fileb

The first two examples above rely on the fact that a runtime will use the CODE_PREFIX or FILE_PREFIX entries left to right, in a continuing search to find the COBOL object or data file. The first two examples will direct the client runtime to first ask AcuServer to serve the COBOL objects and data files. If AcuServer can't find them, the runtime is directed to look for them on the mapped drive. You could reverse the search by reversing the sequence of the entries in CODE_PREFIX or FILE_PREFIX. Specifying individual file aliases will be faster than FILE_PREFIX in opening data files.


Which releases of AcuServer are currently supported?


Our Technical Services continues to offer support for every release of AcuServer and would be pleased to answer your questions about any version of the product. However, all releases of AcuServer prior to Version 5.2 have been retired from our sales portfolio. This means that the older versions are no longer sold, and that you obtain a correction to a problem uncovered in a retired version by updating your site to the latest version that contains the fix.


Is AcuServer able to print files?


AcuServer is a file server. This means that it services file operations. To print, the runtime submits a process to the printer (in the case of Windows NT, it submits a spooler job). Because AcuServer is not intended to service (or start) processes, it is not able to print files to a printer. However, the programmer could use AcuConnect® in conjunction with AcuServer to achieve this functionality. Another option is to assign the print file to disk by establishing an alias for the file in the runtime configuration file with the -f flag, as shown in this example:

printer1 -f /usr2/users/jsmith/printer1

This causes a file named printer1 to be created in the /usr2/users/jsmith directory. This file is a line sequential file with additional formatting characters.


Is AcuServer multi-threaded?


AcuServer is single-threaded. AcuServer processes each request to completion, on a first-come-first-served basis. This means that while AcuServer is engaged in handling a request from one client runtime, other runtime requests are queued in a manner appropriate to the server's operating system, awaiting AcuServer's completion of the current request.

Multiple instances of AcuServer can be executed on the same server or on multiple servers. Each separate instance of AcuServer is a single-threaded program.


AcuServer's response to -info is larger than will fit on my screen, and I lose the information that scrolls past the top. How can I see it all?


Use the properties ability of a command prompt to increase the size of the window or:

  • On UNIX:
    • For the sh and ksh shells, use:
      acuserve –info 2> somefilename
    • for the csh shell, use:
      acuserve –info >& somefilename
  • On Windows NT:
    acuserve –info 2> somefilename 

    Then use any editor to view somefilename.


The entries I previously used for FILE_PREFIX and CODE_PREFIX in the configuration file when AcuServer was on UNIX don't work for Windows NT (or vice versa). Which is correct?


The entries need to comply with operating system naming conventions.

On UNIX, the use of the colon and the direction of the slash are relevant:

FILE_PREFIX @servername:/path
CODE_PREFIX @servername:/path

On Windows NT, the direction of the slash is not important, but the drive designation must be included along with the pathname:

FILE_PREFIX @servername:C:\path     
CODE_PREFIX @servername:C:\path

(where C is a drive letter)


I'm sure I have sufficient values specified in MAX_FILES, MAX_LOCKS, and LOCKS_PER_FILE in the client configuration file and in the AcuServer configuration file. But I still can't open all the files my application needs, or my application runs out of locks. How can I solve this?


In most UNIX operating environments, there is a limit to the maximum number of files that can be opened by any process and the maximum number of locks that can be held by any process. These limits are set in the UNIX kernel. If the settings of these kernel parameters are too low, AcuServer may reach these kernel limits before ever reaching the values you have specified in MAX_FILES, MAX_LOCKS, or LOCKS_PER_FILE.

If you have a C compiler on your UNIX system, you might want to make use of a C utility program (numfiles.c) that is available from our Technical Services. This utility can help you determine how many files your UNIX system will allow a process to open. The utility simply attempts to open 1,000 files and reports the number of the last file it was able to open successfully (if you would like to attempt a smaller or larger number of file opens, change the #define NUM_FILES).

The tuning of the kernel parameters on your UNIX systems is specific to your site and should be determined by your local specialist. Contact your UNIX system administrator to research or change the values of the kernel parameters that control maximum files per process or maximum locks per process at your site.


I'm sure my client system has a valid connection to the server and that the files I'm trying to reach exist, but my attempts to access the files lead to an access denied error (File error 37,07 on @servername:/path/sub/file). How can I solve this?


This file error indicates that file permissions are probably not set up in a way that allows access. It may stem from variables set in your client system, so let's examine those variables first.

When a client runtime attempts to connect to AcuServer, it passes two variables to AcuServer: the client machine name and client user name. AcuServer checks the values of these two variables against the server access file (called AcuAccess by default). AcuAccess contains one or more access records. These access records define which users of which clients are permitted access to AcuServer. AcuAccess is designed to support a wide range of access security, from very open to very restrictive. You choose the level of security best suited to your needs.

The first variable passed from the client is matched against the AcuAccess field Client-Machine-Name, and the second is matched against Client-Username. See Diagnosing Errors with C$PING for a complete description of where those variables come from on various client systems. AcuServer Connection Logic describes how AcuServer uses these variables to determine which account will be used on the server for file access.) AcuAccess will look first for a specific match for the client variables, then for a wildcard that might allow access to the client. This example shows how you can uncover the source of a permissions problem at your site.

Execute AcuServer with a trace file, as shown here:

acuserve –start –e errorfile –t3

Attempt to connect to AcuServer, then after the failure, examine errorfile. You should see lines that resemble this:

acuserve: 08/13/99 17:48:39 – AUTHORIZATION request from user: klevine
>> Socket:0, client:klevine-ntw, pid:282, PASSWORD-ATTEMPTS allowed:3
>>>key 0 = 'klevine-ntw         klevine         '
>>>key 0 = 'klevine-ntw                         '
>>>key 0 = '*                   klevine         '
>>>key 0 = '*                                   '
>> Mapping user: klevine to local user:guest   acuserve: LookupAccountName for guest

In the above example, klevine-ntw is the variable from the client that is matched to Client-Machine-Name, and klevine is the variable that is matched to Client-Username in AcuAccess.

In the above example, the AcuAccess file on the server had a single access record:

Client Machine Name  Client Username  Local Username   Password   Umask
-------------------  ---------------  --------------   --------   -----
*                                     guest            <none>     002

Note that the Client-Machine-Name is a wildcard (matches any name). The Client Username is set to spaces. AcuServer attempts to find an AcuAccess record that has klevine-ntw as Client-Machine-Name AND klevine as Client-Username. There is no such record in the file. See AcuServer Connection Logic for more information.

Next, AcuServer attempts to find a record that has klevine-ntw as Client-Machine-Name AND spaces as Client-Username. There is no such record in the file.

Next, AcuServer attempts to find a record that has "*" as Client-Machine-Name AND klevine as Client-Username. There is no such record in the file.

Finally, AcuServer attempts to find a record that has "*" as Client-Machine-Name AND spaces as Client-Username. Such a record exists in the AcuAccess file, with the Local-Username set to guest.

AcuServer verifies that guest (in the sample above) is valid on this server. Because guest is valid on this server, future file requests from this client will be treated on the server as if guest had made the requests.

If the user specified in Local Username of the AcuAccess file is not valid on the server, the AcuServer configuration variable DEFAULT_USER will be used. If this is a valid user on the server, future file requests from this client will be treated on the server as if DEFAULT_USER had made the requests.

(If neither the Local Username of the appropriate record in the AcuAccess file nor DEFAULT_USER is valid on the server, the Authorization Request is denied.)

In our example, if receiving an access denied error (File error 37,07 on @servername:/path/sub/file), the Client-Machine-Name and Client-Username are still acceptable for the AcuAccess file shown above. Thus, in this case the error message must indicate that Local Username guest doesn't have permission to access the files the application needs.


I'm sure my client system has a valid connection to the server and that the files I'm trying to reach exist, but my attempts to access the files lead to a File not found error (File error 35 on @servername:/path/sub/file). How do I solve this?


This might be caused by insufficient file permissions or by a client runtime that is not AcuServer-enabled.

  1. Verify that the client runtime being used is AcuServer-enabled. At a command line prompt, type:
    <name-of-your-runtime> –v

    Depending on your client platform and runtime version, the response may include a line like:

    AcuServer client


    Network enabled

    Absence of a line similar to one of the two shown above indicates that your runtime does not have the ability to communicate with AcuServer. Contact your Micro Focus extend sales representative to obtain a runtime that does have that capacity.

  2. See the discussion in the preceding question about how AcuServer authorizes a client runtime. The most likely cause of this error is that the local user who was finally selected on the server machine does not have write permissions in the named directory, and the COBOL program is trying to open the file OUTPUT.


Client runtimes experience slow response times during heavy loads (perhaps sometimes even exhausting the DEFAULT_TIMEOUT value and returning 9D/05). Is there anything I can do?


Here are several options to consider:

  1. AcuServer is single-threaded, handling a single request from a single client runtime to completion before attending to requests from other client runtimes, which are queued up in a manner dependent on the server's operating system. Slow response time may indicate that a single copy of AcuServer cannot keep ahead of the queued requests at times of peak load.

    If the load on AcuServer is variable, the DEFAULT_TIMEOUT tolerance allowed by client runtimes may be sufficient most of the time, but may be too brief to allow for the times when AcuServer is heavily burdened. In those cases, setting DEFAULT_TIMEOUT to a higher value can avoid the timeout errors. (On the other hand, if AcuServer is actually unable to access the data for some other reason – such as insufficient file permissions – then increasing DEFAULT_TIMEOUT only increases the amount of time that transpires before the client runtime returns the error message.)

    If there are sufficient system resources available on the server (memory, CPU cycles, I/O bandpass to multiple disks, and so forth), you may gain relief by acquiring an appropriate license and executing multiple instances of AcuServer on the same server. On the server, the operating system will use the time while one instance of AcuServer is waiting for the completion of an I/O process to allow another instance of AcuServer to have the CPU. This second instance of AcuServer will also then issue some I/O command of its own, and (assuming that there are multiple I/O subsystems capable of independent action), the I/O wait time of the multiple instances will interleave. A server with multiple CPUs may gain even more improvement with this approach.

    If you choose to run multiple instances of AcuServer, note that there is no automatic balancing of the load among them. You must direct each specific client runtime to use a particular AcuServer by (a) starting each instance of AcuServer with a particular ACUSERVER_PORT number and (b) setting the client runtime configuration variable of the same name to that value.

  2. You can choose to execute multiple instances of AcuServer on separate servers. In this case, you need not start each AcuServer with a separate ACUSERVER_PORT setting, as noted above. Rather, you would use FILE_PREFIX or file aliases in the client runtime configuration file to direct specific client runtimes to AcuServers running on specific servers. For example:

    In the runtime configuration file of client A:

    FILE_PREFIX @server1:/path/sub

    In the runtime configuration file of client B:

    FILE_PREFIX @server2:/path/sub
  3. You could combine approaches (1) and (2) and run multiple instances of AcuServer on multiple servers. In that case, each instance of AcuServer would need to be started with a ACUSERVER_PORT unique on that server. FILE_PREFIX or file aliases would be needed in each client runtime configuration file to point to the appropriate server. Also, ACUSERVER_PORT would need to be set to point to the appropriate instance of AcuServer on that server.
  4. If there are no runtimes executing on the server, or if the runtimes executing on the server don't use the same files that are being requested by the client runtimes, you can improve performance by directing AcuServer to open data files for exclusive use. To do this, set the AcuServer configuration variable LOCK_ALL_FILES to 1. With this variable on, AcuServer will open data files for exclusive use rather than using individual record locks; this will improve throughput. Note that this is not a workable option if multiple instances of AcuServer will be executed on the same server and will be accessing the same data files.

    (If the runtimes executing on the server do use the same files as client runtimes, you can direct the runtimes on the server to also use AcuServer, rather than opening the files themselves, by setting USE_LOCAL_SERVER to 1 in their configuration files. This will allow use of LOCK_ALL_FILES as noted above, so AcuServer can again open the data files for exclusive use, which is faster.)

  5. If client runtimes need to open files that may be located in various directories on one server or may be located on various servers, it is faster to use file aliases rather than a FILE_PREFIX that points to multiple paths or multiple servers. A great deal of network traffic can be avoided in those cases where the file that a client runtime is seeking happens to be in the last directory or on the last server specified in FILE_PREFIX. For example:
    FILE_PREFIX @server1:/path1a/sub1a @server1:/path1b/sub1b @server1:/path1c/sub1c 

    The above method would be slower at opening files than:

    filea @server1:/path1a/sub1a/filea
    fileb @server1:/path1b/sub1b/fileb
    filec @server1:/path1c/sub1c/filec

    And notice:

    FILE_PREFIX @server1:/path/sub @server2:/path/sub @server3:/path/sub 

    The above settings would be slower at opening files than:

    filea @server1:/path/sub/filea
    fileb @server2:/path/sub/fileb
    filec @server3:/path/sub/filec
  6. The AcuServer server configuration file can use the following variables:

    Setting those variables in the AcuServer server configuration file overrides any setting of the identically named variables in the client runtime configuration file. These variables have the same function on AcuServer as they have on a client runtime, and they can affect file performance. Consult Appendix H. Configuration Variables in the ACUCOBOL-GT manual set for specifics.

  7. You have chosen AcuServer for its ability to serve COBOL object files and data files for your application. However, these data accesses may be overloading your network. If analysis of network performance indicates that network overloading is contributing to your application response time slowdown, consider that some data files in your application might be able to reside on the client system. The goal is to reduce the amount of traffic over the network. Some possibilities in this regard are:
    1. If the application creates temporary files, also consider placing them on a local drive. If the file is useful only on a particular client, and need never be seen by other client systems on the network, you can reduce the network burden by using a file alias in the client configuration file to place this file on a local drive.
    2. If the application has some data files that do need to be seen by every client runtime, but are only updated periodically, consider placing copies of these files on each client system and pointing at them with file aliases. Again the goal is to reduce network traffic. You would have to balance the administrative work of getting correct copies of these files placed on each client in a timely fashion against the gain in network performance by keeping access to these files off the network.