How to build tabular dashboards using proc report

How to Build Tabular Dashboards Using Proc Report

Shana Bereznay - ACS
Raff Rushton - IBM
Frank Bereznay - IBM

This paper presents a SAS based coding framework to develop tabular
dashboards using Proc Report. A tabular dashboard is a two dimensional
matrix of metric values with left hand columns to name and group
resources. Tabular data provides for discrete data points and at the same
time a dense presentation format. Dashboard capabilities include
threshold based traffic lighting of data elements, drilldown capabilities and
automated notification for exceptions. Macro tools are used to simplify the
coding required.

1.0 - Introduction / Dashboard Discussion
Management reporting is a key part of a Capacity Management practitioner’s set of responsibilities. There are
some general themes in this area, but for the most part, the presentation of information is heavily customized to
target the intended audience. The many decisions on what to report, how to report it, how to organize the
presentation page, use of colors, ICONs and links to related or supporting information makes this area more of an
art than science because, ultimately, beauty is in the eye of the beholder.

This presentation format is intended for audiences that prefer to see tabular data and want to see a lot of detailed
information about a single or small group of resources. It is intended to be a tactical presentation framework to
help IT professionals manage infrastructure assets or the delivery of services. Presentation density is a key
theme in Tufte’s work [Tufte05], [Tufte05A], [Tufte06], [Tufte06A]. Simply stated, you provide the viewer as much
related data as possible and let them analyze and derive the information content from the data. Ralston provides
a very good graphical example of presentation density with the Heat Charts he presented in his 2007 CMG Paper,
‘Using SAS/Graph to Display Performance and Capacity Data’ [Ralston07]. The objective here is to provide a
similar dense presentation framework for tabular data.

1.1 - Dashboard Description

Figure 1

The organization of a tabular dashboard is intuitive and easy to understand. Figure 1 is a sample tabular
dashboard. Each data cell represents a derived metric for a configuration item being evaluated for a single time
interval, typically a day or week. The cell is color coded to reflect how the metric value compares to established
utilization thresholds for the item. The data cell may also contain a link to a drill down report for the time interval

of the cell to further investigate the item. A left hand column may contain a trend report for the time intervals
defined by the data columns. Behind the scenes automated notifications can be implemented to E-mail users
when a reported value exceeds a threshold.

1.1 - Dashboard Design
The best place to start the design of your dashboard is to visualize how you want it to appear. Use Excel, or a
piece of paper and draw out what the table will look like. Ask yourself the following questions:

1. How many optional grouping levels will precede the column that will name the configuration item? For
each level you will need a unique variable to establish the hierarchy level.
2. How many resource categories will be reported on? It is likely that each resource category will have a
unique set of threshold values and ranges for utilization grouping and cell background color coding.
3. What will be the criteria to send out an E-mail notification? Who will be receiving the E-mail?
4. What will be the derived metric for a specific cell instance, e.g. mean, 90th Percentile, etc.?
5. What do you want the (optional) linked drill down report to be for a specific cell instance?
6. What do you want the (optional) linked trend report to be for a specific resource category?
7. What do you want the (optional) linked trend report to be for a configuration item?
8. What do you want the (optional) linked report to be for the grouping level(s)?

Figure 2 is a sample layout for a daily z/VM resource dashboard.

Group1 - Environment CI-Name - zVM Instance Resource Date / Metric (Display 30 Days)

CPU, Paging, DASD
Response Time (Drill down
Prod, Test, Sand_Box (No Drill to 30 day trend graph - Box 90th Percentile for Resource
Down) LPAR Name (No Drill down) and Wiskers plot format) (Drill down to hourly plots)

Programming Notes

Paging Rate Thresholds 00 - 05 - Blue CPU Utilization Thresholds 00 - 30 - Blue
Email Sys Admin on Yellow 05 - 15 - Green Email Sys Admin on Yellow 30 - 65 - Green
15 - 30 - Yellow 65 - 85 - Yellow
Greater than 30 - Red Greater than 85 - Red

DASD Response Time 00 - 10 - Green
Email Sys Admin on Yellow 10 - 20 - Yellow
Greater than 20 - Red
Figure 2

The details of the layout become the basis for creating a SAS dataset and supporting formats.

Variable Notes

