Subject: | |
From: | |
Reply To: | |
Date: | Wed, 2 Dec 1998 07:52:46 -0700 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Doug Werth writes:
>[Leonard Berkowitz writes:]
>>As a consultant, I saw one application (not where I am consulting now, I
>hasten to
>>add!) where list processing was used, but the list of items consisted of
>every item
>>in each data set. The combination of the worst of item lists and '@', eh?
>
>
>I respectfully disagree. I don't think this is the worst of both worlds. It
>may not be THE best, but consider this. If the fully defined item list is
>kept in a copylib and updated when new items are added to the database, then
>any new program development will immediately have then entire dataset
>available to it. Older programs will still continue to function without
>recompile.
Older programs will not continue to function without recompile unless
special precautions are taken. The @ list reads the entire image record,
and assumes that there's space to do it. Unless you originally allocated
4096-byte buffers for all IMAGE records (and this IMAGE limit is never
increased), or unless your program checks the IMAGE record length and
dynamically allocates buffer space, the newly-added fields will overlay
some previously-untouched part of the program's data areas. This is
likely to result in anomalous calculation results or program aborts.
>paring down
>the item list does not have enough measurable performance impact to outweigh
>the derived benefits to maintenance and development.
Again, the benefits to using a named item list are precisely those of
decreased maintenance and shorter development times. Programs that read
exactly what they need are immune to changes to items they don't need. In
the absence of careful documentation -- or when verifying documentation
-- the only way to determine which fields are used by a program employing
@-list reads is careful inspection of the entire program source. A
program that accesses only named items can't possibly touch unnamed
items, so its interaction with a given database can be ascertained simply
by inspecting list variables -- or at worst, IMAGE calls.
-- Bruce
--------------------------------------------------------------------------
Bruce Toback Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc. (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142 | But ah, my foes, and oh, my friends -
Phoenix AZ 85028 | It gives a lovely light.
btoback AT optc.com | -- Edna St. Vincent Millay
Mail sent to [log in to unmask] will be inspected for a
fee of US$250. Mailing to said address constitutes agreement to
pay, including collection costs.
|
|
|