Release Overview

extend(TM)5 with ACUCOBOL(TM)-GT

Version 5.0

Acucorp is pleased to release Version 5.0 of our development suite. Please note that this release introduces the new name "extend(TM) 5 with ACUCOBOL(TM)-GT." The new name describes Acucorp's entire family of COBOL development and deployment solutions, designed to extend the life of your COBOL applications.

Version 5.0 provides significant enhancements in performance, user interfaces, interoperability with other tools, and product integration. The net result is increased productivity for COBOL developers and increased access from COBOL to other languages and other products.

Licensing

With the 5.0 release, the licensing procedure for Acucorp products has been improved. All products still require a license file, but you no longer need a separate license disk to install your products. Instead, each site receives a pair of alphanumeric strings (keys) for each product that is licensed. These strings contain information about the products, such as the version and serial numbers.

During installation you will be prompted to type in this "product code and product key" pair to activate your software. The product code and product key are easy to transmit to your site, and will make it easier to update or change your license specifications. If you purchase a new product, you simply open the new License Activator utility and update your license file by entering a new code and key. Details about the new licensing procedure are covered in your new Getting Started booklet. We hope this simplified licensing procedure benefits you, and we welcome your comments about it.

User Documentation

The ACUCOBOL-GT Runtime Manual is now available as an on-line help file. Both Windows help and HTML help are available for this book. The compiler's on-line search index and topic cross -references have both been expanded significantly to help you locate information quickly.

This paper describes the significant enhancements in Version 5.0. Additional details about any new feature can be found in the on-line help for each individual product.

 

ACUCOBOL-GT Compiler and Runtime

ACUCOBOL-GT is the heart of a comprehensive COBOL development system that has always been designed for portability, performance, and quality. Version 5.0 offers several key performance enhancements over its predecessors. Made at very basic design levels, these changes improve the system architecture and its code generating and file management capabilities.

Internal instruction set redesign

The main architectural change involves the new internal instruction set designed especially for 32-bit systems and well positioned to take advantage of 64-bit architectures in the future. As a result of this instruction set, the ACUCOBOL-GT Version 5.0 compiler (running on Windows 95 with a Pentium II processor) shows a noticeable gain in program execution speed over its 4.x predecessors, with the increase in program size in the 10% to 20% range.

The compiler accomplishes these gains while maintaining 100% compatibility with the prior versions of ACUCOBOL at both the source and object level. The Version 5.0 runtime executes programs compiled under earlier versions of the compiler. Older programs (which use the old instruction set) run the same with the new runtime as they always have, because the instruction decoder program that was built for use with the older programs is still intact inside the new runtime. Programs from the two instruction sets can CALL each other.

Native code

The new 32-bit instruction set enables us to offer another performance-improvement: the ability to generate "native" object code. Native code is CPU-specific code whose instructions can be executed directly by the host CPU.

The native code feature of ACUCOBOL-GT Version 5.0 offers a number of performance advantages in specific situations. It also offers you more choices in how you distribute, implement, and use your programs. The capacity to generate machine-independent object code remains unchanged, so you can choose which type of output you want to produce for each COBOL program. This new native code capability is discussed in more detail in a later section.

Faster rebuilding of Vision files

In addition to the redesigned system architecture, ACUCOBOL-GT Version 5.0 offers significantly improved performance for file rebuilds. As always, ACUCOBOL-GT comes with its own file-handling utility for Vision files, called vutil, which provides several important and useful functions in one package. Activated by command line options, those functions can be used to examine file structure and integrity, extract records from files, add records to a file, or rebuild corrupt files.

Vutil rebuilds a corrupt file essentially by writing a new file after reading the records of the old file and rebuilding the keys. Traditionally, vutil has rebuilt one record at a time, by first adding the record and then writing its keys. This cycle was repeated for each new record written during the rebuild.

The new technique involves adding all the records at one time ("bulk" addition), and then writing all the keys, also as a single operation. There are several advantages to this method. Disk space is allocated more economically, and indexes and records are positioned in such a way that data retrieval is faster. But the biggest difference is in the speed of the writing operations. Because of the faster writes, rebuild times can be improved dramatically, particularly for files with more than 250,000 records. You can read more about this enhancement in Book 1, section 6.1.10, in the ACUCOBOL-GT manual set.

Asynchronous reads

Asynchronous reads is a new, optional mode for reading Vision files. This new mode can significantly improve file I/O throughput by reducing the file lock time required during multi-user operations and by eliminating the need for file lock checks by readers.

COBOL developers often write programs that result in a single file being read and updated by almost all users. This can lead to "file busy" messages on the users' terminals when several users are attempting to read or update a file simultaneously.

The major focus of the new feature is to eliminate the need for readers to check file locks. This can result in a large performance improvement for systems that are being "choked" by the lock problem. Our development tests indicate about 20% faster reads, and the improvement grows with an increase in the file size and the number of simultaneous readers.

The feature will have maximum benefit to those who use mapped disk drives on Windows networks. Users of AcuServer will see less dramatic performance gains. The feature will also indirectly eliminate some problems seen with servers that lack effective lock managers, because significantly less lock activity should be occurring. See the variable V-LOCK-METHOD in Book 4, Appendix H of the ACUCOBOL-GT manual set for more information.

Native Code

Prior to Version 5.0, the ACUCOBOL-GT compiler always produced machine-independent object code. The advantage of producing machine-independent object code is that these objects can run on any machine that has an ACUCOBOL-GT runtime. The disadvantage is that the object code is a less efficient user of the processor than the processor's native instruction set. Starting with Version 5.0, compiler users can choose to produce native code as an alternative to machine-independent object code. (See the Overview in Book 1, section 1.1, in the ACUCOBOL-GT manual set.)

What is native code?

Native code is CPU-specific code made up of instructions that are executable directly by the host CPU. You would usually choose the native code option when you want to improve your program's performance with certain operations, and you are willing to give up object-code portability.

Effects on overall program performance and specific operations

Compared to ACUCOBOL-GT Version 4.0, native code is about 2 to 3 times faster for computationally intensive COBOL programs. These numbers come from an industry standard benchmark that measures COBOL operations according to the frequency of their occurrence in real programs. The benchmark measures only processor performance.

