ARM Macros | SAS 9.1.3 Language Reference: Concepts, Third Edition, Volumes 1 and 2

Definition of ARM Macros

The ARM macros provide a way to measure the performance of applications as they are executing. The macros write transaction records to the ARM log. The ARM log is an external output text file that contains the logged ARM transaction records. You insert the ARM macros into your SAS program at strategic points in order to generate calls to the ARM API function calls. The ARM API function calls typically log the time of the call and other related data to the log file. Measuring the time between these ARM API function calls yields an approximate response-time measurement.

An ARM macro is self-contained and does not affect any code surrounding it, provided that the variable name passed as an option to the ARM macro is unique. The ARM macros are used in open code (code that is not in PROC or DATA steps) and in DATA step or SCL environments.

There are two categories of ARM macros:

ARM macros to instrument applications
ARM post-processing macros to use with the ARM log.

Note

The ARM macros are not part of SAS Macro Facility. They are part of the SAS ARM interface. See Chapter 15, "Monitoring Performance Using Application Response Measurement (ARM)," on page 225 for information about the SAS ARM interface that consists of the implementation of the ARM API as an ARM agent, ARM macros, and ARM system options.

Using ARM Macros

Overview of ARM Macros

The ARM macros invoke the ARM API function calls. The ARM macros automatically manage the returned IDs from the ARM API function calls.

The ARM API function calls are implemented in SAS software with SAS ARM macros and these function calls provide a way to measure the performance of SAS applications as they are running. For each ARM API function call, there is a corresponding macro. The following table shows the relationship among the SAS ARM macros and the ARM API function calls:

Table 4.4: Relationship among SAS ARM Macros and ARM API Function Calls
SAS ARM Macro	ARM API Function Call
%ARMINIT	ARM_INIT
%ARMGTID	ARM_GETID
%ARMSTRT	ARM_START
%ARMUPDT	ARM_UPDATE
%ARMSTOP	ARM_STOP
%ARMEND	ARM_END

The SAS ARM macro invokes the ARM API function call.

The following ARM macros are available:

%ARMINIT Macro	generates a call to the ARM_INIT function call, which names the application and optionally the users of the application and initializes the ARM environment for the application. Typically, you would insert this macro in your code once.
%ARMGTID Macro	generates a call to the ARM_GETID function call, which names a transaction. Use %ARMGTID for each unique transaction in order to describe the type of transactions to be logged. A %ARMGTID is typically coded for each transaction class in an application.
%ARMSTRT Macro	generates a call to the ARM_START function call, which signals the start of a transaction instance. Insert %ARMSTRT before each transaction that you want to log. Whereas %ARMGTID defines a transaction class, %ARMSTRT indicates that a transaction is executing.
%ARMUPDT Macro	is an optional macro that generates a call to the ARM_UPDATE function call, which provides additional information about the progress of a transaction. Insert %ARMUPDT between %ARMSTRT and %ARMSTOP in order to supply information about the transaction that is in progress.
%ARMSTOP Macro	generates a call to the ARM_STOP function call, which signals the end of a transaction instance. Insert %ARMSTOP where the transaction is known to be complete.
%ARMEND Macro	generates a call to the ARM_END function call, which terminates the ARM environment and signals that the application will not make any more ARM calls.

The ARM macros permit conditional execution by setting the appropriate macro options and variables .

Some general points about the ARM macros follow: A general recommendation with all ARM macros is to avoid, in the program, the use of either macro variables or SAS variables beginning with the letters "_ARM."
All macro options are keyword parameters. There are no positional parameters. Values for the macro options should be valid SAS values-that is, a SAS variable, quoted character string, numeric constant, and so on.
ARM macros can function either inside a DATA step or in open code. Use the _ARMACRO global variable or the MACONLY=YESNO macro option to tell the macro execution which mode is being used. For more information, see "Setting the Macro Environment" on page 67.

Using Variables with ARM Macros

