Discussion:
Implementing new Herc features?
(too old to reply)
Keven Tipping
2008-09-05 08:46:21 UTC
Permalink
Greetings to all.

I've been using Herc for a while now on a dedicated box. Works great.
I'd like to implement two features that I think Hercules /really/
needs, though I'm not really sure how/where said features should be
implemented.

1) Signal Handling

I'd like to add some sort of signal handling to Hercules so that I can
fire off signals at the process and have it *shut down gracefully* (as
in, running through the HHCxx9yyI messages). Basically, this would be
as simple as setting up the signal handling under Linux and launching
the equivalent to typing "exit" on the Hercules HMC when a signal is
received.

The reason for this being, is that when I'm running Hercules in the
background- start-stop-daemon can start Hercules as a system service,
but I've got to manually shut it down before start-stop-daemon
attempts to do so- otherwise Hercules simply dies and doesn't clean up.

Where would the code for this best go? In an additional module loaded
by the HDL? Or somewhere else?

2) Detachable UI

This is one that really kills me. At the moment, I'm running Hercules
under a screen session with multiuser support in the screenrc for my
system. It's a hack at best.

I'd like to implement a very simple telnet server for Hercules, with a
simple plaintext auth specified in the config file and an ACL for
acceptable host connections (usually just localhost- the idea being
that you can SSH into the machine running Hercules, then launch Telnet
locally to reconnect to the Herc HMC running in the background as a
service).

I'm well aware that Herc has the HTTP server and CGI stuff built-in,
however more times then not the only thing I have is an SSH line to my
Hercules box itself or another box in my network that I can tunnel
through. I also find that (no offense) the HTML/CGI interface is
somewhat kludgy to use at times and the auto-refresh thing isn't as
concise as a direct link to the Hercules cmdline via a terminal.

So once again- /where/ would this code be best fitted? As a module for
HDL, or as something else?

If anyone has any other relevant pointers or suggestions, they would
be highly welcomed.

Cheerio.
-KT
Martin T2..
2008-09-05 09:22:22 UTC
Permalink
Keven,

I try to answer how I handle your first reason for implementing a new
feature.
...and have it *shut down gracefully* ...<<
I do that from within the op-sys running under Herc. All you need is to
enable the DIAG8CMD interface (copied from VM-s implementation: you pass
a command-line to HERC and it reacts to it).

So to shut down with a signal from outside (which I do not do, only
gracefull shutdown after complete shutdown of the guest-system) I would
need a process that receives that signal from outside (i.e. via TCP/IP)
and then signlas to the hosting HERC to QUIT using DIAG 8.

Now: I can tell you what machine instructions are involved in that
interface, but not how to do it in a system other than VM, VSE or z/OS.
--
Martin
--
XML2PDF - the way to get all features of PDF into your documents
on mainframe or PC systems; more at http://www.pi-sysprog.de
peter_flass
2008-09-05 10:56:54 UTC
Permalink
Post by Martin T2..
So to shut down with a signal from outside (which I do not do, only
gracefull shutdown after complete shutdown of the guest-system) I would
need a process that receives that signal from outside (i.e. via TCP/IP)
and then signlas to the hosting HERC to QUIT using DIAG 8.
External interupt?
Martin T2..
2008-09-05 11:10:16 UTC
Permalink
Peter,
External interupt? <<
Herc sends a signal to the guests (via external interrupt- don't know which)

z/LINUX does react to a special signal for shutdown.

z/VSE 4.2 will have support for that as well

z/VM does it already (I do assume this because these kind of features
are usualy pretty fast implemented there)

z/OS no idea...my guess is not in the forseeable future. "Thou should
not have another operation system next to me" is the matra of most in z/OS.
--
Martin
--
XML2PDF - the way to get all features of PDF into your documents
on mainframe or PC systems; more at http://www.pi-sysprog.de
Mike Schwab
2008-09-05 10:22:39 UTC
Permalink
Shutting down: The proposed MVS/380 project has a job that does this.
Remote access: Not sure what you want. There are some RJE programs
out there that allow you to edit and submit jobs in 80 column mode,
then review printout in 132 column mode.
Post by Keven Tipping
Greetings to all.
I've been using Herc for a while now on a dedicated box. Works great.
I'd like to implement two features that I think Hercules /really/
needs, though I'm not really sure how/where said features should be
implemented.
1) Signal Handling
I'd like to add some sort of signal handling to Hercules so that I can
fire off signals at the process and have it *shut down gracefully* (as
in, running through the HHCxx9yyI messages). Basically, this would be
as simple as setting up the signal handling under Linux and launching
the equivalent to typing "exit" on the Hercules HMC when a signal is
received.
The reason for this being, is that when I'm running Hercules in the
background- start-stop-daemon can start Hercules as a system service,
but I've got to manually shut it down before start-stop-daemon
attempts to do so- otherwise Hercules simply dies and doesn't clean up.
Where would the code for this best go? In an additional module loaded
by the HDL? Or somewhere else?
2) Detachable UI
This is one that really kills me. At the moment, I'm running Hercules
under a screen session with multiuser support in the screenrc for my
system. It's a hack at best.
I'd like to implement a very simple telnet server for Hercules, with a
simple plaintext auth specified in the config file and an ACL for
acceptable host connections (usually just localhost- the idea being
that you can SSH into the machine running Hercules, then launch Telnet
locally to reconnect to the Herc HMC running in the background as a
service).
I'm well aware that Herc has the HTTP server and CGI stuff built-in,
however more times then not the only thing I have is an SSH line to my
Hercules box itself or another box in my network that I can tunnel
through. I also find that (no offense) the HTML/CGI interface is
somewhat kludgy to use at times and the auto-refresh thing isn't as
concise as a direct link to the Hercules cmdline via a terminal.
So once again- /where/ would this code be best fitted? As a module for
HDL, or as something else?
If anyone has any other relevant pointers or suggestions, they would
be highly welcomed.
Cheerio.
-KT
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA http://geocities.com/maschwab/ for
software links
Keven Tipping
2008-09-05 19:28:51 UTC
Permalink
I think the point of my original post was missed.

I don't really care about the OS running under Hercules. This has
nothing to do with the emulated system or any other mainframe OS.

This has everything to do with Hercules itself- as a process, running
under a Linux host. I apologize if I'm being unclear here or
something, because I've brought this up before and never got any real
answers.

As I said before- I want to enable Hercules so that it can run as a
INIT service on a dedicated Linux machine. That means Hercules is
started and stopped WITH the actual host computer itself.

In order to do this properly and not use the HTTP GUI, two things have
(had) to happen:

1) Hercules had to support signal handling from the Linux OS, so that
it can shut down cleanly when it receives a signal such as SIGTERM.
This has NOTHING to do with the emulated guest.

2) Run hercules as a daemon (hercules -d -f ./myconf.cnf) with a
detachable, re-attachable text-only user interface. I figured this
would be easiest to implement as a telnet server that only accepts
connections from localhost- so you can log into the dedicated
computer, and just run telnet to reconnect to the /background/
Hercules daemon.

Originally I had asked /how/ it would be best to implement these
features in the Hercules source. As a HDL module, as a separate
executable (aka Herclin), etc. I guess somewhere I confused everyone
or something...

-KT
Shutting down: The proposed MVS/380 project has a job that does this.
Remote access: Not sure what you want. There are some RJE programs
out there that allow you to edit and submit jobs in 80 column mode,
then review printout in 132 column mode.
Post by Keven Tipping
Greetings to all.
I've been using Herc for a while now on a dedicated box. Works
great.
Post by Keven Tipping
I'd like to implement two features that I think Hercules /really/
needs, though I'm not really sure how/where said features should be
implemented.
1) Signal Handling
I'd like to add some sort of signal handling to Hercules so that I
can
Post by Keven Tipping
fire off signals at the process and have it *shut down gracefully*
(as
Post by Keven Tipping
in, running through the HHCxx9yyI messages). Basically, this would
be
Post by Keven Tipping
as simple as setting up the signal handling under Linux and
launching
Post by Keven Tipping
the equivalent to typing "exit" on the Hercules HMC when a signal is
received.
The reason for this being, is that when I'm running Hercules in the
background- start-stop-daemon can start Hercules as a system
service,
Post by Keven Tipping
but I've got to manually shut it down before start-stop-daemon
attempts to do so- otherwise Hercules simply dies and doesn't
clean up.
Post by Keven Tipping
Where would the code for this best go? In an additional module
loaded
Post by Keven Tipping
by the HDL? Or somewhere else?
2) Detachable UI
This is one that really kills me. At the moment, I'm running
Hercules
Post by Keven Tipping
under a screen session with multiuser support in the screenrc for my
system. It's a hack at best.
I'd like to implement a very simple telnet server for Hercules,
with a
Post by Keven Tipping
simple plaintext auth specified in the config file and an ACL for
acceptable host connections (usually just localhost- the idea being
that you can SSH into the machine running Hercules, then launch
Telnet
Post by Keven Tipping
locally to reconnect to the Herc HMC running in the background as a
service).
I'm well aware that Herc has the HTTP server and CGI stuff built-in,
however more times then not the only thing I have is an SSH line
to my
Post by Keven Tipping
Hercules box itself or another box in my network that I can tunnel
through. I also find that (no offense) the HTML/CGI interface is
somewhat kludgy to use at times and the auto-refresh thing isn't as
concise as a direct link to the Hercules cmdline via a terminal.
So once again- /where/ would this code be best fitted? As a module
for
Post by Keven Tipping
HDL, or as something else?
If anyone has any other relevant pointers or suggestions, they would
be highly welcomed.
Cheerio.
-KT
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA http://geocities.com/maschwab/ for
software links
[Non-text portions of this message have been removed]
William Carroll
2008-09-05 21:14:17 UTC
Permalink
Hi Kevin,
I don't post much but I understand what your asking for and it would be
nice, however I have some concerns with #1.

If an OS guest is running under Hercules you need that guest to shutdown
first cleanly
before bringing Hercules down. this mean that SIGTERM has to be relayed
to the guest
OS for it to shutdown. So it does have something to do with the guest OS
IMHO

if you see differently could you please expand on it?
Now I do see that you could do some kind of automation through
the Hercules console and upon receiving a SIGTERM you could invoke
some kind of automation to shutdown the guest OS as long as it can
receive commands from the Hercules console.
Post by Keven Tipping
I think the point of my original post was missed.
I don't really care about the OS running under Hercules. This has
nothing to do with the emulated system or any other mainframe OS.
This has everything to do with Hercules itself- as a process, running
under a Linux host. I apologize if I'm being unclear here or
something, because I've brought this up before and never got any real
answers.
As I said before- I want to enable Hercules so that it can run as a
INIT service on a dedicated Linux machine. That means Hercules is
started and stopped WITH the actual host computer itself.
In order to do this properly and not use the HTTP GUI, two things have
1) Hercules had to support signal handling from the Linux OS, so that
it can shut down cleanly when it receives a signal such as SIGTERM.
This has NOTHING to do with the emulated guest.
2) Run hercules as a daemon (hercules -d -f ./myconf.cnf) with a
detachable, re-attachable text-only user interface. I figured this
would be easiest to implement as a telnet server that only accepts
connections from localhost- so you can log into the dedicated
computer, and just run telnet to reconnect to the /background/
Hercules daemon.
Originally I had asked /how/ it would be best to implement these
features in the Hercules source. As a HDL module, as a separate
executable (aka Herclin), etc. I guess somewhere I confused everyone
or something...
-KT
Shutting down: The proposed MVS/380 project has a job that does this.
Remote access: Not sure what you want. There are some RJE programs
out there that allow you to edit and submit jobs in 80 column mode,
then review printout in 132 column mode.
<mailto:bytelogix%40shaw.ca>>
Post by Keven Tipping
Greetings to all.
I've been using Herc for a while now on a dedicated box. Works
great.
Post by Keven Tipping
I'd like to implement two features that I think Hercules /really/
needs, though I'm not really sure how/where said features should be
implemented.
1) Signal Handling
I'd like to add some sort of signal handling to Hercules so that I
can
Post by Keven Tipping
fire off signals at the process and have it *shut down gracefully*
(as
Post by Keven Tipping
in, running through the HHCxx9yyI messages). Basically, this would
be
Post by Keven Tipping
as simple as setting up the signal handling under Linux and
launching
Post by Keven Tipping
the equivalent to typing "exit" on the Hercules HMC when a signal is
received.
The reason for this being, is that when I'm running Hercules in the
background- start-stop-daemon can start Hercules as a system
service,
Post by Keven Tipping
but I've got to manually shut it down before start-stop-daemon
attempts to do so- otherwise Hercules simply dies and doesn't
clean up.
Post by Keven Tipping
Where would the code for this best go? In an additional module
loaded
Post by Keven Tipping
by the HDL? Or somewhere else?
2) Detachable UI
This is one that really kills me. At the moment, I'm running
Hercules
Post by Keven Tipping
under a screen session with multiuser support in the screenrc for my
system. It's a hack at best.
I'd like to implement a very simple telnet server for Hercules,
with a
Post by Keven Tipping
simple plaintext auth specified in the config file and an ACL for
acceptable host connections (usually just localhost- the idea being
that you can SSH into the machine running Hercules, then launch
Telnet
Post by Keven Tipping
locally to reconnect to the Herc HMC running in the background as a
service).
I'm well aware that Herc has the HTTP server and CGI stuff built-in,
however more times then not the only thing I have is an SSH line
to my
Post by Keven Tipping
Hercules box itself or another box in my network that I can tunnel
through. I also find that (no offense) the HTML/CGI interface is
somewhat kludgy to use at times and the auto-refresh thing isn't as
concise as a direct link to the Hercules cmdline via a terminal.
So once again- /where/ would this code be best fitted? As a module
for
Post by Keven Tipping
HDL, or as something else?
If anyone has any other relevant pointers or suggestions, they would
be highly welcomed.
Cheerio.
-KT
------------------------------------
<mailto:hercules-390%40yahoogroups.com>
<mailto:hercules-390-subscribe%40yahoogroups.com>
<mailto:hercules-390-unsubscribe%40yahoogroups.com>
<mailto:hercules-390-owner%40yahoogroups.com>
Post by Keven Tipping
http://groups.yahoo.com/group/hercules-390
<http://groups.yahoo.com/group/hercules-390>
Post by Keven Tipping
http://www.hercules-390.org <http://www.hercules-390.org>
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA http://geocities.com/maschwab/
<http://geocities.com/maschwab/> for
software links
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
Marcin Cieslak
2008-09-05 22:19:52 UTC
Permalink
Post by William Carroll
If an OS guest is running under Hercules you need that guest to shutdown
first cleanly
before bringing Hercules down. this mean that SIGTERM has to be relayed
to the guest
OS for it to shutdown. So it does have something to do with the guest OS
IMHO
If you want to ignore the OS running under Hercules, just send it
SIGTERM - hercules has little need for "clean" shutdown afaik.

It's the OS that should probably be brought down cleanly first.

--Marcin



[Non-text portions of this message have been removed]
kerravon86
2008-09-05 22:26:51 UTC
Permalink
Post by Marcin Cieslak
If you want to ignore the OS running under Hercules, just send it
SIGTERM - hercules has little need for "clean" shutdown afaik.
It's the OS that should probably be brought down cleanly first.
And if you wish to do that, simply submit a batch
job to the Hercules reader, and trigger an HAO
on the jobname.

BFN. Paul.
Greg Smith
2008-09-05 22:48:40 UTC
Permalink
Post by Keven Tipping
I think the point of my original post was missed.
I don't really care about the OS running under Hercules. This has
nothing to do with the emulated system or any other mainframe OS.
This has everything to do with Hercules itself- as a process, running
under a Linux host. I apologize if I'm being unclear here or
something, because I've brought this up before and never got any real
answers.
As I said before- I want to enable Hercules so that it can run as a
INIT service on a dedicated Linux machine. That means Hercules is
started and stopped WITH the actual host computer itself.
In order to do this properly and not use the HTTP GUI, two things have
1) Hercules had to support signal handling from the Linux OS, so that
it can shut down cleanly when it receives a signal such as SIGTERM.
This has NOTHING to do with the emulated guest.
2) Run hercules as a daemon (hercules -d -f ./myconf.cnf) with a
detachable, re-attachable text-only user interface. I figured this
would be easiest to implement as a telnet server that only accepts
connections from localhost- so you can log into the dedicated
computer, and just run telnet to reconnect to the /background/
Hercules daemon.
Originally I had asked /how/ it would be best to implement these
features in the Hercules source. As a HDL module, as a separate
executable (aka Herclin), etc. I guess somewhere I confused everyone
or something...
In impl.c routine impl() we register the SIGINT handler
sigint_handler(). This would be the place to register a
SIGHUP/SIGTERM/SIGKILL or whatever handler routine shutdown_handler()
which would be a static routine in impl.c (like sigint_handler). This
routine would simply call do_shutdown() (eg see hsccmd.c quit_cmd()).

I suppose we need to come to some consensus what signal(s) to register,
but IMO it should be a signal linux (or whatever) issues to processes
during shutdown.

I'm not sure of the status of signaling on Windows.

I believe what Kevin is getting at here is to do a (semi)-graceful
shutdown of hercules, not the os it is running.

If the operating system indicates that it can process SIGP quiesce
interrupts then do_shutdown() waits for the os to shutdown. If
do_shutdown() is called again then hercules really shuts down.

On my Fedora system I think shutdown issues SIGHUP to all processes,
waits a bit, then issues SIGTERM to all processes. So I think it would
be good to intercept both these signals. SIGHUP to start the os
shutting down and SIGTERM to shut hercules down if the os hasn't
finished shutting down.

As far as the terminal thing goes, I've personally have tolerated
screen. If you want to experiment look at panel.c routine
panel_display().

Greg
Adam Thornton
2008-09-05 23:18:09 UTC
Permalink
Post by Greg Smith
On my Fedora system I think shutdown issues SIGHUP to all processes,
waits a bit, then issues SIGTERM to all processes.
SIGTERM and then SIGKILL, I think.

And you can't trap SIGKILL. That's kinda the point.

HUP means something quite different: the interactive user hung up the
terminal session, or for processes running without an attached
terminal (which would be a very useful hercules mode of operation),
it's usually taken to mean "re-read your configuration files".
Traditionally you HUP a process when you've changed its config but you
don't want to shut down the service and restart it.

Adam

[Non-text portions of this message have been removed]
Frans Pop
2008-09-05 23:22:55 UTC
Permalink
Post by Greg Smith
I suppose we need to come to some consensus what signal(s) to register,
but IMO it should be a signal linux (or whatever) issues to processes
during shutdown.
On Debian it is the /etc/init.d/sendsigs script which stops any processes
still alive when it is called during a shutdown/reboot procedure.
For a switch to single-user mode there is a slightly different script
/etc/init.d/killprocs.

What the both do is essentially:
* send SIGTERM (15) to all processes
* for up to 10 iterations:
* check if there are still active processes using SIGCONT (18)
* if there are none, break
* if there are, sleep for 1 second
* send SIGKILL (9) to remaining processes

This means that by default hercules (or any other process) has only 10
seconds to respond to the signal to shut down gracefully on a Debian
system, which may well not be enough to cleanly shut down a guest system.

The solution would probably be to give Hercules its own init script that
runs earlier than these scripts and make sure that that script waits and
delays the shutdown procedure while the signal is being processed.

Anyway, as far as I know SIGTERM would be the correct signal to use.

Cheers,
FJP
Keven Tipping
2008-09-06 00:44:50 UTC
Permalink
Mr. Smith knows what I'm looking for- simply the ability to have
Hercules call do_shutdown() when it receives a SIGTERM to clean up and
exit gracefully. IMHO, any guest OS's should have been shut down long
before Hercules receives a SIGTERM.

In 99% of all cases, if Hercules is being sent a SIGTERM as a result
of the Linux computer going down, it has approximately 5-10 seconds to
clean up and terminate. Anything past that and Linux will send it a
SIGKILL, killing the Herc process forcefully.

As for the Telnet server...

Hercules already has this support built-in, in the form of TN3270
support (which is Telnet, right?).

Would it be possible to modify this code- so that you could specify a
device that literally hooks up to the Hercules HMC over a separate
port with a simple user/password? 3270 already supports a basic ACL
list in the form of the device arguments, so that's good.

I guess the resulting configuration line would look something like:

0000 HMC 127.0.0.1:23 -u myuser -p mypass

And this would basically tell Hercules- "Okay, let Telnet users
connect to Localhost on port 23, ask them for the username and
password, and if valid- connect them to the Hercules command line
(HMC)"...

Would this be easier to implement then a completely separate Telnet
server?

-KT
Post by Greg Smith
Post by Greg Smith
I suppose we need to come to some consensus what signal(s) to
register,
Post by Greg Smith
but IMO it should be a signal linux (or whatever) issues to
processes
Post by Greg Smith
during shutdown.
On Debian it is the /etc/init.d/sendsigs script which stops any processes
still alive when it is called during a shutdown/reboot procedure.
For a switch to single-user mode there is a slightly different script
/etc/init.d/killprocs.
* send SIGTERM (15) to all processes
* check if there are still active processes using SIGCONT (18)
* if there are none, break
* if there are, sleep for 1 second
* send SIGKILL (9) to remaining processes
This means that by default hercules (or any other process) has only 10
seconds to respond to the signal to shut down gracefully on a Debian
system, which may well not be enough to cleanly shut down a guest system.
The solution would probably be to give Hercules its own init script that
runs earlier than these scripts and make sure that that script waits and
delays the shutdown procedure while the signal is being processed.
Anyway, as far as I know SIGTERM would be the correct signal to use.
Cheers,
FJP
[Non-text portions of this message have been removed]
William Carroll
2008-09-06 01:42:25 UTC
Permalink
The point of a SIGTERM is for the process to shutdown cleanly as you state.
If that process does not include notification of the guest OS to
shutdown then
what is the difference between it and a SIGKILL? NONE

A SIGTERM without guest shutdown is not a clean shutdown IMHO

I've not seen Linux behave the way described either. issue a SIGTERM at
shutdown and if not done in 10sec it KILLs the process.

If that was the case Linux would never make it in an enterprise. Data
integrity
at shutdown would be poor.

am I misunderstanding this?

Doug
Post by Keven Tipping
Mr. Smith knows what I'm looking for- simply the ability to have
Hercules call do_shutdown() when it receives a SIGTERM to clean up and
exit gracefully. IMHO, any guest OS's should have been shut down long
before Hercules receives a SIGTERM.
In 99% of all cases, if Hercules is being sent a SIGTERM as a result
of the Linux computer going down, it has approximately 5-10 seconds to
clean up and terminate. Anything past that and Linux will send it a
SIGKILL, killing the Herc process forcefully.
As for the Telnet server...
Hercules already has this support built-in, in the form of TN3270
support (which is Telnet, right?).
Would it be possible to modify this code- so that you could specify a
device that literally hooks up to the Hercules HMC over a separate
port with a simple user/password? 3270 already supports a basic ACL
list in the form of the device arguments, so that's good.
0000 HMC 127.0.0.1:23 -u myuser -p mypass
And this would basically tell Hercules- "Okay, let Telnet users
connect to Localhost on port 23, ask them for the username and
password, and if valid- connect them to the Hercules command line
(HMC)"...
Would this be easier to implement then a completely separate Telnet
server?
-KT
Post by Greg Smith
Post by Greg Smith
I suppose we need to come to some consensus what signal(s) to
register,
Post by Greg Smith
but IMO it should be a signal linux (or whatever) issues to
processes
Post by Greg Smith
during shutdown.
On Debian it is the /etc/init.d/sendsigs script which stops any processes
still alive when it is called during a shutdown/reboot procedure.
For a switch to single-user mode there is a slightly different script
/etc/init.d/killprocs.
* send SIGTERM (15) to all processes
* check if there are still active processes using SIGCONT (18)
* if there are none, break
* if there are, sleep for 1 second
* send SIGKILL (9) to remaining processes
This means that by default hercules (or any other process) has only 10
seconds to respond to the signal to shut down gracefully on a Debian
system, which may well not be enough to cleanly shut down a guest system.
The solution would probably be to give Hercules its own init script that
runs earlier than these scripts and make sure that that script waits and
delays the shutdown procedure while the signal is being processed.
Anyway, as far as I know SIGTERM would be the correct signal to use.
Cheers,
FJP
[Non-text portions of this message have been removed]
Mike Schwab
2008-09-06 01:55:45 UTC
Permalink
It does exist but you should be able to tune the timing with a settings file.
Post by William Carroll
The point of a SIGTERM is for the process to shutdown cleanly as you state.
If that process does not include notification of the guest OS to
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown IMHO
I've not seen Linux behave the way described either. issue a SIGTERM at
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an enterprise. Data
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
--
Mike A Schwab, Springfield IL USA
Keven Tipping
2008-09-06 02:19:14 UTC
Permalink
It was a simple job that took 10 seconds of writing and grepping
through some files. It's taken me much longer to explain my motives
here with the amount of confusion and effort this is generating.

What would you suggest then, in terms of SIGTERM handling?

90% of the time this is issued when a system is going down. You
yourself claim that a process has exactly 10 seconds to comply before
Linux fries the process with SIGKILL. You can't (AFAIK) shut down z/VM
or z/OS in 10 seconds. Ergo, such a beast should have been shut down
long before SIGTERM is even a priority.

This whole thing was simply a formality I wanted to correct. Most
processes have cleanup routines when exiting. Hercules has these in
the form of do_shutdown(). Therefore, hercules should *call* these
cleanup routines when it receives a SIGTERM. Once you've gotten a
SIGTERM from the Linux host going *down*, it doesn't matter if the
guest OS is running or not- the system is going down regardless of
what you were running where.

So much confusion and effort over 10 lines of code, in as many
seconds. I'm sorry I brought it up.

-KT
Post by William Carroll
The point of a SIGTERM is for the process to shutdown cleanly as you state.
If that process does not include notification of the guest OS to
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown IMHO
I've not seen Linux behave the way described either. issue a SIGTERM
at
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an enterprise. Data
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
Post by Keven Tipping
Mr. Smith knows what I'm looking for- simply the ability to have
Hercules call do_shutdown() when it receives a SIGTERM to clean up
and
Post by Keven Tipping
exit gracefully. IMHO, any guest OS's should have been shut down
long
Post by Keven Tipping
before Hercules receives a SIGTERM.
In 99% of all cases, if Hercules is being sent a SIGTERM as a result
of the Linux computer going down, it has approximately 5-10
seconds to
Post by Keven Tipping
clean up and terminate. Anything past that and Linux will send it a
SIGKILL, killing the Herc process forcefully.
As for the Telnet server...
Hercules already has this support built-in, in the form of TN3270
support (which is Telnet, right?).
Would it be possible to modify this code- so that you could
specify a
Post by Keven Tipping
device that literally hooks up to the Hercules HMC over a separate
port with a simple user/password? 3270 already supports a basic ACL
list in the form of the device arguments, so that's good.
0000 HMC 127.0.0.1:23 -u myuser -p mypass
And this would basically tell Hercules- "Okay, let Telnet users
connect to Localhost on port 23, ask them for the username and
password, and if valid- connect them to the Hercules command line
(HMC)"...
Would this be easier to implement then a completely separate Telnet
server?
-KT
Post by Greg Smith
Post by Greg Smith
I suppose we need to come to some consensus what signal(s) to
register,
Post by Greg Smith
but IMO it should be a signal linux (or whatever) issues to
processes
Post by Greg Smith
during shutdown.
On Debian it is the /etc/init.d/sendsigs script which stops any processes
still alive when it is called during a shutdown/reboot procedure.
For a switch to single-user mode there is a slightly different
script
Post by Keven Tipping
Post by Greg Smith
/etc/init.d/killprocs.
* send SIGTERM (15) to all processes
* check if there are still active processes using SIGCONT (18)
* if there are none, break
* if there are, sleep for 1 second
* send SIGKILL (9) to remaining processes
This means that by default hercules (or any other process) has
only 10
Post by Keven Tipping
Post by Greg Smith
seconds to respond to the signal to shut down gracefully on a
Debian
Post by Keven Tipping
Post by Greg Smith
system, which may well not be enough to cleanly shut down a guest system.
The solution would probably be to give Hercules its own init
script
Post by Keven Tipping
Post by Greg Smith
that
runs earlier than these scripts and make sure that that script
waits
Post by Keven Tipping
Post by Greg Smith
and
delays the shutdown procedure while the signal is being processed.
Anyway, as far as I know SIGTERM would be the correct signal to
use.
Post by Keven Tipping
Post by Greg Smith
Cheers,
FJP
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
William Carroll
2008-09-06 03:31:06 UTC
Permalink
I was only quoting your 5-10sec example and using 10sec as an example.
I have had processes take 5-10 min to shutdown so I have not seen this
5-10sec shutdown
you mention. I personally do not want Linux Killing a process because it
has not responded
in a short time. Data integrity comes to mind. I want them to shutdown
properly and cleanly

I've already suggested what SIGTERM should do.
A method to pass to the guest OS to shutdown, The HMC does this, I've
watched VM shutdown because of a shutdown of the LPAR.
VM does not just die. it shutdown. Passing this via Hercules allows the
user to implement a guest shutdown.
if you don't' care about the guest os you don't implement it. if you do
care you get your guest shutdown
properly then shutdown Hercules

And my argument is it does mater to the guest OS.

I"m not sorry you brought it up, it's a difference of opinion on what
proper shutdown
means. To you the guest OS does not mater, to me it does.

Doug
Post by Keven Tipping
It was a simple job that took 10 seconds of writing and grepping
through some files. It's taken me much longer to explain my motives
here with the amount of confusion and effort this is generating.
What would you suggest then, in terms of SIGTERM handling?
90% of the time this is issued when a system is going down. You
yourself claim that a process has exactly 10 seconds to comply before
Linux fries the process with SIGKILL. You can't (AFAIK) shut down z/VM
or z/OS in 10 seconds. Ergo, such a beast should have been shut down
long before SIGTERM is even a priority.
This whole thing was simply a formality I wanted to correct. Most
processes have cleanup routines when exiting. Hercules has these in
the form of do_shutdown(). Therefore, hercules should *call* these
cleanup routines when it receives a SIGTERM. Once you've gotten a
SIGTERM from the Linux host going *down*, it doesn't matter if the
guest OS is running or not- the system is going down regardless of
what you were running where.
So much confusion and effort over 10 lines of code, in as many
seconds. I'm sorry I brought it up.
-KT
Post by William Carroll
The point of a SIGTERM is for the process to shutdown cleanly as you state.
If that process does not include notification of the guest OS to
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown IMHO
I've not seen Linux behave the way described either. issue a SIGTERM
at
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an enterprise. Data
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
Post by Keven Tipping
Mr. Smith knows what I'm looking for- simply the ability to have
Hercules call do_shutdown() when it receives a SIGTERM to clean up
and
Post by Keven Tipping
exit gracefully. IMHO, any guest OS's should have been shut down
long
Post by Keven Tipping
before Hercules receives a SIGTERM.
In 99% of all cases, if Hercules is being sent a SIGTERM as a result
of the Linux computer going down, it has approximately 5-10
seconds to
Post by Keven Tipping
clean up and terminate. Anything past that and Linux will send it a
SIGKILL, killing the Herc process forcefully.
As for the Telnet server...
Hercules already has this support built-in, in the form of TN3270
support (which is Telnet, right?).
Would it be possible to modify this code- so that you could
specify a
Post by Keven Tipping
device that literally hooks up to the Hercules HMC over a separate
port with a simple user/password? 3270 already supports a basic ACL
list in the form of the device arguments, so that's good.
0000 HMC 127.0.0.1:23 -u myuser -p mypass
And this would basically tell Hercules- "Okay, let Telnet users
connect to Localhost on port 23, ask them for the username and
password, and if valid- connect them to the Hercules command line
(HMC)"...
Would this be easier to implement then a completely separate Telnet
server?
-KT
Post by Greg Smith
Post by Greg Smith
I suppose we need to come to some consensus what signal(s) to
register,
Post by Greg Smith
but IMO it should be a signal linux (or whatever) issues to
processes
Post by Greg Smith
during shutdown.
On Debian it is the /etc/init.d/sendsigs script which stops any processes
still alive when it is called during a shutdown/reboot procedure.
For a switch to single-user mode there is a slightly different
script
Post by Keven Tipping
Post by Greg Smith
/etc/init.d/killprocs.
* send SIGTERM (15) to all processes
* check if there are still active processes using SIGCONT (18)
* if there are none, break
* if there are, sleep for 1 second
* send SIGKILL (9) to remaining processes
This means that by default hercules (or any other process) has
only 10
Post by Keven Tipping
Post by Greg Smith
seconds to respond to the signal to shut down gracefully on a
Debian
Post by Keven Tipping
Post by Greg Smith
system, which may well not be enough to cleanly shut down a guest system.
The solution would probably be to give Hercules its own init
script
Post by Keven Tipping
Post by Greg Smith
that
runs earlier than these scripts and make sure that that script
waits
Post by Keven Tipping
Post by Greg Smith
and
delays the shutdown procedure while the signal is being processed.
Anyway, as far as I know SIGTERM would be the correct signal to
use.
Post by Keven Tipping
Post by Greg Smith
Cheers,
FJP
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
Keven Tipping
2008-09-06 04:20:06 UTC
Permalink
Hmm, that's odd.

This must be something distribution dependent then. As Frans stated-
on Debian, there's a timer, and any processes that take more then 10
seconds to shut down are killed. On Gentoo Linux it seems to do the
same.

If I may ask- which distribution are you running that happens to wait
until the process has died?

-KT
Post by William Carroll
I was only quoting your 5-10sec example and using 10sec as an example.
I have had processes take 5-10 min to shutdown so I have not seen this
5-10sec shutdown
you mention. I personally do not want Linux Killing a process
because it
has not responded
in a short time. Data integrity comes to mind. I want them to shutdown
properly and cleanly
I've already suggested what SIGTERM should do.
A method to pass to the guest OS to shutdown, The HMC does this, I've
watched VM shutdown because of a shutdown of the LPAR.
VM does not just die. it shutdown. Passing this via Hercules allows
the
user to implement a guest shutdown.
if you don't' care about the guest os you don't implement it. if you
do
care you get your guest shutdown
properly then shutdown Hercules
And my argument is it does mater to the guest OS.
I"m not sorry you brought it up, it's a difference of opinion on what
proper shutdown
means. To you the guest OS does not mater, to me it does.
Doug
Post by Keven Tipping
It was a simple job that took 10 seconds of writing and grepping
through some files. It's taken me much longer to explain my motives
here with the amount of confusion and effort this is generating.
What would you suggest then, in terms of SIGTERM handling?
90% of the time this is issued when a system is going down. You
yourself claim that a process has exactly 10 seconds to comply
before
Post by Keven Tipping
Linux fries the process with SIGKILL. You can't (AFAIK) shut down
z/VM
Post by Keven Tipping
or z/OS in 10 seconds. Ergo, such a beast should have been shut down
long before SIGTERM is even a priority.
This whole thing was simply a formality I wanted to correct. Most
processes have cleanup routines when exiting. Hercules has these in
the form of do_shutdown(). Therefore, hercules should *call* these
cleanup routines when it receives a SIGTERM. Once you've gotten a
SIGTERM from the Linux host going *down*, it doesn't matter if the
guest OS is running or not- the system is going down regardless of
what you were running where.
So much confusion and effort over 10 lines of code, in as many
seconds. I'm sorry I brought it up.
-KT
Post by William Carroll
The point of a SIGTERM is for the process to shutdown cleanly as
you
Post by Keven Tipping
Post by William Carroll
state.
If that process does not include notification of the guest OS to
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown IMHO
I've not seen Linux behave the way described either. issue a
SIGTERM
Post by Keven Tipping
Post by William Carroll
at
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an enterprise.
Data
Post by Keven Tipping
Post by William Carroll
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
Post by Keven Tipping
Mr. Smith knows what I'm looking for- simply the ability to have
Hercules call do_shutdown() when it receives a SIGTERM to
clean up
Post by Keven Tipping
Post by William Carroll
and
Post by Keven Tipping
exit gracefully. IMHO, any guest OS's should have been shut down
long
Post by Keven Tipping
before Hercules receives a SIGTERM.
In 99% of all cases, if Hercules is being sent a SIGTERM as a
result
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
of the Linux computer going down, it has approximately 5-10
seconds to
Post by Keven Tipping
clean up and terminate. Anything past that and Linux will send
it a
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
SIGKILL, killing the Herc process forcefully.
As for the Telnet server...
Hercules already has this support built-in, in the form of
TN3270
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
support (which is Telnet, right?).
Would it be possible to modify this code- so that you could
specify a
Post by Keven Tipping
device that literally hooks up to the Hercules HMC over a
separate
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
port with a simple user/password? 3270 already supports a
basic ACL
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
list in the form of the device arguments, so that's good.
I guess the resulting configuration line would look something
0000 HMC 127.0.0.1:23 -u myuser -p mypass
And this would basically tell Hercules- "Okay, let Telnet users
connect to Localhost on port 23, ask them for the username and
password, and if valid- connect them to the Hercules command
line
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
(HMC)"...
Would this be easier to implement then a completely separate
Telnet
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
server?
-KT
Post by Greg Smith
Post by Greg Smith
I suppose we need to come to some consensus what signal(s)
to
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
register,
Post by Greg Smith
but IMO it should be a signal linux (or whatever) issues to
processes
Post by Greg Smith
during shutdown.
On Debian it is the /etc/init.d/sendsigs script which stops
any
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
processes
still alive when it is called during a shutdown/reboot
procedure.
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
For a switch to single-user mode there is a slightly different
script
Post by Keven Tipping
Post by Greg Smith
/etc/init.d/killprocs.
* send SIGTERM (15) to all processes
* check if there are still active processes using SIGCONT (18)
* if there are none, break
* if there are, sleep for 1 second
* send SIGKILL (9) to remaining processes
This means that by default hercules (or any other process) has
only 10
Post by Keven Tipping
Post by Greg Smith
seconds to respond to the signal to shut down gracefully on a
Debian
Post by Keven Tipping
Post by Greg Smith
system, which may well not be enough to cleanly shut down a
guest
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
system.
The solution would probably be to give Hercules its own init
script
Post by Keven Tipping
Post by Greg Smith
that
runs earlier than these scripts and make sure that that script
waits
Post by Keven Tipping
Post by Greg Smith
and
delays the shutdown procedure while the signal is being
processed.
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
Anyway, as far as I know SIGTERM would be the correct signal
to
Post by Keven Tipping
Post by William Carroll
use.
Post by Keven Tipping
Post by Greg Smith
Cheers,
FJP
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
William Carroll
2008-09-06 05:11:38 UTC
Permalink
Redhat RHEL 4 and RH5.2 both wait for all processes to shutdown properly.
i.e. it is not killing processes before they shutdown cleanly on their own

Doug
Post by Keven Tipping
Hmm, that's odd.
This must be something distribution dependent then. As Frans stated-
on Debian, there's a timer, and any processes that take more then 10
seconds to shut down are killed. On Gentoo Linux it seems to do the
same.
If I may ask- which distribution are you running that happens to wait
until the process has died?
-KT
Post by William Carroll
I was only quoting your 5-10sec example and using 10sec as an example.
I have had processes take 5-10 min to shutdown so I have not seen this
5-10sec shutdown
you mention. I personally do not want Linux Killing a process because it
has not responded
in a short time. Data integrity comes to mind. I want them to shutdown
properly and cleanly
I've already suggested what SIGTERM should do.
A method to pass to the guest OS to shutdown, The HMC does this, I've
watched VM shutdown because of a shutdown of the LPAR.
VM does not just die. it shutdown. Passing this via Hercules allows
the
user to implement a guest shutdown.
if you don't' care about the guest os you don't implement it. if you
do
care you get your guest shutdown
properly then shutdown Hercules
And my argument is it does mater to the guest OS.
I"m not sorry you brought it up, it's a difference of opinion on what
proper shutdown
means. To you the guest OS does not mater, to me it does.
Doug
Post by Keven Tipping
It was a simple job that took 10 seconds of writing and grepping
through some files. It's taken me much longer to explain my motives
here with the amount of confusion and effort this is generating.
What would you suggest then, in terms of SIGTERM handling?
90% of the time this is issued when a system is going down. You
yourself claim that a process has exactly 10 seconds to comply
before
Post by Keven Tipping
Linux fries the process with SIGKILL. You can't (AFAIK) shut down
z/VM
Post by Keven Tipping
or z/OS in 10 seconds. Ergo, such a beast should have been shut down
long before SIGTERM is even a priority.
This whole thing was simply a formality I wanted to correct. Most
processes have cleanup routines when exiting. Hercules has these in
the form of do_shutdown(). Therefore, hercules should *call* these
cleanup routines when it receives a SIGTERM. Once you've gotten a
SIGTERM from the Linux host going *down*, it doesn't matter if the
guest OS is running or not- the system is going down regardless of
what you were running where.
So much confusion and effort over 10 lines of code, in as many
seconds. I'm sorry I brought it up.
-KT
Post by William Carroll
The point of a SIGTERM is for the process to shutdown cleanly as
you
Post by Keven Tipping
Post by William Carroll
state.
If that process does not include notification of the guest OS to
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown IMHO
I've not seen Linux behave the way described either. issue a
SIGTERM
Post by Keven Tipping
Post by William Carroll
at
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an enterprise.
Data
Post by Keven Tipping
Post by William Carroll
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
Post by Keven Tipping
Mr. Smith knows what I'm looking for- simply the ability to have
Hercules call do_shutdown() when it receives a SIGTERM to
clean up
Post by Keven Tipping
Post by William Carroll
and
Post by Keven Tipping
exit gracefully. IMHO, any guest OS's should have been shut down
long
Post by Keven Tipping
before Hercules receives a SIGTERM.
In 99% of all cases, if Hercules is being sent a SIGTERM as a
result
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
of the Linux computer going down, it has approximately 5-10
seconds to
Post by Keven Tipping
clean up and terminate. Anything past that and Linux will send
it a
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
SIGKILL, killing the Herc process forcefully.
As for the Telnet server...
Hercules already has this support built-in, in the form of
TN3270
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
support (which is Telnet, right?).
Would it be possible to modify this code- so that you could
specify a
Post by Keven Tipping
device that literally hooks up to the Hercules HMC over a
separate
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
port with a simple user/password? 3270 already supports a
basic ACL
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
list in the form of the device arguments, so that's good.
I guess the resulting configuration line would look something
0000 HMC 127.0.0.1:23 -u myuser -p mypass
And this would basically tell Hercules- "Okay, let Telnet users
connect to Localhost on port 23, ask them for the username and
password, and if valid- connect them to the Hercules command
line
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
(HMC)"...
Would this be easier to implement then a completely separate
Telnet
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
server?
-KT
Post by Greg Smith
Post by Greg Smith
I suppose we need to come to some consensus what signal(s)
to
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
register,
Post by Greg Smith
but IMO it should be a signal linux (or whatever) issues to
processes
Post by Greg Smith
during shutdown.
On Debian it is the /etc/init.d/sendsigs script which stops
any
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
processes
still alive when it is called during a shutdown/reboot
procedure.
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
For a switch to single-user mode there is a slightly different
script
Post by Keven Tipping
Post by Greg Smith
/etc/init.d/killprocs.
* send SIGTERM (15) to all processes
* check if there are still active processes using SIGCONT (18)
* if there are none, break
* if there are, sleep for 1 second
* send SIGKILL (9) to remaining processes
This means that by default hercules (or any other process) has
only 10
Post by Keven Tipping
Post by Greg Smith
seconds to respond to the signal to shut down gracefully on a
Debian
Post by Keven Tipping
Post by Greg Smith
system, which may well not be enough to cleanly shut down a
guest
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
system.
The solution would probably be to give Hercules its own init
script
Post by Keven Tipping
Post by Greg Smith
that
runs earlier than these scripts and make sure that that script
waits
Post by Keven Tipping
Post by Greg Smith
and
delays the shutdown procedure while the signal is being
processed.
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
Anyway, as far as I know SIGTERM would be the correct signal
to
Post by Keven Tipping
Post by William Carroll
use.
Post by Keven Tipping
Post by Greg Smith
Cheers,
FJP
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
Frans Pop
2008-09-06 16:38:26 UTC
Permalink
Post by Keven Tipping
This must be something distribution dependent then. As Frans stated-
on Debian, there's a timer, and any processes that take more then 10
seconds to shut down are killed. On Gentoo Linux it seems to do the
same.
The 10 seconds on Debian is only if you let the "standard" sendsigs init
script handle the shut down of hercules!

That is why I mentioned that to do this properly, you would need a
separate "hercules" init script that _also_ sends a SIGTERM to (and only
to) the hercules process, but that allows for a longer wait so that any
guest OS _can_ be shut down cleanly. This script would obviously need to
run *before* sendsigs.
Harold Grovesteen
2008-09-06 13:56:39 UTC
Permalink
Doug,

Are you suggesting that in addition to properly handling the Linux
SIGTERM signal by Hercules, that this logic should also issue a signal
shutdown service processor command as is done by hsscmd.c in the ssd_cmd
function for the Hercules ssd console command?

Harold Grovesteen
Post by William Carroll
The point of a SIGTERM is for the process to shutdown cleanly as you state.
If that process does not include notification of the guest OS to
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown IMHO
I've not seen Linux behave the way described either. issue a SIGTERM at
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an enterprise. Data
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
Post by Keven Tipping
Mr. Smith knows what I'm looking for- simply the ability to have
Hercules call do_shutdown() when it receives a SIGTERM to clean up and
exit gracefully. IMHO, any guest OS's should have been shut down long
before Hercules receives a SIGTERM.
In 99% of all cases, if Hercules is being sent a SIGTERM as a result
of the Linux computer going down, it has approximately 5-10 seconds to
clean up and terminate. Anything past that and Linux will send it a
SIGKILL, killing the Herc process forcefully.
As for the Telnet server...
Hercules already has this support built-in, in the form of TN3270
support (which is Telnet, right?).
Would it be possible to modify this code- so that you could specify a
device that literally hooks up to the Hercules HMC over a separate
port with a simple user/password? 3270 already supports a basic ACL
list in the form of the device arguments, so that's good.
0000 HMC 127.0.0.1:23 -u myuser -p mypass
And this would basically tell Hercules- "Okay, let Telnet users
connect to Localhost on port 23, ask them for the username and
password, and if valid- connect them to the Hercules command line
(HMC)"...
Would this be easier to implement then a completely separate Telnet
server?
-KT
Post by Greg Smith
Post by Greg Smith
I suppose we need to come to some consensus what signal(s) to
register,
Post by Greg Smith
but IMO it should be a signal linux (or whatever) issues to
processes
Post by Greg Smith
during shutdown.
On Debian it is the /etc/init.d/sendsigs script which stops any processes
still alive when it is called during a shutdown/reboot procedure.
For a switch to single-user mode there is a slightly different script
/etc/init.d/killprocs.
* send SIGTERM (15) to all processes
* check if there are still active processes using SIGCONT (18)
* if there are none, break
* if there are, sleep for 1 second
* send SIGKILL (9) to remaining processes
This means that by default hercules (or any other process) has only 10
seconds to respond to the signal to shut down gracefully on a Debian
system, which may well not be enough to cleanly shut down a guest system.
The solution would probably be to give Hercules its own init script that
runs earlier than these scripts and make sure that that script waits and
delays the shutdown procedure while the signal is being processed.
Anyway, as far as I know SIGTERM would be the correct signal to use.
Cheers,
FJP
[Non-text portions of this message have been removed]
u4gh
2008-09-06 20:34:31 UTC
Permalink
Linux shutdown works like this (with some variation of labels and
directories depending on the distribution):

The 'K' scripts in the /etc/rc*.d are executed with the operand 'stop'.

Then, processes are sent SIGTERM, and after a delay, are sent SIGKILL.

You don't need to wait for the SIGTERM to arrive. The start/stop
script in /etc/init.d (that is linked to the 'Snn' and 'Knn' files in
the /etc/rc*.d directories) can do whatever is necessary to convince
Hercules to safely shut down the guest OSes and quiesce itself and
shut down.

Basically, the startup/shutdown script in /etc/init.d needs to do
everything necessary to properly start and stop Hercules. It's quite
common to use commands like:

/sbin/service hercules stop

or

/sbin/service hercules restart

while the system is running, to get the service 'hercules' to either
stop or completely restart. All that happens during shutdown is that
Linux calls each of these scripts in turn (the Knn prefix determines
the order) and then issues SIGTERM to whatever is left, if the
shutdown script didn't do the job - and then SIGKILL if SIGTERM wasn't
enough.

So, you can use whatever method that you want to shut down your guest
OSes by putting the routines into startup and shutdown scripts - for
example, if you have VM/370 and MVS running as guests, you could
create three scripts in /etc/init.d, one for Hercules, and one each
for the guest OSes. By giving them S/K numbers in the correct order,
Hercules would start up before the guests, and the guests would be
shut down before Hercules. The guest OSes don't need to even use the
same startup/shutdown mechanisms - if you need to do it differently
for each OS, just write different scripts.

This is the typical way in which services are normally controlled in
Linux, and gives you plenty of flexibility since you can even trigger
different guest OS combinations to start up based on the Linux 'init'
state. Different distrubtions of Linux use the init states for
different purposes, but it is easy to alter the /etc/rc*.d files (or
via the chkconfig command if your distro has it) to customise it any
way that you want. You could have init state '3' mean just Hercules
with no guests, and '4' or '5' mean 'with guest X' or with guests
'X,Y, and Z'.

- Richard
Post by Harold Grovesteen
Doug,
Are you suggesting that in addition to properly handling the Linux
SIGTERM signal by Hercules, that this logic should also issue a signal
shutdown service processor command as is done by hsscmd.c in the ssd_cmd
function for the Hercules ssd console command?
Harold Grovesteen
Post by William Carroll
The point of a SIGTERM is for the process to shutdown cleanly as you state.
If that process does not include notification of the guest OS to
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown IMHO
I've not seen Linux behave the way described either. issue a
SIGTERM at
Post by Harold Grovesteen
Post by William Carroll
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an enterprise. Data
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
Keven Tipping
2008-09-06 21:03:36 UTC
Permalink
What I'm getting from this is that things vary depending on the host
OS and guest OS. So we need some way to deal with this.

What I'd prepose then, is something like the following line in the
Hercules configuration (before the device configuration):
SIGNAL SIGTERM /home/User/zVM/zvm_shutdown.rc
- Or the W32 variant, according to Fish -
SIGNAL SHUTDOWN C:\Hercules\zVM\zvm_shutdown.rc

This basically tells Hercules that, when it receives a SIGNAL of type
SIGTERM, it should run the panel commands found in ./zvm-shutdown.rc
(similar to the commands Hercules can run @ startup via Hercules.rc).
Since HAO is programmable from the panel, you could in theory write a
*.rc script that hooks into HAO as well, if that's required.

If no SIGNAL setting is found in the Hercules configuration, then just
assume SIGTERM (Linux) and CTRL_SHUTDOWN_EVENT (W32) is the equivalent
to calling do_shutdown() and be done with it.

The SIGNAL setting would by definition NOT be "shutdown only". Under
Linux, there's a /lot/ of different signals to send at a process. You
could use SIGNAL to define a script to run when Hercules receives
other signals- for doing other various tasks as well. These could hook
into a Linux service script to do a variety of tasks under the host OS
and guest OS.

This seems like the "proper" way to implement it, IMHO. Everyone is
happy and nothing is really hardcoded.

-KT
Post by u4gh
Linux shutdown works like this (with some variation of labels and
The 'K' scripts in the /etc/rc*.d are executed with the operand 'stop'.
Then, processes are sent SIGTERM, and after a delay, are sent SIGKILL.
You don't need to wait for the SIGTERM to arrive. The start/stop
script in /etc/init.d (that is linked to the 'Snn' and 'Knn' files in
the /etc/rc*.d directories) can do whatever is necessary to convince
Hercules to safely shut down the guest OSes and quiesce itself and
shut down.
Basically, the startup/shutdown script in /etc/init.d needs to do
everything necessary to properly start and stop Hercules. It's quite
/sbin/service hercules stop
or
/sbin/service hercules restart
while the system is running, to get the service 'hercules' to either
stop or completely restart. All that happens during shutdown is that
Linux calls each of these scripts in turn (the Knn prefix determines
the order) and then issues SIGTERM to whatever is left, if the
shutdown script didn't do the job - and then SIGKILL if SIGTERM wasn't
enough.
So, you can use whatever method that you want to shut down your guest
OSes by putting the routines into startup and shutdown scripts - for
example, if you have VM/370 and MVS running as guests, you could
create three scripts in /etc/init.d, one for Hercules, and one each
for the guest OSes. By giving them S/K numbers in the correct order,
Hercules would start up before the guests, and the guests would be
shut down before Hercules. The guest OSes don't need to even use the
same startup/shutdown mechanisms - if you need to do it differently
for each OS, just write different scripts.
This is the typical way in which services are normally controlled in
Linux, and gives you plenty of flexibility since you can even trigger
different guest OS combinations to start up based on the Linux 'init'
state. Different distrubtions of Linux use the init states for
different purposes, but it is easy to alter the /etc/rc*.d files (or
via the chkconfig command if your distro has it) to customise it any
way that you want. You could have init state '3' mean just Hercules
with no guests, and '4' or '5' mean 'with guest X' or with guests
'X,Y, and Z'.
- Richard
Post by Harold Grovesteen
Doug,
Are you suggesting that in addition to properly handling the Linux
SIGTERM signal by Hercules, that this logic should also issue a
signal
Post by Harold Grovesteen
shutdown service processor command as is done by hsscmd.c in the
ssd_cmd
Post by Harold Grovesteen
function for the Hercules ssd console command?
Harold Grovesteen
Post by William Carroll
The point of a SIGTERM is for the process to shutdown cleanly as
you
Post by Harold Grovesteen
Post by William Carroll
state.
If that process does not include notification of the guest OS to
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown IMHO
I've not seen Linux behave the way described either. issue a
SIGTERM at
Post by Harold Grovesteen
Post by William Carroll
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an enterprise.
Data
Post by Harold Grovesteen
Post by William Carroll
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
[Non-text portions of this message have been removed]
Mike Schwab
2008-09-06 21:33:28 UTC
Permalink
Instead of having to define every signal and the file in the Herucles
configuration file,
could a signal statement define the directory where the files are, and
the signal type will be used as the filename.
SIGNAL /home/User/zVM/
- Or the W32 variant, according to Fish -
SIGNAL C:\Hercules\zVM\
and the directory would contain filenames SIGTERM, SHUTDOWN,
RUNPDPCLIB, $TEMP, or whatever you want?
What I'm getting from this is that things vary depending on the host
OS and guest OS. So we need some way to deal with this.
What I'd prepose then, is something like the following line in the
SIGNAL SIGTERM /home/User/zVM/zvm_shutdown.rc
- Or the W32 variant, according to Fish -
SIGNAL SHUTDOWN C:\Hercules\zVM\zvm_shutdown.rc
This basically tells Hercules that, when it receives a SIGNAL of type
SIGTERM, it should run the panel commands found in ./zvm-shutdown.rc
Since HAO is programmable from the panel, you could in theory write a
*.rc script that hooks into HAO as well, if that's required.
If no SIGNAL setting is found in the Hercules configuration, then just
assume SIGTERM (Linux) and CTRL_SHUTDOWN_EVENT (W32) is the equivalent
to calling do_shutdown() and be done with it.
The SIGNAL setting would by definition NOT be "shutdown only". Under
Linux, there's a /lot/ of different signals to send at a process. You
could use SIGNAL to define a script to run when Hercules receives
other signals- for doing other various tasks as well. These could hook
into a Linux service script to do a variety of tasks under the host OS
and guest OS.
This seems like the "proper" way to implement it, IMHO. Everyone is
happy and nothing is really hardcoded.
-KT
Post by u4gh
Linux shutdown works like this (with some variation of labels and
The 'K' scripts in the /etc/rc*.d are executed with the operand 'stop'.
Then, processes are sent SIGTERM, and after a delay, are sent SIGKILL.
You don't need to wait for the SIGTERM to arrive. The start/stop
script in /etc/init.d (that is linked to the 'Snn' and 'Knn' files in
the /etc/rc*.d directories) can do whatever is necessary to convince
Hercules to safely shut down the guest OSes and quiesce itself and
shut down.
Basically, the startup/shutdown script in /etc/init.d needs to do
everything necessary to properly start and stop Hercules. It's quite
/sbin/service hercules stop
or
/sbin/service hercules restart
while the system is running, to get the service 'hercules' to either
stop or completely restart. All that happens during shutdown is that
Linux calls each of these scripts in turn (the Knn prefix determines
the order) and then issues SIGTERM to whatever is left, if the
shutdown script didn't do the job - and then SIGKILL if SIGTERM wasn't
enough.
So, you can use whatever method that you want to shut down your guest
OSes by putting the routines into startup and shutdown scripts - for
example, if you have VM/370 and MVS running as guests, you could
create three scripts in /etc/init.d, one for Hercules, and one each
for the guest OSes. By giving them S/K numbers in the correct order,
Hercules would start up before the guests, and the guests would be
shut down before Hercules. The guest OSes don't need to even use the
same startup/shutdown mechanisms - if you need to do it differently
for each OS, just write different scripts.
This is the typical way in which services are normally controlled in
Linux, and gives you plenty of flexibility since you can even trigger
different guest OS combinations to start up based on the Linux 'init'
state. Different distrubtions of Linux use the init states for
different purposes, but it is easy to alter the /etc/rc*.d files (or
via the chkconfig command if your distro has it) to customise it any
way that you want. You could have init state '3' mean just Hercules
with no guests, and '4' or '5' mean 'with guest X' or with guests
'X,Y, and Z'.
- Richard
Post by Harold Grovesteen
Doug,
Are you suggesting that in addition to properly handling the Linux
SIGTERM signal by Hercules, that this logic should also issue a
signal
Post by Harold Grovesteen
shutdown service processor command as is done by hsscmd.c in the
ssd_cmd
Post by Harold Grovesteen
function for the Hercules ssd console command?
Harold Grovesteen
Post by William Carroll
The point of a SIGTERM is for the process to shutdown cleanly as
you
Post by Harold Grovesteen
Post by William Carroll
state.
If that process does not include notification of the guest OS to
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown IMHO
I've not seen Linux behave the way described either. issue a
SIGTERM at
Post by Harold Grovesteen
Post by William Carroll
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an enterprise.
Data
Post by Harold Grovesteen
Post by William Carroll
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
Keven Tipping
2008-09-06 23:58:29 UTC
Permalink
You could do that, but then you're hardcoding the file names. The only
problem with this that I can see is if you have a guest OS system
that's moved between platforms- you'd have to have a file named
SHUTDOWN (assuming that's the alias for WM_ENDSESSION &&
CTRL_SHUTDOWN_EVENT) and a file named SIGTERM for Linux. I guess
ultimately it wouldn't matter, but I would rather leave the script
naming up to the user.

At this point in time, I've revised the SIGNAL config to the following:
SIGNAL SIGTERM SHUTDOWN -rc ./path/to/my/shutdown.rc

Essentially, this allows you to define more then one signal to a
single script. The above line would work on Windows or Linux (assuming
Fish ports what I've written to MSVC), since SIGTERM would simply be
ignored on Win32 and visa versa.

I've also added a hercules CLI command ("signal") to manage 'sig
handling via the command line. The basic usage is "signal list" (show
defined signal triggers), "signal del SIGXYZ" (delete signal trigger
for SIGXYZ), and "signal add SIGXYZ /path/to/shutdown.rc" (add an RC
script for SIGXYZ).

-KT
Post by Mike Schwab
Instead of having to define every signal and the file in the Herucles
configuration file,
could a signal statement define the directory where the files are, and
the signal type will be used as the filename.
SIGNAL /home/User/zVM/
- Or the W32 variant, according to Fish -
SIGNAL C:\Hercules\zVM\
and the directory would contain filenames SIGTERM, SHUTDOWN,
RUNPDPCLIB, $TEMP, or whatever you want?
What I'm getting from this is that things vary depending on the host
OS and guest OS. So we need some way to deal with this.
What I'd prepose then, is something like the following line in the
SIGNAL SIGTERM /home/User/zVM/zvm_shutdown.rc
- Or the W32 variant, according to Fish -
SIGNAL SHUTDOWN C:\Hercules\zVM\zvm_shutdown.rc
This basically tells Hercules that, when it receives a SIGNAL of
type
SIGTERM, it should run the panel commands found in ./zvm-shutdown.rc
Hercules.rc).
Since HAO is programmable from the panel, you could in theory
write a
*.rc script that hooks into HAO as well, if that's required.
If no SIGNAL setting is found in the Hercules configuration, then
just
assume SIGTERM (Linux) and CTRL_SHUTDOWN_EVENT (W32) is the
equivalent
to calling do_shutdown() and be done with it.
The SIGNAL setting would by definition NOT be "shutdown only". Under
Linux, there's a /lot/ of different signals to send at a process.
You
could use SIGNAL to define a script to run when Hercules receives
other signals- for doing other various tasks as well. These could
hook
into a Linux service script to do a variety of tasks under the
host OS
and guest OS.
This seems like the "proper" way to implement it, IMHO. Everyone is
happy and nothing is really hardcoded.
-KT
Post by u4gh
Linux shutdown works like this (with some variation of labels and
The 'K' scripts in the /etc/rc*.d are executed with the operand 'stop'.
Then, processes are sent SIGTERM, and after a delay, are sent
SIGKILL.
Post by u4gh
You don't need to wait for the SIGTERM to arrive. The start/stop
script in /etc/init.d (that is linked to the 'Snn' and 'Knn'
files in
Post by u4gh
the /etc/rc*.d directories) can do whatever is necessary to
convince
Post by u4gh
Hercules to safely shut down the guest OSes and quiesce itself and
shut down.
Basically, the startup/shutdown script in /etc/init.d needs to do
everything necessary to properly start and stop Hercules. It's
quite
Post by u4gh
/sbin/service hercules stop
or
/sbin/service hercules restart
while the system is running, to get the service 'hercules' to
either
Post by u4gh
stop or completely restart. All that happens during shutdown is
that
Post by u4gh
Linux calls each of these scripts in turn (the Knn prefix
determines
Post by u4gh
the order) and then issues SIGTERM to whatever is left, if the
shutdown script didn't do the job - and then SIGKILL if SIGTERM
wasn't
Post by u4gh
enough.
So, you can use whatever method that you want to shut down your
guest
Post by u4gh
OSes by putting the routines into startup and shutdown scripts -
for
Post by u4gh
example, if you have VM/370 and MVS running as guests, you could
create three scripts in /etc/init.d, one for Hercules, and one each
for the guest OSes. By giving them S/K numbers in the correct
order,
Post by u4gh
Hercules would start up before the guests, and the guests would be
shut down before Hercules. The guest OSes don't need to even use
the
Post by u4gh
same startup/shutdown mechanisms - if you need to do it differently
for each OS, just write different scripts.
This is the typical way in which services are normally controlled
in
Post by u4gh
Linux, and gives you plenty of flexibility since you can even
trigger
Post by u4gh
different guest OS combinations to start up based on the Linux
'init'
Post by u4gh
state. Different distrubtions of Linux use the init states for
different purposes, but it is easy to alter the /etc/rc*.d files
(or
Post by u4gh
via the chkconfig command if your distro has it) to customise it
any
Post by u4gh
way that you want. You could have init state '3' mean just Hercules
with no guests, and '4' or '5' mean 'with guest X' or with guests
'X,Y, and Z'.
- Richard
Post by Harold Grovesteen
Doug,
Are you suggesting that in addition to properly handling the
Linux
Post by u4gh
Post by Harold Grovesteen
SIGTERM signal by Hercules, that this logic should also issue a
signal
Post by Harold Grovesteen
shutdown service processor command as is done by hsscmd.c in the
ssd_cmd
Post by Harold Grovesteen
function for the Hercules ssd console command?
Harold Grovesteen
Post by William Carroll
The point of a SIGTERM is for the process to shutdown cleanly
as
Post by u4gh
you
Post by Harold Grovesteen
Post by William Carroll
state.
If that process does not include notification of the guest OS
to
Post by u4gh
Post by Harold Grovesteen
Post by William Carroll
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown IMHO
I've not seen Linux behave the way described either. issue a
SIGTERM at
Post by Harold Grovesteen
Post by William Carroll
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an
enterprise.
Post by u4gh
Data
Post by Harold Grovesteen
Post by William Carroll
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
[Non-text portions of this message have been removed]
Mike Schwab
2008-09-07 00:19:24 UTC
Permalink
It gets the signal name and file name out of the hercules definition file.
You could even write a script on the fly (sample: $temp.rc) then issue
the SIGNAL $temp and it would be executed.
Post by Keven Tipping
You could do that, but then you're hardcoding the file names. The only
problem with this that I can see is if you have a guest OS system
that's moved between platforms- you'd have to have a file named
SHUTDOWN (assuming that's the alias for WM_ENDSESSION &&
CTRL_SHUTDOWN_EVENT) and a file named SIGTERM for Linux. I guess
ultimately it wouldn't matter, but I would rather leave the script
naming up to the user.
SIGNAL SIGTERM SHUTDOWN -rc ./path/to/my/shutdown.rc
Essentially, this allows you to define more then one signal to a
single script. The above line would work on Windows or Linux (assuming
Fish ports what I've written to MSVC), since SIGTERM would simply be
ignored on Win32 and visa versa.
I've also added a hercules CLI command ("signal") to manage 'sig
handling via the command line. The basic usage is "signal list" (show
defined signal triggers), "signal del SIGXYZ" (delete signal trigger
for SIGXYZ), and "signal add SIGXYZ /path/to/shutdown.rc" (add an RC
script for SIGXYZ).
-KT
Post by Mike Schwab
Instead of having to define every signal and the file in the Herucles
configuration file,
could a signal statement define the directory where the files are, and
the signal type will be used as the filename.
SIGNAL /home/User/zVM/
- Or the W32 variant, according to Fish -
SIGNAL C:\Hercules\zVM\
and the directory would contain filenames SIGTERM, SHUTDOWN,
RUNPDPCLIB, $TEMP, or whatever you want?
What I'm getting from this is that things vary depending on the host
OS and guest OS. So we need some way to deal with this.
What I'd prepose then, is something like the following line in the
SIGNAL SIGTERM /home/User/zVM/zvm_shutdown.rc
- Or the W32 variant, according to Fish -
SIGNAL SHUTDOWN C:\Hercules\zVM\zvm_shutdown.rc
This basically tells Hercules that, when it receives a SIGNAL of
type
SIGTERM, it should run the panel commands found in ./zvm-shutdown.rc
Hercules.rc).
Since HAO is programmable from the panel, you could in theory
write a
*.rc script that hooks into HAO as well, if that's required.
If no SIGNAL setting is found in the Hercules configuration, then
just
assume SIGTERM (Linux) and CTRL_SHUTDOWN_EVENT (W32) is the
equivalent
to calling do_shutdown() and be done with it.
The SIGNAL setting would by definition NOT be "shutdown only". Under
Linux, there's a /lot/ of different signals to send at a process.
You
could use SIGNAL to define a script to run when Hercules receives
other signals- for doing other various tasks as well. These could
hook
into a Linux service script to do a variety of tasks under the
host OS
and guest OS.
This seems like the "proper" way to implement it, IMHO. Everyone is
happy and nothing is really hardcoded.
-KT
Post by u4gh
Linux shutdown works like this (with some variation of labels and
The 'K' scripts in the /etc/rc*.d are executed with the operand 'stop'.
Then, processes are sent SIGTERM, and after a delay, are sent
SIGKILL.
Post by u4gh
You don't need to wait for the SIGTERM to arrive. The start/stop
script in /etc/init.d (that is linked to the 'Snn' and 'Knn'
files in
Post by u4gh
the /etc/rc*.d directories) can do whatever is necessary to
convince
Post by u4gh
Hercules to safely shut down the guest OSes and quiesce itself and
shut down.
Basically, the startup/shutdown script in /etc/init.d needs to do
everything necessary to properly start and stop Hercules. It's
quite
Post by u4gh
/sbin/service hercules stop
or
/sbin/service hercules restart
while the system is running, to get the service 'hercules' to
either
Post by u4gh
stop or completely restart. All that happens during shutdown is
that
Post by u4gh
Linux calls each of these scripts in turn (the Knn prefix
determines
Post by u4gh
the order) and then issues SIGTERM to whatever is left, if the
shutdown script didn't do the job - and then SIGKILL if SIGTERM
wasn't
Post by u4gh
enough.
So, you can use whatever method that you want to shut down your
guest
Post by u4gh
OSes by putting the routines into startup and shutdown scripts -
for
Post by u4gh
example, if you have VM/370 and MVS running as guests, you could
create three scripts in /etc/init.d, one for Hercules, and one each
for the guest OSes. By giving them S/K numbers in the correct
order,
Post by u4gh
Hercules would start up before the guests, and the guests would be
shut down before Hercules. The guest OSes don't need to even use
the
Post by u4gh
same startup/shutdown mechanisms - if you need to do it differently
for each OS, just write different scripts.
This is the typical way in which services are normally controlled
in
Post by u4gh
Linux, and gives you plenty of flexibility since you can even
trigger
Post by u4gh
different guest OS combinations to start up based on the Linux
'init'
Post by u4gh
state. Different distrubtions of Linux use the init states for
different purposes, but it is easy to alter the /etc/rc*.d files
(or
Post by u4gh
via the chkconfig command if your distro has it) to customise it
any
Post by u4gh
way that you want. You could have init state '3' mean just Hercules
with no guests, and '4' or '5' mean 'with guest X' or with guests
'X,Y, and Z'.
- Richard
Post by Harold Grovesteen
Doug,
Are you suggesting that in addition to properly handling the
Linux
Post by u4gh
Post by Harold Grovesteen
SIGTERM signal by Hercules, that this logic should also issue a
signal
Post by Harold Grovesteen
shutdown service processor command as is done by hsscmd.c in the
ssd_cmd
Post by Harold Grovesteen
function for the Hercules ssd console command?
Harold Grovesteen
Post by William Carroll
The point of a SIGTERM is for the process to shutdown cleanly
as
Post by u4gh
you
Post by Harold Grovesteen
Post by William Carroll
state.
If that process does not include notification of the guest OS
to
Post by u4gh
Post by Harold Grovesteen
Post by William Carroll
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown IMHO
I've not seen Linux behave the way described either. issue a
SIGTERM at
Post by Harold Grovesteen
Post by William Carroll
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an
enterprise.
Post by u4gh
Data
Post by Harold Grovesteen
Post by William Carroll
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
Keven Tipping
2008-09-07 01:50:18 UTC
Permalink
You've sort of lost me?

What is the Hercules definition file? The configuration file passed to
hercules as -f <myfile.cnf>?

-KT
Post by Mike Schwab
It gets the signal name and file name out of the hercules definition file.
You could even write a script on the fly (sample: $temp.rc) then issue
the SIGNAL $temp and it would be executed.
Post by Keven Tipping
You could do that, but then you're hardcoding the file names. The
only
Post by Keven Tipping
problem with this that I can see is if you have a guest OS system
that's moved between platforms- you'd have to have a file named
SHUTDOWN (assuming that's the alias for WM_ENDSESSION &&
CTRL_SHUTDOWN_EVENT) and a file named SIGTERM for Linux. I guess
ultimately it wouldn't matter, but I would rather leave the script
naming up to the user.
At this point in time, I've revised the SIGNAL config to the
SIGNAL SIGTERM SHUTDOWN -rc ./path/to/my/shutdown.rc
Essentially, this allows you to define more then one signal to a
single script. The above line would work on Windows or Linux
(assuming
Post by Keven Tipping
Fish ports what I've written to MSVC), since SIGTERM would simply be
ignored on Win32 and visa versa.
I've also added a hercules CLI command ("signal") to manage 'sig
handling via the command line. The basic usage is "signal
list" (show
Post by Keven Tipping
defined signal triggers), "signal del SIGXYZ" (delete signal trigger
for SIGXYZ), and "signal add SIGXYZ /path/to/shutdown.rc" (add an RC
script for SIGXYZ).
-KT
Post by Mike Schwab
Instead of having to define every signal and the file in the
Herucles
Post by Keven Tipping
Post by Mike Schwab
configuration file,
could a signal statement define the directory where the files
are, and
Post by Keven Tipping
Post by Mike Schwab
the signal type will be used as the filename.
SIGNAL /home/User/zVM/
- Or the W32 variant, according to Fish -
SIGNAL C:\Hercules\zVM\
and the directory would contain filenames SIGTERM, SHUTDOWN,
RUNPDPCLIB, $TEMP, or whatever you want?
What I'm getting from this is that things vary depending on the
host
Post by Keven Tipping
Post by Mike Schwab
OS and guest OS. So we need some way to deal with this.
What I'd prepose then, is something like the following line in
the
Post by Keven Tipping
Post by Mike Schwab
SIGNAL SIGTERM /home/User/zVM/zvm_shutdown.rc
- Or the W32 variant, according to Fish -
SIGNAL SHUTDOWN C:\Hercules\zVM\zvm_shutdown.rc
This basically tells Hercules that, when it receives a SIGNAL of
type
SIGTERM, it should run the panel commands found in ./zvm-
shutdown.rc
Post by Keven Tipping
Post by Mike Schwab
Hercules.rc).
Since HAO is programmable from the panel, you could in theory
write a
*.rc script that hooks into HAO as well, if that's required.
If no SIGNAL setting is found in the Hercules configuration, then
just
assume SIGTERM (Linux) and CTRL_SHUTDOWN_EVENT (W32) is the
equivalent
to calling do_shutdown() and be done with it.
The SIGNAL setting would by definition NOT be "shutdown only".
Under
Post by Keven Tipping
Post by Mike Schwab
Linux, there's a /lot/ of different signals to send at a process.
You
could use SIGNAL to define a script to run when Hercules receives
other signals- for doing other various tasks as well. These could
hook
into a Linux service script to do a variety of tasks under the
host OS
and guest OS.
This seems like the "proper" way to implement it, IMHO.
Everyone is
Post by Keven Tipping
Post by Mike Schwab
happy and nothing is really hardcoded.
-KT
Post by u4gh
Linux shutdown works like this (with some variation of labels
and
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
The 'K' scripts in the /etc/rc*.d are executed with the operand 'stop'.
Then, processes are sent SIGTERM, and after a delay, are sent
SIGKILL.
Post by u4gh
You don't need to wait for the SIGTERM to arrive. The start/stop
script in /etc/init.d (that is linked to the 'Snn' and 'Knn'
files in
Post by u4gh
the /etc/rc*.d directories) can do whatever is necessary to
convince
Post by u4gh
Hercules to safely shut down the guest OSes and quiesce itself
and
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
shut down.
Basically, the startup/shutdown script in /etc/init.d needs to
do
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
everything necessary to properly start and stop Hercules. It's
quite
Post by u4gh
/sbin/service hercules stop
or
/sbin/service hercules restart
while the system is running, to get the service 'hercules' to
either
Post by u4gh
stop or completely restart. All that happens during shutdown is
that
Post by u4gh
Linux calls each of these scripts in turn (the Knn prefix
determines
Post by u4gh
the order) and then issues SIGTERM to whatever is left, if the
shutdown script didn't do the job - and then SIGKILL if SIGTERM
wasn't
Post by u4gh
enough.
So, you can use whatever method that you want to shut down your
guest
Post by u4gh
OSes by putting the routines into startup and shutdown scripts -
for
Post by u4gh
example, if you have VM/370 and MVS running as guests, you could
create three scripts in /etc/init.d, one for Hercules, and one
each
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
for the guest OSes. By giving them S/K numbers in the correct
order,
Post by u4gh
Hercules would start up before the guests, and the guests
would be
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
shut down before Hercules. The guest OSes don't need to even use
the
Post by u4gh
same startup/shutdown mechanisms - if you need to do it
differently
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
for each OS, just write different scripts.
This is the typical way in which services are normally
controlled
Post by Keven Tipping
Post by Mike Schwab
in
Post by u4gh
Linux, and gives you plenty of flexibility since you can even
trigger
Post by u4gh
different guest OS combinations to start up based on the Linux
'init'
Post by u4gh
state. Different distrubtions of Linux use the init states for
different purposes, but it is easy to alter the /etc/rc*.d files
(or
Post by u4gh
via the chkconfig command if your distro has it) to customise it
any
Post by u4gh
way that you want. You could have init state '3' mean just
Hercules
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
with no guests, and '4' or '5' mean 'with guest X' or with
guests
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
'X,Y, and Z'.
- Richard
Post by Harold Grovesteen
Doug,
Are you suggesting that in addition to properly handling the
Linux
Post by u4gh
Post by Harold Grovesteen
SIGTERM signal by Hercules, that this logic should also
issue a
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
signal
Post by Harold Grovesteen
shutdown service processor command as is done by hsscmd.c in
the
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
ssd_cmd
Post by Harold Grovesteen
function for the Hercules ssd console command?
Harold Grovesteen
Post by William Carroll
The point of a SIGTERM is for the process to shutdown
cleanly
Post by Keven Tipping
Post by Mike Schwab
as
Post by u4gh
you
Post by Harold Grovesteen
Post by William Carroll
state.
If that process does not include notification of the guest
OS
Post by Keven Tipping
Post by Mike Schwab
to
Post by u4gh
Post by Harold Grovesteen
Post by William Carroll
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown
IMHO
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
Post by Harold Grovesteen
Post by William Carroll
I've not seen Linux behave the way described either. issue a
SIGTERM at
Post by Harold Grovesteen
Post by William Carroll
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an
enterprise.
Post by u4gh
Data
Post by Harold Grovesteen
Post by William Carroll
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
[Non-text portions of this message have been removed]
Mike Schwab
2008-09-07 02:41:18 UTC
Permalink
Right now, you have to code your hercules configuration file with a line like
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
SIGNAL SIGTERM SHUTDOWN -rc ./path/to/my/shutdown.rc
that includes both signal names and the script file name.

My suggestion is to take out the signal names and the script file name
and just name a directory for scripts.
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
SIGNAL xxxxxxxxxx xxxxxxxx -rc ./path/to/my/xxxxxxxxx.rc
When a signal name shutdown is received, the shutdown.rc file is run
When a signal name sigterm is received, the sigterm.rc file is run.
When a signal name abcxyz is received, the abcxyz.rc file is run.
Post by Keven Tipping
You've sort of lost me?
What is the Hercules definition file? The configuration file passed to
hercules as -f <myfile.cnf>?
-KT
Post by Mike Schwab
It gets the signal name and file name out of the hercules definition file.
You could even write a script on the fly (sample: $temp.rc) then issue
the SIGNAL $temp and it would be executed.
Post by Keven Tipping
You could do that, but then you're hardcoding the file names. The
only
Post by Keven Tipping
problem with this that I can see is if you have a guest OS system
that's moved between platforms- you'd have to have a file named
SHUTDOWN (assuming that's the alias for WM_ENDSESSION &&
CTRL_SHUTDOWN_EVENT) and a file named SIGTERM for Linux. I guess
ultimately it wouldn't matter, but I would rather leave the script
naming up to the user.
At this point in time, I've revised the SIGNAL config to the
SIGNAL SIGTERM SHUTDOWN -rc ./path/to/my/shutdown.rc
Essentially, this allows you to define more then one signal to a
single script. The above line would work on Windows or Linux
(assuming
Post by Keven Tipping
Fish ports what I've written to MSVC), since SIGTERM would simply be
ignored on Win32 and visa versa.
I've also added a hercules CLI command ("signal") to manage 'sig
handling via the command line. The basic usage is "signal
list" (show
Post by Keven Tipping
defined signal triggers), "signal del SIGXYZ" (delete signal trigger
for SIGXYZ), and "signal add SIGXYZ /path/to/shutdown.rc" (add an RC
script for SIGXYZ).
-KT
Post by Mike Schwab
Instead of having to define every signal and the file in the
Herucles
Post by Keven Tipping
Post by Mike Schwab
configuration file,
could a signal statement define the directory where the files
are, and
Post by Keven Tipping
Post by Mike Schwab
the signal type will be used as the filename.
SIGNAL /home/User/zVM/
- Or the W32 variant, according to Fish -
SIGNAL C:\Hercules\zVM\
and the directory would contain filenames SIGTERM, SHUTDOWN,
RUNPDPCLIB, $TEMP, or whatever you want?
What I'm getting from this is that things vary depending on the
host
Post by Keven Tipping
Post by Mike Schwab
OS and guest OS. So we need some way to deal with this.
What I'd prepose then, is something like the following line in
the
Post by Keven Tipping
Post by Mike Schwab
SIGNAL SIGTERM /home/User/zVM/zvm_shutdown.rc
- Or the W32 variant, according to Fish -
SIGNAL SHUTDOWN C:\Hercules\zVM\zvm_shutdown.rc
This basically tells Hercules that, when it receives a SIGNAL of
type
SIGTERM, it should run the panel commands found in ./zvm-
shutdown.rc
Post by Keven Tipping
Post by Mike Schwab
Hercules.rc).
Since HAO is programmable from the panel, you could in theory
write a
*.rc script that hooks into HAO as well, if that's required.
If no SIGNAL setting is found in the Hercules configuration, then
just
assume SIGTERM (Linux) and CTRL_SHUTDOWN_EVENT (W32) is the
equivalent
to calling do_shutdown() and be done with it.
The SIGNAL setting would by definition NOT be "shutdown only".
Under
Post by Keven Tipping
Post by Mike Schwab
Linux, there's a /lot/ of different signals to send at a process.
You
could use SIGNAL to define a script to run when Hercules receives
other signals- for doing other various tasks as well. These could
hook
into a Linux service script to do a variety of tasks under the
host OS
and guest OS.
This seems like the "proper" way to implement it, IMHO.
Everyone is
Post by Keven Tipping
Post by Mike Schwab
happy and nothing is really hardcoded.
-KT
Post by u4gh
Linux shutdown works like this (with some variation of labels
and
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
The 'K' scripts in the /etc/rc*.d are executed with the operand 'stop'.
Then, processes are sent SIGTERM, and after a delay, are sent
SIGKILL.
Post by u4gh
You don't need to wait for the SIGTERM to arrive. The start/stop
script in /etc/init.d (that is linked to the 'Snn' and 'Knn'
files in
Post by u4gh
the /etc/rc*.d directories) can do whatever is necessary to
convince
Post by u4gh
Hercules to safely shut down the guest OSes and quiesce itself
and
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
shut down.
Basically, the startup/shutdown script in /etc/init.d needs to
do
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
everything necessary to properly start and stop Hercules. It's
quite
Post by u4gh
/sbin/service hercules stop
or
/sbin/service hercules restart
while the system is running, to get the service 'hercules' to
either
Post by u4gh
stop or completely restart. All that happens during shutdown is
that
Post by u4gh
Linux calls each of these scripts in turn (the Knn prefix
determines
Post by u4gh
the order) and then issues SIGTERM to whatever is left, if the
shutdown script didn't do the job - and then SIGKILL if SIGTERM
wasn't
Post by u4gh
enough.
So, you can use whatever method that you want to shut down your
guest
Post by u4gh
OSes by putting the routines into startup and shutdown scripts -
for
Post by u4gh
example, if you have VM/370 and MVS running as guests, you could
create three scripts in /etc/init.d, one for Hercules, and one
each
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
for the guest OSes. By giving them S/K numbers in the correct
order,
Post by u4gh
Hercules would start up before the guests, and the guests
would be
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
shut down before Hercules. The guest OSes don't need to even use
the
Post by u4gh
same startup/shutdown mechanisms - if you need to do it
differently
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
for each OS, just write different scripts.
This is the typical way in which services are normally
controlled
Post by Keven Tipping
Post by Mike Schwab
in
Post by u4gh
Linux, and gives you plenty of flexibility since you can even
trigger
Post by u4gh
different guest OS combinations to start up based on the Linux
'init'
Post by u4gh
state. Different distrubtions of Linux use the init states for
different purposes, but it is easy to alter the /etc/rc*.d files
(or
Post by u4gh
via the chkconfig command if your distro has it) to customise it
any
Post by u4gh
way that you want. You could have init state '3' mean just
Hercules
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
with no guests, and '4' or '5' mean 'with guest X' or with
guests
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
'X,Y, and Z'.
- Richard
Post by Harold Grovesteen
Doug,
Are you suggesting that in addition to properly handling the
Linux
Post by u4gh
Post by Harold Grovesteen
SIGTERM signal by Hercules, that this logic should also
issue a
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
signal
Post by Harold Grovesteen
shutdown service processor command as is done by hsscmd.c in
the
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
ssd_cmd
Post by Harold Grovesteen
function for the Hercules ssd console command?
Harold Grovesteen
Post by William Carroll
The point of a SIGTERM is for the process to shutdown
cleanly
Post by Keven Tipping
Post by Mike Schwab
as
Post by u4gh
you
Post by Harold Grovesteen
Post by William Carroll
state.
If that process does not include notification of the guest
OS
Post by Keven Tipping
Post by Mike Schwab
to
Post by u4gh
Post by Harold Grovesteen
Post by William Carroll
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown
IMHO
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
Post by Harold Grovesteen
Post by William Carroll
I've not seen Linux behave the way described either. issue a
SIGTERM at
Post by Harold Grovesteen
Post by William Carroll
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an
enterprise.
Post by u4gh
Data
Post by Harold Grovesteen
Post by William Carroll
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
Keven Tipping
2008-09-07 02:43:38 UTC
Permalink
Hmm, okay...

I'll probably do it the original way I had it running then:
SIGNAL SIGTERM /path/to/shutdown.rc

But if there's no signal definition (ie, no SIGTERM/whatever):
SIGNAL /path/to/shutdown/scripts

Then it will attempt to load the signal name (ie, SIGTERM.rc) in the
directory specified (/path/to/shutdown/scripts/SIGTERM.rc).

-KT
Post by Mike Schwab
Right now, you have to code your hercules configuration file with a line like
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
SIGNAL SIGTERM SHUTDOWN -rc ./path/to/my/shutdown.rc
that includes both signal names and the script file name.
My suggestion is to take out the signal names and the script file name
and just name a directory for scripts.
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
SIGNAL xxxxxxxxxx xxxxxxxx -rc ./path/to/my/xxxxxxxxx.rc
When a signal name shutdown is received, the shutdown.rc file is run
When a signal name sigterm is received, the sigterm.rc file is run.
When a signal name abcxyz is received, the abcxyz.rc file is run.
Post by Keven Tipping
You've sort of lost me?
What is the Hercules definition file? The configuration file
passed to
Post by Keven Tipping
hercules as -f <myfile.cnf>?
-KT
Post by Mike Schwab
It gets the signal name and file name out of the hercules
definition
Post by Keven Tipping
Post by Mike Schwab
file.
You could even write a script on the fly (sample: $temp.rc) then
issue
Post by Keven Tipping
Post by Mike Schwab
the SIGNAL $temp and it would be executed.
Post by Keven Tipping
You could do that, but then you're hardcoding the file names. The
only
Post by Keven Tipping
problem with this that I can see is if you have a guest OS system
that's moved between platforms- you'd have to have a file named
SHUTDOWN (assuming that's the alias for WM_ENDSESSION &&
CTRL_SHUTDOWN_EVENT) and a file named SIGTERM for Linux. I guess
ultimately it wouldn't matter, but I would rather leave the
script
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
naming up to the user.
At this point in time, I've revised the SIGNAL config to the
SIGNAL SIGTERM SHUTDOWN -rc ./path/to/my/shutdown.rc
Essentially, this allows you to define more then one signal to a
single script. The above line would work on Windows or Linux
(assuming
Post by Keven Tipping
Fish ports what I've written to MSVC), since SIGTERM would
simply be
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
ignored on Win32 and visa versa.
I've also added a hercules CLI command ("signal") to manage 'sig
handling via the command line. The basic usage is "signal
list" (show
Post by Keven Tipping
defined signal triggers), "signal del SIGXYZ" (delete signal
trigger
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
for SIGXYZ), and "signal add SIGXYZ /path/to/shutdown.rc" (add
an RC
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
script for SIGXYZ).
-KT
Post by Mike Schwab
Instead of having to define every signal and the file in the
Herucles
Post by Keven Tipping
Post by Mike Schwab
configuration file,
could a signal statement define the directory where the files
are, and
Post by Keven Tipping
Post by Mike Schwab
the signal type will be used as the filename.
SIGNAL /home/User/zVM/
- Or the W32 variant, according to Fish -
SIGNAL C:\Hercules\zVM\
and the directory would contain filenames SIGTERM, SHUTDOWN,
RUNPDPCLIB, $TEMP, or whatever you want?
On Sat, Sep 6, 2008 at 4:03 PM, Keven Tipping
What I'm getting from this is that things vary depending on
the
Post by Keven Tipping
Post by Mike Schwab
host
Post by Keven Tipping
Post by Mike Schwab
OS and guest OS. So we need some way to deal with this.
What I'd prepose then, is something like the following line in
the
Post by Keven Tipping
Post by Mike Schwab
SIGNAL SIGTERM /home/User/zVM/zvm_shutdown.rc
- Or the W32 variant, according to Fish -
SIGNAL SHUTDOWN C:\Hercules\zVM\zvm_shutdown.rc
This basically tells Hercules that, when it receives a
SIGNAL of
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
type
SIGTERM, it should run the panel commands found in ./zvm-
shutdown.rc
Post by Keven Tipping
Post by Mike Schwab
Hercules.rc).
Since HAO is programmable from the panel, you could in theory
write a
*.rc script that hooks into HAO as well, if that's required.
If no SIGNAL setting is found in the Hercules configuration,
then
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
just
assume SIGTERM (Linux) and CTRL_SHUTDOWN_EVENT (W32) is the
equivalent
to calling do_shutdown() and be done with it.
The SIGNAL setting would by definition NOT be "shutdown only".
Under
Post by Keven Tipping
Post by Mike Schwab
Linux, there's a /lot/ of different signals to send at a
process.
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
You
could use SIGNAL to define a script to run when Hercules
receives
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
other signals- for doing other various tasks as well. These
could
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
hook
into a Linux service script to do a variety of tasks under the
host OS
and guest OS.
This seems like the "proper" way to implement it, IMHO.
Everyone is
Post by Keven Tipping
Post by Mike Schwab
happy and nothing is really hardcoded.
-KT
Post by u4gh
Linux shutdown works like this (with some variation of labels
and
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
The 'K' scripts in the /etc/rc*.d are executed with the
operand
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
'stop'.
Then, processes are sent SIGTERM, and after a delay, are sent
SIGKILL.
Post by u4gh
You don't need to wait for the SIGTERM to arrive. The start/
stop
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
script in /etc/init.d (that is linked to the 'Snn' and 'Knn'
files in
Post by u4gh
the /etc/rc*.d directories) can do whatever is necessary to
convince
Post by u4gh
Hercules to safely shut down the guest OSes and quiesce
itself
Post by Keven Tipping
Post by Mike Schwab
and
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
shut down.
Basically, the startup/shutdown script in /etc/init.d needs
to
Post by Keven Tipping
Post by Mike Schwab
do
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
everything necessary to properly start and stop Hercules.
It's
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
quite
Post by u4gh
/sbin/service hercules stop
or
/sbin/service hercules restart
while the system is running, to get the service 'hercules' to
either
Post by u4gh
stop or completely restart. All that happens during
shutdown is
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
that
Post by u4gh
Linux calls each of these scripts in turn (the Knn prefix
determines
Post by u4gh
the order) and then issues SIGTERM to whatever is left, if
the
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
shutdown script didn't do the job - and then SIGKILL if
SIGTERM
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
wasn't
Post by u4gh
enough.
So, you can use whatever method that you want to shut down
your
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
guest
Post by u4gh
OSes by putting the routines into startup and shutdown
scripts -
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
for
Post by u4gh
example, if you have VM/370 and MVS running as guests, you
could
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
create three scripts in /etc/init.d, one for Hercules, and
one
Post by Keven Tipping
Post by Mike Schwab
each
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
for the guest OSes. By giving them S/K numbers in the correct
order,
Post by u4gh
Hercules would start up before the guests, and the guests
would be
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
shut down before Hercules. The guest OSes don't need to
even use
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
the
Post by u4gh
same startup/shutdown mechanisms - if you need to do it
differently
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
for each OS, just write different scripts.
This is the typical way in which services are normally
controlled
Post by Keven Tipping
Post by Mike Schwab
in
Post by u4gh
Linux, and gives you plenty of flexibility since you can even
trigger
Post by u4gh
different guest OS combinations to start up based on the
Linux
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
'init'
Post by u4gh
state. Different distrubtions of Linux use the init states
for
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
different purposes, but it is easy to alter the /etc/rc*.d
files
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
(or
Post by u4gh
via the chkconfig command if your distro has it) to
customise it
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
any
Post by u4gh
way that you want. You could have init state '3' mean just
Hercules
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
with no guests, and '4' or '5' mean 'with guest X' or with
guests
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
'X,Y, and Z'.
- Richard
Post by Harold Grovesteen
Doug,
Are you suggesting that in addition to properly handling
the
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
Linux
Post by u4gh
Post by Harold Grovesteen
SIGTERM signal by Hercules, that this logic should also
issue a
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
signal
Post by Harold Grovesteen
shutdown service processor command as is done by hsscmd.c
in
Post by Keven Tipping
Post by Mike Schwab
the
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
ssd_cmd
Post by Harold Grovesteen
function for the Hercules ssd console command?
Harold Grovesteen
Post by William Carroll
The point of a SIGTERM is for the process to shutdown
cleanly
Post by Keven Tipping
Post by Mike Schwab
as
Post by u4gh
you
Post by Harold Grovesteen
Post by William Carroll
state.
If that process does not include notification of the
guest
Post by Keven Tipping
Post by Mike Schwab
OS
Post by Keven Tipping
Post by Mike Schwab
to
Post by u4gh
Post by Harold Grovesteen
Post by William Carroll
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown
IMHO
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
Post by Harold Grovesteen
Post by William Carroll
I've not seen Linux behave the way described either.
issue a
Post by Keven Tipping
Post by Mike Schwab
Post by Keven Tipping
Post by Mike Schwab
Post by u4gh
SIGTERM at
Post by Harold Grovesteen
Post by William Carroll
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an
enterprise.
Post by u4gh
Data
Post by Harold Grovesteen
Post by William Carroll
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
[Non-text portions of this message have been removed]
u4gh
2008-09-07 19:03:57 UTC
Permalink
You definitely want to have a mechanism to accept signals other than
SIGTERM, as it would be useful to perform different operations based
on the signals. The following signals are the most commonly used in
Linux/Unix land:

SIGKILL - not trappable, stop the task right now.
SIGTERM - trappable, stop the task after cleanup.

The rest are more user definable:

SIGHUP - Originally 'Hang up the phone'. It used now for either 'stop
the task more gracefully than SIGTERM', or 'reread your configuration
files and continue'. Can actually be used for whatever you like.
SIGINT - Interrupt - sort of like the interrupt key on the front of a
mainframe. Can be used for whatever you like.
SIGUSR1 - Can be used for whatever you like.
SIGUSR2 - Can be used for whatever you like.

You basically end up with four user defined interrupts. Note that this
is a pretty limited set of functionality, you can't pass commands or
operands, just kick the task into waking up and doing something.

This is typically all that is needed for 'refresh my config' or 'shut
me down gently' or 'dump a debug print to a file or the console'. For
more complex interaction it would be better to have an API that
external programs can communicate with. Such an API would also be
cross-platform compatible.

There's been a suggestion to implement a Telnet interface - why not
make it a full RPC/API instead? There are several models for such
interfaces, such as the POP/IMAP model and SOAP/XML. The advantage of
such a programmed interface is that if an external program is being
used to communicate, rather than a human typing at a keyboard, the
protocol is rigid enough to get deterministic results.

e.g., using a POP model, the exchange would look something like:

-> user xxxxx
<- 100 send password
-> password yyyy
<- 200 success
-> show guests
<- 201 vm370
<- 201 mvs2
<- 201 zOS1
<- 200 success
-> shutdown guest mvs1
<- 300 no such guest
-> shutdown guest vm370
<- 200 success
-> show guests
<- 201 mvs2
<- 201 zOS1
<- 200 success
-> quit
<- 400 bye!

SOAP with XML gives a much richer remote procedure call interface, but
is also more complex, and the POP model gives something that is also
human readable for when you just want to type a few quick commands in
manually. You simply telnet to the port, and type in the '->' lines
above. (The human is welcome to ignore the return code numbers. :-) It
is also very easy to write programs that interact with the interface
without having to parse the words - you just send commands and look
for the numeric return codes (although you might print out or log the
words that follow).

This provides a platform-independent model for interaction, and means
that for Linux you could have a series of startup/shutdown scripts for
each guest and another for Hercules itself, and on Windows you could
create 'services' to do the same.

It's been a long time since I've worked on mainframes, but Linux
systems administration is part of my current job (as well as a hobby
:-), and I'm willing to help out with this effort.

It would truly be neat to have Hercules start up and shut down like a
service and have the guest OSes do the same. This would be an analog
to VMware ESX, rather than VMware Workstation (which is about how
Hercules works now). This brings Hercules closer to the 'appliance'
that was being asked for.

Another added feature would be remote enterprise-class monitoring
using SNMP...

- Richard
Post by Keven Tipping
Hmm, okay...
SIGNAL SIGTERM /path/to/shutdown.rc
SIGNAL /path/to/shutdown/scripts
Then it will attempt to load the signal name (ie, SIGTERM.rc) in the
directory specified (/path/to/shutdown/scripts/SIGTERM.rc).
-KT
Post by Mike Schwab
Right now, you have to code your hercules configuration file with a line like
Post by Keven Tipping
SIGNAL SIGTERM SHUTDOWN -rc ./path/to/my/shutdown.rc
that includes both signal names and the script file name.
My suggestion is to take out the signal names and the script file name
and just name a directory for scripts.
Post by Keven Tipping
SIGNAL xxxxxxxxxx xxxxxxxx -rc ./path/to/my/xxxxxxxxx.rc
When a signal name shutdown is received, the shutdown.rc file is run
When a signal name sigterm is received, the sigterm.rc file is run.
When a signal name abcxyz is received, the abcxyz.rc file is run.
Roger Bowler
2008-09-07 20:00:10 UTC
Permalink
Post by u4gh
There's been a suggestion to implement a Telnet interface - why not
make it a full RPC/API instead? There are several models for such
interfaces, such as the POP/IMAP model and SOAP/XML. The advantage of
such a programmed interface is that if an external program is being
used to communicate, rather than a human typing at a keyboard, the
protocol is rigid enough to get deterministic results.
This sounds a reasonable idea. But can I make a plea that it should *not*
be based on XML? I'm not going to put forward any rational reason for that
(I'm sure there are plenty of arguments for and against!), it's just a
feeling that XML is alien to the mainframe way of doing things. I like to
see Hercules as a bastion of the "mainframe way" wherever possible.
--
Cordialement,
Roger Bowler
http://perso.wanadoo.fr/rbowler
Hercules "the people's mainframe"
u4gh
2008-09-07 20:20:59 UTC
Permalink
Post by Roger Bowler
Post by u4gh
There's been a suggestion to implement a Telnet interface - why not
make it a full RPC/API instead? There are several models for such
interfaces, such as the POP/IMAP model and SOAP/XML. The advantage of
such a programmed interface is that if an external program is being
used to communicate, rather than a human typing at a keyboard, the
protocol is rigid enough to get deterministic results.
This sounds a reasonable idea. But can I make a plea that it should *not*
be based on XML? I'm not going to put forward any rational reason for that
(I'm sure there are plenty of arguments for and against!), it's just a
feeling that XML is alien to the mainframe way of doing things. I like to
see Hercules as a bastion of the "mainframe way" wherever possible.
--
Cordialement,
Roger Bowler
http://perso.wanadoo.fr/rbowler
Hercules "the people's mainframe"
Well, there is: <http://www-03.ibm.com/servers/eserver/zseries/zos/xml/>

and zLinux certainly has XML within it.

Using SOAP, you never really have to see or touch the XML, it's just
an encoding technique used to by the transport mechanism for the
remote procedure calls.

However, I understand the reticence - and a reasonable argument would
be that the bulk of the mainframe folk aren't familiar with XML and
would be less likely to be able to contribute to the effort.

Also, the 'POP-like' approach is fine for simpler interfaces and does
make it practical to interact manually when necessary, which
definitely is not practical with XML-encoded interfaces like SOAP. To
me it seemed to be a good compromise between easy-to-program client
code and mainframe-like simplicity of command structure and usability,
which is why I recommended it.

To get *really* mainframe-like, we *could* go with a bisync protocol
complete with EBCDIC control characters. I do remember emulating a
2780 on a protocol analyser back in the late '70s... Anyone still
speak Model 20? :-)

- Richard
peter_flass
2008-09-09 10:52:19 UTC
Permalink
Post by Martin T2..
Post by Roger Bowler
Post by u4gh
There's been a suggestion to implement a Telnet interface - why not
make it a full RPC/API instead? There are several models for such
interfaces, such as the POP/IMAP model and SOAP/XML. The
advantage of
Post by Martin T2..
Post by Roger Bowler
Post by u4gh
such a programmed interface is that if an external program is being
used to communicate, rather than a human typing at a keyboard, the
protocol is rigid enough to get deterministic results.
This sounds a reasonable idea. But can I make a plea that it should
*not*
Post by Roger Bowler
be based on XML? I'm not going to put forward any rational reason
for that
Post by Roger Bowler
(I'm sure there are plenty of arguments for and against!), it's just a
feeling that XML is alien to the mainframe way of doing things. I
like to
Post by Roger Bowler
see Hercules as a bastion of the "mainframe way" wherever possible.
--
Cordialement,
Roger Bowler
http://perso.wanadoo.fr/rbowler
Hercules "the people's mainframe"
Well, there is: <http://www-03.ibm.com/servers/eserver/zseries/zos/xml/>
and zLinux certainly has XML within it.
Using SOAP, you never really have to see or touch the XML, it's just
an encoding technique used to by the transport mechanism for the
remote procedure calls.
However, I understand the reticence - and a reasonable argument would
be that the bulk of the mainframe folk aren't familiar with XML and
would be less likely to be able to contribute to the effort.
Also, the 'POP-like' approach is fine for simpler interfaces and does
make it practical to interact manually when necessary, which
definitely is not practical with XML-encoded interfaces like SOAP. To
me it seemed to be a good compromise between easy-to-program client
code and mainframe-like simplicity of command structure and usability,
which is why I recommended it.
To get *really* mainframe-like, we *could* go with a bisync protocol
complete with EBCDIC control characters. I do remember emulating a
2780 on a protocol analyser back in the late '70s... Anyone still
speak Model 20? :-)
- Richard
Actually, XML is the exact opposite of "alien to the mainframe way of
doing things."

XML is a minor extension of GML, which was first developed for Script
on the mainframe. GML became SGML and was then borrowed for HTML and
then XML, but it's all in the family.
Roger Bowler
2008-09-09 12:32:47 UTC
Permalink
Post by peter_flass
Actually, XML is the exact opposite of "alien to the mainframe
way of doing things." XML is a minor extension of GML, which was
first developed for Script on the mainframe. GML became SGML
and was then borrowed for HTML and then XML, but it's all in the
family.
I don't dispute XML's mainframe heritage, but GML is a document markup
language. That's not the way that classic mainframe applications store
or transmit data.

Regards,
Roger Bowler
Keven Tipping
2008-09-07 23:49:18 UTC
Permalink
Note that this... Kick the task into waking up and doing something
That's all sighandler is supposed to do.

The code I've got right now defines all the standard Linux signals
(about 31 in total) in a table at the beginning of sighandler.c. Among
other things, the table also defines a block flag for each signal-
which lets sighandler know if the signal is trapable or not (ie,
SIGKILL) and throw any warnings as a result of invalid configuration
lines.

The final form of the configuration lines in the hercules config is
basically either:
SIGNAL <signals> -rc <path_to_rc_file>
or
SIGNAL <signals> -exec <panel_command>

An example usage would be:
SIGNAL SIGTERM SIGUSR1 -rc /path/to/shutdown.rc
or
SIGNAL SIGINT -exec s+

You can define multiple signals to execute the same script (-rc) or
single panel command (-exec). The rc script path, when triggered by
either SIGTERM or SIGUSR1 (as above), is fed to process_script_file()
in hsccmd.c. The -exec option simply runs anything after -exec as a
panel command when SIGINT (as above) is triggered.

I added the -exec feature when I noticed impl.c was using SIGINT to
activate instruction stepping. I removed this code, and the equivalent
would be the above statement placed in the hercules config (executing s
+ when SIGINT is received).
Why not make it a full RPC/APU instead?... POP model...
Analogue to VMware ESX...
I'll take a look at that, unless you want to- as I'm working on
sighandler right now. My ultimate goal for the "telnet" server was
simple: 1) Let me log in either locally or remotely via Telnet to the
Hercules HMC, and 2) Allow the implementation of an API/command set to
serve as a foundation for splitting off the Ncurses GUI into it's own
network client. There's no reason this API could be more public
though, for use with other various tools and scripts as well.

VMware's ESX platform is actually where I wanted to eventually go with
all of this. I had errant thoughts of building a small (<64MB) Linux
distribution, sticking it on a USB flash drive (similar to ESX 3i or
ESXi, whatever they're calling it), and having it boot straight into
Hercules using EVMS for local storage management. Point being, it
could be distributed with cost-effective Core 2 Quad based servers for
a "poor man's mainframe".

But that's something for later, once sighandler and the new interface
are done.

-KT
You definitely want to have a mechanism to accept signals other than
SIGTERM, as it would be useful to perform different operations based
on the signals. The following signals are the most commonly used in
SIGKILL - not trappable, stop the task right now.
SIGTERM - trappable, stop the task after cleanup.
SIGHUP - Originally 'Hang up the phone'. It used now for either 'stop
the task more gracefully than SIGTERM', or 'reread your configuration
files and continue'. Can actually be used for whatever you like.
SIGINT - Interrupt - sort of like the interrupt key on the front of a
mainframe. Can be used for whatever you like.
SIGUSR1 - Can be used for whatever you like.
SIGUSR2 - Can be used for whatever you like.
You basically end up with four user defined interrupts. Note that this
is a pretty limited set of functionality, you can't pass commands or
operands, just kick the task into waking up and doing something.
This is typically all that is needed for 'refresh my config' or 'shut
me down gently' or 'dump a debug print to a file or the console'. For
more complex interaction it would be better to have an API that
external programs can communicate with. Such an API would also be
cross-platform compatible.
There's been a suggestion to implement a Telnet interface - why not
make it a full RPC/API instead? There are several models for such
interfaces, such as the POP/IMAP model and SOAP/XML. The advantage of
such a programmed interface is that if an external program is being
used to communicate, rather than a human typing at a keyboard, the
protocol is rigid enough to get deterministic results.
-> user xxxxx
<- 100 send password
-> password yyyy
<- 200 success
-> show guests
<- 201 vm370
<- 201 mvs2
<- 201 zOS1
<- 200 success
-> shutdown guest mvs1
<- 300 no such guest
-> shutdown guest vm370
<- 200 success
-> show guests
<- 201 mvs2
<- 201 zOS1
<- 200 success
-> quit
<- 400 bye!
SOAP with XML gives a much richer remote procedure call interface, but
is also more complex, and the POP model gives something that is also
human readable for when you just want to type a few quick commands in
manually. You simply telnet to the port, and type in the '->' lines
above. (The human is welcome to ignore the return code numbers. :-) It
is also very easy to write programs that interact with the interface
without having to parse the words - you just send commands and look
for the numeric return codes (although you might print out or log the
words that follow).
This provides a platform-independent model for interaction, and means
that for Linux you could have a series of startup/shutdown scripts for
each guest and another for Hercules itself, and on Windows you could
create 'services' to do the same.
It's been a long time since I've worked on mainframes, but Linux
systems administration is part of my current job (as well as a hobby
:-), and I'm willing to help out with this effort.
It would truly be neat to have Hercules start up and shut down like a
service and have the guest OSes do the same. This would be an analog
to VMware ESX, rather than VMware Workstation (which is about how
Hercules works now). This brings Hercules closer to the 'appliance'
that was being asked for.
Another added feature would be remote enterprise-class monitoring
using SNMP...
- Richard
Post by Keven Tipping
Hmm, okay...
SIGNAL SIGTERM /path/to/shutdown.rc
SIGNAL /path/to/shutdown/scripts
Then it will attempt to load the signal name (ie, SIGTERM.rc) in the
directory specified (/path/to/shutdown/scripts/SIGTERM.rc).
-KT
Post by Mike Schwab
Right now, you have to code your hercules configuration file
with a
Post by Keven Tipping
Post by Mike Schwab
line like
Post by Keven Tipping
SIGNAL SIGTERM SHUTDOWN -rc ./path/to/my/shutdown.rc
that includes both signal names and the script file name.
My suggestion is to take out the signal names and the script
file name
Post by Keven Tipping
Post by Mike Schwab
and just name a directory for scripts.
Post by Keven Tipping
SIGNAL xxxxxxxxxx xxxxxxxx -rc ./path/to/my/xxxxxxxxx.rc
When a signal name shutdown is received, the shutdown.rc file is
run
Post by Keven Tipping
Post by Mike Schwab
When a signal name sigterm is received, the sigterm.rc file is
run.
Post by Keven Tipping
Post by Mike Schwab
When a signal name abcxyz is received, the abcxyz.rc file is run.
[Non-text portions of this message have been removed]
Tim Pinkawa
2008-09-08 00:29:58 UTC
Permalink
Post by u4gh
There's been a suggestion to implement a Telnet interface - why not
make it a full RPC/API instead? There are several models for such
interfaces, such as the POP/IMAP model and SOAP/XML. The advantage of
such a programmed interface is that if an external program is being
used to communicate, rather than a human typing at a keyboard, the
protocol is rigid enough to get deterministic results.
It would be interesting to look at XML-RPC[1]. I think for the scope
of Hercules, XML-RPC can handle most of the required tasks and is more
lightweight than full-blown SOAP. A huge boon is that since Hercules
already implements an HTTP server, XML-RPC can be added fairly easily
as a loadable module (HDL). I've been looking at some various XML-RPC
libraries and would be interested in giving it a shot. Does anyone
have experience building HDL modules? I looked over the README.HDL
file and that makes sense, but I haven't been able to figure out how
to actually compile the code (with gcc on Linux) and get it into a
format Hercules recognizes.

Tim

[1] http://www.xmlrpc.com/spec
William Carroll
2008-09-06 21:45:18 UTC
Permalink
Kevin that seems like a great way to do it to me.
Very clean and keeps the shutdown in the users hands which is what I
personally prefer.

Doug
Post by Keven Tipping
What I'm getting from this is that things vary depending on the host
OS and guest OS. So we need some way to deal with this.
What I'd prepose then, is something like the following line in the
SIGNAL SIGTERM /home/User/zVM/zvm_shutdown.rc
- Or the W32 variant, according to Fish -
SIGNAL SHUTDOWN C:\Hercules\zVM\zvm_shutdown.rc
This basically tells Hercules that, when it receives a SIGNAL of type
SIGTERM, it should run the panel commands found in ./zvm-shutdown.rc
Since HAO is programmable from the panel, you could in theory write a
*.rc script that hooks into HAO as well, if that's required.
If no SIGNAL setting is found in the Hercules configuration, then just
assume SIGTERM (Linux) and CTRL_SHUTDOWN_EVENT (W32) is the equivalent
to calling do_shutdown() and be done with it.
The SIGNAL setting would by definition NOT be "shutdown only". Under
Linux, there's a /lot/ of different signals to send at a process. You
could use SIGNAL to define a script to run when Hercules receives
other signals- for doing other various tasks as well. These could hook
into a Linux service script to do a variety of tasks under the host OS
and guest OS.
This seems like the "proper" way to implement it, IMHO. Everyone is
happy and nothing is really hardcoded.
-KT
Post by u4gh
Linux shutdown works like this (with some variation of labels and
The 'K' scripts in the /etc/rc*.d are executed with the operand 'stop'.
Then, processes are sent SIGTERM, and after a delay, are sent SIGKILL.
You don't need to wait for the SIGTERM to arrive. The start/stop
script in /etc/init.d (that is linked to the 'Snn' and 'Knn' files in
the /etc/rc*.d directories) can do whatever is necessary to convince
Hercules to safely shut down the guest OSes and quiesce itself and
shut down.
Basically, the startup/shutdown script in /etc/init.d needs to do
everything necessary to properly start and stop Hercules. It's quite
/sbin/service hercules stop
or
/sbin/service hercules restart
while the system is running, to get the service 'hercules' to either
stop or completely restart. All that happens during shutdown is that
Linux calls each of these scripts in turn (the Knn prefix determines
the order) and then issues SIGTERM to whatever is left, if the
shutdown script didn't do the job - and then SIGKILL if SIGTERM wasn't
enough.
So, you can use whatever method that you want to shut down your guest
OSes by putting the routines into startup and shutdown scripts - for
example, if you have VM/370 and MVS running as guests, you could
create three scripts in /etc/init.d, one for Hercules, and one each
for the guest OSes. By giving them S/K numbers in the correct order,
Hercules would start up before the guests, and the guests would be
shut down before Hercules. The guest OSes don't need to even use the
same startup/shutdown mechanisms - if you need to do it differently
for each OS, just write different scripts.
This is the typical way in which services are normally controlled in
Linux, and gives you plenty of flexibility since you can even trigger
different guest OS combinations to start up based on the Linux 'init'
state. Different distrubtions of Linux use the init states for
different purposes, but it is easy to alter the /etc/rc*.d files (or
via the chkconfig command if your distro has it) to customise it any
way that you want. You could have init state '3' mean just Hercules
with no guests, and '4' or '5' mean 'with guest X' or with guests
'X,Y, and Z'.
- Richard
<mailto:hercules-390%40yahoogroups.com>, Harold Grovesteen
Post by u4gh
Post by Harold Grovesteen
Doug,
Are you suggesting that in addition to properly handling the Linux
SIGTERM signal by Hercules, that this logic should also issue a
signal
Post by Harold Grovesteen
shutdown service processor command as is done by hsscmd.c in the
ssd_cmd
Post by Harold Grovesteen
function for the Hercules ssd console command?
Harold Grovesteen
Post by William Carroll
The point of a SIGTERM is for the process to shutdown cleanly as
you
Post by Harold Grovesteen
Post by William Carroll
state.
If that process does not include notification of the guest OS to
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown IMHO
I've not seen Linux behave the way described either. issue a
SIGTERM at
Post by Harold Grovesteen
Post by William Carroll
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an enterprise.
Data
Post by Harold Grovesteen
Post by William Carroll
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
[Non-text portions of this message have been removed]
Marcin Cieslak
2008-09-09 12:53:49 UTC
Permalink
Post by Keven Tipping
As I said before- I want to enable Hercules so that it can run as a
INIT service on a dedicated Linux machine. That means Hercules is
started and stopped WITH the actual host computer itself.
In order to do this properly and not use the HTTP GUI, two things have
Why not?

What about this:

http://localhost:8081/cgi-bin/tasks/syslog?command=quit

I think you can also run a script or some other commands this way.
Hey, you don't even need to log in :)

--Marcin



[Non-text portions of this message have been removed]
Gilson Lasco
2008-09-09 15:33:02 UTC
Permalink
Post by Marcin Cieslak
Post by Keven Tipping
As I said before- I want to enable Hercules so that it can run as a
INIT service on a dedicated Linux machine. That means Hercules is
started and stopped WITH the actual host computer itself.
In order to do this properly and not use the HTTP GUI, two things have
Why not?
http://localhost:8081/cgi-bin/tasks/syslog?command=quit
I think you can also run a script or some other commands this way.
Hey, you don't even need to log in :)
Keven,

About a year ago, I wrote a small script to submit commands to Hercules
(running with -d).
Here it is:

#!/bin/bash
# hcmd.sh (sends cmd to Hercules)
# 10/21/2007 Author: Gilson Lasco
# copy to /usr/bin/hcmd & chmod ugoa=xrw hcmd

if [ "$1" == "" ]; then
echo "usage: hcmd command [operand operand ...]"
exit -1
fi

u=lasco # change to reflect your HTTPUSER
p=gilson # change to reflect your HTTPPASS

z="$1"
# change localhost:port as needed
url="localhost:8081/cgi-bin/tasks/syslog?command="

if [ "$2" != "" ]; then
z="$1+$2"
fi
if [ "$3" != "" ]; then
z="$1+$2+$3"
fi
if [ "$4" != "" ]; then
z="$1+$2+$3+$4"
fi
if [ "$5" != "" ]; then
z="$1+$2+$3+$4+$5"
fi

# remove the following if/fi if hcmd is remote to Hercules
if [ "$(pidof hercules)" == "" ]; then
echo "hercules is not up"
exit -1
fi

wget -q -O - --http-user=$u --http-password=$p $url$z \
|sed '1,/<PRE>/d'|sed '/<\/PRE>/,$d'
exit 0
#end

Save it as hcmd at /usr/bin etc..
then:
hcmd quit
This script will submit the command to Hercules and will return
the response to you, 22 lines of pure text, no browser, no windows,
or, as Roger Bowler says,
on the MVS way ;-)

Gilson Lasco





[Non-text portions of this message have been removed]
kerravon86
2008-09-05 14:11:19 UTC
Permalink
Post by Keven Tipping
1) Signal Handling
I'd like to add some sort of signal handling to Hercules so that I can
fire off signals at the process and have it *shut down gracefully* (as
in, running through the HHCxx9yyI messages).
Use Hercules' HAO facility, use an integrated console,
write to the console, and let a Hercules script do
the rest.

As Mike said, MVS/380 already does this:

http://mvs380.sourceforge.net

BFN. Paul.
Jim Pierson
2008-09-06 04:25:20 UTC
Permalink
Adding a SIGTERM handler to Hercules does very well. I have
a localmod to impl.c the implements SIGTERM and calls do_shutdown().
If the guest OS handles the service processor quiesce signal ( as
does most of the Linux's today ) then everything comes down clean.

I run Hercules as a service. The only gotcha is in the init.d
proc. You might want to specify a '-d' delay time in the call to
killproc to extend the timeout before SIGKILL gets sent.

(Note to the latest post from Kevin: RedHat and thus CentOS 5
have the -d parm to killproc. Doesn;t wait for the process to
actually go away... but does allow for the extension of time
before SIGKILL gets sent. Not sure about other dist's.)

Jim
-----Original Message-----
Sent: Friday, September 05, 2008 11:31 PM
Subject: Re: [hercules-390] Implementing new Herc features?
I was only quoting your 5-10sec example and using 10sec as an
example.
I have had processes take 5-10 min to shutdown so I have not
seen this
5-10sec shutdown
you mention. I personally do not want Linux Killing a process
because it
has not responded
in a short time. Data integrity comes to mind. I want them
to shutdown
properly and cleanly
I've already suggested what SIGTERM should do.
A method to pass to the guest OS to shutdown, The HMC does this, I've
watched VM shutdown because of a shutdown of the LPAR.
VM does not just die. it shutdown. Passing this via Hercules
allows the
user to implement a guest shutdown.
if you don't' care about the guest os you don't implement it.
if you do
care you get your guest shutdown
properly then shutdown Hercules
And my argument is it does mater to the guest OS.
I"m not sorry you brought it up, it's a difference of
opinion on what
proper shutdown
means. To you the guest OS does not mater, to me it does.
Doug
Post by Keven Tipping
It was a simple job that took 10 seconds of writing and grepping
through some files. It's taken me much longer to explain my motives
here with the amount of confusion and effort this is generating.
What would you suggest then, in terms of SIGTERM handling?
90% of the time this is issued when a system is going down. You
yourself claim that a process has exactly 10 seconds to
comply before
Post by Keven Tipping
Linux fries the process with SIGKILL. You can't (AFAIK)
shut down z/VM
Post by Keven Tipping
or z/OS in 10 seconds. Ergo, such a beast should have been shut down
long before SIGTERM is even a priority.
This whole thing was simply a formality I wanted to correct. Most
processes have cleanup routines when exiting. Hercules has these in
the form of do_shutdown(). Therefore, hercules should *call* these
cleanup routines when it receives a SIGTERM. Once you've gotten a
SIGTERM from the Linux host going *down*, it doesn't matter if the
guest OS is running or not- the system is going down regardless of
what you were running where.
So much confusion and effort over 10 lines of code, in as many
seconds. I'm sorry I brought it up.
-KT
Post by William Carroll
The point of a SIGTERM is for the process to shutdown
cleanly as you
Post by Keven Tipping
Post by William Carroll
state.
If that process does not include notification of the guest OS to
shutdown then
what is the difference between it and a SIGKILL? NONE
A SIGTERM without guest shutdown is not a clean shutdown IMHO
I've not seen Linux behave the way described either.
issue a SIGTERM
Post by Keven Tipping
Post by William Carroll
at
shutdown and if not done in 10sec it KILLs the process.
If that was the case Linux would never make it in an
enterprise. Data
Post by Keven Tipping
Post by William Carroll
integrity
at shutdown would be poor.
am I misunderstanding this?
Doug
Post by Keven Tipping
Mr. Smith knows what I'm looking for- simply the ability to have
Hercules call do_shutdown() when it receives a SIGTERM
to clean up
Post by Keven Tipping
Post by William Carroll
and
Post by Keven Tipping
exit gracefully. IMHO, any guest OS's should have been shut down
long
Post by Keven Tipping
before Hercules receives a SIGTERM.
In 99% of all cases, if Hercules is being sent a
SIGTERM as a result
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
of the Linux computer going down, it has approximately 5-10
seconds to
Post by Keven Tipping
clean up and terminate. Anything past that and Linux
will send it a
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
SIGKILL, killing the Herc process forcefully.
As for the Telnet server...
Hercules already has this support built-in, in the form
of TN3270
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
support (which is Telnet, right?).
Would it be possible to modify this code- so that you could
specify a
Post by Keven Tipping
device that literally hooks up to the Hercules HMC over
a separate
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
port with a simple user/password? 3270 already supports
a basic ACL
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
list in the form of the device arguments, so that's good.
I guess the resulting configuration line would look
0000 HMC 127.0.0.1:23 -u myuser -p mypass
And this would basically tell Hercules- "Okay, let Telnet users
connect to Localhost on port 23, ask them for the username and
password, and if valid- connect them to the Hercules
command line
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
(HMC)"...
Would this be easier to implement then a completely
separate Telnet
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
server?
-KT
Post by Greg Smith
Post by Greg Smith
I suppose we need to come to some consensus what
signal(s) to
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
register,
Post by Greg Smith
but IMO it should be a signal linux (or whatever) issues to
processes
Post by Greg Smith
during shutdown.
On Debian it is the /etc/init.d/sendsigs script which
stops any
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
processes
still alive when it is called during a
shutdown/reboot procedure.
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
For a switch to single-user mode there is a slightly different
script
Post by Keven Tipping
Post by Greg Smith
/etc/init.d/killprocs.
* send SIGTERM (15) to all processes
* check if there are still active processes using SIGCONT (18)
* if there are none, break
* if there are, sleep for 1 second
* send SIGKILL (9) to remaining processes
This means that by default hercules (or any other process) has
only 10
Post by Keven Tipping
Post by Greg Smith
seconds to respond to the signal to shut down gracefully on a
Debian
Post by Keven Tipping
Post by Greg Smith
system, which may well not be enough to cleanly shut
down a guest
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
system.
The solution would probably be to give Hercules its own init
script
Post by Keven Tipping
Post by Greg Smith
that
runs earlier than these scripts and make sure that that script
waits
Post by Keven Tipping
Post by Greg Smith
and
delays the shutdown procedure while the signal is
being processed.
Post by Keven Tipping
Post by William Carroll
Post by Keven Tipping
Post by Greg Smith
Anyway, as far as I know SIGTERM would be the correct
signal to
Post by Keven Tipping
Post by William Carroll
use.
Post by Keven Tipping
Post by Greg Smith
Cheers,
FJP
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
Jim Pierson
2008-09-06 04:40:33 UTC
Permalink
-----Original Message-----
Sent: Friday, September 05, 2008 6:49 PM
Subject: Re: [hercules-390] Implementing new Herc features?
(SNIP)
I'm not sure of the status of signaling on Windows.
Windows is a whole different beast for shutdown. Though it's
nothing that Fish couldn't whip up in bootstrap.c to handle it.
Running Herc as a service on Windows would require a few more
routines... but nothing that would get too hairy. It wouldn't
surprise me if a few out there have written wrappers around
Hercules just for that purpose.
Fish
2008-09-06 12:36:22 UTC
Permalink
[...]
Post by Jim Pierson
Post by Greg Smith
I'm not sure of the status of signaling on Windows.
Windows is a whole different beast for shutdown. Though
it's nothing that Fish couldn't whip up in bootstrap.c
to handle it.
Would take a bit of effort but it's definitely doable.

We'd need to create an invisible window to capture the
WM_QUERYENDSESSION and WM_ENDSESSION messages Windows sends. Not hard
to do but something that does add a whole new level of complexity to
Hercules.[1][2]

To support running as a Windows service we'd need to install a
SetConsoleCtrlHandler to respond to the CTRL_LOGOFF_EVENT and
CTRL_SHUTDOWN_EVENT signals.[3]

Wouldn't hurt to have one anyway (SetConsoleCtrlHandler) even if
we're NOT running as a service so we could properly intercept/handle
the CTRL_CLOSE_EVENT and CTRL_C_EVENT signals to prevent someone from
accidentally killing Herc via pressing Ctrl+C and/or clicking the [X]
close box (which is still possible today).[4]
Post by Jim Pierson
Running Herc as a service on Windows would require a few
more routines... but nothing that would get too hairy.
Agreed. Not exactly trivial but relatively straightforward. Just lots
of grunt work to do it right.[5]
Post by Jim Pierson
It wouldn't surprise me if a few out there have written
wrappers around Hercules just for that purpose.
Indeed there are tools already in existence that will turn any
executable into a Windows service, but to do it properly the program
should be properly designed/written *AS* a service (or with service
capability/functionality).[6]

- --
"Fish" (David B. Trout) - fish(at)infidels.org
Fight Spam! Join CAUCE! <http://www.cauce.org/>
7 reasons why HTML email is a bad thing
http://www.georgedillon.com/web/html_email_is_evil.shtml
PGP key fingerprints:
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A

[1] We have to have a separate "GUI" thread (or perhaps use the
existing panel/dyngui threads?) to drive the window's message pump
(read from Windows' message queue and process the messages it
receives), calling the Default procedure for whatever messages it
decides not to explicitly react to (which in this case would be all
of them except the end-session ones mentioned above).

[2] See also footnote 3 below.

[3] Display a timed messagebox (with a countdown) notifying them of
the shutdown/logoff, giving them a chance to abort it should they
change their mind (and with a reasonable safe default should they not
respond in time).

[4] I think one of our users may have even offered a patch for this
at some point?

[5] http://msdn.microsoft.com/en-us/library/ms686953(VS.85).aspx

[6] ibid.
Paul Raulerson
2008-09-08 18:07:51 UTC
Permalink
What's deficient about screen? You start a session, with as many separate
windows as you like and can disconnect and reconnect to the session over and
over.
I start mine with a descriptive name like screen - R mvs, then run Hercules
in one window and c3270 in the next. Control-A to disconnect, and I can
reconnect to it at any time with screen -r mvs.

-Paul
Post by Keven Tipping
Greetings to all.
I've been using Herc for a while now on a dedicated box. Works great.
I'd like to implement two features that I think Hercules /really/
needs, though I'm not really sure how/where said features should be
implemented.
1) Signal Handling
I'd like to add some sort of signal handling to Hercules so that I can
fire off signals at the process and have it *shut down gracefully* (as
in, running through the HHCxx9yyI messages). Basically, this would be
as simple as setting up the signal handling under Linux and launching
the equivalent to typing "exit" on the Hercules HMC when a signal is
received.
The reason for this being, is that when I'm running Hercules in the
background- start-stop-daemon can start Hercules as a system service,
but I've got to manually shut it down before start-stop-daemon
attempts to do so- otherwise Hercules simply dies and doesn't clean up.
Where would the code for this best go? In an additional module loaded
by the HDL? Or somewhere else?
2) Detachable UI
This is one that really kills me. At the moment, I'm running Hercules
under a screen session with multiuser support in the screenrc for my
system. It's a hack at best.
I'd like to implement a very simple telnet server for Hercules, with a
simple plaintext auth specified in the config file and an ACL for
acceptable host connections (usually just localhost- the idea being
that you can SSH into the machine running Hercules, then launch Telnet
locally to reconnect to the Herc HMC running in the background as a
service).
I'm well aware that Herc has the HTTP server and CGI stuff built-in,
however more times then not the only thing I have is an SSH line to my
Hercules box itself or another box in my network that I can tunnel
through. I also find that (no offense) the HTML/CGI interface is
somewhat kludgy to use at times and the auto-refresh thing isn't as
concise as a direct link to the Hercules cmdline via a terminal.
So once again- /where/ would this code be best fitted? As a module for
HDL, or as something else?
If anyone has any other relevant pointers or suggestions, they would
be highly welcomed.
Cheerio.
-KT
[Non-text portions of this message have been removed]
Keven Tipping
2008-09-08 19:07:52 UTC
Permalink
Nothing is wrong with screen.

If you didn't need to use `screen` on Hercules- if the engine and UI
client were separate programs, would you still use screen anyways?

Point being, screen is designed to allow applications that run in a
terminal foreground to run in the background. Screen doesn't fix the
ultimate issue of why the application needs a terminal to run in the
foreground or why the application can't be ran as a background daemon
properly.

-KT
What's deficient about screen? You start a session, with as many
separate
windows as you like and can disconnect and reconnect to the session over and
over.
I start mine with a descriptive name like screen - R mvs, then run Hercules
in one window and c3270 in the next. Control-A to disconnect, and I
can
reconnect to it at any time with screen -r mvs.
-Paul
Post by Keven Tipping
Greetings to all.
I've been using Herc for a while now on a dedicated box. Works
great.
Post by Keven Tipping
I'd like to implement two features that I think Hercules /really/
needs, though I'm not really sure how/where said features should be
implemented.
1) Signal Handling
I'd like to add some sort of signal handling to Hercules so that I
can
Post by Keven Tipping
fire off signals at the process and have it *shut down gracefully*
(as
Post by Keven Tipping
in, running through the HHCxx9yyI messages). Basically, this would
be
Post by Keven Tipping
as simple as setting up the signal handling under Linux and
launching
Post by Keven Tipping
the equivalent to typing "exit" on the Hercules HMC when a signal is
received.
The reason for this being, is that when I'm running Hercules in the
background- start-stop-daemon can start Hercules as a system
service,
Post by Keven Tipping
but I've got to manually shut it down before start-stop-daemon
attempts to do so- otherwise Hercules simply dies and doesn't
clean up.
Post by Keven Tipping
Where would the code for this best go? In an additional module
loaded
Post by Keven Tipping
by the HDL? Or somewhere else?
2) Detachable UI
This is one that really kills me. At the moment, I'm running
Hercules
Post by Keven Tipping
under a screen session with multiuser support in the screenrc for my
system. It's a hack at best.
I'd like to implement a very simple telnet server for Hercules,
with a
Post by Keven Tipping
simple plaintext auth specified in the config file and an ACL for
acceptable host connections (usually just localhost- the idea being
that you can SSH into the machine running Hercules, then launch
Telnet
Post by Keven Tipping
locally to reconnect to the Herc HMC running in the background as a
service).
I'm well aware that Herc has the HTTP server and CGI stuff built-in,
however more times then not the only thing I have is an SSH line
to my
Post by Keven Tipping
Hercules box itself or another box in my network that I can tunnel
through. I also find that (no offense) the HTML/CGI interface is
somewhat kludgy to use at times and the auto-refresh thing isn't as
concise as a direct link to the Hercules cmdline via a terminal.
So once again- /where/ would this code be best fitted? As a module
for
Post by Keven Tipping
HDL, or as something else?
If anyone has any other relevant pointers or suggestions, they would
be highly welcomed.
Cheerio.
-KT
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
Paul Raulerson
2008-09-09 14:35:05 UTC
Permalink
Oh I see where you are going - it's definitely a Windows take on the world
though. Hercules just doesn't need to be a background task - mostly because
it is emulating a real mainframe and "real" mainframes have consoles.
The OS's that those mainframes run, with the exception of Linux & z/VM, also
expect to have consoles there.

Running Herc as a background task sounds like a good idea until you look at
it a little closer, then it really just turns out to be a foreground task.

-Paul
Post by Keven Tipping
Nothing is wrong with screen.
If you didn't need to use `screen` on Hercules- if the engine and UI
client were separate programs, would you still use screen anyways?
Point being, screen is designed to allow applications that run in a
terminal foreground to run in the background. Screen doesn't fix the
ultimate issue of why the application needs a terminal to run in the
foreground or why the application can't be ran as a background daemon
properly.
-KT
What's deficient about screen? You start a session, with as many
separate
windows as you like and can disconnect and reconnect to the session over and
over.
I start mine with a descriptive name like screen - R mvs, then run Hercules
in one window and c3270 in the next. Control-A to disconnect, and I
can
reconnect to it at any time with screen -r mvs.
-Paul
Post by Keven Tipping
Greetings to all.
I've been using Herc for a while now on a dedicated box. Works
great.
Post by Keven Tipping
I'd like to implement two features that I think Hercules /really/
needs, though I'm not really sure how/where said features should be
implemented.
1) Signal Handling
I'd like to add some sort of signal handling to Hercules so that I
can
Post by Keven Tipping
fire off signals at the process and have it *shut down gracefully*
(as
Post by Keven Tipping
in, running through the HHCxx9yyI messages). Basically, this would
be
Post by Keven Tipping
as simple as setting up the signal handling under Linux and
launching
Post by Keven Tipping
the equivalent to typing "exit" on the Hercules HMC when a signal is
received.
The reason for this being, is that when I'm running Hercules in the
background- start-stop-daemon can start Hercules as a system
service,
Post by Keven Tipping
but I've got to manually shut it down before start-stop-daemon
attempts to do so- otherwise Hercules simply dies and doesn't
clean up.
Post by Keven Tipping
Where would the code for this best go? In an additional module
loaded
Post by Keven Tipping
by the HDL? Or somewhere else?
2) Detachable UI
This is one that really kills me. At the moment, I'm running
Hercules
Post by Keven Tipping
under a screen session with multiuser support in the screenrc for my
system. It's a hack at best.
I'd like to implement a very simple telnet server for Hercules,
with a
Post by Keven Tipping
simple plaintext auth specified in the config file and an ACL for
acceptable host connections (usually just localhost- the idea being
that you can SSH into the machine running Hercules, then launch
Telnet
Post by Keven Tipping
locally to reconnect to the Herc HMC running in the background as a
service).
I'm well aware that Herc has the HTTP server and CGI stuff built-in,
however more times then not the only thing I have is an SSH line
to my
Post by Keven Tipping
Hercules box itself or another box in my network that I can tunnel
through. I also find that (no offense) the HTML/CGI interface is
somewhat kludgy to use at times and the auto-refresh thing isn't as
concise as a direct link to the Hercules cmdline via a terminal.
So once again- /where/ would this code be best fitted? As a module
for
Post by Keven Tipping
HDL, or as something else?
If anyone has any other relevant pointers or suggestions, they would
be highly welcomed.
Cheerio.
-KT
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
jacampbell-8K57OPj+
2008-09-10 10:32:58 UTC
Permalink
Ultimately, XML's purpose in life is to encapsulate a data flow between any two processes,
especially when they don't know anything about each other.

