HP3000-L Archives

November 2004, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Tue, 23 Nov 2004 00:32:51 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (34 lines)
Walter Murray wrote:

>Am I correct in my belief, based on admittedly limited observation, that
>practically everybody always uses an "@;" list?  If so, is there any good
>reason for this?  Is "@;" faster than "*;"?  If so, why?  And is it enough
>faster to justify the risk and inconvenience of having to recompile many
>programs whenever a minor structural database change is made?  Or am I
>missing something more significant?
>
We do both in combination.

Our program initialization, along with opening the database in the first
place, will call DBINFO for each dataset it is going to use, supplying
the name and saving the binary numeric value returned for the dataset
number.  It then calls DBINFO for each search item it is going to use,
supplying the name and saving the binary numeric value returned for the
data item number.  And finally it does a DBGET mode 4 to record 0 as you
describe, using "@;" as the item list, for each dataset to be
referenced.  Finally, the item list is replaced with "*;".

So we were fine up until the DBGET.  Sure wish we had specified the
initial item list by names instead, then we would have had some immunity
from structural changes.

At least in the "old days" using the binary set and item numbers,
combined with the "*;" item list was supposed to be the most efficient,
particularly the item list (although clearly "@;" is more efficient than
a long string of item names when used over and over again).

Jeff

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2