The improvement in any one program depends on what that program does. File processing is not any faster using native code rather than object code. The more "CPU bound" the program, the bigger the improvement. Many programs spend 90% of their time doing file operations. Improving the remaining 10% by a factor of 5 results in a total improvement of only 8%. Most programs will experience only modest improvements (something in the range of 5 to 10% is a reasonable expectation); some programs, however, will see much bigger improvement.

The program operations that benefit the most from native code are simple MOVEs, simple comparisons, general flow-of-control, GO TO, PERFORM, and table addressing. All operations run somewhat faster using native code, but how much faster depends on the operation itself. The simpler the operation, the bigger the improvement is likely to be. For example, the statement "MOVE 'A' TO PIC-X-1" will show a large improvement, probably around ten-to-one. This is because the overhead in setting up to do the statement in object code is large compared to the work done in the statement itself.

Practical benefits

There are two scenarios where using native code is likely to have a substantial benefit. The first is programs that are heavy users of the CPU or that have specific portions that are CPU-intensive. For example, programs that fill a large table and then do some sort of iterative analysis on this table will likely see a large improvement in performance. If you have an interactive program that does quite a bit of list processing, your users may experience a pause while the list is processed. This pause should noticeably lessen when you use native code.

The second benefit occurs when you are looking at the total throughput of a multi-user system. The system's total capacity is defined by several values, such as the speed of its file system, its memory capacity, and its CPU speed. The number of users a system can support depends on how these resources are consumed by the users. Running out of processing power is one of the common constraints. Using native code substantially reduces the total CPU consumption of the programs that are running, allowing more users to run effectively. For example, if a machine's CPU idle time is 50% or more, then converting to native code will have little effect, because the CPU is not under much of a load anyhow. However, if the idle time is under 10%, then you could expect a noticeable improvement in total throughput.

You may mix native code objects and machine-independent objects in the same run, using the format that is more advantageous for each program, and thus deriving the best of both worlds.

There are two other aspects to using native code that merit consideration. The first is program size. Native code is quite a bit larger than object code (a growth in code size of 3 to 4 times is quite normal). Considering the improved performance, this effectively trades one resource (memory) for another (processor), which generally is a good trade. It is easier and cheaper to add memory to a machine than it is to upgrade its processor.

The second aspect is that the native object code is no longer machine-independent. This means you cannot just copy the object files to a new machine (of a different type) and expect them to run. A program written in native code is, however, system-independent within its own family of processors. So you can compile the native code for Intel and transport it among any and all hardware platforms and operating systems running on an Intel family processor without recompilation or modification. That includes Windows, Unix, Linux, and other platforms, as long as they use the same family of processors. Currently supported are two popular families of processors: Intel (386 to Pentium III) and Sparc (v.7 to v.9). We anticipate adding other processors in future versions. (See Book 1, section 1.4.1, in the ACUCOBOL-GT manual set.)

Implementation and usage

There are a number of ways you can implement native code with ACUCOBOL-GT, and each produces exactly the same result, with the difference being simply their convenience to you, the developer.

• You can ask the compiler to produce native code directly.
• You can produce machine-independent object code first and then translate it into native code using the cblutil utility (see Book 1, section 3.2.4, in the ACUCOBOL-GT manual set).
• You can compile native code directly on the target machine ("-n" option, which produces the code for the type of processor used by the machine on which the compiler is working).
• You can compile on one machine for different target machines (with the "--sparc" or "--intel" options described in Book 1, section 2.1.1.1 in the ACUCOBOL-GT manual set) and then port the native program files, instead of compiling on every target machine.
• You can compile to produce machine-independent object code, port it, and then translate it to the native code on target machines.

This versatility gives you a number of distribution options so that you may choose the best for any specific situation.

The role of the runtime

The runtime is still required with the native code. The native code objects use the runtime to provide system services, screen handling, file handling, and library support. In fact, you run the native code objects with the runtime just as you do the machine-independent objects. You can also debug native code programs using the runtime's debugger in the normal fashion. The only restriction is that you cannot use the "@!" operation in the debugger to start execution from a different point in the program.

Windows Functions

On 32-bit Windows operating systems, ACUCOBOL-GT includes a number of dynamic link libraries (extension ".DLL"). These DLLs are part of the product and contain various utility functions used by the executable files. They may also contain data. The .DLL files that are part of the ACUCOBOL-GT compiler and runtime install automatically in the same directories as the main executable files for the compiler and runtime, "CCBL32.EXE" and "WRUN32.EXE", respectively.

One of the main components of the 32-bit Windows versions of ACUCOBOL-GT is a utility file called "ACME.DLL". All the .EXE and .DLL components of ACUCOBOL-GT link to this file, including their initialization and shutdown functions. "ACME.DLL" offers the benefit of providing a common set of utility functions for all executables to share, as well as allowing you an easy and consistent access to all our libraries through a single .DLL. "ACME.DLL" installs automatically in the same default subdirectory on your machine as the executable files.

Note: Those users who move the products into a different directory after the installation is complete, or those who ship the compiler or runtime separately as part of their own product, should make sure that all of the .DLL files are placed in the same directory as the .EXE files. So if you move "CCBL32.EXE" or "WRUN32.EXE", you must move all of the associated .DLLs along with them.

Please refer to the READ_ME.32 file in the "AcuGT" subdirectory for the complete list and brief descriptions of the files installed with your ACUCOBOL-GT product.

Support for IBM's CICS Universal Client

The Windows version of the ACUCOBOL-GT runtime has been enhanced to understand the call syntax of IBM's Customer Information Control System (CICS) Universal Client. This allows you to access IBM applications on a mainframe and to use ACUCOBOL-GT GUI interfaces as a front end to IBM COBOL applications. (Please note that we support only the External Call Interface (ECI) of the CICS client.) To use this feature, you must install and configure CICS according to IBM's specifications. Then you simply compile with the appropriate data format switches; the runtime does the rest. No relinking of the runtime is required. See Book 4, Appendix M of the ACUCOBOL-GT manual set for more details.

