There was a problem with RoadRunner not releasing store bits on 6.0 thast
has been fixed since February of last year. I think the problem was related
to a conflict with SAMBA on 6.0 and perhaps that is why you are now seeing
the problem when you did not before with the network shut down.

The problem appeared random because the store bit was left set in the LAT
table and a new file could be created and appear to have its store bit
already set. I even had temporary files show up with the store bit set that
were created hours after the backup ran.

Peggy Lacy was the escalation engineer at HP that solved this problem,
perhaps Orbit should have a talk with her?

> -----Original Message-----
> From: Lane Rollins [mailto:[log in to unmask]]
> Sent: Friday, February 16, 2001 9:52 AM
> To: [log in to unmask]
> Subject: [HP3000-L] random store bits set
>
>
> The last few days I've had a problem with store bits being
> set on files.
> Twice on the GB file of the same database and  a couple files
> used by JMS.
> Has anybody seen a problem like this?
>
> The database one is the most curious. We used FSCHECK to
> purge the file and
> then within a half hour it was set again. With NO store
> operations of any
> kind. This database isn't heavily used, on normal days there
> are three jobs
> that work against it and an occasional program access ( <10
> time in a day ).
>
> The system in 979/100 running 6.0pp2+. I had made a few changes to the
> backup process. It would down all of the port and network
> before doing the
> store using orbit. Now it uses the allowall program from jazz
> to let the job
> set the limits down and runs the abortj command file that
> Jeff Vance wrote,
> leaving the network up.
>
> I can't believe that it's orbit because of no backup was
> running at the time
> of any of these problems and the fact that orbit does not
> store the GB file
> of an image database. The response center is pointing the
> finger at orbit.
>
> Any ideas would be appreciated.
>
> Thanks,
> Lane
>