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.
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.
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. 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:
acuserve –info 2> somefilename
acuserve –info >& somefilename
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 (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, 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.
<name-of-your-runtime> –v
Depending on your client platform and runtime version, the response may include a line like:
AcuServer client
or
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.
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:
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.
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
(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.)
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
V_BUFFERS V_BUFFER_DATA V_READ_AHEAD
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.