IBM Cognos Proven Practices: Monitoring IBM Cognos 8 BI in the z/OS Environment – An Introduction

Nature of Document: Guideline; Product(s): IBM Cognos 8 BI version 8.4.1; Area of Interest: Infrastructure

Using various z/OS tools to monitor IBM Cognos 8 BI and supporting applications such as WebSphere and DB2.

Share:

Thuy Nguyen , Software Engineer, IBM

Thuy Nguyen is a software engineer at the Silicon Valley Laboratory in San Jose, California. Prior to joining SVL, Thuy worked in IBM Global Services as a DB2 LUW DBA for 8 years. After that, she worked on the InfoSphere performance test team at SVL for 3 years where she scalability testing of DataStage on Linux for zSeries. She has been with the Cognos Solution Test team for over 2 years now where she has worked solution testing of various scalability, performance, stability, and test driver issues.



Ann Jackson, IT Architect, IBM

Ann Jackson is an IT architect with IBM with too many years to name with experience in business systems implementation, business analytics and data technologies. She is valued by clients for not only recommending leading edge technologies, but also designing and implementing these technologies with them to deliver total business solutions yielding significant return on investment.



Tim Lighter, Software Developer

Tim Lighter currently works on the IBM Cognos zSeries offering team and is responsible for leading its Solutions Test group. During his 30 years with IBM, Tim has enjoyed fixing problems and making things go faster and has been fortunate to have plenty of opportunities to do so starting out in IBM internal I/T, as a large systems SE and database specialist, in IBM Global Services as an I/T architect, principal and delivery manager, and working on the zSeries benchmarking team in Advanced Technical Support.



17 May 2012

Introduction

Purpose

This paper provides an introduction to monitoring the performance of IBM Cognos 8 BI 8.4.1 in the z/OS environment. Its purpose is to:

  • Provide a common high level understanding of IBM Cognos 8 BI
  • Describe some of the available performance monitoring tools
  • Document the basics of performance management for IBM Cognos 8 BI running on z/OS versus open systems and provide information on some of the techniques we’ve used to address the requirement to monitor IBM Cognos 8 BI running in the z/OS UNIX System Services (USS) environment (also known as OMVS or Open MVS).

The z/OS tools used for monitoring are:

  1. Resource Management Facility (RMF)
  2. System Display and Search Facility (SDSF)
  3. System Management Facilities (SMF)
  4. IBM Tivoli OMEGAMON XE for DB2 Performance Expert on z/OS

The targeted audience for this paper are those with deep IBM Cognos 8 BI experience that are new to the z/OS platform and those that are new to IBM Cognos 8 BI but have a strong background in z/OS and/or DB2. The reader is assumed to have a rudimentary understanding of basic z/OS concepts of resource usage (service units) and control (address spaces/jobs, service levels, workload manager (WLM)), IBM WebSphere Application Server or Apache Tomcat, and DB2. A valuable set of IBM Redbooks that provides a wide breadth of introductory material on z/OS can be found here: http://www.redbooks.ibm.com/cgi-bin/searchsite.cgi?query=ABCs.

Applicability

IBM Cognos 8 BI version 8.4.1 running under z/OS.

Exclusions and Exceptions

There are no known exclusions or exceptions at the time this document was written.


Basic Cognos Architecture

The IBM Cognos 8 BI Platform is built on a web-based service oriented architecture (SOA), designed for scalability, availability and openness. This n-tiered SOA has three tiers: Web, Application and Data.

Web Tier

IBM Cognos 8 BI Gateway

The IBM Cognos 8 BI Gateway component manages all web communication for the IBM Cognos 8 BI platform. The workload on the IBM Cognos 8 BI Gateway server is comparatively lightweight, therefore it requires minimal processing resources. With IBM Cognos 8 BI for z/OS, the Gateway may be implemented in an external HTTP component such as the IBM HTTP Server or within the application server but IBM Cognos 8 BI for z/OS achieves best performance with reduced system resources when the web communication is handled within the application server. This is known as the dispatcher direct method and, as shown below, the external HTTP component is effectively handled by the Application Server.

Figure 1: IBM Cognos 8 BI for z/OS with web communications being handled directly by the Dispatcher component within the application server
Figure 1: IBM Cognos 8 BI for z/OS with web communications being handled directly by the Dispatcher component within the application server

Application Tier

The application tier for the IBM Cognos 8 BI platform is made up of three main server components; the Content Manager, Dispatchers, and Report Servers. These execute within either IBM WebSphere Application Server (WAS) or Apache Tomcat. Report Servers are composed of a collection of Java and C++ based services. The IBM Cognos 8 BI Java based services run within IBM WebSphere Application Server, the C++ based services run within z/OS Unix System Service (USS). USS is a certified UNIX system which has been integrated into z/OS with all the features and functionality found within UNIX.

IBM Cognos 8 BI Dispatcher

IBM Cognos 8 BI Dispatcher performs the load balancing of requests at the application tier. The Dispatcher component is a lightweight Java servlet that manages and provides communication between application services. At startup, each Dispatcher registers locally available services with the IBM Cognos 8 BI Content Manager. During the normal operation of IBM Cognos 8 BI services, requests are load balanced across all available services by using a configurable, weighted round-robin algorithm to distribute requests. You can tune the performance of IBM Cognos 8 BI by defining how each Dispatcher handles requests and manages services.

IBM Cognos 8 BI Report Server

The main service that is responsible for application-tier processing is the report or query service. These are also referred to as the BIBus processes. The Dispatcher starts Report Server processes (may be referred to as RSPs which also include the BIBus processes) dynamically as needed to handle the request load. An administrator can specify the maximum number of processes that these services can start as well as the minimum that should be running at non-peak times. When configuring the IBM Cognos 8 BI server environment, a Java heap size must be set. The IBM Cognos 8 BI reporting and query service is made up of two underlying components — the Java servlet-based Dispatcher services and C++ report services that are launched using the Java Native Interface (JNI). Set the Java Virtual Machine (JVM) heap-size allocation for IBM Cognos 8 BI so that Java memory is only as large as is necessary to accommodate the processing requirements of the Java based services. This ensures that as much memory as possible is available to the IBM Cognos 8 BI reporting service which is not Java. Optimal Java heap size can be determined though use of Java garbage collection statistics reported by the application server.

IBM Cognos 8 BI Content Manager

Content Manager is the IBM Cognos 8 BI platform service that manages the storage of customer application data, including security, configuration data, models, metrics, report specifications and report output. Content Manager is needed to publish models, retrieve or store report specifications, handle scheduling information and manage the Cognos security namespace. Content Manager maintains information in a relational database that is referred to as the Content Store database. DB2 for z/OS, version 9 or later, is the only supported database product for the Content Store database. A minimum of one Content Manager service is required for each IBM Cognos 8 BI implementation cluster of report servers/address spaces. While multiple Content Mangers may be implemented in a single cluster, only one may be active. Any additional Content Managers are in standby mode for failover.

