Model 204 Autofix: Part 3
By Donna Goodwin
We conclude the series of articles on Autofix maintenance with a collection of helpful hints to assist you in the application of Early Warning fixes. We hope this helps you keep Model 204 at the most current level and as problem free as possible.
Eliminate zaps you can't use
Operating system fixes
Zaps that do not apply to your operating system are automatically eliminated. This is based on the operating system value that is entered in the first Autofix screen.
SQL option fixes
In your Autofix profile you can indicate whether or not you want fixes to SQL. Check to make sure that this is set correctly for your site.
Optional products fixes
Eliminate fixes that apply to products you don't have. For example:
No-zap fixes
Be sure to read the no-fix fixes. They usually contain important documentation updates.
Create the zap files
After you press the PF10/Apply key, you'll receive a message that the extract of Early Warnings has completed. Figure A is an example of the object modules you might have downloaded. Print this screen - you'll need it to construct your relink job.
Figure A. Autofix screen showing extracted objects
PROCESS FUNCTION CONFIRMATION ************************************************************************* THE APPLY EXTRACT FUNCTION FOR OBJECT HAS COMPLETED TO THE OUTPUT LOCATION(S) SPECIFIED.
OBJECT: USE ARG: OBJECT: USE ARG: OBJECT: USE ARG: BXCI OUTBXCI EVSO OUTEVSO IFAS OUTIFAS IFDM OUTIFDM RSQL OUTRSQL ************************************************************************** ===> PRESS <ENTER> KEY TO CONTINUE
Avoid overwriting OUTZAPS
At this point you should copy your OUTZAPS file to another dataset. The reason for this is that when you look at fixes through Autofix, you might mistakenly press the PF10/Apply key when you wanted to press the PF9/Display key. This action will overwrite your OUTZAPS file.
Construct and run relink job
In some cases there are fixes that have both object replacements and also zaps.
Note: You never have multiple object decks for a module for a specific release.
Use the printed screen output to determine what new object replacements should be relinked in OS/390 and VSE or linked in VM. Execute the relink, after making backups, of course.
Analyze the OUTZAPS file
Analyzing the OUTZAPS file is the lengthiest task you have in Autofix. You need to determine what special handling fixes you have. Special handling fixes are marked in the OUTZAPS file; the fixes are commented out. They are issued for the following reasons:
Note: If you have not kept current with maintenance, CCA suggests splitting up the OUTZAPS file into smaller chunks to more easily analyze the output. If by chance you get a return code greater than 4 on your zap job, look for the string NO GO in the output - this should get you right to the problem area.
Back out superseded zaps
Some modules have a mixture of zaps and object replacement modules. Fixes are issued incrementally. When you apply a new object replacement, a previous fix may no longer apply.
The Autofix Notes that accompanies the Autofix tape tells you which fixes no longer apply. Figure B is an example from the current Autofix Notes.
Figure B. From Autofix Notes
V4R2.0 EW 129 This early warning contains a BXCI object deck replacement. Previous to this early warning, we have released the following zap maintenance to BXCI:
420EW003 - All operating systems 420EW105 - All operating systems
These zaps will no longer apply after linking in this new BXCI object replacement. Also, any subsequent early warnings that contain zap fixes to BXCI on this or future Autofix tapes will apply only after linking in the BXCI object replacement in this early warning.
Based on the information in Figure B, you need to edit your OUTZAPS file to take out the BXCI parts of Fix 3 and Fix 105. You may be left with only the EWDP zap for the Early Warning. The EWDP turns on the bit that indicates the fix was applied. Leave the EWDP part in - the fix really was applied because it was included in the object replacement. Later you won't be confused by not seeing the EW in the display.
Conclusion
Keep your maintenance current and don't pick and choose specific Early Warnings to apply. Put on all the fixes that are applicable to your site. This concludes the series on Autofix. Parts 1 and Part 2 appeared in the March and April 2000 editions of CCAprint, respectively.
Model 204
Sending E-mail from Your Model 204 Application
by Liz Blaney, System Manager, CCA Cerise
E-mail provides a quick, inexpensive, and easy way to distribute output from your Model 204 application. E-mail offers a number of advantages:
We started e-mailing reports to CCA customers, who run Model 204 applications on our Bureau machine, Cerise. We found more and more useful applications for it. Our customers and our own development team like the ability to choose to receive their key reports via e-mail, whether they are in the office, at home, or away.
Setting up to send e-mail
Set up is straightforward. You can use it for a wide range of applications. Figure Z shows an example of how to route your Model 204 output to e-mail. All our production Onlines are running Model 204 V4.2 under OS/390 V2.10.
Now you can send the output from your Model 204 procedure directly to the e-mail accounts you specified.
This type of format is fine for fairly simple statements or lists, such as:
Adding attachments
You might want to e-mail more information, for example, revenue or utilization details. You can send the messages the same way, but add an attachment in formats such as PDF, RTF, or HTML. Commercial products, such as JES2Mail from Data21, enable you to choose a format. It is no more complex than the simple e-mail report.
Easy-mail
E-mail direct from Model 204 opens up a whole range of possibilities for enhancing your Model 204 applications, with relatively little effort. In particular, you can produce results automatically from your Model 204 application, and deliver them directly to the desktop of users who never even have to log on to Model 204 - all they have to do is to read their e-mail!
System 1032 Query Efficiency: Part 1
By Kevin Fuller Updated by: Tym Stegner
Query Efficiency: Part 1 begins a series of articles describing how to formulate efficient queries by understanding how the FIND command, other query commands, and System 1032 key tables work. Query Efficiency was originally a presentation for the System 1032 User's Conference in 1992. We divided it into a series of articles for CCAPRINT in response to a customer inquiry.
This series covers the following topics:
Key table internals
A key table is a data structure that enhances the fast location of records. System 1032 key tables are an index to your dataset, much the same as a book index is to the pages of that book or a card catalog is to a library.
System 1032 key tables are specifically designed to optimize query speed, especially when dealing with millions of records. This performance is the result of a modified B-tree index structure. Although System 1032 key tables follow most of the basic rules of a B-tree data structure, they stray when efficiency considerations make it practical.
Key table size and block levels
System 1032 key tables are built with at least two levels in the B-tree structure: one high-level key block and one low -level key block. To display the number of blocks a key table uses and the number of levels necessary to build it, you can turn on key messages when you create the dataset. Include the statement in your CREATE DATASET command:
KEY_DEFAULTS ALL_KEYED MESSAGE
When the keys are initially built, System 1032 displays information about the size and structure of the key tables. Figure 1 shows the output from a 10,000 record demographics dataset, which has keyed a unique Social Security number, last name, age, and gender.
Figure 1. Key table messages, displayed when a dataset is loaded
Writing SSN keys 10,000 values, 3 levels 325 LLK blocks, 339 total blocks
Writing LAST_NAME keys 64 values, 3 levels 34 LLK blocks, 39 total blocks
Writing AGE keys 50 values, 2 levels 31 LLK blocks, 34 total blocks
Writing GENDER keys 2 values, 2 levels 6 LLK blocks, 9 total blocks
Key table blocks
The number of blocks required to build a key tables varies depending on the number of unique values to be indexed. The GENDER key tracks only two values; the entire key table uses only nine blocks of disk space. However, the SSN key tracks 10,000 different values, requiring 339 blocks. Estimating the size of a key table is nearly impossible.
Key table levels
The other piece of information shown in Figure 1 is the number of levels in the key table. Notice that an attribute with only 64 values, LAST_NAME, using only 39 total blocks, required three levels. The SSN attribute, which takes 10 times the disk space, still requires only three levels. The B-tree structure can make a very wide, but very short tree. Datasets with millions of records still require only five or six levels. A query in this key table can reach the leaf nodes of the tree using very little I/O.
Lower-level key blocks
The base of the tree (this tree spreads downwards) are the lower-level key blocks. These blocks hold the actual index information. The blocks contain each unique value within your dataset for that attribute, and also a corresponding record list, which is compressed for efficient storage. These compressed record lists track by $ID the records that contain the associated value. The values themselves can be anywhere from one byte to 80 bytes in length, depending on data type. The compressed record lists have no size boundaries. For very large datasets, record lists can be several disk blocks long. However, with compression, it is possible for a record list within a dataset of 1,000,000-plus records to be only a few bytes long.
As shown in Figure 2, the lower-level blocks are linked together and read across without moving back up and down the levels of the tree.
Figure 2. Lower-level key blocks linked forward
Examining a lower-level key block
At the beginning of each lower-level block is a 4-byte longword, which points to the next block. The second longword is a series of flags used by System 1032, which are not relevant to this discussion. The rest of the block is filled with value/record-list pairs. The values run in ascending order - sorted at the time the keys are built. The values for each key are a single fixed-length. The length of the record lists depends on uniqueness and distribution. Figure 3 shows the lower-level key structure. Figure 4 shows the structure for the LAST_NAME attribute.
Figure 3. Lower-level key block internals
As you can see, the first two sections of the block are used for structural purposes. Each value section is the same size; however, the record lists range from very small (Record List 2) to much larger (Record List 3).
Figure 4. Lower-level key block for LAST_NAME
In Figure 4, the names are stored in uppercase, which is the default storage for all text attributes. If you choose to KEY USE_CASE, then the values are stored in the key tables in mixed case. The shorter names (BELL) leave blank space, where the longer ones (ABBOTT) fill the allotted space. This diagram implies that LAST_NAME is a TEXT 6 attribute.
The compressed records lists are exactly as long as they need to be to hold the required data. Compressed record lists do not actually store a string of numbers as shown in Figure 4. Instead record lists are stored in one of three different compression formats.
Think of the record list as a compressed bitmap of the dataset, which contains one bit per dataset record. The bit positions that correspond to a record with the associated value are set to one; all other bits are set to zero. When this bitmap is read and decompressed during a query, your selection set is formed, and the records are represented in what is called a compressed bit vector. This bitmap design makes it very fast and very easy to combine compressed record lists in logical AND, OR, XOR, and other operations.
Higher-level key blocks
The levels above the lower-level key blocks are called higher-level key blocks. Their sole purpose is to point to the next lower-level key blocks. There are only as many levels of higher-level key blocks as needed to form the tree structure that comes to a single point at the top.
Each higher-level key block keeps information about the starting value of each block in the level below that it points to. It also tracks whether the block starts with a new value or with the continuation of a record list. By knowing where each block starts, the tree can be navigated taking the shortest path possible through the block(s).
Key entry points
Figure 5 illustrates the two special key blocks. The first is the top of the tree, called the top higher-level key. The other is the first lower-level block at the left-most end of the lower-level blocks, called the first lower-level key. These are the two entry points for reading key tables, which we return to in later articles.
Figure 5. Top-higher-level and first lower-level key
Coming attraction
We have completed Part 1, which presents the concepts and the structure of System 1032 key tables. In Part 2 we will discuss how System 1032 resolves queries using key tables and the design of the query command.
Copyright © 2003 Computer Corporation of America. All right reserved. Published in the United States of America.
500 Old Connecticut Path, Framingham, MA 01701 Contact CCA Webmaster Copyright 2005
