HP3000-L Archives

May 2009, Week 1

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:
"Walter J. Murray" <[log in to unmask]>
Reply To:
Walter J. Murray
Date:
Sun, 3 May 2009 13:29:57 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (68 lines)
Greetings,

Thanks to those who responded to my query about why DBERROR (and
DBEXPLAIN) sometimes report "UNRECOGNIZED RETURN STATUS: 41" instead of
"DBUPDATE ATTEMPTED TO MODIFY VALUE OF CRITICAL ITEM--KEY, SEARCH OR
SORT", when a program attempts to use DBUPDATE to change the value of a
critical item without having enabled the CIUPDATE option.

Stan Sieler figured out the problem, a previously undocumented bug in
DBUPDATE.  The problem occurs only when the record number of the record
in question is greater than or equal to 2^16, that is, 65536.  That
explains why I was unable to duplicate it in a small database.

For those who want the details, here's a short paraphrase of what Stan
discovered.  When DBUPDATE fails on an attempt to update a critical
item, it sets the first halfword of the status array to 41.  (This is
working as it should.)  In addition, DBUPDATE is supposed to store a
secondary error code in the third halfword of the status array, giving
additional information about the details of the failure.  In my test
program, that value should have been zero.

However, DBUPDATE apparently sets the third and fourth halfwords of the
status array to the current record number.  As long as the current
record number is less than 2^16, the high-order 16 bits are zero, and
there's no problem.  But with a higher record number, the third
half-word of the status array is set to a bogus value.

DBERROR relies on this value.  The bogus value causes DBERROR to fail to
recognize the error.

Walter  

-----Original Message-----
From: Walter J. Murray [mailto:[log in to unmask]] 
Sent: Wednesday, April 22, 2009 9:44 PM
Subject: TurboIMAGE UNRECOGNIZED RETURN STATUS error

Greetings,

Has anyone seen this problem in TurboIMAGE?

I have a database where CIUPDATE is set to ALLOWED (not ON).  I have a
program that calls DBUPDATE and inadvertently tries to change the value
of a critical item.  (Don't tell me I can't do that.  I know it's an
error.)  IMAGE correctly returns a status value of 41.  The problem
occurs when the program calls DBERROR to retrieve the error message.  It
ought to return the  message "DBUPDATE ATTEMPTED TO MODIFY VALUE OF
CRITICAL ITEM--KEY, SEARCH OR SORT".  Instead, it returns "UNRECOGNIZED
RETURN STATUS: 41".  DBEXPLAIN has the same problem.

The detail data set in question has approximately 112,000 entries.  I
haven't been able to duplicate the problem with a small database.

The problem isn't in my program.  I see the same problem using QUERY
against this database.  There shouldn't be anything wrong with the
structure of the database.  I built a fresh copy of it and loaded it
with data.  No unsupported or third-party tools have been used to access
it or make any structural changes to it.

I called the Response Center.  This is not a known problem.

Walter  

Walter J. Murray

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

ATOM RSS1 RSS2