• Model 204 - A Surfeit of Checkpoint Records
• Model 204 - $CODE and $DECODE - An Overlooked, Underutilized Gem

Model 204

A Surfeit of Checkpoint Records

By Donna Goodwin

A CCA customer asks

I'm changing a field from non-key to ORDERED. The file has 12 million records; there are 175,000 pages in Table D. How could this be producing 600,000 checkpoint records in the CHKPOINT dataset?

All I want Model 204 to do is scan through all the records in Table B - the data and build indexes for all the values of the field in Table D - the index.

Checkpoint records are preimages - copies of pages before changes have been applied and are used to perform rollback recovery. How could that many pages have changed?

Recalling basic file management

Model 204 is generating a preimage of every Table B page that has a value for the field because the field's overhead bytes are changing.

If you remember from your basic File Manager class, you need overhead for every non-preallocated field. If the field is defined as:

• CODED, FLOAT, or BINARY, two bytes are needed.
• STRING of indeterminate length, three bytes are needed. The extra byte contains the field length of the string. You don't need an extra byte for CODED and BINARY, which are always length 4, or FLOAT, which is always length 4, 8, or 16.

Defining a field with default attributes

To see an overhead change occur, open a file and define a field, as shown in Figure 1:

OPEN FILEABC
DEFINE FIELD SAMPLE

Figure 1: Defining a field

Store a record with the new field:

BEGIN

STORE RECORD

SAMPLE='THIS IS MY SAMPLE FIELD'

END STORE

END

Now let's look at the record you just stored. You can see the value of the field, which in this case is, THIS IS MY SAMPLE FIELD, is 23 bytes. Remember, this field is defined with only default field attributes: STRING and it is not indexed. Figure 2 accounts for the overhead.

Overhead information	Current Values	Bytes used
Field value	This is my sample field	23
Field length	23	1
Field type and field name code	STRING; field code	2

Figure 2: Overhead information stored for the SAMPLE field with default attributes

The field type, STRING, and field name code, which identifies a particular field, take two bytes of overhead. In our example the SAMPLE field name, defined in Figure 1, is represented internally by a field name code.

Model 204 field types

The following field types are currently represented in Model 204:

• CODED or BINARY
• STRING
• 4 byte floating point
• 8 byte floating point
• 16 byte floating point
• INDEXED

Redefining a field with specified attributes

Now redefine the SAMPLE field with the ORDERED attribute:

REDEFINE FIELD SAMPLE (ORD CHAR)

Figure 3 illustrates what changed in the overhead information for the SAMPLE field, although the total bytes needed remained the same.

Overhead information	Current values	Bytes used
Field value	This is my sample field	23
Field length	23	1
Field type and field name code	STRING, INDEXED; field code	2

Figure 3: Overhead information stored for redefined attributes

The REDEFINE process updated field type to STRING and INDEXED, which will add a 6184-byte Table B preimage record to the CHKPOINT dataset for each Table B page touched by the REDEFINE command.

The importance of field type

The field type explains how the value of the field is stored: as a string, a coded value, a binary value, or a floating point number.

The indexed indicator, such as ORDERED or KEY, is necessary because of the DELETE RECORD statement. For example:

FOR RECORD NUMBER 27

DELETE RECORD

END FOR

When the record is deleted, the field code indicates whether or not to change the index as well as the data proper.

Recommendation

