Re: Re: quit files

On Fri, 21 Jun 2019 at 16:21, [email protected] wrote:

Everything you are describing below isn't regular MVS usage. Shutting the
> system down before powering off the mainframe was always common sense and
> is so even with today's latest z/VM and z/OS systems.
>
> Subsecond termination? Well, fine. But you are on your own with this. I'll
> never "support" such a thing, it is simply not supportable, because MVS
> isn't designed for such usage. Power on - IPL - run one job - pull the
> system's power plug, and so on. Incredibly unMVSish.
>

I think it's important not to lose sight of (what I see as) the problem
here. I have little interest in what version of Hercules or MVS Paul is
running, and what his scripting looks like. I have a lot of interest in
being confident that Hercules is architecturally correct.

Hercules, like VM, has console commands that correspond to architected
operator facilities on the real hardware. Some of those facilities (and
their matching commands in any emulator) are part of the architecture;
others are not. In particular, the various resets are architected, but
Power Off is not. If I understand correctly, the Hercules quit command
combines a System Reset with a Power Off. To that extent, it must perform
the System Reset in accordance with the architecture. If there are
under-the-covers things going on, most obviously emulated disk cacheing,
then those must be done in a safe and transparent manner. This has nothing
to do with how one normally runs MVS or any other guest OS. (If I am
mistaken, and "quit" is a pure unarchitected Power Off, then indeed all
bets are off.)

Obviously if an MVS application, or even an OS component (though I'm not
sure there are any such), is doing write cacheing, then there is no
guaranty that things will be written out if a System Reset is performed
without shutting down the app properly first. But with stock MVS, including
JES2, there is never a case where any system component will be left in a
wrong or corrupted state as long as there is no write I/O operation active
at the time of Reset. This can be ensured simply by using the MVS QUIESCE
command, making sure MVS is in a disabled wait state, issuing the Hercules
Stop function, and then Hercules System Reset. As I said, my understanding
is that the latter two may well be included in Hercules "quit".

I may be mistaken, but it appears that Paul is complaining that Hercules
can have a race condition while shutting down. While this may be indirectly
provoked by the workload running on MVS, I think if he can demonstrate that
emulated DASD at the host (UNIX/Windows) level is not being closed
consistently (including writing out of any cached data) before Hercules
goes away, then this is a serious issue.

From its very beginning, MVS was designed to run forever, hardware
> stability and maintenance requirements permitting -- and today (now being
> called z/OS, operating on the most reliable hardware in existance on this
> planet) this is one of its major competive advantages. I will never support
> any other concept.
>
Nothing more to add from my side.
>

I don't disagree, but I do think treating the complaint seriously *if it
can be properly isolated and demonstrated* is important. As Paul says,
Hercules should be deterministic (and I will qualify that by saying "*must*
be deterministic when it comes to architected facilities").

Tony H.