Acucorp Release Overview
Product Suite Version 5.2
extend5 with Thin Client Technology
AcucorpTM is pleased to release Version 5.2 of our extendTM5 family of technologies. In addition to the many enhancements made to the established members of the extend family, Version 5.2 introduces two important new products.
Version 5.2 also contains several important enhancements to the nerve center of the extend family, ACUCOBOLTM-GT:
An overview of these and other enhancements is provided in this Release Overview.
With Version 5.2, Acucorp introduces an innovative new networking technology called thin client, which lets you display the user interface portion of your server-based application on a graphical display host. The extend Thin Client technology allows ACUCOBOL-GT programs running on a UNIX (including Linux) or Windows NT/2000 server to present a full Windows graphical user interface (GUI) on Windows PCs networked with TCP/IP. To enjoy the maximum benefit of this technology, application screens should be converted to graphical; however character-based applications can be displayed as well, if desired.
Both UNIX and Windows users enjoy the benefits of centralized application maintenance and the performance characteristics of a thin client architecture. Many applications perform better when deployed in a thin fashion compared to other networking techniques, because COBOL programs execute on the server where data access is local.
Thin Client technology consists of three essential components. First, a small program on the Windows client communicates with the application running on the server and handles the display of the user interface. This thin piece is called the ACUCOBOL-GT Thin Client. Second, there is a listener service running on the UNIX/Linux or Windows NT/2000 server called AcuLaunchTM. AcuLaunch's job is to listen for requests from thin clients and to launch the third component, a standard ACUCOBOL-GT runtime. Once the application has started, the ACUCOBOL-GT runtime communicates directly with the thin client, and AcuLaunch returns to its role of listening for thin client requests. AcuLaunch is a separately licensed product which allows a specific number of thin client connections.
The benefits of Acucorp's Thin Client technology are plentiful. UNIX and Linux users retain the stability and security of their familiar environment and take advantage of the graphical capabilities of Microsoft Windows desktops. Because Acucorp Thin Client technology is designed for TCP/IP-based networks, thin client applications can be deployed on the Internet and TCP/IP-based WANs and LANs. In addition, thin client applications can utilize ActiveX controls on the Windows display host. Users also have the ability to print locally--on their Windows machine--or on the remote server.
When considering a thin client solution, users need to carefully examine their individual situations and goals. In this introductory release, the Thin Client technology is especially well-suited to some particular types of applications. If an ACUCOBOL-GT application is already graphical, some work may be necessary to use the thin client. If the goal is to maintain an ACUCOBOL-GT program on a UNIX application host and develop a Windows graphical user interface, then Acucorp's Thin Client technology is a good match. You can create the desired user interface by combining the Thin Client technology with our Character-to-GUI Wizard and the AcuBenchTM Screen Designer to convert and edit character screens and add new graphical screens.
Some configurations and situations may require that programs be reworked significantly to use the Thin Client technology. For example, running a character-based application in thin client has some limitations. Some display elements may not appear as expected or may not be supported at all. (Refer to section 2.1 in A Guide to Using Acucorp's Thin Client Technology for specific limitations.) Highly interactive programs that generate high volumes of communication between the client and server may not work well with thin client. Windows applications that contain direct calls to the Windows API have to be modified to remove these calls. If you move an application from one operating system to another (DOS to UNIX, for example), the file naming conventions and directory structures embedded in the program have to be changed. Future enhancements to the Thin Client technology may ease many of these restrictions. An Acucorp Systems Engineer can help you evaluate the suitability of your application for use with thin client.
Acucorp's Thin Client technology supports UNIX/Linux or Windows NT/2000 servers and 32-bit Windows clients. For more information about how our Thin Client technology works, refer to A Guide to Using Acucorp's Thin Client Technology in your Acucorp on-line documentation set.
NOTE: If you plan to use AcuLaunch on an HP e3000 MPE/iX system, please read the section titled, "Special Note to Those Planning to Use AcuLaunch, AcuServerTM, or AcuConnectTM on HP MPE/iX Systems," located near the end of this paper.
In Version 5.2, Acucorp is pleased to introduce AcuODBC Server. With AcuODBC Server, you can now both store files and perform SQL processing on a data host. AcuODBC Server is an add-on to AcuODBC and is licensed separately.
AcuODBC Server provides you with an enhanced two-tier environment--one in which SQL processing can be performed remotely on an application server, with the results returned to the client machine. This architecture has several advantages:
This overview introduces you to AcuODBC Server; please refer to Chapters 8 and 9 of the AcuODBC User's Guide for complete information.
Before using AcuODBC Server, you must perform the following steps:
If you are using AcuODBC with AcuODBC Server or AcuServer on a Windows NT server, Version 5.2 makes it easy for you to use Windows NT's native security system in place of the Acucorp security system. To use Windows NT security, select "Logon" on the AcuODBC Server or AcuServer tab of the AcuODBC Configuration property sheet. With this option enabled, when an AcuODBC user uses AcuODBC Server or AcuServer, the service attempts to log the user directly onto the Windows NT domain. If the login succeeds, the connection runs as if the user were logged directly onto the Windows NT system, and all of the Windows NT security provisions established for that user apply. See Chapters 3 and 9 of the AcuODBC User's Guide for additional information.
A new setting on the Advanced tab of AcuODBC Configuration property sheet allows you to indicate how AcuODBC should treat non-numeric data in a numeric field. The choices are:
For additional information, see Chapter 3 in the AcuODBC User's Guide.
A new setting on the Advanced tab of the AcuODBC Configuration property sheet enables you to indicate whether AcuODBC should retain or remove trailing spaces in character data. The choices are:
ACUCOBOL-GT Version 5.2 introduces several new capabilities, including support for Acucorp's Thin Client technology, expanded support for printing under Windows, support for defining multiple entry points in a program, and many other enhancements.
Native Code Generation for 64-bit SPARC Processors
A new native code option, "--sparc_v9", causes the compiler to produce 64-bit native code for the SPARC Version 9 processor. Using SPARC native code can improve the performance of computationally intensive programs. You can use the "--sparc_v9" option from any host machine. You can also use it with cblutil. This is the same as specifying "-n" with a 64-bit compiler on a SPARC v9-based host machine. This switch is documented in Book 1, User's Guide, sections 2.1.1.1 (compiler) and 3.2.4 (cblutil).
Remote File Handling
ACUCOBOL-GT Version 5.2 includes new remote file handling capabilities. If AcuServer or AcuLaunch is running on a remote machine, you can use new remote file path syntax with the "-o" option to direct the compiler to create the resulting object file directly on the remote system. With the same syntax, you can direct cblutil to read remote objects and create a remote library. The syntax rules for specifying remote paths with the compiler and cblutil are described in detail, including examples, in Book 1, User's Guide, sections 2.1.13.1 and 3.2.2.1, respectively.
Multiple Entry Points
ACUCOBOL-GT Version 5.2 introduces the ability to define multiple entry points in a program. Such entry points can be called from other programs, just as subroutines are called. A new ENTRY statement is used to define each alternate entry point in the program. Such alternate points can occur many times in a single program. To activate a program at an ENTRY point, the calling program uses a standard CALL statement.
This feature is documented in Book 3, Reference Manual, section 6.6, "Procedure Division Statements," CALL and ENTRY statements.
UNIX Shared Objects
ACUCOBOL-GT Version 5.2 allows you to use the CALL statement to call subroutines in UNIX (including Linux) shared libraries. Placing native code routines in shared libraries and calling them from your COBOL program is a convenient way to access native code routines without having to link them into the runtime. To use a routine located in a shared library, you must first load, or CALL, that library. Once the library has been loaded, all of the routines it contains can be called.
NOTE: While most UNIX systems use a binary format that supports the calling of subroutines in UNIX shared libraries as described in the preceding paragraph, SCO UNIX (and possibly other UNIX systems) use different binary formats, namely COFF and ELF. Under SCO UNIX, the ACUCOBOL-GT Version 5.2 runtime runs in the ELF binary format. Prior to Version 5.2, the ACUCOBOL-GT runtime for SCO UNIX ran in the COFF format (but COFF does not support calling shared libraries). If you deploy on SCO UNIX systems and you have C routines that you link into the ACUCOBOL-GT runtime, you will need to recompile those C routines to create ELF objects to link into the Version 5.2 runtime.
This feature is documented in Book 4, Appendices, Appendix M, section M.3.1. The CALL statement syntax and rules are documented in Book 3, Reference Manual, section 6.6, "Procedure Division Statements."
Expanded Print Job Control Under Microsoft Windows
To give you more control over the layout of reports printed in Windows, Version 5.2 contains extensions to the WIN$PRINTER library routine (outlined under "Library Routines" below) and an enhancement to the Windows print spooler interaction. You may now specify a particular printer when using the Windows print spooler. Similar to "-P SPOOLER", the new "-Q <printername>" option is set in the configuration file ("CBLCONFI"). When the runtime opens a file assigned to "-Q <printername>" it sets the Windows print spooler to use the indicated printer. This feature is described in section 1.2.5 of the Getting Started book.
Mouse Wheel Support
ACUCOBOL-GT Version 5.2 supports the use of a mouse wheel with the scroll bar control in all versions of Windows that support a mouse wheel. Support for the mouse wheel applies only to vertical scroll bars. The Windows operating system supports mouse wheel rotation through the WM_MOUSEWHEEL message. The runtime intercepts the WM_MOUSEWHEEL events and translates them into WM_VSCROLL messages, which are then handled as conventional mouse button clicks on a scroll bar. By default, a single WM_MOUSEWHEEL event is translated into three WM_VSCROLL messages. The application user can configure this number through the Mouse Properties applet in the Windows Control Panel. This feature is documented in Book 2, User Interface Programming, Chapter 5, section 5.12, "Scroll Bar."
HP e3000 COBOL II Compatibility
Acucorp is preparing the ACUCOBOL-GT development system to include broad support for compatibility with HP e3000 COBOL II. We continue to refine this support and plan to make it available some time after the general release of Version 5.2. Most aspects of HP COBOL II compatibility are documented in the ACUCOBOL-GT Version 5.2 manual set. To learn more about HP COBOL II compatibility, see Book 4, Appendices, Appendix Q. To get the most up-to-date status regarding availability, please contact your Acucorp Sales Professional.
New WRITE Statement Option
Format 3 of the WRITE statement has a new option, NO CONVERSION. Format 3 writes data to the specified file without any additional carriage-control information. If the NO CONVERSION option is specified, trailing spaces are not removed from the record, even if they otherwise would be.
Controls
To eliminate unnecessary screen repainting, ACUCOBOL-GT attempts to eliminate some requests to resize screen controls. In Version 5.2, the method used to perform this optimization has changed. Please see the entry for OPTIMIZE_CONTROL_RESIZE in the "Configuration Variables" section below.
ActiveX
In Version 5.2, the AXDEFGEN utility comes with an improved facility for locating the names of ActiveX controls and OLE objects registered on the system. The AXDEFGEN dialog box now displays two tabs: "Components" and "Libraries." The Components tab lists all ActiveX controls and other OLE objects that have registered type libraries. The Libraries tab contains a list of libraries derived from the HKEY_CLASSES_ROOT\TypeLib registry key. AXDEFGEN is described in Book 1, User's Guide, section 3.7.
Grid
The grid control is enhanced in several ways in Version 5.2, including a new special property and a new value for the ACTION special property.
The DRAG-COLOR special property is used to set the highlight color that's applied to the rectangular area defined when the user clicks in the grid and drags the mouse. You should use DRAG-COLOR instead of REGION-COLOR in applications that will be deployed with Acucorp's Thin Client technology. The existing REGION-COLOR property is not supported by the Thin Client technology.
The new ACTION setting ACTION-HIDE-DRAG can be used to suppress the displayed DRAG-COLOR.
These special properties are described in Book 2, User Interface Programming, Chapter 5, section 5.15, "Grid."
Another new feature of the grid control is a change in the behavior of the MSG-GOTO-CELL-MOUSE event. In versions prior to 5.2, the runtime would not pass a MSG-GOTO-CELL-MOUSE event to the program when the user clicked on the cell containing the grid cursor. This was done to prevent extraneous messages from being sent to the program. However, this message can be useful in some cases, such as when you want to allow a user to deselect something that is already selected. Therefore, in Version 5.2 the runtime no longer filters out MSG-GOTO-CELL-MOUSE messages just because the destination cell is the same as the current cell. This feature is documented in Book 2, User Interface Programming, Chapter 6, section 6.3, "Control Events."
For programs that rely on the old behavior, this change can be inhibited via the new configuration option V52_GRID_GOTO. See Book 4, Appendices, Appendix H.
Library Routines
Some new library routines and enhancements to existing routines highlight this version of ACUCOBOL-GT. Runtime library routines are described in detail in Book 4, Appendices, Appendix I.
C$GETLASTFILEOP: The new C$GETLASTFILEOP routine retrieves information about the last file operation performed. This routine is called from Declaratives when an unexpected I/O error has occurred. The return values can be useful in some debugging or customer support situations.
C$LIST-DIRECTORY: The new C$LIST-DIRECTORY routine allows you to build a list of files contained in a particular directory. The routine uses a sequence of three operations to open a specified directory, return the names of some or all of the files contained therein, and close the directory.
W$FLUSH: The new W$FLUSH routine can be used to refresh the screen or cursor display even if an ACCEPT has not been performed. This is useful in situations where you DISPLAY a control or some text and then continue processing before the screen is ACCEPTed. The updated screen may not otherwise be visible to the user based on the normal behavior of the runtime.
WIN$PRINTER: This routine has been expanded to give you much more control over the format of reports. New WIN$PRINTER operation codes include:
These changes are described in Book 4, Appendices, Appendix I, "Library Routines."
Configuration Variables
Several new configuration variables are described below. You can find detailed descriptions of ACUCOBOL-GT configuration variables in Book 4, Appendices, Appendix H.
IMPORT_USES_CELL_SIZE: This configuration variable gives you more control over how fields are sized when a screen is imported with the Graphical Screen Import Utility. IMPORT_USES_CELL_SIZE allows you to choose whether fields are measured using the actual cell size of the imported screen or measured in 10-pixel by 10-pixel cells. See the AcuBench documentation for more information on importing screens.
OPTIMIZE_CONTROL_RESIZE: Prior to Version 5.2, the runtime eliminated requests to resize a control on the screen if the new size and position matched the control's current size and position. Beginning with Version 5.2, the runtime eliminates the control resize request if the SIZE and LINES indicated (or implied) by the program match the control's current size and position. This change was made to provide more predictable behavior and to improve efficiency when the display service is on a remote machine. Refer to Appendix F for details about how this may affect existing programs.
SCREEN_COL_PLUS_BASE: This configuration variable allows you to configure the COLUMN PLUS phrase in the Screen Section. In prior versions, the phrase "COLUMN PLUS 1" placed the next screen item immediately after the last screen item. However, if you compiled for ICOBOL compatibility, "COLUMN PLUS 1" would place a space between the end of the last item and the start of the next. SCREEN_COL_PLUS_BASE allows you to choose the behavior that works best for your program.
V52_GRID_GOTO: In Version 5.2 and later, the runtime no longer filters out MSG-GOTO-CELL-MOUSE messages when the destination cell is the same as the current cell. You can use the V52_GRID_GOTO configuration variable to enable the pre-5.2 behavior. See the section on the grid control, above, for more information. Refer to Appendix F, "Changes Affecting Version 5.1," for details about how this may affect existing programs.
Compiler Options
The following compiler options are new:
"-Td ####" Identifier and statement table - sets the maximum number of items in each statement. The default value is 4096.
"-Te ###" Subscript statement table - sets the maximum size for OCCURS statements. The default value is 256.
These options are documented in Book 1, User's Guide, section 2.1.1.2.
VUTIL
The file utility vutil has two new command line options in Version 5.2.
The "-x" switch, used with the "-check" option, causes vutil to run more extensive tests than those run by the "-a" or "-f" options. The extended tests include: reading every record with every key, reading the records in their physical order in the file, and checking the deleted records list. You must specify the "-x" option with either "-a" or "-f" on the same command line; used by itself, "-x" does nothing. The "-x" option disables the "-k" option when the two are specified on the same command line. Note that "-x" causes a write lock to be placed on the file to ensure exclusive access during the tests. The "-x" switch is described in Book 1, User's Guide, section 3.3.2.
The other new vutil option is "-fixvers". This option resets the internal revision number of all segments in the specified Vision file to the revision number of the first data segment. It does this without rebuilding the entire file. To use this option, you must have exclusive access to the file. The command is:
vutil -fixvers [ -q ] [ file ]
The files can be listed on the command line, or can be read from the standard input. For convenience in building scripts, non-Vision files are ignored. The "-fixvers" switch is described in Book 1, User's Guide, section 3.3.5.
A special note to Web Plug-in Users: Microsoft dropped support for Netscape-style plug-ins beginning with Internet Explorer version 5.5, Service Pack 2, and in all version 6.x releases. The ACUCOBOL-GT Web Plug-in is a Netscape-style plug-in and will not run in the versions of Internet Explorer cited above. In support of our customers, we have begun developing an ActiveX version of the Web Plug-in that will be compatible with the latest versions of Internet Explorer. We expect the ActiveX version of the Web Plug-in to be ready in a few months.
Acu4GL supports three new configuration variables in Version 5.2.
A_MSSQL_NT_AUTHENTICATION
The A_MSSQL_NT_AUTHENTICATION configuration variable indicates whether MS SQL Server will authenticate users based on their Windows login. (This variable is valid only with Acu4GL for MSSQL.)
If this variable is set to "on" (true, yes), the Acu4GL for MSSQL product attempts to log users on using the SQL Server Windows NT authentication mode. (See your SQL Server documentation for information about this authentication mode.) When A_MSSQL_NT_AUTHENTICATION is enabled, the A_MSSQL_LOGIN and A_MSSQL_PASSWD configuration variables are no longer needed or used. (They are still available if you are not using Windows NT authentication mode.) If you have not set up SQL Server itself to allow this type of authentication, setting this variable to "true" causes all login attempts to fail. See your SQL Server documentation for information on how to set up this type of authentication.
The default is "off" (false, no), indicating that Acu4GL for MSSQL will not use Windows NT authentication mode when logging users on, and will continue to use login/password authentication.
A_MSSQL_TRANSLATE_TO_ANSI and A_SYB_TRANSLATE_TO_ANSI
Setting this variable to "on" (true, yes) causes the Acu4GL for MSSQL or Acu4GL for Sybase product to call the same translation function used by the Windows runtime to translate characters going to the server into the OEM character set, and to translate characters coming from the server to ANSI.
The default is "off" (false, no), which indicates that Acu4GL does not call the translation function, but passes the data as is to the library.
This variable applies only to Windows versions of Acu4GL for MSSQL and Acu4GL for Sybase.
A_ORA_DEFER_CLOSE
Valid with Acu4GL for Oracle, this variable determines whether the closing of cursors is deferred or not. Deferring the closing of cursors can result in faster performance when a cursor is re-used, such as on a READ NEXT. Note, however, that this can result in the use of additional Oracle resources, such as memory.
The default value for A_ORA_DEFER_CLOSE is "1" (on, true, yes). If A_ORA_DEFER_CLOSE is set to "0" (off, false, no), cursors are closed as they were in versions of Acu4GL for Oracle earlier than Version 5.2.
Note that this variable can be set only as a configuration variable or an environment variable. It cannot be set programmatically.
Version 5.2 of AcuConnect includes several minor corrections. Please see the ECN list for details.
NOTE: If you plan to use AcuConnect on an HP e3000 MPE/iX system, please read the section titled, "Special Note to Those Planning to Use AcuLaunch, AcuServer, or AcuConnect on HP MPE/iX Systems," located near the end of this paper.
Version 5.2 of AcuSQL includes several minor corrections. Please see the ECN list for details.
Expanded Windows NT Security Option
Version 5.2 introduces a simple way for UNIX and Windows clients to use Windows NT native security in place of AcuServer's built-in security, when AcuServer is running on a Windows NT or Windows 2000 host. The NT_SECURITY configuration variable accepts a new value ("LOGON") that, when set, causes AcuServer to attempt to log the user directly onto the Windows NT domain. If the login succeeds, the AcuServer connection runs as if the user were logged directly onto the Windows NT system. Windows NT security provisions established for that user apply. Note that using Windows NT security may improve AcuServer performance. For more information, see section 3.5, "Windows Security vs. AcuServer System Security," and the entry for NT_SECURITY in section 4.2.2 of the AcuServer User's Guide.
Password Messages
The text of three messages used by AcuServer to prompt for and respond to user passwords can now be defined in the server configuration file (on the AcuServer host) and transparently downloaded to clients for use. This capability makes it easier for AcuServer system administrators to redefine password messages and ensure uniformity. It also simplifies AcuServer system maintenance.
Prior to Version 5.2, if you wanted to redefine any of the three text messages related to password acquisition and response you had to define the new text in the runtime configuration file on each client machine. Beginning with Version 5.2, the messages can be defined in the server configuration file and, when the new configuration variable PROVIDE_PASSWORD_MESSAGES is set to "on," the redefined messages are automatically sent to the client upon initial connection. See the entry for the configuration variables TEXT and PROVIDE_PASSWORD_MESSAGES in section 4.2.2 of the AcuServer User's Guide.
Encryption Option
AcuServer now offers support for data encryption. At your option, you can direct AcuServer to encrypt all data exchanged between AcuServer and a given client connection. Encryption is enabled with two configuration variables: ENCRYPTION_SEED and AS_CLIENT_ENCRYPT. Once encryption is turned on, it remains on until the program terminates and the connection with AcuServer is closed.
NOTE: The use of encryption can have a significant performance cost. That cost is determined by the quantity of data being exchanged, the speed and bandwidth of the network, and the computational power of both the client and AcuServer host machines. If you plan to use encryption, you should test and benchmark your application with encryption enabled prior to deployment to ensure that your performance requirements are met.
Service Dependencies Under Windows NT and Windows 2000
Beginning with Version 5.2, under Windows NT and Windows 2000, on the "acuserve -install" command line you can specify services on which acuserve depends. Such dependent services must be installed and running before acuserve is allowed to start. This allows you to ensure that other essential services are running on the system before AcuServer is allowed to start. For a description of the "acuserve -install" syntax, see section 5.2.4 in the AcuServer User's Guide.
NOTE: If you plan to use AcuServer on an HP e3000 MPE/iX system, please read the section titled, "Special Note to Those Planning to Use AcuLaunch, AcuServer, or AcuConnect on HP MPE/iX Systems," located near the end of this paper.
AcuBench Version 5.2 features support for Acucorp's Thin Client technology, which lets you display your server-based application on graphical display hosts. (For more information about Acucorp's Thin Client technology, refer to the "Acucorp's Thin Client Technology" section near the beginning of this overview and A Guide to Using Acucorp's Thin Client Technology in your on-line documentation set.)
Support for Acucorp's Thin Client technology in the workbench means greater flexibility in your development environment. Imagine this scenario: Your source code is stored on your UNIX or Windows server and protected by a version control system. You check needed files out to your Windows client machine, which is running AcuBench, and edit the source as desired in the workbench. Source is compiled in the workbench, and the resultant object code is automatically placed on the remote server. From within the workbench you use the new remote debugging capabilities to test your application, which is displayed on the Windows client while it is running on the remote machine. Finally, you check your edited source back in to the server when your work is complete.
A drop-down menu option signals the workbench that you want to use thin client functions. The commands you now use to develop your project locally (including Compile, Build, Execute, and Debug) are also used to develop your project for a thin client environment. A new Create Alias command allows you to create program aliases for your thin client applications. You can set options to create and access remote objects in your project and to use remote debugging, all in the familiar, easy-to-use integrated workbench interface.
Support for Acucorp's Thin Client technology is not the only workbench enhancement. Other Version 5.2 features improve your AcuBench development environment:
We have simplified the license file creation and installation procedure for Windows platforms.
The Version 5.2 installation procedures are described in the Quick Start cards and in the Getting Started manual.
We are preparing to release a version of AcuLaunch, AcuServer, and AcuConnect for HP e3000 systems under POSIX. A limitation in the MPE/iX operating environment requires that users of these services carefully consider how they will deploy each service on MPE/iX systems. The following section explains the situation and provides two management approaches.
Background
Acucorp offers three client/server technologies for use on the HP MPE/iX platform.
These services share the same basic methods for starting the service, validating a service request, and fulfilling the request. Each service runs as an independent resident program. The service (running program) takes the user ID of the account that starts it. The service normally runs in the background, waiting for requests. When a service request is received, the service determines the user ID of the requester, checks an authorization file (AcuAccess) to determine if the requester is allowed to use the service, and determines the proxy user ID to be used for the requester (the requester user ID can be mapped to another ID; the mapped ID may be unique or may be shared by a number of users). If authorization is successful, the service temporarily assumes the proxy user ID to spawn a process or fulfill a request. On most UNIX systems, the SETUID system function is used to assume the correct user ID. A similar function is used in the Windows operating environment.
Special Considerations Under MPE/iX
In the MPE/iX environment, the operating system does not provide a way for a program (in this case one of the Acucorp services) to change its user ID. Therefore, the service always uses the ID of the account that started the service. Any action the service takes is performed with that ID. This inability to change IDs imposes some limitations and requires that MPE/iX sites carefully consider how they will configure and use these services.
Because the service takes the user ID of the account that starts it, and because it uses that ID to access files and fulfill requests, it's very important that that account be able to service all anticipated requesters. There are two approaches to managing this issue. The approaches can be combined.
One approach is to start the service from an account that is accessible to all requesters (a "group" account). Of course, such an account must have all of the necessary access permissions to satisfy every requester. The limitation of this approach is that all requesters have the same proxy user ID on the server, and there is no way to identify a unique requester (with the possible exception that an application launched by AcuConnect could implement its own interactive logging facility).
The second approach is to start a separate instance of the service for each unique requester or group of requesters (multiple group accounts). This approach will work so long as the number of separate instances does not overtax system resources (process space, processor capacity, and dynamic memory). The number of instances that each system can handle will vary depending on the resources of each machine. Note that when the service is not executing a request, the service waits on a socket in an efficient loop, consuming few resources. Some experimentation may be necessary to determine the limits of a given machine.
If we can help you in any way, please contact Acucorp Technical Support. We can be reached at the following numbers:
Acucorp Technical Support in the United States:
Phone: +1 (858) 689-4500
1-800-262-6585 (within the U.S.)
Fax: +1 (858) 689-4552
E-mail: support@acucorp.com
Customers outside of the United Stated, please contact your regional Technical Support office or your local distributor:
In Benelux:
Phone: +31 (0)73 623 01 95
Fax: +31 (0)73 623 01 99
E-mail: nlsupport@acucorp.com
In France:
Phone: +33 (0)1 53 34 9005
Fax: +33 (0)1 53 34 9001
E-mail: frsupport@acucorp.com
In Germany:
Phone: +49 (0)61 75 9331 33
Fax: +49 (0)61 75 1429
E-mail: desupport@acucorp.com
In Scandinavia:
Phone: +46 (0)8 514 907 44
Fax: +46 (0)8 735 40 24
E-mail: sesupport@acucorp.com
In the United Kingdom:
Phone: +44 (0)20 8707 2010
Fax: +44 (0)20 8707 2055
E-mail: uksupport@acucorp.com
Acucorp, Acucobol, AcuServer, AcuConnect, Acu4GL, AcuSQL, AcuBench, AcuLaunch, and extend are trademarks of Acucorp, Inc. Acu4GL is protected by U.S. patent no. 5,640,550. AcuODBC is a registered trademark of Acucorp, Inc.
Other brand and product names are trademarks or registered trademarks of their holders.
(c) Copyright 2001 Acucorp, Inc. ALL RIGHTS RESERVED.