AcuServer™ FAQ

August 1, 2001

The following information pertains to Version 4.2 and 4.3 of the AcuServer™ product from Acucorp, Inc. AcuServer provides full function remote access from UNIX, Windows NT (Intel), Windows 95/98, Windows 3.1, and DOS clients to all Vision, relative, sequential, and object files stored on any UNIX or Windows NT (Intel) server equipped with AcuServer

I'm considering using AcuServer with my application. Will it be faster or more secure than other possible approaches (such as mapped drives in Windows or Novell environments)?
What is "RPC" and how is it used by AcuServer?
In my Windows NT or Novell 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?
Which releases of AcuServer are currently supported by Acucorp?
Is AcuServer able to print files?
Is AcuServer "multi-threaded"?
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?
In a Windows environment, I'm receiving client runtime errors in the format "9D,200xx". I cannot locate these error messages in the AcuServer User's Guide. What do they mean?
RPC error codes seem fairly terse. What do they mean?
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?
On Windows NT, the only portmap utility that can be successfully used is the one that is distributed by Acucorp. How can I tell which portmap is running?
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?
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?
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?
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?

I'm considering using AcuServer with my application. Will it be faster or more secure than other possible approaches (such as mapped drives in Windows or Novell 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. Following is a description of one situation in which file caching techniques were used (instead of AcuServer), and a caching error led to corrupted files.
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 due to 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. For example, 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 Novell or 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 remote procedure call (RPC). 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.

Back to top
What is "RPC" and how is it used by AcuServer?
This acronym stands for Remote Procedure Call. AcuServer uses RPC technology to make efficient use of network resources. In the absence of configuration variables that specify remote file names, a client runtime responds to COBOL file actions (OPEN, CLOSE, READ, WRITE, etc.) by invoking the appropriate file routine within the client runtime itself. However, when configuration variables specify remote file names, a client runtime makes a Remote Procedure Call across the network to the identical file routine within AcuServer, rather than within itself. Because AcuServer contains the same file routines as the runtime, the client runtime need not pass individual I/O requests across the network to issue each of the many disk actions required to perform a particular I/O command. Instead, one high-level call can be made. AcuServer has all the same file logic as a runtime, can issue all the necessary I/O commands on the server, and need only reply across the network when the high-level request is completed. The result is a much more efficient use of the network resources.
Back to top
In my Windows NT or Novell 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, or 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.

Back to top
Which releases of AcuServer are currently supported by Acucorp?
Acucorp Technical Support continues to offer telephone and fax 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 4.0.0 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 upgrading your site to the latest version that contains the fix.
Back to top
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:
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.

Back to top
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.

Back to top
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?
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 > somefilename 2>&1
Then use any editor to view "somefilename."
Back to top
In a Windows environment, I'm receiving client runtime errors in the format "9D,200xx". I cannot locate these error messages in the AcuServer User's Guide. What do they mean?
On Windows systems, the number 20,000 is automatically added to the extended error codes. Subtract 20,000 from the extended error code to find the documented value. In other words, "9D,20005" is equivalent to "9D,05". Errors in this format (9D,xx) are the two-digit RPC error codes that are documented in the second portion of Section 10.2 of the AcuServer User's Guide.
Back to top
RPC error codes seem fairly terse. What do they mean?
RPC error codes most often represent network failures. Some of the more common RPC codes (and their causes) are:
- RPC_CANTRECV=4
  - AcuServer is terminated abnormally.
  - The server goes down.
  - The network goes down.
- RPC_TIMEDOUT=5
  - The client runtime has made an acceptable RPC call and is waiting for a return from AcuServer. The time tolerance for the client runtime is defined in the client configuration variable DEFAULT-TIMEOUT (the default setting is 25 seconds). If no answer is received from AcuServer in DEFAULT-TIMEOUT seconds, the client runtime generates this error message.
- RPC_PROGUNAVAIL=8
  - AcuServer is not running.
- RPC_SYSTEMERROR=12
  - AcuServer is not running but is still registered with portmap.
- RPC_UNKNOWNHOST=13
  - The host name in etc/hosts file is poorly formed.
  - Or, the Domain Name Server is busy.
- RPC_PMAPFAILURE=14
  - Portmap is not running on the server.
  - There is a duplicate IP address in the etc/hosts file.
- RPC_PROGNOTREGISTERED=15
  - This can occur if AcuServer is not running or if the client file "host" doesn't have a correct entry for the server. In this latter case, you can try changing the client remote name from a server name to an IP address, as shown in this example:
    
    change this to this
    
    @server:/path/file @192.215.170.107:/path/file
- RPC_TLIERROR=20
  - AcuServer was stopped but is still registered with portmap. You can delete the registration on a UNIX server by typing:
  - rpcinfo -d 300301 1
