If you are accessing code tables for validating data, editing data, translating values, or populating drop-down boxes, locally cache the code tables for better performance. This practice is relevant for any code tables that rarely change.
For example, a batch COBOL job reads your code tables into in-core tables. For larger code tables, employ a binary or quick search algorithm to quickly look up values. For CICS applications, set up the code in VSAM files, and use them as CICS data tables. This practice is much faster than using DB2 to look up the value for every CICS transaction. The VSAM files can be refreshed on regular intervals using a batch process or on an as-needed basis. If you are using a remote application or Windows-based clients, read the code tables once when the application starts and cache the values locally to populate various on-screen fields or to validate the data input on a screen.
For object- or service-oriented applications, check if an object has already been read in before reading it again. This practice helps you avoid constantly rereading the data every time a method is invoked to retrieve the data. If you are concerned that an object is not fresh and that you may be updating old data, employ a concept called optimistic locking. With optimistic locking, you do not have to constantly reread the object (the table or query to support the object). Instead, you read it once, and when you go to update the object, you can check the update timestamp to see if someone else has updated the object before you.
|
Copyright © 2013 CA Technologies.
All rights reserved.
|
|