Rational Apex Release Notes Thank you for choosing Rational Apex!
Please read this document to learn about known product issues, important tips, and other Apex product information. The Release Notes are also available online in HTML format from the Help > Manuals command.
The online Release Notes are guaranteed to be the latest version of this document. If you find discrepancies between the hard-copy and online versions of the Release Note, please assume that the online document contains the most current information.
ObjectivesThese release notes provide information critical to installing and using Rational Apex, including supported platforms and known issues with this release.
Scope - Product DefinitionThis document applies to Release 4.2.0 B of Rational Apex for Sun Solaris, HP-UX,True64 UNIX, and SGI Irix, and IBM AIX. These release notes describe:
- Hardware/Software Information
- New and Changed Features
- Guidelines and Restrictions on Using Rational Apex
- Defects/Change Requests
- Contacting Rational Technical Support
Before installing Rational Apex, be sure to read the Hardware/Software Information and Getting Started sections of this document. These sections contain important information for a smooth and successful installation.
Hardware/Software InformationThis section provides basic information on the platforms supported and the hardware and software requirements for installing and running Rational Apex and its add-ins.
Supported Platforms
This document uses the following terms to designated the various platforms on which Rational Apex 4.2.0 B runs.
Hardware Requirements
Hardware requirements are outlined in Installing Rational Apex.
If you wish to generate and/or execute SPARC V9 64-bit binaries, a Solaris 7 machine with the 64-bit Kernel is required. More information on determining if your Solaris 7 system has the 64-bit Kernel can be found in SPARC V9 Solaris 64-bit Support.
Software Requirements
Software requirements are outlined in Installing Rational Apex.
To use the Apex Web interface, the JDK 1.2.2 plug-in and the "appletviewer" tool (shipped with JDK 1.2.2) must be installed.
Getting StartedThis section provides information about pre-installation and licensing issues for Apex.
Getting Announcements from Rational
New Apex products, layered products, new releases, patches, and critical technical information about these products are now announced through e-mail.
To sign up for automatic notification, send an e-mail message to majordomo@rational.com with the words subscribe apex-announcements in the body of the message.
If you already subscribe to this list and wish to be removed, send an e-mail message to majordomo@rational.com with the words unsubscribe apex-announcements in the body of the message.
We do not advertise on this list.
Installation Information
Installation instructions for Rational Apex are available in Installing Rational Apex.
Licensing
Apex 4.2.0 B will not introduce a new license FEATURE line, but the version number will be incremented to 4.200.
All Apex products require the following base license features:
- env_base.host
- summit_base.host
- summit_cm.host
Each of the following products requires both the base license features and the additional license features listed after it:
- Apex Ada 95/83 (ada.host, asis)
The components described below are included with the Apex product but require additional license features:
- RCI (rci.host)
The components described below are included on the media with the Apex product but require additional license features to be purchased.
- Summit/TM
The host part of the name is one of alpha, hppa, mips, rs6k, sun4, or any.
- The alpha license is good for Digital UNIX.
- The hppa license is good for HP-UX.
- The mips license is good for SGI/IRIX. [Not in this release]
- The rs6k license is good for AIX.
- The sun4 license is good for Solaris.
- The any license is good for any O.S.
Note: Once Apex is purchased for two or more O.S.'s, an any key is provided.
The licenses held by an Apex session can be viewed using the Tools > Session > Show Licenses command from a Jobs, Server or Output window.
Upgrading from Previous Releases
This release note applies to Release 4.2.0 B of Rational Apex. If you are upgrading from a previous release, after the installation is complete, upgrade your subsystems and views using the apex_upgrade command. This command is described in detail in the Command Reference.
If you are doing just a patch install, it is not necessary to run apex_upgrade. Installing a patch to an existing release is described in Installing Rational Apex.
Installation Issues
Required Operating System Patches
The latest information on patches for each of the Apex platforms can be found at the following URLs:
- Sun Solaris:
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
We recommend that users take Sun's recommended patches for each OS version. These patches are incorporated into the OS by Sun. There are no patches required specifically for Apex.
- SGI Irix
http://support.sgi.com/surfzone/patches/
Site requires registration for access.
- HP-PA HP-UX
http://us-support.external.hp.com/
Patch information can be reached through the support pages. Site requires registration for access.
- Digital UNIX:
http://www.service.digital.com.patches
At this time, Apex requires no patches on this platform. Site requires registration for access.
To view the current list of patches produced by Rational for the Apex products, visit the ftp://ftp.rational.com/patch_info/index.html patch information page on our FTP server.
Product Documentation
Rational Software Corporation provides a full set of online documentation with this release. These documents can be accessed through the Help > Manuals command from any directory viewer or the Doc List button in the navigation bar at the top of each HTML document. A subset of these documents is provided in hard-copy.
A specific discussion of online help using Netscape can also be found in the Getting Started manual.
Postscript Versions
Postscript versions of most of the manuals are also provided and can be printed using the Help > Print Manuals command.
In some cases, you may note discrepancies between the printed documentation and the online documentation. In these cases, the online documentation is the most up-to-date and should be followed.
Man Pages
For a list of available manual pages, enter the following command in an Apex xterm window:
man apex
An Apex xterm window is an xterm window generated from an Apex window using Tools > Shell.
Compatibility IssuesReserved Words
Apex locates executables based on standard UNIX searchlist mechanisms. The following are words you should avoid using as names for scripts to be invoked in shell windows spawned from Apex:
apex
apex_display
apex_action
apex_output
visit
visit_ada
radaOf special notice in this list is apex, which is the central command for shell usage. Because Apex provides multiple ways to invoke shell operations, problems caused by overloading the term apex might seem to occur in inconsistent ways.
In addition, avoid any name that begins with Apex_ (case is important). No specific names are provided because the list is subject to change.
New and Changed FeaturesThis section outlines the changes, enhancements, and new features available in this release of Apex. The following are included in this section:
- SPARC V9 Solaris 64-bit Support
- Ada Compilation System
- Ada Object Editor
- Runtime
- User Interface
- Apex Shadowing
- Summit/CM
- Tools
- Documentation
- RCI
Miscellaneous
Ada Language Reference Manual (Ada LRM)
Since the release of Apex 4.0.0 the LRM has had some updates/corrections made by the Technical Corrigendum 1. You can find the latest copy with the most up-to-date information at http://www.ada-auth.org/arm.html.
Grep
With the 4.0 release of Apex the grep command was changed to first save any edit buffers to disk prior to performing the grep. A side effect of this change was that the grep operation could slow down greatly. With 4.2 the grep dialog box now allows the user to select whether files should be saved to disk prior to performing the grep operation. The behavior can also be controlled through the environment variable APEX_GREP_SAVEALL which can have the values:
TRUE Save all files before performing the grep operation
FALSE Do not save files and perform the grep operation on files currently on disk.
Linker
Solaris ld (linker) version 4 or later is required for use with Apex 4.2.x.
In developing release 4.2 it was found that the use of version 3 of the Solaris linker resulted in flawed binaries. Systems should be updated to have version 4 or 5 of the linker when using Apex 4.2. Current recommented patches from Sun contain the newest linkers.
To determine the version of the linker, run the command
ld -V
The apexinit requirements checking has also been updated to detect if version 3 of the linker "ld" is installed when starting Apex and will issue a warning.
SPARC V9 Solaris 64-bit Support
This release provides the tool set that helps Apex users to develop and deploy SPARC V9 64-bit programs (Ada, C, C++) on 64-bit Solaris machines.
No new license is required as long as the Solaris Apex license is valid.
Basic System Requirement
In addition to the system requirements for installing Apex, a Solaris 7 machine with the 64-bit Kernel is required to generate and/or execute SPARC V9 64-bit binaries. All Solaris 7 machines don't have the 64-bit Kernel installed. The command to identify a Solaris 7 machine capable of generating and running 64-bit programs is: isainfo -v. The output of this command on a Solaris 7 machine with 64-bit kernel is:
host% isainfo -v 64-bit sparcv9 applications 32-bit sparc applications
Data Model - LP64
The fundamental difference between SPARC 32-bit model and SPARC V9 64-bit model is in the Data Model. The former supports the ILP32 model, where the integer type (int in C/C++ and Integer in Ada), long integer types (long in C/C++ and Long_Integer in Ada) and pointer/address type (pointers in C/C++ and Access/System.Address type in Ada), are all 32-bit. The object file format is ELF-32. The latter supports the LP64 model, where long integer types (long in C/C++ and Long_Integer in Ada) and pointer/address type (pointers in C/C++ and Access/System.Address type in Ada), are 64-bit, but integer type (int in C/C++ and Integer in Ada) is 32-bit. The object file format is ELF-64.
One major cause of worry when moving from ILP32 to LP64 is that the size of pointers and integers are no longer the same. This poses major problems for C programs written in K&R mode (where it is not mandatory to specify function prototypes) if prototypes for functions returning pointers are missing. The default return type is integer which is not the same size as pointers in LP64 model.
SPARC V9 64-bit Programming
In Apex, the key to generating a SPARC V9 64-bit Ada/C/C++ object is modeling your view with the appropriate model. Any model whose name starts with "sun4_solaris_64 " models your view to use the SPARC V9 64-bit compiler.
There is no static linking in SPARC V9 64-bit mode since the standard system libraries are available only as shared objects (there are no static archives). Given that, in any Ada view, even if the value of the link mode switch (LINK_CONTRIBUTION_DEFAULT_MODE) is set to static, the system libraries are linked in dynamically.
One cannot mix and match 32-bit objects and 64-bit objects. That is, a 32-bit object cannot be linked into a 64-bit object and vice-versa.
Ada Compilation System
The following have been implemented for this release of the Apex Ada compiler and runtimes.
- Alignment of Types and Objects
- Address Clause Alignment Check
- Check Name Alignment_Check
- Checking of Interfacing Pragmas For Composite Types
- Elaboration Order
- New Parameter Passing Conventions
- Pooling of Global Variables
- Pragma Concurrent_Processing_Policy
- Pragma Convention (Intrinsic, Some_Random_User_Routine)
- Pragma Suppress_Warning
- Shared Library Version Numbering
- System Address
- Interface to ANSI C and K&R C - Change in Default
- Single Rada and COMPILER_TOOLS_PATH
- COMPILER_TOOLS_PATH Switch
- Miscellaneous Changes
Alignment of Types and Objects
The default alignment of types and objects has changed. In the absence of representation clauses specifying the alignment of a type or object, the compiler is free to choose the alignment it wants, in order to obtain the best performance.
In all cases, the default alignment of an object is the alignment of its type.
In this release, the default alignment for a composite type is the smallest power of two that is larger than the size, subject to architecture-dependent limits. This is, in general, the approach that results in the best performance, notably on RISC processors. However, it causes data structures to become larger, and this effect is especially noticeable for small composite types. This is a change from previous Apex releases, where the alignment of a composite type was the LCM of the alignments of the components. If the additional storage consumption is undesirable, the alignment of the type should be explicitly specified.
Alignment of types and objects is described in detail in the Appendix F and Annex M chapters of the Ada Compiler Reference.
Address Clause Alignment Check
The code generated for an address clause now includes a runtime check that the alignment of the specified address satisfies the alignment requirement of the specified object. Program_Error is raised if the check fails, as per RM95 1.1.5(12).
For example, a call to the following procedure will raise Program_Error:
with System.Storage_Elements; procedure Raise_Program_Error is Buffer : String (1 .. 10); function Odd_Address return System.Address is Result : System.Address := Buffer (1)'Address; use System.Storage_Elements; begin if Result mod 2 = 0 then Result := Result + 1; end if; return Result; end Odd_Address; X : Integer; for X'Address use Odd_Address; -- raises Program_Error begin null; end Raise_Program_Error;
Check Name Alignment_Check
An implementation-defined check name, Alignment_Check, has been added as permitted by RM95 11.5(27).
When an address clause for an object is elaborated, a check is made that the specified address is consistent with the alignment of the object. Program_Error is raised if this check fails. The check name Alignment_Check may be used in pragma Suppress to suppress this check.
Checking of Interfacing Pragmas For Composite Types
The checking of the interfacing pragmas (pragmas Import, Export and Convention) has been tightened up to avoid problems when interfacing with other languages. Consider the following example, which was legal in previous versions of Apex:
type Time_Type is record Seconds : Integer; Milliseconds : Integer; end record; type Data_Type is record Id : Integer; Time : Time_Type; end record; pragma Convention (C, Data_Type);The type Data_Type has convention C, and is therefore laid out in a way which is consistent with a C struct: the components are not reordered (they occur in memory in the same order as in the declaration) and the record is 4-byte aligned.
Note however that no pragma Convention was applied to type Time_Type. This type therefore has convention Ada, meaning that Apex is free to use the layout that will give the best performance. On 64-bit processors this type is 8-byte aligned in order to get faster memory access. Unfortunately this 8-byte alignment results in a 4-byte gap between the components Id and Time of Data_Type, which is probably not what the author of the code intended.
Apex now rejects the pragma Convention on Data_Type, stating that type Time_Type does not have convention C. In order for the pragma Convention on Data_Type to be legal, a pragma Convention must also be applied to Time_Type, as follows:
type Time_Type is record Seconds : Integer; Milliseconds : Integer; end record; pragma Convention (C, Time_Type); type Data_Type is record Id : Integer; Time : Time_Type; end record; pragma Convention (C, Data_Type);With this change Time_Type is 4-byte aligned (for compatibility with C) and there is no gap between the components Id and Time of Data_Type.
There is one situation where adding a pragma Convention has a significant effect. Consider the following code:
type Color is (Red, Green, Blue); type Set is array (Color) of Boolean; pragma Pack (Set);This type is bit-packed, and occupies 3 bits in memory. Say that it becomes necessary to specify convention C for this type (presumably in order to be able to specify convention C for a composite type having a component of type Set). The naive way of effecting this change is to add a pragma Convention, as in:
type Color is (Red, Green, Blue); type Set is array (Color) of Boolean; pragma Pack (Set); pragma Convention (C, Set);Unfortunately, the presence of the pragma Convention causes the pragma Pack to be ignored. That's because array components in C must be independently addressable (C does not make much of a difference between pointers and arrays), and pragma Pack is only a hint, which has to be ignored if it conflicts with other requirements.
The correct way to declare a bit-packed array for interfacing with C is to use a component size clause, as in:
type Color is (Red, Green, Blue); type Set is array (Color) of Boolean; for Set'Component_Size use 1; pragma Convention (C, Set);Note however that modular types may be a better way to interface with bit-level data structures in C.
Elaboration Order
The Apex compiler now takes subsystem/view importing information into account when choosing the elaboration order for the units in the closure of the main program. If view A imports view B, then all units of view B which need to be elaborated are elaborated before any units of view A are elaborated (excluding mutual imports and preelaborated units).
The following example formerly raised Program_Error because Text_Io.Put_Line was called after Text_Io had been finalized (in particular, after Standard_Output had been closed):
with Ada.Finalization; package Eo is type T is new Ada.Finalization.Controlled with null record; procedure Finalize (X : in out T); X : T; end Eo; package body Eo is procedure Finalize (X : in out T) is begin Text_Io.Put_Line ("Eo.Finalize called"); end Finalize; end Eo; with Eo; procedure Eo_Main is begin null; end Eo_Main;
- 1 . Eo'Spec
- 2 . Text_Io and all of its friends and relations.
- 3 . Eo'Body
- 4 . Eo_Main
This new prelinker now selects the order and the execution proceeds correctly.
- 1 . Text_Io and all of its friends and relations.
- 2 . Eo'Spec
- 3 . Eo'Body
- 4 . Eo_Main
The decision about whether elaboration checking is to be suppressed for a two-part subprogram is now made when processing the compilation unit containing the first part of the subprogram.
If the spec and body of a subprogram occur in two different compilation units, then any elaboration-check suppression pragmas which occur in the compilation unit of the body have no effect on this decision.
Language.1.ada Removed from Predefined Subsystems
The package language.1.ada has been removed from the predefined subsystems for native platforms. On Embedded platforms, this package was removed in a previous release.
The typical use for language.1.ada was to supply the prefix for C code:
pragma Interface(C, foo); pragma Interface_Name(foo, language.c_prefix & "FOO");
This is now handled through the use of the Ada95 pragma Import, which our compiler also supports for Ada83. With this pragma you no longer need the clumsy mechanism to supply the language prefix.
pragma Import(C, foo, external_name => "FOO");
When using pragma Import, the compiler determines whatever prefix is necessary. Note that you want to specify External_Name for C code, never Interface_Name. Refer to LRM95 Annex B for details.
New Parameter Passing Conventions
Two implementation-defined conventions, Ada_Pass_By_Copy and Ada_Pass_By_Reference, have been added as permitted by RM95 B.1(11). These conventions may be used in pragmas Import, Export and Convention.
These conventions may only be specified for types whose parameter passing mode is not defined by the language (in technical terms, types which are neither by-copy nor by-reference as defined in RM95 6.2(3-9)). They make it possible to select the parameter passing mode. For the purposes of checking the compatibility rules of RM95 B.1(14-19), these conventions are compatible with convention Ada.
If an object of a type having convention Ada_Pass_By_Reference is misaligned, an aligned copy will be created for parameter passing. The address of this copy will be passed to the called subprogram. When this situation arises, the following warning is emitted to inform the user that the address may not denote what she expects:
Specified alignment X is not a multiple of the alignment of the components, Y; this may cause the creation of copies for parameter passing, even though the type has convention Ada_Pass_By_ReferenceIf a composite type contains a subcomponent with convention Ada_Pass_By_Reference, the composite type inherits convention Ada_Pass_By_Reference, unless another convention is explicitly specified for it.
The reason why these conventions have been added has to do with a change in parameter passing for types that are neither by-copy nor by-reference (types for which the parameter passing mode is not defined by the language). In previous versions of Apex such types were always passed by-reference. Consider however a small composite type, for instance:
type Complex is record Re, Im : Float; end record;For such a type, passing by-copy (i.e., in registers in most machines) is considerably more efficient than passing by-reference. Apex 4.2.0 incorporates a heuristic decision that passes types by-copy when the resulting code is deemed to be more efficient.
A parameter of an undiscriminated record type or of a constrained array type will be passed by value if:
- the language allows it (i.e. the type is not a by-reference type) and
- the size of the type (in bits) is known statically, is a multiple of 8, and is <= the size of an address.
Certain rep-specs may also cause a parameter not to be passed by value (e.g. specifying a larger size for an array type than the compiler would have chosen by default).
A parameter of an undiscriminated record type whose size is known statically and is greater than the size of an address may also be passed by value if it consists of <= 3 scalar (or access-to-object, or address-sized access-to-subprogram) components.
An undiscriminated record component may, for purposes of this computation, be "flattened" in some cases. For example, a parameter of type Has_3_Fields (see following) might be passed by value:
type Has_2_Fields is record F1, F2 : Float; end record; type Has_3_Fields is record F1_And_F2 : Has_2_Fields; F3 : Integer; end record;
This "flattening" only occurs if the inner record occurs at the beginning of the enclosing record.
Most users should not have to worry about this change, which will only bring improved code performance. However, in rare situations the body of a subprogram may depend on its parameter being passed by-reference. In this case, the user will have to specify convention Ada_Pass_By_Reference to force the type to be passed as it used to be in prior versions of Apex:
type Complex is record Re, Im : Float; end record; pragma Convention (Ada_Pass_By_Reference, Complex);
In order to make it easier to detect the types for which the convention Ada_Pass_By_Reference may need to be explicitly specified, a warning is emitted if the parameter passing mode has changed since the previous version of Apex:
T is passed by copy, but it was passed by
reference in the previous version of Apex;
this may cause incompatibilitiesIn Apex 4.0 Ada was synonymous with Ada_Pass_By_Reference for purposes of choosing parameter passing methods.
With Apex 4.2, Ada is symonymous, in this respect, with Ada_Pass_By_Copy. In 4.2.0 you do not get any additional passing-by-value if you specify Ada_Pass_By_Copy instead of Ada_Pass_By_Reference.
Pooling of Global Variables
Under previous releases of Apex, each global object was given its own link name. Under Apex , all of the global objects for a given package spec are placed in a single pool and referenced using a single base register (only the single pool object will be given a link name). This allows more efficient code for referencing global data and reduces TOC (GOT) consumption.
Pragma Concurrent_Processing_Policy
A new configuration pragma has been added to control the mechanism used to implement concurrent processing (i.e., tasking). The syntax of this pragma is as follows:
pragma Concurrent_Processing_Policy (policy_identifier)Where the policy_identifier must be one of Interleaved_Processing or Threaded_Processing.
Interleaved_Processing causes the prelinker to use the Rational Exec execution environment to simulate concurrency by using interleaving execution. The entire program runs on a single operating system thread.
Threaded_Processing causes the prelinker to use the underlying operating system's thread library to implement concurrent execution. Each Ada task executes on its own operating system thread.
Some policies may not be supported on some target (although evidently at least one policy is supported on each target).
At most one concurrent processing policy must be specified for the entire program. If no Concurrent_Processing_Policy pragma appears in any of the units comprising the program, the concurrent processing policy for that program is Interleaved_Processing.
The predefined subsystems and the model.ss subsystem do not have separate threaded and non-threaded views anymore. The pragma Concurrent_Processing_Policy is the mechanism whereby the user selects the threaded or non-threaded runtimes. This pragma typically appears in the main program, or in the pragma.1.ada file for the view containing the main program.
Pragma Convention (Intrinsic, Some_Random_User_Routine)
If a convention of Intrinsic is specified for a subprogram whose name is not one of Less, Less_Equal, Greater, Greater_Equal, Convert, Add, Subtract, Modulus, Shift_Left, Shift_Right, Shift_Right_Arithmetic, Rotate_Left, Rotate_Right, Return_Address, then calls to the that subprogram will raise Program_Error.
In the past, the name of the subprogram was interpreted as the linkname of an external subprogram. Note that this does not affect other intrinsic operations associated with Machine_Code when used in a code statement; these operations are affected if they are used in other contexts.
Pragma Suppress_Warning
A new pragma, Suppress_Warning, has been added to provide fine-grained suppression of warnings. In numerous instances the Apex compiler emits warnings to inform the user that some construct in her code might be problematic (e.g., might not work as intended, or might not be portable) or might involve a performance penalty. In general, it is good practice to modify the code so as to avoid warnings. There are situations however where it is impossible or impractical to do so. For instance, when using memory-mapped I/O to access external devices, it might be necessary to use record components with strange sizes and alignments; the compiler might warn that the layout will result in inefficiencies, but there is no way to avoid this (short of changing the hardware, which is generally not an option). The pragma Suppress_Warning provides a solution to eliminate warnings in this situation.
The syntax of this pragma is as follows:
pragma Suppress_Warning (static_string_expression);
Note: Suppress_Warning will only suppress the warnings that are emitted by the semanticist, i.e., at installation time. The pragma will not do anything with coding or link time warnings.
This pragma suppresses any warning that matches the given string expression in the declaration, statement, or pragma that immediately precedes the pragma Suppress_Warning (ignoring any intervening pragmas Suppress_Warning; this makes it possible to attach several pragmas Suppress_Warning to a single declaration, statement or pragma).
For the purpose of determining if a warning emitted by the compiler matches the static string expression given in the pragma, any parameter appearing in the message is ignored. So the warning:
Component clause specifies a field offset of 96 which is not a multiple of the component type's alignment, 64
"Component clause specifies a field offset of 96" & " which is not a multiple of the component type" & "`s alignment, 64"
"Component clause specifies a field offset of " & " which is not a multiple of the component type" & "`s alignment, "
"Component clause specifies a field offset of XX" & " which is not a multiple of the component type" & "`s alignment, YY"
Note however that it is important to preserve the white space around parameters. In general it is recommended to use the message as emitted by the compiler, but the flexibility of omitting parameters is useful for messages that involve data that changes often (e.g., paths). It also makes it possible to define string constants and use them in many occurrences of the pragma, thereby reducing the maintenance effort in case the wording of some message changes in a future release of Apex.
Shared Library Version Numbering
Shared libraries in Apex 4.2.0 have some new controls. There are four new switches that control the new behavior and one old switch whose behavior is slightly different. The new behavior has been named "shared library version numbering". For any given view that produces a shared library, version numbering is either "on" or "off". "Off" is the default value and it causes the familiar pre-Apex 4.2.0 behavior and "on" produces the new behavior.
The SHARED_LIBRARY_NAME switch has been changed slightly. If version numbering is "off" then the change is purely cosmetic. Prior to Apex 4.2.0, the SHARED_LIBRARY_NAME switch had a default value of "lib<subsystem:r:t>.so". For a subsystem xyz.ss this caused the shared library for a view of that subsystem to be given the name "libxyz.so".
The default value has changed and it is now "lib<subsystem:t:r>.<if><view'host_architecture><eq>hppa_hpux<then>sl<else>so<endif>" What this does is produce a name of "libxyz.sl" for HPPA and a name of "libxyz.so" for all other targets.
With version numbering "off", this switch determines the name of the shared library file. With version numbering "on", this switch determines the name of a symbolic link that will point to the actual shared library file. Otherwise the use of this switch is unchanged. Except when there are multiple versions of the shared library file present in a view, the old functionality and the new functionality are indistinguishable.
There are four new switches that govern shared library version numbering.
SHARED_LIBRARY_VERSIONING: on/off SHARED_LIBRARY_VERSION_NUMBER: <number> SHARED_LIBRARY_VERSION_RETENTION: -1, 0, 1..N SHARED_LIBRARY_VERSION_NAME:lib<subsystem:t:r>.<view'switch (SHARED_LIBRARY_VERSION_NUMBER><if><view'host_architecture><eq>hppa_hpux<the n>sl<else>so<endif>Version numbering is turned "on" or "off" by SHARED_LIBRARY_VERSIONING. The default value for a view is "off". (It can also be set to "true"/"false" or "1"/"0".) When version numbering is "off", the other three switches are ignored.
SHARED_LIBRARY_VERSION_NUMBER is a simple number, of any Integer value. It is automatically incremented every time a version numbered shared library is created in the view. It is used to give each created library file a unique identity.
SHARED_LIBRARY_RETENTION is a simple number, of any Integer value. When negative (-1) it is interpreted as meaning "keep all old versions". When zero (0) it is interpreted as "keep no old versions". When positive (1..N) it is interpreted as "keep this many old versions". When a new version numbered shared library is created in a view, existing library files in that view are either kept or deleted according to their relative ages depending on this switch. Prior to Apex 4.2.0, the new library always replaced the old library.
This was the same as a value of zero (0) for this switch. It is possible to preserve any number of prior versions of the library being created. This allows programs linked against those prior versions to continue to operate.
SHARED_LIBRARY_VERSION_NAME determines the name of the actual shared library file when version numbering is "on". For example, using the default switch value, the name of the library file will be "libxyz.123.so" if the subsystem is xyz.ss and the incremented SHARED_LIBRARY_VERSION_NUMBER is 123. A symbolic link is also created pointing to the actual shared library file. The name of that symbolic link is controlled by the SHARED_LIBRARY_NAME, "libxyz.so" in this example.
As an example, imagine a view named /disk/space/xyz.ss/project.wrk that has these Policy/Switch values:
SHARED_LIBRARY_NAME: lib<subsystem:t:r>.so SHARED_LIBRARY_VERSIONING: on SHARED_LIBRARY_VERSION_RETENTION: 1 SHARED_LIBRARY_VERSION_NUMBER: 23 SHARED_LIBRARY_VERSION_NAME: \ lib<subsystem:t:r>.<view'switch(SHARED_LIBRARY_VERSION_NUMBER)>.soIf there are no shared library files currently present in the view:
- The next time a shared library is created in the view:
- the version number switch value will be incremented from 23 to 24
- a new shared library file named libxyz.24.so will be created
- a new symbolic link libxyz.so -> libxyz.24.so will be created
- The time after that:
- the version number switch value will be incremented from 24 to 25
- a new shared library file named libxyz.25.so will be created
- the symbolic link will be changed to libxyz.so -> libxyz.25.so
- The time after that:
- the version number switch value will be incremented from 25 to 26
- the shared library file libxyz.24.so will be deleted
- a new shared library file named libxyz.26.so will be created
- the symbolic link will be changed to libxyz.so -> libxyz.26.so
System Address
In this release, System.Address is now a private type implemented as an access type. In previous releases, it was a private type implemented as a modular type.
This means that default initialization is now performed in cases where it was not previously performed. For example,
X : System.Address;
X will now be initialized to null whereas before it would have been uninitialized.
One place where this can make a difference is when using address clauses. In this example
type R is record F1 : Integer; F2 : Float; F3 : System.Address; end record; procedure P (X : System.Address) is R_Var : R; for R_Var'Address use X; begin ... end P;
R_Var.F3 will be set to null. To suppress this default initialization, it is necessary to add
pragma Import (Ada, R_Var);
either after the declaration of R_Var or after the address clause.
Time Type Configuration
Apex represents the values of the types Ada.Real_Time.Time and Ada.Calendar.Time as 64-bit counts of Ada.Real_Time.Time_Unit. On 32-bit platforms, arithmetic on these types is done using software implementations off 64-bit operations. THese operations are much slower than integer operations provided by the hardware, particularly 64-bit multiplication and division. This reduces the performance of Time arithmetic and other operations that use it.
Some conversion operations in Ada.Real_Time are particularly slow, since they are implemented with 64-bit multiplication and division: Split, Time_Of, To_Duration, and To_Time_Span. These may be used implicitly, as when using the Calendar."-" operation to subtract two time values to obtain a duration value. The 64-bit subtraction is relatively fast, but it produces a Time_Span value; this must then be converted to Duration, which is much slower.
None of these conversion operator produce 64-bit results, and so do not need the full 64-bit arithmetic. The 56 bits of precision provided by double precision floating point is adequate. All the native platforms supported by Apex provide hardware which implements floating point operations that are much faster than 64-bit software integer operations. Apex now reimplements the Ada.Real_Time conversions listed above using floating point operations. This results in greatly increased performance for them and other Time operations that use them.
Note: This does not affect Apex embedded products since they cannot assume floating point hardware on the target platform.
Thread Concurrency
Most implementations of POSIX threads provide an extension allowing applications to provide the OS with a "hint" regarding the desired level of concurrency. This usually influences the mapping of threads to underlying kernel entities (e.g. Solaris LWP, SGI sproc) which control the actual allocation of hardware processing resources.
The Apex runtime provides several interfaces to specify the desired concurrency for threads used to implement Ada tasks. For Solaris, one of these is the environment variable ADA_CONCURRENCY_LEVEL. The value of this variable is interpreted as a number and passed to the OS interface thr_setconcurrency().
In Apex 3.2.0b, the code interpreting ADA_CONCURRENCY_LEVEL was left out, so the Apex runtime ignored the environment variable. It has been restored in this release.
This mechanism was developed for Solaris threads when it was the only threads platform supported by Apex that provided this interface. Most of the newer POSIX threads implementations now supported provide this interface, so it is now available for most threaded platforms.
Volatility
Compiler support is added for the case of declaring a volatile scalar object which is subject to an address clause
Multithreaded Ada Mutex Locking Policy Emulation
The Apex multithreaded Ada runtime, implemented over POSIX threads, provides an emulation of the POSIX_THREADS_PRIO_PROTECT (priority ceiling) mutex locking policy if it is not implemented by the operating system. This provides support for the Ada Ceiling_Locking polity defined in the Real Time Annex (Annex D). In Apex 3.2.0b, this emulation was implemented incorrectly. When a priority ceiling mutex was unlocked, for example, when leaving a protected object compiled with pragma Locking_Policy (Ceiling_Locking), the priority of the calling task was reset to its active priority at the time the mutex was locked. This is not necessarily correct. If the base priority of the task had been changed in the meantime, and if the mutex being unlocked is the last priority ceiling mutex held by the task, then the new base priority should become the active priority, not the base priority at the time that the mutex was originally locked. This is what currently occurs.
Interface to ANSI C and K&R C - Change in Default
The interface to both ANSI: and K&R C is now supported. In previous releases, Apex supported whichever was the standard for the system .h files.
The ANSI dialect is now the default. To specify otherwise, use pragma Import_Directive. This pragma can be included in pragma.1.ada to set the default to K&R.
pragma Import_Directive (Pre_Ansi).
It is also possible to control individual references. For example,
procedure P; pragma Import (C, P); pragma Import_Directive (P, Pre_Ansi);
Single Rada and COMPILER_TOOLS_PATH
Apex 4.0.0 and beyond uses a unified rada. This means that the rada executable supplied with the native Apex product is the same one used to code files under the embedded Apex product. Implementing this change resulted in several changes that may effect customers.
How to Invoke rada
Under normal circumstances, rada is not invoked directly. Instead, users should invoke the specific rada functionality: analyze, clean, code, disassemble, link, migrate, parse, or pretty_print. For example,
% apex code ...
Passing special options to rada
In general, options specified in the Apex documentation are known to the command interpreter (apex), and can be used directly on the command line. For example,
% apex code -option
In rare cases, you may need to pass a special option to rada that the command interpreter does not recognize. In these cases, you will need to preface the option with -cmd_options. For example
% apex code -cmd_options -special_option ...
Determining what tools rada is using
Starting with Apex 4.0.0, the target-specific tools used by rada (for example, apex_ada_cg_phase, apex_ada_optim_phase) are no longer on your path. Instead Ada views contain a COMPILER_TOOLS_PATH switch (in the Policy/Switches file). By default, this switch is set to a single directory containing target-specific tools.
The COMPILER_TOOLS_PATH value is not normally on the user's path. When rada is invoked, it prepends the COMPILER_TOOLS_PATH value to the $path before invoking tools.
To determine which tools rada is using, the user can invoke rada indirectly from an Ada view with the -show_tools option. For example,
% apex code -show_tools /full/path/to/rada /full/path/to/apex_ada_optim_phase /full/path/to/apex_ada_cg_phase
COMPILER_TOOLS_PATH Switch
The COMPILER_TOOLS_PATH switch is used by the Ada compiler and other Apex tools to locate target-specific versions of each tools. It can be specified on the command line as -compiler_tools_path <list of filesystem directory pathnames> the Policy/Switches file as COMPILER_TOOLS_PATH: <list of filesystem directory pathnames>. The list of pathnames must be separated by ":"s (same conventions as $PATH.)
The COMPILER_TOOLS_PATH switch is specified in the Ada model. It is copied from the model into the Ada view a view creation and any time an apex remodel -update or -replace_switches command is invoked on the Ada view.
The default value is set by the Ada model being used.
Creating C/C++ Executables Linked with Ada Subroutines
It is now possible to create a C/C++ executable that is linked with Ada subroutines. This is described in Programming with Apex.
Miscellaneous Changes
The following additional changes have been made to the Ada compiler.
- Improved Implementation of controlled types
The compiler now eliminates certain finalize/adjust pairs as per AI95-00083. The compiler is able to transform dispatching calls into direct calls in more cases than it could before, resulting in more efficient code.
- Improved stream operator performance
The RM states that the predefined streaming operations of a structured type must handle each component separately. For example, calling Standard.String'Write with a value of length 10 must result in 10 dispatching calls to Ada.Streams.Write. AI95-00195, item #9, relaxed this requirement and the compiler now takes advantage of this freedom. When it is possible, Stream operations on structured types now treat the structured object as a whole instead of decomposing it into its components.
- Support for package Simple_Io.
Ada Object Editor
Coloring
The default Ada object editor now does both language coloring and "as you type casing". These can be turned off by setting the APEX_NO_ADA_LANGUAGE_MARKS and APEX_NO_AS_YOU_TYPE_CASING environment variables to true.
The casing is consistent with the pretty printer switches. Currently only the Ada object editor does language coloring. The C/C++ editor does not do this.
The new color scheme is consistent with the color scheme used with Apex NT and with other environments such as MSVC++. Language constructs (keywords, strings, comments, etc.) have a foreground color with a white background while messages and prompts have a background color and a white foreground.
Here are the default settings for the common constructs:
Delimiter Alignment
The Apex Ada editor now supports delimiter alignment. Delimiter alignment is an option of the pretty-printer, which causes lexical delimiters to be vertically aligned to improve readability of the source code.
Delimiter alignment is controlled by the boolean context switch ALIGN_DELIMITERS. This switch defaults to False. To enable delimiter alignment, the switch must be set to True by editing the switch file for the appropriate view(s):
ALIGN_DELIMITERS: TrueOnce this switch has been set, the pretty-printer (invoked either by Compile:Pretty Print or by Compile:Syntax) will automatically perform delimiter alignment.
Expansion and Elision in the Completion Window
By default, the completion window shows each possible completion on one line, abbreviating it if necessary by adding ellipsis near the end of the declaration. This is convenient in most cases, as the abridged form is sufficient to select a completion, but it can become ambiguous for subprograms with long parameter parts. For instance, say that we are completing the call to P below:
procedure P (A : Integer; B : Integer; C : Integer; D : Integer; E : Integer; F : Integer; Z : Float) is separate; procedure P (A : Integer; B : Integer; C : Integer; D : Integer; E : Integer; F : Integer; Z : Boolean) is separate; begin P;The completion window that is brought up only shows the first four parameters of each subprogram.
The parameter Z, which is the only one that helps disambiguate the two subprograms, is not displayed, so it is hard to tell which of the entries in the completion window corresponds to which declaration. (The entries in the completion window are listed in the other in which they appear in the source code, so this gives a way to disambiguate, but in real programs this is rather awkward.)
It is now possible to use the Expand button to expand entries in the completion window. The parameter Z is now visible. Of course, the second entry could be expanded as well for maximum readability.
Hitting Complete on any of the entries will cause completion to happen with the desired declaration.
Once an entry has been expanded, it is possible to revert to the abbreviated, one-line description by using Elide.
Multiple Completion
When a completion window presents choices for completing several constructs, it was only possible to complete one of the constructs. This made it necessary to run completion over and over again, dealing with one construct at a time.
The completion window has been improved: it is now possible to select (at most) one completion for each construct, and have all of them completed in one fell swoop. For instance, say that the lines containing the calls to P and Q below are selected, and Complete is hit:
procedure P (X : Integer) is separate; procedure P (X : Float) is separate; procedure Q (X : Boolean) is separate; procedure Q (X : Integer) is separate; begin P; Q;The following completion window is brought up. Now say that the first completion is selected for P and the second is selected for Q:
After hitting Complete on the completion window, the two subprogram calls are simultaneously completed:
procedure P (X : Integer) is separate; procedure P (X : Float) is separate; procedure Q (X : Boolean) is separate; procedure Q (X : Integer) is separate; begin P (X => [FLOAT-expression]); Q (X => [INTEGER-expression]);Semantic Completion Dialog
Semantic completion in the Ada object editor can now be configured using the Completion Options dialog box. This dialog is displayed if the Control key is depressed while selecting Compile > Complete. The discussion of semantic description in Programming Using Apex has been improved and the new dialog is described in detail in the Online Reference.
Runtime
Fixed Point Rounding
The fixed point multiplication, division and conversion operations used to ROUND the result to the nearest machine representable number when the operation was executed at runtime, but it used truncation when the result was computed at compile-time. The Apex 4.2.0 compiler now uses truncation uniformly. For example:
type Fixed is delta 1.0 range 0.0 .. 100.0; X1 : constant Fixed := 17.0; Y1 : constant Fixed := X / 3.0; X2 : Fixed := 17.0; Y2 : Fixed := X2 / 3.0; Z : constant Boolean := Y1 = Y2;
would yield False for earlier versions of Apex and will yield True for the Apex 4.2.0 release. Under older versions of Apex Y1 = 5.0 and Y2 = 6.0. Under this release, both Y1 and Y2 will have the value 5.0.
Pragma Suppress
When a runtime check is suppressed using pragma Suppress (<check name>), the compiler not only omits the code to perform the check, but now assumes that the check would have passed. This assumption allows the optimizer to make the same inferences about the code as when then checks were present thus preventing code quality degradation in some cases when checks are suppressed.
In the case that a check would fail, RM 95 11.5(26) states:
If a given check has been suppressed, and the corresponding error situation occurs, the execution of the program is erroneous.
By assuming that suppressed checks will always pass, the Apex 4.2.0 compiler has changed the behavior of some erroneous programs. For example, it is dangerous to declare the size of an imported (variable size) array to be one:
X : array (1 .. 1) of Integer; pragma Import (C, X); ... procedure P (I : Natural) is pragma Suppress (Index_Check); begin X (I) := 17; end P;
will always update the first element of X regardless of the value since the optimizer is allowed to assume that then index check (I in 1 .. 1) will pass. In earlier releases of Apex, the compiler would (typically) generate code to update the Ith element of X.
Task Naming
Apex now systematically assigns a short, unique prefix to task names. The full task name (including the prefix) can be obtained at execution time from Ada.Task_Identification.Image. This name is also passed to LynxOS when the thread implementing the task is created, allowing the names to be displayed with the LynxOS ps command using the -t option.
The OS truncates the full task names, but the unique prefix will usually be visible. The debugger now provides a task_id flag that can be set to display these names using the lt command.
Further details can be found in the "Tasking" chapter of Using the Ada Runtime.
For Apex Solaris 4.0.0b native, the Ada runtime now checks for insufficient stack space to meet the requirements for stack space size as requested by either "pragma Main(Stack_Size => ...);" or by the configuration table parameter V_Usr_Conf.Configuration_Table(Main_Task_Stack_Size). Solaris does not allow a process to change its own stack size limit, so the solution we chose is to emit the following warning when the current stack space is insufficient:
Ada runtime warning: This program has been configured to request xxx bytes of stack space either via V_Usr_Conf.Configuration_Table.Main_Task_Stack_Size, or via pragma Main (Stack_Size => ...). However, the current stack size cannot be increased beyond what was set by the parent process, which is currently xxx bytes.
If you are invoking this program from the shell, use the command `limit stacksize yyy' to increase the stack limit before running this program.
Otherwise, in the parent process, before invoking this program, use the system call setrlimit(2) as follows: setrlimit(RLIMIT_STACK, xxx);
(Where xxx is the number of bytes, and yyy is the number of kbytes)
Note that this message tells you the csh or tcsh command to use, not the sh, ksh, or bash command, which would be "ulimit -s yyy"
When assigning a priority to a task in the threaded runtime, Ada priorities are translated to POSIX priorities by transposing the Ada priority range into that of the scheduling policy of the underlying thread. However, this is not done when assigning a ceiling priority to a PTHREAD_PRIO_PROTECT mutex. This leads to unexpected behavior.
User Interface
The File > Run and File > Debug dialogs have been combined into one dialog. The new unified dialog has pages to select between running and debugging. Use the Run page to run a program. Use the Debug page to debug a program. The menu items have not changed. For example, selecting File > Debug will bring up the new dialog with the Debug page selected.
The Debugger Tasks window contains three new buttons: Default, Full, and Stack Usage. You can select all tasks, or a single task, then one of these buttons to change the format of the Task window display. Default corresponds to the simple lt case. Full corresponds to the lt all | <task number> (lt all or lt 5). Stack Usage corresponds to lt use or lt use 5.
The Debugger Session check box has been removed from the File > Debug dialog.
The descriptions of the options from the Print dialog have been corrected The Raw option has been added and Postscript has been changed to Formatted to match the actual entries on the dialog.
The Show Unused and Show Usage dialogs have changed extensively. These changes are also reflected in a new set of options for the show_unused and show_usage commands. These commands are documented in the Command Reference.
The "tear off" menu feature for Apex is no longer available. Apex 4.0 switched to using Motif 2.1 instead of 1.2. Motif 2.1 recommends against enabling tear off on shared menus.Motif strongly discourages it, suggesting that the user may encounter severe problems.
Apex Shadowing
A new context switch, REMOTE_CONTEXT_COMPLETION, is used when shadowing is enabled. It allows the view to specify a remote context relative path.
Currently the remote context is either specified directly in the shadow switches, or if USE_CONTEXT_AS_BASE is set, then the <subsystem_path>/<view_name> is append to the remote context.
Both switches are supported, but the new switch takes precedence over the old switch (the new switch can achieve the same thing as the old switch "<view>:s:r/<view>:t:r")
Summit/CM
Bill of Materials Command
A new command, apex_BOM, enables you to obtain a bill of materials from an Apex build if the Summit/CM configuration management system is being used. This command supports the generation of a Version Description Document. This command is described in detail in the Command Reference.
New Command Options
The abandon, control, set_history, and set_version commands now accept the -no_artifacts option. This option specifies that compilation artifacts should not be [abandoned, controlled, or set] with the source files. The default value is false.
The -goal <goal_state> option has been added to the copy command. The new objects will be copied along with artifacts appropriate to the goal state.Units in the new views are compiled to the requested state as required, except in the case of preserve, which preserves the original state but does not perform any recompilation. The default value is preserve.
Tools
Reporting Problems to Apex Technical Support
A new version of the rreport tool is included in this release. This tool enables Apex customers to more easily and quickly report problems and suggestions to Apex Technical Support.
The rreport tool asks the customer for the problem description and automatically includes required Apex data (version, patches, installation log) to the report sent to Apex support. In addition, a service request is automatically created when rreport is used to report problems/make suggestions to Rational Software.
Apex Disassemble
The apex disassemble command has changed where it puts the assembly files. The new default location is in the source directory next to the .ada files. Two switches can modify this new default behavior.
- APEX_DISASSEMBLY_HIDDEN=True
Reverts to the default behavior for previous releases. The.asm file is placed in the corresponding subdirectory of .Rational/Compilation.
- APEX_DISASSEMBLY_DIRECTORY=<pathname>
Places the .asm file in the named directory. This switch overrides APEX_DISASSEMBLY_HIDDEN.
Apex Trace
Support for call-return and basic block tracing has been removed from the Tasking Logic Analyzer product (apex_trace). Only runtime event tracing is now supported.
Documentation
Changes in Hard-Copy Documentation
The Rational Apex documentation set has been simplified. No longer are there separate manuals for each variant of Apex (Ada, C/C++, Duo). Where there is information that is specific to only a single variant, it is clearly labelled in the documentation.
Many of the titles of the Apex manuals have been changed to adhere to the Rational standards for manual titles. In addition, the manuals are now formatted using the standard Rational templates.
User Interface Changes in Help Files
In the online help system, a link to the Technical Support Solutions has been added to the HTML help files. The Solutions provide additional, in depth information on the Rational Apex product.
The Version button has been removed from the online help files. To view Version information, click Help > On Version.
RCI
Licensing
RCI is being removed from the Rational price list. RCI is considered to be part of the base Apex product and will now be supported as part of the standard Apex product. Licenses for RCI are issued as part of the normal set for both Apex Native and Apex Embedded products.
ClearCase support
- RCI is fully supported in an Apex/Clearcase environment.
In such a context, Rational (.rss) subsystems may be created with an RCI model, and have an associated RCI target directory.
The File > New Subsystem dialog has an RCI tab, which allows specification of the usual RCI options (host-only view, target machine name, target directory context and name) for creation of the RCI target directory.
- An RCI .rss subsystem may be controlled under ClearCase, just like any other .rss subsystem.
RCI itself has no provision for controlling the associated target directory, which will typically be managed as a non-controlled, view-private object.
If the target directory is to be controlled, this will have to be managed explicitly by the user, or by the RCI customization scripts (which will have to be adapted to handle the ClearCase actions associated to the creation/deletion of a target library or target unit).
- When operating on .rss subsystems, the RCI > Create Target Library and RCI > Delete Target Library dialogs have, in the same manner as other Apex dialogs (Remodel, Add Import), a button Check out/in Artifact files, to perform checkout/checkin of the subsystem's Policy/Switches file.
This allows the target library creation/deletion process to update the RCI specific switches in the switch file.
RCI also has a provision for managing the RCI specific switches in a separate, view-private file, rather than in the controlled default switch file:
The RCI model view for the customization should then be set up so that:
- The RCI switches are moved from its Policy/Switches file to a Policy/RCI.sw file;
- The Policy/Switches file does an `INCLUDE_OPTIONAL: RCI.sw'.
This setup will then be automatically propagated to any RCI subsystem created from this model.
Note: To support this usage model, the RCI customization scripts should be updated to take into account the Policy/RCI.sw file, if it exists. This is the case for the sample customizations provided with this release.
Changes that may affect existing customizations
Existing RCI customizations, that work with previous releases of Apex, will have to be slightly adapted, to take into account the following changes in Apex 4.0.0b:
- OMS/CMVC version
The value of the OMS/CMVC version parameter that is passed to most RCI customization scripts, has changed to 1.2. This value is typically tested in the test_version script, that should be adapted to accept the new value.
- Clean operation
The clean customization script should no longer use the rada_clean command. It should instead call rada -clean.
- Post_Create_View parameters
The post_create_view customization script should now handle, in addition to the existing -rci_target_directory parameter, the new parameters -rci_target_context, -rci_default_target_context and -rci_default_target_directory.
This interface change was needed to support the new scheme introduced in this release for handling target library specifications (see below).
Please refer to the sample customizations provided with this release for examples of the updated test_version, clean and post_create_view scripts.
Handling of target library specifications
In previous Apex releases, in the File > New View, File > Copy (View) and RCI > Create Target Library dialogs, the RCI target "context" and "library name" specified by the user were combined by the dialog itself to generate a target directory pathname which was passed to the underlying Apex or RCI command.
This scheme had serious drawbacks when the target system was not the same as the host system, especially if the target system was not a UNIX system.
Starting with this release, the context and directory name specified by the user are passed unmodified from the dialog, through the underlying Apex or RCI command, all the way to the RCI post_create_view script, which may then interpret its -rci_target_directory and -rci_target_context parameters and compose them according to the target OS file naming rules, to generate the resulting RCI_TARGET_DIRECTORY name.
Also, when a "default" context or library name is selected by the user, this information is passed to the post_create_view script (-rci_default_target context and -rci_default_target_directory boolean parameters), which may then synthesize default values as appropriate for the customization.
Upgraded sample customizations
The Ada83 VADSself and Ada95 GNAT sample customizations delivered with RCI have been upgraded in various aspects in this release.
Support for new versions of target compilers
The VADSself customization now targets version 6.2.3d of VADSself Solaris.
The GNAT customization now targets version 3.12p of GNAT Solaris.
New setup for predefined views
The mapping of predefined units for the target environment to the $APEX_BASE/ada/xxxx.ss subsystem views for the sample customization has been reorganized, to have a setup similar to that of the standard Apex predefined views.
- VADSself customization
The VADS predefined units (from the VADS standard library) are now distributed across an lrm.ss view and a (new) predefined.ss view (the lrm.ss view contains the minimal set of units required by Apex).
The units from the VADS verdixlib library remain in the VADS specific verdixlib.ss view.
- GNAT customization
The GNAT predefined units (from the GNAT adainclude directory) are now distributed across an lrm.ss view, a predefined.ss view, and views in the standard Apex subsystems for Ada95 annexes: distributed_systems.ss, information_systems.ss, numerics.ss, realtime_systems.ss, and systems_programming.ss.
The lrm.ss view contains the minimal set of units required by Apex, and the Ada95 annex subsystem views contain the relevant units, according to the distribution outlined in RM 95 A (2).
Revised customization scripts
The scripts provided in the $APEX_BASE/ada/keys/rci_xxx compiler key directories for the sample VADS and GNAT customizations have been extensively rewritten:
- to be more suitable for `as is' usage of the sample customizations.
- to provide a more robust and complete reference base to build other customizations.
RCI customizers are strongly encouraged to study these sample scripts and use this new base for evolutions of their own customizations.
The scripts now have a more homogeneous format and coding style.
Comments have been revised, to better document the purpose of the scripts and the conditions where they get called.
Areas of the scripts that may need to be adapted for a new customization ("CUSTOMIZABLE CODE" boxes) have been more systematically identified and documented.
To encapsulate actions repeatedly performed by customization scripts, a number of utility scripts have been added, among which:
- get_switch and set_switch, to get/set the value of a RCI view switch. These scripts transparently handle the case where a RCI view has an RCI-specific switch file.
The set_switch script replaces the previous set_state_value script.
- get_op_spec, to get the value of an operational characteristic from the rci_op.spec specification file.
- download and upload, to perform file transfer operations between the Apex host and the target compilation host.
- build_comp_command and build_link_command, to generate target compile or link command lines, based on the compiler key xxx_option_line and xxx_option_symbol templates and the view's xxx_option_file. The rci_post_build_script script, to generate batch mode scripts, now uses these utility scripts.
As a result, most of the scripts are now common between the VADS and GNAT sample customizations,
The sample customizations now come with an interactive setup script, which may be used to automate the setup of the customization for the local installation of the target compilation system (see the README file provided in the customizations' compiler key directory for details).
Guidelines and Restrictions on Using Rational ApexThe known limitations of Apex 4.2.0 B are described below. Workarounds are included where applicable.
Ada Compilation System
Running Apex binaries compiled on Solaris 2.7 under Solaris 2.6
New releases of operating systems usually provide several forms of backward compatibility. In particular, it is often possible to run binaries compiled for an older version of the OS on a new release. Running binaries compiled for the newer version of the OS on the older version may also be possible, though it is not usually supported and may cause problems.
Solaris 2.7 binaries in particular can often be run using Solaris 2.6 with varying degrees of success. However, binaries that make use of POSIX 1003.1b Real-Time Extensions will fail immediately for lack of the shared librt.so library with a message like:
swift% driver_900042 ld.so.1: driver_900042: fatal: librt.so.1: open failed: No such file or director Killed
Here librt.so.1 is the particular version of librt.so on this machine. A soft link from librt.so to librt.so.1 is provided in /usr/lib to direct the linker to the latest version of this library. Note that the linker looks through the soft link, including the name of the actual library file rather than the link in the resulting application binary. The Solaris 2.6 equivalent to this library is libposix4.so. Solaris 2.6 binaries using libposix4.so will work on Solaris 2.7, since a soft link from libposix4.so to librt.so is provided in /usr/lib. Apex always links against the name libposix4.so to support Ada.Calendar and other time related features, but again the linker looks past the soft link to the name of the library binary itself. Those linked on Solaris 2.7 will therefore attempt to load librt.so when executed. Under Solaris 2.6 this will fail since there is no library of that name.
In general it is best to avoid running Solaris 2.7 binaries on 2.6. However, this particular problem can be avoided by providing a link visible to the loader from the name needed by the binary to /usr/lib/libposix4.so. The easiest way to do this is to add the appropriate link in /usr/lib. For the example above:
cd /usr/lib ln -s libposix4.so librt.so.1
This requires superuser privileges. In the absence of such privileges, any directory can be used by adding it to the LD_LIBRARY_PATH environment variable:
cd $HOME mkdir lib.2.7 cd lib.2.7 ln -s /usr/lib/libposix4.so librt.so.1
To make this visible to the loader, execute
setenv LD_LIBRARY_PATH $LD_LIBRARY_PATH\:$HOME/lib.2.7
If you are attempting to run the application outside of an Apex shell,
LD_LIBRARY_PATH may not be defined, in which case you should substitute:
setenv LD_LIBRARY_PATH $HOME/lib.2.7
Ada 95 Unimplemented Features
The following Ada95 features are not implemented in the Apex 4.2.0 B compiler:
- Discriminant-dependent entry families for tasks (RM95 3.7.1) and protected records (RM95 9.4):
task type T (D : Natural) is entry Nyi (1 .. D); -- Not yet implemented. entry Ok (1 .. 10); -- Ok, not discriminant- -- dependent. end T;
- Bit_Order attribute (RM95 13.5.3).
- Annex B
- Interface to COBOL (RM95 B.4)
- Interface to FORTRAN (RM95 B.5)
Fortran-convention multi-dimensional array types are represented in column-major format instead of the usual row-major. The predefined type Interfaces.Fortran is provided, although the package Interfaces.Fortran.Logical is not declared.
- Annex E: Distributed Systems
- Not supported.
- Annex F: Information Systems
- BCD decimal types (RM95 F.1)
- Package Ada.Decimal (RM95 F.2)
- Package Ada.(Wide_)Text_Io.Editing (RM95 F.3)
- Annex H: Safety and Security
- Pragma Normalize_Scalars (RM95 H.1)
- Pragma Reviewable (RM95 H.3.1)
- Pragma Inspection_Point (RM95 H.3.2)
- (Note: Most restrictions in H.4 are implemented)
Ada 95 Known Limitations
- Atomic/Volatile pragmas (RM95 C.6) are only supported for scalar types.
- Volatile/Volatile_Components pragmas (RM95 C.6) do not necessarily force every read/write of a volatile object to be performed to memory.
- Optimize (Off) pragma does not disable all optimization of a subprogram when the enclosing view has an optimization level greater than zero.
- Discard_Names pragma (RM95 C.6) has no effect.
- Initialization and exceptions (RM95 7.6.1).
When the initialization of an object of a controlled type (or one containing controlled components) is abandoned due to an exception or an abort, the already initialized subcomponents are not finalized. (Any top-level object that has been completely initialized WILL be properly finalized when an exception or abort causes the scope to be exited).
procedure P is type T is record F1 : A_Controlled_Type; F2 : Natural := -1; F3 : A_Controlled_Type; end record; X : A_Controlled_Type; Y : T; Z : T; begin -- Execution does not reach this point -- because an exception is raised during the -- initialization of the field Y.F2. -- The object X (which has been completely -- initialized) will be finalized. -- The field Y.F1 (which was successfully -- initialized) will not be finalized. end P;
- Initialization and elaboration (RM95 7.6.1).
When the elaboration of a main program is abandoned due to an exception (or an abort), any units that were successfully initialized will not be finalized. Once the main program has been fully elaborated, if its execution is abandoned, then all of the units in the closure will be properly finalized.
- Streams (RM95 13.13).
- Objects of type Ada.Exceptions.Exception_Occurrence cannot be streamed.
- Objects of an access-to-subprogram type cannot in general be streamed using the default compiler-generated stream routines. When the access type is declared at static scope (not nested within a subprogram) then compiler-generated routines will work on platforms other than IBM.
- When using a representation clause to override the default compiler-generated streaming routines for a tagged type, it is necessary to override all four ('Read, 'Write, 'Input, and 'Output).
- Data validity (RM95 13.9.1).
In some cases the compiler erroneously assumes that the value of an object lies within the bounds of its subtype. For example, the value of an uninitialized scalar object may not be a valid representation for an object of that type. In the Ada95 standard this is a bounded error that is not always caught by the current Apex implementation.
- When using a user-defined storage pool for access type, the alignment parameter passed to the storage pool's Allocate procedure will always be "double-word aligned" (that is to say, 8 bytes on most architectures) instead of the alignment of the designated type as specified by the LRM. The Apex storage management routines require that the user Allocate procedure honor the alignment passed (8 bytes).
- "Per object" alignment and size clauses are not supported for objects of floating point, access, or task types.
SPARC V9 Solaris 64-bit C/C++ Profiling
For Sol64, prof is not supported; only gprof is supported by Sun. In order to be able to profile a C/C++ program using the Apex C/C++ compiler, RCC, you must obtain the64-bit version oft he gprof run-ime object gcrt1.o and copy it over to the sol64 RCC area (CPP_COMPILER_HOME/self/lib). If you do not do this, the link will fail. Once the 64-bit version of gprof is in place, profiling support via gprof is complete for the Sol64 product.
This also applies to profiling mixed Ada/C/C++ programs with Ada/C++ as main (where RCC is doing the final link.) You must obtain the 64-bit "gcrt1.o" for the link to be successful.
Runtime
After setting the UNIX signal mask using V_Interrupts, executing a DELAY statement will corrupt the signal mask. Workaround: Remove the DELAY statement.
The following session switches are not supported:
APEX_TASK_PRIORITY_DEFAULT
APEX_TASK_STACK_SIZE_DEFAULT
AEPX_TIME_SLICE
APEX_STACK_SIZE
APEX_SIGNAL_STACK_SIZEThe Rational Ada runtimes do no support the fork() system call as a mechanism for creating a process. The posix.ss subsystem supports the industry standard bindings to POSIX which includes Posix_Process_Primitives.Start_Process, as the recommended way to create a new process from an Ada program.
Libraries
The multiplication function in the complex arithmetic package in $APEX_BASE/vads_compatibility.ss/.../verdixlib is incorrect. It incorrectly assumes that values of equal magnitude are equal, even if the signs are not. This results in incorrect values. Therefore (2,2) * (2,-2) yields (0,8) when it should yield (8,0). In Ada 95, Rational strongly recommends that you use the complex arithmetic implementation in $APEX_BASE/ada/numerics.ss.
The return code from procedure $APEX_BASE/vads_compatibility.ss/.../verdixlib/unix_calls.open is documented backwards. The routine returns True if there is an error and False if it succeeds.
Interfacing with C
When generating code for a function with a 32-bit floating point result, the Rational C compiler promotes the result to a 64-bit representation.
On targets which support 32-bit floating point registers, for example, Sun and SGI, this is incompatible with the conventions of the platform vendor's C compiler. On other targets, such as Dec Alpha, this promotion has no effect because all floating point results are returned in 64-bit registers.
The Rational Ada compiler expects C functions to follow the conventions of the platform vendor's C compiler. This means that the following example executes correctly if the .c file is compiled with the vendor's C compiler and fails on targets such as Sun and SGI if it is compiled with the Rational C compiler.
float foo () { return 3.0 ;} procedure Maine is function Foo return Float; pragma Import (C, Foo, External_Name => "foo"): begin if Foo /= 3.0 then raise Program_Error; end if; end Maine;
Workaround: Use 64-bit floats instead of 32-bit floats on those platforms for which this is a problem.
ASIS
The test install of ASIS is very slow. Link time takes up the bulk of the test install time. Link time can be reduced by a factor of 10 if the link is performed on the same machine that owns the disks on which the ASIS views are installed.
Optimizer
The optimizer assumes infinite precision for floating point operations. This is a problem in some cases. For example, if you have the expression
while x + 1.0 /= 1.0 loop
and x is continually reduced towards zero, the expected result is that when the value of x drops below float_type'EPSILON, the comparison will become false (i.e., x + 1.0 will equal 1.0). The optimizer assumes an infinite precision for x, such that even float_type'SMALL +1.0 /= 1.0. This is incorrect per LRM 4.5.7 and 3.5.6. The workaround is to turn off optimization.
Debugger
- Ada and C++ Exception Interoperability: Ada and C++ exceptions are now more cooperative. Unhandled C++ exceptions in code called by Ada can now be caught by the "when others" clause of an Ada exception handler. Similarly, Ada exceptions can be caught by a C++ "..." handler. However, no provision is made for accessing information within the foreign language's exception object.
- The debugger cannot be attached to a running process if the process's executable file is on an NFS mounted file system that's not mounted "nointr". The debugger dynamically checks for this and issues an error message at the time of the attach. Workaround: Mount the disk as "nointr" or place the executable on a locally mounted disk. (HP Only)
- The debugger takes an excessively long time to single-step over Ada statements that call the run-time kernel (e.g. an array of task type elements).
- The raise command should not be used from inside the prolog of a procedure because its behavior will be unpredictable.
- The watchpoint mechanism takes advantage of hardware or software support when it is available. If this support is not available, the debugger uses single stepping to watch objects. If single stepping is used, watchpoint execution will be slow. At the current time, watchpoints are slow on all targets except SGI and PowerPC.
- When a breakpoint is set on a call to a task entry, the debugger sometimes gets confused and hangs when an advance/step over command is entered, or skips to a faulty line upon issuing a step command.
- The following error:
Modify data in the debugger only supports the modification of scalars, strings, and pointers. When you kill a program using the File > Kill command from the debugger GUI, then run another program, one or two of the following messages will be displayed in the debugger's log window:
can only handle init messages from hi
These messages should be ignored. Debugging is not affected.
- The debugger prints an error message when trying to display a parameter whose type is tagged.
- The debugger prints bad values for protected object entry parameters.
- The Emacs editor does not work with the GUI debugger. Workarounds:
- Use the Ada Object Editor with the GUI debugger
- Use the debugger in Source Mode (display source code in the debugger window with the View > Show Source command)
- Use the command-line debugger (rdb or a_db).
- The debugger is currently unable to call a task entry. A CASE_ERROR is generated if this attempted.
- The Ada95 debugger cannot set breakpoints within a protected entry.
- The Ada95 debugger cannot display discriminants of a task.
- User procedure calls of protected functions and procedures from within the debugger are not supported.
- The debugger cannot display protected entry parameters correctly.
- The debugger cannot display tasks or protected objects with discriminants.
- The multi-exe debugger does not support multiple dbrc files well. In particular, the debugger does not read in the dbrc file for exec'd files correctly.
- The following are known limitations of the Object Display Window:
- Deleting objects causes unnecessary reevaluation of remaining objects.
- Inactive objects and some other evaluation errors aren't handled very well; they may result in blanks in the Object Display Window and extraneous messages in the Log window.
- Messages are displayed indicating that the debugger cannot access the memory of the program being debugged. These are due to a problem with disassembly of a program that uses shared libraries. (DEC Alpha OSF/1 only)
Ada Object Editor
Functionality of Basic Keys in Apex Editor under Solaris 6 or later7
The Home, End, PageUp, and PageDown keys do not work as expected in the Apex Editor on Solaris 6 and Solaris 7. The problem is that the Motif setup on Solaris 2.6 or later is incompatible with Motif applications like Apex. Solaris is defining osfBeginLine twice, once for the Home key and once for the "7" key on the numeric keypad. When the Motif library code in Apex reads two bindings for the same osfKeysym, it only accepts the second one, that is, for the "7" key.
The workaround is to create a file called $HOME/.motifbind containing this text:
osfActivate: <Key>KP_Enter osfCancel: <Key>Escape osfHelp: <Key>Help osfMenu: Shift<Key>F10 osfMenuBar: <Key>F10 osfLeft: <Key>Left osfUp: <Key>Up osfRight: <Key>Right osfDown: <Key>Down osfBeginLine: <Key>F27 osfEndLine: <Key>F33 osfBeginLine: <Key>Home osfEndLine: <Key>End osfPageUp: <Key>F29 osfPageDown: <Key>F35 osfPageUp: <Key>Prior osfPageDown: <Key>Next osfBackSpace: <Key>BackSpace osfDelete: <Key>Delete osfInsert: <Key>KP_Insert osfInsert: <Key>Insert osfUndo: <Key>Undo osfAddMode: Shift<Key>F8 osfCopy: <Key>SunCopy osfCut: <Key>SunCut osfPaste: <Key>SunPaste
When you log in again (or when you restart the window manager), the _MOTIF_DEFAULT_BINDINGS root property will be initialized from this file instead of the Solaris defaults. Apex will then bind the Home, End, PageUp and PageDown keys as expected. You can also change the motif bindings without restarting X or the window manager by running "xmbind bindings_file", but you'll have to restart Apex afterwards to see the new bindings.
If you use the Sun desktop, you can copy this file to /usr/dt/lib/bindings/sun, which makes these bindings the default for all users.
Configuration Management System (Summit/CM)
Set Location for Remote Storage Directory
If you remotely store a view in another directory outside a subsystem, you should first execute Control > Maintenance > Permanent Name on that directory to establish a permanent name for it. This avoids possible automounter problems.
Recovering File Locks from Remote Machines
When an Apex command runs on a machine (machine A), it attempts to acquire a lock for a file. If it finds the file locked on a remote machine (machine B), machine A checks machine B to see whether the process that acquired the lock is still active. If the process is not running, machine A recovers the file lock for itself. If the process is still running, the command running on machine B retains the file lock.
For this to work correctly, the remote machine must be running the remote execution demon (rexd).
To see whether rexd is running on the remote machine, enter the following command in an xterm window, where remote_machine is the hostname of the remote machine:
on remote_machine ps 1
If a status line is returned, the remote machine is running rexd.
You can also set APEX_LOCKING to 'rsh' or 'on' depending on how you want locking to query the remote machine.
If you cannot run rexd, contact your Rational technical representative for alternative workarounds.
Version Description Files and Obsolescence
Introduction of new VDF files does not cause imports to be considered to be obsolete.
Any changes to included VDF files or VDF files in export directories do not cause obsolescence of client import information.
Task Management System (Summit/TM)
Task Editor Naming
The Task Editor dialogs for different task kinds must have different names.
Controlled Tasks
A task file can be made a controlled object under the Summit/CM system, although this is not recommended. A controlled task must be checked out when the task is modified via a task editor or the modify_task command, when the task is associated with or disassociated from an object via a Summit/CM command (such as check_out), and when a child of the task is created, since a checked in task cannot be modified.
Updating Existing Task Management Domains
Incompatibilities between older versions (pre 2.4.0) of Summit/TM and newer versions (2.4.0 or later) may cause problems when updating existing task management domains
This is an issue that may arise at installation time when the Summit/TM installation tests are performed, or it may occur later when a user tries to create a new task in some existing old task domain. In either case, an error of the form:
*** missing kind field for task template /xyz/.../abc.task
is generated from the create_task command. Task templates used by the create_task command must always identify their task kind via the "Kind" field.
There are two ways to solve this problem depending on which task kind is being used to create the new task. The task kind can be determined by examining the KIND_PATH switch in the Policy/Taskmgmt.sw switch file of the given task domain subsystem.
- 1 . If one of the older versions of the standard task kinds is being used, such as:
$APEX_BASE/task/task_kinds.ss/share.1.0.4.rel/change
replace the old standard task kind in the KIND_PATH switch with the respective new one, such as
$APEX_BASE/task/task_kinds.ss/share.1.0.7.rel/change.
- 2 . If a user-customized task kind is being used (with the simple name, "my_kind", for example), add the following line to the task template that was used to create the new task:
Kind: my_kind
User Interface
Delete Object Confirming Dialog
The behavior of the Delete Object command in terms of confirming dialogs is inconsistent. If a single subsystem in the directory viewer is selected the Delete Object command is executed, a confirming dialog is displayed. To delete the subsystem and all its contents, the user must click Yes for the action to continue.
If a directory, which contains a subsystem is selected and the Delete Object command is executed, no confirming dialog is displayed and the action is carried out.
White Foreground
On some systems, most notably CDE, an X resource gets loaded of the form:
*foreground: #FFFFFFFF
This results in the default foreground color being white in every possible place. Apex's X defaults set up background colors for everything but only sets foreground colors for error messages and warnings. Directory viewers have a background that is almost white so things are just about invisible. Workaround: Place the following in $APEX_HOME/app-defaults/Rational or your .Xdefaults file:
Rational*foreground: black
Or, from the command line, enter:
% xrdb -merge -nocpp Rational*foreground: black ^D %
Note that you need the -nocpp to get it to work interactively.
Clearing Output Windows
Output windows become slower as they acquire large amounts of information. To speed up the output, occasionally clear the window by selecting File > Clear.
Documentation
Manpages
If you are having problems displaying an Apex man page because there is a system command man page with the same name (such as the link command), use the following man command format from an Apex shell window:
%man -F -M $APEX_HOME/doc/En_US/man/ada link
Difficulties Starting Online Help
If you have problems initially accessing the online help system in Apex, invoke Netscape outside of Apex, then attempt to access the help system again. This time the desired documentation will be displayed in the Netscape window.
If the Netscape session begins, but the correct help page is not displayed, repeat your help request. The online help page will now be displayed. This may happen the first time the help system is invoked.
Dancing Colors
When using Apex and viewing the online help system using the default Netscape, your display colors may change as you shift from Apex windows to the Netscape window. To eliminate these "dancing colors", you must edit the value of the APEX_HELP_BROWSER switch. Do this using the Tools > Session > Environment command to change the value of this switch to "netscape" (from "netscape-install").
Note that, while the dancing colors will stop, poor color mappings for the Apex dialogs could result.
Java Browser/Web Interface
Co-hosting Apex and Web Servers
If you plan to use the Apex/Java Interface, the Web server and the Apex server must be the same machine. This is a Java restriction.
The Apex Web interface includes a Java applet. One unchangeable characteristic of a Java applet is that it can communicate only with the Web server from which it comes. This means that the Web server applet cannot make a connection to some arbitrary Apex server. It can connect only to the Web server itself.
Using Web Browsers
The Apex Java source has been ported to Swing technology. For any browser to be able to use the Apex Web Interface, the JDK 1.2.2 plug-in is required. Note that both JDK 1.2.2 and the "appletviewer" tool shipped with JDK 1.2.2 are required.
Pressing Icon Buttons and Selecting Tabs
The Apex/Java Interface icon buttons (navigate, alternatives, history, and completion) will respond to a mouse click only if the mouse does not move before the mouse button is release. The slightest movement will cause the click to be ignored.
If an icon button appears to pop out instantly as the mouse button is released, the click has probably been ignored.
The same problem occurs in tabbed dialogs when a tab is selected. The selection is ignored if the mouse moves.
Installation and Licensing
For several of the Apex platforms, there are known limitations pertaining to the installation of Apex. These are described in detail in the Installing Rational Apex.
Not all FlexLM features described in the online FlexLM documentation are supported.
RCI
Setup of sample customizations
Before they are used, the sample RCI customizations for VADSself and GNAT need to be setup for the local installation of the target compilation system (see the README file provided in the customization's compiler key directory for details).
This process may be automated by using the setup script provided in the customizations' compiler key directory. This interactive script should be run within an Apex session, by the user who `owns' the Apex/RCI installation.
Compiler_Properties File
An RCI customization's Compiler_Properties file (in the compiler key directory) must include the property RCI_VERSION. If it is missing, Apex will treat dependent views as non-RCI views, and such operations as building standard or semantic checking will use the attributes of the native Apex compiler.
Remodelling non-RCI views
If remodelling a non-RCI view with an RCI model partially fails during the post-import phase, that is an indication that the RCI compiler key for this model may lack an appropriate set_key script.
Refer to the sample customizations for an example.
Mutual imports
The RCI itself does not have any restrictions or specific handling for mutual imports: RCI host views may belong to a mutual import set; this will result in similar mutual imports being established between the target libraries for these views.
This may not work if the target compilation system does not support such mutual imports. Then, the customization should be adapted to handle this case (for example, by imposing a single common target library for a mutual import set).
Target Compilation
Killing an Apex RCI compilation operation may not kill the spawned target compilation, which is generally running on a different machine.
Attributes
- Static attributes cannot be defined in RCI. (Defect 1341)
- Types returned by attributes must be declared inside of package System. The RCI customization thus requires a new package system to be declared. (Defect 0627)
RCI Batch Mode
When one or both of the operational characteristics REQUIRE_BODY_AND_GENERIC_IN_SAME_COMPILATION or REQUIRES_SUBUNITS_AND_GENERIC_IN_SAME_COMPILATION are set to true, compilation ordering generated in RCI batch mode may be incorrect.
Profiling
Solaris Only: The platform C compiler must be installed to use the Apex profiling capability.
Defects/Change RequestsThe defects described in this section have been resolved in Apex 4.2.0.
Contacting Rational Technical SupportIf you have questions about installing, using, or maintaining this product, contact Rational Technical Support as follows:
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |