 | Level: Introductory Jean-Jacques Heler (jheler@us.ibm.com), Programming Consultant, IBM
28 May 2005 This article describes a method of accessing WebSphere Application Server for z/OS (WAS/z) generated SMF records directly, aggregating those records into a separate address space and providing Application Programming Interfaces (APIs) for retrieval. The target programs using these APIs are Performance Monitoring or Resource Management programs for display or monitoring purposes in real time. In particular this method has been implemented in WebSphere Studio Application Monitor (WSAM) in its monitoring of the various server instances of WAS/z.
SMF Records
System management facilities (SMF) is that part of the z/OS environment which collects and records data in an installation to provide among other things, system and subsystem profiling or users billing. This information is collected and stored into system datasets. Records in this datasets can be retrieved using SMF dump programs, which in turn output them into dump datasets. Installation-written report routines are then able to publish reports.
In addition to system supplied SMF records, individual subsytems can use SMF services to produce their own records. This is the case for Customer Information Customization Services (CICS), Database 2 (DB2), or WebSphere Application Server (WAS). Whether system or individual subsystem provided, SMF records are very standard and part of the culture of any z/OS installation.
In all cases SMF records have a standard format that the generating components (system or susbsystems) must follow. In particular SMF records are identified by their type which is a number between 00 and 120 currently, where type 00 are IPL records and 120 are OS/390 Component Broker Performance Statistics. In addition SMF records can be further broken down into subtypes for more granularity. For instance record type 84 JES3 Monitoring Facility (JMF) data is subdivided into 10 subtypes. Subtype 7 in record 84 for instance contains JES3 Internal Reader DSP Analysis.
Operating System Generated Records
Operating system records whether job or system related provide information about workload, paging activity,and CPU time, dataset activity for jobs, programs, or TSO/E sessions. A good example of such records would be Resource Measurement Facility (RMF) records for Monitor II activity, which are also known as SMF records type 79. They include address space state and resource data, storage/processor data, device activity, page data set activity, I/O Queuing activity, etc. For more information about SMF or RMF records see z/OS V1R5.0 MVS System Management Facilities (SMF). This document is for z/OS V1R5.0, but there is such a document for each release of the MVS operating system.
Subsystems Records
These are SMF records generated by MVS subsystems like CICS, DB2, MQSeries, TCP/IP, DB2, or WAS/z. They require that those subsystems do their own monitoring and produce specific SMF records (i.e., of a specific type). Usually the record generation is optional because it requires some overhead. For instance types 100 through 102 are DB2 related, 103, HTTP Server, 110, CICS, 115 and 116, MQSeries. WAS/z can produce such records upon request. These records are SMF records type 120 (hexadecimal 78).
WAS/z Generated SMF Records. Record Type 120. WAS/z Performance Statistics
WebSphere Application Server for z/OS can produce SMF records 80 and SMF records 120. SMF records 80 are security related, whereas SMF records 120 are performance related. We will concentrate on records 120 which provide useful information on the number of transactions that have run, their completion time, information on clients (active or not) attached to each server instance. In addition records 120 provide some application profiling with timing information on its components. Two types of SMF records 120 can be generated: activity records and interval records.
- Activity records are produced when each activity within a server is completed, whether it is a server or user-initiated transaction.
- Interval records are produced at installation-specified intervals and provide performance and resource information.
With WAS/z release 5.x, six record subtypes (activity or interval) are produced. They are briefly described in this section. For all practical purposes, we will limit ourselves to interval records (subtypes 3, 6, and 8). Disabling/enabling SMF recording and their subtypes and Interval can be specified on the WAS/z console. For more information about SMF records 120 see WebSphere Application Server for z/OS, Version 5.1.x, Information center.
Subtype 1: Server activity record
They mostly contain information about each activity that occured within one server.
Subtype 3: Server interval record
They contain aggregated information about all activities that occured during the specified server interval. For instance, the number of bytes that have been exchanged between clients and server, the number of active local and remote communications, as well as the total CPU time accumulated by the WLM enclaves.
Subtype 5: J2EE container activity record
They consist of information about all beans and corresponding methods involved in this activity.
Subtype 6: J2EE container interval record
They consist of aggregated information about all bean and corresponding methods activities that occured during the specified interval. Information like the minimum, maximum, or average response time for each bean method, as well as the minimum, average, minimum cpu time.
Subtype 7: Web Container activity record
They consist of information about all HTTP sessions, WebApplications and Servlets involved in this activity.
Subtype 8: Web Container interval record
They contain aggregated information about all HTTP sessions, WebApplications and Servlets that occured during the specified interval. The HttpSessionManager section includes the numbers of created, invalidated, or active sessions, with some statistics about active, live, or invalidated sessions. The WebApplications and Servlets section basically contains servlet response time and cpu information.
Accessing SMF Records 120 Directly, Aggregating and Storing Them
Rather than relying on SMF dump programs and installation-written routines to retrieve and publish reports on SMF records, it is possible to access these records directly as they are being generated and written to the system datasets. Accessing these records "on the fly" allows one to have immediate information on the activity that occured in the previous intervals. These records can be assembled, sorted, aggregated, stored and updated in real time. As the number of intervals grow, records can be summarized and totals, moving averages, maxima, minima, or statistics over longer period produced. Also check-points can be established when records cease to be accumulated, current values stored, and counter resets. This can be done at specified times during the day, or systematically once a day (like midnight). In order to achieve such a feature, we need:
- A way to intercept the creation of the SMF records we are interested in. In our case SMF records 120, subtypes 3, 6, and 8 (interval records).
- A place to store and aggregate the records so obtained. This place could be a direct access medium or an in-memory location, allowing more efficient and flexible access.
- Some APIs to selectively retrieve and display their contents, and also to permanently store and reset the statistics, if they were kept in memory.
Writing your own IEFU83
SMF supplies exits that receive control at critical points during SMF events. The SMF record exit IEFU83 receives control before each record is written to an SMF data set. Upon return from the exit records can subsequently written or the writing can be suppressed. By setting up some system commands in the PARMLIB member used during IPL of the system, you can substitute your own routine and instruct SMF to give control to it. See z/OS V1R5.0 MVS System Management Facilities (SMF) for more information about using IEFU83 to access SMF records directly as they are about to be written.
Below is an example of a IEFU83 routine written in MVS assembler which intercepts WAS/z generated 120 records subtypes 3, 6, and 8.
Listing 1. A sample IEFU83 routine
CYN1FU83 CSECT
CYN1FU83 AMODE 31
CYN1FU83 RMODE ANY
$AENTER WORK=R13,ZERO=N,VER=03.02.00
EJECT
*---------------------------------------------------------------------*
* GET SMF RECORD AND PARSE IT *
*---------------------------------------------------------------------*
SPACE
LTR R1,R1 ANYTHING THERE ?
BNZ GETREC OKAY PROCEED
B LEAVE0 SORRY CAN'T GO ON
GETREC DS 0H
L R10,0(,R1) POINT TO SMF RECORD
LH R2,0(,R10) RECORD LENGTH
LTR R2,R2 ANYTHING THERE ?
BZ LEAVE0 NO, RETURN
SPACE
PARSHDR DS 0H
USING SMFHDR,R10 BASE THE SMF HEADER (RDW)
CLC SM120RTY,=AL1(SM120VAL) SMF RECORD 120 ?
BNE LEAVE0 NO, RETURN
CLC SM120RST,=AL2(SM120RWI) SUBTYPE 8 ?
BE CALLAPI YES, GO PROCESS RECORD
CLC SM120RST,=AL2(SM120RJ2) SUBTYPE 6 ?
BE CALLAPI YES, GO PROCESS RECORD
CLC SM120RST,=AL2(SM120RSI) SUBTYPE 3 ?
BE PARSHDR3 YES - DO SOME MORE FILTERING
BLEAVE0 NO - RETURN
SPACE
PARSHDR3 DS 0H
USING SM120SES,R11 BASE SERVER INTVL SECT.
L R11,SM120SIS OFFSET TO IT FROM RDW
AR R11,R10 SERVER INTERVAL SECTION ADDR
CLC SM120STY,=A(SM120STJ) J2EE SERVER ?
BNE LEAVE0 NO - RETURN
SPACE
*---------------------------------------------------------------------*
* PREPARE INPUT AND CALL CYN1CALL *
*---------------------------------------------------------------------*
SPACE
CALLAPI DS 0H
MVI XMPMKFUN,XMPMKCRR SET FUNCTION CODE
ST R10,XMPMPRM1 STORE RECORD ADDR IN XMPARM
LA R4,XMPARM GET ADDRESS OF XMPARM
ST R4,PARMLIST STORE IT IN PARMLIST
LA R1,PARMLIST R1 POINTS TO PARMLIST
LINK EP=CYN1CALL,ERRET=LNKERROR INVOKE CYN1 API
B CONTINUE CONTINUE IF IT WORKS
LNKERROR DS 0H
WTO 'CYNS0037E: ERROR LINKING TO CYN1CALL FROM CYN1FU83 ' X
CONTINUE DS 0H
TM XMPMKRTC,X'80' RETURN CODE HI BIT SET?
BZ LEAVE0 NO - WRITE SMF RECORD
LA R15,4 YES - DO NOT WRITE
B LEAVE AND LEAVE
SPACE
*---------------------------------------------------------------------*
* RETURN TO CALLER *
*---------------------------------------------------------------------*
SPACE
LEAVE0 DS 0H
* XR R15,R15 SET RETURN CODE = 0
LA R15,0 SET RETURN CODE = 0
LEAVE DS 0H
SPACE
DROP R11
DROP R10
$ALEAVE
EJECT
*
* PROGRAM CONSTANTS AND LITERALS
*
SPACE
LTORG
SPACE
*
* MAPPING MACROS AND DSECTS FOLLOW
*
$AEND
$WORK
$XMPARM DSECT=NO
PARMLIST DS A PARAMETER LIST FOR CYN1CALL
$WORK END
$REGS
EJECT
$SMF120
END
|
Service Address Space
In the CYN1FU83 routine example above, we can see that after retrieving the WAS/z interval records, the routine links to a program called CYN1CALL. This program actually selects a service routine based on a function code among a set of pre-defined routines. These routines are accessed through cross-memory services and run in a separate address space. This address space, called the service address space is host to the various SMF records.
The service address space is an MVS subsystem which allows external programs running in separate address spaces to access service routines cross-memory. Some of these routines invoked by CYN1FU83 take the SMF records and store them in the service address space memory.
Storage organization
When stored in the service address space, records are organized in such a fashion that they can be retrieved easily. The retrieval structure is composed of:
- A server directory. There is an entry for each WAS/z server instance running in the same LPAR (z/OS platform).
- In each entry a set of pointers to SMF records: server interval records, J2EE container interval records, Web container interval records. Rather than stored individually, records of the same subtype are aggregated and summarized.
How Records are aggregated and statistics combined
As collection intervals are added, records of the same subtype are dynamically aggregated, cumulated, and summarized; therefore the duration of the interval to which the aggregated statistics apply increases. This implies that each record entry contains cumulated statistics. For instance if records are produced every 2 minutes, after 30 such intervals the aggregated records will contain statistics relative to one hour period, after 60, two hours, and so on. A value containing the total number of beans that were run, will be accumulated and that value will contain the total number of beans that were run over a period of several 2 minute intervals.
Record field aggregation depends on the contents of the field. The field contains either a total, a maximum, or a minimum of a quantity over the interval. It can also contain the value of the quantity at the end of the interval. Let A(i) be the current value in the field after i intervals, N(i) the number of samples that resulted in that value being A(i) after i intervals, a(i+1) the marginal value and n(i+1) the additional number of samples between intervals i and i+1.
- If the field contains a total: A(i+1) = A(i) + a(i+1)
- If the field contains an average: A(i+1) = ( A(i)*N(i) + a(i+1)*n(i+1) ) / ( N(i) + n(i+1) )
- If the field contains a maximum: A(i+1) = MAX(A(i),a(i+1))
- If the field contains a minimum: A(i+1) = MIN(A(i),a(i+1))
- If the field contains the value at the end of the interval: A(i+1) = a(i+1)
Creating APIs to access individual records
As described in the section above, WAS/z SMF records 120 subtypes 3, 6, and 8 are captured real time and stored in a separate service address space where they are aggregated, summarized and stored. In addition to storing and aggregating routines, the service address space contains retrieval routines, which can also be invoked through cross memory services, via the CYN1CALL program described above. Since it would be inconvenient to use cross-memory services for programs written in high-level languages like C or C++,the CYN1CALL is "wrapped" with high-level language glue routines constituting external APIs. For instance a program written in C will invoke these APIs by dynamically loading them or being statically bound to them. These APIs will invoke CYN1CALL and pass the right function and parameters. CYN1CALL will invoke the corresponding retrieval routine running in the service address space via cross-memory services. The retrieval routine will copy the section of the requested records from the service address space to the target area specified as a parameter in the API.
C/C++ API Header File
Below is the header file that the C/C++ APIs use. They closely map the SMF 120 records subtypes 3, 6, and 8.
Listing 2. Header file
/*
* $RCSfile: SMFAPI.h,v $
*
* Copyright (c) 2002-2005 IBM Corp.
* All rights reserved.
*
*/
#ifndef SMFAPI_H
#define SMFAPI_H
struct ServerSection
{
/* Server section information */
unsigned long long sm120sst[2];
/* Time sample began in STCK390 format */
unsigned long long sm120set[2];
/* Time sample ended */
int sm120ngt;
/* Number of global transactions having run thru
and initiated by the server instance during the
interval. */
int sm120nlt;
/* Number of local transactions initiated by the server
instance during the interval. */
int sm120ncs;
/* Number of existing communication sessions at the
end of the interval */
int sm120nca;
/* Number of communication sessions active during
the interval. */
int sm120nls;
/* Number of existing local communication sessions
at the end of the interval. */
int sm120nla;
/* Number of active local communication sessions
having been attached and active within the server
instance during the interval. */
int sm120nrs;
/* Number of existing remote communication sessions
at the end of the interval . */
int sm120nra;
/* Number of active remote communication sessions
having been attached and active within the server
instance during the interval. */
unsigned int sm120bts;
/* Number of bytes that transferred to the
server from all attached clients. */
unsigned int sm120bfs;
/* Number of bytes sent from the server to all
attached clients. */
unsigned int sm120btl;
/* Number of bytes transferred to the server
from all locally attached clients. */
unsigned int sm120bfl;
/* Number of bytes transferred from the server
to all locally attached clients. */
unsigned int sm120btr;
/* Number of bytes transferred to the server
from all remotely attached clients. */
unsigned int sm120bfr;
/* Number of bytes transferred from the server
to all remotely attached clients. */
int sm120nsess;
/* Number of HTTP communication sessions that exist
at the end of the interval (4 byte integer) */
int sm120nsessactive;
/* Number of HTTP communication sessions that
have been attached and active within the
server instance during the interval
(4 byte integer) */
unsigned int sm120nserverbytes;
/* Number of bytes that have been
transferred to the server from all
HTTP attached clients (4 byte unsigned
integer) */
unsigned int sm120nclientbytes;
/* Number of bytes that have been transferred
from the server to all HTTP attached
clients (4 byte unsigned integer) */
long long wlmcpu;
/* Total CPU time accumulated by the
WLM enclaves (it says long long 8 byte integer).
I will check whether it can be expressed in ms
and therefore be reduced to a 4 byte integer. */
int sm120nbs;
/* Number of bean sections */
};
struct BeanSection
{
/* Bean section entry; one per bean */
char sm120jb1[512];
/* AMCName of container activated bean
(only rightmost 256 charaters- Unicode)
unsigned int sm120jb2[15];
/* UUID based AMC name. */
int sm120jb3;
/* Bean.s type. 0:CMP entity bean
1:BMP entity bean
2: stateless session bean
3: stateful session bean . */
int sm120jb456[3];
/* Reserved */
int sm120jb7;
/* Bean.s reentrance within transaction
policy.
0: not reentrant
1: reentrant. */
int sm120jb8jmc6[3];
/* Reserved */
int sm120jb9;
/* Number of associated methods. */
};
struct ejbtriple
{
/* ejb operation statistics. */
int numInvocations;
/* Number of invocations. */
int avgExecTime;
/* Average execution time. */
int maxExecTime;
/* Maximum execution time. */
};
struct BeanMethodSection
{
/* Bean method section entry;
one per method */
char sm120jm1[1024];
/* Name of the method including its
signature in human-readable form
(only leftmost 512
characters). Unicode format. */
int sm120jm2;
/* Number of times method was invoked
during the interval. */
int sm120jm3;
/* Average response time in milliseconds. */
int sm120jm4;
/* Maximum response time in milliseconds. */
int sm120jm5;
/* Bean method.s transaction policy:
0: TX_NOT_SUPPORTED
1: TX_BEAN_MANAGED
2: TX_REQUIRED
3: TX_SUPPORTS
4: TX_REQUIRES_NEW
5: TX_MANDATORY
6: TX_NEVER */
int sm120jm89[2];
/* Reserved */
char sm120jma[512];
/* List of ejbRoles associated with method
separated with .;. up to 256 characters.
Unicode format */
int sm120jmbd[2];
/* Reserved */
struct ejbtriple ejbLoad;
/* ejbload statistics. */
struct ejbtriple ejbStore;
/* ejbstore statistics. */
struct ejbtriple ejbActivate;
/* ejbActivate statistics. */
struct ejbtriple ejbPassivate;
/* ejbPassivate statistics. */
// New for v212
char averageCpu[8];
/* Average cpu time in ms (8 bytes) */
char minCpu[8];
/* Minimum cpu time in ms (8 bytes) */
char maxCpu[8];
/* Maximum cpu time in ms (8 bytes) */
};
struct HttpSessionManagerSection
{
/* Http session manager information */
int sm120wif;
/* Number of http sessions that
were created. */
int sm120wig;
/* Number of http sessions that were
invalidated. */
int sm120wih;
/* Current number of http sessions that
are actively referenced */
int sm120wii;
/* Minimum number of active http sessions
during the interval */
int sm120wij;
/* Maximum number of active http sessions
during the interval */
int sm120wik;
/* Average lifetime (in milliseconds) of
invalidated http sessions */
int sm120wil;
/* Average time (in milliseconds) required
to invalidate sessions */
int sm120wim;
/* Number of sessions that were finalized. */
int sm120win;
/* Total number of http sessions being
tracked by the server */
int sm120wio;
/* Minimum number of live http sessions
during the interval */
int sm120wip;
/* Maximum number of live http sessions
during the interval */
int sm120nws;
/* Number of Web application sections. */
};
struct WebApplicationSection
{
/* Web application section entry;
one per application */
char sm120wiq[256];
/* The WebApplication name. Unicode format. */
int sm120wir;
/* Number of servlets that were loaded */
int sm120wis;
/* Number of associated servlets */
};
struct ServletSection
{
/* Servlet section entry; one per servlet */
char sm120wiw[256];
/* The servlet name. Unicode format. */
int sm120wix;
/* Number of times the servlet service was
requested during the interval. */
int sm120wiy;
/* Average response time in milliseconds. */
int sm120wiz;
/* Minimum response time in milliseconds. */
int sm120wj1;
/* Maximum response time in milliseconds. */
int sm120wj2;
/* Number of errors that were encountered
during servlet execution. */
char sm120wj3[16];
/* Timestamp when the servlet was loaded.
Alphanumeric. */
// New for v212
char averageCpu[8];
/* Average cpu time in ms (8 bytes) */
char minCpu[8];
/* Minimum cpu time in ms (8 bytes) */
char maxCpu[8];
/* Maximum cpu time in ms (8 bytes) */
};
struct AppServer
{
/* Application server specification
triplet. */
char HostNm[65];
/* WebSphere for z/OS transaction
server host name. Null terminated */
char ServerNm[9];
/* Websphere for z/OS transaction
server name. Null terminated */
char InstanceNm[9];
/* Websphere for z/OS transaction
server instance name. Null terminated */
};
struct xmparm
{
char xmpmkeye[16];
/* Reserved */
char xmpmkfun;
/* Primary function code:
'\x03': Get server section
'\x04': Get bean section(s)
'\x05': Get bean method section(s) */
char xmpmkres[3];
/* Reserved */
void *xmprm[6];
/* Parameters to CYN1CALL */
int xmpmkrtc;
/* Primary return code */
int xmpmkreq;
/* Reserved (XM unique request number) */
};
#endif
|
C/C++ API List and Description
GetServerSection
short int GetServerSection ( struct AppServer *AS, int locale,struct ServerSection *SS );
Copies the current server section to the area pointed to by SS for the application server instance defined by the structure pointed to by AS. The application server instance structure is assumed to contain EBCDIC characters if locale=0, or ASCII characters if locale=1.
Return Values:
- 1: Success
- 0: NoApp (App Server information not found)
- -2: NotFound (Server section not found)
- -3: Protection (Invalid target address or improper target length)
- -4: NotAvailable (Repository address space not running or not ready)
GetBeanSections
short int GetBeanSections ( struct AppServer *AS, int locale, int first, int num,struct BeanSection *BS );
Copies a specific number of bean section entries to the area starting at the location pointed to by BS for the application server instance defined by the structure pointed to by AS. The application server instance structure is assumed to contain EBCDIC characters if locale=0, or ASCII characters if locale=1. first identifies the rank of the first bean section entry to be copied, and num the number of bean section entries.
Return Values:
- n: Success (n = number of bean section entries copied, n <= num)
- 0: NoApp (App Server information not found)
- -2: NotFound (No bean section entries for the specified range: first is negative or greater than max , or num is non positive)
- -3: Protection (Invalid target address or improper target length)
- -4: NotAvailable (Repository address space not running or not ready)
GetBeanMethodSections
short int GetBeanMethodSections ( struct AppServer *AS, int locale, char *AMC,int first, int num,struct BeanMethodSection *BMS );
Copies a specific number of bean method section entries to the area starting at the location pointed to by BMS; the bean methods are all defined for the same bean defined by the character string pointed to by AMC. The bean character string is 512 characters long in Unicode format starting with the 256 rightmost characters. The request is made for the application server instance defined by the structure pointed to by AS. The application server instance structure is assumed to contain EBCDIC characters if locale=0, or ASCII characters if locale=1. first identifies the rank of the first bean method section entry to be copied, and num the number of bean method section entries.
Return Values:
- n: Success (n = number of bean method section entries copied, n <= num)
- 0: NoApp (App Server information not found)
- -1: Notthere (Bean information not found)
- -2: NotFound (No bean method section entries for the specified range: first is negative or greater than max , or num is non positive)
- -3: Protection (Invalid target address or improper target length)
- -4: NotAvailable (Repository address space not running or not ready)
GetHttpSessionManagerSection
short int GetHttpSessionManagerSection ( struct AppServer *AS, int locale,struct HttpSessionManagerSection *HSMS );
Copies the current Http session manager section to the area pointed to by HSMS for the application server instance defined by the structure pointed to by AS. The application server instance structure is assumed to contain EBCDIC characters if locale=0, or ASCII characters if locale=1.
Return Values:
- 1: Success
- 0: NoApp (App Server information not found)
- -2: NotFound (Http session manager section not found)
- -3: Protection (Invalid target address or improper target length)
- -4: NotAvailable (Repository address space not running or not ready)
GetWebApplicationSections
short int GetWebApplicationSections ( struct AppServer *AS, int locale, int first,int num, struct WebApplicationSection *WAS );
Copies a specific number of Web application section entries to the area starting at the location pointed to by WAS for the application server instance defined by the structure pointed to by AS. The application server instance structure is assumed to contain EBCDIC characters if locale=0, or ASCII characters if locale=1. first identifies the rank of the first Web application section entry to be copied, and num the number of Web application section entries.
Return Values:
- n: Success (n = number of Web application section entries copied, n <= num)
- 0: NoApp (App Server information not found)
- -2: NotFound (No Web application section entries for the specified range: first is negative or greater than max , or num is non positive)
- -3: Protection (Invalid target address or improper target length)
- -4: NotAvailable (Repository address space not running or not ready)
GetServletSections
short int GetServletSections ( struct AppServer *AS, int locale, char *WIQ,int first, int num,struct ServletSection *SVS );
Copies a specific number of servlet section entries to the area starting at the location pointed to by SVS; the servlets are all defined for the same Web application defined by the character string pointed to by WIQ. The Web application name character string is 256 characters long in Unicode format. The request is made for the application server instance defined by the structure pointed to by AS. The application server instance structure is assumed to contain EBCDIC characters if locale=0, or ASCII characters if locale=1. first identifies the rank of the first servlet section entry to be copied, and num the number of servlet section entries.
Return Values:
- n: Success (n = number of servlet section entries copied, n <= num)
- 0: NoApp (App Server information not found)
- -1: Notthere (Web application information not found)
- -2: NotFound (No servlet section entries for the specified range: first is negative or greater than max , or num is non positive)
- -3: Protection (Invalid target address or improper target length)
- -4: NotAvailable (Repository address space not running or not ready)
ResetSmfStatistics
short int ResetSmfStatistics(struct AppServer *AS, int locale);
Normally as SMF statistics are collected on a regular interval basis, they are accumulated/averaged with existing statistics as the new interval is added to the previous intervals for all server instances in the SYSPLEX node. This function will stop the current accumulation: i.e., the next collected statistics will overwrite the existing data and a new series of accumulated statistics is started for the application server instance defined by the structure pointed to by AS. The application server instance structure is assumed to contain EBCDIC characters if locale=0, or ASCII characters if locale=1.
Return Values:
- 1: Success (next SMF collected statistics will overwrite existing data)
- 0: NoApp (App Server information not found)
- -3: Protection (Invalid target address or improper target length)
- -4: NotAvailable (Repository address space not running or not ready)
WSAM examples with screenshots
Tivoli WebSphere Studio Application Monitor (WSAM) uses such APIs to display SMF records. These records are retrieved from the service address space and refreshed periodically. Below are some sample screen shots from the WSAM Visualisation Engine (VE) which display SMF records for a specific server instance. As described above, data are accumulated and summarized and apply to the monitored period (interval) displayed in the snapshot info frame. Note that the length of the monitored period increases as the number of records increases as noted above, until the statistics are reset.
The first page gives a graphical summary of the system resources, with links to pages containing data from subtype 3 records (Server), subtype 6 records (EJBs), and subtype 8 records(Servlet Session Manager and Web Applications.)
Figure 1. System Resource Overview
Clicking on the Server link leads to the Server Detail page below, which contains aggregated statistics (transaction, session, traffic, and CPU information) for the selected server.
Figure 2. Server Detail
In order to get more information about EJB activity during the monitored period for that server, one can click on the EJBs link which leads to the EJB Summary page. The EJB Summary page gives the list of EJBs which ran during the monitored period. In addition, the page computes the average response for each EJB and plots a table of the top 5 worst performers.
Figure 3. EJB Summary
Additional information about a specific EJB can be obtained by clicking that EJB link. This leads to the EJB Method Summary page, which gives summarized performance information on each of the methods invoked during the execution of that EJB.
Figure 4. EJB Method Summary
Clicking on the Servlet Session Manager link leads to the Servlet Session Manager Detail page below, which contains aggregated servlett session statistics for the selected server.
Figure 5. Servlet Session Manager Detail
In order to get more information about servlet activity during the monitored period for that server, one can click on the Web Applications link which leads to the Web Application Summary page. The Web Application Summary page gives the list of servlets which ran during the monitored period. In addition, the page computes the average response for each servlet and plots a table of the top 5 worst performers.
Figure 6. Web Application Summary
Additional information about a specific servlet can be obtained by clicking on that servlet link. This leads to the Web Application Detail page, which gives detail performance information (response and CPU time and the number of requests) for that servlet during the monitored interval.
Figure 7. Web Application Detail
About the author | | | Jean-Jacques Heler joined IBM in August 2005 after the purchase of Cyanea Systems, where he held the position of Vice President, z/OS Engineering. Prior to working
at Cyanea, Jean-Jacques was the CTO of Cedera Systems, that he joined after holding several
senior technical positions at Schwab, Sun Microsystems, and other technology companies. He served as an international consultant for more than 20 years prior to that. He holds an Engineering degree from Ecole Nationale Superieure des Mines de Paris, an M.S. in Computer Science from Stanford University, and a PHD in mathematics from University of Paris. |
Rate this page
| |
