Bertram Moshier wrote:

[...]

I'm wondering is it possible to have

1) Two Hercules systems on the same Windows system
running VM and
2) Connect these two CMS users on each VM system via
a CTCA between these two Hercules systems?

Also:

Is it possible to have these two VM and Hercules systems
on different physical Windows or Linux systems connected
by a CTCA?

Yes to both.

If so, how? What should I read?

Start here:

*


As far as documentation describing actual CTCA functionality goes (i.e. how it works and how to use it), there are the following IBM reference manuals:

* GA22-6983-00 IBM System-370 Special Feature Description - Channel-to-Channel Adapter
* SA22-7091-01 ESA-390 (CTCA) Channel-to-Channel Adapter for the System-360 and System-370 I-O Interface
* SA22-7203-00 ESA-390 ESCON Channel-to-Channel Adapter
* SB10-7034-04 System z - ESCON and FICON Channel-to-Channel Reference

You might be able to find them on the web somewhere if you search hard enough. If you can't find them though, contact me off list and I'll send you a copy. I have them all.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Hi, Joe,

Thanks for that clarification.

Mark

开云体育

Read the source of Hercules and you will find that your statement is not correct.?

To All,

??? If you want to try VM/370 on a 370 simulator there is the one I developed for simH. It will run pretty much anything but MVS for some reason. I can't figure out why I can't get past SMP install.

But it is a 370 only machine, it will also emulate a 360 (including a /67). Once I can run MVS on it I will release it to the main open-simh repository. I also need to complete VM/CP assist instructions.

If anyone wants to play with it let me know.

Rich

To all,

There is one big "flaw" in this thread, the part about adding newer instructions " for use in 370 mode ..." -- I believe Roger Bowler set out to develop hercules-390 as a S/390 emulator, from "day one"... it only runs S/370 SCPs by virtue of the fact that the real S/390 machines could also do so ...? because those machines provided a certain amount of backward compatibility.
?
So, on a real S/390, you would have newer problem-state instructions available to use, even if you were running an older SCP that was originally for S/360 or S/370 ...

Just saying ...

Cheers,
Mark S. Waterbury

Laddie Hanus wrote:

[...]

Next Hercules has implemented a CCW that came from the p/390
and still exists in z/PDT I believe.

Yes! I forgot all about that one. Thank you, Laddie, for mentioning it. That would also be a viable method for Bertram:

*
*

Note: The above TMOUNT assembler source code was written for the DOS/VSE operating system, but the program is so short and simple that I would like to believe any competent assembler programmer should have no problem understanding it, given that the most important part is how the CCWs are used. How I/O to a device is done on other operating systems is left to the user.


[...]

Caution: writing a channel program you need to know about
how I/O works and can be very difficult to debug.

I guess it all depends on how complicated the I/O is. In the TMOUNT case, the I/O is so dirt simple that I'm doubting there would be any significant problems.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

I worked at StorageTek on tape libraries and virtual tape from 1984 to 2017 with a 6 year vacation. The 4400 and newer tape libraries under worked on vm by using IUCV for sending a command to a service machine that ran a modified version of HSC which was the MVS Host Software Component that controlled the tape library. The tape library had a 3270 connection that was used by HSC to communicate with the library. ?I don’t remember?the data shipped along the 3270 connection?. Suffice it to say that the was a mount command and unmount?command. It also required VM/SP so I don’t know if something similar could be done on older releases of VM. This is what the customer saw so I can share this. What I know about the internals I can’t share due to my employment contract that I signed when I started there. And I respect that. Every little bit?is left of STK is owned by Oracle who bought Sun. Which bought STK

Tony Harminc wrote:

Fish wrote:

Tony Harminc wrote:

[...]

Is that maybe what you're referring to?

No - not at all.

I simply refer to the fact that part of ("full") virtualization
is that the guest cannot discover using architected features
whether or not it is running in a virtual environment. Note
that the DIAG interface to CP (or Hercules, or an LPAR, for
that matter) is not part of the architecture. Yes, of course
the guest can probably, but not deterministically, discover that
it is running virtualized - most likely using timing tests. But
not by finding a different result from an architected instruction.
This is discussed in the VM books from the earliest days.

Ah. I see where you're coming from now.

Well gosh, Tony. By that definition then, IBM's VM has *never* provided full virtualization (hint: STIDP), so why the big deal about EPSW?

I'm not sure that even today i64 is 100% virtualizable,
is it?

I have no idea. I don't know i64.

Oh, sorry - I thought all Windows people did.

Nope. I absolutely *hate* the Intel architecture, and have never found the real need to ever learn it (thank goodness!). Mark Gaubatz seems to be quite familiar with it, and uses that knowledge/skill to find bugs in Microsoft's Visual C/C++ compiler (most often in their optimization logic). He tells me about it all the time.

Me? I'm not interested in debugging their compiler or stepping through their generated assembler code or, at ANY time, ever coding anything in it. I leave that to Mark and others. If I come across a situation where my C/C++ code misbehaves when optimized (whereas it doesn't when not optimized), I would just report it and then disable optimizations for that particular function and move on. I have ZERO interest in the Intel architecture. It truly SUCKS IMHO.

