On 18/03/2025 16:36, BlameTroi via groups.io wrote:

This may be a dumb question, but I couldn't find anything helpful after searching here in groups and generally on the web.

I'm wanting to rebuild my first serious shop in my home: VM hosting DOS/VS. I see that there are Hercules Aethra and SDL Hercules versions. Is there any reason to prefer one over the other for running VMCE?

I don't believe for any of the 370 based OSs such as VM/370 R6 which is the base for VM/CE there is any difference. In fact at the risk of irking Jay and Fish I would say that on a PI one of the 3.X releases might work better as they are a little lighter.

From my reading a while back, MacOS security is a pain in the butt for Hercules and some other software.

I am not a Mac guy, but I think this is only a problem when running post 370 operating systems which have network interfaces....

While I'm a Mac guy these days, I have old but Windows 11 capable Intel boxes and a few of the various Pi boards, including a 4, available. Are Pis sufficient for VM and possibly DOSVS?

I haven't run Hercules on a PI for a while. Its slow, I believe it gives a similar performance to 4331/4341/4361 class machine. Give it a try..

Thanks.

Dave
G4UGM

开云体育

On Mar 18, 2025, at 9:36 AM, BlameTroi via groups.io <blametroi@...> wrote:

This may be a dumb question, but I couldn't find anything helpful after searching here in groups and generally on the web.

I'm wanting to rebuild my first serious shop in my home: VM hosting DOS/VS. I see that there are Hercules Aethra and SDL Hercules versions. Is there any reason to prefer one over the other for running VMCE?

From my reading a while back, MacOS security is a pain in the butt for Hercules and some other software. While I'm a Mac guy these days, I have old but Windows 11 capable Intel boxes and a few of the various Pi boards, including a 4, available. Are Pis sufficient for VM and possibly DOSVS?

Thanks.

Mark A. Stevens <marXtevens@...> added folder /RSCS_Assistant

Description:
A couple of EXECs to set up the access order and build RSCS with or without Peter Coghlan's mods. Two formats a zip of an AWS tape, and a VMARC file.

The following items have been added to the Files area of the [email protected] group.

• /hrc422ds.vmarc

By: Ross Patterson <ross.patterson@...>

Description:
HRC422DS NUCXTEXT occasionally causes DMSLIO109S VIRTUAL STORAGE CAPACITY EXCEEDED See https://github.com/s390guy/vm370/issues/131

replace the * (asterisk or star symbol) before publibz with a forward

> slash /

That's got it. Thanks, Gonzalo.

De

Is the above mangled from what you sent? IA gives me a "No URL has been
captured for this URL prefix" error. (I live behind a $%^*&
"protection" system, i.e. URL destroyer, sigh.)

De

开云体育

I googled 1fc5g101 and got this URL as first hit. So I guess there are ways to find them anyway. Looking for the Erep Users guide gives the URL as well, though that wil give ifc5g103.

Funny part is that if you go to epub/pdf/ it gives a forbidden result so you do need to specifically enter the full url of a book.

Regards, Berry.

As mentioned, technically there's no limit. But in practice there is. It all has to do with the overhead you get when running in virtual environments and especially when CPU instructions need to be emulated. I do work with modern z-environments, in a current z/VM virtualization overhead is about 7%, emulation is effectively about 100% overhead, more or less the same is true for any VM/ESA or VM/XA system.

You have to consider SIE processing. () Because of SIE your guest can get access to the processor directly, but when SIE is not available all CPU load needs to be emulated by the host levels. SIE can run three levels. In the past you were running a mainframe in basic mode. You could run three levels with SIE: first level (or native), second level and third level. SIE was available in the 370 XA architecture, so VM/370 doesn't include SIE, you would need VM/XA or newer for that.

Then we got LPAR mode mainframes. Starting zArchitecture LPAR mode is the only mode available. PR/SM is basically the first level of virtualization. So now you can run two SIE levels in an LPAR, the VM Host (now refered to as native or first level) and a guest under VM (now refered to as second level). Any guest running under the second level guest (a third level guest) cannot benefit from SIE processing. Remember, in LPAR mode this third level guest is actually a fourth level guest. So in practice, when running a VM LPAR with a VM guest and a VM or VSE guest under the second level VM, the host now needs to emulate all CPU instructions.

Some 15 years ago we wanted to run a customer in a second level environment. Indeed we could run their VM?(z/VM -> customer z/VM guest -> z/VSE guests) as second level guest, but their VSE systems couldn't use SIE. As a result the load was emulated and CPU usage doubled and also introduced a lot of other timing related issues. That wasn't an option for that customer, but we did run another customer as second level environment for a couple of years and they accepted the increased CPU load for their environment.

Apart from running on the real hardware, we obviously focus on Hercules. So in this case all CPU needs to be emulated, going from x86 hardware to an emulated S360-S370-S390 CPU. Next we run VM in hercules. As stated, SIE is only found in VM/XA and later so SIE is not available in VM/370 and a guest CPU needs to be emulated in any level of virtualization. But for argument sake, Hercules implements the ESA/390 architecture, including SIE, so if you run a newer VM within this system SIE is available. But only for three levels, and the S390 CPU is emulated to begin with.

But technically, you can run Hercules -> VM -> Linux -> Hercules -> Linux etc (or whatever configuration you like). The only thing is, your guest may be very slowwww as the overhead will double with every new level, especially when SIE is not available in any of the levels (VM/370 or any level beyond third level virtualization).

At least you're not the first to try this. I have seen a virtualization up to 7 levels running various configurations of hercules, VM and Linux.

Regards, Berry.

Op 11-03-2025 om 15:48 schreef Alexander Huemer via groups.io:

开云体育

