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:
Paul Christidis <[log in to unmask]>
Reply To:
Date:
Tue, 23 Nov 2004 15:40:18 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (57 lines)
HP-3000 Systems Discussion <[log in to unmask]> wrote on 11/23/2004
09:33:27 AM:

> --- Walter Murray <[log in to unmask]> 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?

Actually "*;" IS faster than "@;".  One aspect of Image 'list processing'
is the determination of what access rights a specific user has on each
item that is being retrieved.  The usage of the "*;" construct directs
Image to use the previously specified list and thus by-pass this 'access
validation' step.  In today's machines the difference may be negligible
but it is there.  About three years ago we needed to reformat the data on
a somewhat large dataset (over 30 million records with 5 or 6 keys) in
order comply with some organizational changes.  During our planning phase
we concluded that we would have to delay access to the users, on Monday
morning, by about 2 hours in order to complete the task.  After some
testing using about 2 million records, we changed the list construct to
"*;" (after an initial DBGET to record 0) and were able to complete the
task 30 minutes before the first user tried to access the system (we
'saved' 2.5 hours).

>
> way back when....yes, we used "@;" and "*;".  we had wee bit of logic
> that determined if this was the 1st call or not to that particular
> dataset or not and adjusted the list accordingly.
>
> > 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?

While I prefer the approach of re-compiling the entire system when a
database change is performed, I can see how that may not work for
everyone.  In some of our systems we had developed job streams that would
re-compile each 'subsystem' and a 'master' job stream that would submit
each 'subsystem job'.  Also the ability of using HFS utilities to 'slide'
in the new version of the application helped with the 'user' aspect of new
releases.

I think that the only place where an 'explicit' item list makes sense, is
when your application deals with a 'foreign' database (a database residing
in another account or under someone else's jurisdiction) where you don't
have complete structure control or where you may not be notified about
database changes.

Regards
Paul Christidis


<<snip>>

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

ATOM RSS1 RSS2