Data Tier

IBM Cognos 8 BI data-source performance

Query performance is typically bound to the performance of the server that hosts the data source for IBM Cognos 8 BI. IBM Cognos 8 BI for z/OS data sources must be DB2 for z/OS or IBM Cognos PowerCubes. Relational data sources that are tuned to meet the access requirements of the business community naturally perform better than those that are not. DB2 for z/OS databases should be monitored and tuned by an experienced database administrator to achieve optimum BI performance.


Monitoring IBM Cognos 8 BI with z/OS tools

Resource Management Facility (RMF)

The IBM z/OS environment provides excellent resource usage statistics through the Resource Management Facility (RMF) subsystem or an equivalent tool. RMF is shipped with every release of z/OS as an optional product.

The operational usage data is initially collected as System Management Facility (SMF) records. Most clients use this information for charge back and capacity planning efforts. There can be overhead in collecting all the information available, so clients will typically collect only a subset of the records that are needed to satisfy their requirements. The reports created from the selected SMF records are typically generated after the fact (normally customers “print” them overnight) so while they can help track resource consumption, it is generally a historical perspective rather than real time monitoring. RMF does include two facilities to monitor applications in “real time” through both TSO/E and ISPF. TSO/E stands for Time Sharing Option Extended and is a command line tool which allows a user to access programs and data on a z/OS system. ISPF stands for Interactive System Productivity Facility and is a menu driven alternative to TSO/E with similar functionality. In addition, a Windows workstation GUI based version, RMF PM is also available at the following URL,

http://www-03.ibm.com/systems/z/os/zos/features/rmf/product/components.html.

When discussing RMF reporting you will generally see it broken into 3 topics:

  • RMF Monitor I sessions – provide long term data collection for system workload and resource utilization. The Monitor I (Mon I) session is continuous, and measures various areas of system activity over a long period of time.
  • RMF Monitor II sessions - provide online measurements on demand for use in solving immediate problems. A Monitor II (Mon II) session can be regarded as a real time snapshot session. Unlike the continuous Monitor I session, a Monitor II session generates a requested report from a single data sample.
  • RMF Monitor III sessions – provide short term data collection and online reports over a period of time spanning multiple data samples for continuous monitoring of system status and solving performance problems. Monitor III (Mon III) is a good place to begin system tuning.

For purposes of monitoring an application while it is running, RMF Monitor II and III are a good starting point. While Monitor II sessions can be started from TSO, we recommend that you use the ISPF interface since both Monitor II and Monitor III sessions can be run using that interface (the valuable Monitor III is not accessible via TSO/E). ISPF also allows you to use split screen techniques to view multiple aspects of the performance picture simultaneously and provides a useful tutorial for the new user. For those inclined to use native TSO/E, Appendix B provides examples of how to produce some of the same screens shown in this section.

RMF ISPF Monitor

To use the RMF ISPF monitor, determine how your site has ISPF tailored so you will know which options to select in order to access the main RMF menu, which is shown below. ISPF has a basic menu with numerical options 1 though 8, but provides the capability of adding options via alphanumerical characters to this basic menu. Customers typically will add one or more options which will take you to additional panels which provide more options for specific z/OS functions or other products, such as RMF.

Before starting with ISPF screenshots, first a word about their layout. The screenshots are the Personal Communications product from IBM, a workstation product that provides a graphical interface to z/OS terminals and consoles. ISPF and related applications are built to use these types of terminals. In the screenshots, the black area between the header and footer areas is the ISPF session.

ISPF is an end-user tool which provides an efficient interface to z/OS for working with data and programs and these base functions of ISPF are included in options 0 to 8 in the next screenshot. To access each option, type the corresponding number in the Option field and hit the Enter key.

The ISPF primary menu can be tailored so that option 9, “IBM Products”, or a customer provided option (hidden by the licensing window), will point to a second menu with a full list of products on it that a user can select from, including RMF. Once you get to the main menu for IBM Resource Management Facility, the following instructions will apply to any installation.

Here is an example of the ISPF Main Menu.

Figure 2: ISPF Main Menu
Figure 2: ISPF Main Menu

Before focusing on the RMF application, some productivity tips can be mentioned. The ISPF interface allows you to split your screen by using PF2 and to jump between the two sessions with PF9. You also have the ability to use PF7 and PF8 to scroll up and down through the data. Even more important, all ISPF applications come with an online help to assist with interpreting the data. Extended help is accessed by pressing PF1 within the IBM Resource Management Facility (RMF) application and following the various paths through the menus.

Further, help will provide additional commands and command keys to present the data in a more usable format, such as sorting by CPU time or Jobname. You can also use the RO (report options) command to limit the data displayed in the ISPF interface.

We'll now begin looking at the online RMF application, starting with the RMF main menu. For purposes of this paper, option 2 to access Monitor II and option 3 to access Monitor III are most important. To learn more about RMF, option T on the main menu will go to a Tutorial. An option X for Exit is also seen on this main menu. As a general rule for all ISPF screens, X is the option to use to exit the application.

Here is the main menu for RMF:

Figure 3: Primary RMF Menu from ISPF
Figure 3: Primary RMF Menu from ISPF

RMF Monitor II sessions

RMF Monitor II can be accessed from the main RMF panel by selecting option 2. The RMF Monitor II Primary Menu appears as shown in the following figure. There is a wealth of information provided in Monitor II (and also Monitor III), however to keep our focus on IBM Cognos 8 BI we will only focus on option 1 for individual address space information now. Two other major options explore I/O subsystem performance (option 2) and overall system resource usage (option 3).

Figure 4: RMF Monitor II Primary Menu
Figure 4: RMF Monitor II Primary Menu

RMF Monitor II Address Space Reporting

The following figure shows the RMF Monitor II Address Space Report Selection menu. This menu is the used for address space reporting and is accessed by specifying option 1 on the RMF Monitor II Primary Menu. There are two sets of options on this menu – one set to view information about all address spaces (options 1-3) and a second set (options 4-6) to focus on single address spaces whether it is a jobname or started task.

Figure 5: ISPF RMF Monitor II Address Space Menu
Figure 5: ISPF RMF Monitor II Address Space Menu

Selecting option 1 from the RMF Monitor II Address Space Report Selection menu, we will see an Address Space Resource Data (ARD) report for all address spaces active in the system, as shown in the following figure.

The ARD panel shown in the next figure includes key performance categories such as CPU, I/O, and memory usage by “JOBNAME”. “JOBNAME” includes both batch jobs and started tasks. Monitor II only provides a snapshot of current conditions. You cannot scroll back and forth in time, a useful feature you will find available in Monitor III.

Figure 6: RMF Monitor II ARD panel
Figure 6: RMF Monitor II ARD panel

