Impact '98 - Miami: Sunday, May 31-Wednesday, June 3, 1998
Analyzing Connect* Client/Server Messages
By Mark LaRocca
Anyone who uses client/server software such as MS/Access, Crystal Reports, or Infomaker, or writes client/server applications using Visual Basic, C++, or PowerBuilder, for example, knows the frustration of trying to identify and interpret error messages. Most often, they appear in the form of error message boxes on your PC. You must then press OK, close your application, figure out what's wrong, correct the problem, and try again. To accomplish this, you must answer the questions:
To answer these questions, you need to know what pieces of software are combined to make your client/server application. This article addresses these questions and touches on some of the common error messages seen by users accessing Model 204 data via client/server applications.
Keep in mind that error messages are frequently displayed in clusters, an initial error setting off a chain of errors. You might have to research them all to determine which one triggered the others. Yet, they might be independent.
Connect* allows you to access Model 204 data from your PC via:
Connect* also manages the communications to Model 204, specifically, to the CCA Horizon product running within Model 204. The network communications between Connect* (your PC) and Model 204 (mainframe) can be TCP/IP or SNA LU6.2 - Advanced Program-to-Program Communications (APPC), a protocol developed by IBM.
Errors are generated by the products involved in the client/server application accessing the Model 204 data. Error messages on the PC usually identify themselves according to type and software origin. Table 1 lists the types of errors with formats and identifies by number the probable software origin of the error. Table 1 is followed by a number key to the possible origins of the error.
*Software origins of error messages:
SQL errors can be common syntax errors. For example, entering a SELECT statement such as:
SELECT * DEMO.CLIENTS
returns the following error at the PC: SQL Error -2060, Syntax error in identifier at position 10 A close inspection shows that, at position 10, FROM was left out.
The Model 204 audit trail gives this same information in the form: M204.2500: SQL ERROR -2060: Syntax error in identifier at position 10 The previous example is a simple error; when the error is more complex, check the Model 204 audit trail. The SQL errors commonly seen by Model 204 users are listed in Model 204 SQL Error Code Messages. Check this book first, because it tells you what the error means and how to fix it.
In a test environment, you can set LAUDIT=16 on your IODEV 19 threads. This causes all SQL-related statement processing to be listed on the audit trail.
Applications that use ODBC to communicate to Model 204 interact with the Model 204 ODBC driver. Often errors or warnings are displayed to the PC. To determine if the application has failed, you must interpret the error message and look at the audit trail.
It is possible that the transaction has succeeded and the message is only a warning. Many times these errors are confused with communication failures, because the connection ends.
Consult Table 1 for ODBC error formats. Some common errors reported are:
Your application issued an SQLCancel. Check the audit trail.
An ODBC statement was executed out of sequence. For example, the program ended without properly disconnecting.
To resolve these types of errors, refer to an ODBC reference such as the Microsoft ODBC 2.0 Programmer's Reference and SDK Guide published by Microsoft Press.
Additional errors reported by the Connect_ ´ Model 204 ODBC driver might indicate communication failure or actual program failure. They are of the form HZnnn or S19nn and are a CCA extension of the ODBC errors.
For example:
The connection failed. Look for other ODBC errors. Check the audit trail.
The application might have abended.
The Microsoft Jet Engine often returns a class of ODBC errors that are recognizable by their format: -77nn, as in the following example: ODBC Specification Conformance Error (-7711) This error should be reported to the ODBC Driver vendor. An "ODBC Specification compliance error" usually requires a trace of the ODBC calls at the PC to debug. As a reference, see the Jet Database Engine ODBC Connectivity White Paper available on the Web from http://www.microsoft.com. This paper contains a list of these errors and their meanings.
The previously discussed errors can often cause communications to end or fail, or there might be a totally independent reason for a communications failure. Check the Model 204 audit trail when a communications failure is indicated. Many such failures are accompanied by an APPC (LU6.2) return code.
Note the format of communications errors: a statement followed by a return code. The following APPC error indicates a communications failure; the lack of communications was because a Model 204 region was not available: communications error; MC_ALLOCATE - FAILED - primary rc rc X'3'. [AP_ALLOCATION_ERROR] secondary rcX'4' [AP_ALLOCATION_FAILURE_NO_RETRY], in SQLConnect
Because all communications from Connect* at the PC to Horizon and Model 204 on the mainframe are governed by the APPC protocol, you might see references to APPC errors at any time, even when using TCP/IP.
A good reference for the APPC return codes is the NetWare LU6.2 Technical Reference; see the list in Appendix A. Note, however, that APPC errors are not specific to Novell.
Some errors might not fall into these specific categories. If in doubt, call CCA Customer Support.
Applying System 1032 Text Attributes
By Tym Stegner
This article is the second of a two-part article on Text attributes. The first article, "Understanding Text Attributes," appeared in the December 1997 issue of CCAPRINT.
Questions and Answers What happens if you miscalculate the update frequency of Text Varying attributes?
Because the attribute values and structures are stored contiguously, updating an attribute's value requires moving everything downstream from the changed value, as well as updating locators and lengths within the record and attribute structure blocks. The reverse is also true, for when an attribute's value is shrunk: everything downstream must be moved toward the front and the locators must be updated.
The primary reason for the expansion padding is to reduce the need for repositioning downstream structures, thus requiring only lengths to be updated in the structure blocks.
Sooner or later, expansion space is used up, and/or the space in the data cluster is used up. At this point, additional data clusters must be allocated, so that the downstream values have a place to move into.
What if you don't know how frequently text is updated?
If you don't know how frequently or to what extent your text data is updated, define it as Text n, until the data stabilizes and you can evaluate the update frequency.
What if you must use Text Varying because you store reports?
The UPDATE option becomes your efficiency consideration. Try to choose an update frequency that shifts and relocates the data as infrequently as possible.
How should you regard MISSING values in a Text Varying attribute?
A Text Varying attribute represents a varying length string; you can decide the initial, maximum, and incremental size of the attribute. The default Text Varying attribute data storage is:FROM 16 BY 16 TO 65535
If many records in the dataset are expected to have a MISSING value for the Text Varying attribute, use a value of zero in the FROM clause (FROM 0...) to minimize the data storage.
The following scenarios are examined to determine whether to choose Text Varying or Fixed Length text.
Figure 1 is a partial dataset definition with 4 potential Text attributes, currently defined as Varying.
... Atr ADDRESS_1 or AD1 Text Varying To 40 Atr ADDRESS_2 or AD2 Text Varying To 40 Atr FIX Text Varying To 100 Atr COMMENT or CMT Text Varying To 250 ...
Table 1 compares the storage requirements of Varying and Fixed Length text. This is a worst case scenario: all values are always filled to capacity. Each Text Varying attribute has overhead of 8 bytes, plus an additional 2 bytes as a portion of the small class header. (Refer to "Building data clusters" in the December 1997 issue.)
Table 1 illustrates that you would do just as well to use Fixed Length text and save all the Text Varying overhead.
In a better case scenario, still using the attributes from Figure 1, assume that you have knowledge of the average sizes of the data and that the data is not updated. Table 2 illustrates the changes.
Table 2 shows that you would definitely use Text Varying, as you save 78% of the fixed length space.
And in a final scenario, now suppose that you have the same attributes, but they are subject to updating, although you do not know how frequently. The default update frequency is MODERATE, leaving 25% of the total space of the attribute free for expansion, but where expansion space is necessarily limited to the maximum size of the attribute, as shown in Table 3.
Table 3 shows that you still save 53% of the needed storage space. However, you know from the way Text Varying data is stored that you would suffer a decrease in query and update speed.
In this scenario, CCA recommends that you make the AD1 and AD2 attributes Fixed Length Text and keep the FIX and CMT attributes as Text Varying.
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
Contact CCA Webmaster Copyright 2008
