Computer Corporation of America
|
Feedback
Search CCA:
   
USA CCA
CCA Products
CCA Customer Support
CCA Resources
CCA - Company
CCAPRINT: A Newsletter for Model 204® and System 1032® Users
May 10, 2002

System 1032

A Double Delivery Commercial Release

By Tym Stegner

Introducing System 1032 V9.8

By now most System 1032 sites have received a package* from CCA that contains the anticipated System 1032 V9.8 release.

Version 9.8 is fundamentally a maintenance and reliability release. The full list of corrections is on page 4 of the System 1032 Release Notes V9.8, which is included in your shipment.

The new functionality included in Version 9.8 is an extension of the API. This feature is currently limited to use by ODBC Driver

Another feature of this release is our newly consolidated distribution. Not only does the CD contain the VAX and Alpha versions of System 1032 V9.8, but it also contains System 1032 ODBC Driver, Version 3.3 and Version 4. The VAX and Alpha versions of the System 1032/Application Facility, our menu-driven application generation utility, is on the CD as well.

ODBC Driver and System 1032/Application Facility are separately licensed products, which require only an updated Licensed Application Form for execution. Please contact System 1032 Support to set up an evaluation.

Introducing ODBC Driver V4

ODBC Driver V4 incorporates not only fixes to both the server and the Dictionary utility, it also incorporates a significant change to the underlying multitable SELECT engine. In versions of the ODBC Driver prior to V3.2, multitable selections were made by generating a view dataset. Then MAP processing populated the view with the necessary records based on the selection criteria.

In ODBC Driver V4, generating the view dataset has been replaced by a callable PRINT command. This reduces time to first record retrieved, as well as an overall reduction in resources necessary to the query. Although the ODBC engine limits this functionality to two-table queries, even three or more table queries will reap the benefit of the enhancement.

Best of all, you don't need to change any of your SQL queries to take advantage of the improvement!

ODBC Driver V4 must be used in conjunction with System 1032 V9.8 for the callable PRINT command feature to take effect. If you are unable to upgrade to System 1032 V9.8 right away, you can install ODBC Driver V3.3, which contains all of the ODBC Driver V4 enhancements except the callable PRINT command feature.

Updated Manuals

In addition to the improvements to the ODBC Driver described in the ODBC Driver Release Notes V4, extensive work was done on the ODBC Driver Installation and Maintenance Guide. This work integrated all the documentation corrections and dictionary upgrades, as well as incorporated performance and usage information gleaned from the last two years of ODBC Driver usage by the customer base.

The ODBC Driver Installation and Maintenance Guide is included on the distribution CD in the DOCUMENTATION directory.

In Summary

System 1032 Support encourages all customers to upgrade to the new versions. Both System 1032 V9.8 and ODBC Driver V4 have proved to be very stable in the extended beta test of both products. CCA gives great thanks to the beta testers for their diligence.

* If you have NOT received your package, or if the site contact for your site has not received it -- print $MAINTAINER if you are not sure who should have received the upgrade -- then please contact System 1032 Support at 508-270-6666. We will help track your shipment or determine why it wasn't sent.

Model 204

Tracking Transactions for Performance: Part 2

By Jim Damon

What Is a Transaction?

In Part 1, April 2002 edition of CCAprint, I identified the READ SCREEN statement and its associated SCREENS statistic as a measure of one kind of transaction in a Model 204 Online system. Since most Model 204 production Onlines run predominately full-screen application subsystems (APSY), most of the transactions (+80%) processed in these Onlines are accounted for by the SCREENS statistic.

But how do we account for the other transactions that are not part of full-screen, APSY subsystems? The following list is a small sample of other units of work that may be processed in an Online, but for which there is no discrete counter like the SCREENS statistic:

User Language requests which may issue many FIND statements and may process many records in FOR loops to:
STORE, DELETE or update records
Send reports to external datasets or printers
Requests from BATCH2 and IFAM2 threads
Connect* RCL or SQL requests
Horizon RCL or SQL requests
MQ/204 requests to and from the IBM Websphere MQ product
CREATE FILE and INITIALIZE commands
DUMP and RESTORE commands
COPY PROCEDURE commands
Miscellaneous system and file commands such as, MONITOR, DISPLAY, VIEW, DEFINE, and the like