Group1...N One or more optional variables to group configuration items on the page.
The zVM instance’s environment will be used to group.
CI_Name The name of the configuration item being reported on. The zVM instance name will be used.
Resource Resources being reported on: CPU, Paging and DASD Response time.
Date The date interval for the specific metric instance. Each cell will represent one day’s activity.
Metric The derived value (mean, 90th Percentile, etc.) for the resource. The 90th Percentile is used.
Background The background color for the metric instance. Use thresholds defined in table.
Cell_Link The URL link pointing to the drill down report for the metric instance.
Concatenate CI_Name, Resource and Date to create URL.
Trend_Link The URL link pointing to the trend graph for the reported resource for the time interval of the
dashboard. Concatenate CI_Name and Resource to create URL.

Once we have mapped our dashboards data requirements and defined the structure of the SAS dataset needed,
we can take a look at the overall process to build the dashboard.

2.0 - Tabular Dashboard Construction Overview

Figure 3

The SAS programming needed to create a dashboard and supporting reports can be divided into three steps: (1)
Data Preparation Steps, (2) Create Dashboard (Proc Report), and (3) Create supporting reports / graphs.

Five Proc Report examples will be used to demonstrate the procedure syntax to create a tabular dashboard.
Data Preparation Steps will be included as part of the five examples. After the tabular dashboard has been
developed, trend and drill down reporting will be covered along with E-mail notification. Figure 3 depicts this
overall flow.

2.1 - SAS Programming Notes
The SAS programs presented in this paper execute on a zSeries mainframe. The same SAS code is also
transferred and executed with no change (other than the symbolic parameter Path) on a Windows platform. The
primary reason to execute SAS code on the Windows platform is to capture the SAS log file to provide color
coded SAS code examples for inclusion in the paper. The ODS HTML output from the programs also can be
stored on a Windows file system or a zSeries mainframe zFS file system with no change (except for the path
statement).

2.2 - Dashboard Construction
Proc Report is a very popular and powerful reporting tool. The best evidence of this is the hundreds of papers
that have been written about it. In addition to papers, Art Carpenter has published a comprehensive book on how
to use Proc Report [Carpenter07A]. From this author’s perspective there are two main phases in learning to build
a tabular dashboard. The first phase is to master the basic syntax of the procedure. Three examples are
presented to show procedure syntax and how to build the basic structure of a tabular dashboard. The second
phase uses the Compute Block and hidden variables to assign attributes (cell formatting specification, links to
related reports, etc.) to cells. Two examples will be provided to cover cell attribution.

2.3 - Phase I
The first three examples will build an unattributed dashboard. This type of a dashboard is structurally the same
as the first example provided in the paper, except that colors and links are not part of the data cells. For good
references, in addition to Carpenter’s book, on coding PROC REPORT statement used in these examples, refer
to Lewandowki’s 2008 paper, ‘A Step-by-Step Introduction to PROC REPORT’ [Lewandowski08] and / or Pass’s
2006 paper, ‘So You’re Still Not Using PROC REPORT, Why Not?’ [Pass05]. Both of these tutorials can be
downloaded from the SAS Global Forum website, support.sas.com/events/sasglobalforum/previous/index.html.

2.3.1 - Example 1 – List of Data with Average Calculated
This first example is intended to show the simplicity of the procedure syntax and its summarization capabilities.
The Column statement identifies the variables that are to be included in the report and shows their order on the
page from left to right. A Define statement establishes the attributes for each variable. The Group attribute on
the Define statement creates a visual hierarchy much like the ID and BY combination does in Proc Print. The
value of the group variable is only displayed when it’s value changes. This report has two Group variables Serial
and Startime. The second Group variable, Startime, also has a format specification associated with it. Therefore,
the variable is only displayed when it’s formatted value changes. The last variable, CPUUtil, is defined as an
analysis variable and the average value is requested. It is important to note that the formatted value of Startime
and CPUUtil interact to calculate the average value. Since the formatted value of Startime is at the day level, all
the observations from a given day are used to calculate the reported mean. If the format specification for Startime
was changed to Datetime10. (hourly values), the reported mean value for CPUUtil would be hourly and there
would be 24 entries per day instead of the single entry.

SAS Code – Example 1
Error!
LibName VelSoft "&PathVelSoft";
ODS Html File="&PathVelSoftExample_1.html" Style=Statistical;
ODS Listing Close;
ODS Html;