The following display of the Address Space Resource screen has been sorted by JOBNAME. Sorting on any column can be done by placing the cursor anywhere in the column you want sorted and pressing PF6. Data is sorted in ascending order.

Figure 7: RMF Monitor II ARD panel sorted by JOBNAME
Figure 7: RMF Monitor II ARD panel sorted by JOBNAME

Notice the address spaces that start with BBO and CGC. These are IBM Cognos 8 BI jobs in a minimally tailored IBM Cognos 8 BI for z/OS environment. The address spaces starting with BBO represent default z/OS WebSphere Application Server job names; CGC represents default IBM Cognos 8 BI BIBus job names from setting the _BPX_JOBNAME variable. Both of these can be tailored.

The BBO* job names are application server activity taking place in the application tier. The CGC jobs are also in the application tier and each is known as a BIBus.

Another useful report is the Address Space SRM Data (ASRM) as shown in the next screen shot. SRM stands for System Resource Manager and is a key z/OS component that, as its name implies, is responsible for the management of all system resources via dispatching, prioritization, swapping and enqueue management. This report is option 3 on the RMF Monitor II Address Space Report Selection menu. The report gives an overview of the system resources that are used by each address space in the system or each address space that meets the selection criteria that you specify when you request the report, as well as the duration of time the job has been active.

For example, the columns in this report give information on various types of processor service, storage service and I/O service in terms of z/OS service units. These measurement units help to simplify analysis across unlike multiple System z hardware systems. This information is also used by the z/OS Workload Manager (WLM) in its management of system resources.

Figure 8: RMF Monitor II ASRM report
Figure 8: RMF Monitor II ASRM report

Option 3 on the RMF Monitor II Primary Menu will provide other useful RMF Monitor II reports to assess system usage and possible causes of service delays, reports such as:

  • PGSP – Page/Swap Dataset Activity report which monitors activity in the system datasets which are used when paging occurs
  • SPAG – System Paging Activity report which shows details on current paging, if any, and is valuable in monitoring a system with highly utilized memory, or memory constraints
  • SRCS – Central Storage/Processor/SRM report provides details on activity in various parts of z/OS storage areas and can help pinpoint potential problems

RMF Monitor III sessions

One benefit of accessing RMF through ISPF is that you can also access RMF Monitor III reports, which are not available through TSO/E. RMF Monitor III report displays are much more interactive and can quickly display details about system usage within and across multiple z/OS systems as well as potential causes of delays in Address Space execution for user specified periods of time in which raw SMF data are still available online.

Monitor III produces online reports that provide information about contention for critical hardware and software resources and helps you pinpoint sources of performance problems in your system. Many reports have cursor-sensitive control fields that will take you directly to another Monitor III report to provide additional information. The online contextual help and tutorial for each report facilitates quick learning about the report contents and also provide possible trouble resolution.

The next screen shot shows the Monitor III Primary Menu with options to look at Sysplex activity (option S), a system Overview (option 1), job details (option 2), system resource details such as processor and I/O (option 3), and z/OS-related subsystem information (option 4).

Figure 9: RMF Monitor III Primary Menu
Figure 9: RMF Monitor III Primary Menu

From the RMF Monitor III primary menu, select option 1 for Overview to bring up the following Overview menu. This menu has twelve options that can be used to learn more about various facets of system performance.

Figure 10: RMF Monitor III Overview Report Selection menu
Figure 10: RMF Monitor III Overview Report Selection menu

From the RMF Monitor III Overview Menu, option 2 for system information (SYSINFO) is a good starting point for understanding job/address space performance according to pre-defined WLM policies.

The SYSINFO panel provides some detail on overall system performance and address space activity. The top part of the screen shows information on how many processors are online and overall CPU utilization. The second half of the screen provides a list of WLM groups and information on how many active address spaces there are in each service class, their average response times and throughput, and causes of delays (if any).

The column labeled “T” on the SYSINFO panel indicates the type of WLM group that is being displayed:

  • W for workload (a grouping of service classes for reporting and accounting)
  • S for service class (which defines the performance goals for what is assigned to that class)
  • R for reporting class (allows for individual or aggregate reporting on work in the system)

For more information on using and understanding WLM, see the following IBM Redbook:

http://www.redbooks.ibm.com/abstracts/sg246472.html

Figure 11: RMF Monitor III SYSINFO display
Figure 11: RMF Monitor III SYSINFO display

The sample SYSINFO display above shows an IBM Cognos 8 BI system with 8 “CPs Online” at 49% CPU utilization. This means the system is using 49% of the available MIPS. This utilization number can help in two basic ways – indicate a CPU bottleneck (when over 90%) or indicate CPU may not be the cause of delays.

As mentioned earlier, IBM Cognos 8 BI processing is composed of 1) Java activity within the WebSphere Application Server (or Apache Tomcat) and 2) spawned C++ processes. On this system, the z/OS Workload Manager has been defined to allocate resources to the IBM Cognos 8 BI Java activity within the workload named WAS_WKLD. This processing has been broken down further into two service classes WAS7CB and WAS7SR that are defined as part of the WAS_WKLD workload. At the same time, the IBM Cognos 8 BI spawned C++ processes run under service class OMVSSRV.

An explanation of the SYSINFO display can be retrieved by pressing PF1 for help with the cursor anywhere on this screen. As shown in Figure 12 below, an initial help screen provides further options.

Figure 12: RMF Monitor III SYSINFO Initial Help
Figure 12: RMF Monitor III SYSINFO Initial Help

Extended help from this initial help screen may be displayed by placing the cursor on the field in question. For example, let's look at workflow percentage numbers (WFL%) by putting the cursor over the WFL% heading and pressing PF1 in Figure 12.

The following Field Help screen provides basic information to understand the data in the WFL% column on the SYSINFO panel.

Figure 13: RMF Monitor III SYSINFO Workflow Percentage Help
Figure 13: RMF Monitor III SYSINFO Workflow Percentage Help

Going back to Figure 11, it may be unclear whether the numbers for WFL % below 100% or delays in the WAS_WKLD group are a problem or not. This is dependent upon whether explicit or implicit service level agreements (SLAs) are at risk or not and whether these agreements are reflected appropriately in the WLM policy for the LPAR.

What specific jobs in the WAS_WKLD group are delayed may be determined by examining the service classes immediately under it by positioning the cursor on the service class name in the Group column and pressing Enter. You will be presented with the Delay Report screen as shown in Figure 14. The Delay Report provides data on each address space running in the service class selected on the SYSINFO screen. The columns report on active and idle time for each address space, as well as what type of delay is causing the idle time.

Figure 14: RMF Monitor III Delay Report for specific service class from SYSINFO
Figure 14: RMF Monitor III Delay Report for specific service class from SYSINFO

We see in our example that the IBM Cognos 8 BI WebSphere Application Server Java job BBOS001S (the servant region) is delayed with BBO100S having a workflow percentage of 44% and that it is waiting for processor resource 33% of the time interval.

