|
Each individual LSPR workload is designed to focus on a major type of activity, such as interactive, on-line database, or batch. The LSPR does not focus on individual pieces of work such as a specific job or application. Instead, each LSPR workload includes a broad mix of activity related to that workload type. Focusing on a broad mix can help assure that resulting capacity comparisons are not skewed.
The LSPR workload suite is updated periodically to reflect changing production environments. High-level workload descriptions are provided below.
NOTE: The workloads presented here are considered the LSPR “primitives” and generally not expected to be used individually for capacity sizing. Please refer to Relating Production Workloads to LSPR Workloads for a discussion about creating mixtures of LSPR workloads to better represent production environments.
 |
z/OS and OS/390 |
OLTP-T (formerly IMS) - Traditional On-line Workload
The OLTP-T workload consists of light to moderate IMS transactions from DLI applications covering diverse business functions, including order entry, stock control, inventory tracking, production specification, hotel reservations, banking, and teller system. These applications all make use of IMS functions such as logging and recovery. The workload contains sets of 12 (17 for OS/390 Version 1 Release 1 and earliler) unique transactions, each of which has different transaction names and IDs, and uses different databases. Conversational and wait-for-input transactions are included in the workload.
The number of copies of the workload and the number of Message Processing Regions (MPRs) configured is adjusted to ensure that the IMS subsystem is processing smoothly, with no unnecessary points of contention. No Batch Message Processing regions (BMPs) are run. IMS address spaces are non-swappable. This IMS workload accesses both VSAM and OSAM databases, with VSAM indexes (primary and secondary). DLI HDAM and HIDAM access methods are used. The workload has a moderate I/O load, and data in memory is not implemented for the DLI databases.
Measurements are made with z/OS, OS/390, DFSMS, JES2, RMF, VTAM, and IMS/ESA. IMS coat-tailing (enabling reuse of a module already in storage) is not used; since this activity is so sensitive to processor utilization, it could cause distortion when comparing ITRs between faster and slower processors. Beginning with OS/390 Version 1 Release 1, measurements were done with one or more control regions. The number of data base copies, MPR’s, and control regions (within the limits of granularity) are scaled with the processing power of a particular machine in-order to assure equal and normalized tuning. Performance data collected consists of IMS PARS, and the usual SMF data, including type 72 records (workload data), and RMF data.
IMS is measured by logging on a predetermined number of terminals, each of which starts executing scripts consisting of end-user actions. Once the logons are complete, the average think time is adjusted to provide a transaction rate that causes the processor to reach the target utilization level. After appropriate stabilization periods, measurements are made at 70% and 90% processor busy. The average think time is approximately 6.1 seconds (14 seconds for OS/390 Version 1 Release 1) for the 70% run, and 4.9 seconds (11 seconds for OS/390 Version 1 Release 1) for the 90% run, with a uniform distribution ranging from 75% to 125% of the average applied. IMS is measured as a steady-state system over an elapsed period deemed adequate to produce a repeatable sample of work
OLTP-W -Web-enabled On-line Workload
The OLTP-W workload reflects a production environment that has web-enabled access to a traditional data base. For the LSPR, this has been accomplished by placing a WebSphere front-end to connect to the LSPR CICS/DB2 workload (described below).
The J2EE application for legacy CICS transactions was created using the CICS Transaction Gateway (CTG) external call interface (ECI) connector enabled in a J2EE server in WebSphere for z/OS V4.0.4. The application uses the J2EE architected Common Client Interface (CCI). Clients access WebSphere services using the HTTP Transport Handlers. Then the appropriate servlet is run through the webcontainer, which call EJB's in the EJB Container. Using the CTG external call interface (ECI) CICS is called to invoke DB2 to access the database and obtain the information for the client.
For a description of the CICS and DB2 components of this workload, please see the CICS/DB2 workload description further below.
WASDB - WebSphere Application Server and Data Base
The WASDB workload reflects a new e-business production environment that uses WebSphere applications and a DB2 data base all running in z/OS.
WASDB is a collection of Java classes, Java Servlets, Java Server Pages and Enterprise Java Beans integrated into a single application. It is designed to emulate an online brokerage firm. WASDB was developed using the IBM VisualAge* for Java and WebSphere Studio tools. Each of the components is written to open Web and Java Enterprise APIs, making the WASDB application portable across J2EE-compliant application servers.
The WASDB application allows a user, typically using a web browser, to perform the following actions:
- Register to create a user profile, user ID/password and initial account balance.
- Login to validate an already registered user.
- Browse current stock price for a ticker symbol.
- Purchase shares.
- Sell shares from holdings.
- Browse portfolio.
- Logout to terminate the user's active interval.
- Browse and update user account information.
CB-L (formerly CBW2)-Commercial Batch Long Job Steps
The CB-L workload is a commercial batch jobstream is reflective of large batch jobs with fairly heavy CPU processing. Each copy consists of 22 jobs, with 157 job steps. These jobs are more resource intensive than jobs in the CB-S workload (discussed below), use more current software, and exploit ESA features. Sufficient copies of the workload are used in-order to achieve high processor utilization. The work done by these jobs includes various combinations of C, COBOL, FORTRAN, and PL/I compile, link-edit, and execute steps. Sorting, DFSMS utilities (e.g. dump/restore and IEBCOPY), VSAM and DB2 utilities, SQL processing, SLR processing, GDDM* graphics, and FORTRAN engineering/scientific subroutine library processing are also included. Compared to CB-S, there is much greater use of JES processing, with more JCL statements processed and more lines of output spooled to the SYSOUT and HOLD queues. This workload is heavily DB2 oriented with about half of the processing time performing DB2 related functions.
Measurements are made with z/OS, OS/390, DFSMS, JES2, RMF, and RACF. C/370, COBOL II, DB2, DFSORT, FORTRAN II, GDDM, PL/I, and SLR software is also used by the job stream. Access methods include DB2, VSAM, and QSAM. SMS is used to manage all data. Performance data collected consists of the usual SMF data, including type 30 records (workload data), and RMF data.
The CB-L job stream is replicated to assure a reasonable measurement period, and the job queue is pre loaded. Enough initiators are activated to ensure a high steady-state utilization level, approaching 100%. The number of initiators are generally scaled with processing power to achieve comparable tuning across different machines. The measurement is started when the job queue is released, and ended as the last job completes. Each copy of the workload uses its own datasets, but jobs within the workload share data.
CB-S (formerly CB84)-Commercial Batch Short Job Steps for pre-z/OS version 1 release 6
The CB-S workload is a moderate commercial batch job stream reflective of processing short batch job steps. Each copy consists of 130 jobs, with 610 unique job steps. The work done by these jobs includes various combinations of compile, link-edit, and execute steps. Utility jobs, primarily for data manipulation, are also included.
Measurements are made with z/OS, OS/390, DFSMS, JES2, and RMF. Assembler H, COBOL/VS, PL/I Optimizing Compiler, and DFSORT software is also used by the job stream. Access methods include BSAM, QSAM, BDAM, and VSAM. SMS is used to manage non-system data. Performance data collected consists of the usual SMF data, including type 30 records (workload data), and RMF data.
The CB-S job stream is replicated many times to assure a reasonable measurement period, and the job queue is pre loaded. Enough initiators are activated to ensure a high steady-state utilization level, approaching 100%. The number of initiators are generally scaled with processing power to achieve comparable tuning across different machines. The measurement is started when the job queue is released, and ended as the last job completes. Each job in the job stream uses its own datasets in order to eliminate dataset contention
ODE-B - On Demand Environment - Batch
The ODE-B workload reflects the billing process used in the telecommunications industry. This is a multi-step approach which includes the initial processing of Call Detail Records (CDR), the calculation of the telephone fees, and the insertion of the created telephone bills in a database. The CDRs contain the details of the telephone calls such as the source and target numbers along with the time and the duration of the call. The CDRs are stored in flat files within a zFS file system. A feeder application reads the CDRs from the files, converts them into XML format and sends them to a queue. An analyzer application reads the messages from the queue and performs analysis on the data. During the analysis further information is retrieved from the relational database, and the same database is subsequently updated with the newly created telephone bill and new records for each call. The feeder and the analyzer applications are implemented as enterprise java beans (EJB) in IBM WebSphere Application Server for z/OS. Using the concept of multi-servant regions, which is unique to the z/OS implementation of WebSphere Application Server, the threads of the feeder and the analyzer applications are distributed over several java virtual machines (JVM). The WebSphere internal queuing engine is used as the queue for the message transport between the feeder and analyzer.
CB-J - JavaBatch
The JavaBatch workload reflects the batch production environment of a clearing bank that uses a collection of java classes working on a DB2 database and a set of flat files in z/OS. JavaBatch is a native, standard Java application that can be run standalone on a single JVM (Java Virtual Machine) or in parallel to itself on multiple JVMs. Each of the parallel applications instances can be tuned separately. All parallel applications are working on the same set of flat files and database tables. The JavaBatch application is based on a Java-JDBC-framework of an external banking software vendor and has been enhanced and adapted using the Websphere Application Developer tool. Various properties such as number of banks, number of accounts, and more, can be adapted for the specific runtime environment in a special properties file, by keeping the java application unchanged. The JavaBatch application allows a user to perform the following activities:
- initialize the working database
- create a set of flat files, each containing several hundreds to thousands of payments.
- read the flat files, perform various syntax-checks and validation for each payment and store the payments to the working database.
- read the payments from the database and route them to destination bank's flat files.
CICS/DB2 - On-line Workload for pre-z/OS version 1 release 4
The CICS/DB2 workload is an LSPR workload that was designed to represent clients daily business by simulating the placement of orders and delivery of products, as well as business function like supply and demand management, client demographics and item selling hit list information. The workload consists of ten unique transactions.
CICS is used as a transaction monitor system. It provides both an API for designing the dialogue panels and parameters to drive the interface to the DB2 database. The interface between the two subsystems is fully supported by S/390 and exploits N-Way designs. CICS functions like dynamic workload gathering and function shipping are not exploited in this workload. The CICS implementation uses an MRO model, which is managed by CP/SM. The number of AOR (Address Owning Region) and TOR (Terminal Owning Region) used, depends on the number of engines of the processor under test. The ratio between TOR and AOR is 1:3. The utilization of the TOR and the AOR regions is kept under 60%.
The application database is implemented in a DB2 subsystem. One of the major design efforts was to achieve a read-to-write ratio exhibited by OLTP clients. Several data center surveys indicate an average read-to-write ratio to be in the range of 4:1 - 6:1. The read-to-write ratio is an indication of how much of the accessed data are changed as well. For this CICS/DB2 workload implemented on a S/390 or z/Architecture system and using DB2 as database system, an approximation of the read-to-write ratio is the ratio of SQL statements performing 'read' operation, like select, fetch, open cursor to the 'write' SQL statements, like insert, update, delete.
To reduce the number of database locks and the inter system communication required for each database update and to preserve local buffer coherency in data sharing environments, DB2 type 2 indexes have been used. Additionally, row-level-locking has been introduced for some tables. Each table and index are buffered in separate buffer pools for easy sizing and control.
CICS - On-line Workload prior to OS/390 Version 2 Release 10 only
The CICS workload consists of light to moderate transactions from diverse business applications, including order entry, stock control, inventory tracking, production specification, hotel reservations, banking, and teller system. The application programs are written in COBOL or Assembler. These applications are functionally similar, but not identical, to the IMS workload applications, described below.
For measurements on MVS/SP 4.2.0, the CICS workload contains six sets of 17 unique transactions. One set of transaction programs is run below the 16 megabyte line, and the other five are run in 32-bit mode above the line. For measurements on OS/390, there are twelve sets of transactions, with two sets running below the line and 10 sets above the line. Each set of transactions has different transaction names and IDs, and uses different program load modules, buffer pools, datasets, etc. The effect is that the OS/390/CICS system manages 102 or 204 transactions in each copy of the CICS workload.
CICS measurements are done in an MRO environment. For MVS/SP 4.2.0 measurements, a three region "MROplex", consisting of a TOR (terminal-owning region), AOR (application-owning region), and FOR (file-owning region), is run for each engine in the processor being measured. For OS/390, each MROplex consists of four regions: TOR, AOR, FOR, and a combined A/FOR, as this configuration results in CICS processing characteristics that are more typical of client environments, and an MROplex is run for each one or two engines in the processor being measured. Each MROplex runs a copy of the workload. All CICS address spaces are nonswappable.
The CICS workload uses VSAM datasets, and data in storage is implemented with large buffer pools. Measurements are made with OS/390, DFSMS, JES2, RMF, VTAM, and CICS/OS/390. Performance data collected consists of CICS shutdown statistics and the usual SMF data, including type 30 records (workload data), and RMF data. CICS is measured by logging on a predetermined number of terminals, each of which starts executing scripts consisting of end-user actions. Once the logons are complete, the average think time is adjusted to provide a transaction rate that causes the processor to reach the target utilization level. After appropriate stabilization periods, measurements are made at 70% and 90% processor busy. The average think time is approximately 16 seconds for the 70% run and 12 seconds for the 90% run, with a uniform distribution ranging from 75% to 125% of the average. CICS is measured as a steady-state system over an elapsed period deemed adequate to produce a repeatable sample of work.
DB2 - On-line Workload for OS/390 Version 1 Release 1 only
The DB2 workload consists of light to moderate transactions from two predefined, well-structured (not ad hoc query) applications, inventory tracking and stock control. IMS/DC is used as the transaction manager. The applications are functionally similar, but not identical, to two of the IMS/DLI and CICS applications. The DB2 workload contains sets of seven unique transactions, each of which has different transaction names and IDs. Conversational and wait-for-input transactions are not included in the DB2 workload.
The number of copies of the workload and the number of IMS Message Processing Regions (MPRs) configured is adjusted to ensure that the IMS and DB2 subsystems are processing smoothly, with no unnecessary points of contention. No Batch Message Processing regions (BMPs) are run. IMS and DB2 address spaces are nonswappable.
There are two DB2 databases, consisting of 11 tables for inventory tracking and 5 tables for stock control. Each table is in its own table space; partitioned and segmented table spaces are not used. Each table contains from 1 to 5 indexes, to ensure good performance, and is defined with "Lock Size ANY". All DB2 referential integrity constraints are defined with the "Delete Restrict" rule. The DB2 workload has moderate I/O characteristics.
Measurements are made with OS/390, DFSMS, JES2, RMF, VTAM, IMS/ESA, and DB2. IMS coat-tailing (enabling reuse of a module already in storage) is not used; since this activity is so sensitive to processor utilization, it could cause distortion when comparing ITRs between faster and slower processors. The DB2 LSPR workload does not take advantage of the DB2 sort assist feature found on the high-end ES/3090* and ES/9000 processors, because the transactions do not happen to invoke sorts. Performance data collected consists of IMSPARS, DB2PM, and the usual SMF data, including type 30 records (workload data), and RMF data.
DB2 is measured by logging on the number of terminals required to reach the target utilization. Measurements are made at 70% and 90% processor busy. Each terminal starts executing scripts consisting of end-user actions. The average think time is approximately 4 seconds, with a uniform distribution ranging from 75% to 125% of the average applied. After the logons are complete, a stabilization period is used to ensure that the DB2 buffers are fully primed. Once the system reaches steady-state, the measurement is made for an elapsed time deemed adequate to produce a repeatable sample of work.
TSO - Online Workload for pre-z/OS version 1 release 4
The TSO workload is representative of the work done by a typical OS/390 end-user community developing and testing programs interactively using ISPF/PDF. Workload activities include editing and browsing source data, compilation, execution, program testing, graphics, and Info/Management transactions. CLISTs are both explicitly and implicitly invoked.
Measurements are made with OS/390, DFSMS, JES2, RMF, VTAM, and TSO/E. The workload also uses ISPF/PDF, COBOL/VS and COBOL Prompter, PL/I Checkout Compiler, Script/VS, GDDM, and INFO/SYS program products. SMS is used to manage non-system data. RACF is used to control access to user datasets. Performance data collected consists of the usual SMF data, including type 30 records (workload data), and RMF data.
TSO is measured by logging on the number of terminals (end-users) required to reach the target utilization. Measurements are made at 70% and 90% processor busy. There are 25 different scripts, each consisting of a related set of activities in the form of TSO commands. The average think time is 15 seconds. A negative exponential distribution is applied to the think times so that half are 2 seconds or less, and 80% are 8 seconds or less. After a terminal completes a script, the entire process is repeated. TSO is measured as a steady-state workload over an elapsed period deemed adequate to produce a repeatable sample of work.
Historically, TSO measurements were made with simulated local VTAM terminals. Due to the greater number of terminals required on larger systems, measurements are made with simulated remote VTAM terminals for OS/390.
FPC1 - Engineering/Scientific Batch Workload For pre-z/OS version 1 release 4
The FPC1 batch workload is an engineering and manufacturing batch jobstream, representative of scientific data development work. It includes jobs doing static analysis, dynamic analysis, computational fluid dynamics, nuclear fuel calculations, and circuit analysis. Being scientific work, it makes heavy use of floating point. While FPC1 is a processor intensive workload, it also places significant demands on external resources such as central storage, channels, and DASD.
Measurements are made with OS/390, DFSMS, JES2, and RMF. FORTRAN H Extended and MSC/NASTRAN TM software is also used by the jobstream. Performance data collected consists of the usual SMF data, including type 30 records (workload data), and RMF data.
The FPC1 job stream is replicated to assure a reasonable measurement period, and the job queue is pre loaded. Enough initiators are activated to ensure a high steady-state utilization level, approaching 100%. The measurement is started when the job queue is released, and ended as the last job completes. Each job in the job stream uses its own datasets in order to eliminate dataset contention.
Note: Since the LSPR is intended to characterize System/370, System/390 architecture, and z/Architecture processors with standard features, FPC1 has not been implemented to take advantage of an integrated vector facility where available.
|
Linux TM on zSeries |
WASDB/L - WebSphere Application Server and Data Base under Linux on zSeries
The WASDB/L workload reflects an e-business environment where a full function application is being run under Linux on zSeries in an LPAR partition. For LSPR this was accomplished by taking the WASDB workload (described above under z/OS), and converting it to run both application and data base server in a single Linux on zSeries image. The WASDB/L workload is basically the same as the WASDB workload on z/OS with the exception of being enabled for Linux on zSeries. See the ‘WASDB - WebSphere Application Serving and Data Base’ section for a detailed description.
The following software levels were used:
- Linux on zSeries SLES 9
- WAS 6.1.0.0
- UDB 8.2
|
z/VM |
WASDB/LVm - many Linux on zSeries guests under z/VM running WebSphere Application Server and Data Base
The WASDB/LVm workload reflects a server consolidation environment where each server is running a full function application. For LSPR this was accomplished by taking the WASDB workload (described above under z/OS), and then replicating the Linux- guest a number of times based on the Nway of the processor. Guest pair activity was then adjusted to achieve a constant processor utilization for each Nway. Thus the ratios between processors of equal Nway are based on the throughput per guest rather than the number of guests.
The following software levels were used:
- Linux on zSeries SLES 9
- WAS 6.1.0.0
- UDB 8.2
See the ‘WASDB - WebSphere Application Server and Data Base’ section above for a description of the WASDB workload.
CMS1 - CMS Workload used for z/VM
The CMS1 workload is designed to represent a VM/CMS end-user community. Processor time per command, I/Os per command, T/V ratio, and think time distribution are similar to those observed for actual VM production systems running large numbers of CMS users.
Each user runs as a separate virtual machine under VM, which IPLs CMS and enters a variety of CMS and CP commands. Each has access to its own read/write minidisks, and a shared read-only minidisk containing all of the data files required by the script activities. In addition, each user has access to shared minidisks containing the CMS system and containing the software products required by the workload. All user accessible software is installed as shared code where supported.
Software used includes z/VM or VM/ESA, TCP/IP VM, VS COBOL II, VS FORTRAN, IBM High Level Assembler, and OS PL/I. SCP exploitation includes the use of minidisk caching, spooling, paging, and virtual disks in storage. VM Monitor data is collected and post-processed by VMPRF.
CMS1 is measured by logging on the number of terminals (end-users) required to reach the 90% processor utilization target. There are 14 different scripts, each containing a related set of activities in the form of end-user commands. The average think time is 9 seconds. CMS1 is measured as a steady-state workload over an elapsed period deemed adequate to contain a repeatable sample of work.
|
pre-z/VM |
PD - CMS Program Development On-line Workload for pre-z/VM
The PD workload is designed to represent a VM/CMS end-user community whose processing demands are of a CPU-intensive nature. Workload activities, while including some program input, tends to emphasize compilation, execution, and program test using interactive debug software.
Each user runs as a separate virtual machine under VM that IPLs CMS and enters a variety of CMS and CP commands. Each has access to its own read/write minidisk, and a shared read-only minidisk containing all of the data files required by the script activities. In addition, each user virtual machine has access to shared minidisks containing the CMS system and containing the software products required by the workload. All user accessible software is installed as shared code where supported (the amount of shared code used for PD is nominal).
Software used includes VM/ESA, CMS, XEDIT, FILELIST, APL, BASIC, COBOL, and COBOL Interactive Debug. SCP exploitation includes the use of minidisk caching, spooling, and paging. VM Monitor data is collected and post-processed by VMPRF.
PD is measured by logging on the number of terminals (end-users) required to reach the 90% processor utilization target. There are 7 different scripts, each containing a related set of activities in the form of end-user commands. The average think time is 14 seconds. A negative exponential distribution is applied to the think times so that half are 5 seconds or less, and 80% are at or under the average. After a terminal completes a script, the entire process repeats itself. PD is measured as a steady-state workload over an elapsed period deemed adequate to contain a repeatable sample of work.
HT - CMS High Transaction On-line Workload for pre-z/VM
The HT workload is designed to represent a VM/CMS end-user community whose processing demands tend to be of a trivial nature. Many commands are of the type which would normally produce an instantaneous response. Workload activities include a high percentage of editing subcommands, along with a variety of assemblies, compilations, and executions.
Each user runs as a separate virtual machine under VM that IPLs CMS and enters a variety of CMS and CP commands. Each has access to its own read/write minidisk, and a shared read-only minidisk containing all of the data files required by the script activities. In addition, each user virtual machine has access to shared minidisks containing the CMS system and containing the software products required by the workload. All user accessible software is installed as shared code where supported (since the HT workload references more software than does PD, the amount of shared code is much greater).
Software used includes VM/ESA, CMS, XEDIT, FILELIST, Assembler, APL, BASIC, COBOL, COBOL Interactive Debug, FORTRAN, and Script/VS (DCF). SCP exploitation includes the use of minidisk caching, spooling, and paging. VM Monitor data is collected and post-processed by VMPRF.
HT is measured by logging on the number of terminals (end-users) required to reach the 90% processor utilization target. There are 20 different scripts, each containing a related set of activities in the form of end-user commands. The average think time is 14 seconds. A negative exponential distribution is applied to the think times so that half are 5 seconds or less, and 80% are at or under the average. After a terminal completes a script, the entire process repeats itself. HT is measured as a steady-state workload over an elapsed period deemed adequate to contain a repeatable sample of work
|
VSE (appearing in previous versions of LSPR) |
CICS On-line Workload
The VSE CICS workload consists of light to moderate transactions from diverse business applications including order entry, stock control, inventory tracking, production specification, banking, hotel reservations, and teller system. The application programs are written in COBOL or Assembler. These applications are functionally similar to those used for the OS/390 CICS workload, described earlier. However, the workload similarity ends here; the number of transactions managed by CICS and the rest of the software environment are extremely different. The VSE CICS workload consists of 17 unique transactions, using various combinations of CICS functions.
Two independent and equivalent CICS partitions are run in order to effectively utilize the processor. Each has access to its own datasets, to avoid potential dataset I/O contention. The CICS workload accesses 16 VSAM KSDS datasets, and has a moderate I/O load.
Software used includes VSE/ESA, CICS/VSE*, ACF/VTAM*, and VSE/VSAM. SCP exploitation includes the use of VSE/POWER and of ACF/VTAM, each in their own address spaces, allowing virtual storage constraint relief. Access methods used include SAM and VSAM.
CMF data, used to report CICS response time and total transaction counts, is logged and then processed by the CICSPARS post processing facility. Goal System's EXPLORE TM is also used to gather system performance data including CPU utilization, channel path utilization and DASD utilization.
CICS is measured by logging on a predetermined number of terminals, each of which starts executing scripts consisting of end-user actions. Once the logons are complete, the average think time is adjusted to provide a transaction rate that causes the processor to reach the target utilization level. After appropriate stabilization periods, measurements are made at 70% and 90% processor busy. The average think time is approximately 15 seconds for the 70% run and 11 seconds for the 90% run, with a uniform distribution ranging from 75% to 125% of the average applied. CICS is measured as a steady-state system over an elapsed period deemed adequate to produce a repeatable sample of work.
CICS - On-line Workload as a VM/ESA V=R Guest
The VSE CICS workload described above is also run under VM/ESA as a single preferred V=R guest. There is no other virtual machine activity. In addition to the normal performance data, VM monitor data is used to determine actual processor utilization.
As with all LSPR data, the value of doing these VM/VSE measurements lies in being able to provide relative capacity between processors when the SCP influence on the processor contains both VM and VSE elements. While the cost of running the VSE CICS environment under VM can be determined by comparing the VM/VSE data to the VSE basic-mode data on the same machine, this comparison is only meaningful for the single V=R guest case.
The following terms, denoted by an asterisk (*) on this Web page, are trademarks or servicemarks of the IBM Corporation in the United States or other countries or both:
- ACF/VTAM
- CICS/VSE
- ES/3090
- GDDM
The following terms, also denoted by the symbol ( TM ) on this Web page, are trademarks or servicemarks of other companies.
- MSC/NASTRAN MacNeal-Schwendler Corp.
|