Proc Report Data=VelSoft.XAMCPUBY NoWindows;
Column Serial Startime CPUUtil;
Define Serial /'Serial' Group;
Define Startime /'Date' Group Format=Datetime7.;
Define CPUUtil /'Mean Busy' Analysis Mean Format=4.1;
Where DatePart(Startime) Between '01Mar10'd and '05Mar10'd
and Serial In ('04E910','05D3A0');
Title1 "Proc Report Example 1 – List of Data with Average Calculated";
Title2 "Reporting on two zVM Instances to Save Space";
Run;

ODS Html Close;
ODS Listing;

SAS Output – Example 1

2.3.2 - Example 2 – Use of the Across Parameter and Grouping Variables
Example 2 adds the Across parameter to the Define statement and grouping variables. The Across parameter
will create a separate column for each unique value of the formatted value of the Startime variable. A comma is
used after the Startime variable on the Column statement to cause the CPUUtil variable to become nested or part
of each date value. In essence, a transform of the data is performed.

It is important to note here that the dimensions of the table are defined by the data, not procedure statements. If
the date range present in the data were increased, the number of columns would adjust to match. This becomes
an important design point in Phase 2 coding when attributes are assigned to data metric cells.

A preparatory data step is added to create grouping variables. Two variables are created using the serial number
of the CEC and are being formatted to identify LPAR names and environments. The actual Proc Format code has
been removed to save space. The report has been designed to accommodate multiple resource metrics per z/VM
instance. A resource category variable is created to indicate this will be a CPU metric. Labels are omitted
because the value of the data is now intuitive. The basic form of the dashboard is now in place.


Data XAMCPUBY;
Set VelSoft.XAMCPUBY;
LPAR = Serial; Env = Serial; Cat = 'CPU';

ODS Html File="&pathVelSoftExample_2.html" Style=Statistical;
ODS Listing Close;
ODS Html;

Proc Report Data=XAMCPUBY NoWindows;
Column Env LPAR Cat Startime, CPUUtil;
Define Env / '' Group Format=$Env.;
Define LPAR / '' Group Format=$LPAR.;
Define Cat / '' Group Format=$Cat.;
Define Startime / '' Across Format=Datetime7.;
Define CPUUtil / '' Analysis Format=4.1 Mean Width=7;
Where DatePart(Startime) Between '01Mar10'd and '05Mar10'd;
Title1 "Proc Report Example 2 - Use of the Across Parameter and Grouping Variables”;
Run;

ODS HTML Close;
ODS Listing;


2.3.3 - Example 3 – ODS Style Elements
Now that we have the basic structure in place, the presentation density will be increased to allow at least 30 days
of data to be displayed in the data matrix portion when it is displayed as a web page. ODS Style elements are
used reduce the width of a data cell to accommodate the dense presentation format desired. This example
expanded the number of days to 12 to display the output on a portrait layout printed page.


Data XAMCPUBY;
LPAR = Serial; Env = Serial; Cat = 'CPU';

ODS Listing Close;
ODS Html;

Proc Report Data=XAMCPUBY headline headskip missing
Style(Report)={Background=Black CellSpacing=1MM CellWidth=1MM}
Style(Column)={Font_Size=10PT}
Style(Header)={Foreground=Black Background=White Font_Size=10PT};
Column Env LPAR Cat Startime, CPUUtil;
Define Startime / '' Across Format=DTDate5.;
Define CPUUtil / '' Analysis Mean Format=3.;
Title1 "Proc Report Example 3 - ODS Style Elements";
Run;

ODS HTML Close;
ODS Listing;


2.4 - Summary Phase I
The development of an ‘unattributed’ dashboard is complete. For many reporting requirements, this may be all
that is needed. The second phase of the development effort will address how to add attributes to metric and
grouping cells.

2.5 - Phase II
The goal of Phase II is to assign attributes (background colors & drill down URLs) to individual cells. This
processing is done in a Compute Block. The other key concept in this phase is the use of hidden variables that
will provide the cell attribution information but do not get displayed on the report. The Compute Block is a data
step inside the reporting procedure that is targeted to a specific variable or report location. It has many functions,
but for our use it will be used to attribute specific variables. Inside the Compute Block code a Call Define
statement will be used to assign attributes. Two examples will be provided to demonstrate how this is done.

For excellent tutorials on coding compute block SAS code, please refer to the five Art Carpenter papers listed in
the reference section. These papers also can be downloaded from the SAS Global Forum website.