Placing the cursor on the BBO100S line in Figure 14 and pressing Enter provides additional hints on possible causes as shown below in Figure 15 - RMF Monitor III Job Delays. In our example, the primary delay is “Job is waiting to use the processor” and the probable causes are either higher priority work is using the system or we have improperly tuned dispatching priorities. In reality, this likely means the CPU resources are saturated and the BBO100S address space is waiting on other work.

Detailed extended help is available for these displays as well. You are encouraged to review and learn from the help, especially the probable causes of delays on this report option.

Figure 15: RMF Monitor III Job Delays
Figure 15: RMF Monitor III Job Delays

As described already, IBM Cognos 8 BI for z/OS utilizes the open systems capability with Unix Systems Services (USS). USS is also known as Open MVS (OMVS) and RMF uses the label OMVS. For OMVS activity, another very useful RMF Monitor III report for IBM Cognos 8 BI monitoring is the OPD (OMVS Process Data) report. This report displays job usage data about USS jobs at the process and thread level, including all IBM Cognos 8 BI related activity. One may select it after choosing Overview from the RMF Monitor III Primary Menu as shown in Figure 10 or one may just type opd in any Command or Selection field of any other RMF Monitor III display as shown in Figure 16 below.

Figure 16: RMF Monitor III Overview Report Selection Menu with “opd” typed into the Selection field
Figure 16: RMF Monitor III Overview Report Selection Menu with 'opd' typed into the Selection field

Other Monitor III reports provided above show OMVS address spaces with their associated job names and system information collected in a similar way as traditional z/OS started tasks, batch jobs or TSO users. However, OMVS address spaces can consist of several processes which in turn might run one or more threads. This is the case with IBM Cognos 8 BI. Each process is typically associated with a UNIX command, consumes a certain amount of CPU and also provides state information.

The OPD report, as shown in Figure 17, can help a performance analyst involved in problem determination by providing answers to the following questions:

  • What are the delayed processes?
  • Which UNIX command initiated each process?
  • What is the status of each of the processes?
  • Which processes are high CPU consumers?
Figure 17: Monitor III OMVS Process Data
Figure 17: Monitor III OMVS Process Data

If more information is desired, you can position the cursor over the data you wish to drill down into and get further information. For example, one might want to examine the performance of the IBM Cognos 8 BI Java processes. You could position the cursor over the row for job BBOS001S (ASID 0194) and the column Jobname and hit Enter – the details for the response time issues being experienced by the address space would be displayed as shown previously in Figure 15. Yes, the Monitor III reports may be displayed from multiple paths!

Another option is to position the cursor on any one of the following columns - User, ASID, PID, State, Appl%, Total or Server – and hit Enter to obtain additional process data. As always, for the many possible process states, consult the help by pressing PF1.

Figure 18: Monitor II OMVS Process Data - Details
Figure 18: Monitor II OMVS Process Data - Details

Monitor III reports also let you scroll forward (PF11) and backward (PF10) through time – this allows you to see how the system was behaving prior to where you began observing it. Be careful as this effect can be somewhat confusing to the new user.

To automatically refresh a Monitor III screen periodically you can use the go command – the screen will continue refreshing until the Attention key on your keyboard is pressed (generally, the escape key on a PC keyboard is mapped to the Attention key used by z/OS).

Information displayed on most Monitor III panels is reported for an interval specified by the Time and Range values on each panel. The Time field specifies the start of the reporting interval you want to view, while the Range specifies in seconds how long you want the interval to be. The shortest interval you can monitor is dictated by how SMF recording is setup. SMF intervals can be as short as one minute.

Obtaining hardcopy from RMF Monitor sessions

While using Monitor II or Monitor III, you might want to save the results from your monitoring so that you can analyze them later. To do this you need to allocate a dataset before entering RMF, regardless of whether you are using RMF through TSO/E or ISPF. The attributes of the data set must be a record format of VBA and a record length of 137. This dataset can be created using ISPF panel 3.2 – typically you will only need one track for occasional use. Once the dataset is created you will next need to allocate it using the TSO ALLOC command. The syntax for this command is,

ALLOC F(RMFDMTSO) DS('data.set.name') SHR

where data.set.name is the name of the data set to be used for the hardcopy output. Any existing contents of the data set are overwritten.

To add output from a new monitoring session to an existing data set, use the command:

ALLOC F(RMFDMTSO) DS('data.set.name') MOD

The file name used must be RMFDMTSO. When you are ready to record the Monitor data, issue the command h on (hardcopy on) and then go. When you are done recording enter the command h off (hardcopy off). Your RMF session must then be stopped before you can use or view the captured usage data.

This next diagram, Figure 19, shows an extract of the file collected during one of the periods that an IBM Cognos 8 BI job was run. In this example, RMF monitor II was used and option SRCS-Central Storage/Processor/SRN was selected to capture the CPU utilization every 4 minutes. It can be seen that the CPU utilization was steady in the low 80's with an occasional spike to the high 80's.

Figure 19: Sample RMF hardcopy output
Figure 19: Sample RMF hardcopy output

The System Display and Search Facility (SDSF)

The System Display and Search Facility (SDSF) also provides the ability to interrogate what’s happening in the overall system and the OMVS environment in which IBM Cognos 8 BI executes. The primary SDSF menu is shown in Figure 20. Access to this panel via ISPF is installation-specific, so check with the system programmer. The SDSF Primary Option menu offers numerous options to look at the system log, active tasks in the system, output produced by users or tasks, and devices that handle output. Some or all of these functions may require authorization to use, so when given access to SDSF it would be time well spent to understand what can or cannot be used.

SDSF takes advantage of the ability to span multiple screens to provide a wealth of data. To scroll right on any SDSF display use PF11. To scroll back to the left, use PF10.

Figure 20: The SDSF Primary Option menu
Figure 20: The SDSF Primary Option menu

The Display Active (DA) and the Process Status (PS) panels provide basic usage data by the current workload. Be aware the order of columns in the following figures may be installation-specific and it is also possible for them to be user-tailored.

The DA command provides some useful information about the overall activity in the system in a single quick view. You may condition the data displayed using sort, filter, and prefix options. Press PF1 for more information on the various options.

As mentioned earlier in this document, the default IBM Cognos 8 BI related job names are the WebSphere Application Server BBO* and CGC job names. CPU and real memory usage as well as I/O (EXCP) counts are available.

Figure 21: SDSF DA panel with IBM Cognos 8 BI jobs
Figure 21: SDSF DA panel with IBM Cognos 8 BI jobs

The PS option and panel are much like the UNIX ps command and is shown below.

Figure 22: SDSF process data (PS) display
Figure 22: SDSF process data (PS) display