In this context one of the processes is defined in a fairly hard fashion (hercules). To make
XML the encapsulating mechanism would mean that I couldn't talk to hercules directly - I
would need a priest to take my offering and convert it into something intelligible at the other
end. This would be done by placing the code that understands my gibberish in an underling -
rather than in the fount of wisdom.

What problem is solved by using XML?

James Campbell
Post by peter_flass
Well, there is: <http://www-03. ibm.com/servers/eserver/zseries/zos/xml/>
and zLinux certainly has XML within it.
Using SOAP, you never really have to see or touch the XML, it's just
an encoding technique used to by the transport mechanism for the
remote procedure calls.
...
Post by peter_flass
Actually, XML is the exact opposite of "alien to the mainframe way of
doing things."
XML is a minor extension of GML, which was first developed for Script
on the mainframe. GML became SGML and was then borrowed for HTML and
then XML, but it's all in the family.
peter_flass
2008-09-10 21:59:06 UTC
Permalink
Post by jacampbell-8K57OPj+
Ultimately, XML's purpose in life is to encapsulate a data flow between any two processes,
especially when they don't know anything about each other.
In this context one of the processes is defined in a fairly hard fashion (hercules). To make
XML the encapsulating mechanism would mean that I couldn't talk to hercules directly - I
would need a priest to take my offering and convert it into
something intelligible at the other
Post by jacampbell-8K57OPj+
end. This would be done by placing the code that understands my gibberish in an underling -
rather than in the fount of wisdom.
There are DLLs available to parse the XML fairly simply.
.
Post by jacampbell-8K57OPj+
What problem is solved by using XML?
This, of course, is the real question, to which I have no real answer.
Continue reading on narkive:
Loading...