| Newsgroups |
gmane.comp.emulators.hercules390.general |
| Message-ID |
<[email protected]> |
---In [email protected], <gerhardp@...> wrote :
>> No application with a "quit" command
>> should be producing non-deterministic
>> results. None. At all. Not even applications
>> that start with the letter "H".
> When MVS issues an I/O, Hercules fields it, but some I/Os don't have
> normal completion (e.g. outstanding 0A on a TP line), so Hercules can't
> know when it's safe to close the thread.
When "quit" is entered, it's time to close
the thread for sure.
> On top of which Windows has an asynchronous write mode, so even if
> Hercules flushes the buffers, there is no assurance that a disk write
> completed.
It is beyond Hercules's responsibility to
care about Windows buffering. So long
as Hercules correctly does an fclose(),
it's job is done. It's not a Windows bug.
> In any case you should fix the shutdown commands to ensure all tasks are
> complete, prior to issuing the P JES2,TERM / Z EOD / QUIESCE commands.
> The QUIT after that should be clean. To make the JES2 shutdown easier,
> ensure that all pseudo-devices default to DRAINED so you won't have any
> funny hangs.
If MVS isn't shut down cleanly, then any data
that MVS may have been buffering may be lost.
I don't have a problem with "quit" causing an
interrupted MVS task leaving disks in a bad
state.
What I have a problem with is Hercules not
having the intended verbiage of disk files
being closed present in the log file. Hercules
is responsible for issuing an fclose() for
every file (MVS disk) it has open, and is
designed to output some verbiage to the
log file to indicate that. It is not designed
to only randomly do that.
BFN. Paul.