The PS output can be controlled by using the PREFIX command to limit the processes displayed – in this example we’ve entered the command PRE CGC* to limit the display to only the spawned BIBus processes which will begin with the default string “CGC”. Filter and sort operations on column data are also available to help define the exact information you are interested in. Extensive help is available by pressing PF1. The PREFIX command is available and useful on any SDSF display.

Figure 23: SDSF PS display after prefix specification
Figure 23: SDSF PS display after prefix specification

SDSF can also be used to view the system log to see warnings or errors as they appear on the operator’s console. This is done by entering the command LOG from any SDSF panel. You will find details here about what else was going on in the system at the time IBM Cognos 8 BI was running. If you are an authorized user (many installations do not permit this beyond the systems administration and operations groups) you can even enter system commands through this interface by prefixing the command line with a /. For example, you can see the execution of the command /D OMVS,LIMITS in the log shown in Figure 24. The HIGHWATER USAGE column can help you identify problem areas related to system resource limits.

Figure 24: SDSF System Log with USS system resource limits vs usage
Figure 24: SDSF System Log with USS system resource limits vs usage

System Management Facilities (SMF)

The information provided by the RMF monitors and displays shown above are derived from the following basic SMF record types,

  • Record type 70 RMF Processor Activity
  • Record type 71 RMF Paging Activity
  • Record type 72 RMF Workload activity and Storage Data
  • Record type 73 RMF Channel Path Activity
  • Record type 74 RMF Activity of Several Resources
  • Record type 75 RMF Page Data Set Activity
  • Record type 76 RMF Trace Activity
  • Record type 77 RMF Enqueue Activity
  • Record type 78 RMF Monitor I Activity
  • Record type 79 RMF Monitor II Activity

In addition to using these SMF record types for online monitoring, reports may be produced via post-processing with RMF batch jobs using the SMF data as input. These reports are useful for analyzing the overall performance of your system.

Other record types are available and have been assigned to other products and z/OS components. For example, SMF record types 100, 101 and 102 are assigned for DB2 use. See specific product or zOS manuals to see what SMF record types are available for processing and what information is available in them.

System Management Facilities (SMF) – Record Type 120

SMF records are available to support WebSphere Application Server performance management. SMF record type 120 is reserved for WebSphere Application Server for z/OS.

There are two types of SMF 120 records produced by WebSphere Application Server,

  • Activity records are gathered as each activity within a server is completed. An activity is a logical unit of business function. It can be a server or user-initiated transaction.
  • Interval records consist of data gathered at installation-specified intervals and provide capacity planning and reliability information.

The following are the subtypes that can be collected,

  • Subtype 1 - Server Activity record
  • Subtype 3 - Server Interval record
  • Subtype 5 - J2EE Container Activity Record
  • Subtype 6 - J2EE Container Interval Record
  • Subtype 7 - WebContainer Activity record
  • Subtype 8 - WebContainer Interval record
  • Subtype 9 - Request Activity record

The collection of these records must be enabled both at the WebSphere Application Server administrator console and in the z/OS SYS1.PARMLIB (SMFPRMxx) member.

The SMF Browser available at the WebSphere Application Server for z/OS download site is able to display record type 120. To download the SMF Browser go to the following URL (your IBM ID will be required),

https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=zosos390

For further information on the SMF Browser, download the browser package and read the associated documentation. The following example shows sample output from the SMF Browser. The example features subtype 9. The SMF Browser produces report files that can be browsed with a tool such as PuTTY, as shown below.

Figure 25: Sample output from SMF Browser
Figure 25: Sample output from SMF Browser

Unix System Services (USS) functions

Job Names in z/OS UNIX

By default, all spawned processes (address spaces) in the USS environment inherit the parent’s job name. One useful facility within USS is the ability to specify a base job name to be used when creating children processes/address spaces. This is done by including the environmental variable _BPX_JOBNAME and assigning a unique name to label all the processes associated with a specific flow with a common name. Since z/OS job names are limited to 8 characters, if you choose a job name with less than 8 characters, a suffix of 1 to 9 will be appended to the base name, but if you choose an 8 character job name, the same name will be used for all the processes.

It is recommend that _BPX_JOBNAME be specified in the WebSphere Application Server or Apache Tomcat job so that IBM Cognos 8 BI Java execution may be differentiated from the IBM Cognos 8 BI C++ BIBus execution. This will be important when managing and tuning the various IBM Cognos 8 BI processes. In the monitoring samples below, the IBM Cognos 8 BI Java processes execute within the WebSphere Application Server servant address space job name BBOxxxxS and the spawned IBM Cognos 8 BI C++ BIBus processes execute within the address spaces with job name CGC.

USS facilities

Rather than using the TSO/E interface, IT administrators more comfortable with Linux, Unix and/or Windows (LUW) interfaces may prefer to remotely login via a secure shell (SSH) such as PuTTY or OpenSSH and use the z/OS USS interfaces.

For experienced users, be aware that USS does not provide many of the traditional UNIX monitoring commands. There is a ps command available, but unless you are an administrator you will typically only see the processes owned by the userid you are logged in with. You can use the man ps command to see the options available in the USS environment. The example below show a couple variations of the ps command issued when IBM Cognos 8 BI is executing.

Figure 26 provides basic information on the IBM Cognos 8 BI related processes active in the system (BBO* and CGC) such as the PID (Process ID) and command which help in accessing the proper process while doing problem determination. The -o parameter of the ps command allows the user to specify what columns will be shown in the response.

Figure 26: Sample output of PS command
Figure 26: Sample output of PS command

Details provided by the ps command can help with problem determination or performance tuning by providing information that will help you pinpoint where activity of interest is occurring, such as job names, PIDs, or parent PIDs. Information provided here can be used in conjunction with other monitors, such as those in SDSF we reviewed in Figures 22 and 23.

The z/OS UNIX netstat command can be used to display the network configuration and status of a local TCP/IP stack. The example below shows the IBM Cognos 8 BI job is running and that port 9080 is used by IBM Cognos 8 BI.

Figure 27: Netstat output
Figure 27: Netstat output

UNIX “top” command lookalike for z/OS

For those coming from a UNIX or Linux background that like to use the top command to monitor performance, z/OS provides functionality in USS and SDSF that, when combined, can be used to create a tool that works like the top command.

Figure 28: Sample output of the top command on z/OS
Figure 28: Sample output of the top command on z/OS

See Appendix C for the “TOP” scripts and instructions how to execute the scripts.

DB2 Monitoring for Content Store and Data Source

IBM Cognos 8 BI for z/OS requires DB2 for z/OS for its Content Store database and may use DB2 for a data source. This section will provide an overview of some IBM tools available for monitoring DB2 as the Content Store or data source.

DB2 provides various traces which enable users to monitor DB2 activity online or produce reports afterwards. There is a monitor trace which records data in an accessible format for monitoring tools. There are also traces which collect what DB2 calls accounting and statistics information.

