Re: Migrating ISAM to Relational Database
- From: "Joel C. Ewing" <jcREMOVEewing@xxxxxxxxxxxx>
- Date: Sat, 14 Apr 2007 15:29:38 GMT
Pete Dashwood wrote:
"Rick Smith" <ricksmith@xxxxxxx> wrote in message news:1320k5l1kvroc05@xxxxxxxxxxxxxxxxxxxxxLike so much in this business, it depends."Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
This has now been posted... Accessing the following link will reveal 3In 4.ISAM2RDB.doc,
documents that are worth reading if you are considering migrating ISAM to
Any or all feedback appreciated.
1. Page 3, Dealing with OCCURS (Repeating Groups),
items 1 and 3. You seem to disregard the space savings
that ODO and RECORD VARYING provide.
Yes, that's probably true, although I would have done so unconsciously.
My personal opinion (and it is ONLY that :-)) is that these constructs are just pointless and useless. Unless COBOL dynamically allocates space (and it doesn't) the only "saving" that is made with ODO is on external media. Internally, an ODO definitition always takes the maximum space that it could. The compiler has to allocate the maximum because it can't dynamically allocate space at run time.
I don't use this construct, and I discourage others from doing so too. A relational DB allows "tables" with "infinite" (limiited only by available disk space, and that gets cheaper every year) dimension, so the external saving is just unnecessary if you use RDB, anyway.
Never needed it; don't use it. :-)
RECORD VARYING... may have some marginal use and is certainly important when processing legacy files.
If ODO saves a significant amount of raw file space to store the data on external media this can have a number of beneficial effects that go much beyond the mere cost of your DASD media: (1)savings in processor time, I/O activity, media, and real time to backup the external data for Disaster Recovery; (2)savings in cost of disk media at a DR recovery site (which may be expensive or difficult to increase depending on your contract); (3)savings in processor time, I/O activity, and real time to reorganize or rebuild the database;(4)savings in processor time, I/O, and elapsed time to sequentially access a significant percent of the database, because more used bytes are transferred with each physical block read; (5)savings in the number of buffers required (affecting size of working set and real storage requirements) for caching the database in order to contain the same number of records in cache and get acceptable response time for random access.
If you are in an environment where you are never constrained by processor time, real memory, I/O response times, daily batch windows, DASD availability, or DR costs, then by all means ODO is irrelevant. In all other cases, one looks for the major resource hogs, or "loved ones" with poor response times, and do whatever it takes to address the problem, including use of ODO where appropriate.
We too have had COBOL programmers who hated to deal with variable length records. But, the marginal extra cost to manage variable length records within a COBOL program can easily be insignificant when compared with what is costs to pump unused bytes through the I/O subsystem over and over.
COBOL does not bother to dynamically allocate storage to ODO items at run time, because with virtual storage there is no significant savings in allocating COBOL ODO data items at anything less than the max required. Unused portions of a large array do not contribute to the working set of the program or the real storage required to execute. In the z/OS environment, real 4KiB pages wouldn't even be assigned to portions of a large array until the first reference required it. So long as you don't do something silly, like initializing the entire array in advance just in case you might need all of it, then the cost of unused portions is essentially zero in that environment.
Although it's probable your remarks on ODO were only intended to apply to record formats used in I/O, I want others reading this to be clear that there are other cases in COBOL where ODO is the only reasonable way to go. One case where ODO should ALWAYS be used is for a sorted data item array with a variable number of items that will be used repeatedly with a SEARCH ALL. Not only does proper setting of the "depending on" variable eliminate the need to initialize unused trailing items in the array, but it guarantees the resulting binary search uses the minimal number of compares for the search. For arrays whose max size is much greater than their average usage, failure to use ODO here can have a significant negative impact on performance.
Joel C. Ewing, Fort Smith, AR jREMOVEcCAPSewing@xxxxxxx