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:
"Dave Powell, MMfab" <[log in to unmask]>
Reply To:
Dave Powell, MMfab
Date:
Tue, 23 Nov 2004 11:23:06 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (77 lines)
In the early eighties what I 'learned' was that '@;' and '*;' were the same
speed, or as close as made no difference, but that a full item list was MUCH
slower.  I did a little un-scientific testing about 24 years ago and confirmed
that as close as I could tell.  But a full list makes adding items at the end
of a data set MUCH easier.  So we use the full list for the 1st call on each
data set, and '*;' after that.

There's no extra work for the application programmer because flags in our
image call routines take care of it.

When we add an item to a data set we re-compile only the programs that need to
pay attention to that item, typically only one that adds entries to that set,
one or two that modify it, and just one or two out of many that read it.  We
don't have many of the maintenance concerns voiced by others because every
data set is defined just once, in one copylib (ok, when there is a new test
data base there will also be a test copylib with the matching changes, and the
same job that converts the live data base will convert the copylib and
re-compile whatever programs need it).  All programs that touch a data set
read every item, except for pgms that didn't need to worry about a new item
and haven't been re-compiled yet, so the effect is a lot like '@;' except
fewer urgent recompiles.


----- Original Message -----
From: "Walter Murray" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Monday, November 22, 2004 21:17
Subject: spam: [HP3000-L] Using the "@" list in TurboIMAGE


> [My apologies if this is a duplicate for some readers.  I had trouble last
> week with some of my postings not making the jump through the gateway to
> 3000-L.]
>
> When I learned IMAGE yea many years ago, I got the notion that the right way
> to call DBGET and related procedures was with an explicit list parameter
> specifying the particular items of interest.  If I was concerned with the
> overhead of processing such a list, I could establish a "current list",
> typically by doing a directed read to record 0 (which I knew would return
> condition 12) and using "*;" in subsequent calls.  The theory was that, if
> there were structural changes to the database, such as new items added to
> the dataset, it would not be necessary to change and recompile any programs
> that did not use the new items.
>
> In practice, however, it seems as though everybody just uses "@;" all the
> time.  The buffer layout gets put into a COPY library.  If items are added
> or modified, you have to track down every program that uses that dataset
> and, at a minimum, recompile it.  If you miss one, mysterious things happen,
> as when the program's buffer becomes too short for the newly enlarged
> dataset layout.
>
> 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?
>
> Thanks.
>
> Walter
>
>
>
>
> ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet
News==----
> http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000
Newsgroups
> ---= East/West-Coast Server Farms - Total Privacy via Encryption =---
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

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

ATOM RSS1 RSS2