2.5.1 - Example 4 – Assigning a URL
Example 4 has added three items to the report program. In the data preparation data step a variable,
URL_Trend, is created to hold the URL for the trend report. This variable is created by concatenating the
resource category (in this case CPU) with the formatted value for the LPAR. To accomplish this, the formatting of
the LPAR variable from a CEC serial to a VM instance is moved up to the data step instead of being formatted as
part of the Proc Report processing. An example of the URL_Trend variable would be ‘CPU-zVM4-mth.html’. In
the Proc Report code URL_Trend is added to the column statement before the Cat variable that it is intended to
attribute. The Define statement for it has the NoPrint option which implies the variable and it values are part of
the computed data matrix for the report output, but it will not be displayed. A compute block is added at the
bottom of the procedure code for the Cat variable to make the value in the URL_Trend variable a URL attribute for
that report cell.

Data step type logic can be programmed in the Compute Block, but debugging this code is not as easy as regular
data step code. Because of this, it has been the preference of this programmer to do as much programming as
possible outside of the Compute Block. In this particular example it would have been possible to pick up the
components of the URLP value inside the Compute block by referencing other Proc Report defined variables and
build the URL value using string manipulation statements instead of passing the same information as an
additional variable. The programming decision here reflects the author’s preference.


Data VelSoft.XAMCPUBY;
Length URL_Trend $19.;

LPAR = Put(Serial,$LPAR.); Env = Serial; Cat = 'CPU';
URL_Trend = Cats(Cat,'-',LPAR,'-mth.html');

ODS Listing Close;
ODS Html;

Proc Report Data=VelSoft.XAMCPUBY headline headskip missing;
Column Env URL_Trend LPAR Cat Startime, CPUUtil;
Define URL_Trend/ '' Group NoPrint;
Define LPAR / '' Group;
Define Startime / '' Across Format=DTDate5.;
Define CPUUtil / '' Analysis Mean Format=3.;

Compute Cat;
Call Define('Cat','URLP',URL_Trend);
EndComp;

Title1 "Proc Report Example 4 - Assigning a URL";
Run;

ODS HTML Close;
ODS Listing;


2.5.2 - Example 5 – Attributing Metric Cells
Example 5 will add two attributers to each metric cell, a URL for drill down reporting and a background color.
Attributing the individuals cells in an array created by the Across parameter requires a new way to address the
variables and imposes a structural requirement for the input dataset. Other changes include creating the second
URL variable and assigning the background color for the cells. This SAS program creates the final report, a
tabular dashboard that is fully attributed. To demonstrate the background color capability, artificially low utilization
thresholds were used to show the traffic lighting capabilities. These are not the production thresholds for the
configuration items being used in the example.

A second URL is created in the preparatory data step. This URL will be the concatenation of the resource
category, the name of the LPAR and the metric date. An example of the URL_Day variable would be ‘CPU-
zVM4-04Mar10.html’. The number of these links can quickly add up. A dashboard reporting on 3 resource
categories for 50 configuration items for 30 days will create 4,500 URLs each day. This can create a bit of a
housekeeping problem. Each day will introduces a new day value and will orphan the oldest day URLs and
corresponding drill down reports from the previous run. It is prudent to include some sort of cleanup utility to
delete the contents of the destination URL folder prior to each production run to eliminate the orphaned URLs and
reporting from prior runs to accumulate. One alternative to eliminate the need for this is to use a relative cycle
number in the URL construction by subtracting the metric date from processing run date to get an offset value
instead of a date value. This eliminates the need for a cleanup utility because the values of the URL will not
change. Either option will work as long as the URL value created in the link matches the URL created for the
object it is intended to retrieve.

Summarization of the data has been moved from Proc Report to a separate Proc Summary right after the
preparatory data step. The derived metric has been changed from mean to 90th Percentile to match the
production version of this dashboard. Since this is intended to be a multiple resource dashboard, the proper color
formatting for a cell can’t be determined by a single format statement during Proc Report execution, so it will be
determined in a separate data step following the Proc Summary step by a category specific format specification.
The Data Step which creates the SAS Dataset CPU_Rept is where this processing takes place. The second
statement of the Data Step creates the background color variable, BK_Color, by formatting the variable Metric
based on a CPUFmt specification. To save space the CPUFmt SAS code has been omitted. It is a simple
assignment of a color based on ranges of values. This same data step will also be used in subsequent
processing to setup E-mail notifications.

