In message <[log in to unmask]>, Eddie 
Hopper <[log in to unmask]> writing at 12:51:34 in his/her local time 
opines:-
>Thanks for checking in on things, we still have an issues hidden 
>somewhere.  And to clarify, this particular database was not set to 
>read only, it was actually extraneous to the changes.  It is used as an 
>intermediary between external users and our production data.  A request 
>comes in and the requesting user information is written into this 
>database, then the pertinent unfo is used pull data back from the 
>production data and then transfer back to the requestor.

>So to the best of my knowledge, there were no direct changes to this 
>database/sets/passwords, nor to the user/group/account access or 
>capabilities.  So figuring out why the failure to open mode 1 is the 
>mystery.

>A brief update, Suprtool was used interactively and in a quick job, 
>usnig the same user.account and group.  No issues opening, writing a 
>record, then deleting the record.  The only caveat I have, the expected 
>password is truly used to open the DB.

>Maybe banging my head on the racks will jar something loose.
>eddie

Is this dataset a Master?

If so, another WAG is that something *has* changed, and that the attempt 
to write is being made only under the aegis of a record lock, when you 
need a set lock to DBPUT to a Master.

BTDTGTT (or at least, sat next to the person who cracked it).

Roy

-- 
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  William Morris

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