On Tue, Mar 11, 2025 at 11:30:46AM -0400, Ross Patterson via groups.io wrote:

On Tue, Mar 11, 2025 at 10:50 Alexander Huemer via groups.io <aziD5eeth9fe=
[email protected]> wrote:

You can install VM on top of VM

My knee-jerk question to my instructor back then was:

How deep can you go?

He didn't know.

Technically, there is no limit.  Diagnose code x'0000' will attempt to
return up to 5 levels of CP info.  Practically, the "top level" system gets
slower and slower as you add more levels of CP underneath it.  It was
common to run two levels for testing purposes, back in the 70s and 80s, but
not for production, due to poor performance.  With today's real and
emulated mainframes, you could easily do more than that in production.

That sounds encouraging, thanks for laying that out.
I would think too that performance shouldn't be a problem.
This is very much an academic exercise anyways. The idea is just to 
demonstrate that it is possible, not to solve any real-world problem.
 

Ever since, I have an idea in my head that comes back occasionally.
Can you install VM 'recursively'?
What I mean by that is the following:
...

Yes, but you'd have to write that installation process yourself.  Nothing
in the normal VM installation makes that simple.

Right. The problem is, I know so little about VM and its ecosystem that 
I don't even know where to start.

I am lacking the experience with VM to assess whether this is 
possible at all or if perhaps it is possible in principle but only 
with later versions of VM than VM/370 or something like that.

Its possible with every version of VM and there are as far as I know no hard coded limits limits. Performance suffers the deeper you go because many instructions need to be interpreted at each level.
At some point you will run out of real memory because in order to do certain things pages need to be locked in memory.
? ?

Successive later versions of VM have added more and more functions to
improve automation capabilites.  Stuff like the Secondary Console Image
Facility.

Sounds great, but I can't say I really know what that is.

In case anybody on this list is interested to tinker on this, please let 
me know, on of off list.

I would say even with the later facilities you can't automate something that generates an arbitrary depth of VMs.
Lets take things at a simple level. Each VM needs its own system disk that you IPL from. These need to be known in some way, by the top level VM before you start.
So if they are physical disks the top level VM needs to have a separate IO address in DMKRIO.
Yes you can use minidisks but that doesn?t help much. The number of cylinders is defined at startup...

-Alex

Dave

On Tue, Mar 11, 2025 at 11:30:46AM -0400, Ross Patterson via groups.io wrote:

On Tue, Mar 11, 2025 at 10:50 Alexander Huemer via groups.io <aziD5eeth9fe=
[email protected]> wrote:

You can install VM on top of VM

My knee-jerk question to my instructor back then was:

How deep can you go?

He didn't know.

Technically, there is no limit. Diagnose code x'0000' will attempt to
return up to 5 levels of CP info. Practically, the "top level" system gets
slower and slower as you add more levels of CP underneath it. It was
common to run two levels for testing purposes, back in the 70s and 80s, but
not for production, due to poor performance. With today's real and
emulated mainframes, you could easily do more than that in production.

That sounds encouraging, thanks for laying that out.
I would think too that performance shouldn't be a problem.
This is very much an academic exercise anyways. The idea is just to
demonstrate that it is possible, not to solve any real-world problem.

Ever since, I have an idea in my head that comes back occasionally.
Can you install VM 'recursively'?
What I mean by that is the following:
...

Yes, but you'd have to write that installation process yourself. Nothing
in the normal VM installation makes that simple.

Right. The problem is, I know so little about VM and its ecosystem that
I don't even know where to start.

I am lacking the experience with VM to assess whether this is
possible at all or if perhaps it is possible in principle but only
with later versions of VM than VM/370 or something like that.

Successive later versions of VM have added more and more functions to
improve automation capabilites. Stuff like the Secondary Console Image
Facility.

Sounds great, but I can't say I really know what that is.

In case anybody on this list is interested to tinker on this, please let
me know, on of off list.

-Alex

Hi

I am new to this group.
Let me please provide a bit of background why I am making this post.
At my first IT job in 1999 there was an IBM 9221 running VM/ESA and on
top of that VSE/ESA. My involvement with that machine was
(unfortunately) very sporadic, I had to look after other tech.
I got very basic training on the machine, enabling me to do some simple
things ('v net, act' and stuff like that). Unfortunately I forgot most
of what I knew back then over the last 25 years due to not being
involved with mainframes professionally.
While I do play with mainframe tech in my spare time a bit, I cannot
claim any in-depth knowledge.
One thing that was explained to me back then was very impressive to me
and stuck in my mind.

You can install VM on top of VM

My knee-jerk question to my instructor back then was:

How deep can you go?

He didn't know.

Ever since, I have an idea in my head that comes back occasionally.
Can you install VM 'recursively'?
What I mean by that is the following:
Can you prepare an IPL-able VM tape that does the following:
* IPL (obviously)
* without user interaction:
* Some arithmetic to assess suitable values for the next step like
available memory (storage) and available DASD space
* create the necessary infrastructure to run a VM guest
(user account, minidisk, etc.) with the pre-computed values from the
last step
* IPL the same tape that was used originally for the 'bare-metal'
installation inside the just created VM
* Configure the guest system so that it can be reached from the
outside via a 3270 session or some such

This process is supposed to run as unattended as possible, continuing
until some inherent nesting limitation of VM is reached or a required
resource like storage or DASD space is exhausted.

I am lacking the experience with VM to assess whether this is possible
at all or if perhaps it is possible in principle but only with later
versions of VM than VM/370 or something like that.

Anyways, I would be interested in the opinion of people on this mailing
list regarding this topic.
Perhaps you'll tell me this is a stupid idea, but hey ho.

-Alex