Model 204
by Jim Damon
The number of segments in a Model 204 file has a direct bearing on application performance and particularly on FIND statement performance. FIND statements are evaluated on a segment-by-segment basis and, as the number of file segments increases, the elapsed time (CPU and I/O) and the size of VTBL required to resolve a FIND also increase proportionately.
This concept is important in application development, which should include testing objectives for:
If care is taken in generating test files, application testing for functionality can yield the additional benefits of testing for adequate server-table sizes and of performance testing, which increases the level of confidence managers have when an application is migrated into production.
Application testing is usually conducted against only small samples of production data. While representative of the type of data the application encounters in production, these samples often do not represent production-file sizes or, more specifically, the number of segments involved in production files.
The result is testing that is devoted almost exclusively to correctness and functionality. The performance characteristics of an application remain unknown until the application is actually run in a production environment, where large, multi-segment files can cause unexpected and unacceptable response-time delays for end users.
The time, effort, disk space, and other expenses involved in maintaining full copies of production data for testing often cannot be justified. However, large, multi-segment file simulation can be accomplished in a test environment without actually loading all the data required to create a production-size, multi-segment file.
A segment is the number of record numbers that Model 204 can identify on one bit-pattern page in Table D and is equal to the number of bits in the usable portion of a page:
page = (6144*8) = 49152
You can set the BRECPPG parameter at file creation time to facilitate multi-segment file simulation. When BRECPPG=49152, every Table B page represents a segment's worth of records regardless of how many records are actually stored on the page. If you want to simulate a 5-million-record, 100-segment production file, for example, set BRECPPG as follows and load 50 records on each Table B page: BRECPPG=49152
If more test data is required in this 100-segment simulation, set BRECPPG as follows and load 200 Table B pages: BRECPPG=24576=(49152/2)
The number of records stored per page (when BRECPPG=49152) depends entirely on the average record length and the BRESERVE parameter. The objective for these test files, typically, is to store the maximum number of records per page (while avoiding extension records) in order to provide the largest possible sample of interesting data to the application to test. This can be achieved by setting BRESERVE to the average record length, the standard recommendation. Setting BRESERVE higher, when BRECPPG=49152, is the only way to actually limit the number of records per page to a specific, nominal value.
To accurately simulate production files and give performance results that approximate behavior in a production environment, records must be distributed across segments in the environment in the same way as they are in production. If, for example, a 5-million-record production file has some records for males and others for females, evenly distributed across 100 segments, then the simulated file must also have an equal number of male and female records in each of its 100 segments. In the 5-million-record example above, half the records on each page must be male and half female.
Additionally, if the 5-million-record production file has 5% of its records with STATE=CO and those records are concentrated in 5 or 6 segments, then 5 or 6 pages in the test file must have 250 records - alternately male and female, but all with STATE=CO.
One simple approach to accomplish this kind of segment distribution involves selecting 50 representative records (say every 1000th record) from each segment of the production file and loading those to the test file in the same order. You can identify the segment that a record is in as follows: $CURREC/49152
Worst-case performance testing refers to the results obtained in a test environment where each application is forced to do the maximum number of nonthrashing, nonrepetitive I/Os required by its specific processing needs. Testing in a single-user Online, using an unconstrained and empty buffer pool at the start of evaluation, is the best way to achieve this objective. Ultimately, the performance results obtained in a multiuser production environment, where physical I/O per transaction tends to be less as more users increase the probability of data sharing, contrast favorably with the results from the test environment.
If testing is done in a simulated multiuser environment using IODEV=3 threads or a network simulator like TPNS from IBM, a constrained buffer pool, smaller than the production environment by a significant percentage, is necessary, because these test files are so small that they easily fit, in toto, in the buffer pool, resulting in little, if any, physical I/O during testing.
The end result should be test results that simulate not only the data, but the true performance characteristics of production files and that, ideally, give worst-case performance results.
System 1032
Please join the System 1032 development team in polishing up the details of System 1032 products.
If your site is now eager to try the ODBC Driver, and you have installed System 1032 Version 9.70, you can test ODBC Driver, Version 2.1-2, which includes:
If you would like to try the new features in System 1032, you can test the beta release of Version 9.71-1. The new features in System 1032 support:
If you want to try the ODBC Driver as well, sign up for ODBC Driver, Version 2.2-1, which includes the redesigned metadata dictionary utility and the ODBC_DICTIONARY.EXE, as well as supporting 200 open datasets and Varying Length Text in record descriptors.
What can you expect as a beta site? Along with beta software and documentation, you are assigned your own System 1032 Customer Support partner, who assists you with installation and development issues as they arise. And, of course, you receive the first priority delivery of the commercially released software and documentation.
To sign up as a System 1032 beta site, contact System 1032 Customer Support at CCA: 508-270-6666 ext 700.
Enterprise Internet Solutions for the 21st Century
WebGate is an Internet-based software solution that helps you leverage your investment in Model 204 for conducting real business on the Web. It helps you transform your Web site from an electronic billboard into your most valuable and versatile business application.
By simply filling out templates, you can generate Web pages that provide fast, flexible access to Model 204 data. These pages are then easily incorporated into a company's Internet, intranet, or extranet Web site so that anyone with a browser and access rights can use them to query, update, and report on Model 204 data.
Why have a Web site that is nothing more than a collection of static pages? With WebGate, you can build interactive applications that:
These are examples of how you can use the Internet for conducting REAL business and impacting the bottom line. They require lightning fast access to potentially high volumes of data - something that Model 204 customers have always enjoyed.
WebGate from Computer Corporation of America now lets you extend the renowned power of Model 204 to a new class of applications that use the Web to strengthen your business.
On September 9, Computer Corporation of America publicly announced WebGate™, a new product designed to help your organization leverage the Web and Model 204 for conducting business. As a valued Model 204 customer, we invite you to attend a special regional briefing, where CCA representatives will present and demonstrate WebGate in more detail. The dates and locations of the briefings are:
*The Albany briefing will take place at the Northeast Model 204 User Group (NEMUG) 1998 Conference in Latham, NY from 8:00 a.m. to 4:00 p.m. To register for this conference, contact Sandy Cocco, NYS Department of State, at 518-474- 3335. Note that this conference includes other presentations in addition to the WebGate briefing, and that there is a NEMUG fee of $65 to attend this conference.
** Hotel locations for these cities will be forwarded upon receipt of registration form.
Each briefing will be held in the morning on the scheduled date from 9:00 a.m. to 1:00 p.m. Registration and a continental breakfast will begin at 8:30 a.m., and lunch will be served from 12:00-1:00 p.m.
We hope to see you soon at a regional WebGate briefing!
500 Old Connecticut Path, Framingham, MA 01701 webmaster@cca-int.com Copyright 2005
