Hello!
I'm not the fellow here who's surrounded by DEC gear, but, ah, it's a
family of networking protocols used by that family to, ah,
communicate. People could send files to other systems, and naturally
get them back. They could also make use of an email idea. However it's
biggest use happened to be to facilitate remote diagnosis of unhappy
DEC systems.

We also should expect a response from the fellow as soon as a member
of his staff understands the email.

Fish? What's that green thing in your bowl? Oh right, the pottery
whatsit that's usually found inside fish bowls.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."

On Fri, Nov 25, 2022 at 6:20 PM Bertram Moshier <herc370390vm@...> wrote:

Hey!

I'm not familiar with DECNet. I'm looking at the possibility of using CTCA to allow the VM Backup program to talk to other copies of itself.

The idea being offsite backup or copies of backups.

This wouldn't work in a mixed real iron and Hercules, from what I can tell.

Bertram / WB8ERT

On Fri, Nov 25, 2022, 17:08 Gregg Levine <gregg.drwho8@...> wrote:

Hello!
I believe I originally proposed that sometime earlier. The idea was
that we'd each have our machines communicating over the Internet, and
sending and receiving files, and perhaps messages. Of course that one
is a bit more difficult. Oddly enough I first proposed this, well
before the Hobbyist DECNet project emerged, back when your wonderful
ideas on connecting the Hercules example to the outside world first
got launched.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."

On Thu, Nov 24, 2022 at 6:17 PM Fish Fish <david.b.trout@...> wrote:

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@...

And we've gotten space allocated for the Rebel fleet which is moving
from Sullust.

And we've gotten more space allocated for the Rebel fleet which is
moving from Sullust.

Hello!
I believe I originally proposed that sometime earlier. The idea was
that we'd each have our machines communicating over the Internet, and
sending and receiving files, and perhaps messages. Of course that one
is a bit more difficult. Oddly enough I first proposed this, well
before the Hobbyist DECNet project emerged, back when your wonderful
ideas on connecting the Hercules example to the outside world first
got launched.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."

On Thu, Nov 24, 2022 at 6:17 PM Fish Fish <david.b.trout@...> wrote:

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@...

And we've gotten space allocated for the Rebel fleet which is moving
from Sullust.

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@...