gmane.comp.emulators.hercules390.general

Re: Re: Implementing new Herc features?

Tim Pinkawa — 2008-09-08T00:29:58

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

Re: Re: Implementing new Herc features?

Keven Tipping — 2008-09-07T23:49:18

> 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 -rc or SIGNAL -exec 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 af

Re: Implementing new Herc features?

u4gh — 2008-09-07T20:20:59

*not* for that like to Well, there is: 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 pro

Re: Re: Implementing new Herc features?

Roger Bowler — 2008-09-07T20:00:10

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.

Re: Implementing new Herc features?

u4gh — 2008-09-07T19:03:57

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 'ref

Re: Copyright or Copy-wrong - from TK3 - Forum

Harold Grovesteen — 2008-09-07T15:11:38

Thank you. Jay Maynard wrote:

Re: Copyright or Copy-wrong - from TK3 - Forum

Jay Maynard — 2008-09-07T13:15:35

This is your forum owner speaking. Stop it. Now. This is off topic for hercules-390, and indeed any forum but turnkey-mvs. I don't know why people have gotten their panties in a wad, but it's long past time for it to have been taken offline. It's gotten personal. That's not going to help the project. If you want to complain at me about this, do it offline.

Re: Hercules UI

Harold Grovesteen — 2008-09-07T13:10:44

This sounds a lot like what is done to support an external interface, such as Fish's HercGUI, except on Linux. Have you looked to see if anything already there is worth leveraging? I would think that there will be some reluctance to drop the HTTP I/F because some use it. Just an observation. Harold Grovesteen Keven Tipping wrote:

Re: Copyright or Copy-wrong - from TK3 - Forum

kerravon86 — 2008-09-07T09:28:30

You can. Go into the shadow directory after mvs/380 is installed and delete all the files there. Right. Just like I say I won't rape women, and when someone claims that I raped a woman, I ask them to report their concern to the police. Right. You made a libellous claim. Right. in Go right ahead. Right. Right. owner only part copyright If you have added something, yes, you own the added work there, assuming it is something that is normally copyrightable, anyway. It is unlikely that a court will give you copyright protection on a config file. Nope. Yes, you can't release something under a particular licence and after everyone has started using it, start demanding licence fees because you "changed your mind". Yours is. their They can. When they release it. format The portions of it that aren't owned by someone else, yes, if they have some sort of significant copyrightable material in them. week As in, *YOU* followed the instructions, not me. directories, No you didn't. file And?

Copyright or Copy-wrong - from TK3 - Forum

halfmeg — 2008-09-07T06:57:57

If as you state above, you have created an add-on similiar to dyn75, then you should be able to remove it in a similiar manner. Wow, You evidently state you won't violate copyright, then when someone makes a claim, you say go to court. Nothing about let's talk it over or maybe we can work something out. Nope straight to court and that you'll possibly sue for libel as well. Let's see how 'going to court' might proceed. What say we publish in several forums which might have an interest in copyright. There was another email attributed to you as well: And even if there is something in there that you wrote, you can't go and withdraw that either. Hmmm, a little overview of Copyright Law of the United States of America, since I published my work in the US. 17 U.S.C 102. Subject matter of copyright: In general (a) Copyright protection subsists, in accordance with this title, in original works of authorship fixed in any tangible medium of expression ... 17 U.S.C 103(a) Subject matter of copyrigh

Re: Re: Implementing new Herc features?

Keven Tipping — 2008-09-07T02:43:38

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 On Sep 6, 2008, at 8:41 PM, Mike Schwab wrote: [Non-text portions of this message have been removed]

Re: Re: Implementing new Herc features?

Mike Schwab — 2008-09-07T02:41:18

Right now, you have to code your hercules configuration file with a line like 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. 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. On Sat, Sep 6, 2008 at 8:50 PM, Keven Tipping public.gmane.org> wrote:

Re: Re: Implementing new Herc features?

Keven Tipping — 2008-09-07T01:50:18

You've sort of lost me? What is the Hercules definition file? The configuration file passed to hercules as -f ? -KT On Sep 6, 2008, at 6:19 PM, Mike Schwab wrote: [Non-text portions of this message have been removed]

Re: Re: Implementing new Herc features?

Mike Schwab — 2008-09-07T00:19:24

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. On Sat, Sep 6, 2008 at 6:58 PM, Keven Tipping public.gmane.org> wrote:

Re: Re: Implementing new Herc features?

Keven Tipping — 2008-09-06T23:58:29

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),

Re: Re: Implementing new Herc features?

William Carroll — 2008-09-06T21:45:18

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 Keven Tipping wrote:

Re: Re: Implementing new Herc features?

Mike Schwab — 2008-09-06T21:33:28

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. 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 public.gmane.org> wrote:

Hercules UI

Keven Tipping — 2008-09-06T21:22:38

I hate to do this, but the discussion over in "Implementing new Herc features?" is/has been geared towards shutdown handling and the sorts, so I'd like to branch off the UI portion of that thread into this one. Anyways. In addition to the whole shutdown thing, I wanted to either implement a new UI suitable for controlling Hercules in the background (without using the HTTP server). Originally I thought this would be best achieved by implementing a new Telnet server as a loadable module, but I'm starting to think that this is more of a bandaid then an actual improvement. So here's what I'm preposing for the Hercules user interface. 1) get rid of the HTTP server. The HTTP/CGI interface is fairly old, even though it does the job it still has issues with page refreshes and such (IMHO). Something text-based in a terminal is far more efficient, quicker, and simpler to implement. 2) Break off the NCurses GUI. Run Hercules in "daemon" mode by default. 3) Implement a new Telnet based server i

Re: Re: Implementing new Herc features?

Keven Tipping — 2008-09-06T21:03:36

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): SIGNALSIGTERM /home/User/zVM/zvm_shutdown.rc - Or the W32 variant, according to Fish - SIGNALSHUTDOWN 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 < at > 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

Re: Implementing new Herc features?

u4gh — 2008-09-06T20:34:31

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

Re: Implementing new Herc features?

Frans Pop — 2008-09-06T16:38:26

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.