RE: Re: quit files

Folks,
Looking at the documentation for 3.07 it says:-

>The EXIT command (see also the QUIT command) initiates the Hercules shutdown. It terminates all
>threads, detaches all channels and devices and releases the configuration. Finally it terminates the
>emulator.

So its not equivalent to hitting the power switch, it attempts to do an orderly shutdown.
This is necessary to ensure the integrity of DASD files. 
So if you try detaching devices without first quiescing MVS you deserve everything you get.

Dave

> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: 22 June 2019 01:06
> To: hercules-390 hercules <[email protected]>
> Subject: Re: [hercules-390] 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.
> 
> 
> ------------------------------------
> Posted by: Gregg Levine <[email protected]>
> ------------------------------------
> 
> Community email addresses:
>   Post message: [email protected]
>   Subscribe:    [email protected]
>   Unsubscribe:  [email protected]
>   List owner:   [email protected]
> 
> Files and archives at:
>   http://groups.yahoo.com/group/hercules-390
> 
> Get the latest version of Hercules from:
>   http://www.hercules-390.org
> 
> 
> ------------------------------------
> 
> Yahoo Groups Links
> 
> 
>