All these units of work consume CPU. Many perform database I/O and many require the allocation of CCATEMP pages in the buffer pool or the allocation of temporary storage from SPCORE. So how do you as a system manager deal with these units of work? If you called them transactions, how would you count them? A single DUMP command may read and write 1,000 database pages or 100,000 pages. A COPY PROCEDURE command may copy ten procedures or 10,000. There are several solutions to this dilemma. They are subjective depending on the measurement goals you're trying to achieve.

Defining a Transaction

There is no industry-accepted definition of a transaction. What constitutes a transaction depends largely on the type of business, or even the individual system or application under review. Deciding which transaction definition to use is determined by a number of interests.

You may choose a transaction definition that yields the greatest number of transactions processed per second to demonstrate your highly efficient system. For internal reporting and performance measurements, you may choose a definition that more closely reflects what full-screen, end-users actually see, screen-to-screen. Both are valid definitions, but each views the system or application under review from a different perspective.

We will use the end-of-run statistics from CCAAUDIT at a customer site to show how to evaluate each definition:

AUDIT=15660446 OUT=9529 IN=3005 OUTXX=6 INXX=37 DEV5=6837931 DEV6=67996267 DEV7=2141929 DEV8=1929003 DEV9=127 DEV10=15112424 DEV11=2 OUTTTY=4299 INTTY=1600 DEV27=53083 OUTCRAM=1135897 INCRAM=500205 INVMIO=161176 OUTVMFS=10230 DEV52=6651 WAIT=8106555 DKRD=36266057 DKWR=11685665 SVRD=743691 SVWR=745091 CPU=79821116 REQ=8185582 MOVE=48509988 SLIC=44942 CNCT=53999 SWT=21107 RECADD=919226 RECDEL=466850 BADD=99576166 BDEL=22841834 BCHG=9375376 IXADD=2590184 IXDEL=1797337 FINDS=46901235 SORTS=422989 RECDS=242113417 STRECDS=3948097 DKAR=245872253 . . . WAIT=38636654 STPOST=613668 LKWAIT=2617658 LKPOST=2617864 RSXCOMP=5 SCREENS=1837763 STIMERS=45163 SVPAGES=137409786 COMMITS=660243 BACKOUTS=4101 . . .

 

All Transactions Are SCREENS

The first and simplest definition considers all transactions that are not full-screen as overhead. Our presumption is that the resources they consume are averaged across all full-screen transactions thereby exaggerating, not insignificantly, the amount of work done by those transactions. However, this greatly simplifies measurement and monitoring for changes in performance.

If we use the SCREENS statistic as a transaction counter, then the following ratios are indicative of overall performance in this Online:

What you are evaluating

Statistic used

Count

Total transactions processed

SCREENS

1,837,763

Total elapsed time for the run

CNCT

53,999 secs

Transactions per second

SCREENS/CNCT

34

CPU(ms) per transaction

CPU/SCREENS

43 ms

Database I/O per transaction

DKRD+DKWR/SCREENS

26

Server swaps per transaction

(SVRD+SVWR)/SCREENS

.8

 

SCREENS, Plus Other Work

A second transaction definition uses a derived value for the transaction count. The REQ statistic counts the total number of User Language requests evaluated. Based on the large values for INCRAM and OUTCRAM in this collection of statistics, it's safe to presume that a fair number of User Language transactions that are not full-screen are processed on remote User Language CRAM threads (IODEV=29). Depending on what is known about the environment, it might be reasonable to say that a more accurate measure of total transactions processed is (SCREENS + .5 * REQ). That would change our performance measurements as shown in the following table:

What you are evaluating

Statistic used

Count

Total transactions processed

SCREENS+.5REQ

5,930,554

Total elapsed time for the run

CNCT

53,999 secs

Transactions per second

SCREENS+.5REQ/CNCT

110

CPU(ms) per transaction

CPU/SCREENS+.5REQ

14 ms

Database I/O per transaction

DKRD+DKWR/SCREENS+.5REQ

8

Server swaps per transaction

(SVRD+SVWR)/SCREENS+.5REQ

.25

 

Finding Records (FINDS statistic)

A third definition takes the view that all transactions start with a FIND or SELECT (SQL) statement. Regardless of whether the transaction is read or update, a User Language full-screen or a transaction that is not full-screen, SQL, Horizon, BATCH2, CRAM Host Language, IBM Websphere MQ, or Connect*, each transaction starts at the FIND or SELECT statement. Recognizing that some requests will issue one FIND statement, and process 100,000 records and others will process one record per FIND, we have the following ratios:

