Tracy wrote back directly:

> sounds to me like you're on track.  Are you really checking 
> for status-word 0 = zero before calling DBEXPLAIN?

As near as possible, yes -- as I mentioned, the IMAGE intrinsics are wrapped up in a "neat, tidy XL routine" that does "some" error checking, but in general the actual IMAGE STATUS array is passed back verbatim from the call.

>  I'd bet your STATUS word's getting stomped by something - maybe a clever
> buffer overrun? 

well, you called it [got stomped on], but it wasn't a "clever buffer overrun", rather it was explicit [dumb] coding [did I mention the intrinsics were wrapped in a "neat tidy XL routine that does some marginal error checking"?]

 S06-100.
     CALL "DBFIND" USING BASE, DBSET, DB-MOD1, DB-STAT,
         DBKEY, DB-ITEM.
     IF DB-OK = ZEROES AND DB-NR NOT > ZEROES
         MOVE 1 TO DB-OK.

note: DB-OK === DB-STAT  [i.e., db-ok == first word of image status array]

In other words, the dbfind failed, so the "zero" result was mangled to be a non-zero value, and the subsequent "dbget" wasn't called [I trimmed a "goback" statement from the above copy]

> i bet you're gonna kick yourself when you find your bug.

kick myself, no... [but wish I could find the programmer that wrote this in the first place...]

Actually, there is another "generic" routine in the mix that is just making things more difficult -- it is this second routine that simply sees that "status not equal zero, danger wil robinson! abort now or forever hold your peace..." and dies an unsightly death rather than "knowing" that in this instance, a return value of "1" is a legitimate value [the data being sought doesn't really exist, but there might be an auto master for this item because it is used in other datasets...]

All in all, thanks for confirming I wasn't going bonkers and "missed" some interesting new status result :)

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