Support for IBM's MQSeries

The Windows version of ACUCOBOL-GT now supports calls to the MQSeries Windows client. The runtime has been enhanced to understand the call syntax of this client. This enhancement enables you to access IBM applications on a mainframe and to use ACUCOBOL-GT GUI interfaces as a front end to IBM COBOL applications. To use this feature, you must install and configure MQSeries according to IBM's specifications. Then you simply compile with the appropriate data format switches; the runtime does the rest. No relinking of the runtime is required. See Book 4, Appendix M of the ACUCOBOL-GT manual set for more details.

ActiveX and OLE

Now you can use "off the shelf" ActiveX controls and Object Linking and Embedding (OLE) objects in your Windows-based ACUCOBOL-GT programs. The compiler has been enhanced to allow you to insert pre-programmed OLE objects (including ActiveX controls) into your ACUCOBOL-GT source code. AcuBench has been enhanced to allow you to insert graphical ActiveX controls (such as browsers or custom gauges) into the screens of your Windows interface.

In AcuBench, you open an ActiveX control in the Screen Designer, place it on your screen, and set the properties, just as you do with any other ACUCOBOL-GT control. AcuBench generates the code and copybook necessary to run the ActiveX control.

Outside of AcuBench, you use the AXDEFGEN utility to generate copybooks for ActiveX controls and other OLE objects, including those that are non-graphical in nature, such as spell checkers and automation servers. You then add the control or object to your program, get and set properties using the INQUIRE verb, and invoke the methods using the MODIFY verb. (A method is a particular function performed by the control or object.) When you distribute your COBOL programs, you include the resource file and copybook for the ActiveX control or OLE object.

Many ACUCOBOL-GT verbs have been enhanced to support ActiveX and OLE functionality. For general information on ActiveX and OLE programming, refer to Book 1, section 6.10 of the ACUCOBOL-GT manual set. For other ActiveX and OLE-related topics, refer to the following sections of the manual set. Note that User's Guide (Book 1) is abbreviated UG, User Interface Programming (Book 2) is abbreviated UI, Reference Manual (Book 3) is abbreviated RF, and Appendices (Book 4) is abbreviated AP.

Automation Server

The ACUCOBOL-GT Automation Server makes COBOL accessible from any macro-language or programming tool that can act as an automation controller. You can now integrate existing COBOL programs with programs written in different languages to synthesize new applications. The Automation Server simplifies the process of passing data back and forth between COBOL and other languages. You do not need to insert declarations into the source code of the other programming language, and you can call COBOL programs from multiple threads in your applications. See Book 4, Appendix M of the ACUCOBOL-GT manual set for more details.

Compiler Options

The following compiler options are new:

The following compiler options allow you to call IBM Servers using CICS and MQSeries:

The following compiler option has been enhanced:

Library Routines

Several new library routines and enhancements to existing routines highlight this new version of ACUCOBOL-GT.

The new C$KEYPROGRESS routine is used in a USE FOR REPORTING declarative procedure to obtain information about the progress of the system when it is adding keys to a file opened for BULK-ADDITION.

Several library routines have been added as a part of the new ActiveX feature:

The $WINHELP library routine has been enhanced so that you can access compiled Microsoft HTML files that have the ".chm" extension. $WINHELP will automatically detect the ".chm" file extension and invoke the Microsoft HTML Help Viewer application (hh.exe) to access the file.

The I$IO routine, which provides an interface to the ACUCOBOL-GT file handler, is now documented in Book 4, Appendix I of the ACUCOBOL-GT manual set.

The WIN$PRINTER routine has been enhanced with new operation codes that allow you to specify columns when you are printing with proportionally spaced fonts, and to change the page orientation so that you can intermix pages with landscape and portrait orientation in a single print job. For the input (print line) side, you have the following new operations:

For the output side (page layout), you have the following new operations:

The "winprint.def" file has a new structure to support these new operations. See Book 4, Appendix I of the ACUCOBOL-GT manual set for more information.

Some AcuConnect(TM) library routines have been added to Book 4, Appendix I of the ACUCOBOL-GT manual set, for ease of reference:

Configuration Manager

The runtime has been enhanced with a new configuration manager that processes configuration variables in a more efficient way. This has made it possible to have multiple configuration files nested one inside another. You can specify another configuration file to process within the configuration file given to the runtime by using the following syntax:

!COPY filename

where "filename" is the name of the configuration file you are including. No processing is done to "filename", so you must specify the full path to the file.

Configuration Variables

Numerous configuration variables have been added that act as equivalents for existing values of the SCREEN, KEYBOARD and MOUSE variables. They are documented in Book 1, Chapter 4 and Book 2, Chapter 7 of the ACUCOBOL-GT manual set. Following is a complete list:

The Entry Field control was previously modified in Version 4.3 to include a new property called AUTO-DECIMAL. Now, a new AUTO_DECIMAL configuration variable performs the same function as the AUTO-DECIMAL property.

You can now exclude .DLLs from a CANCEL ALL statement by using the CANCEL_ALL_DLLS configuration variable.

DUPLICATES_LOG can be used during the bulk addition of Vision files to create a log file of records rejected for having illegal duplicate keys.

Using the FILE_TRACE variable, you can now save information about all file OPENs, READs, and WRITES in the error file without opening the debugger.

LC_ALL causes the runtime to set the locale to a particular value to support the transfer of double-byte character variables and string literals on 32-bit Windows systems.

You can force the runtime to open broken files that would normally cause an error 98 with the V_FORCE_OPEN variable.

WINDOW_INTENSITY controls whether the color settings specified in the COLOR phrase of the DISPLAY WINDOW statement are used or ignored by the runtime.

DISABLED_CONTROL_COLOR enables you to use color to distinguish between enabled and disabled screen controls on character-based systems. End users can differentiate readily between controls that are available for use and those that are not.

The FLUSH_ON_CLOSE configuration variable prevents the runtime from automatically flushing a file's cache buffers to disk on close (but allows this function when desired). This can provide a significant improvement in system performance in some situations.

