Stan after Craig gives us some of the "inside story":

> > That's pretty close to what's going on. In order to enforce
> > the proper security for the file open, we need to know what the
> > group and account file access matrices are. These are ANDed
> > with the file access matrix to get the default MPE security for a
> > file. This needs to be done so that opening a .....
> ..
>
> It would be nice to have an option, which would require PM, that
> would say "hey...do it fast, bypass security".  Then, trusted
> subsystems could use open-by-UFID when appropriate.

hmmm.....   Including IMAGE, I gather (perhaps "assume" is a
more appropriate word) ??..   If the IMAGE intrinsics are also
paying the price for NOT "bypassing security", that would be one
place where it seems like just about everybody would benefit...


SIDEBAR:  Jumping the gun a little, but:  A somewhat related
subject (related in the sense of improving performance for file
opens):  In the '01 Interex System Improvement Ballot (SIB) that is
*just about* ready to be opened up to the world for voting, SIGCSY
has an item they proposed that made the cut for the "final 25":

"Increase DBOPEN Concurrency in TurboIMAGE."    This item
proposes to deal with the issue where every DBOPEN locks the
IMAGESIR (1 per system) almost at the beginning of the intrinsic;
and releases it only at end of the intrinsic;  causing DBOPEN to be
serialized even if users open different databases. This can cause
significant delays to log on if many users start apps at the same
time. Benchmarks show it can take half an hour to start 900 users.

Since file opens are "expensive", if IMAGE could indeed benefit
by "bypassing file security" in this way, that would be a "good
thing".....


In fact we now have several good "better performance / avoid limits"
enhancements dealing with file open still on the table.  Example:
Stan's idea a couple years ago for:

Global file FOPEN (system-wide "handle"):  Better performance
plus avoid one-process max # of open files limit (some sites are
already at limit).  IMAGE & other PM could access via intrinsics.

Last above didn't make the cut for the SIB this year, but we will
certainly keep it on the SIGImage/SQL TurboIMAGE ballot again
for next year....

Ken Sletten