The best way to redefine a field and eliminate excessive checkpoint records is to do it in batch. Dump the file, turn off all recovery options (you can eliminate the journal and checkpoint files) and execute the REDEFINE process. In the event the Batch job fails (for example, Table D isn't large enough), restore the file, increase Table D and try again. When the job has completed enable all recovery options for the file or job.

Conclusion

If you have very large files, consider that the REDEFINE FIELD command may produce more checkpoint records than you anticipated. "How many more?" you ask.

Probably about as many pages as you have in use in Table B; check the value of BHIGHPG for the file where you want to redefine the field. You might want to run the REDEFINE process in batch to serialize the updates.

Model 204

$CODE and $DECODE - An Overlooked, Underutilized Gem

By James Damon

A table lookup or data translation is required by many applications. For example, a code value, such as a 3-byte telephone area code, is stored as a data element in one or more files, but many applications need to print the city associated with that area code. Or, vice-versa - given a city name, what is the area code? The pair of User Language $functions, $CODE and $DECODE, provides an easy, flexible, and extremely efficient way to implement this kind of functionality without changing existing files or field definitions.

Model 204 Code tables

The following two small tables, DAY for day-of-week and STATES for USA states are distributed and linked into all versions of Model 204.

CODETABL DAY,1 DAYS OF THE WEEK

CODE 1,'MONDAY'

CODE 2,'TUESDAY'

CODE 3,'WEDNESDAY'

CODE 4,'THURSDAY'

CODE 5,'FRIDAY'

CODE 6,'SATURDAY'

CODE 7,'SUNDAY'

ENDTAB

SPACE

CODETABL STATES,2 A starter code table

CODE AK,'ALASKA'

CODE VA,'VIRGINIA'

CODE MA,'MASSACHUSETTS'

ENDTAB

Anatomy of a Code table

A code table is comprised of the following Assembler macros:

Assembler macro	Purpose
CODETABL	Create the code table
CODE	Describe individual Code-Decode pairs
ENDTAB	End the Code table

You might want to complete the STATES table at your site by adding the remaining Code (state abbreviation code)-Decode (state name) pairs. Code table entries may be in any order; sorting by code is not required.

Accessing and adding Code tables

You can access Code tables with the following User Language procedure:

BEGIN

PRINT $DECODE('DAY','4')

PRINT $CODE('STATES','VIRGINIA')

END

THURSDAY

VA

You can change or add code tables at any time. You can add new entries, delete old entries, and update existing entries. Once you update your applications to use $CODE and $DECODE, you need not change your applications again when you change the code tables.

Adding a Code table of area codes

The following Code table illustrates part of a partially complete table of area codes.

CODETABL ACODES,3 SOME AREA CODES

CODE 214,'DALLAS'

CODE 202,'WASHINGTON, DC'

CODE 415,'SAN FRANCISCO'

CODE 720,'DENVER/BOULDER'

CODE 617,'BOSTON'

CODE 617,'BROOKLINE'

CODE 508,'FRAMINGHAM'

CODE 702,'LAS VEGAS'

CODE 808,'HAWAII'

CODE 213,'LOS ANGELES'

ENDTAB

SPACE

Significance of using only unique values

You might find that Code tables are most useful and easier to use when each Code and each Decode value is unique. This is because a table search starts at the beginning of the table, continues until a match is found, then stops. Thus, in CODETABL ACODES, Boston and Brookline share the 617 area code. Compare the results of the following:

$CODE('ACODES','BOSTON')

$CODE('ACODES','BROOKLINE')

Both return 617. However,

$DECODE('ACODES','617')

returns only Boston, the first match for 617.

Building Code tables

Code tables are built by the Model 204 system manager in an assembly language Csect and linked into the ONLINE and BATCH204 load modules in a three step process:

1. Add or update code tables in member CDTB in M204.MACLIB.
2. Assemble member CDTB using job or member CDTBASM in INS204.JCLLIB.
3. Link the CDTB object module into the ONLINE and BATCH204 load modules, while preserving all previously applied maintenance. Use job or member M204RLNK in INS204.JCLLIB after you make the following edit to the linkage editor commands for CDTB to SYSIN:

INCLUDE OBJLIB(CDTB)

INCLUDE SYSLMOD(ONLINE) or (BATCH204)

ENTRY MAINTASK

NAME ONLINE(R) or BATCH204(R)

Table updates are available to all applications, both APSY and non-APSY, regardless of files required.

Do not confuse this feature with the field level attribute, CODED, which is implemented at the file or field level primarily as a data compression attribute. The CODED attribute is not a table lookup facility. Code tables are used by the $CODE and $DECODE functions, are independent of files and fields, and are accessible by any User Language application, even those with no open files.

Conclusion

Using Code tables an organization can adjust quickly to changing requirements without updating large amounts of data in associated database files. When a new area code is added to the telephone system, a single change in a single table accommodates the new area-code values being stored in any Model 204 file anywhere in the enterprise.

• Further documentation on the CDTB module is in the Model 204 System Manager's Guide, Chapter 24: Customizing Functions and Translation Tables.
• Additional documentation for $CODE and $DECODE is in the Model 204 User Language Manual, Chapter 27: User Language Functions.

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

Home DownloadsownFeedback

Contact CCA Webmaster
Copyright 2008