The V_MARK_READ_CORRUPT variable allows you to configure the runtime so that it does not mark a Vision file as broken if it encounters a corruption during a read or start operation. This allows you to retry the file in the event of a network caching error.

On Windows systems, the V42_TRANSPARENT variable allows you to choose whether a transparent label placed within a frame takes the color of the frame background or of the parent window.

On Extended DOS systems, the DOS_WATCOM_10 configuration variable allows the runtime to work around differences in the "C clock( )" of the Watcom C Version 10.0 and the Watcom C Version 11.0 (the version now used by Acucorp).

CGI_STRIP_CR allows you to strip extra carriage returns from HTML text areas. This can prevent double-spacing problems and help avoid conflicts when data is used in a context that does not expect a carriage return to precede each line feed.

Windows users may now place a "sub" routine into one or more .DLL files. To do this, you must specify which routine to use as the "sub" interface routine by setting the DLL_SUB_INTERFACE configuration variable. Details on placing "sub" routines in .DLLs can be found in Book 4, Appendix C, section C.3.1.1 and Book 4, Appendix H of the ACUCOBOL-GT manual set.

Some new configuration variables apply to character spacing issues:

• Windows 98 uses a wider version of the Arial font than prior versions of Windows use. OLD_ARIAL_DIMENSIONS allows you to select which width of Arial is used to calculate character spacing in your screens.
• Version 5.0 of the runtime computes the width of printer cells differently than earlier versions. V43_PRINTER_CELLS allows you to use the width calculation from Version 4.3.

Vision allocates a memory buffer for each file opened for bulk addition. You can set the size of this buffer using the V_BULK_MEMORY configuration option.

Some AcuServer(TM) configuration variables have been added to Book 4, Appendix H of the ACUCOBOL-GT manual set, for ease of reference:

• DEFAULT_TIMEOUT sets the length of time in seconds that the runtime or plug-in waits for a response from acuserve before timing out.
• USE_LOCAL_SERVER specifies whether or not you want to run client applications on a machine designated as an AcuServer file server.

With Version 5.0, most configuration variables can be read with the ACCEPT FROM ENVIRONMENT verb. Because of this, we have changed the way this functionality is noted in Appendix H. Now, only variables that CANNOT be read with ACCEPT FROM ENVIRONMENT are marked with an asterisk (*).

You can find detailed explanations of all these variables in Book 4, Appendix H of the ACUCOBOL-GT manual set.

Intrinsic Functions

Version 5.0 has been enhanced to include over three dozen intrinsic functions. Intrinsic functions are subprograms that are built into the ACUCOBOL-GT library. They save time by simplifying common tasks that your COBOL programs might need to perform. For example, intrinsic functions can perform statistical calculations, convert strings from upper to lower case, compute annuities, derive values for trigonometric functions such as sine and cosine, and perform general utility tasks such as determining the compile date of the current object file. See Book 4, Appendix P of the ACUCOBOL-GT manual set for details about these new functions.

ACUCOBOL-GT and IBM DOS/VS COBOL Compatibility

The ACUCOBOL-GT Version 5.0 compiler has been enhanced with a new command line option that supports the core syntax and configuration modes of IBM DOS/VS COBOL.

This compatibility is quite beneficial for users who have existing code with IBM COBOL/VS syntax. These users might include those who have:

• Micro Focus applications with IBM syntax
• Migrations from IBM syntax

Through the versatile new "-Cv" command line option, ACUCOBOL-GT enters a mode that accepts specific syntax and features of IBM DOS/VS COBOL that are not compatible with the "regular" ACUCOBOL-GT mode.

The command line argument "-Cv" is required to specify compatibility with IBM DOS/VS COBOL. If this argument is not present (either on the command line or in the CBLFLAGS environment string), then the ACUCOBOL-GT compiler rejects IBM DOS/VS COBOL-specific features as general errors.

The following list contains the features of IBM DOS/VS COBOL that are accepted via the "-Cv" command line option. See Book 4, Appendix G of the ACUCOBOL-GT documentation for more details about this option.

ACTUAL KEY Clause and SEEK	AFTER POSITIONING Clause	APPLY Clause Options
BASIS, INSERT, DELETE	COM-REG	COPY Statement
CURRENT-DATE	Data Files	DATE-COMPILED
Debugging Features	DISPLAY UPON SYSPCH	EJECT, SKIP
ENTER Statement	EXAMINE, TRANSFORM	File Status Codes
FILE-LIMIT Clause	Floating-Point Data Representation	IDENTIFICATION Division Arrangement
IF OTHERWISE	LABEL RECORDS	NOTE Statement
Password Protection of Files	PICTURE and USAGE Clauses	PROCESSING MODE Clause
PROGRAM-ID Program Name	RECORDING MODE Clause	Reversed File Reads
SORT Statement Registers	SPECIAL-NAMES	START Statement and NOMINAL KEY
TIME-OF-DAY	TRACK-AREA Clause	USE AFTER ERROR PROCEDURE
VALUE OF Clause	WHEN-COMPILED

At this point, absolute IBM DOS/VS COBOL compatibility is not entirely possible. However, with the "-Cv" option, many prime differences between the two COBOLs are greatly lessened, and ACUCOBOL-GT Version 5.0 becomes a viable option for users who are part of the IBM syntax and mainframe COBOL world.

Internet Features

Starting with Version 5.0, you have additional control over which routines can be called by programs that are executed by the Web plug-in. If you want to allow programs executed by the plug-in to call a library routine that is normally disallowed, you can now instruct your users to add a line to the "acuauth.txt" file containing the name of the routine. In addition, if you want to allow programs executed by the plug-in to call .DLLs, you can instruct your users to add a line containing the word "DLL." Refer to section 5.9 of the Programmer's Guide to the Internet for more information on updating the "acuauth.txt" file.

In addition, the files necessary for running the plug-in have changed. If your users install the plug-in using the installation script provided by Acucorp, they do not have to do anything different. However, if they are installing the plug-in manually, they should:

1. Copy "NPacu32.dll", "acucorp.lic", "vic32.dll", "acme.dll", and "wrun32.dll" to their browser's "plugins" directory.
2. Copy "mfc42.dll" and "msvcrt.dll" to their Windows .DLL search path (typically, the c:\windows\system directory on Windows 95/98 or c:\winnt\system32 on Windows NT/2000).

