ARM stands for Application Response Measurement. It is an API jointly developed by an industry partnership that is used to monitor the availability and performance of applications. This monitoring is done from the perspective of the application itself, so it reflects those units of work that are important from the perspective of the business.
Applications define units of work (transactions) that are meaningful within the application. Typical examples are transactions initiated by a user, or transactions with servers. Applications then call the API when transactions begin and end, allowing these transactions to be measured and monitored.
There are many different techniques for measuring response times, but only ARM measures them accurately from the perspective of the business. Other approaches, although useful in other ways, can only measure business service levels by making assumptions or guesses about what is a business transaction, and when it begins and ends. Other approaches also can't provide important information that ARM can, such as whether a transaction completed successfully.
Version 1 of ARM was developed jointly by Tivoli Systems and Hewlett Packard in 1996. Version 2 has been available since December 1997. The first two versions of ARM pertain to C programs. SAS V8.2 has implemented ARM 1.0. SAS V9 contains ARM 2.0 starting in January 2002.
ARM was developed by an industry partnership (the ARM Working Group). Members of the ARM Working Group are BGS, BMC Software, The Boeing Company, Candle, Citicorp, Compuware, Hewlett-Packard Company, IBM, Landmark, Novell, Oracle, SAS, SES, Sun, Tivoli Systems and Unify.
Version 3 of ARM is for Java applications. A beta version of this interface is in the queue for implementation here at SAS. The final version of the ARM 3.0 API was issued in Spring 2002.
Version 4 of ARM is under development. It will combine features of the C API (ARM 2.0) and Java API implementation (ARM 3.0).
The ARM Working Group is not a formal standards body, but ARM was developed by a consortium of companies with wide-ranging interests. These companies include application users, developers, and tool providers. Now that a significant level of support for ARM has developed, the Working Group intends to submit ARM for inclusion in formal standards.
Combining ARM calls within your application with an ARM agent, users of your application will be able to answer questions like the following. Is a transaction (and the application) hung, or are transactions failing? What is the response time? Are service level commitments being met? Who uses the application and how many of each transaction are used?
Using version 2 of ARM, applications can provide information that show how transactions are affected by other transactions, both within the same system and on different systems. This information can be used to pinpoint where response times are the longest, and where bottlenecks are occurring.
ARM has been designed to be a high speed interface that has minimal impact on applications. ARM agents are designed to quickly extract the minimum information needed and return control to the application immediately. Processing of the information is done in a different process that can run when the system is otherwise idle.
The SAS ARM Agent generates the minimum number of log records with the miminum abount of data in them. The actual statistics are generated in the %ARMJOIN processing, triggered by the presence of an stop or end transaction.
To get the end-of-start-instance, the user must submit an ARM_STOP function before ending the application. To get the end-of-application statistics, the user must submit an ARM_END funtion.