HP3000-L Archives

November 1998, 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:
Larry Boyd <[log in to unmask]>
Reply To:
Date:
Mon, 23 Nov 1998 14:57:17 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (50 lines)
Bruce wrote:
> This has hit my clients as well, on several occasions. Isn't there a
> facility in TPI to intercept DBERROR and DBEXPLAIN? If not, can one be
> added? Most programmers go to the trouble of calling one or the other in
> order to speed up diagnosis of problems, but TPI errors just end up being
> completely opaque. The customer looks in the IMAGE manual (it's an IMAGE
> error, after all; it says so in the message), discovers that s/he's got
> an *undocumented* error, and panics.
>
> How about it, TPI vendors? Can we get real error messages through the
> documented DBERROR and DBEXPLAIN interfaces?

and Mike writes:
>In my dbupdate of the Tuboimage/XL FAQ I came across the DBTPIINFO
>intrinsic. Apparently it is currently for version information only. But it
>would work nicely as extensions if DBERROR and DBEXPLAIN could call it for
>*unknown* errors if TPI was enabled.

The DBERROR/EXPLAIN problem during DBOPEN is one that was found several
years ago.  Image calls the tpi product which then returns an error code of
+/- 3xxx.  Sometimes this error means there's a mismatch in versions or any
number of other problems.  Since this failure occurs during DBOPEN, Image
does not open the database.  So, when the application calls DBERROR/EXPLAIN,
there is no way for Image to know which TPI product to pass the error code
(the same error code can be used by both products).  There was some talk
about trying to solve this problem when I left Bradmark in 1995.  Jerry (or
DISC) might have some information on the status of this enhancement.  It may
seem like a simple change, but the information about which tpi product is
used isn't stored in the status array, and since the status array is
basically completely used, it was difficult to find a location to store the
product code.

The DBTPIINFO routine is used by Query (I think) when you use the VERSION
command.  Adding a call within the tpi product's DBERROR or DBEXPLAIN would
not be that difficult, but would change the standard display of these two
intrinsics.  DBERROR might not be a big problem, but the returned buffer
from DBEXPLAIN might be stored and saved in an application log file or some
place else.  If might cause a problem if returning more than 80 characters
(or whatever the length is today).  The routine (DBTPIINFO) is not a special
routine, and any application can call the routine.

I don't remember if this returns *all* current versions of tpi on the
system, or just for the open database.  Considering your dbdriver display,
it seems it returns all, which might not be the information requested.
There is another DBINFO mode that returns the current version for the
current tpi product for the currently open database (as I remember).  It
might be that this is what you're looking for.

lb

ATOM RSS1 RSS2