The following table describes where you can find information previously provided in release notes.

Flashes contained urgent information about product issues and are delivered after a product is released. On docs.bmc.com, this information is delivered in an "Urgent issues" topic, under Release notes and notices. If this topic does not exist for a given product release, no urgent issues have been discovered for that release.

Depending on the number of topics included in the export, it might take several minutes to create the PDF. Once the export is complete, you can download the PDF.

Sizing a database can be one of the most arduous tasks a database administrator, analyst or developer must attend to. It is time consuming and more hours go into analyzing the database than actually sizing it. There are some tools that can efficiently size a database before deployment. For example, one can use ERwin to determine how large the database will become in N number of months. One could also a database with random data using products like Datatect. Of course one can do the math themselves which is more often the case than not.

Fortunately, has relatively little to do with databases for its own purposes. The notable exception is the metrics data that it can collect. Storing the metric data in an external standalone RDBMS is considered a best practice. When sizing that database, a general rule of thumb is that approximately 700 MB of space is required to retain up to a month of metric data.

Technically, it is less resource intensive to have larger or more coarse workflows than it is to have many smaller workflows. Large numbers of small workflows have a measurable impact on the grid requiring more processing, memory, and disk space to properly utilize and maintain. However, one must consider readability and the relative simplicity of decomposing larger workflows into smaller more concise workflows. Moreover, the more succinct and focused the workflow is, the more reusable it will become in other workflows.

Yes, the product is multi-threaded. It is written in Java, which is largely OS-agnostic and highly portable. The development team uses both Windows and UNIX for its development.

Customers tend to run on virtual machines. However, using physical hardware provides best performance and stability.

If auditing is configured, then will record actions that are performed by users on the grid (e.g. configuring an adapter, activating a module, etc.).

Repository logs (named repository.log) are located in the AO_HOME/repository/logs folder.

Grid peer component logs (named grid.log and processes.log) are located in the AO_HOME/tomcat/logs folder.

Logging level is configured using the Grid Manager web UI. Navigate to Manage > Peer > edit the peer(pencil button) → Configure Logging button.