AcuConnect® 5.2.0 FAQ
October 31, 2002- What is AcuConnect?
- What's required to use AcuConnect?
- How is an application prepared for use with AcuConnect?
- What configuration files are used with AcuConnect?
- How can I debug a module running on the server?
- Can I test my client/server programs on a single computer?
- Are there any differences between UNIX and Windows configurations?
- Can modules running on a Windows server access files on mapped drives?
- What if I receive the message "A required privilege is not held by the client"?
- Can Server modules operate based on password-protected logons without requiring the user to know the password?
- Can my client or server programs read data located on yet another computer?
- Can my client or server programs read databases?
- What is AcuConnect?
AcuConnect is the part of Acucorp's client/server technology that allows portions of the application logic to run on different computers. For instance, a user may be logged on to a client machine and start a program there. Then the program may call a subroutine, which executes on the server. AcuConnect makes this possible.
- What's required to use AcuConnect?
To use AcuConnect, you must have a TCP/IP network in place. In addition to the network software, you'll need:- An AcuConnect-enabled runtime for each client machine (all ACUCOBOL-GT® runtimes, Version 3.2.2 and higher are AcuConnect-enabled.)
- AcuConnect for each server machine
- A valid runtime license file for each server machine.
- How is an application prepared for use with AcuConnect?
If your application is already broken out into called routines, it may not need modification. If not, the parts of the application that are to be run on the server must be broken out into separate called subroutines. Once this is done, locate the object files in the preferred directories on the server where they will run.
- What configuration files are used with AcuConnect?
A client/server application with AcuConnect will require up to three configuration files:
- Client runtime configuration file to control the client portion of the application
- Server runtime configuration file to control the server portion of the application
- AcuConnect "server.cfg" to control the behavior of AcuConnect on the server
Here are some more specifics about each file:
- Client runtime configuration file:
This file is specified in the run command for the client main program, for example:
wrun32 -c runconfig.cli main.acu
This file contains standard ACUCOBOL-GT runtime configuration variables, some are specifically designed for use with AcuConnect. For instance, note that this file will contain a pointer to its server counterpart:
ACUCONNECT-CONFIGURATION-FILE *servername:/appdir/runconfig.srv
which will be explained below.
- Server Runtime configuration file:
A counterpart to the client runtime configuration file described above, this file contains standard ACUCOBOL-GT runtime configuration variables to control the behavior of the server part of the application. As mentioned above, it is specified in its counterpart, the client runtime configuration file. It will reside on the server in your chosen location.
- AcuConnect "server.cfg"
This file controls the behavior of AcuConnect itself, which runs on the server. It is specified in the startup command used to start the AcuConnect daemon or Windows NT/2000 service. For example:acuconnect -start -c server.cfg
Note that this file will contain a pointer to the AcuConnect security file (which is not one of the three configuration files):
ACCESS-FILE /etc/acuaccess
See the AcuConnect User's Guide for further information on these three configuration files and the AcuConnect security file.
- How can I debug a module running on the server?
A module running on the server must be debugged at the server after being called by the client. To cause the debugger to come up at the server, start the AcuConnect service with the "-d" flag (note that this causes AcuConnect to run in the foreground). Once AcuConnect is started this way, start the client program normally. Then when the application's client component calls the server module, the debugger will start at the server automatically.
- Can I test my client/server programs on a single computer?
Yes. In both Windows and UNIX, this can be done. In Windows, remember that AcuConnect runs only on NT or 2000 servers, and not on workstations.
- Are there any differences between UNIX and Windows configurations?
- On Windows NT/2000, any password supplied by the calling program or user must match both:
a) the password specified for that user in the AcuAccess file and
b)the password for the Windows user ID of the same name on that Server.
On UNIX, the password supplied by the calling program or user need only match the AcuAccess user password, and not necessarily the password for the matching UNIX logon.
- Remote file notations in UNIX and Windows are similar, but can be a source of confusion:
UNIX = *machine:/directory/file
WIN = *machine:c:\directory\file
The important item here is to remember to specify the drive letter on Windows systems. Be sure to check for this easily-fixed oversight if problems occur.
- On Windows NT/2000, any password supplied by the calling program or user must match both:
- Can modules running on a Windows server access files on mapped drives?
It's possible, but because mapped drives are available only while the user who mapped them is logged on, this approach can cause problems.
The preferred approach is to use UNC, or Universal Naming Convention paths. For example:
- \\servername\sharename\path\filename
- What if I receive the message "A required privilege is not held by the client"?
Be sure that AcuConnect was started by Administrator on NT/2000 servers or by root on UNIX systems.
- Can server modules operate based on password-protected logons without requiring the user to know the password?
Yes. To accomplish this, the COBOL program must have the password coded internally. To do so, define this variable in the COBOL program:
- 01 ACU-CLIENT-PASSWORD PIC X(??) IS EXTERNAL.
Be sure that:- the variable is named ACU-CLIENT-PASSWORD;
- the variable definition includes the IS EXTERNAL phrase;
- "??" in the example is replaced by a number which reserves enough space to hold the password; and
- during execution, the actual password is assigned to ACU-CLIENT-PASSWORD with a MOVE statement before the program begins any file I/O.
- Can my client or server programs read data located on yet another computer?
Yes. Use Acucorp's AcuServer™ product to enable client or server programs to read distributed data.
- Can my client or server programs read databases?
Yes. Use Acucorp's Acu4GL® and AcuSQL® products to enable client or server programs to read databases.
####
Acucorp, extend and ACUCOBOL are trademarks or registered trademarks of Acucorp, Inc. All rights reserved. All other trademarks are the property of their respective owners.