Accounting traces can collect all information related to application programs while the statistics trace reports on resources used by the DB2 system and database services. There are other DB2 traces such as performance and auditing which provide much greater detail, with associated overhead, that will not be covered here.

Omegamon Performance Expert Online Monitoring

We will start by looking at how DB2 accounting information can be accessed by the IBM Tivoli Omegamon XE for DB2 Performance Expert on z/OS tool (will be referred to as Omegamon XE from here on). There is an online component which can be accessed through ISPF. Figure 29 shows the main ISPF menu for Omegamon XE. The key option on this panel we will use is option 3 for the latest version of the online monitor.

Figure 29: Omegamon XE main menu
Figure 29: Omegamon XE main menu

From the main menu, we will select option 3 to access the Omegamon XE Online Monitor Main Menu (OLM), shown next in Figure 30.

Figure 30: Omegamon XE Online Monitor Main Menu
Figure 30: Omegamon XE Online Monitor Main Menu

We will look at the first three options of the online monitor from this screen,

  • Thread activity, which shows accounting information (option 1)
  • Statistics information (option 2)
  • System parameters (option 3)

Note the two labels shown at the top of the screen under the Command field, DB0I and DB1I. In this test environment, DB0I is the DB2 data sharing group name and DB1I is the DB2 subsystem ID the monitor is displaying. This can help the user keep track of what they are looking at.

From the Online Monitor Main Menu, selecting option 1 will go to the Thread Summary panel showing a list of active DB2 threads similar to the panel shown in Figure 31, with the connection type and status, and elapsed time of each thread.

Figure 31: Omegamon XE thread activity
Figure 31: Omegamon XE thread activity

You can drill down from this menu but let's look at the information provided on the summary screen. This display shows three distinct plans under the Planname column:

  1. KO2PLAN is the Omegamon XE monitor itself
  2. DSNACLI is the plan used by an ODBC connection
  3. DISTSERV indicates the threads using a JDBC connection

The last two columns to the right show two types of elapsed times. Class 1 elapsed times include the period an application has a thread open with DB2 until it closes. As will be seen below, Class 1 times can be broken down further into CPU and wait times. Class 2 elapsed time accounts for time just in DB2 and also consists of both CPU and wait times.

Pressing PF1 from the screen will provide a help screen. Near the bottom of this help screen are a list of items that you can get further help on, by placing the cursor over the relevant item and pressing PF1 again.

On the Thread Summary screen, you can find more detail on a specific thread by typing a character (any character) in the far left field and hitting Enter. This more detailed information may be desired if the user sees some anomalies on the Thread Summary screen or from information obtained elsewhere (e.g., a help desk). For example, a user may see a thread running for an excessive time while using considerable DB2 resources, or, vice versa, a long running thread that just sits there. Figure 32 shows some of the thread detail available through the Omegamon XE monitor in order to diagnose these types of problems.

This detail starts by providing more information on what or who is using the thread under the Thread Identification section. Within the Times section, some key indicators to look at are whether Class 1 (application) time is mostly made up of Class 2 (DB2) time. If Class 1 time is considerably higher, any performance issue is likely outside of DB2. If performance is poor and you find Class 1 times close to or equivalent to Class 2 times, then further diagnosis within DB2 is called for.

When diagnosing DB2 performance, start by differentiating elapsed time with CPU time. If CPU time is relatively low, continue by looking at wait times and delays which are recorded as Class 3, 7, or 8 time. If high elapsed times are made up of CPU time (and performance is bad), find out why so much CPU is being used by exploring SQL efficiency or access path selection.

Figure 32: Omegamon XE Thread Detail panel
Figure 32: Omegamon XE Thread Detail panel

Scroll down on this screen to find more categories to examine. For each category, typing a character in the field to the left and hitting Enter will provide further details.

From the Omegamon XE Online Monitor Main Menu, select 2 to display statistics and a DB2 Statistics Detail screen similar to the one in Figure 33 will appear. This is the top of a three page display through which you can scroll up with PF7 or down with PF8.

Some key significant DB2 statistics data for an IBM Cognos 8 BI for z/OS environment can include EDM pool activity. EDM pool is a storage area where object descriptors are kept for quick access. The architecture and implementation of IBM Cognos 8 BI for z/OS can access a larger number of descriptor objects than a customer is used to seeing, so it will be important to monitor how full the EDM pool is.

The Buffer Manager section of this panel tracks the use, or lack of use, of DB2 bufferpools. True read I/O to disk is indicated by the number of synchronous reads on this panel and should be avoided as much as possible.

Finally, locking can be a performance inhibitor and the Locking Activity section of this panel provides some high level numbers on key locking activities such as deadlocks or timeouts.

Figure 33: Omegamon XE DB2 Statistics Detail panel
Figure 33: Omegamon XE DB2 Statistics Detail panel

To drill down into any of these headings, enter a character in the far left field and hit the Enter key. As an example, Figure 34 shows the detail for the Buffer Manager category.

Figure 34: Omegamon XE buffer manager details
Figure 34: Omegamon XE buffer manager details

As with many screens in this monitor, it is possible to find details in more depth. In this example, you can select any of these bufferpools to determine why a significant performance phenomena is occurring, such as a low Hit Ratio or a high Synchronous Read count.

Finally, with the online monitor, you can view the system parameters currently in effect for the DB2 subsystem you're looking at. This assumes you have been granted proper authority, which is also true for access to the thread and statistics detail monitors shown above.

By selecting option 3 for Display Subsystem Parameters from the Omegamon XE Online Monitor Main Menu, you will see the screen shown in Figure 35. It provides groupings of parameters that can be looked at together. The groups are based on the different panels used the in the DB2 install process (e.g., DSNTIPK). These parameters are compiled into a startup module used by DB2 which is unofficially known as “zparm”. All basic functions of DB2 are established by these parameters and include such things as,

  • System names
  • Application defaults
  • Storage or memory settings
  • Logging and archiving
  • Security
Figure 35: Omegamon XE DB2 System Parameters panel
Figure 35: Omegamon XE DB2 System Parameters panel

Again, type a character next to the heading you want to look at and hit the Enter key. An ISPF pop-up will display a list of parameters with their individual settings.

One key area for an IBM Cognos 8 BI for z/OS implementation is the thread settings. For example, the window in Figure 36 shows some sample thread settings. This information will help in determining if enough threads have been defined to support the number of users accessing IBM Cognos 8 BI. For example, the CTHREAD setting establishes the maximum number of local threads that will be set. The MAXDBAT setting for remote active users determines have many JDBC connections are possible. Finally, the number of ODBC threads used for the Content Store are controlled by the IDBACK setting.

Figure 36: Omegamon XE for DB2 thread management details
Figure 36: Omegamon XE for DB2 thread management details

From the panel shown in Figure 35 you can also look at and verify Buffer Pool settings by going to the Buffer Pool menu in Figure 37. This list shows all the bufferpools defined to DB2 and the number of 4K pages allocated to each one.