Most of these files can be found in the AcuGT\bin directory on the ACUCOBOL-GT distribution media. Caution users not to overwrite newer versions of these files. Refer to section 5.7.1 of the Programmer's Guide to the Internet for more information.

For CGI programming, you can now configure the runtime to automatically remove carriage return characters from CGI data received from the client machine as a result of multiple line entry fields (also known as HTML TEXTAREAS). To do so, set the runtime configuration variable CGI-STRIP-CR to "1" (ON, TRUE, YES). Stripping the carriage returns prevents double-spacing problems and eliminates conflicts that may arise if a carriage return character is not expected before each line feed character. Refer to section 7.3.2.1 of the Programmer's Guide to the Internet for more information.

Finally, starting with Version 5.0, your users must have MS Internet Explorer Version 4.0 or later on their machines in order for the Web Browser control to work.

Miscellaneous ACUCOBOL-GT Enhancements

1. GUI controls can now be positioned by exact pixel coordinates rather than by relative character positions. You can specify the "X" and "Y" coordinates, LINES, and SIZE of a control in pixels. This feature gives you better control over screen layouts. The screen designer can now easily accommodate screens based on different cell sizes. See Book 2, section 4.5.3 of the ACUCOBOL-GT manual set. Note that the LABEL-OFFSET property is ignored when a control's coordinates are specified in pixels (absolute coordinates).
2. Nearly all configuration variables can now treat the values of "1", ON, TRUE, and YES as synonymous. See Book 4, Appendix H of the ACUCOBOL-GT manual set for exceptions.
3. The file utility program vutil has several new options that allow it to run unattended more easily. Every major mode can now take the "-q" option, which causes vutil to exit with status 99 if user interaction is required. The "extract" mode has three new options: "-k #",
   "-n #", and "-v value". See Book 1, section 3.3.5 of the ACUCOBOL-GT manual set for details.
4. The vutil "-size" option now accepts the new option "-n". This option causes the names of non-Vision files to be listed, even though their size is not reported. This enables you to see a full listing of the files that are being examined.
5. The program name in the PROGRAM-ID paragraph of the Identification Division may now be placed in quotation marks. This is especially useful if the name contains embedded spaces or is in any way incompatible with identifier syntax.
6. You can now name INCLUDE files of mixed-mode in your Embedded SQL source. Mixed-mode files contain both terminal and ANSI source format types.
7. The new Status Bar control is now supported on 32-bit Windows systems. A status bar appears at the bottom of its host window and contains panels that can be programmed to display the status of events in the window. A status bar remains accessible even when the window is scrolled. It automatically grows and shrinks horizontally to match the width of the window. See Book 2, section 5.18 in the ACUCOBOL-GT manual set for details.
8. Additional information about line numbers has been added to error messages and listings.
9. You may now increase the maximum record size of a Vision file with the "vutil -augment" option. This is useful when you want to add fields to a record without rebuilding the entire data file. See Book 1, section 3.3.13 in the ACUCOBOL-GT manual set for details.
10. As part of the improvements to our license protection features, the way the runtime identifies users in acushare has been modified. Acushare now tracks the number of unique terminal names that are executing simultaneously. Each unique terminal name may be running many processes at a time. This enhancement is described in Book 1, section 2.12.1 of the ACUCOBOL-GT manual set.
11. A new RECORD-POSITION construct may now be used anywhere a data item can be used. This allows you to refer to a data item by creating a numeric literal that represents the location of the data item within a record. This construct is particularly useful with the DATA-COLUMNS property of the list box and grid controls. See Book 3, section 5.2.5 of the ACUCOBOL-GT manual set for syntax and examples.
12. Nested COPY REPLACING statements are now allowed at any level of nesting.
13. The word SUPPRESS can now be used to exclude library or path names from the COPY statement. This word was added to enhance compatibility with IBM DOS/VS COBOL, but is not exclusive to the "-Cv" command line option. See Book 3, section 2.4.1 of the ACUCOBOL-GT manual set for more information.
14. The external variables F-INT-ERRNO and F-INT2-ERRNO are now LONG instead of SHORT. This allows greater precision for error codes from outside sources.
15. Numeric literals may now be specified with binary, octal, and hexadecimal notation, as well as decimal.
16. You may use COPY RESOURCE or cblutil to add wave files (.WAV) to an object library. The routine WIN$PLAYSOUND now searches for a specified wave file in the object libraries.
17. The compiler and runtime now accept the External Floating-Point (EFP) data type. This data type is defined with a PICTURE phrase and provides compatibility with IBM DOS/VS COBOL. EFP items may be written to and read from data files, and converted to and from other numeric types. Addition, subtraction, multiplication, division, comparison, and exponentiation are supported. EFP operations are always rounded off, regardless of whether the ROUNDED option is used.
18. The compiler now recognizes additional debugging options. The new options are most useful when compiling is done with the workbench, but compilers on all machines understand them. The new options are:

-Gd includes the source code in the compiled object file. This option is equivalent to "-Zd" (which is still available).

-Gs includes extra symbol information. This information is accessible only from the workbench. It allows the workbench to traverse the symbol table of the COBOL program.

-Gl includes line numbers. This allows the workbench to show the source of the COBOL program, highlighting the line that the debugger is currently stopped on.

-Gy includes minimal symbol information. This option is equivalent to "-Zs" (which is still available).

-Ga is a shortcut for turning on all the debugging options.