Compute block processing for an across variable is different than processing a scalar variable because you can’t
use the variable name to address a specific instance of the array of variables that are created. To operate on a
specific instance of the across variable matrix, its column number is used. To illustrate how this works, the output
data set from Proc Report is displayed below the report output from Example 5 (this dataset is created by
specifying an Out=dataset name option on the Proc Report statement). Notice in the output dataset the first four
columns have the variable name as the column header. These variables can be referenced by their variable
name in compute block processing. However, starting with column 5, the beginning of the Across variable, the
column number is substituted for the variable name. To reference these variables, you must use the column
number. Column 7 is the first instance of the metric value, while column 5 holds the URL_Day value and column
6 holds the background color for the metric cell. Now look at the first two Call Define statements. Column 7
replaces the variable name as the first parameter, this is the destination that is going to be attributed. The first
Call Define statement assigns a background style element and uses the value in column 6 to provide the
background color. The second Call Define statement also operates on column 7 as the destination to be
attributed and assigns the value of column 5 as the URL for the drill down link. This pair of statements is
repeated 12 times, once for each occurrence of the across variable date. Each subsequent pair has their column
number incremented by 3 to match the next set of across variables to be processed.

Proc Report is not sensitive to the dimensionality of the across variable, but the Call Define statements are. If the
data has more date values than what is coded in the Call Define statements, the right hand date occurrences will
not be attributed. If the data has less date values that the number of Call Define statements that are coded, the
Call Define statements that don’t have valid data to operate on will create error messages, one for each
execution. So, it is important to keep the date range in your input dataset synchronized with the implied
dimensionality of the Call Define statements. One item to note here, the error messages associated with invalid
data for the Call Define statements do not show up as an abend condition for the mainframe version of SAS used
for much of the production reporting. Over coding the Call Define statements and just living with the error
messages is one option you may want to chose.

Data XAMCPUBY;
Length URL_Trend $19. URL_Day $23.;
Date = Datepart(StarTime); LPAR = Put(Serial,$LPAR.);
Env = Serial; Cat = 'CPU';
URL_Trend = Cats(Cat,'-',LPAR,'-mth.html');
URL_Day = Cats(Cat,'-',LPAR,'-',PUT(DATE,DATE7.),'.html');
Where Date Between '01Mar10'd and '12Mar10'd;
Proc Summary Nway Data=XAMCPUBY;
ID CAT ENV URL_Day URL_Trend;
Class LPAR Date; Var CPUUtil;
Output Out=CPU_Rpt(DROP=_TYPE_ _FREQ_) P90(CPUUtil)=Metric;
Data CPU_Rpt;
Set CPU_Rpt; Bk_Color = Put(Metric,CPUFmt.);
ODS Listing Close; ODS Html;
Proc Report Data=CPU_Rpt headline headskip missing
Column Env LPAR URL_Trend Cat Date, (URL_Day BK_Color Metric);
Define URL_Trend/ '' Group NoPrint;
Define Date / '' Across Format=Date5.;
Define URL_Day / '' Noprint;
Define BK_Color / '' Noprint;
Define Metric / '' Analysis Mean Format=3.;
Compute Cat; Call Define('Cat','URLP',URL_Trend); EndComp;
Compute Metric;
Call Define( 7 ,"style",CATS("style={background=",_C6_,"}"));
Call Define( 7,'URLP',_C5_);
Call Define(10 ,"style",CATS("style={background=",_C9_,"}"));
Call Define(10,'URLP',_C8_);
Repeating code blocks removed to save space
EndComp;
Title1 "Proc Report Example 5 - Attributing Metric Cells";
Run; Quit; ODS HTML Close; ODS Listing;


The fully attributed tabular dashboard is now completed. This particular example has the capability of reporting
on multiple resource categories for a z/VM instance. To add a second resource a separate preparatory data step,
Proc Summary and follow on data step are needed, one set for each resource. The resultant datasets are then
combined into a single input to Proc Report. No changes are needed to the reporting procedure to accommodate
the additional resource categories. A sample of the production dashboard for the z/VM configuration items is
shown below. The production program has some additional code to pick up the reporting dates and add them to
the title statement. This allows the column titles to be briefer, but still meaningful.

3.0 - Related Reporting
Connecting your dashboard to related information is a very powerful way to increase the presentation density and
allow the viewer to investigate and explore the data. Linking can be one to N layers deep. The only thing that
limits the expansion of the data is the creativity and coding perseverance of the developer. The repetitive nature
of this coding effort makes macro processing a must.