Figure 37: Omegamon XE for DB2 bufferpool sizes
Figure 37: Omegamon XE for DB2 bufferpool sizes

These are but two examples of the key information that can found via the Omegamon XE for DB2 online monitor. This information can be key when understanding or debugging performance when you want to know what important DB2 settings have been set to.

Omegamon Performance Expert Batch Reporting

All of the capability and information shown and described above can be produced after the fact through the use of batch reporting. With the proper DB2 traces active, accounting and statistics records will be written out to SMF datasets. This data can then be used as input to batch jobs which can produce various reports. The default classes for Accounting (1, 2, 3, 7, and 8) and Statistics (1, 2, 3) are usually sufficient.

This section will show,

  • Sample Job Control Language (JCL) that can be used to read SMF data and produce reports
  • An example of an Accounting Report
  • An example of a Statistics Report

Batch reporting JCL

The following is some simple JCL that can be used to create both accounting and statistics reports. It reads input from a dataset with SMF records called SMF.DATA.FOR.COGNOS. The control cards specify the TIMEZONE where the records were created (offset from GMT), and produce LONG versions of both reports. The output goes to the dynamically allocated print datasets (SYSOUT).

//DB2REPT JOB  (),'DB2 PERF EXPERT',MSGLEVEL=(1,1),TIME=1440,
//             CLASS=A,MSGCLASS=H,NOTIFY=&SYSUID,REGION=0M
//DB2PE     EXEC PGM=DB2PE,REGION=6000K
//SYSIN     DD *
GLOBAL(
    TIMEZONE(+7))
ACCOUNTING
  REPORT
    LAYOUT(LONG)
STATISTICS
  REPORT
    LAYOUT(LONG)
    EXEC
//INPUTDD   DD DISP=SHR,DSN=SMF.DATA.FOR.COGNOS
//SYSPRMDD  DD SYSOUT=*
//SYSPRINT  DD SYSOUT=*
//SYSOUT    DD SYSOUT=*
//JOBSUMDD  DD SYSOUT=*

DB2 accounting report

Figure 38 below shows the first page as an example of the long version of an accounting report. The report covers almost everything involved in executing a DB2 transaction. Details and descriptions of all fields in this report are provided in both DB2 and Omegamon XE for DB2 product manuals, along with various IBM RedBooks and white papers.

The top shows the report name, but to the left it verifies what DB2 subsystem the data is taken from (on the left) and the time interval being reported on (on the right).

Next are two simple bar graphs showing the breakdown of the elapsed time (Class 1 in DB2 terminology) and Class 2 time (time spent strictly within DB2).

Below the bar graphs are the details of Class 1, 2 and 3 time. Class 1 and class 2 time are broken down into components of average elapsed time, CPU time and suspend time to the left. To the right of the Class 1 and 2 numbers is information on average time spent waiting on DB2 suspensions (such as time waiting on locking and I/O). To the far right are the “Highlights', or totals for the amount of activity occurring during the interval being reported on.

In general, the key to good performance is to eliminate as much wait time as possible. This is done, from a DB2 perspective, by first identifying differences between Class 1 and Class 2 time and whether there is a delay outside DB2 that is slowing work from being dispatched to DB2. Next, a look at the breakdown of DB2 time can help identify where tuning can be done. A high degree of suspend time most often means looking further into locking or I/O performance.

Figure 38: Omegamon XE for DB2 accounting report
Figure 38: Omegamon XE for DB2 accounting report

DB2 statistics report

DB2 statistic traces, when turned on, can provide information on all components of the DB2 subsystem. Customers generally have statistics tracing turned on to capture information on,

  • SQL activity
  • Storage usage
  • Dataset use
  • Plan and package binding
  • Locking detail
  • Bufferpool activity

Figure 39 shows, as an example, one page of the statistics report. This particular page is providing statistics on EDM storage pool usage. EDM pool storage is made up of individual storage pools for details on plans and packages (RDS), database descriptors (DBD), cached dynamic SQL statements (STMT) and skeleton copies of plans and packages (SKEL). This report contains data on each of these pools. What's important with this report is the ability to monitor the use of each EDM pool, and whether problems are on the horizon (percentage of FREE PAGES remaining) or whether failures have already occurred due to FAILS DUE TO POOL FULL.

Figure 39: Omegamon XE for DB2 statistics report
Figure 39: Omegamon XE for DB2 statistics report

IBM Cognos 8 BI Built-in Performance Monitoring

There are some built-in capabilities with IBM Cognos 8 BI that provide monitoring and tuning capability from an IBM Cognos 8 BI perspective. This is beyond the scope of this document but this section will provide pointers to some documentation samples that can be useful in monitoring performance within IBM Cognos 8 BI.

For starters, find more information about IBM Cognos 8 BI Administration in the IBM Cognos 8 Administration and Security Guide at:

http://publib.boulder.ibm.com/infocenter/c8bi/v8r4m0/index.jsp?topic=/com.ibm.swg.im.cognos.ug_cra.8.4.0.doc/ug_cra.html

There is additional information on performance related topics on the Cognos Proven Practice section on developerWorks. Here is a link directly to all articles related to IBM Cognos 8 BI performance:

http://www.ibm.com/developerworks/views/data/libraryview.jsp?sort_by=Title&sort_order=1&show_abstract=true&show_all=false&search_flag=true&product_by=Cognos&topic_by=All%20Topics&type_by=All%20Types&search_by=cognosppperformanceall&Submit.x=0&Submit.y=0

As an example of what is available, here is a rudimentary look at the tuning knobs available for IBM Cognos 8 BI reports that can be used from the IBM Cognos 8 BI Administration console:

http://www.ibm.com/developerworks/data/library/cognos/page61.html


Appendix A - Useful Reference Material

IBM briefing document on the features and functions of z/OS Unix System Services:
http://www-03.ibm.com/systems/z/os/zos/features/unix/

RMF User's Guide, SC33-7990

RMF Report Analysis, SC33-7991

RMF Performance Management Guide, SC33-7992, last update: V1R12 RMF

Messages and Codes, SC33-7993 RMF Programmer's Guide, SC33-7994

RMF Reference Summary, SX33-9033

RMF – Programmer’s Guide - SC33-7994-03

SDSF Operation and Customization - SA22-7670-04

z/OS MVS Initialization and Tuning Guide – SA22-7591

z/OS MVS Initialization and Tuning Reference – SA22-7592

OS/390 V2R10.0 elements and features PDF files:
http://www-03.ibm.com/systems/z/os/zos/bkserv/os390_r10pdf/#uss

IBM article describing how to generate the jobnames for OMVS address spaces:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bpxzb230/32.9?DT=20020620152554

Tivoli OMEGAMON XE for DB2 Performance Expert on z/OS:
http://www-01.ibm.com/software/tivoli/products/omegamon-xe-db2-peex-zos/


