Re:

> It's this small difference of putting the filename into the directory at the
> beginning of the file open process, prior to the actual file copy, and
> putting it there at the close of the process that makes all of the difference
> between a polling process being "virtually impossible" to screw up (if all of
> the necessary precautions are taken) and one that is flat-out impossible to
> screw up.

Yep...that's why I'm surprised that COPY does it the "insert immediately"
way.

There are good reasons for having both methods.  In some cases, one wants
to get the disk file inserted in the directory at the start because:

  - you find out at FOPEN time if the file name is available for use

  - if the application aborts before the final FCLOSE (, 1), you've
    may have some useful data in the file.

OTOH, one wants the original MPE semantics (file name not inserted into
directory) because:

  - if you see it, you can use it

  - no partial file data

> Nonetheless, Ken Hirsch's RENAME is answer -- and the gold standard. By the
> time that the RENAME command would have been issued by a job, the source file
> would have been built, fully populated and completely stable. Moving the

yep.

> state variable indicator of the presence of the file. Using Ken's method,
> there can never be problems associated with polling simply because there is
> no window of vulnerability, no matter how small it might be.

Not true (the "can never be problems" part).

Polling has three intrinsic problems:

  1) knowing if the file is "ready"
     ... however, the insert-into-directory-at-end solves this problem.

     (BTW, DOS and Windows seem to insert the file into the
     directory at file-open time, although the EOF doesn't seem to
     get updated until file close time)

  2) performance: response time

     If the polling is not extremely frequent, there's a time gap
     between the file being ready and the file being noticed.

  3) performance: CPU waste

     If the polling is extremely frequent, a lot of CPU is wasted
     by the polling.

One simply cannot escape the second two problems.  (I.e., one
can minimize one at the cost of the other, but one cannot
eliminate both problems.)  That's why a notification mechanism
is greatly to be desired.  Trust me...that's an OS designer speaking here :)

--
Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html                  www.sieler.com

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