Re: Re: quit files

Hi Toni 

 Thanks for commenting.
 

 When saying "Nothing more to add from my side", I really meant Paul's weird way to run MVS (i.e. one job per IPL). Of course I'm fully with you that reproducable race conditions upon shutdown must be analyzed and fixed, particularly when they prevent emulated DASD from flushing buffers and closing cleanly.
 

 However, my observation is, that the quit command _always_ waits until all device threads have terminated before it brings Hercules down. If there are any reasons for a device thread not to terminate gracefully, then the quit command will sit there forever, simply waiting.
 

 What we are seeing here from Paul -- quit bringing Hercules down with some device threads stll being active -- is _not_ the designed behaviour. What we are seeing here, however, is what happens when the Hercules user impatiently kills (ctrl-c, kill, kill -9, closing the terminal window, and the like)  the Hercules process, while it is still waiting for some device threads to come down -- instead of analysing what it is waiting for.
 

 The most common reasons for long waits upon Hercules termination are IP stack wait conditions (TIME_WAIT, and relatives). Hercules supports a lot of devices that interface to the user via IP connections (for example the console telnet server, socket printers, BSC lines, 3705, TWX and 2741 lines, CTC adapters). The TK4- standard configuration contains one or more instances of most of these devices. Thus TK4- in its standard configuration is somewhat depending on graceful handling of these devices. Shooting them out of the sky without prior warning isn't considered graceful handling in that context.
 

 People not using the system the way it is intended to be used, particularly those who don't accept conventions (like performing orderly shutdowns) but prefer rough handling (shoot first, think later, then complain about collateral damage) will not become happy with a fully configured TK4- system. And that's the reason why I yesterday recommended Paul, to read about parameterized configuration and particularly about the minimal configuration. I'm relatively sure this will circumvent his problem in a sense that he will no longer have to kill Hercules, thus getting his "verbiage" at the end of the shutdown sequence.
 

 Cheers
 Jürgen

---In [email protected], <tharminc@...> wrote :

 On Fri, 21 Jun 2019 at 16:21, winkelmann@... mailto:winkelmann@... 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 deterministicwhen it comes to architected facilities").

 


 Tony H.