Ideally, the related reporting will use the same detail dataset you built for the construction of the dashboard. That
will simplify the link value management task because the links you need are already in the data. For the z/VM
example, both the daily drill down and the monthly trend reports can be created from the same input dataset that
was built for the dashboard. For both types of reporting, the link variable value will become a Where clause filter
to select the proper subset of the data for each specific report. The same link variable value will also become the
ODS file specification name to direct the report to the proper location so it can be subsequently retrieved from a
dashboard link. For the monthly trend report a line plot will be used. Since all the z/VM instances will use the
same plot a simple macro will be used to create this output object. This Macro uses one keyword parameter; the
name of the URL_Trend variable.
%Macro Mth_Trend(URL_Trend=);
ODS HTML Body="&URL_Trend" Path="&Path" (URL=None);
Symbol1 I=BOXJ10;
Axis1 ORDER=(&STRT_DAT TO &STOP_DAT BY DAY);
Axis2 Order=(0 to 100 by 10) Label=None;
Proc GPLOT Data=CPU;
PLOT CPUUTIL*DATE / HAXIS=AXIS1 VAXIS=AXIS2 LEGEND=LEGEND1;
LABEL CPUUTIL = "Total CPU Utilization";
Where URL_Trend = "&URL_Trend";
Title1 C=BLACK H=12 "zVM systems";
Title2 H=9 C=BLACK "CPU Percent Busy -- Fifteen Minute Interval Data";
Title3 "Box Range Spans the 25th to 75th Percentile";
Title4 "Wiskers Extend to the 90th Percentile";
Run;
%Mend Mth_Trend;

The challenge now becomes how to code the macro invocation statements. It would be possible to hard code
macro invocation statements but that creates a maintenance issue whenever there is a change to the set of z/VM
instances being reported on. A better way is to dynamically generate the macro invocation statements. Proc
SQL can be used as part of a macro to facilitate this type of dynamic code generation. It can create a list of macro
variable values from a table it reads and subsequent macro code can retrieve and use these variable values. The
example shown here creates a vector of URL_Trend variable values and places them into a list named Trend1 –
TrendNN. The Distinct option on the Select statement creates a list of unique URL_Trend values, exactly what is
needed. Once the list is created by Proc SQL, the subsequent Do Loop retrieves these values (the &&Trend&I.
value) and the macro invocation statement is generated with the z/VM instance name. For a complete discussion
of this very powerful SAS capability, refer to Carpenter’s 2007 paper, ‘List Processing Basics: Creating and Using
Lists of Macro Variables’ [Carpenter07].

This type of automated code generation permits a very large number of related reporting objects to be created
with minimal coding effort. When developing the related reporting plan for your dashboard, remember to try to
keep all the information you need in a single dataset so the reporting can be automated as demonstrated here.

%MACRO Gen_Mth_Stmt;
Proc SQL NoPrint;
Select Distinct URL_Trend
Into :Trend1 - :Trend&SYSMAXLONG
From XAMCPUBY;
Quit;
%Do I = 1 %To &SQLOBS;
%Mth_Trend(URL_Trend = &&Trend&I.);
%End;
Run;
%MEND Gen_Mth_Stmt;

4.0 - E-mail notification
Incorporating E-mail notifications into the dashboard coding is easy to do, but it does require some setup work by
the E-mail administrator at your site. Information needed to implement SAS’s SMTP E-Mail Interface is located in
two SAS manuals. SAS Language Reference: Concepts contains a general description of how the E-Mail
interface works. Platform specific implementation information is located in the SAS Companion for the platform
you are going to be using. Both of these books can be down loaded from the SAS support web portal
(www.support.sas.com). From a SAS coding perspective E-mail is an access method associated with an external
file destination. Composing an E-mail can be done as a data step activity which provides a lot of flexibility in
determining the content and distribution or procedure output can be directed to this external file location to
become the body of the E-mail.

The coding to incorporate E-mail notification takes place in two data steps. Exceptions are captured and stored in
a separate SAS dataset in the same data step that determines the background color for the metric cell.

Data CPU_Rpt Exceptions;
Set CPU_Rpt;
If Metric = . Then Metric = 0;
Bk_Color = Put(Metric,CPUFmt.);
Output CPU_Rpt;
Select (Bk_Color);
When ('lime’,’blue');
Otherwise Output Exceptions;
End; Run;