Appendix B – RMF Monitoring With TSO/E Sessions

An alternative to the RMF ISPF panels is the TSO/E based monitoring. In a typical customer environment this can be accessed by going to option 6 in TSO and entering the RMFMON command. The following screen containing several options for various facets of performance will then be displayed.

Figure 40: RMF Monitor II via TSO/E – initial display
Figure 40: RMF Monitor II via TSO/E – initial display

The upper left corner of the panel (where the ‘f’ is located) is the user interface area. You can type the report name, the F command (page forward), the M command (return to menu), or the Z command (quit) into this area. The most interesting reports from an IBM Cognos 8 BI point of view are probably ARD and ASRM. Note that split screen operations are not available using the TSO/E interface.

All panels in the TSO/E version can be automatically refreshed by entering the T command on the initial RMF display shown above. You will get a response saying “ENTER MONITOR 2 REPORT OPTION” which requires a reply in the format m,n. The m is the number of times you want to fresh and n is the number of seconds between refreshes. Once the refresh options are set, select the PF key to access the monitor desired.

Looking at both active and inactive spaces will present a better feel for how many parallel (pipelined and partitioned) operations are occurring. The command to view the address space resource data report for all USS address spaces whether they are active or not is ARD O,A.

Figure 41: TSO/E RMFMON of USS activity using the ARD O,A command
Figure 41: TSO/E RMFMON of USS activity using the ARD O,A command

Monitor II offers two types of reports - row reports and table reports. Row reports are generally associated with monitoring a single job or metric set – each time you press the Enter key a new row of data is added to the report. Since IBM Cognos 8 BI executes with multiple address spaces, we have found using the table reports to be more useful. There are a number of useful features that can be used with table reports through ISPF, such as sorting by columns.

Monitor II also offers two modes for the session reports, be sure you understand which mode you are using to avoid confusion on resource usage statistics. Total mode shows the cumulative total since the beginning of the Monitor II interval. Delta mode shows the change in the activity since the previous request for the report. You can toggle between these modes using the D ON and D OFF commands.


Appendix C – Lookalike UNIX “top” Command for z/OS

The shell script below (code starting with the line #!/bin/sh) can be run from an ssh client such as PuTTY when logged into USS. This script will call a REXX program below (starting with the line /* REXX */) which executes the SDSF DA command (see Figure 21 above). These two components take the data returned by SDSF and format it in a display similar to top as shown in Figure C1 below. This display will roll and be updated according to any parameters you supply to the shell script.

Figure 42: TOP output
Figure 42: TOP output

To use the shell script, first of all copy both the shell script and the REXX program into the same directory and modify the shell script as necessary. Also, the user will need to add a STEPLIB environmental variable pointing to the SDSF load library (typically named ISF.SISFLOAD) with the command export STEPLIB=ISF.SISFLOAD.

The format of the command to execute the shell script is top -job n.

The -sort parameter allows you to select which column of the output will be sorted on. The default column for sorting is cpu. The -n parameter specifies in seconds how often the display will be refreshed. An optional -h parameter before trying the script will provide a list and short explanation of the parameters that can be used.

The following is the shell script named TOP. This script is used to call other scripts and reformat the header or output.

#!/bin/sh
# written by IBM
#NOTE MAKE SURE TO SET  ENV VAR STEPLIB ISF.SISFLOAD

#sorting column starts with ZERO
sortBy="2" #default sort by cpu

#refresh rate is default 3secs
secs="3"

if [ "$1" = "-cpu" ]
then
        sortBy="2"
elif [ "$1" = "-job" ]
then
        sortBy="0"
elif [ "$1" = "-pid" ]
then
        sortBy="1"
elif [ "$1" = "-path" ]
then
        sortBy="7"
elif [ "$1" = "-mem" ]
then
        sortBy="4"
else [ "$1" = "-h" ]
        echo "default sort by CPU, otherwise give -cpu, -job, -pid, -path, 
         -mem to sort on a specific column"
        echo "2nd param is the refresh rate in seconds, default 3secs"
        echo "example: top -job 5"
        echo "due to some processes not having all columns, it confuses the unix sort, 
         but it's minor & easy to see"
        exit
fi
if test "$2" != ""
then
        secs=$2
fi
while [ 1 ]
do
    echo "JOBNAME    PID       CPU%      IO COUNT   REAL MEG   CPU_SECS   IORATE    PATH"
    ./topcog | sort -r +${sortBy}n
    echo "JOBNAME    PID       CPU%      IO COUNT   REAL MEG   CPU_SECS   IORATE    PATH"
    sleep ${secs}
    echo "===================================END================================”
done

The following REXX script is named TOPCOG. It is called by the TOP script above and gathers statistics from the SDSF/PS command and displays on z/OS Unix.

/* REXX */
trace o
arg cmd
if cmd='' then cmd='DA'
xx=isfcalls('ON')
if xx<>0 then say 'isfcalls rc='xx
isfsort="cpupr d"
isfcols="jname cpupr excp ecpu real excprt jobid"
isfprefix="**"
isfowner="*"
address sdsf 'ISFEXEC DA ( PREFIX da_ NOMODIFY'
address sdsf 'ISFEXEC' cmd
if rc<> then do
say 'SDSF error. RC='rc
  say isfmsg2.0
 do ix=1 to isfmsg2.0
  say isfmsg2.ix
 end
exit
end
/*say isftline "WITH ASSIGNED PID"*/
isfcols="pid jobid command"
isfsort="pid a"
address sdsf 'ISFEXEC PS ( PREFIX ps_ NOMODIFY'
cmd = "PS"
address sdsf 'ISFEXEC' cmd
/*say ps_pid.0*/
if rc<>0 then do
say 'SDSF error. RC='rc
  say isfmsg2.0
 do ix=1 to isfmsg2.0
  say isfmsg2.ix
 end
exit
end
/*say 'JOBNAME    PID        CPU%       IO COUNT   REAL MEG   CPU_SECS   IORATE'*/
do i=1 to da_jname.0
 pidsave=''
 cmdsave=''
 do j=1 to ps_pid.0 until pidsave<>""
  if da_jobid.i<>"" & da_jobid.i=ps_jobid.j then
    pidsave=ps_pid.j
    cmdsave=ps_command.j
 end
 if pidsave<>"" | da_jname.i='OMVS' | da_janme.i='TCPIP' then
 say l(da_jname.i) l(pidsave) l(da_cpupr.i) l(da_excp.i) l(substr(da_real.i/256,1,5))
  l(da_ecpu.i) l(da_excprt.i) cmdsave
end
return
l: return left(arg(1),10)

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Big data and analytics on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Big data and analytics, Information Management
ArticleID=813387
ArticleTitle=IBM Cognos Proven Practices: Monitoring IBM Cognos 8 BI in the z/OS Environment – An Introduction
publish-date=05172012