What you are evaluating

Statistic used

Count

Total transactions processed

FINDS

46,901,235

Total elapsed time for the run

CNCT

53,999 secs

Transactions per second

FINDS/CNCT

870

CPU(ms) per transaction

CPU/FINDS

1.7 ms

Database I/O per transaction

DKRD+DKWR/FINDS

1

Server swaps per transaction

(SVRD+SVWR)/FINDS

.03

 

Counting Records

Finally, using the most inclusive definition, you could argue that touching a record in a FOR EACH RECORD loop, which is counted by the RECDS statistic, constitutes a transaction. Again, virtually all request types, as listed in Finding Records (FINDS statistic) increment the RECDS statistic. If we use the RECDS statistic as a transaction counter, the ratios to measure performance are:

What you are evaluating

Statistic used

Total count

Total transactions processed

RECDS

242,113,417

Total elapsed time for the run

CNCT

53999 secs

Transactions per second

RECDS/CNCT

4484

CPU(ms) per transaction

CPU/RECDS

.33 ms

Database I/O per transaction

DKRD+DKWR/RECDS

.2

Server swaps per transaction

(SVRD+SVWR)/RECDS

.006

 

Using a transaction definition

Regardless of which definition makes sense for your organization, once you have defined what constitutes a transaction in your environment, you have also defined the metric you will use for:

Note: Each of the transaction definitions includes some overhead that cannot be excluded. The DUMP and RESTORE commands, for example, do not increment any of the four statistics chosen as a transaction counter. However, these commands do increment the DKRD, DKWR, and CPU statistics. The same is true for CREATE, INITIALIZE, COPY PROCEDURE, and several others.

Summary

The cost of processing a transaction is the cumulative cost of three resources:

Full-screen, end-user response time is dependent on the speed of access to those resources. The speed of access, combined with estimates on record and resource locking conflicts and network delays, provides a more complete picture of response time. Changes in the rate at which these resources are consumed measures performance.

Coming Attractions

The consumption and rate of consumption of these resources is determined by a variety of environmental factors that are controlled in large part by system and Model 204 parameter settings. In Part 3, I’ll discuss how to make these measurements and estimates.

Insight 204

Register TODAY for Insight 204!

By Marie Kelly

We are excited to invite you to this year’s symposium -- Insight 204: Extending the Power -- being held September 17­20 in Boston. With a new version of Model 204 released this year and a new product planning cycle underway, this event is clearly not-to-be missed if you are involved with Model 204 applications.

What Will I Get Out of Insight 204?

Organized by Computer Corporation of America, Insight 204 offers significant benefits not found at any other event, including:

Where Is Insight 204 Being Held?

This year’s symposium is being held right in Boston at the Hyatt Harborside Hotel. Perched on the edge of Boston Harbor and facing the city, this world-class hotel not only offers first-rate conference and lodging facilities, it is one of the most convenient locations in the city for getting around easily and cost-effectively. Unless you plan to travel outside of the city, you will not need to rent a car, if you fly in for the conference. For more information about the hotel, visit http://www.hyatt.com/corporate/gateway/gateway_boston.jhtml.

Symposium Registration Is FREE!

Because we want to make sure that you are using Model 204 to its fullest, there is NO CHARGE for the symposium itself. You pay only for your travel and lodging expenses, and for meals not included with the symposium.

Stay Tuned for More Information!

Over the next month, we will provide detailed information on the specific presentations, partner participation, product demonstrations, and other special events you can expect to see at Insight 204. So bookmark the Insight 204 Web site (http://www.cca-int.com/resouces/usergroups/insight/main.html) and stay tuned for future e-mail updates!

To the CCA User Community

From the Editor

Recently we published articles that developed ideas and shared some code from two long-time customers at different sites. It was a great pleasure to work with these people. We think this is the best type of article to present in CCAPRINT -- an article that addresses the on-the-job needs of our user community.

  • We would love to hear from you if you have something to share.
  • We would love to hear from you if you would like to have a particular topic discussed.

Just dash off a quick e-mail message telling us what you would like to share or what you would like to see discussed in print. Send your comments and ideas.

 

Copyright © 2008 Computer Corporation of America.
All right reserved. Published in the United States of America.


Contact CCA Webmaster
Copyright 2008