System 1032 — Model 204
So you have ODBC, now what...
by David Stone
You have taken the plunge: System 1032 ODBC Driver or Connect * for Model 204 is installed on your system. Now what?
This article is the first of three articles about ODBC. These articles discuss:
In the second and third articles, examples present ways that you can use ODBC. Along the way, we note the differences in the ODBC drivers and servers for Model 204 and System 1032, keeping in mind that not all examples work on both systems.
What’s in an ODBC-ready system
The following components complete an ODBC- ready system:
Underlying the software is the ODBC standard, published by Microsoft, which describes an application programming interface (API) for accessing a database.
What ODBC does
The real power of ODBC, is that, using the ODBC set of standard database calls, one application can access multiple databases. In fact, most ODBC-compliant applications allow you to specify the database at run time.
Because of the develop-once-use-many-times philosophy, ODBC compliant applications have flourished. Literally thousands of applications can use ODBC to provide a data conduit.
A standard in progress
As originally conceived, ODBC was expected to provide a standard that would allow applications to utilize the user’s database of choice. However, ODBC has turned out to be less than the universal standard that was once hoped.
The ODBC standard is continuously revised and published by Microsoft. Each version of the standard specifies a set of functions and SQL language constructs that must be accepted by a driver in order to claim compliance. In addition, several levels of core functions and extended functions can be defined. As a consequence, an application can be developed that requires functions or SQL commands not supported by a particular driver or server.
Note that a well-written ODBC-compliant application queries the driver for its capabilities, and then uses only the capabilities provided by the driver. Not all applications, however, are well written.
What ODBC does not do
ODBC is not a programming language. While ODBC requires the use of the SQL language syntax, it does not provide translation from SQL to non- SQL databases. Therefore, the ODBC drivers for Model 204 and System 1032 provide application- specific translators to convert from SQL to native commands, as needed.
ODBC is also not a generic messaging middle- ware package. The standard does not specify how an ODBC driver connects to a database server, or the format of the information transferred between the client and the server. Therefore, each database that you want to use has a specific set of drivers. The driver for System 1032 does not work with Model 204, and vice versa
What’s next?
The next article will explore the development of ODBC applications using third-party products such as Microsoft Excel, among others. It will also introduce Rapid Application Development (RAD) tools for developing PC and web-based applications.
Model 204
Critical File Resources (CFRs) and Performance Implications
by Jim Damon
Critical file resources (CFRs) guarantee that users have a consistent and static view of the data, a snapshot of the data at an instant in time when it is not changing.
Four distinct CFRs exist for each file, and these provide access to different data structures:
Access to CFRs provides for data integrity in Model 204 in one of these ways:
Multiple users can have a SHR lock, but only one can have an EXCL lock.
The CFR implicated in most performance problems is the INDEX resource, as the following examples illustrate.
Read-only example
Assume that a user request requires one file with a field, LASTNAME (ORD CHAR):
FS1: FD LASTNAME IS ALPHA IN RANGE ’DAV*’ TO ’MUR*’
If the resource is not currently held by an EXCL lock, this user acquires and holds a SHR lock on the INDEX resource until the find completes. During that period, no INDEX updates can occur, because updates require exclusive access and this user is holding the resource in a SHR lock. Other users attempting INDEX updates must wait, WT code=24. The more I/O (DKRD) to Table D needed to resolve the find, the longer the wait.
Update example
STORE RECORD ... LASTNAME=FERGUSON END STORE
This user requires an EXCL lock on the INDEX resource, on the DIRECT resource to update Table B, and on the EXISTS resource to update the existence bit map. Assuming that the DIRECT and EXISTS resources are available, if the user in the Read-only example is running, the Update example user must wait, WT code=24. If other users require share access to the INDEX resource, they succeed and run, increasing the wait time for this user and any other user requiring exclusive access to the INDEX resource.
Managing exclusive access
Waits for CFRs are, by default, swappable and being swapped out to CCASERVR can result in even longer waits for updaters.
A CCAIN parameter, CFRWPCT, sets the percentage of NSERVS (0–75 percent) that can hold updating users in a wait state for CFR-EXCL, but the wait in these cases is nonswappable.
After initialization, VIEW CFRWPCT shows the actual number (CFRWPCT*NSERVS), not the percentage, of servers that have been so designated.
Setting the CFRWPCT parameter
If the MONITOR command (see Figure 1), consistently shows many users with a WT code=24, setting CFRWPCT might improve response time for those users.
Figure 1
For example, in Figure 1, GRUMPY is waiting for an EXCL lock, but is swapped in. DOC and SLEEPY are also waiting for an EXCL lock, but have the additional problem of being swapped out.
CFRWPCT would help improve their response time by keeping them in a server, in a nonswappable state, while waiting. When the resource does become available, they are already in the server and acquire the EXCL lock immediately, rather than having to first wait to be swapped in, a delay that risks losing the resource to a SHR lock user and repeating the wait, swap-out, swap-in cycle.
Note: CFRWPCT is not currently documented in the Model 204 Command Reference Manual.
August – October 1999
Contact CCA Webmaster Copyright 2008
