Re: Re: quit files

Hello!
Speaking as a disinterested observer, I definitely agree with Tony
there. In fact judging from the abundance of system still running
applications for our banking and other financial transactions that got
started on MVS originally, you are decidedly right.

Besides Paul the problems you're having have a logical reason. And if
I said what they were you'd be more annoyed at me, then at the rest of
the group. And it has nothing at all to do with those improvements you
came up with.

However, I am inviting all of you to continue this discussion next
door on the H390-MVS list.
-----
Gregg C Levine [email protected]
"This signature fought the Time Wars, time and again."


On Fri, Jun 21, 2019 at 7:57 PM Tony Harminc [email protected]
[hercules-390] <[email protected]> wrote:
>
>
>
> 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.
>
>
> 
> ________________________________
> Posted by: Tony Harminc <[email protected]>
> ________________________________

And this message is sponsored by the Astromech droid union of the
Rebel Alliance.