Frequently Asked Questions

Question:

Can AcuConnect load object files on mapped server drives?

Answer:

AcuConnect starts a new instance of the ACUCOBOL-GT runtime for each client request for an application to be executed. This runtime can locate object files on a Windows server mapped drive only if the drive mapping has occurred at an administrator level at system startup.

To load object files on a Windows server mapped drive in this way, you must ensure that the SECURITY_METHOD configuration variable defines the type of Windows security to be used for the connection. See SECURITY_METHOD. for more information.

Question:

Is the Windows print spooler supported in the thin client?

Answer:

Generally speaking, all functionality of the Windows print spooler is supported except the following WIN$PRINTER functions:

These functions are not supported because of variations in memory allocated by data types on the client and the server (for example, a 64-bit UNIX server versus a 32-bit Windows client). Instead, you can make calls to WINPRINT_GET_PRINTER_INFO_EX and WINPRINT_SET_PRINTER, which are similar.

See Printing in Thin Client for information about these functions.

Question:

I am using ACCEPT user-id FROM SYSTEM-INFO to return details about the user that is running a specific copy of the application, but the returned user ID is "root". How can I ensure that the correct user information is returned?

Answer:

To return the actual user ID of the user who is executing the application on a UNIX server, AcuConnect must be started automatically at server startup or by a user that logs onto the server as root and then logs out of the system. When a subsequent client user starts an application that executes ACCEPT user-id FROM SYSTEM-INFO, the correct user ID is returned.

To return the correct user ID when a program is running on a Windows server, AcuConnect must be started as a Windows service and SECURITY_METHOD must be set to LOGON.

See Starting AcuConnect at System Startup for information about starting AcuConnect automatically at system startup or as a Windows service.

Question:

I have an application that contains branching code, which is used when the application is executed on either UNIX or Windows servers. The code relies on information that is returned about the operating system by ACCEPT FROM SYSTEM-INFO.

However, with the thin client, the information returned is from the server side of the configuration. How can I obtain information about the client side, so that the application is executed using the correct client-side information?

Answer:

ACCEPT FROM SYSTEM-INFO returns server-side information for the thin client environment. To obtain client-side information, you should modify your existing code to perform an ACCEPT FROM TERMINAL-INFO.

Question:

If a thin client application is launched from a Web browser, does that application have Web browser access? Should a hyperlink be included on the screen?

Answer:

The thin client does not run in a Web browser. However, you could use the Web browser control inside your application to allow Web browser access, or include your links on the same Web page that launches the application.

Question:

Are there any restrictions regarding the use of ActiveX or COM objects?

Answer:

You can use ActiveX controls. However, they must be installed on the client machine. Note that some controls may generate too many messages to be usable over the Internet. See Installing ActiveX Files for information about installing ActiveX controls.

COM and Distributed COM objects maybe used with Thin Client.