Back to top
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:
- FILE-PREFIX @servername:/path
- CODE-PREFIX @servername:/path
On Windows NT:
- FILE-PREFIX @servername:C:\path (where C is a drive letter)
- CODE-PREFIX @servername:C:\path
Back to top
On Windows NT, the only portmap utility that can be successfully used is the one that is distributed by Acucorp. How can I tell which portmap is running?
At a command prompt, type:
- sc qc portmap
The result will show, among other things, the complete path of the portmap that is running. Portmap's location in your directory structure may help you to determine its origin. Additionally, you can use a "dir" command to check the size of the executable file that was shown in the "qc". The portmap from Acucorp has consistently remained at 20,820 bytes since the release of AcuServer Version 1.2.1.

Back to top
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 Acucorp Technical Support. 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. Please 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.

Back to top
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 would allow 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 section 10.3.4 of the AcuServer User's Guide for a complete description of where those variables come from on various client systems. Section 8.4 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, and (if that's not found) will then look for a wildcard that might allow access to the client. Let's look at a specific example that 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:

Socket:0, client:jmadsen-ntw, pid:282, PASSWORD-ATTEMPTS allowed:3

key 0 = 'jmadsen-ntw jmadsen '

key 0 = 'jmadsen-ntw '

key 0 = '* jmadsen '

key 0 = '* '

Mapping user: jmadsen to local user:guest
acuserve: LookupAccountName for guest

In the above example, "jmadsen-ntw" is the variable from the client that is matched to "Client-Machine-Name," and "jmadsen" 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. As outlined in section 8.4 of the AcuServer User's Guide, AcuServer attempts to find an AcuAccess record that has "jmadsen=ntw" as Client-Machine-Name AND "jmadsen" as Client-Username. There is no such record in the file.

Next, AcuServer attempts to find a record that has "jmadsen-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 "jmadsen" 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, suppose we received an "access denied" error (File error 37,07 on @servername:/path/sub/file). We know that the Client-Machine-Name and Client-Username are 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.

Back to top
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
- 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 Acucorp 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.

Back to top
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, please 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 SERVER-NUMBER and (b) setting the client runtime configuration variable of the same name to that value. For example:

On the server:
- acuserve -start -c serverone.cfg
- acuserve -start -c servertwo.cfg
In serverone.cfg
In servertwo.cfg
In the runtime configuration file of client A:
In the runtime configuration of client B:
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 SERVER-NUMBER 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:
In the runtime configuration file of client B:
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 SERVER-NUMBER 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, SERVER-NUMBER would need to be set to point to the appropriate instance of AcuServer on that server. For example:
- On server one:
  - acuserve -start -c serverone.cfg
  - acuserve -start -c servertwo.cfg
  - In serverone.cfg
  - SERVER-NUMBER 1
  - In servertwo.cfg
  - SERVER-NUMBER 2
- On server two:
  - In serverone.cfg
  - SERVER-NUMBER 1
  - In servertwo.cfg
  - SERVER-NUMBER 2
- In the runtime configuration file of client A:
  - filea @server1:/path/sub/filea
  - fileb @server1:/path/sub/fileb
  - SERVER-NUMBER 1
- In the runtime configuration file of client B:
  - filea @server1:/path/sub/filea
  - fileb @server1:/path/sub/fileb
  - SERVER-NUMBER 2
- In the runtime configuration file of client C:
  - filea @server2:/path/sub/filea
  - fileb @server2:/path/sub/fileb
  - SERVER-NUMBER 1
- In the runtime configuration file of client D:
  - filea @server2:/path/sub/filea
  - fileb @server2:/path/sub/fileb
  - SERVER-NUMBER 2
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. Please 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

@server1:/path1d/sub1d

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
- filed @server1:/path1c/sub1d/filed
And notice:

FILE-PREFIX @server1:/path/sub

@server2:/path/sub

@server3:/path/sub

@server4:/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
- filed @server4:/path/sub/filed
6) The AcuServer server configuration file can use the following variables:
- 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 the documentation (Appendix H in the ACUCOBOL-GT^® documentation) for particulars.

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:
a) SORT_DIR
This client configuration variable allows the client runtime to place temporary sort files in the directory specified. There is no advantage to placing those temporary sort files on the server. On the contrary, there is a considerable disadvantage to burdening the network with traffic that is of no use to any other client system except the one executing the SORT verb. Consider setting SORT_DIR to a local drive. (For users of MS-DOS and VAX/VMS systems, please see the corresponding variable, TEMP_DIR.)

b) 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.

c) 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.

Back to top

If you have additional questions about AcuServer, please contact Acucorp Technical Support or your local Acucorp representative for assistance.

####

	Company History
	Press
	Newsletter
	White Papers
	Customer Successes

	Inter- operability
	Web Access
	Faster Processing
	Data Access
	Windows Look and Feel
	Short Time To Market
	Platform Conversions
	Product Datasheets

	Registered Users
	Technical Tips
	How Do I?
	Sample Programs
	Contact Support
	Port Lists
	Installation Help
	Release Overview
	Downloads

	Partner Programs
	Strategic Alliance Program
	ISV Program
	Become a Partner
	Meet Our Partners