The ARM macros use variables to pass IDs and other information from one macro to another. Because the ARM macros function within the same DATA step, across DATA steps, and in open code, variables that are used by the macros can take the form of DATA step variables or macro variables as determined by the macro environment.

SAS DATA step variables are used to pass ID information between two or more ARM macros in the same DATA step. In the DATA step environment, but not in the SCL environment, DROP statements are generated for these variables so that they are not inadvertently included in any output data sets.

If ID information must be passed between two or more ARM macros across separate DATA steps, then macro global variables are used.

The following SAS DATA step variables and macro variables are considered global:

Table 4.5: Global ARM Macro Variables
Variable	Description	Set By	Used as Input by
_ARMAPID	application ID	%ARMINIT	%ARMEND
_ARMTXID	transaction class ID	%ARMGTID	%ARMSTRT
_ARMSHDL	start handle	%ARMSTRT	%ARMUPDT, %ARMSTOP
_ARMRC	error status	%ARMUPDT %ARMSTOP %ARMEND	none
_ARMGLVL	global level indicator	calling program	all
_ARMTLVL	target level indicator	calling program	all
_ARMEXEC	global enablement	calling program	all
_ARMACRO	open code enablement	calling program	all
_ARMSCL	SCL code enablement	calling program	all

ARM API Objects

The following three classes of objects are specified in the ARM API:

applications represent the systems that you are creating, such as an inventory or order entry application. Because the SAS interface to the ARM API provides totals on a per application basis, you might want to consider this when you define the scope of your application.
transaction classes specify a unit of work. You should create a transaction class for each major type of work that you want to create within an application. In concept, the transaction class is a template for the started transaction.
transaction instances specify the actual start time for a unit of work. Transaction instances have response time information that is associated with them.

The ARM API uses numeric identifiers or IDs to uniquely identify the ARM objects that are input and output from the ARM macro. The three different classes of IDs that correspond to the three ARM classes are

application IDs
transaction class IDs
start handles (start time) for transaction instances.

ID Management Using ARM Macros

These examples demonstrate how the ARM macros work. The ARM macros automatically manage application IDs, transaction IDs, and start handles. The default ID management works best in simple ARM call schemes. See "Complex ARM Macro Call Schemes" on page 61 for more information. By default, the ARM macros use IDs that were generated from the most recent macro call. The following example demonstrates how to use all of the ARM macros:

 /*global macro variable to indicate ARM macros are outside the data step*/   %let _armacro=1;       /* start of the application */   %arminit(appname='Sales App', appuser='userxyz');       /* define the transaction classes */   %armgtid(txnname='Sales Order', txndet='Sales Order Transaction');       /* more arm_getid calls go here for different transaction classes */       /* start of a transaction */   %armstrt;   data _null_;       /* place the actual transaction code here */       /* update the status of the transaction as it is running */   %armupdt(data='Sales transaction still running...',maconly=no);   run;       /* place the actual transaction stop here */       /* the transaction has stopped */   %armstop(status=0);       /* end of the application */   %armend;

All ID management is performed by the macros without requiring the calling program to track IDs. Each macro in the previous example uses the most recently generated ID values from previous macros. The following example is identical, but the comments explain the passing of IDs in more detail:

 %let _armacro=1;        /*       * This %arminit macro will generate both a SAS       * variable and global macro variable by the name       * of _armapid and set it in the ID that is returned       * from the arm_init() function call that is       * wrapped by the macro.       */     %arminit(appname='Sales App', appuser='userxyz');       /*       * This %armgtid macro uses the _armapid SAS variable       * as input to the arm_getid() function call that it wraps.       * It also generates both a SAS variable and global macro       * variable by the name of _armtxid and sets them to the       * ID that is returned from the arm_getid function call that       * it wraps.       */    %armgtid(txnname='Sales Order', txndet='Sales Order Transaction');       /*       * Because we are still in the same DATA step, the %armstrt       * macro below will use the _armtxid SAS variable that is       * generated from the previous %armgtid macro as input       * to the arm_start() function call that it wraps. It       * also generates an _armshdl variable.       */     %armstrt;       /*       * The %armupdt call below uses the _armshdl SAS variable       * that is generated from the previous %armstrt macro.       */     %armupdt(data='Sales transaction still running...');       /*       * The armstop call also uses the same _armshdl SAS       * variable from the %armstrt.       */     %armstop(status=0);       /*       * The %armend call uses the _armapid SAS variable       * generated by the %arminit macro earlier to end       * the application.       */     %armend;   run;