19. The new "LENGTH OF data-name" expression generates a value representing the current number of bytes of storage used by data-name. This new expression can be used wherever a numeric data item can be used, except as a subscript or a reference modifier. It can also be used to set the value of a level 78 item. Prior to this enhancement, you could use the SET verb to get the size of an item and then use the size in an expression. There was previously no way to set a level 78 item's value to the size of an item. See Book 3, section 2.1.2.1 of the ACUCOBOL-GT manual set for more information about this feature.
20. For sites that interface ACUCOBOL-GT programs with C subroutines, you can now call the routine "cobol_exit_code" to retrieve the reason why the "cobol" function returned. The values returned by "cobol_exit_code" are specified in Book 4, Appendix C, section C.6 of the ACUCOBOL-GT manual set.
21. The Alternate Terminal Manager is a separate runtime available with Version 5.0 that you can install and use independently from the regular ACUCOBOL-GT graphical runtime. The Alternate Terminal Manager runs only on Windows NT/Windows 2000. It is similar to the regular UNIX or Extended DOS character-based runtimes, with one of the differences being that the Alternate Terminal Manager runtime can now detect Acu4GL(TM) .DLLs (and other .DLLs). The ATM runtime comes with all the libraries it needs, compiled with different flags for the regular graphical runtime than for the character runtime.

This self-contained architecture of the Alternate Terminal Manager allows you to use a Windows NT server machine in a manner that is similar to a UNIX machine. You can telnet to the Windows NT server (with a third-party telnet service) and execute a COBOL program in that telnet window. Note, however, that this does not allow you to run the runtime from a console window on the Windows NT machine.

All major runtime functionality is available with the Alternate Terminal Manager runtime (keep in mind that this is strictly a character-based program, so certain Windows-specific features, such as pop-up dialog boxes, are not included). In case you need to relink the runtime, the library is provided (LIB\TERM32.LIB), and the makefile (WRUN32.MAK) contains the instructions for using the Alternate Terminal Manager.

22. The CBLFLAGS environment variable now ignores all arguments in excess of 50 arguments. This eliminates the possibility of a memory protection violation. Combined options from the same group are counted as one argument.
23. The default size of a floating window for which no main application window exists has now been defined. It is the same as the size of the current window.
24. A new runtime option "--no-save-debug" prevents the debugger from writing out a file (".adb") that contains information about the "state" of the debugger when it exits. This option also prevents the debugger from reading any existing "state" file at startup. The debugger thus starts up in its default state.
25. The transaction management utility logutil now requires you to specify years in a four-digit format.

 

Acu4GL

General Enhancements

You may be familiar with the XFD_MAP configuration variable. It associates filenames with a particular XFD, thus enabling you to use one XFD for many different files. A new variable named XFD_MAP_RESET now allows you to specify whether setting a value for XFD_MAP causes the previous value of XFD_MAP to be replaced, or adds another filename (or set of filenames) to the association. When multiple lines exist, all associations are used in the order they are listed.

The new version of Acu4GL(TM) offers improved error reporting when a dictionary file conflicts with the COBOL definition of the file. The exact nature of the mismatch is now reported with an error 9D, 06.

MS SQL Server and Sybase

You can now dynamically assign the specific database and server to be accessed by individual SQL commands by making CALLs to the library routine I$IO. This routine is documented in Book 4, Appendix P of the ACUCOBOL-GT manual set. An example is provided in the Acu4GL User's Guide, section B.3 under A_MSSQL_DEFAULT_CONNECTION and section E.5 under A_SYB_DEFAULT_CONNECTION.

With the Acu4GL Version 5.0 release, the default values for the A_SYB_ADD_IDENTITY and A-MSSQL_ADD_IDENTITY configuration variables have changed from FALSE to TRUE for files with keys that permit duplicates. This change allows such files to be more efficient in their processing of keys that allow duplicates.

When set at the default of TRUE, A_SYB_ADD-IDENTITY and A_MSSQL_ADD_IDENTITY add an extra column to any table created by the Acu4GL for Sybase and Microsoft SQL Server products, respectively. This extra column contains the Identity property, and is included on all indexes that are not unique. Otherwise, when A_SYB_ADD_IDENTITY and A_MSSQL_ADD_IDENTITY are set at FALSE, an extra column is not added.

When set for files with keys that allow duplicates, this variable has been tested and found to vastly improve performance. However, users who miss the old default behavior simply need to set the appropriate configuration variable to FALSE.

Informix

Support for Informix 7.3 libraries has been added. Because Informix is no longer offering Informix 5.0, the newest Acu4GL for Informix is designed for use with Informix 5.1, Informix 7.2, and Informix 7.3.

Oracle

Acu4GL now supports the 64-bit version of Oracle 8.

AcuConnect

Starting with AcuConnect(TM) 5.0, one instance of AcuConnect can CALL another. This means that a client application can launch an application on one server, and that application can then launch another application on another server. Previously, AcuConnect could CALL another instance of AcuConnect only if it was on the same server. Because of this enhancement, customers can distribute their application across as many server machines as they like. Refer to section 2.2.3 of the AcuConnect User's Guide for more information on CALLing multiple programs.

AcuODBC