Now Motorola's 68XXX and 88XXX architectures are pretty nice IMO. I messed with both of them many eons ago at one of my former employers.

But Intel? YUCK! :)

(I mean, little endian?! Come on!)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

开云体育

Tony Harminc wrote:

[...]

OK, fair enough.

Thank you.

What it does do is make the architecture no longer virtualizable
(without some feature like SIE).

Eh? How so?

This 100% virtualizable feature (even for privileged states,
and for that matter I/O) was to my knowledge unique among the
architectures of the day, and may be still true.

I'm not following you.

Look at the early kluges with i86 and VMWare and such, that
had to resort to paravirtualization, where the guest has to
cooperate (or the host zaps the guest code on the fly so that
it does).

What does that have to do with your claim that the introduction of new instructions that weren't defined in the original published version of the architecture's manuals somehow makes the architecture "longer virtualizable without some feature like SIE"? I'm not understanding your argument/reasoning.

The architecture should still be virtualizable (even *without* SIE) with or without the introduction of the new instructions. And if none of the new instructions are privileged instructions, the architecture should still be virtualizable (without SIE) without any modification at all to the hypervisor. Only if support for a new privileged instruction was needed would the hypervisor then need to be changed (to add support to simulate the privileged instruction).

Is that maybe what you're referring to?

I'm not sure that even today i64 is 100% virtualizable,
is it?

I have no idea. I don't know i64.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Tony Harminc wrote:

In my view the key to all this is that there is no way for
a program running in CMS (or any guest in a VM) to discover
what the real PSW is, even if they are in virtual supervisor
state. In S/370 versions of VM, there is simply no instruction
that will provide the current PSW to the running code. The
only way to see what the PSW *was* is to look at the old PSW
from an interrupt, and that value will have been cooked up
by CP to match the expected reality.

Precisely.


<snip; EPSW = Extract PSW instruction>

Where things go wrong is that later versions of Hercules have
back ported a large number of unprivileged S/390 and zArch
instructions into the S/370 implementation,

But only if/when specifically requested via enabling that specific Hercules facility (256):

FACILITY ENABLE HERC_370_EXTENSION

and EPSW is one of them. So indeed a CMS user program can
issue that, and find out the horrible truth...

Yep. But again, only if facility 256 is specifically enabled. Normally it is not enabled, so in normal situations 370 systems can never learn they are actually running inside the matrix.

I objected to porting EPSW way back when, but it seems to be
a done deal that breaks the S/370 architecture, albeit not in
any extreme way.

I was never crazy about it myself, but I have to admit that having *some* of the newer instructions available in 370 mode can certainly prove to be quite handy. But as designed (by Ivan Warren I think) it's an all or nothing sort of thing so EPSW came along for the ride.

Your comment regarding it "breaking" the S/370 architecture however, is most definitely not true. It does NOT -- repeat, *NOT* -- break (violate) the [published] architecture.

Yes, it does indeed introduce new instructions that never actually existed on any IBM S/370 machine (or published in any S/370 Principles of Operation manual), but that does not constitute a violation of the architecture. Even back in the days of S/370 IBM would occasionally introduce a new instruction that never existed before then. Was THAT a violation of the architecture? Did IBM "break" the architecture by doing so? Of course not.

Adding new instructions to an existing architecture does not "break" the architecture. Only if a new instruction violates in some manner the way the architecture is supposed to behave would an architectural violation then occur. This was Ivan's argument and one with which I agree with 100%.

Is it weird? (unusual?) Yes! Absolutely. It adds new instructions that never existed back then, and thus "just feels wrong" to purists like you and me.

But it certainly does NOT violate the architecture.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Bob Bolch wrote:

Not really. Supervisor state is virtualized for the CMS user.
When an instruction requiring supervisor state is executed in
a CMS machine, a privop occurs and CP is given control to
simulate the privileged instruction.

Precisely!

The CMS user may *think* (believe) it is running in supervisor state, but in actuality it is not. It's "virtual" PSW (saved/maintained in its VM [user?] block) indicates it's in supervisor state, but when CP -- which is the only one in control of the REAL machine (actual hardware) always dispatches the virtual machine in *problem* state.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Aaron Finerman wrote:

When you run under VM, you are in a virtual machine
and everything is virtualized.

Correct. Even your PSW.

No one on this forum needs a lesson on that.

Well, what you say next makes me question that.

Applications running under CMS are given control in supervisor
state by default.

Their virtual PSW indicates supervisor state, yes. But their *real* (actual) PSW is still in problem state.

If the problem state bit in the PSW is off, you are in
supervisor state.

VIRTUAL supervisor state.

There is no virtualized supervisor state in any architecture.

Sure there is! That's the hallmark of VM! A virtual machine "sees" its PSW is in supervisor state, but the PSW it is seeing is NOT its *real* PSW. It's a fake ("virtual") one constructed by CP. The virtual machine's *real* (actual) PSW *always* remains in problem state.

This is basic VM.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...