You can code the ARM macros across different DATA steps as follows and achieve the same results:

 data _null_;       /* note the end of the application */     %arminit(appname='Sales App', appuser="userxyz');   run;   data _null_;     %armgtid(txnname='Sales Order', txndet='Sales Order Transaction');       /* more arm_getid function calls go here for different transaction classes */   run;   data _null_;       /* note the start of the transaction */     %armstrt;       /* place the actual transaction here */   run;   data _null_;       /* update the status of the transaction as it is running */     %armupdt(data='Sales transaction still running...');   run;   data _null_;       /* place the actual transaction stop here */       /* note that the transaction has stopped */     %armstop(status=0);   run;   data _null_;       /* note the end of the application */     %armend;   run;

The end result is the same as in the first example, except that the macros are using the generated macro variables rather than the SAS variables for passing IDs.

Complex ARM Macro Call Schemes

Allowing the macros to automatically use the global variables in basic scenarios simplifies coding. However, macros that use global variables can lead to misleading results in more complicated scenarios when you attempt to monitor concurrent applications or transactions as follows:

 data _null_;     %arminit(appname='App 1',getid=yes,txnname='txn 1');   run;       /* start transaction instance 1*/   data _null_;     %armstrt;   run;       /* start transaction instance 2 */   data _null_;     %armstrt;   run;       /* WRONG! This assumes that the %armupdt is updating       * the first transaction. However, it is actually updating the       * second transaction instance because _armshdl contains the value       * from the last macro call that was executed, which is the second       * transaction.      */   data _null_;     %armupdt(data='txn instance 1 still running...');   run;

To save the IDs use the *var options (APPIDVAR=, TXNIDVAR=, and SHDLVAR=) to pass or return the IDs in your own named variables. Here is an example that uses the SHDLVAR= option to save the start handles:

 data _null_;     %arminit(appname='xyz',getid=YES,txname='txn 1');   run;       /* start transaction instance 1 and save the ID using shdlvar= */   data _null_;     %armstrt(shdlvar=savhdl1 );   run;       /* start transaction instance 2 and save the ID using shdlvar= */   data _null_;     /*armstrt( shdlvar=savhd12 );   run;       /* Now use the shandle= parameter after retrieving the first id. */   data _null_;     %armupdt(data='updating txn 1', shdlvar=savhdl1);   run;       /* Use the same technique to stop the transactions */       /* in the order they were started. */   data _null_;     %armstop(shdlvar=savhdl1);     %armstop(shdlvar=savhdl2);     %armend();   run;

As the previous example shows, using the *var option simplifies the code. The previous technique is recommended for use on all ARM macro calls.

The following example demonstrates how to use all of the *var options to automatically manage IDs for concurrent applications, transaction classes, transaction instances, and correlated transaction instances:

 data _null_;     %arminit(appname='Appl 1', appuser='userid', appidvar=app1);     %arminit(appname='Appl 2', appuser='userid', appidvar=app2);     %arminit(appname='Appl 3', appuser='userid', appidvar=app3);   run;   data _null_;     %armgtid(txnname='Txn 1A', txndet='Txn Class 1A',              appidvar=appl,txnidvar=txnidvar=txn1a);     %armgtid(txnname='Txn 1B', txndet='Txn Class 1B',              appidvar=appl,txnidvar=txnidvar=txn1b);     %armgtid(txnname='Txn 2A', txndet='Txn Class 2A',              appidvar=app2,txnidvar=txnidvar=txn2a);     %armgtid(txnname='Txn 2B', txndet='Txn Class 2B',              appidvar=app2,txnidvar=txnidvar=txn2b);     %armgtid(txnname='Txn 3A', txndet='Txn Class 3A',              appidvar=app3,txnidvar=txnidvar=txn3a);     %armgtid(txnname='Txn 3B', txndet='Txn Class 3B',              appidvar=app3,txnidvar=txnidvar=txn3b);   run;   data _null_;     %armstrt(txnidvar=txn1a,shdlvar=sh1a);     %armstrt(txnidvar=txn1b,shdlvar=sh1b);     %armstrt(txnidvar=txn2a,shdlvar=sh2a);     %armstrt(txnidvar=txn2b,shdlvar=sh2b);     %armstrt(txnidvar=txn3a,shdlvar=sh3a);     %armstrt(txnidvar=txn3b,shdlvar=sh3b);   run;   data _null_;     %armupdt(data='Updating txn instance 1a...', shdlvar=sh1a);     %armupdt(data='Updating txn instance 1b...', shdlvar=sh1b);     %armupdt(data='Updating txn instance 2a...', shdlvar=sh2a);     %armupdt(data='Updating txn instance 2b...', shdlvar=sh2b);     %armupdt(data='Updating txn instance 3a...', shdlvar=sh3a);     %armupdt(data='Updating txn instance 3b...', shdlvar=sh3b);   run;   data _null_;     %armstop(status=0, shdlvar=sh1a); %armstop(status=1, shdlvar=sh1b);     %armstop(status=0, shdlvar=sh2a); %armstop(status=1, shdlvar=sh2b);     %armstop(status=0, shdlvar=sh3a); %armstop(status=1, shdlvar=sh3b);   run;   data _null_;     %armend(appidvar=app1);     %armend(appidvar=app2);     %armend(appidvar=app3); run;

As the previous example demonstrates, you can establish your own naming conventions to uniquely identify applications, transaction classes, and transaction instances across different DATA steps, in open code, or in SCL programs.

The macros support explicit passing of the IDs using the APPID=, TXNID=, and SHANDLE= options. These options are similar to the *var options, except that they do not retrieve values across DATA steps using macro variables. The primary use of the options is to supply numeric constants as ID values to the macros, because the *var options do not accept numeric constants.

Note	The use of APPID=, TXNID=, and SHANDLE= is not recommended for new applications. These options are maintained for compatibility with earlier ARM macro releases only. Use APPIDVAR=, TXNIDVAR=, and SHDLVAR= instead of APPID=, TXNID=, and SHANDLE=, respectively.

Because IDs are generated by the ARM agent, to pass a numeric literal requires that you start a new SAS session. If any SAS subsystems are also functioning, you will not know what the ID will be at execution time.

The use of APPIDVAR=, TXNIDVAR=, and SHDLVAR= options is recommended when coding new applications.

Defining User Metrics in ARM Macros

A metric is a counter, gauge, numeric ID, or string that you define. You specify one or more metrics for each ARM transaction class. When a start handle (instance of the transaction class) is started, updated, or stopped, the application indicates a value for the metric and writes it to the ARM log by the ARM agent.

The user metric name and user metric definition must be specified together in the %ARMGTID. METRNAM1-7= names the user metric and must be a SAS character variable or quoted literal value up to eight characters in length. METRDEF1-7= defines the output of the user-defined metric. The value of METRDEF1-6= must be one of the following:

COUNT32, COUNT64, COUNTDIV	use the counter to sum up the values over an interval. A counter can also calculate average values, maximums, and minimums per transaction, and other statistical calculations.
GAUGE32, GAUGE64, GAUGEDIV	use the gauge when a sum of values is not needed. A gauge can calculate average values, maximums, and minimums per transaction, and other statistical calculations.
ID32, ID64	use the numeric ID simply as an identifier but not as a measurement value, such as an error code or an employee ID. No calculations can be performed on the numeric ID.
SHORTSTR, LONGSTR	use the string ID as an identifier. No calculations can be performed on the string ID.
	Restriction: METRDEF7= can only equal LONGSTR and can be a long string of 32 bytes. METRDEF1-6 cannot equal LONGSTR.

Note	32 and 64 signify the number of bits in the counter, gauge, divisor, or ID.

The METRVAL1-7= sends the value of the user-defined metric to the ARM agent for logging when used in the %ARMSTRT, %ARMUPDT, and %ARMSTOP. The value of the user-defined metric must conform to the corresponding user metrics defined in the %ARMGTID. The following example shows the user metrics:

 %let _armacro=1;    %arminit(appname='Sales App', appuser='userxyz');       /* name and define the user defined metrics */   %armgtid(txnname='Sales Order', txndet='Sales Order Transaction',            metrnam1=  aname  , metrdef1=count32);       /* aname is the NAME of the metric and can be anything up to 8 characters */       /* start of user defined metric */       /* initial value of the metric */   %armstrt(metrval1=0);   data myfile;   .   .    /*some SAS statements*/   .   end=EOF;   run;       /* value of the metric is the automatic observation */   %armupdt(data='Sales transaction still running...',maconly=no,            metrval1=_N_);   data myfile;   .   .    /*more SAS statements*/   .   if EOF then       /* value of the metric is at the highest observation count */   %armstop(status=0, metrval1=_N_,maconly=no);   run;   %armend;

Defining Correlators in ARM Macros

A primary or parent transaction can contain several component or child transactions nested within them. Child transactions can also contain other child transactions. It can be very useful to know how much each child transaction contributes to the total response time of the parent transaction. If a failure occurs within a parent transaction, knowing which child transaction contains the failure is also useful information. Correlators are used to track these parent and child transactions.

The use of correlators requires that multiple transaction start handles be active simultaneously . This requires the use of the CORR= and SHDLVAR= options in the %ARMSTRT macro. You define each parent and child transaction in the %ARMSTRT macro using the SHDLVAR= option. For each child transaction, you must also define the parent transaction using the PARNTVAR= option.

Each child transaction is started after the parent transaction starts. Parent or child transactions can be of the same or different transaction classes. You define the transaction classes in the %ARMGTID macro using the TXNIDVAR= option.

Both parent and child transactions can have updates specified in the %ARMUPDT macro. User metrics can be specified for both transaction types in the %ARMSTRT macro if the user metrics were defined in the corresponding transaction class in the %ARMGTID macro.

All child transactions must stop in the %ARMSTOP macro before the parent transaction stops. The sibling (multiple child) transactions can be stopped in any order.

For example, the parent transaction 100 consists of child transactions 110, 120, and 130, each performing a different part of the unit of work represented by the parent transaction 100. The child transaction 120 contains child transactions 121 and 122. Transaction 200 has no child transactions. Here is a code fragment used to create these relationships:

 %arminit(appname='Application",appidvar=appid);   %armgtid(appidvar=appid,txnname='TranCls',txndet='Transaction Class Def',            txnidvar=txnid);   %armstrt(txnidvar=txnid,corr=1,shdlvar=HDL100);   %armstrt(txnidvar=txnid,corr=0,shdlvar=HDL200<,...user metrics>);   %armstrt(txnidvar=txnid,corr=2,shldvar=HDL110,parntvar=HDL100);   %armstrt(txnidvar=txnid,corr=3,shldvar=HDL120,parntvar=HDL100);   %armstrt(txnidvar=txnid,corr=2,shldvar=HDL130,parntvar=HDL100);   %armstrt(txnidvar=txnid,corr=2,shldvar=HDL121,parntvar=HDL120);   %armstrt(txnidvar=txnid,corr=2,shldvar=HDL122,parntvar=HDL120);   ...   %armstop(shdlvar=HDL200);   %armstop(shdlvar=HDL121);   %armstop(shdlvar=HDL122);   %armstop(shdlvar=HDL120);   %armstop(shdlvar=HDL130);   %armstop(shdlvar=HDL110);   %armstop(shdlvar=HDL100);

Enabling ARM Macro Execution

Setting the _ARMEXEC Macro Variable

All ARM macros are disabled by default so that insertion of ARM macros within created code will not result in inadvertent, unwanted logging. To globally activate execution of the ARM macros, you must set the _ARMEXEC global macro variable to a value of 1. Any other value for _ARMEXEC disables the ARM macros.

There are two methods of setting the _ARMEXEC macro variable. The first method sets the variable during DATA step or SCL program compilation using %LET:

 %let _armexec = 1;

If the _ARMEXEC value is not set to 1, then no code is generated and a message is written in the log:

 NOTE: ARMSTRT macro bypassed by _armexec.

The second method of setting _ARMEXEC variables is to use SYMPUT during execution. To set the _ARMEXEC variable during DATA step or SCL program execution:

 call symput('_armexec', '1');

With this technique, the macro checks the _ARMEXEC variable during program execution and the ARM function call is executed or bypassed as appropriate.

Enabling ARM Macro Execution with SCL

There are two methods of setting the _ARMEXEC macro variable-during compilation or execution. Both methods are explained in "Setting the _ARMEXEC Macro Variable" on page 65, or you can use a combination of these methods. For example, set _ARMEXEC to 1 using the compilation technique (perhaps in an autoexec at SAS initialization), and then code a drop-down menu option or other means within the application to turn _ARMEXEC on and off dynamically using CALL SYMPUT.

In SCL, if _ARMEXEC is not 1, when the program compiles, all macros will be set to null and the ARM interface will be unavailable until it is recompiled with _ARMEXEC set to 1.

Additionally, to enable proper compilation of the ARM macros within SCL, you must set the _ARMSCL global macro variable to 1 prior to issuing any ARM macros. This variable suppresses the generation of DROP statements, which are invalid in SCL.

Conditional ARM Macro Execution

It is useful to code the ARM macros in your program but to execute them only when needed. All ARM macros support a LEVEL= option that specifies the execution level of that particular macro.

If it is coded, then the execution level of the macro is compared to two global macro variables, _ARMGLVL and _ARMTLVL. _ARMGLVL is the global level macro variable. If the LEVEL= value on the ARM macro is less than or equal to the _ARMGLVL value, then the macro is executed. If the LEVEL= value on the ARM macro is greater than the _ARMGLVL value, then macro execution is bypassed:

 /* Set the global level to 10 */     %let _armglvl = 10;   data _null_;     %arminit(appname='Appl 1', appuser='userid' );     %armgtid(txnname='Txn 1', txndet='Transaction #1 detail' );       /* These macros are executed */     %armstrt( level=9 );     %armstop( level=9 );       /* These macros are executed */     %armstrt( level=10 );     %armstop( level=10 );       /* These macros are NOT executed */     %armstrt( level=11 );     %armstop( level=11 );     %armend   run;

_ARMTLVL is the target level macro variable and works similarly to the ARMGLVL, except the LEVEL= value on the ARM macro must be exactly equal to the _ARMTLVL value for the macro to execute:

 /* Set the target level to 10 */     %let _armtlvl = 10;   data _null_;     %arminit(appname='Appl 1', appuser='userid' );     %armgtid(txnname='Txn 1', txndet='Transaction #1 detail' );       /* These macros are NOT executed */     %armstrt( level=9 );     %armstop( level=9 );       /* These macros are executed */     %armstrt( level=10 );     %armstop( level=10 );       /* These macros are NOT executed */     %armstrt( level=11 );     %armstop( level=11 );     %armend   run;

The LEVEL= option can be placed on any ARM macro and this is highly recommended. It allows you to design more granular levels of logging that can serve as an effective filtering device by logging only as much data as you want. If you set both _ARMGLVL and _ARMTLVL at the same time, then both values are compared to determine whether the macro should be executed or not.

Setting the Macro Environment

You set the global ARM macro environment by using the _ARMACRO variable with the value of 1 or 0. The value of 1 specifies that all ARM macros occur in open code and the value of 0 specifies that the ARM macros occur only in DATA steps. You use the MACONLY= option if an individual ARM macro is not placed outside of the global environment that is defined by the _ARMACRO setting. For SCL programs, you specify _ARMSCL with a value of 1.

The following table shows the global value, the temporary option needed, and the results.

Table 4.6: Using _ARMACRO and _ARMSCL to Set the ARM Macro Environment
Global Value	Temporary Option	Result
%let _ARMACRO=0;	MACONLY=NO	macro is in DATA step
%let _ARMACRO=1;	MACONLY=YES	macro is in open code
%let _ARMSCL=1;	none	macro is in SCL
%let _ARMSCL=0;	none	macro is not in SCL

The following example shows how to set the macro environment in a DATA step:

 /* set global environment */       %let _armacro = 1;   data _null_;       %arminit(appname='Appl 1', appuser='user1',                appidvar=appl, maconly=no);         /* exception to global value */   run;         /* using global setting */         /* maconly= parameter not needed */      %armgtid(txnname='Txn 1A', txndet='Txn Class 1A',               appidvar=appl, txnidvar=txn1a);

The following example shows how to set the macro environment in SCL using autoexec:

 /* set global environment */       %let _armscl = 1;       %let _armexec = 1;

The following example shows how to set the macro environment in SCL:

 init:       %arminit(appname='Appl 1', appuser='user1',                appidvar=appl);       %armgtid(txnname='Txn 1A', txndet='Txn Class 1A',                appidvar=appl, txnidvar=txn1a);   return;   main:       %armstrt(txnidvar=txn1a,shdlvar=strt1);   return;   term:       %armstop(shdlvar=strt1);       %armend(appidvar=app1);   return;

Using ARM Post-Processing Macros

Post-processing ARM macros are also available. These ARM macros are specific to the SAS ARM implementation; they are not part of the ARM API standard.

After logging performance data to the ARM log, you can then use the ARM macros to read the log and create SAS data sets for reporting and analysis. The default name of the file is ARMLOG.LOG. To specify a different output file, use the ARMLOC= system option. There are three ARM post-processing macros:

%ARMCONV Macro	converts an ARM log created in SAS 9 or later, which uses a simple format, into the label=item ARM format used in SAS 8.2.
%ARMPROC Macro	processes the ARM log and outputs six SAS data sets that contain the information from the log. It processes ARM logs that include user metadata definitions on class transactions and user data values on start handles, update, and stop transactions.
%ARMJOIN Macro	processes the six SAS data sets that are created by %ARMPROC and creates data sets and SQL views that contain common information about applications and transactions.

For SAS 9 or later, the simple format of the ARM log records is comma delimited, which consists of columns of data separated by commas. The datetime stamp and the call identifier always appear in the same column location.

The format used in SAS 8.2. is a label=item format and is easier to read. Unfortunately, SAS spends a lot of time formatting the string, and this affects performance. In SAS 9 or later, ARM logs can be compared with SAS 8.2 ARM logs by using the following methods:

You can generate the SAS 9 or later ARM log and process it using the SAS 9 or later %ARMPROC and %ARMJOIN. The resulting data sets contain the complete statistics for the end of the start handle and the end of the application.
To convert SAS 9 or later ARM log format to the SAS 8.2 format you use the SAS ARM macro %ARMCONV.