AcuODBC(R) Version 5.0 includes several enhancements. It conforms to more SQL and API ODBC standards requirements. This means you are able to issue more grammatically complex SQL commands, giving you more precise control over data access. For instance, AcuODBC now supports more functions of the SELECT command, including the use of EXISTS subqueries, SELECT FOR UPDATE syntax, additional string functions, the use of aggregate functions on ORDER BY clauses, the use of arithmetic functions, and the use of rowsets. (See section 6.3.1 of the AcuODBC User's Guide for more information on these new functions.)

AcuODBC Version 5.0 also adds transaction management logging capabilities such as the ability to create a log file, set the log buffer size, and enable/disable transaction logging. In addition, it includes the ability to set connection parameters for use with AcuServer, including default timeout and server port number. Both of these capabilities have been added to the Vision Options screen. Refer to section 3.4 in the AcuODBC User's Guide for more information. Similarly, the Advanced Options screen has also been enhanced with an option to allow empty data strings that have the value "" (empty string) rather than "NULL". This allows you to view empty fields in your data source as desired. This is explained in section 3.2 of the AcuODBC User's Guide.

AcuSQL

Starting with Version 5.0, AcuSQL(TM) supports a set of Oracle data types. This enables Oracle customers to access their data from COBOL with the embedded SQL approach as needed. Previously, AcuSQL supported DB2 and MS-SQL databases, as well as any other SQL92 compliant data source. As of Version 5.0, it will be tested and proven with Oracle data types as well. Refer to section 2.3 of the AcuSQL User's Guide for more information on using Oracle data types.

Starting with Version 5.0, AcuSQL customers are also able to pre-compile files that contain both terminal and ANSI data types, also known as "mixed-mode" files. This gives you more flexibility in the types of data you can use.

AcuServer

The AcuServer(TM) client now communicates with AcuServer using a different networking technology. Rather than using Remote Procedure Calls (RPC) to pass information between the client and the server, it uses a concept called "sockets." Your benefit from this change is improved performance. Sockets are a lower layer of software than RPC, so data reaches its intended path more quickly in Version 5.0. Likewise, previous implementations of AcuServer imposed additional layers of networking protocols when transferring a large number of sequential records without user interruption. Starting with Version 5.0, you can generate reports considerably faster, because no additional layers are added. Note that because of this change, AcuServer 5.0 does not work with previous versions of the ACUCOBOL-GT runtime, and earlier versions of AcuServer do not work with the Version 5.0 runtime. Programs compiled earlier versions of ACUCOBOL-GT can be executed, provided that the version of ACUCOBOL-GT runtime and AcuServer match.

In Version 5.0, the "acuserve -install" command has been changed to support any valid start option. These options are stored for service start-up on this particular port. For example, to run the service with the arguments "-c c:\etc\server1.cfg -le c:\tmp\server1.log" on start-up, you would use the following "-install" command:

acuserve -install -c c:\etc\server1.cfg -le c:\tmp\server1.log

Installing a service on a particular port resets all start-up options for the service on that port. If no options are stored for a service, then starting the server on a particular port automatically installs a service on that port and stores the options used. In other words, you can install and run a service with one set of arguments and then occasionally run the service with different arguments by using "acuserve -start".

In Version 5.0, you can now use the "acuserve -config" command to change the configuration of a running AcuServer server, for instance, to turn tracing on or off or to change configuration variables such as PASSWORD-ATTEMPTS. When you enter this option, you start communicating with the server running on the named server and named port. If no server name is given, the local server is assumed. If no port number is given, the default port is assumed. See section 7.2.2 of the AcuServer User's Guide for more information.

You can now also use the "acuserve -query" command to query whether or not the specified Windows NT or Windows 2000 service is installed. See section 7.2.6 of the AcuServer User's Guide for more information.

A new configuration variable, ACUSERVER_PORT, specifies a particular port number to be used for accessing acuserve on the server host machine. This is especially helpful when the server host machine has a security firewall, because firewalls generally allow access only to specific ports. With this variable, the site can ensure that firewall restrictions are satisfied. Refer to section 6.1.2 of the AcuServer User's Guide for more information.

In Version 5.0, ACUCOBOL-GT includes a library routine, C$PING, that provides diagnostic information for debugging network performance with AcuServer. If you write a small COBOL program that calls C$PING, you obtain information such as whether or not the client is AcuServer-enabled, whether or not the parameter passed from the COBOL program is valid, whether the connection was refused or accepted by the server, and whether or not a socket error occurred. A compiled sample COBOL program called "acuping" is included in the \AcuGT\tools directory where you installed ACUCOBOL-GT. C$PING is described in the AcuServer User's Guide, section 10.3.

Version 5.0 includes a utility program called NTSAcuSv for Windows NT sites. NTSAcuSV is a Graphical User Interface for AcuServer. It issues the same command lines described in the AcuServer User's Manual. This program is automatically installed any time AcuServer for Windows NT or ACUCOBOL-GT is installed. It shows up on the "Start" menus for both AcuServer and the sample programs.

You may control the following AcuServer features with this interface:

• Monitor a port for status.
• Monitor a port for open files.
• Install/Remove AcuServer NT Service on any port.
• Start/Stop on any port.
• Unlock stranded files.
• Edit an Access File (Add, Change, Delete user security info).

To use this interface, you must have a Windows NT system, AcuServer for Windows NT, and an ACUCOBOL-GT client-enabled runtime. The on-line Help file called "NTSACUSV.HLP" provides additional details about this new utility program.

AcuBench

AcuBench(TM) Version 5.0 is a major upgrade to the Version 4.x workbench series. Version 5.0 significantly improves the integration of workbench components and greatly expands workbench capabilities. New features include a consolidated, integrated user interface; structural presentation of COBOL programs; multiple project support; graphical interfaces to ACUCOBOL(TM)-GT utilities; support for graphical and character-based screen design; support for ActiveX controls; automated code generation for screens, Working-Storage and Linkage items, File Descriptors, and Select statements; specialized tools and editors for creating and maintaining various sections of your code; an integrated debugger; support for most third party version control software; and more. After you read this summary of the major Version 5.0 workbench features, we are confident that you will want to try this greatly enhanced development tool. Detailed information about all these features can be found in the AcuBench User's Guide.

Component Integration

The most noticeable new feature is the integrated user interface. AcuBench now presents all of the workbench's primary functions within the AcuBench main application window. This user-configurable window contains several interior windows for viewing projects; for working with screen, source, and project files; and for monitoring several types of system output, like compilation messages, version control actions, and search results. Special windows exist for working with graphical controls and the integrated debugger. AcuBench provides a graphical interface to the functions performed by the ACUCOBOL utilities cblutil, vutil, vio, logutil, and alfred. You can control the visibility, size, and placement of all interior windows and toolbars.

Workspace Window

Version 5.0 introduces the workspace, a new concept and mechanism for collecting, viewing, and manipulating projects. The workspace is a container for one or more projects and their associated files and settings. Every AcuBench project is a member of a workspace (and only one workspace). The workspace is implemented in the form of the Workspace window. The tabs at the bottom of the Workspace window let you see three different workspace views. The workspace Structural View tab shows each project's programs, and within each program, access nodes to such basic COBOL program areas as Working-Storage and Linkage sections, event paragraphs, and data sets. The File View tab shows each project's member files grouped into related types like Source, Screen, Copy, Object, List, Resource, and FD files. The Data View tab shows each project's File Descriptors created using the workbench File Designer.

The Workspace window simplifies many aspects of working with project components. You can initiate most workbench activities by double-clicking on nodes in the workspace views or by selecting options from the context-sensitive right-click pop-up menus. You can also develop multiple projects concurrently, as long as they belong to the same workspace. Detailed information about working with projects can be found in Chapter 9 of the AcuBench User's Guide.

Code Editor Environment

Version 5.0 Code Editor functions continue to include familiar Windows desktop and text-editing features, plus a wide range of specialty tools that are COBOL sensitive. New commands allow you to display all level-78 constants and code macros in list boxes, add comment markings to or delete them from a selected block of code, and toggle the foreground and background colors of your code. You can also select a vertical block of text. The Control Flow Diagram (CFD) for your source code now displays in a separate window, and it can be printed.

You have several new options for customizing the Code Editor window's appearance and behavior in the Tools/Options dialog. General options include a setting for Line Number pane width. Foreground and background color settings for your code are consolidated in the Format options. You can direct the Code Editor to support tabs in your source, or to automatically convert the tabs in your code to spaces with the Tabs options. Using Keyword options, you can associate an indent value with a keyword or choose a general auto-indent behavior for your code. Code Insight options help facilitate the creation of your source code. Enable the Code Completion option if you want the workbench to suggest how to finish a section of code. If you enable the Parameter Completion option, the editor displays pop-up hints that describe the activity you want your application to perform and the syntax for completing some code statements and internal library calls. The Code Template option allows you to define frequently used code as a template that can be inserted into your source code with a mouse click.

Screen Designer Environment

New Screen Designer capabilities allow you to design screens in both graphical and character-based environments. Your application can contain both graphical and character-based screens, because the automatic code generation function creates Screen Section code that labels the two types of screens differently. The Execute command replaces the Run Screen command from previous versions. For an Execute action, the workbench performs several functions: save screen, generate code, compile program, and execute program.

The Align toolbar contains many of the commands previously included on the alignment palette. However, some positioning commands are new to this version. You can space your controls evenly in a screen, horizontally or vertically, or you can position two controls so that they share boundary locations, either horizontally or vertically. You can also resize your control to fit the size of its title or label. Change the order that an end user tabs through the controls on a screen with the Tab Order command.

In addition to the alphabetic listing of properties and events, in this version the Property window contains a tab that lists properties by category. For example, properties are grouped by appearance, behavior, and position.

Previously called the control toolbox, the Component Toolbox contains icons for standard and ActiveX controls. Icons for the Menu Designer and Toolbar designer appear with the standard controls. Control icons may be viewed in a list with labels or as bitmap push buttons with pop-up hints. You can design a status bar for your graphical screen with the new status bar control.

New options for customizing the Screen Designer are available with the Tools/Options command. You can set basic attributes of the Screen Designer grid and how controls interact with the grid. You can set default control property values for the properties that can have default values. You can also customize the appearance of your Property window by determining which properties are actually listed and which ones are not.

ActiveX Controls

The AcuBench Screen Designer supports the inclusion of ActiveX controls in programs that run under Microsoft Windows. The ActiveX controls used in your program must be installed and licensed on every system on which the program is deployed. Like standard controls, ActiveX controls are placed and configured on the screen form. Exactly which ActiveX controls are available to you depends on the ActiveX controls that are installed on your system and registered in your Windows system registry.

Automated Code Generation

AcuBench Version 5.0 enhances its facilities for automatically generating COBOL code for key program elements. These facilities have been expanded in an ongoing effort to provide a development environment that includes useful methods of simplifying development while creating programs that are more reliable and robust. Automated code generation facilities were introduced to AcuBench in Version 4.x in the form of the Screen Painter, renamed the Screen Designer in Version 5.0. In addition to the Screen Designer, Version 5.0 has specialized support for building File Descriptors with the File Designer, creating data set associations with the Data Set Designer, adding Working-Storage and Linkage Section items with the Working Storage Editor and the Linkage Editor, and creating event and embedded procedures with the Event Editor. These facilities generate the bulk of the associated code into COPY books that are then included in the program with COPY statements. These COPY statements are automatically inserted into the program between special tags as part of the Generate function. Detailed information about automated code generation and tags can be found in Chapter 4 of the AcuBench User's Guide.

Configuration File Editor

AcuBench includes an integrated Configuration File Editor (CFE), which allows you to open and edit any ACUCOBOL-GT runtime configuration file. With the CFE, you no longer need to access the host system's text editor in order to modify a configuration variable. Instead, you can modify the variable from within the workbench.

Integrated Debugger

An integrated debugger provides many of the functional capabilities of the ACUCOBOL-GT runtime debugger, but is accessed directly in the workbench. If you have used the runtime debugger, you will be comfortable using the workbench debugger. To aid in debugging, AcuBench provides four specialized debugger windows: Watch, Call Stack, Memory, and Threads. These windows contain valuable information about debugger functions, like the status of a watched variable or the amount of memory in use. Detailed information about debugger functions can be found in Chapter 24 of the AcuBench User's Guide.

Version Control

AcuBench provides support for third party version control software that includes a command line interface. In a special workspace options dialog box, you can define commands that interact with your version control system directly, or that execute your custom version control batch files. The commands that you define are automatically added to the version control menu that appears on all file-related right-click pop-up menus.

Miscellaneous

Product Corrections

Please note that all corrections contained in this release are described in a separate document that explains each change in the form of a brief Engineering Change Notice (ECN). The Version 5.0 ECN List is available on our Web site at www.acucorp.com and from Acucorp Technical Support.

Operating System Support

Starting with Version 5.0, we are retiring the 16-bit Windows version of all of our products. Technical Support is still provided for the older versions. The 16-bit platforms, like Windows 3.1, are gradually phasing out of view in most corporate settings, and focusing on the more popular 32-bit Windows environments will enable us to better serve our customers. In the past, we have supported 32-bit Windows 95, Windows 98, and Windows NT operating systems. Starting with Version 5.0, we will also add support for Windows 2000. We are committed to supporting the latest technologies and enabling you to use the most popular tools.

For more details about the new features in Version 5.0, please contact Acucorp Technical Support. For information about any of the Acucorp family of products, please contact your Acucorp Representative.

(c) Copyright 2000 Acucorp, Inc. ALL RIGHTS RESERVED.