Once the exceptions have been captured, a second data step or procedure output is used to send out the E-mail
notifications. This specific example is a one-for-one business rule, each exception is sent out as an E-mail
notification, so a simple Proc Print is used and output is directed to the E-Mail destination with an ODS statement.
A more generalized and flexible approach is to use a data step and Put statements. This would allow any sort of
business rule(s) to be implemented to limit notification to those situations where there is a pattern or multiple
occasions of a particular exception. In both cases the objective is the same. The FileName statement is

configured to use EMAIL as the destination and options on the FileName statement provide the ‘wrapper’
information for the E-Mail. Fleischer’s 2001 paper ‘SAS and Electronic Mail: Send E-mail faster, and
DEFINITELY more efficiently’ [Fleischer01] provides a complete description on how to setup and use this valuable
SAS capability.

FileName MyMail EMAIL Subject=("zVM Exceptions")
TO=("CapMgmt@Gmail.Com" "zLINUXAdmin@Gmail.Com")
TYPE="TEXT/HTML";

ODS CHTML File=MyMail;
Proc Print Data=Exceptions N NOOBS;
TITLE1 "zVM Exceptions";
Run;
ODS CHTML Close;

5.0 - Summary
Tabular dashboards can be a powerful framework for the presentation of data. The discrete nature of a table
coupled with resolution granularity that ODS supports provides for a dense presentation format. Four to six
weeks of daily metrics be accommodated on a web page for a large number of configuration items and or
resource categories. Color coding of cells and drill down capabilities makes it very each to research exceptions.
All of this is available with the base SAS product.

If your audience is receptive to tabular data for management reporting, this can be a powerful framework for
presenting it.

References
[Carpenter06] Art Carpenter, “In The Compute Block: Issues Associated with Using and Naming Variables”,
Proceedings of the14th Annual Western Users of SAS Software, Inc. Users Group Conference (WUSS) 2006
[Carpenter06A] Art Carpenter, “Advanced PROC REPORT: Traffic Lighting – Controlling Cell Attributes With Your
Data”, Proceedings of the14th Annual Western Users of SAS Software, Inc. Users Group Conference (WUSS)
2006
[Carpenter07] Art Carpenter & Ron Fehd,”List Processing Basics: Creating and Using Lists of Macro Variables”,
Proceedings of the SAS Global Forum 2007 Conference
[Carpenter07A] Art Carpenter, Carpenter’s Complete Guide to the SAS® REPORT Procedure. Cary, NC: SAS
Institute Inc.
[Carpenter07B] Art Carpenter, “Advanced PROC RPORT: Getting your Tables Connected Using Links”,
Proceedings of the Pharmaceutical SAS Users Group Conference (PharmaSUG) 2007 Conference
[Carpenter07C] Art Carpenter, “Advanced PROC RPORT: Doing More in the Compute Block”, Proceedings of the
Pharmaceutical SAS Users Group Conference (PharmaSUG) 2007 Conference
[Carpenter08] Art Carpenter,”PROC REPORT: Compute Block Basics”, Proceedings of the SAS Global Forum
2008 Conference
[Fleischer01] Roy Fleischer, “SAS and Electronic Mail: Send e-mail faster, and DEFINITELY more efficiently”,
Proceedings of the Twenty-Sixth Annual SAS® Users Group International Conference 2001
[Lewandowski08] David Lewandowski, “A Step-byStep Introduction to PROC REPORT”, Proceedings of the SAS
Global Forum 2008 Conference
[Pass06] Ray Pass “So You’re Still Not Using PROC REPORT, Why Not?”, Proceedings of the SAS Global
Forum 2006 Conference
[Ralston07] Richard S. Ralston, “Using SAS/Graph to Display Performance and Capacity Data”, Proceedings of
the Computer Measurement Group, 2007
[Tufte05] Edward R. Tufte, Envisioning Information. Graphics Press, 2005 Print.
[Tufte05A] Edward R. Tufte. Visual Explanations. Graphics Press, 2005 Print.
[Tufte06] Edward R. Tufte, Beautiful Evidence. Graphics Press, 2006 Print.
[Tufte06A] Edward R. Tufte, The Visual Display of Quantitative Information. Graphics Press, 2006 Print.
.

How to build tabular dashboards using proc report

More Related Content

Similar to How to build tabular dashboards using proc report (20)

Recently uploaded (20)

How to build tabular dashboards using proc report