Discussion:
[hercules-390] Hercules status
williaj@sympatico.ca [hercules-390]
2017-01-10 19:04:18 UTC
Permalink
I was just reading the instruction leakage thread and saw somitcw's comment about the various (obsolete) forks of Hercuels, which made me wonder what is the current state of affairs with regard to future Hercules development.

1. Is work still continuing on the 3.x line or is 3.12 the end of that era ? I seem to recall reading a post from way back that implied that most of the 3.x devs had given up due to strife between some people.

2. Is Hyperion then where any further development will or is occurring ? I saw a post about still looking for help. I have a working knowledge of C but not C++, so I'm not sure if I could contribute or not. Since I'm retiring shortly, spare time I ought to have though, even if just for doc writing.

3. Are there binaries for Hyperion, or is it just a build your own from source at the moment ?
somitcw@yahoo.com [hercules-390]
2017-01-10 19:57:03 UTC
Permalink
Post by ***@sympatico.ca [hercules-390]
I was just reading the instruction leakage thread and saw somitcw's
comment about the various (obsolete) forks of Hercuels, which made
me wonder what is the current state of affairs with regard to future
Hercules development.
Don't depend on me. I don't keep track and couldn't build Hercules if I tried.
Post by ***@sympatico.ca [hercules-390]
1. Is work still continuing on the 3.x line or is 3.12 the end of that era ?
I seem to recall reading a post from way back that implied that most of
the 3.x devs had given up due to strife between some people.
2. Is Hyperion then where any further development will or is occurring ?
I saw a post about still looking for help. I have a working knowledge of
C but not C++, so I'm not sure if I could contribute or not. Since I'm retiring
shortly, spare time I ought to have though, even if just for doc writing.
3. Are there binaries for Hyperion, or is it just a build your own from
source at the moment ?
Like I said, I don't keep track.
I also don't know C or want to learn, but:

Possible Hercules 3.12
http://www.hercules-390.eu/

Possible Hercules 4.00
http://hercules-390.github.io/html/

Possible Fish splinter or fork:
http://www.softdevlabs.com/hyperion.html#prebuilt

another include one with TCPIP code is within TK4-minus
http://wotho.ethz.ch/tk4-/
Warning, web page upside down and scrambled.
You probably want tk4-_v1.00_current.zip at the bottom with
other pieces at the top.
Or you can down load tk4-_v1.00.zip like everone else
and re-report the problem that were already fixed.

One with AMODE 31 and possibly AMODE 64? and
TDF/OMA updates, start searching at:
https://groups.yahoo.com/neo/groups/hercules-os380/files
Perhaps Stage127 ?
or post a question on that yahoo group.

I don't know which one has the latest updates to CTCE?

There could be more?
I don't keep track and remember little.
somitcw@yahoo.com [hercules-390]
2017-01-10 20:03:37 UTC
Permalink
- - - In hercules-***@yahoogroups.com, <***@...> wrote:
- - - beginning snipped - - -
Post by ***@yahoo.com [hercules-390]
One with AMODE 31 and possibly AMODE 64? and
https://groups.yahoo.com/neo/groups/hercules-os380/files
Perhaps Stage127 ?
or post a question on that yahoo group.
- - - ending snipped - - -


Perhaps: herc380-stage129.zip but I don't know.
'Peter J. Jansen' peter_j_jansen@yahoo.com [hercules-390]
2017-01-11 10:54:20 UTC
Permalink
Please see comments below.
Sent: Tuesday, 10 January, 2017 20:57
Subject: [hercules-390] Re: Hercules status
[...]
I don't know which one has the latest updates to CTCE?
[...]

The official Hyperion repo (https://github.com/hercules-390/hyperion) is up-to-date with my latest CTCE stuff.

The Spinhawk repo (https://github.com/rbowler/spinhawk) has an in-progress pull request outstanding from my repo (https://github.com/Peter-J-Jansen/spinhawk) which has my latest CTCE stuff included.

Cheers,

Peter
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-01-11 18:55:48 UTC
Permalink
Post by 'Peter J. Jansen' ***@yahoo.com [hercules-390]
[...]
Post by ***@yahoo.com [hercules-390]
I don't know which one has the latest updates to CTCE?
[...]
The official Hyperion repo (https://github.com/hercules-390/hyperion)
is up-to-date with my latest CTCE stuff.
FYI: So is my fork of it:

https://fish-git.github.io/html/
https://github.com/Fish-Git/hyperion
https://github.com/Fish-Git


I intend to (within the limits of my ability to do so and until such time as I can finish development of my own brand new version) try and keep my current fork of hyperion "current" with respect to whatever important architectural/emulation changes that might be made to the official version (though such changes might not be implemented in the same manner of course), such that the end result functionality between the two is identical to each other.

Of course minor differences may be introduced over time (such as dasdls(*) for example or the addition of new features and functionality above and beyond what is currently offered by official hyperion for another), but generally speaking the above is my intent.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com

(*) My fork has issue #160(**) completed whereas official hyperion does not.

(**) https://github.com/hercules-390/hyperion/issues/160
Maarten Hoes hoes.maarten@gmail.com [hercules-390]
2017-01-13 16:40:10 UTC
Permalink
Hi,


On Wed, Jan 11, 2017 at 7:55 PM, ''Fish' (David B. Trout)'
***@gmail.com [hercules-390] <hercules-***@yahoogroups.com> wrote:
<snip>
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
until such time as I can finish development of my own brand new version
<snip>


Wait, what ? i completely overlooked this bit. Im so stoked now. Details,
please !


- Maarten
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-01-13 22:09:15 UTC
Permalink
Post by Maarten Hoes ***@gmail.com [hercules-390]
<snip>
... until such time as I can finish development of
my own brand new version ...
<snip>
Wait, what ? i completely overlooked this bit. Im so stoked now.
Details, please !
There are none. It's still being designed.

The only thing I can divulge is my intent (hope): to completely rewrite Hercules in its entirety in C++, leveraging as absolutely little of the existing code as possible (hopefully none at all).

This will of course take me quite some time to pull off (and of course there is the distinct possibility it may be entirely beyond my capabilities too), so don't expect to see anything soon. We're probably talking a multi-year effort here.

If anyone with both mainframe and C++ skills is interested in helping, feel free to contact me off list.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-14 00:51:22 UTC
Permalink
Don't count on me...

I would have completely supported a hercules project that is true to the
various PoPs...

But C++ ? Why not Java, Python or C# ?

Not my thing... Simple C is fine for me to implement those architectures !

--Ivan
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Post by Maarten Hoes ***@gmail.com [hercules-390]
<snip>
... until such time as I can finish development of
my own brand new version ...
<snip>
Wait, what ? i completely overlooked this bit. Im so stoked now.
Details, please !
There are none. It's still being designed.
The only thing I can divulge is my intent (hope): to completely rewrite Hercules in its entirety in C++, leveraging as absolutely little of the existing code as possible (hopefully none at all).
This will of course take me quite some time to pull off (and of course there is the distinct possibility it may be entirely beyond my capabilities too), so don't expect to see anything soon. We're probably talking a multi-year effort here.
If anyone with both mainframe and C++ skills is interested in helping, feel free to contact me off list.
[Non-text portions of this message have been removed]
Joe Monk joemonk64@gmail.com [hercules-390]
2017-01-14 01:02:45 UTC
Permalink
Even better ... why not Swift?

Joe
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Don't count on me...
I would have completely supported a hercules project that is true to the
various PoPs...
But C++ ? Why not Java, Python or C# ?
Not my thing... Simple C is fine for me to implement those architectures !
--Ivan
Post by Maarten Hoes ***@gmail.com [hercules-390]
<snip>
... until such time as I can finish development of
my own brand new version ...
<snip>
Wait, what ? i completely overlooked this bit. Im so stoked now.
Details, please !
There are none. It's still being designed.
The only thing I can divulge is my intent (hope): to completely rewrite
Hercules in its entirety in C++, leveraging as absolutely little of the
existing code as possible (hopefully none at all).
This will of course take me quite some time to pull off (and of course
there is the distinct possibility it may be entirely beyond my capabilities
too), so don't expect to see anything soon. We're probably talking a
multi-year effort here.
If anyone with both mainframe and C++ skills is interested in helping,
feel free to contact me off list.
[Non-text portions of this message have been removed]
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-14 01:08:14 UTC
Permalink
Erlang or Brainfuck would be nice !

--Ivan
Post by Joe Monk ***@gmail.com [hercules-390]
Even better ... why not Swift?
Joe
Don't count on me...
I would have completely supported a hercules project that is true to the
various PoPs...
But C++ ? Why not Java, Python or C# ?
Not my thing... Simple C is fine for me to implement those
architectures !
--Ivan
On 1/13/2017 11:09 PM, ''Fish' (David B. Trout)'
Post by Maarten Hoes ***@gmail.com [hercules-390]
<snip>
... until such time as I can finish development of
my own brand new version ...
<snip>
Wait, what ? i completely overlooked this bit. Im so stoked now.
Details, please !
There are none. It's still being designed.
The only thing I can divulge is my intent (hope): to completely
rewrite Hercules in its entirety in C++, leveraging as absolutely
little of the existing code as possible (hopefully none at all).
This will of course take me quite some time to pull off (and of
course there is the distinct possibility it may be entirely beyond
my capabilities too), so don't expect to see anything soon. We're
probably talking a multi-year effort here.
If anyone with both mainframe and C++ skills is interested in
helping, feel free to contact me off list.
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
Tony Harminc tharminc@gmail.com [hercules-390]
2017-01-14 01:46:51 UTC
Permalink
APL, like the original
...

Tony H.


On Jan 13, 2017 8:08 PM, "Ivan Warren ***@vmfacility.fr [hercules-390]" <
hercules-***@yahoogroups.com> wrote:

Erlang or Brainfuck would be nice !

--Ivan
Post by Joe Monk ***@gmail.com [hercules-390]
Even better ... why not Swift?
Joe
Don't count on me...
I would have completely supported a hercules project that is true to the
various PoPs...
But C++ ? Why not Java, Python or C# ?
Not my thing... Simple C is fine for me to implement those
architectures !
--Ivan
On 1/13/2017 11:09 PM, ''Fish' (David B. Trout)'
Post by Maarten Hoes ***@gmail.com [hercules-390]
<snip>
... until such time as I can finish development of
my own brand new version ...
<snip>
Wait, what ? i completely overlooked this bit. Im so stoked now.
Details, please !
There are none. It's still being designed.
The only thing I can divulge is my intent (hope): to completely
rewrite Hercules in its entirety in C++, leveraging as absolutely
little of the existing code as possible (hopefully none at all).
This will of course take me quite some time to pull off (and of
course there is the distinct possibility it may be entirely beyond
my capabilities too), so don't expect to see anything soon. We're
probably talking a multi-year effort here.
If anyone with both mainframe and C++ skills is interested in
helping, feel free to contact me off list.
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]



------------------------------------
Posted by: Ivan Warren <***@vmfacility.fr>
------------------------------------

Community email addresses:
Post message: hercules-***@yahoogroups.com
Subscribe: hercules-390-***@yahoogroups.com
Unsubscribe: hercules-390-***@yahoogroups.com
List owner: hercules-390-***@yahoogroups.com

Files and archives at:
http://groups.yahoo.com/group/hercules-390

Get the latest version of Hercules from:
http://www.hercules-390.org


------------------------------------

Yahoo Groups Links
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-14 03:39:08 UTC
Permalink
Let's write hercules in S/370, ESA and z/Arch assembler... Oh wait...

--Ivan
Post by Tony Harminc ***@gmail.com [hercules-390]
APL, like the original
...
Tony H.
Erlang or Brainfuck would be nice !
--Ivan
Post by Joe Monk ***@gmail.com [hercules-390]
Even better ... why not Swift?
Joe
[hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
Don't count on me...
I would have completely supported a hercules project that is
true
Post by Joe Monk ***@gmail.com [hercules-390]
to the
various PoPs...
But C++ ? Why not Java, Python or C# ?
Not my thing... Simple C is fine for me to implement those
architectures !
--Ivan
On 1/13/2017 11:09 PM, ''Fish' (David B. Trout)'
Post by Maarten Hoes ***@gmail.com [hercules-390]
<snip>
... until such time as I can finish development of
my own brand new version ...
<snip>
Wait, what ? i completely overlooked this bit. Im so
stoked now.
Post by Joe Monk ***@gmail.com [hercules-390]
Post by Maarten Hoes ***@gmail.com [hercules-390]
Details, please !
There are none. It's still being designed.
The only thing I can divulge is my intent (hope): to
completely
Post by Joe Monk ***@gmail.com [hercules-390]
rewrite Hercules in its entirety in C++, leveraging as
absolutely
Post by Joe Monk ***@gmail.com [hercules-390]
little of the existing code as possible (hopefully none at all).
This will of course take me quite some time to pull off
(and of
Post by Joe Monk ***@gmail.com [hercules-390]
course there is the distinct possibility it may be entirely
beyond
Post by Joe Monk ***@gmail.com [hercules-390]
my capabilities too), so don't expect to see anything soon.
We're
Post by Joe Monk ***@gmail.com [hercules-390]
probably talking a multi-year effort here.
If anyone with both mainframe and C++ skills is interested in
helping, feel free to contact me off list.
[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://groups.yahoo.com/group/hercules-390>
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links
http://groups.yahoo.com/group/hercules-390/
<http://groups.yahoo.com/group/hercules-390/>
(Yahoo! ID required)
[Non-text portions of this message have been removed]
Alvin Schmitt schmitt_alvin@yahoo.com [hercules-390]
2017-01-14 06:18:38 UTC
Permalink
MR. Trout.  I bought the Hercules windows emulator from a guy on ebay for $10 - it was a CD. Just found out that you are the creator and that I do not own my copy. Glad to see that one person developed it and that you get your living off of it. I used IBM/360 model 50, 370, VM/MVS, TSO and CMS from about 1970 to 1981 and then 1983-1985  at Virginia Tech. I was a student, then research associate in Electrical Engineering and then a systems programmer working with glass ttys and the Series/1 running Yale IUP to emulate 3270 terminals on smart terminals. I even held the distinction of IPLing the machine during down time for my own testing.  Wrote one useful program on EDX using the series/1 emulated assembler program (somewhat like basic) to keep track of the various terminal types used for the administration to charge the various departments and for bureaucratic control. I joined the Hercules group and find the discussions interesting. Even though I am an electrical engineer with over 40 years experience and have a history with IBM I can't get a job because I was out of industry a few years and am 65.  Thanks for letting me share. Alvin P. Schmitt

APSTRON LLC
P.O. Box 201Newport VA 24128-0201

1-888-730-6478
http://www.apsministries.org/
   

On Friday, January 13, 2017 10:39 PM, "Ivan Warren ***@vmfacility.fr [hercules-390]" <hercules-***@yahoogroups.com> wrote:


  Let's write hercules in S/370, ESA and z/Arch assembler... Oh wait...

--Ivan
Post by Tony Harminc ***@gmail.com [hercules-390]
APL, like the original
...
Tony H.
Erlang or Brainfuck would be nice !
--Ivan
Post by Joe Monk ***@gmail.com [hercules-390]
Even better ... why not Swift?
Joe
[hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
Don't count on me...
I would have completely supported a hercules project that is
true
Post by Joe Monk ***@gmail.com [hercules-390]
to the
various PoPs...
But C++ ? Why not Java, Python or C# ?
Not my thing... Simple C is fine for me to implement those
architectures !
--Ivan
On 1/13/2017 11:09 PM, ''Fish' (David B. Trout)'
Post by Maarten Hoes ***@gmail.com [hercules-390]
<snip>
... until such time as I can finish development of
my own brand new version ...
<snip>
Wait, what ? i completely overlooked this bit. Im so
stoked now.
Post by Joe Monk ***@gmail.com [hercules-390]
Post by Maarten Hoes ***@gmail.com [hercules-390]
Details, please !
There are none. It's still being designed.
The only thing I can divulge is my intent (hope): to
completely
Post by Joe Monk ***@gmail.com [hercules-390]
rewrite Hercules in its entirety in C++, leveraging as
absolutely
Post by Joe Monk ***@gmail.com [hercules-390]
little of the existing code as possible (hopefully none at all).
This will of course take me quite some time to pull off
(and of
Post by Joe Monk ***@gmail.com [hercules-390]
course there is the distinct possibility it may be entirely
beyond
Post by Joe Monk ***@gmail.com [hercules-390]
my capabilities too), so don't expect to see anything soon.
We're
Post by Joe Monk ***@gmail.com [hercules-390]
probably talking a multi-year effort here.
If anyone with both mainframe and C++ skills is interested in
helping, feel free to contact me off list.
[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://groups.yahoo.com/group/hercules-390>
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links
http://groups.yahoo.com/group/hercules-390/
<http://groups.yahoo.com/group/hercules-390/>
(Yahoo! ID required)
[Non-text portions of this message have been removed]

#yiv3495518660 #yiv3495518660 -- #yiv3495518660ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3495518660 #yiv3495518660ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3495518660 #yiv3495518660ygrp-mkp #yiv3495518660hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv3495518660 #yiv3495518660ygrp-mkp #yiv3495518660ads {margin-bottom:10px;}#yiv3495518660 #yiv3495518660ygrp-mkp .yiv3495518660ad {padding:0 0;}#yiv3495518660 #yiv3495518660ygrp-mkp .yiv3495518660ad p {margin:0;}#yiv3495518660 #yiv3495518660ygrp-mkp .yiv3495518660ad a {color:#0000ff;text-decoration:none;}#yiv3495518660 #yiv3495518660ygrp-sponsor #yiv3495518660ygrp-lc {font-family:Arial;}#yiv3495518660 #yiv3495518660ygrp-sponsor #yiv3495518660ygrp-lc #yiv3495518660hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3495518660 #yiv3495518660ygrp-sponsor #yiv3495518660ygrp-lc .yiv3495518660ad {margin-bottom:10px;padding:0 0;}#yiv3495518660 #yiv3495518660actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3495518660 #yiv3495518660activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3495518660 #yiv3495518660activity span {font-weight:700;}#yiv3495518660 #yiv3495518660activity span:first-child {text-transform:uppercase;}#yiv3495518660 #yiv3495518660activity span a {color:#5085b6;text-decoration:none;}#yiv3495518660 #yiv3495518660activity span span {color:#ff7900;}#yiv3495518660 #yiv3495518660activity span .yiv3495518660underline {text-decoration:underline;}#yiv3495518660 .yiv3495518660attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv3495518660 .yiv3495518660attach div a {text-decoration:none;}#yiv3495518660 .yiv3495518660attach img {border:none;padding-right:5px;}#yiv3495518660 .yiv3495518660attach label {display:block;margin-bottom:5px;}#yiv3495518660 .yiv3495518660attach label a {text-decoration:none;}#yiv3495518660 blockquote {margin:0 0 0 4px;}#yiv3495518660 .yiv3495518660bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv3495518660 .yiv3495518660bold a {text-decoration:none;}#yiv3495518660 dd.yiv3495518660last p a {font-family:Verdana;font-weight:700;}#yiv3495518660 dd.yiv3495518660last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3495518660 dd.yiv3495518660last p span.yiv3495518660yshortcuts {margin-right:0;}#yiv3495518660 div.yiv3495518660attach-table div div a {text-decoration:none;}#yiv3495518660 div.yiv3495518660attach-table {width:400px;}#yiv3495518660 div.yiv3495518660file-title a, #yiv3495518660 div.yiv3495518660file-title a:active, #yiv3495518660 div.yiv3495518660file-title a:hover, #yiv3495518660 div.yiv3495518660file-title a:visited {text-decoration:none;}#yiv3495518660 div.yiv3495518660photo-title a, #yiv3495518660 div.yiv3495518660photo-title a:active, #yiv3495518660 div.yiv3495518660photo-title a:hover, #yiv3495518660 div.yiv3495518660photo-title a:visited {text-decoration:none;}#yiv3495518660 div#yiv3495518660ygrp-mlmsg #yiv3495518660ygrp-msg p a span.yiv3495518660yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3495518660 .yiv3495518660green {color:#628c2a;}#yiv3495518660 .yiv3495518660MsoNormal {margin:0 0 0 0;}#yiv3495518660 o {font-size:0;}#yiv3495518660 #yiv3495518660photos div {float:left;width:72px;}#yiv3495518660 #yiv3495518660photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv3495518660 #yiv3495518660photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv3495518660 #yiv3495518660reco-category {font-size:77%;}#yiv3495518660 #yiv3495518660reco-desc {font-size:77%;}#yiv3495518660 .yiv3495518660replbq {margin:4px;}#yiv3495518660 #yiv3495518660ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv3495518660 #yiv3495518660ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv3495518660 #yiv3495518660ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv3495518660 #yiv3495518660ygrp-mlmsg select, #yiv3495518660 input, #yiv3495518660 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv3495518660 #yiv3495518660ygrp-mlmsg pre, #yiv3495518660 code {font:115% monospace;}#yiv3495518660 #yiv3495518660ygrp-mlmsg * {line-height:1.22em;}#yiv3495518660 #yiv3495518660ygrp-mlmsg #yiv3495518660logo {padding-bottom:10px;}#yiv3495518660 #yiv3495518660ygrp-msg p a {font-family:Verdana;}#yiv3495518660 #yiv3495518660ygrp-msg p#yiv3495518660attach-count span {color:#1E66AE;font-weight:700;}#yiv3495518660 #yiv3495518660ygrp-reco #yiv3495518660reco-head {color:#ff7900;font-weight:700;}#yiv3495518660 #yiv3495518660ygrp-reco {margin-bottom:20px;padding:0px;}#yiv3495518660 #yiv3495518660ygrp-sponsor #yiv3495518660ov li a {font-size:130%;text-decoration:none;}#yiv3495518660 #yiv3495518660ygrp-sponsor #yiv3495518660ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv3495518660 #yiv3495518660ygrp-sponsor #yiv3495518660ov ul {margin:0;padding:0 0 0 8px;}#yiv3495518660 #yiv3495518660ygrp-text {font-family:Georgia;}#yiv3495518660 #yiv3495518660ygrp-text p {margin:0 0 1em 0;}#yiv3495518660 #yiv3495518660ygrp-text tt {font-size:120%;}#yiv3495518660 #yiv3495518660ygrp-vital ul li:last-child {border-right:none !important;}#yiv3495518660
Robert Prins robert.ah.prins@gmail.com [hercules-390]
2017-01-14 12:10:43 UTC
Permalink
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Don't count on me...
I would have completely supported a hercules project that is true to the
various PoPs...
But C++ ? Why not Java, Python or C# ?
Maybe because Fish seems to like <http://www.ncdm.com/bloat/bloat.htm>,
which is the "to-do" thing nowadays. Check his version of "HashCheck shell
extension" @ <http://www.softdevlabs.com/downloads.html> and compare the
size with the original... (And then think about the fact that he even uses
M$ API's rather than rolling his own code, which is what he implies the
original did!!!)

And seemingly, rather that trying to discuss and solve the issues he and
the other developers have with each other, he thinks it's better to create
yet another fork of Hercules (to massage his ego?)

If you want to rewrite Hercules, do it in x86 assembler, and, well
commented, that would/should be just as maintainable as C...

Hell, you can even let the C compiler do the initial heavy lifting, and use
the generated code as a template to write your own, which is what I'm doing
with some programs <https://goo.gl/ZN3XAB> I'm using to process the
hitchhike data I collect on-the-road. The "pure Pascal" version of the main
program generates 70,708 bytes of (user) code, and runs in 0.45 seconds,
the version that's been hacked to pieces by using in-line assembler
generates 46,916 bytes of (user) code. and runs in 0.23 seconds.

Of course portability suffers, but other than a few people, with more time
than sense ;), who seem to run Hercules on Raspberry Pi's, how many on this
list are actually running Hercules on non-x86/AMD64 architectures?

Robert

PS: And if an esoteric language version is needed? How about Malbolge?
--
Robert AH Prins
***@gmail.com
A little bit of (z/OS) programming @ <
https://prino.neocities.org/zOS/zOS%20Tools.html>
kerravon86@yahoo.com.au [hercules-390]
2017-01-14 12:22:23 UTC
Permalink
how many on this list are actually running
Hercules on non-x86/AMD64 architectures?
While most hobbyists are probably using
AMD64, I would have thought an integral
design goal of Hercules would be for
commercial users to be able to use a
SPARC machine or any other machine
they may choose to use, rather than
be constrained to what hobbyists have
at home.

BFN. Paul.
Robert Prins robert.ah.prins@gmail.com [hercules-390]
2017-01-14 12:37:11 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
how many on this list are actually running
Hercules on non-x86/AMD64 architectures?
While most hobbyists are probably using
AMD64, I would have thought an integral
design goal of Hercules would be for
commercial users to be able to use a
SPARC machine or any other machine
they may choose to use, rather than
be constrained to what hobbyists have
at home.
Now why would a commercial user want to run an old, no longer supported,
public domain version of an IBM operating system on a SPARC or other
machine?

I think the reason for using a SPARC or other machine is rather simple,
they don't want to pay IBM for z/OS...

Robert
--
Robert AH Prins
***@gmail.com
A little bit of (z/OS) programming @ <https://prino.neocities.org/
zOS/zOS%20Tools.html>
kerravon86@yahoo.com.au [hercules-390]
2017-01-14 12:46:15 UTC
Permalink
Post by Robert Prins ***@gmail.com [hercules-390]
Now why would a commercial user want
to run an old, no longer supported, public
domain version of an IBM operating
system on a SPARC or other machine?
I think the reason for using a SPARC or
other machine is rather simple, they
don't want to pay IBM for z/OS...
I can't predict the future. I do not know
if there are real-world applications that
can be run on MVS 3.8j, especially if
they are happy to use MVS/380 with
31-bit and 64-bit support.

I also don't know if a political decision
will be made to force IBM to sell z/OS
to non-IBM hardware like TurboHercules
was trying to do.

Also they could run z/Linux instead of
z/OS. Maybe one day z/PDOS will be
viable too.

When some viable combination becomes
available, if your code is in C, you are
ready. With no disadvantage compared
to x64 code.

BFN. Paul.
jsavit@mail.com [hercules-390]
2017-01-15 16:07:20 UTC
Permalink
I only lurk here now, but I'd like to speak up, as the person who first (I think) ported Hercules to Solaris on SPARC (and Intel, for that matter) very long ago around Hercules 2.17. [Obligatory disclaimer: I'm ex-Sun, and now Oracle. My comments represent my own opinions, and not that of my employer or anyone else] Why did I do the port? For fun, and because I was homesick for VM at the time.

SPARC stopped being a workstation product years ago, which makes it unreasonable for hobbyists unless you run rackmount servers or get an old, used workstation. The price for modern kit, and environmentals, make it less attractive for home use. I'm not saying people would not or should not do either of those, it's just that it's a less likely choice. Not as hard as putting a used z890 in the basement, since 1RU and 2RU servers are easy, but reduces the number of people willing to do it. By definition, Hercules fans run old OS versions on hardware it was not intended for, so a bigger challenge might even be an attraction for some.


SPARC certainly has good points and advantages to this very day, but they are not oriented towards the hobbyist or desktop user. I don't want to turn this into an advertisement or debate over computer families, as fun as that may be. Well, sure, I'm as game as the next guy, but am not interested a fight. More on that below.


On the OS side, Solaris 8 is ancient and I would not recommend anyone use it except for nostalgia, any more than I would suggest a Windows user be on NT or a Linux user be on Red Hat 3. If you want to run Solaris then I strongly suggest downloading Solaris 11, which is a very nice OS. It's not an eval copy, it's the full OS. Also: we don't bite, so download without fear. Since I spend much if not most of my time in Linux on x86 I'll add that there is indeed a modern port of Linux to SPARC, which can be downloaded for free and without even putting in your mail address. Just Google for 'sparc linux' - top 2 hits for me. I have it running.


Besides SPARC, there's also POWER, ARM, Itanium, and probably others. That's ample reason to not rewrite in x86 assembler (for goodness sake, why?) I also think it would be folly to start from scratch in any language and discard the tremendous engineering effort that has created Hercules. People who have infinite time on their hands surely can do what they think the most fun.


This all about hobbyist purposes, which means "practicaility" flies out the window anyway. I think the idea of transacting serious business on Hercules a very strange idea, and would not recommend it, regardless of chip set or which OS was being run. As to the 'pure, emulate actual mainframe families as they existed in the wild" vs. "emulate hopefully-better versions", I can see the arguments for both.


I haven't run Hercules in quite a while, as my motivation has lessened, and I have access to z/VM if I really want to stroll memory lane. But what disturbs me about Hercules is the strident tone that has crept in over the last few years, with sniping and personal attacks. Even if nothing else was going on, that would make me want to keep my distance from the project. That's one of the reasons I haven't posted in a long time, even when it was a fun thread, and I hope I don't regret making this post.


Jeff
Dave McGuire Mcguire@neurotica.com [hercules-390]
2017-01-15 16:46:58 UTC
Permalink
Post by ***@mail.com [hercules-390]
I only lurk here now, but I'd like to speak up, as the person who first
(I think) ported Hercules to Solaris on SPARC (and Intel, for that
matter) very long ago around Hercules 2.17.
Thank you for that!
Post by ***@mail.com [hercules-390]
SPARC stopped being a workstation product years ago, which makes it
unreasonable for hobbyists unless you run rackmount servers or get an
old, used workstation. The price for modern kit, and environmentals,
make it less attractive for home use. I'm not saying people would not or
should not do either of those, it's just that it's a less likely choice.
Not as hard as putting a used z890 in the basement, since 1RU and 2RU
servers are easy, but reduces the number of people willing to do it. By
definition, Hercules fans run old OS versions on hardware it was not
intended for, so a bigger challenge might even be an attraction for some.
This is a lot more common than you might think. There are four people
with rackmount servers in their homes on my block! ;)

Granted a very high density of smart people is one of the big reasons
I moved to this area, so this constitutes sample bias, but still. I
typically don't associate with people who don't have at least one rack
of computer equipment in their living space. ;)

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Gregg Levine gregg.drwho8@gmail.com [hercules-390]
2017-01-15 17:29:08 UTC
Permalink
Hello!
You also forgot about the historical systems standing around being
managed by individuals from far away...

I have a SPARC system running 11 March 2005 here...
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."
Post by Dave McGuire ***@neurotica.com [hercules-390]
Post by ***@mail.com [hercules-390]
I only lurk here now, but I'd like to speak up, as the person who first
(I think) ported Hercules to Solaris on SPARC (and Intel, for that
matter) very long ago around Hercules 2.17.
Thank you for that!
Post by ***@mail.com [hercules-390]
SPARC stopped being a workstation product years ago, which makes it
unreasonable for hobbyists unless you run rackmount servers or get an
old, used workstation. The price for modern kit, and environmentals,
make it less attractive for home use. I'm not saying people would not or
should not do either of those, it's just that it's a less likely choice.
Not as hard as putting a used z890 in the basement, since 1RU and 2RU
servers are easy, but reduces the number of people willing to do it. By
definition, Hercules fans run old OS versions on hardware it was not
intended for, so a bigger challenge might even be an attraction for some.
This is a lot more common than you might think. There are four people
with rackmount servers in their homes on my block! ;)
Granted a very high density of smart people is one of the big reasons
I moved to this area, so this constitutes sample bias, but still. I
typically don't associate with people who don't have at least one rack
of computer equipment in their living space. ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links
'Styma, Robert (Nokia - US)' robert.styma@nokia.com [hercules-390]
2017-01-16 12:59:19 UTC
Permalink
Oh, and the SunFreeware site is now subscription-only, which complicates getting GCC etc. for Solaris.

OpenCSW still has free GCC.

pkgadd -d http://get.opencsw.org/now

See my page: http://www.styma.org/SunAtHome/SunAtHome.shtml for notes on setting it up.
'Styma, Robert (Nokia - US)' robert.styma@nokia.com [hercules-390]
2017-01-16 12:54:43 UTC
Permalink
how many on this list are actually running
Hercules on non-x86/AMD64 architectures?
I have run Hercules on SPARC, once I got it to compile. Normally I use the CentOS version of Linux. I have never run it under Windows.
kerravon86@yahoo.com.au [hercules-390]
2017-01-14 13:34:21 UTC
Permalink
Post by Robert Prins ***@gmail.com [hercules-390]
If you want to rewrite Hercules, do it in
x86 assembler,
BTW, the fact that some people are still
advocating assembler is exactly why I
program in C90 exclusively. I would not
consider "upgrading" to a higher level
language while ever people exist who
are willing to write things in assembler
because it's more efficient.

I see C as the only serious competitor
to assembler, and if not C alone, then
mixed C & assembler.

BFN. Paul.
Dave McGuire Mcguire@neurotica.com [hercules-390]
2017-01-14 17:14:18 UTC
Permalink
Post by Robert Prins ***@gmail.com [hercules-390]
If you want to rewrite Hercules, do it in x86 assembler, and, well
commented, that would/should be just as maintainable as C...
Wow, I sure am glad there's nobody here with a sufficient level of
utter blithering stupidity who would actually implement such a suggestion.

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Gregg Levine gregg.drwho8@gmail.com [hercules-390]
2017-01-14 17:49:05 UTC
Permalink
Hello!
And this is from someone who works surrounded by a few hundred monsters.........

Besides take a look at the earlier ones.

I first ran Hercules on X86 Linux, and then under Windows who was an
X64 build. Now largely on Raspberry Pi.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."
Post by Dave McGuire ***@neurotica.com [hercules-390]
Post by Robert Prins ***@gmail.com [hercules-390]
If you want to rewrite Hercules, do it in x86 assembler, and, well
commented, that would/should be just as maintainable as C...
Wow, I sure am glad there's nobody here with a sufficient level of
utter blithering stupidity who would actually implement such a suggestion.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links
kerravon86@yahoo.com.au [hercules-390]
2017-01-14 08:52:33 UTC
Permalink
Second attempt to post. First attempt was
around 10 hours ago ...
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
The only thing I can divulge is my intent
(hope): to completely rewrite Hercules
in its entirety in C++
Hmmm. I was hoping for what is almost
the exact opposite.

I would like to be able to be able to build
Hercules with a C90 compiler with zero
extensions (PDPCLIB has no extensions).

Basically if I have a C90-compliant compiler
with 32-bit ints and 64-bit longs and pointers,
I would like to do one of:

gcc *.c
gcc -DPUREISO *.c
gcc -DPUREC90 *.c

and have a standalone hercules.exe

(assuming I have deleted/moved away
other C programs like hetget.c)

I can start Hercules like this:

hercules >log\hercules.log 2>&1

And have it automatically start MVS,
run a batch job which reads and
writes emulated tapes and emulated
disks, and terminate.

All of the above (reading and writing
files) is covered by the C90 standard.
No extensions are required.

When run like the above, I do not need
to see the Hercules integrated console,
so don't need all the non-standard
functions to do that. Nor do I need
TCP/IP, so don't need those functions.
I also (no longer) require pauses in
my Hercules scripts, so I don't need
the non-C90 sleep/usleep to work.

I don't mind if non-standard C functions
like socket() are either:

1. Not called.
2. A dummy version that returns success
and does nothing.
3. A dummy version that returns failure
and does nothing.

Also functions like open() I already have
"stubs" that call fopen(). I needed that
to produce a C90-compliant GCC ready
for porting to MVS.

BTW, normally when I code a large C
program, I do it in an object-oriented
way, so that hopefully my C code has
the same cleanliness as C++ code.

So using the FILE typedef as an
example, I would code:

fileOpen(FILE *fp, "filename.txt", "r");
fileRead(FILE *fp, char *buf, etc);

You can see a real example here:

https://sourceforge.net/projects/pdos/files/pdpzm/PDPZM%201.08/


My ultimate goal is to be stuck on a
desert island with a 64-bit x64 processor,
PDOS/x64, 64-bit C90-compliant Hercules,
MVS/380, GCCMVS and then I can spend
my time writing C utilities that work on
MVS as ANY/ANY modules and on a
64-bit PCDOS-like and a 32-bit PCDOS-like
and real PCDOS (of which PDOS/x86 is
a (very) limited clone.

And I will have the tools required to
improve on this position until I die, ie
produce a decent PDOS/390 and
z/PDOS and z/GCC.

The operating systems and the C
libraries and generated C utilities
will all be pubic domain, while GCC
and Hercules will be virus-licensed.
But theoretically I will have the tools
to eventually replace the virus
licensed code with public domain
alternatives, or if someone else
gets marooned on the desert island
they may have the skills and willingness
to generate public domain replacements.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-01-16 00:29:14 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
My ultimate goal is to be stuck on a
desert island with a 64-bit x64 processor,
PDOS/x64, 64-bit C90-compliant Hercules,
MVS/380, GCCMVS and then I can spend
my time writing C utilities that work on
MVS as ANY/ANY modules and on a
64-bit PCDOS-like and a 32-bit PCDOS-like
and real PCDOS (of which PDOS/x86 is
a (very) limited clone.
Actually, I just realized that since I'm really
only interested in generating ANY/ANY
modules on MVS/380 for MVS 3.8j and
z/OS targets, and also I want other Unix
developers to start adding these targets
for their projects (diffutils etc), that I only
need 31/32-bit software.

So I need PDOS/386 (already exists),
with a 80386 GCC+PDPCLIB (already
exists), a 32-bit C90 Hercules clone
(discussing now), 31-bit MVS version
of GCC + PDPCLIB (already exists).

Since my target audience is Unix
projects like info-zip who no longer
support MVS because they don't
have access to it, my hope is that
they can run a C90 Hercules to
just do the simple task of running
a batch job. They don't need to
learn about or see consoles or
configure tcp/ip.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-01-16 00:39:29 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Basically if I have a C90-compliant compiler
with 32-bit ints and 64-bit longs and pointers,
gcc *.c
gcc -DPUREISO *.c
gcc -DPUREC90 *.c
Actually, I'd also like to be able to use
Borland C++ (32-bit longs, no "long
long") to build a version of Hercules.

If I do:

gcc *.c

then if sizeof(long) is >= 8 then 64-bit
operations like LGR should be enabled.

Otherwise, only 32-bit instructions like
LR should be enabled (ie a more
restrictive subset of z/Arch+).

It would also be useful to have an
option:

gcc -DUSELL *.c

to force the non-C90 "long long" type
to be used in order to provide 64-bit
capability using Microsoft C on Windows.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-01-21 03:17:01 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Actually, I'd also like to be able to use
Borland C++ (32-bit longs, no "long
long") to build a version of Hercules.
Assuming I have a C90 semi-clone of
Hercules, and I do:

bcc32 *.c

and then I attempt to execute this
workload on it:

https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/80885

will it actually be technically possible?

Note that when an SIO instruction is
executed, I expect it to do the I/O
straight away before returning, rather
than sending the I/O off to a separate
task (since there is no such thing as
a "separate task" in C90).

I am wondering whether running the
above workload will be totally
deterministic and reproducible
because there are no timing
sensitivities introduced by multitasking.

Or is it likely that I would run into
some sort of logic problem where
I would end up waiting on an ECB
which is impossible to ever be
posted, because of the single
threaded nature of the proposed
C90 emulator?

Or perhaps waiting on some sort
of timer, but there is difficulty
implementing (or faking) timers.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-01-21 03:48:47 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Note that when an SIO instruction is
executed, I expect it to do the I/O
straight away before returning, rather
than sending the I/O off to a separate
task (since there is no such thing as
a "separate task" in C90).
Also I am wondering what the expected
performance of such a "C90 Hercules clone"
would be, assuming two different usages:

1. Long-running CPU-bound GCC compiles.
I would assume that the C90 version will
be almost as fast as normal Hercules for all
practical purposes.

2. An IPL, then running a quick IEBGENER,
then shutting down. Without the benefit of
multitasking, I can imagine this being about
10% slower, but I suspect that most time is
still tied up in the CPU, and I am running
MVS 3.8j with a single CPU, so I'm again
not expecting to see much difference.

BFN. Paul.

'Styma, Robert (Nokia - US)' robert.styma@nokia.com [hercules-390]
2017-01-16 12:50:30 UTC
Permalink
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
The only thing I can divulge is my intent
(hope): to completely rewrite Hercules
in its entirety in C++
C++ tends to vary in its implementation across platforms. I run Hercules under Linux (CentOS 6). Would your rewrite make Hercules Windows Only or do you plan to jump through the hoops to have it run across platforms.
kerravon86@yahoo.com.au [hercules-390]
2017-01-15 02:48:47 UTC
Permalink
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
The only thing I can divulge is my intent
(hope): to completely rewrite Hercules
in its entirety in C++, leveraging as
absolutely little of the existing code as
possible (hopefully none at all).
I've thought some more about this,
and have the following suggestions:

1. Make it C90, not C++
2. Make it public domain, without caveats
3. Focus on Jujitsu z/Arch+ as the first architecture.
4. Within z/Arch+ concentrate on the
S/370 instructions plus BSM so that
both MVS 3.8j and MVS/380 can run.
5. Concentrate on what can be done
in standard C90 first, before adding
non-C90 stuff like console windows
and TCP/IP.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-01-15 05:28:11 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
1. Make it C90, not C++
2. Make it public domain, without caveats
BTW, as public domain C90 code, I
would be *far* more willing to
contribute, because it is actually one
of my life goals to have public domain
C90 versions of all the software I use.
So this would save me from having
to (eventually) write my own version
of Hercules.

It is also my intention (or at least, I
pretend it is), that once I have
public domain versions of all the
software I use, that I will then use
that software as a base for my
own proprietary (and probably
closed source) software which
I would sell as a competitor to
the public domain version.

I'm not likely to achieve that before
I die, but I'm happy traveling on
this road.

BFN. Paul.
somitcw@yahoo.com [hercules-390]
2017-01-15 17:17:43 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
The only thing I can divulge is my intent
(hope): to completely rewrite Hercules
in its entirety in C++, leveraging as
absolutely little of the existing code as
possible (hopefully none at all).
I've thought some more about this,
1. Make it C90, not C++
2. Make it public domain, without caveats
3. Focus on Jujitsu z/Arch+ as the first architecture.
. Within z/Arch+ concentrate on the
S/370 instructions plus BSM so that
both MVS 3.8j and MVS/380 can run.
5. Concentrate on what can be done
in standard C90 first, before adding
non-C90 stuff like console windows
and TCP/IP.
BFN. Paul.
Noooooooooooooo. Forget anything called Jujitsu.

We need a S/360 with all upward compatible
updates that IBM has made.

S/360-24bit had restrictions of:
24-bit real memory limit
24-bit addressing limit.
No virtual memory.

IBM killed those restrictions with upward compatible:
24-bit real memory limit
24-bit addressing limit.
Virtual memory
New instructions

Mainframes that don't allow paging are dead.
Get over it.

IBM killed another restriction with upward compatible:
26-bit real memory limit
24-bit addressing limit.
Kept virtual memory
Still more new instructions

Mainframes that don't allow 26-bit real memory are dead.
Get over it.

IBM killed more restrictions with both upward compatible
and non-upward compatibility:
31-bit real memory limit
31-bit addressing limit.
Kept virtual memory
Still more new instructions.
Broke upward compatibility with I/O.
We want upward compatibility, not S/370-31bit I/O
except possibly as a never used option.

Mainframes that don't allow 31-bit real and virtual
memory are dead.
Get over it.

IBM killed more restrictions with upward compatible:
64-bit real memory limit
64-bit addressing limit.
Kept virtual memory
Still more new instructions.

Mainframes that don't allow 64-bit real and virtual
memory are dead.
Get over it.

The new architecture could be called
S/360-upward or S36U for short.

When there is an instruction conflict, use the one
that makes the most sense.
Read direct and write direct are dead. Leave them there.
Same for any vector instruction op-code that duplicate
newer instructions if any.
S/370-24bit ISKE, RRBE, SSKE, and TB are better than
S/370-32bit instructions. That is to say that if someone
specified the extra bits, use them.
Same for obsolete and dead RSX instruction format that
were replaced with upward compatible RXY.
somitcw@yahoo.com [hercules-390]
2017-01-15 17:51:17 UTC
Permalink
- - - In hercules-***@yahoogroups.com, <***@...> wrote:
- - - most snipped - - -
Post by ***@yahoo.com [hercules-390]
Same for obsolete and dead RSX instruction format that
were replaced with upward compatible RXY.
Of course I meant that RXE instruction format was killed
when replaced with RXY.

Unless I scrambled the letters again?
Harold Grovesteen h.grovsteen@tx.rr.com [hercules-390]
2017-01-16 16:30:42 UTC
Permalink
RXE still survives in some floating point instructions. Not all RXE
instructions got the "upgrade" to a 20-bit displacement.
Post by ***@yahoo.com [hercules-390]
- - - most snipped - - -
Post by ***@yahoo.com [hercules-390]
Same for obsolete and dead RSX instruction format that
were replaced with upward compatible RXY.
Of course I meant that RXE instruction format was killed
when replaced with RXY.
Unless I scrambled the letters again?
somitcw@yahoo.com [hercules-390]
2017-01-16 17:00:20 UTC
Permalink
RXE still survives in some floating point instructions. Not all RXE
instructions got the "upgrade" to a 20-bit displacement.
- - - remainder snipped - - -

It's old, but:
SA22-7832-08.zArch.Principles.of.Operations.Aug.2010.pdf
Page xxxviii
z/Architecture Principles of Operation
"All previously existing format-RSE and for-
mat-RXE instructions are changed to be of
formats RSY and RXY, respectively, by use
of a previously unused byte in the instruc-
tions."

Assuming that the old zArch Principles of Operations
made a misstatement,
RXY is upward compatible from RXE.

There is no need for RXE.
IBM killed it and no one has need for it.
Even if Hercules had beat IBM to the punch replacing
all RXE with RXY, that would cause no problem.

RXE was incomplete.
RXY allows the use of the previous unused bits.

Same for RSE being replaced with RSY.
Harold Grovesteen h.grovsteen@tx.rr.com [hercules-390]
2017-01-16 17:39:01 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
RXE still survives in some floating point instructions. Not all RXE
instructions got the "upgrade" to a 20-bit displacement.
- - - remainder snipped - - -
SA22-7832-08.zArch.Principles.of.Operations.Aug.2010.pdf
Page xxxviii
z/Architecture Principles of Operation
"All previously existing format-RSE and for-
mat-RXE instructions are changed to be of
formats RSY and RXY, respectively, by use
of a previously unused byte in the instruc-
tions."
Yes. But in that same PoO (-08), see the BFP ADD instructions AEB or ADB
on page 19-11. These are still documented with RXE and the correct bit
usage in the format for RXE. As of the latest PoO, -10 (Mar. 2015) on
page 19-15, these same instructions, and others, still show RXE.
Appendix B also still shows them to be RXE. So, in five years nobody
found the incorrect description for these instructions (and others).

I guess the only way to know for sure is see what real hardware does.
But my bet is that the PoO is correct for the individual instructions
and that the 2010 summary statement should have have had some qualifier
like "all previously existing _binary/logical_ instructions" etc.
Post by ***@yahoo.com [hercules-390]
Assuming that the old zArch Principles of Operations
made a misstatement,
RXY is upward compatible from RXE.
There is no need for RXE.
IBM killed it and no one has need for it.
Even if Hercules had beat IBM to the punch replacing
all RXE with RXY, that would cause no problem.
RXE was incomplete.
RXY allows the use of the previous unused bits.
Same for RSE being replaced with RSY.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-16 17:57:40 UTC
Permalink
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
I guess the only way to know for sure is see what real hardware does.
What do you mean by "real hardware" ?

--Ivan




[Non-text portions of this message have been removed]
somitcw@yahoo.com [hercules-390]
2017-01-16 20:58:36 UTC
Permalink
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
Post by ***@yahoo.com [hercules-390]
RXE still survives in some floating point instructions. Not all RXE
instructions got the "upgrade" to a 20-bit displacement.
- - - remainder snipped - - -
SA22-7832-08.zArch.Principles.of.Operations.Aug.2010.pdf
Page xxxviii
z/Architecture Principles of Operation
"All previously existing format-RSE and for-
mat-RXE instructions are changed to be of
formats RSY and RXY, respectively, by use
of a previously unused byte in the instruc-
tions."
Yes. But in that same PoO (-08), see the BFP ADD instructions
AEB or ADB on page 19-11. These are still documented with
RXE and the correct bit usage in the format for RXE. As of the
latest PoO, -10 (Mar. 2015) on page 19-15, these same
instructions, and others, still show RXE.
Appendix B also still shows them to be RXE. So, in five years
nobody found the incorrect description for these instructions
(and others).
If you find the zArch confusing, I suggest that you contact IBM.
I can't help you.
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
I guess the only way to know for sure is see what real hardware does.
But my bet is that the PoO is correct for the individual instructions
and that the 2010 summary statement should have have had some
qualifier like "all previously existing _binary/logical_ instructions" etc.
No, I disagree totally.
I would go by what is in the zArch Principal of Operations.
RSE and RXE are dead.
RSE and RXE no longer had a use.
IBM didn't want to confuse or break the
long-displacement facility so killed them.
IBM could not sell one machine by adding an
obnoxious restriction to keep RSE and RXE.

When IBM drops a restriction, let it die.

Even older than 2010, as in 2003:

SA22-7832-02.zArch.Principles.of.Operations.Jun.2003.pdf
Page xxii to xxiii
"All previously existing format-RSE and
format-RXE instructions are changed to be
of formats RSY and RXY, respectively, by
use of a previously unused byte in the
instructions. These changes are not
marked by a bar in the margin."
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
Assuming that the old zArch Principles of Operations
made a misstatement,
RXY is upward compatible from RXE.
There is no need for RXE.
IBM killed it and no one has need for it.
Even if Hercules had beat IBM to the punch replacing
all RXE with RXY, that would cause no problem.
RXE was incomplete.
RXY allows the use of the previous unused bits.
Same for RSE being replaced with RSY.
kerravon86@yahoo.com.au [hercules-390]
2017-01-16 01:09:59 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
3. Focus on Jujitsu z/Arch+ as the first architecture.
Noooooooooooooo. Forget anything called Jujitsu.
We need
I thought what you wanted was S/370
I/O combined with XA DAT?

No IBM machine was ever built that
did that.

Jujitsu has a machine that does that
though. It does more than that in
fact, and comes closer to Fujitsu's
"proposed" z/Arch+ than any other
vendor.

Where do you propose getting the
specs for the machine that you
want from? Would you prefer that
we call it "somitcw architecture"?
I'm happy to do that if you want,
because "what's in a name?".

BFN. Paul.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-01-16 01:28:02 UTC
Permalink
"No IBM machine was ever built that
did that."

As you will note, the 4381 is a S/370 system that is capable of running XA.
It uses S370 style IO.

Joe
Post by ***@yahoo.com.au [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
3. Focus on Jujitsu z/Arch+ as the first architecture.
Noooooooooooooo. Forget anything called Jujitsu.
We need
I thought what you wanted was S/370
I/O combined with XA DAT?
No IBM machine was ever built that
did that.
Jujitsu has a machine that does that
though. It does more than that in
fact, and comes closer to Fujitsu's
"proposed" z/Arch+ than any other
vendor.
Where do you propose getting the
specs for the machine that you
want from? Would you prefer that
we call it "somitcw architecture"?
I'm happy to do that if you want,
because "what's in a name?".
BFN. Paul.
somitcw@yahoo.com [hercules-390]
2017-01-16 02:03:17 UTC
Permalink
"No IBM machine was ever built that did that."
As you will note, the 4381 is a S/370 system that is
capable of running XA. It uses S370 style IO.
Joe
- - - old notes snipped - - -

No.

The highest end of 4381 could either run:
1. S370-24bit
or
2. S370-31bit

To switch, we had to shut the system down to
something like "bios" level, and run a program
to switch it to either S370-24bit or S370-31bit.
Then boot in the mode that we had selected.

In S370-24bit mode, it was a S370-24bit system.

In S370-31bit mode, it was a S370-31bit system.
kerravon86@yahoo.com.au [hercules-390]
2017-01-16 02:22:36 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
In S370-24bit mode, it was a S370-24bit system.
And presumably with S/370 I/O.
Post by ***@yahoo.com [hercules-390]
In S370-31bit mode, it was a S370-31bit system.
And presumably with S/390 I/O.

BFN. Paul.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-01-16 02:42:16 UTC
Permalink
"And presumably with S/390 I/O."

Nope.

4381 was a S/370 system.

Joe
Post by ***@yahoo.com.au [hercules-390]
Post by ***@yahoo.com [hercules-390]
In S370-24bit mode, it was a S370-24bit system.
And presumably with S/370 I/O.
Post by ***@yahoo.com [hercules-390]
In S370-31bit mode, it was a S370-31bit system.
And presumably with S/390 I/O.
BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-01-16 02:52:23 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com [hercules-390]
In S370-31bit mode, it was a S370-31bit system.
And presumably with S/390 I/O."
Nope.
4381 was a S/370 system.
I might have used the wrong terminology.

My point is that the 4381 when in
S/370 31-bit mode (ie supporting
an XA DAT), it did NOT support the
S/370 I/O instruction "SIO", it
instead *only* support SSCH,
whatever that is called.

Bottom line - it is NOT the non-standard
machine that somitcw is after, which
is S/370 I/O combined with XA DAT.
No such machine was ever created
by IBM.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-01-16 04:36:36 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Bottom line - it is NOT the non-standard
machine that somitcw is after, which
is S/370 I/O combined with XA DAT.
No such machine was ever created
by IBM.
And also no operating system was
produced (or at least, released, at
least by IBM) that could run on
such a machine, even if it did exist.

As far as I can tell, anyway.

BFN. Paul.
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2017-01-16 10:39:44 UTC
Permalink
Two machines were built to support the XA effort. They ran "Newson's
tool", a highly modified VM/370 release 3.

I have seen them running.
Post by ***@yahoo.com.au [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
Bottom line - it is NOT the non-standard
machine that somitcw is after, which
is S/370 I/O combined with XA DAT.
No such machine was ever created
by IBM.
And also no operating system was
produced (or at least, released, at
least by IBM) that could run on
such a machine, even if it did exist.
As far as I can tell, anyway.
BFN. Paul.
somitcw@yahoo.com [hercules-390]
2017-01-16 15:34:41 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com [hercules-390]
In S370-31bit mode, it was a S370-31bit system.
And presumably with S/390 I/O."
Nope.
4381 was a S/370 system.
I might have used the wrong terminology.
My point is that the 4381 when in
S/370 31-bit mode (ie supporting
an XA DAT), it did NOT support the
S/370 I/O instruction "SIO", it
instead *only* support SSCH,
whatever that is called.
Bottom line - it is NOT the non-standard
machine that somitcw is after, which
is S/370 I/O combined with XA DAT.
No such machine was ever created
by IBM.
BFN. Paul.
A 4381 is not related to my suggestion for a S/360
with upward compatible features not blocked..

You constant descriptions of your opinion of
my suggested S/360 with upward compatible
features not blocked is twisted.
'au1john' au1john@yahoo.com.au [hercules-390]
2017-01-16 03:08:04 UTC
Permalink
Try this, https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP4381.html and read both pages (the Next -> at the bottom).



Admittedly it is “marketing” stuff, but it does show that certain 4381’s were indeed XA capable and all that that implies.





John

From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Monday, 16 January 2017 13:42
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-390] Re: Hercules status








"And presumably with S/390 I/O."



Nope.



4381 was a S/370 system.



Joe
Post by ***@yahoo.com [hercules-390]
In S370-24bit mode, it was a S370-24bit system.
And presumably with S/370 I/O.
Post by ***@yahoo.com [hercules-390]
In S370-31bit mode, it was a S370-31bit system.
And presumably with S/390 I/O.

BFN. Paul.
Laddie Hanus laddiehanus@yahoo.com [hercules-390]
2017-01-16 03:55:00 UTC
Permalink
I think all 4381's were XA capable. I installed MVS/XA on one in 1984 shortly after the 4381 became available. It had an option to select 370 or 370/XA. Never ran MVS/SP 1.3 on it as it was only licensed on the 4341

Laddie Hanus

Sent from whatever device I am using.
Post by 'au1john' ***@yahoo.com.au [hercules-390]
Try this, https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP4381.html and read both pages (the Next -> at the bottom).
Admittedly it is “marketing” stuff, but it does show that certain 4381’s were indeed XA capable and all that that implies.
John
Sent: Monday, 16 January 2017 13:42
Subject: Re: [hercules-390] Re: Hercules status
"And presumably with S/390 I/O."
Nope.
4381 was a S/370 system.
Joe
Post by ***@yahoo.com [hercules-390]
In S370-24bit mode, it was a S370-24bit system.
And presumably with S/370 I/O.
Post by ***@yahoo.com [hercules-390]
In S370-31bit mode, it was a S370-31bit system.
And presumably with S/390 I/O.
BFN. Paul.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-16 03:26:48 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
"And presumably with S/390 I/O."
Nope.
4381 was a S/370 system.
Joe
the 4381 was either a S/370 or an XA system... It could do both.

It was a matter of how you IMLed it.

--Ivan


[Non-text portions of this message have been removed]
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-16 03:29:55 UTC
Permalink
Read :

https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP4381.html

Read last paragraph :

Support for both System/370 and System/370 extended architecture (XA)
operating systems enables the 4381 to meet the growth and operating
system requirements of the smallest System/360, System/370 and 4300
users, while being compatible with the most powerful 308X processors
offered by IBM.

--Ivan
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
"And presumably with S/390 I/O."
Nope.
4381 was a S/370 system.
Joe
the 4381 was either a S/370 or an XA system... It could do both.
It was a matter of how you IMLed it.
--Ivan
[Non-text portions of this message have been removed]
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links
[Non-text portions of this message have been removed]
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-16 03:35:35 UTC
Permalink
And yes.. I have run VM/XA SP2.1 on a 4381 P21 (with OEM 32MB memory on
it).... In production for a real estate company

And it didn't go smoothly (since VM/XA SP2.1 didn't have native BSC
support for remote 3x74 controllers).

Yes - it was sometime ago (early 90s)

--Ivan
Post by 'au1john' ***@yahoo.com.au [hercules-390]
https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP4381.html
Support for both System/370 and System/370 extended architecture (XA)
operating systems enables the 4381 to meet the growth and operating
system requirements of the smallest System/360, System/370 and 4300
users, while being compatible with the most powerful 308X processors
offered by IBM.
--Ivan
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
"And presumably with S/390 I/O."
Nope.
4381 was a S/370 system.
Joe
the 4381 was either a S/370 or an XA system... It could do both.
It was a matter of how you IMLed it.
--Ivan
[Non-text portions of this message have been removed]
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links
[Non-text portions of this message have been removed]
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links
[Non-text portions of this message have been removed]
somitcw@yahoo.com [hercules-390]
2017-01-16 15:29:12 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
"And presumably with S/390 I/O."
Nope.
4381 was a S/370 system.
Joe
- - - old notes snipped - - -

A high-end 4381 could run in either
S/370-24bit mode
or
S/370-31bit mode
but not both at the same time.

When in S/370-24bit mode, it ran as a S/370-24bit system.
When in S/370-31bit mode, it ran as a S/370-31bit system.

No cross-over.
No convolutions.
Straight out one or the other.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-16 15:44:05 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
"And presumably with S/390 I/O."
Nope.
4381 was a S/370 system.
Joe
- - - old notes snipped - - -
A high-end 4381 could run in either
S/370-24bit mode
or
S/370-31bit mode
but not both at the same time.
When in S/370-24bit mode, it ran as a S/370-24bit system.
When in S/370-31bit mode, it ran as a S/370-31bit system.
No cross-over.
No convolutions.
Straight out one or the other.
In 31 bit mode it ran as a S/370 XA system.... with XA I/O ! (and it is
more akin to ESA/390 mode).

Not all 4381 models running in XA mode had the full ESA capabilities
(for example, they didn't all have the Access Register type of DAT)... I
think it only appeared in the 4381 Models 92 & 93...

Same for a 3090 (Only models J were ESA capable AFAIK - Others were only
S/370 and XA only).

--Ivan



[Non-text portions of this message have been removed]
Gerhard Postpischil gerhardp@charter.net [hercules-390]
2017-01-16 16:24:40 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
When in S/370-24bit mode, it ran as a S/370-24bit system.
When in S/370-31bit mode, it ran as a S/370-31bit system.
IIRC, the 4341 and 4381 came with two channel sets of four channels
each, but the second was not available efficiently in S/370 mode. I
found out the hard way - while I was away at a conference, one of my
employees decided to make the system more efficient by changing the NCR/
Comten front-end to its own channel (channel 0 on second channel set).
Lo and behold, remote lines and users kept dropping like flies until I
made him recable things. To this day I don't think he understands why he
had problems.

Gerhard Postpischil
Bradford, VT
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-16 16:26:17 UTC
Permalink
Post by Gerhard Postpischil ***@charter.net [hercules-390]
Post by ***@yahoo.com [hercules-390]
When in S/370-24bit mode, it ran as a S/370-24bit system.
When in S/370-31bit mode, it ran as a S/370-31bit system.
IIRC, the 4341 and 4381 came with two channel sets of four channels
each, but the second was not available efficiently in S/370 mode. I
found out the hard way - while I was away at a conference, one of my
employees decided to make the system more efficient by changing the NCR/
Comten front-end to its own channel (channel 0 on second channel set).
Lo and behold, remote lines and users kept dropping like flies until I
made him recable things. To this day I don't think he understands why he
had problems.
Gerhard Postpischil
Bradford, VT
The answer was :

Disable SIOFQ !

--Ivan



[Non-text portions of this message have been removed]
Gerhard Postpischil gerhardp@charter.net [hercules-390]
2017-01-17 02:15:17 UTC
Permalink
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Disable SIOFQ !
What was the question <g>

The problem was that MVS spent a lot of time on shoulder taps between
CPUs, and couldn't keep up with the traffic. I'm not sure that disabling
fast I/O would have helped, and I don't remember that as a sysgen option.

It wasn't until X/A that the I/O handler was modified to use multiple
CPUs properly.

Gerhard Postpischil
Bradford, VT
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-17 05:19:57 UTC
Permalink
Post by Gerhard Postpischil ***@charter.net [hercules-390]
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Disable SIOFQ !
What was the question <g>
The problem was that MVS spent a lot of time on shoulder taps between
CPUs, and couldn't keep up with the traffic. I'm not sure that disabling
fast I/O would have helped, and I don't remember that as a sysgen option.
It wasn't until X/A that the I/O handler was modified to use multiple
CPUs properly.
Gerhard Postpischil
Bradford, VT
The problem was that if you had a 2 channel switch on a 3880, and you
had SIOFQ enabled in the CPU (it wasn't a OS option, it was an option in
the 4381), then the OS was never made aware an I/O could not be directly
scheduled on another channel (the I/O was just queued by the channel
subsystem if it was busy doing something else) - so you had an I/O
queued on a channel even though you could have presented it on another
channel (this is not associated with the number of CPUs you had on your
system).

This was only an issue S/370, not in XA as the I/O would have been
automatically been presented to a channel which was available (SSCH
applies to a subchannel - which can have multiple CHPIDs - NOT a CCUU)

The I/O *interrupt* handler in XA was modified because the I/O interrupt
was made floating in XA (that is, an I/O interrupt can occur on any CPU
- without regard of the CPU that issued the I/O request - it wasn't in
S/370).

So the big diff is that XA dissociates the CPU from the Channel
subsystem - whereas in S/370 each CPU is associated with a Channel Set.

--Ivan



[Non-text portions of this message have been removed]
Gerhard Postpischil gerhardp@charter.net [hercules-390]
2017-01-17 16:15:36 UTC
Permalink
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
The problem was that if you had a 2 channel switch on a 3880, and you
had SIOFQ enabled in the CPU (it wasn't a OS option, it was an option in
the 4381), then the OS was never made aware an I/O could not be directly
scheduled on another channel (the I/O was just queued by the channel
subsystem if it was busy doing something else) - so you had an I/O
queued on a channel even though you could have presented it on another
channel (this is not associated with the number of CPUs you had on your
system).
I'm not sure what you're describing. There was no two-channel switch,
unless there was a hidden one in the 4381 channel logic. The NCR/Comten
was a TP front end, with better features than IBM's, and only a single
channel.

As to SIOFQ, at the time we had third-party maintenance, and possibly
the C.E. didn't know about it.

Gerhard Postpischil
Bradford, VT
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-01-17 18:04:02 UTC
Permalink
Post by Gerhard Postpischil ***@charter.net [hercules-390]
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
The problem was that if you had a 2 channel switch on a 3880,
[...]
Post by Gerhard Postpischil ***@charter.net [hercules-390]
I'm not sure what you're describing. There was no two-channel
switch, unless there was a hidden one in the 4381 channel logic.
<snip>

The 3880 dasd controller most certainly *did* have a 2 channel switch. It in fact supported up to eight channels being connected. And none of them were required to be connected to the same processor either. It also had a string switch feature too. We used both features quite extensively at one of the last shops I worked at.

Refer to Chapter 1 of manual GA26-1661-09 "3880 Storage Control Models 1, 2, 3 and 4 Description Manual".
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Dave McGuire Mcguire@neurotica.com [hercules-390]
2017-01-17 20:05:53 UTC
Permalink
On 01/17/2017 01:04 PM, ''Fish' (David B. Trout)'
Post by Maarten Hoes ***@gmail.com [hercules-390]
Post by Gerhard Postpischil ***@charter.net [hercules-390]
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
The problem was that if you had a 2 channel switch on a 3880,
[...]
Post by Gerhard Postpischil ***@charter.net [hercules-390]
I'm not sure what you're describing. There was no two-channel
switch, unless there was a hidden one in the 4381 channel logic.
<snip>
The 3880 dasd controller most certainly *did* have a 2 channel switch.
It in fact supported up to eight channels being connected. And none of
them were required to be connected to the same processor either. It also
had a string switch feature too. We used both features quite extensively
at one of the last shops I worked at.
Refer to Chapter 1 of manual GA26-1661-09 "3880 Storage Control Models
1, 2, 3 and 4 Description Manual".
Let me know if you want some quick pictures of a 3880 control panel! B-)

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-17 20:45:48 UTC
Permalink
Post by Maarten Hoes ***@gmail.com [hercules-390]
Post by Gerhard Postpischil ***@charter.net [hercules-390]
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
The problem was that if you had a 2 channel switch on a 3880,
[...]
Post by Gerhard Postpischil ***@charter.net [hercules-390]
I'm not sure what you're describing. There was no two-channel
switch, unless there was a hidden one in the 4381 channel logic.
<snip>
The 3880 dasd controller most certainly *did* have a 2 channel switch. It in fact supported up to eight channels being connected. And none of them were required to be connected to the same processor either. It also had a string switch feature too. We used both features quite extensively at one of the last shops I worked at.
Refer to Chapter 1 of manual GA26-1661-09 "3880 Storage Control Models 1, 2, 3 and 4 Description Manual".
I think the thing Gerhard describes is that he was having an issue with
a Control Unit (a NCR Comten communication controler) connected on
Channel 0 (which on a 4381 is a Byte Muliplexor), and because he had an
MP system, any work/request given from a CPU to which the channel which
connected to the Comm Controller required some processor switch. Since
working with a controller, especially in EP mode required a lot of I/Os,
this could very heavily overwhelm any supervisor because of jobs having
to switch processors (including the necessary TLB clearing, SIGP and
whatnot).

The SIOFQ issue I was talking about was indeed not related to that. It
was an issue I encountered running VM/SP 5 HPO where disabling SIOFQ in
the 4381 did yield a much better performance (around 30%) when doing
DASD I/O because my 3880 did have a 2 way channel path - thus allowing
resubmitting an I/O over an alternate path when possible (instead of
queuing it over the busy path).

Note that SIO and SIOF in hercules act the same (hercules never presents
a deferred CC on I/O initiation), and since there is no SIOF, there is
no SIOFQ "Feature" either.

--Ivan



[Non-text portions of this message have been removed]
Gerhard Postpischil gerhardp@charter.net [hercules-390]
2017-01-17 22:29:50 UTC
Permalink
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
The 3880 dasd controller most certainly *did* have a 2 channel switch. It in fact supported up to eight channels being connected. And none of them were required to be connected to the same processor either. It also had a string switch feature too. We used both features quite extensively at one of the last shops I worked at.
I'm not sure who dragged a 3880 into the discussion, but we didn't have
one. Our NCR/Comten only had a single channel, and it was directly
cabled into channel 0.

Gerhard Postpischil
Bradford, VT
Joe Monk joemonk64@gmail.com [hercules-390]
2017-01-17 20:21:33 UTC
Permalink
Page 6:

Two and four channel switches are available as special features on the 3880
Storage Control Models 2, 3, and 13, and eight channel switches are
available on Models 2 and 3. The three features can be used as described as
follows and in Figure 4.

-

With a two-channel switch pair feature, each storage director of a 3880
can connect to two different chan- nels. Both storage directors can connect
to the same or different channels.
- With a two-channel switch pair, additional feature, each storage
director of a 3880 can connect to up to four different channels. Both
storage directors can connect to the same or different channels.
- With an eight-channel switch feature, both storage directors of a 3880
connect to the same eight channels.

Channel switching is especially significant for 3380 model AAs with two
controllers. In this configuration, data in a 3380 string can be accessed
by as many as 16 different channels. This is possible if one 3380
controller is attached to a storage director in one 3880 and the other
controller is attached to a storage director in a different 3880 and both
3880s have the eight-channel switch feature.



http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/dasd/
3380/GA26-1664-1_3380_IBM_3380_Direct_Access_Storage_
Description_and_Users_Guide_Dec81.pdf
Post by Gerhard Postpischil ***@charter.net [hercules-390]
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
The problem was that if you had a 2 channel switch on a 3880, and you
had SIOFQ enabled in the CPU (it wasn't a OS option, it was an option in
the 4381), then the OS was never made aware an I/O could not be directly
scheduled on another channel (the I/O was just queued by the channel
subsystem if it was busy doing something else) - so you had an I/O
queued on a channel even though you could have presented it on another
channel (this is not associated with the number of CPUs you had on your
system).
I'm not sure what you're describing. There was no two-channel switch,
unless there was a hidden one in the 4381 channel logic. The NCR/Comten
was a TP front end, with better features than IBM's, and only a single
channel.
As to SIOFQ, at the time we had third-party maintenance, and possibly
the C.E. didn't know about it.
Gerhard Postpischil
Bradford, VT
somitcw@yahoo.com [hercules-390]
2017-01-17 20:54:12 UTC
Permalink
- - - In hercules-***@yahoogroups.com, <***@...> wrote:
- - - old notes snipped - - -
Post by Gerhard Postpischil ***@charter.net [hercules-390]
I'm not sure what you're describing. There was no two-channel switch,
unless there was a hidden one in the 4381 channel logic. The NCR/Comten
was a TP front end, with better features than IBM's, and only a single
channel.
So you agree that there was only one physical path to the COMTEN.
MVS kept trying to use a channel that did not have the COMTEN attached.
That would fail, channel 0 in the other channel-set was tried.
It worked, but was not running at a reasonable speed.

config or vary the channel path that did not exist offline.
Post by Gerhard Postpischil ***@charter.net [hercules-390]
As to SIOFQ, at the time we had third-party maintenance, and possibly
the C.E. didn't know about it.
Gerhard Postpischil
Bradford, VT
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-17 05:28:32 UTC
Permalink
Post by Gerhard Postpischil ***@charter.net [hercules-390]
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Disable SIOFQ !
What was the question <g>
The problem was that MVS spent a lot of time on shoulder taps between
CPUs, and couldn't keep up with the traffic. I'm not sure that disabling
fast I/O would have helped, and I don't remember that as a sysgen option.
It wasn't until X/A that the I/O handler was modified to use multiple
CPUs properly.
Gerhard Postpischil
Bradford, VT
To make this complete :

When SIOFQ is NOT enabled on a 4381, when the CPU issues a SIOF
instruction and the Control Unit reports it is busy, a deferred CC 1 is
reported (via I/O interrupt) and a Control Unit Busy status in the CSW.
At which point the OS can try to issue that same I/O request on an
alternate channel.

When SIOFQ is enabled, if the SIOF instruction is issued, but the
Control Unit reports a busy status, the channel subsystem will just
queue the request and issue the request again when it receives a Channel
End from the Control Unit (even for another device).

So basically, if you have SIOFQ enabled in a 4381, you lose all the
benefits of having a 2 channel switch feature installed - and connected
to multiple channels - on a 3880.

--Ivan



[Non-text portions of this message have been removed]
somitcw@yahoo.com [hercules-390]
2017-01-17 14:40:48 UTC
Permalink
Post by Gerhard Postpischil ***@charter.net [hercules-390]
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Disable SIOFQ !
What was the question <g>
The problem was that MVS spent a lot of time on shoulder taps between
CPUs, and couldn't keep up with the traffic. I'm not sure that disabling
fast I/O would have helped, and I don't remember that as a sysgen option.
It wasn't until X/A that the I/O handler was modified to use multiple
CPUs properly.
Gerhard Postpischil
Bradford, VT
So configure the non-existent path offline.
Gerhard Postpischil gerhardp@charter.net [hercules-390]
2017-01-17 16:08:34 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
Post by Gerhard Postpischil ***@charter.net [hercules-390]
It wasn't until X/A that the I/O handler was modified to use multiple
CPUs properly.
So configure the non-existent path offline.
Which non-existent path? There was only one (020) in the gen.

Gerhard Postpischil
Bradford, VT
somitcw@yahoo.com [hercules-390]
2017-01-17 16:17:52 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
Post by Gerhard Postpischil ***@charter.net [hercules-390]
It wasn't until X/A that the I/O handler was modified to use multiple
CPUs properly.
So configure the non-existent path offline.
Which non-existent path? There was only one (020) in the gen.
Gerhard Postpischil
Bradford, VT
Yes, but to MVS, it was on both channel zeros.

That is two paths defined but only connected to the
second path to be tried each I/O.
somitcw@yahoo.com [hercules-390]
2017-01-16 16:47:34 UTC
Permalink
Post by Gerhard Postpischil ***@charter.net [hercules-390]
Post by ***@yahoo.com [hercules-390]
When in S/370-24bit mode, it ran as a S/370-24bit system.
When in S/370-31bit mode, it ran as a S/370-31bit system.
IIRC, the 4341 and 4381 came with two channel sets of four channels
each, but the second was not available efficiently in S/370 mode. I
found out the hard way - while I was away at a conference, one of my
employees decided to make the system more efficient by changing the NCR/
Comten front-end to its own channel (channel 0 on second channel set).
Lo and behold, remote lines and users kept dropping like flies until I
made him recable things. To this day I don't think he understands why he
had problems.
Gerhard Postpischil
Bradford, VT
Our 4381- ?T92E? had 12 channels which is 6 on each side.

We had no issues with MVS SP3 or MVS 2.2.0 or MVS 2.2.3.
All channels worked.as described.

The other sites would have reported issues to me if they
had any but none did.

I never ran COMTEN on my systems but had to support it
later at a customer site.

I suspect that channel zero on the first channel set was tried
first for each I/O and then re-routed to try the second channel set?

There could be other configuration issues?

On amdahl, I had a customer switch to the Last-Channel-Used
algorithm because the disk control units could not communicate
between each other as fast as MVS could redrive an I/O request
after a busy. amdahl had fast channels but IBM CPU channels
were slow enough that they didn't have the issue.
Rotate didn't work well with amdahl channels and gave busy forever.
Michael Short michael.short.47@gmail.com [hercules-390]
2017-01-16 21:59:21 UTC
Permalink
The 4381-9X came with two sets of nine channels in XA node. Channel 0 on
both sets
acted as a mutliplexor channel and the rest as block channels. With so many
channels we had every controller on its own channel.
Post by Gerhard Postpischil ***@charter.net [hercules-390]
Post by ***@yahoo.com [hercules-390]
When in S/370-24bit mode, it ran as a S/370-24bit system.
When in S/370-31bit mode, it ran as a S/370-31bit system.
IIRC, the 4341 and 4381 came with two channel sets of four channels
each, but the second was not available efficiently in S/370 mode. I
found out the hard way - while I was away at a conference, one of my
employees decided to make the system more efficient by changing the NCR/
Comten front-end to its own channel (channel 0 on second channel set).
Lo and behold, remote lines and users kept dropping like flies until I
made him recable things. To this day I don't think he understands why he
had problems.
Gerhard Postpischil
Bradford, VT
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-16 02:24:55 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
"No IBM machine was ever built that did that."
As you will note, the 4381 is a S/370 system that is
capable of running XA. It uses S370 style IO.
Joe
- - - old notes snipped - - -
No.
1. S370-24bit
or
2. S370-31bit
To switch, we had to shut the system down to
something like "bios" level, and run a program
to switch it to either S370-24bit or S370-31bit.
Then boot in the mode that we had selected.
In S370-24bit mode, it was a S370-24bit system.
In S370-31bit mode, it was a S370-31bit system.
In XA mode on a 4381 was XA I/O (SSCH and 31 bit.... NO SIO)...

--Ivan





[Non-text portions of this message have been removed]
'Dave Wade' dave.g4ugm@gmail.com [hercules-390]
2017-01-16 06:52:38 UTC
Permalink
-----Original Message-----
Sent: 16 January 2017 02:03
Subject: Re: [hercules-390] Re: Hercules status
"No IBM machine was ever built that did that."
As you will note, the 4381 is a S/370 system that is capable of
running XA. It uses S370 style IO.
Joe
- - - old notes snipped - - -
No.
1. S370-24bit
or
2. S370-31bit
To switch, we had to shut the system down to something like "bios" level,
and run a program to switch it to either S370-24bit or S370-31bit.
Then boot in the mode that we had selected.
In S370-24bit mode, it was a S370-24bit system.
In S370-31bit mode, it was a S370-31bit system.
It all gets rather fuzzy around this time but wouldn't early versions of VM/XA SP or VM/ESA run 370 mode guests.
Did SIE Assist (i.e. the microcode) handle the I/O or did VM have to convert the SIO to SSCH (is that right, Start SubSchannel etc.)

Dave
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2017-01-16 10:35:14 UTC
Permalink
SIE never did I/O.

CP did the channel program, whichever instruction issued it. SIE-1 did
370 virtual machines and would indicate an intercept on the 7c
instruction; the rest was up to CP.
Post by 'Dave Wade' ***@gmail.com [hercules-390]
t all gets rather fuzzy around this time but wouldn't early versions of
VM/XA SP or VM/ESA run 370 mode guests.
Did SIE Assist (i.e. the microcode) handle the I/O or did VM have to
convert the SIO to SSCH (is that right, Start SubSchannel etc.)
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-16 12:11:15 UTC
Permalink
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
SIE never did I/O.
Oh yes it did (and it does on hercules)... I/O can be performed by SIE
if it has the SIE I/O assist installed - but it only works for so called
"preferred guests" - that is for V=R or V=F virtual machines on
dedicated devices.

--Ivan



[Non-text portions of this message have been removed]
somitcw@yahoo.com [hercules-390]
2017-01-16 16:01:46 UTC
Permalink
- - - In hercules-***@yahoogroups.com, <***@...> wrote:
- - - old notes snipped top and bottom - - -
Post by 'Dave Wade' ***@gmail.com [hercules-390]
It all gets rather fuzzy around this time but wouldn't early versions
of VM/XA SP or VM/ESA run 370 mode guests.
Did SIE Assist (i.e. the microcode) handle the I/O or did VM have
to convert the SIO to SSCH (is that right, Start SubSchannel etc.)
Dave
Probably even fuzzier for me.

I assUme that VM/ESA 1.1.0 or 1.1.0 running
in S/370-24bit mode would handle S/370-24bit
operating systems?
somitcw@yahoo.com [hercules-390]
2017-01-16 16:04:46 UTC
Permalink
- - - In hercules-***@yahoogroups.com, <***@...> wrote:
- - - beginning snipped - - -
Post by ***@yahoo.com [hercules-390]
I assUme that VM/ESA 1.1.0 or 1.1.0 running
in S/370-24bit mode would handle S/370-24bit
operating systems?
Now days, if there isn't at least one typo,
the post isn't from me.

1.1.0. or 1.1.1
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-01-16 16:13:22 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
- - - old notes snipped top and bottom - - -
Post by 'Dave Wade' ***@gmail.com [hercules-390]
It all gets rather fuzzy around this time but wouldn't early versions
of VM/XA SP or VM/ESA run 370 mode guests.
Did SIE Assist (i.e. the microcode) handle the I/O or did VM have
to convert the SIO to SSCH (is that right, Start SubSchannel etc.)
Dave
Probably even fuzzier for me.
I assUme that VM/ESA 1.1.0 or 1.1.0 running
in S/370-24bit mode would handle S/370-24bit
operating systems?
VM ESA 1.1.X had 2 very different versions :

VM/ESA S/370 version (basically an enhanced version of VM/HPO)
VM/ESA XA version (basically an enhanced version of VM/XA SP 2.1)

--Ivan



[Non-text portions of this message have been removed]
'Dave Wade' dave.g4ugm@gmail.com [hercules-390]
2017-01-16 16:29:29 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
Probably even fuzzier for me.
I assUme that VM/ESA 1.1.0 or 1.1.0 running in S/370-24bit mode would
handle S/370-24bit operating systems?
But then that’s a pure 24-bit environment. Some releases of VM/XA? VM/ESA? Provided 24-bit guest support and so mapped the 24-bit i/o onto 32-bit i/o.

Its also impossible to know what IBM did internally in all its labs for certain (e.g. government) customers. I am assured that IBM still maintains spares for government Series/1 machines.
These were withdrawn from normal support 10 years ago.

Dave
somitcw@yahoo.com [hercules-390]
2017-01-16 02:00:27 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
3. Focus on Jujitsu z/Arch+ as the first architecture.
Noooooooooooooo. Forget anything called Jujitsu.
We need
I thought what you wanted was S/370
I/O combined with XA DAT?
No IBM machine was ever built that
did that.
Jujitsu has a machine that does that
though. It does more than that in
fact, and comes closer to Fujitsu's
"proposed" z/Arch+ than any other
vendor.
Where do you propose getting the
specs for the machine that you
want from? Would you prefer that
we call it "somitcw architecture"?
I'm happy to do that if you want,
because "what's in a name?".
BFN. Paul.
You have made it clear that you want zArch baggage
with S370-31bit I/O ripped out and surgically replaced
with S/370-24bit I/O.

Have you noticed that many people want their Hercules
to continue to run DOS, MVS, and others so don't really
need that kludge?

I suggested S/360 upward to add all available upward
compatible feature on a S/360. That would be no
different than using the same Hercules ARCHLVL to
run either S/360 or S/370-24bit or S/370-24bit enhanced.
I just suggest that we remove the absurd roadblocks.
Take it to the next level and next level.
The same ARCHLVL S36U will run MFT, DOS, VM, MVS,
and many more and will be allowed to also use instructions
from the S/370-31bit to the most current zArch-64bit on
operating systems that came out fifty years ago.

No butchery needed.
No incompatibility needs to be added.
It is not just removing restrictions that Hercules already
ignores but removing all restrictions that make no sense.
Every instruction that anyone could possibly want from
1965 until today.
All RMODEs that anyone could possibly want from
1965 until today.
All AMODEs that anyone could possibly want from
1965 until today.

Removing absurd restrictions does not remove
any usefulness. It just means that people can do
anything that they do today and much more.

The fact that IBM added restrictions for marketing
reasons should not be any reason that Hercules
does a 180 and starts enforcing all of them.
Hercules should not enforce the restrictions
that it has chosen to enforce.
kerravon86@yahoo.com.au [hercules-390]
2017-01-16 02:39:20 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
You have made it clear that you want zArch baggage
with S370-31bit I/O ripped out and surgically replaced
with S/370-24bit I/O.
It should be possible at compile time
or run time (or both) to do the above, yes.

The above would (in fact, already
does) allow people to run 64-bit
programs on MVS 3.8j, which
I consider to be a cool option.
Post by ***@yahoo.com [hercules-390]
Have you noticed that many people want their Hercules
to continue to run DOS, MVS, and others so don't really
need that kludge?
I am happy for there to be a compile
time, or run time (or both) option to
remove the z/Arch "baggage" if that
is causing them distress.

BFN. Paul.
hoes.maarten@gmail.com [hercules-390]
2017-01-10 20:27:41 UTC
Permalink
Hi,

DISCLAIMER: I'm mostly a lurker around here, so the post below may be wildly inaccurate.


I don't think any of the various forks/branches are 'obsolete'. To me it just seems that the various developers have/had different opinions on what to do and how to go about doing it (so there are forks/branches), and that each of them has a different use-case and/or user-base.


#1.
As far as I can tell, Hercules 3.x still gets updates (mostly, or perhaps even only, bugfixes I guess ?), just not very frequently.


#2. When the Hyperion fork was initially made, it was with the intent of making that the development branch of the next 'official' version of the emulator. Furthermore, I'm fairly sure that all of the developers of the various forks/branches would welcome any help on the development part. It looks to me like most of Hyperion is written in 'C' and not C++, so in principle that should not stop you from contributing. The hardest part may be figuring out which fork/branch to contribute to. ;)


#3.
But I think I can only really answer your last point #3:

For Linux
You can go with the binaries your distribution offers, but those may be out of date or not be there at all, so you may indeed have to compile from sources.


For Windows

For Hercules 3.x, there are binaries over here.
http://www.hercules-390.eu/ http://www.hercules-390.eu/

For 'official' Hyperion 4, I just noticed that recently a release candidate has been made available. I guess that after being in development for a while, a formal release is now planned ?
https://github.com/hercules-390/hyperion/releases https://github.com/hercules-390/hyperion/releases

And there are builds on the SoftDevLabs website of the (recently forced to fork) 'Fish-Git' Hyperion fork.
http://www.softdevlabs.com/hyperion.html http://www.softdevlabs.com/hyperion.html



Feel free to correct me on all points above, though.



- Maarten.


---In hercules-***@yahoogroups.com, <***@...> wrote :

I was just reading the instruction leakage thread and saw somitcw's comment about the various (obsolete) forks of Hercuels, which made me wonder what is the current state of affairs with regard to future Hercules development.

1. Is work still continuing on the 3.x line or is 3.12 the end of that era ? I seem to recall reading a post from way back that implied that most of the 3.x devs had given up due to strife between some people.

2. Is Hyperion then where any further development will or is occurring ? I saw a post about still looking for help. I have a working knowledge of C but not C++, so I'm not sure if I could contribute or not. Since I'm retiring shortly, spare time I ought to have though, even if just for doc writing.

3. Are there binaries for Hyperion, or is it just a build your own from source at the moment ?
kerravon86@yahoo.com.au [hercules-390]
2017-01-11 00:36:54 UTC
Permalink
Post by ***@sympatico.ca [hercules-390]
I was just reading the instruction leakage
thread and saw somitcw's comment
about the various (obsolete) forks of
Hercuels,
When he said "obsolete" he should
probably have said "missing
functionality".

He named Hercules/380 as "obsolete"
despite the fact that the most recent
beta was released 2016-11-24, and
it allows you to do 64-bit programming
on MVS 3.8j.

And from my point of view, as someone
who wishes to do 31-bit programming
on MVS 3.8j, all other targets are
obsolete to me.
Post by ***@sympatico.ca [hercules-390]
I have a working knowledge of C but
not C++, so I'm not sure if I could
contribute or not. Since I'm retiring
shortly, spare time I ought to have
though, even if just for doc writing.
Hercules is in C, not C++, as far as I
am aware.

Also, are you aware that GCC is available
for MVS 3.8j? You may wish to port or
write some C programs on the mainframe.
Or volunteer to produce the next version
of SEASIK or MVS/380.

BFN. Paul.
williaj@sympatico.ca [hercules-390]
2017-01-11 04:16:33 UTC
Permalink
What's SEASIK ? I've not run across that name before. I did know about the GCC port, but I've never used it.
kerravon86@yahoo.com.au [hercules-390]
2017-01-11 05:58:41 UTC
Permalink
Post by ***@sympatico.ca [hercules-390]
What's SEASIK ? I've not run across that
name before. I did know about the GCC
port, but I've never used it.
SEASIK is a collection of random C programs
that may be useful to MVS 3.8j or z/OS users.

It includes BREXX, BISON, BWBASIC, SED,
DIFFUTILS etc.

You can get it from here:

https://sourceforge.net/projects/gccmvs/files/SEASIK/SEASIK%201.0/

Or it comes bundled with MVS/380 and
also I believe the programs are in TK4-
but not in the original dataset names.

All the modules except GCC are 24/24,
but in the next release of SEASIK they
will all be marked 31/ANY but in reality
they will be ANY/ANY, ie they run as
24/24 on MVS 3.8j but 31/ANY on z/OS.

BTW, I assume you are replying to
messages using the Yahoo interface.
If so, after you click "reply", you should
see "> show message history" down
the bottom. Can you please click on
that so that we can see who you are
replying to? Thanks.

BFN. Paul.
' Richard Pinion' rpinion@netscape.com [hercules-390]
2017-01-14 01:12:04 UTC
Permalink
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> </head> <body style="background-color: #fff;"> <span style="display:none">&nbsp;</span> <!--~-|**|PrettyHtmlStartT|**|-~--> <div id="ygrp-mlmsg" style="position:relative;"> <div id="ygrp-msg" style="z-index: 1;"> <!--~-|**|PrettyHtmlEndT|**|-~--> <div id="ygrp-text" > <p><DIV style="font-family:Arial, sans-serif;font-size:10pt;"><FONT size="2">Why not interpreted Basic?</FONT><BR><BR><SPAN style="font-size: 10pt;">Richard and Vickie Pinion</SPAN><BR><BR><SPAN style="font-size: 10pt;">--- hercules-***@yahoogroups.com wrote:</SPAN><BR><BR><SPAN style="font-size: 10pt;">From: "Joe Monk ***@gmail.com [hercules-390]" &lt;hercules-***@yahoogroups.com&gt;</SPAN><BR><SPAN style="font-size: 10pt;">To: hercules-***@yahoogroups.com</SPAN><BR><SPAN style="font-size: 10pt;">Subject: Re: [hercules-390] Re: Hercules status</SPAN><BR><SPAN style="font-size: 10pt;">Date: Fri, 13 Jan 2017 19:02:45 -0600</SPAN><BR><BR> <SPAN>&nbsp;</SPAN> <DIV style="font-size: 10pt;"> <DIV> <DIV> <P></P><DIV dir="ltr">Even better ... why not Swift?<DIV><BR></DIV><DIV>Joe</DIV></DIV><DIV><BR><DIV>On Fri, Jan 13, 2017 at 6:51 PM, Ivan Warren <A href="mailto:***@vmfacility.fr">***@vmfacility.fr</A> [hercules-390] <SPAN dir="ltr">&lt;<A href="mailto:hercules-***@yahoogroups.com">hercules-***@yahoogroups.com</A>&gt;</SPAN> wrote:<BR><BLOCKQUOTE style="border-left:1px #ccc solid;">


<U></U>










<DIV style="background-color:#fff;">
<SPAN>&nbsp;</SPAN>


<DIV>
<DIV>


<DIV>


</DIV></DIV></DIV></DIV></BLOCKQUOTE></DIV></DIV><P></P><P>Don't count on me...<BR>
<BR>
I would have completely supported a hercules project that is true to the <BR>
various PoPs...<BR>
<BR>
But C&#43;+ ? Why not Java, Python or C# ?<BR>
<BR>
Not my thing... Simple C is fine for me to implement those architectures !<BR>
<BR>
--Ivan<BR>
<BR>
On 1/13/2017 11:09 PM, ''Fish' (David B. Trout)' <A href="mailto:***@gmail.com">***@gmail.com</A> <BR>
[hercules-390] wrote:<BR>
&gt; Maarten Hoes wrote<BR>
&gt;&gt; Fish wrote:<BR>
&gt;&gt;<BR>
&gt;&gt; &lt;snip&gt;<BR>
&gt;&gt;&gt; ... until such time as I can finish development of<BR>
&gt;&gt;&gt; my own brand new version ...<BR>
&gt;&gt; &lt;snip&gt;<BR>
&gt;&gt;<BR>
&gt;&gt; Wait, what ? i completely overlooked this bit. Im so stoked now.<BR>
&gt;&gt; Details, please !<BR>
&gt; There are none. It's still being designed.<BR>
&gt;<BR>
&gt; The only thing I can divulge is my intent (hope): to completely rewrite Hercules in its entirety in C&#43;+, leveraging as absolutely little of the existing code as possible (hopefully none at all).<BR>
&gt;<BR>
&gt; This will of course take me quite some time to pull off (and of course there is the distinct possibility it may be entirely beyond my capabilities too), so don't expect to see anything soon. We're probably talking a multi-year effort here.<BR>
&gt;<BR>
&gt; If anyone with both mainframe and C&#43;+ skills is interested in helping, feel free to contact me off list.<BR>
&gt;<BR>
<BR>
[Non-text portions of this message have been removed]<BR>
<BR>
</P>

</DIV>



<DIV style="color:#fff;height:0;"></DIV>


</DIV>










</DIV><BR>
<P style="font-size: 10pt;"></P>





<DIV style="font-size: 10pt;color: rgb(255, 255, 255);height: 0px;"></DIV>













<BR>&nbsp;<BR><HR>Netscape.&nbsp; Just the Net You Need.</DIV></p>

</div>


<!--~-|**|PrettyHtmlStart|**|-~-->
<div style="color: #fff; height: 0;">__._,_.___</div>






<div style="clear:both"> </div>

<div id="fromDMARC" style="margin-top: 10px;">
<hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
Posted by: &quot; Richard Pinion&quot; &lt;***@netscape.com&gt; <hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
</div>
<div style="clear:both"> </div>

<table cellspacing=4px style="margin-top: 10px; margin-bottom: 10px; color: #2D50FD;">
<tbody>
<tr>
<td style="font-size: 12px; font-family: arial; font-weight: bold; padding: 7px 5px 5px;" >
<a style="text-decoration: none; color: #2D50FD" href="https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/80734;_ylc=X3oDMTJwbTEwZ2xuBF9TAzk3MzU5NzE0BGdycElkAzM0MjA2NARncnBzcElkAzE3MDcyODE5NDIEbXNnSWQDODA3MzQEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxNDg0MzY0MjAz?act=reply&messageNum=80734">Reply via web post</a>
</td>
<td>&bull;</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;" >
<a href="mailto:***@netscape.com?subject=Re%3A%20%5Bhercules-390%5D%20Re%3A%20Hercules%20status" style="text-decoration: none; color: #2D50FD;">
Reply to sender </a>
</td>
<td>&bull;</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;">
<a href="mailto:hercules-***@yahoogroups.com?subject=Re%3A%20%5Bhercules-390%5D%20Re%3A%20Hercules%20status" style="text-decoration: none; color: #2D50FD">
Reply to group </a>
</td>
<td>&bull;</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;" >
<a href="https://groups.yahoo.com/neo/groups/hercules-390/conversations/newtopic;_ylc=X3oDMTJkaWV1dmFlBF9TAzk3MzU5NzE0BGdycElkAzM0MjA2NARncnBzcElkAzE3MDcyODE5NDIEc2VjA2Z0cgRzbGsDbnRwYwRzdGltZQMxNDg0MzY0MjAz" style="text-decoration: none; color: #2D50FD">Start a New Topic</a>
</td>
<td>&bull;</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;color: #2D50FD;" >
<a href="https://groups.yahoo.com/neo/groups/hercules-390/conversations/topics/80654;_ylc=X3oDMTM1NHZuZW9pBF9TAzk3MzU5NzE0BGdycElkAzM0MjA2NARncnBzcElkAzE3MDcyODE5NDIEbXNnSWQDODA3MzQEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxNDg0MzY0MjAzBHRwY0lkAzgwNjU0" style="text-decoration: none; color: #2D50FD;">Messages in this topic</a>
(16)
</td>
</tr>
</tbody>
</table>


<div id="megaphoneModule">
<hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
<div>
<div class="stream" style="margin-bottom:10px;">
<div style="background-color:white;">
<div class="sn-img" style="display:inline;"><img name="tn_file" style="padding:0px 10px;vertical-align:top;margin-top:5px;" src="https://s.yimg.com/ru/static/images/yg/img/megaphone/1464031581_phpFA8bON" height="82" width="82"></div>
<div class="mod-txt" style="display:inline-block;">
<a rel="nofollow" name="sub_url" target="_blank" href="https://yho.com/1wwmgg" style="color:#0000FF;display:block;margin-left:5px;text-decoration:none;"><span style="font-size:15px;">Have you tried the highest rated email app?</span></a>
<div style="max-width:530px;padding:2px 5px;">With 4.5 stars in iTunes, the Yahoo Mail app is the highest rated email app on the market. What are you waiting for? Now you can access all your inboxes (Gmail, Outlook, AOL and more) in one place. Never delete an email again with 1000GB of free cloud storage.</div>
</div>
</div>
</div> </div>

<hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
</div>

<!------- Start Nav Bar ------>
<!-- |**|begin egp html banner|**| -->
<!-- |**|end egp html banner|**| -->


<div id="ygrp-grfd" style="font-family: Verdana; font-size: 12px; padding: 15px 0;">

<!-- |**|begin egp html banner|**| -->

Community email addresses:<BR>
&nbsp; Post message: hercules-***@yahoogroups.com<BR>
&nbsp; Subscribe:&nbsp;&nbsp;&nbsp; hercules-390-***@yahoogroups.com<BR>
&nbsp; Unsubscribe:&nbsp; hercules-390-***@yahoogroups.com<BR>
&nbsp; List owner:&nbsp;&nbsp; hercules-390-***@yahoogroups.com<BR>
<BR>
Files and archives at:<BR>
&nbsp; <a href="http://groups.yahoo.com/group/hercules-390">http://groups.yahoo.com/group/hercules-390</a><BR>
<BR>
Get the latest version of Hercules from:<BR>
&nbsp; <a href="http://www.hercules-390.org">http://www.hercules-390.org</a><BR>
<BR>

<!-- |**|end egp html banner|**| -->

</div>




<!-- |**|begin egp html banner|**| -->
<div id="ygrp-vital" style="background-color: #f2f2f2; font-family: Verdana; font-size: 10px; margin-bottom: 10px; padding: 10px;">

<span id="vithd" style="font-weight: bold; color: #333; text-transform: uppercase; "><a href="https://groups.yahoo.com/neo/groups/hercules-390/info;_ylc=X3oDMTJkbWx0cW51BF9TAzk3MzU5NzE0BGdycElkAzM0MjA2NARncnBzcElkAzE3MDcyODE5NDIEc2VjA3Z0bARzbGsDdmdocARzdGltZQMxNDg0MzY0MjAz" style="text-decoration: none;">Visit Your Group</a></span>

<ul style="list-style-type: none; margin: 0; padding: 0; display: inline;">
<li style="border-right: 1px solid #000; font-weight: 700; display: inline; padding: 0 5px; margin-left: 0;">
<span class="cat"><a href="https://groups.yahoo.com/neo/groups/hercules-390/members/all;_ylc=X3oDMTJlNnZwM2JjBF9TAzk3MzU5NzE0BGdycElkAzM0MjA2NARncnBzcElkAzE3MDcyODE5NDIEc2VjA3Z0bARzbGsDdm1icnMEc3RpbWUDMTQ4NDM2NDIwMw--" style="text-decoration: none;">New Members</a></span>
<span class="ct" style="color: #ff7900;">4</span>
</li>
</ul>
</div>


<div id="ft" style="font-family: Arial; font-size: 11px; margin-top: 5px; padding: 0 2px 0 0; clear: both;">
<a href="https://groups.yahoo.com/neo;_ylc=X3oDMTJjZGcxdTE4BF9TAzk3NDc2NTkwBGdycElkAzM0MjA2NARncnBzcElkAzE3MDcyODE5NDIEc2VjA2Z0cgRzbGsDZ2ZwBHN0aW1lAzE0ODQzNjQyMDM-" style="float: left;"><img src="Loading Image..." height="15" width="137" alt="Yahoo! Groups" style="border: 0;"/></a>
<div style="color: #747575; float: right;"> &bull; <a href="https://info.yahoo.com/privacy/us/yahoo/groups/details.html" style="text-decoration: none;">Privacy</a> &bull; <a href="mailto:hercules-390-***@yahoogroups.com?subject=Unsubscribe" style="text-decoration: none;">Unsubscribe</a> &bull; <a href="https://info.yahoo.com/legal/us/yahoo/utos/terms/" style="text-decoration: none;">Terms of Use</a> </div>
</div>
<br>

<!-- |**|end egp html banner|**| -->

</div> <!-- ygrp-msg -->


<!-- Sponsor -->
<!-- |**|begin egp html banner|**| -->
<div id="ygrp-sponsor" style="width:160px; float:right; clear:none; margin:0 0 25px 0; background: #fff;">

<!-- Start Recommendations -->
<div id="ygrp-reco">
</div>
<!-- End Recommendations -->



</div> <!-- |**|end egp html banner|**| -->

<div style="clear:both; color: #FFF; font-size:1px;">.</div>
</div>

<img src="http://geo.yahoo.com/serv?s=97359714/grpId=342064/grpspId=1707281942/msgId=80734/stime=1484364203" width="1" height="1"> <br>

<img src="http://y.analytics.yahoo.com/fpc.pl?ywarid=515FB27823A7407E&a=10001310322279&js=no&resp=img&cf12=CP" width="1" height="1">

<div style="color: #fff; height: 0;">__,_._,___</div>
<!--~-|**|PrettyHtmlEnd|**|-~-->

</body>

<!--~-|**|PrettyHtmlStart|**|-~-->
<head>
<style type="text/css">
<!--
#ygrp-mkp {
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 10px 0;
padding: 0 10px;
}

#ygrp-mkp hr {
border: 1px solid #d8d8d8;
}

#ygrp-mkp #hd {
color: #628c2a;
font-size: 85%;
font-weight: 700;
line-height: 122%;
margin: 10px 0;
}

#ygrp-mkp #ads {
margin-bottom: 10px;
}

#ygrp-mkp .ad {
padding: 0 0;
}

#ygrp-mkp .ad p {
margin: 0;
}

#ygrp-mkp .ad a {
color: #0000ff;
text-decoration: none;
}
#ygrp-sponsor #ygrp-lc {
font-family: Arial;
}

#ygrp-sponsor #ygrp-lc #hd {
margin: 10px 0px;
font-weight: 700;
font-size: 78%;
line-height: 122%;
}

#ygrp-sponsor #ygrp-lc .ad {
margin-bottom: 10px;
padding: 0 0;
}

#actions {
font-family: Verdana;
font-size: 11px;
padding: 10px 0;
}

#activity {
background-color: #e0ecee;
float: left;
font-family: Verdana;
font-size: 10px;
padding: 10px;
}

#activity span {
font-weight: 700;
}

#activity span:first-child {
text-transform: uppercase;
}

#activity span a {
color: #5085b6;
text-decoration: none;
}

#activity span span {
color: #ff7900;
}

#activity span .underline {
text-decoration: underline;
}

.attach {
clear: both;
display: table;
font-family: Arial;
font-size: 12px;
padding: 10px 0;
width: 400px;
}

.attach div a {
text-decoration: none;
}

.attach img {
border: none;
padding-right: 5px;
}

.attach label {
display: block;
margin-bottom: 5px;
}

.attach label a {
text-decoration: none;
}

blockquote {
margin: 0 0 0 4px;
}

.bold {
font-family: Arial;
font-size: 13px;
font-weight: 700;
}

.bold a {
text-decoration: none;
}

dd.last p a {
font-family: Verdana;
font-weight: 700;
}

dd.last p span {
margin-right: 10px;
font-family: Verdana;
font-weight: 700;
}

dd.last p span.yshortcuts {
margin-right: 0;
}

div.attach-table div div a {
text-decoration: none;
}

div.attach-table {
width: 400px;
}

div.file-title a, div.file-title a:active, div.file-title a:hover, div.file-title a:visited {
text-decoration: none;
}

div.photo-title a, div.photo-title a:active, div.photo-title a:hover, div.photo-title a:visited {
text-decoration: none;
}

div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts {
font-family: Verdana;
font-size: 10px;
font-weight: normal;
}

.green {
color: #628c2a;
}

.MsoNormal {
margin: 0 0 0 0;
}

o {
font-size: 0;
}

#photos div {
float: left;
width: 72px;
}

#photos div div {
border: 1px solid #666666;
height: 62px;
overflow: hidden;
width: 62px;
}

#photos div label {
color: #666666;
font-size: 10px;
overflow: hidden;
text-align: center;
white-space: nowrap;
width: 64px;
}

#reco-category {
font-size: 77%;
}

#reco-desc {
font-size: 77%;
}

.replbq {
margin: 4px;
}

#ygrp-actbar div a:first-child {
/* border-right: 0px solid #000;*/
margin-right: 2px;
padding-right: 5px;
}

#ygrp-mlmsg {
font-size: 13px;
font-family: Arial, helvetica,clean, sans-serif;
*font-size: small;
*font: x-small;
}

#ygrp-mlmsg table {
font-size: inherit;
font: 100%;
}

#ygrp-mlmsg select, input, textarea {
font: 99% Arial, Helvetica, clean, sans-serif;
}

#ygrp-mlmsg pre, code {
font:115% monospace;
*font-size:100%;
}

#ygrp-mlmsg * {
line-height: 1.22em;
}

#ygrp-mlmsg #logo {
padding-bottom: 10px;
}


#ygrp-msg p a {
font-family: Verdana;
}

#ygrp-msg p#attach-count span {
color: #1E66AE;
font-weight: 700;
}

#ygrp-reco #reco-head {
color: #ff7900;
font-weight: 700;
}

#ygrp-reco {
margin-bottom: 20px;
padding: 0px;
}

#ygrp-sponsor #ov li a {
font-size: 130%;
text-decoration: none;
}

#ygrp-sponsor #ov li {
font-size: 77%;
list-style-type: square;
padding: 6px 0;
}

#ygrp-sponsor #ov ul {
margin: 0;
padding: 0 0 0 8px;
}

#ygrp-text {
font-family: Georgia;
}

#ygrp-text p {
margin: 0 0 1em 0;
}

#ygrp-text tt {
font-size: 120%;
}

#ygrp-vital ul li:last-child {
border-right: none !important;
}
-->
</style>
</head>

<!--~-|**|PrettyHtmlEnd|**|-~-->
</html>
<!-- end group email -->
'Paul Dembry' pade@trifox.com [hercules-390]
2017-01-15 21:28:33 UTC
Permalink
I am simply happy that it works and I can run MVS, Linux, MTS without having
to fire up my P/390. I'm not qualified to help keep it running (the last 360
assembler code I wrote was in 1978) but I certainly appreciate the
engineering work that went into it. So thank you to everyone who got
Hercules to this point. I run 3.12 which is rock-solid for my purposes.
Paul
Dave McGuire Mcguire@neurotica.com [hercules-390]
2017-01-15 23:09:31 UTC
Permalink
Post by 'Paul Dembry' ***@trifox.com [hercules-390]
I am simply happy that it works and I can run MVS, Linux, MTS without having
to fire up my P/390. I'm not qualified to help keep it running (the last 360
assembler code I wrote was in 1978) but I certainly appreciate the
engineering work that went into it. So thank you to everyone who got
Hercules to this point. I run 3.12 which is rock-solid for my purposes.
Seconded. I love my real iron, but Hercules is just so damn handy.
Great stuff!

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA


------------------------------------

------------------------------------

Community email addresses:
Post message: hercules-***@yahoogroups.com
Subscribe: hercules-390-***@yahoogroups.com
Unsubscribe: hercules-390-***@yahoogroups.com
List owner: hercules-390-***@yahoogroups.com

Files and archives at:
http://groups.yahoo.com/group/hercules-390

Get the latest version of Hercules from:
http://www.hercules-390.org


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/hercules-390/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/hercules-390/join
(Yahoo! ID required)

<*> To change settings via email:
hercules-390-***@yahoogroups.com
hercules-390-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
hercules-390-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
somitcw@yahoo.com [hercules-390]
2017-01-16 01:55:38 UTC
Permalink
Post by 'Paul Dembry' ***@trifox.com [hercules-390]
I am simply happy that it works and I can run MVS, Linux,
MTS without having to fire up my P/390. I'm not qualified
to help keep it running (the last 360 assembler code
I wrote was in 1978) but I certainly appreciate the
engineering work that went into it. So thank you to
everyone who got Hercules to this point. I run 3.12
which is rock-solid for my purposes.
Seconded. I love my real iron, but Hercules is just so
damn handy.
Great stuff!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
With new Hercules development. it should only
become even more handy.

The both 4.00 and 3.12 seem solid and I look
forward to advances from there.
'Stephen Orso' stephen.orso@yahoo.com [hercules-390]
2017-01-17 14:13:36 UTC
Permalink
The interesting question when it comes to floating point is what to do with
the bits available in the current (-10) RXE instructions.



For some, making them RXY makes sense, for example Load Lengthened. For
others, such as BFP Add (AEB, ADB), there are at least two reasonable
alternatives:



1. Make them RXY and enable and extended range of access (the big data
direction).
2. Make them a register-storage version of one of the RRF variants,
likely RRF-a, and enable better control of rounding and inexact exception
reporting.



It is likely that users with binary floating point-intensive applications
would find 2) more useful, and because there are, for such users, a) other
ways to deal with the long displacement requirement: use RXF variants of
LE/LD/STE/STD and the RRF successors to the current RRE BFP instructions,
and b) if one is working with floating point, getting control of rounding is
very important.



This is essentially how the decimal floating point arithmetic set appears to
have been designed: the only Register-Storage instructions are Convert
To/From Packed/Zoned and Test Data Class/Group. The rest are three-operand
register-register-register instructions with rounding mode control nibbles.




I doubt IBM will do much with hex floating point; significant extensions of
that instruction set would require significant application changes by
floating point customers to take advantage of the extensions. That customer
effort might be better spent migrating to BFP, with its constant stored
significance (for normal numbers) and gradual underflow (for subnormals), or
to DFP, with its wider range of values and better control of significance,
especially trailing zero significance. I should note that IBM has not asked
my opinion in the matter, nor am I holding my breath in anticipation of such
a query.



That said, there are RXE floating point instructions with unassigned
instruction bits, there are reasonable alternatives for the use of those
bits, and only an IBM announcement (or -11 of the PoO) will settle the
question.
somitcw@yahoo.com [hercules-390]
2017-01-17 14:58:40 UTC
Permalink
Post by 'Stephen Orso' ***@yahoo.com [hercules-390]
The interesting question when it comes to floating point is what to
do with the bits available in the current (-10) RXE instructions.
IBM already settled that in the last eight Principal of Operation manuals.
Post by 'Stephen Orso' ***@yahoo.com [hercules-390]
For some, making them RXY makes sense, for example Load Lengthened.
For others, such as BFP Add (AEB, ADB), there are at least two reasonable
1. Make them RXY and enable and extended range of access (the big data direction).
Already done.
Post by 'Stephen Orso' ***@yahoo.com [hercules-390]
2. Make them a register-storage version of one of the RRF variants, likely
RRF-a, and enable better control of rounding and inexact exception reporting.
That is not upward compatible with RXY.

IBM often prefers upward changes.
Post by 'Stephen Orso' ***@yahoo.com [hercules-390]
It is likely that users with binary floating point-intensive applications would
find 2) more useful, and because there are, for such users, a) other ways
to deal with the long displacement requirement: use RXF variants of
LE/LD/STE/STD and the RRF successors to the current RRE BFP
instructions, and b) if one is working with floating point, getting control of
rounding is very important.
Your new suggest feature is:

1. Not needed.
2. Not upward compatible with RXY.
Post by 'Stephen Orso' ***@yahoo.com [hercules-390]
This is essentially how the decimal floating point arithmetic set appears
to have been designed: the only Register-Storage instructions are
Convert To/From Packed/Zoned and Test Data Class/Group.
The rest are three-operand register-register-register instructions with
rounding mode control nibbles.
I doubt IBM will do much with hex floating point; significant extensions
of that instruction set would require significant application changes by
floating point customers to take advantage of the extensions.
That customer effort might be better spent migrating to BFP, with its
constant stored significance (for normal numbers) and gradual
underflow (for subnormals), or to DFP, with its wider range of values
and better control of significance, especially trailing zero significance.
I should note that IBM has not asked my opinion in the matter, nor
am I holding my breath in anticipation of such a query.
That said, there are RXE floating point instructions with unassigned
instruction bits, there are reasonable alternatives for the use of those
bits, and only an IBM announcement (or -11 of the PoO) will settle
the question.
If you don't like IBM's decision, please tell them.

If you want your never to be used new feature, please tell IBM.

If you don't like what IBM wrote in eight versions of the
zArch Principle of Operations, please tell them.

If IBM's Principal of Operations turns out to be a long running typo,
then I want to know. Let me know.
somitcw@yahoo.com [hercules-390]
2017-01-17 16:14:29 UTC
Permalink
- - - In hercules-***@yahoogroups.com, <***@...> wrote:
- - - all snipped - - -

The biggest concentrations of zArch assembler programmers is probably on
ListServ Assembler-List so I posted the question about possible typos in the
zArch Principles of Operations:

Your message dated Tue, 17 Jan 2017 10:38:47 -0500 with subject "Did IBM
replace all format RXE with RXY ?" has been successfully distributed to the
ASSEMBLER-LIST list (847 recipients).

SA22-7832-02.zArch.Principles.of.Operations.Jun.2003.pdf
claims:

Page xxii to xxiii
"All previously existing format-RSE and
format-RXE instructions are changed to be
of formats RSY and RXY, respectively, by
use of a previously unused byte in the
instructions. These changes are not
marked by a bar in the margin."

The change uses previously unused 8 bits to extend
displacements from 12 bits to the long displacement
positive or negative 20 bit displacement.

All zArch Principle of Operation manuals starting with
June 2003 have the same wording.

But, many of the instruction definition such as BFP Add
instructions AEB and ADB still show RXE ?

Does IBM plan to back-off the change from RXE to RXY and
go in a different direction or are they just sloppy about keeping
the first part of the manual insync with the rest?
somitcw@yahoo.com [hercules-390]
2017-01-18 14:05:36 UTC
Permalink
I posted the answer from IBM yesterday, but yahoo probably
didn't like my complete formatting including the format
information within IBM's post,

Today I've also added a response to IBM's response:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IBM posted:

On Tue, Jan 17, 2017 at 11:09 AM, Jonathan Scott
<***@vnet.ibm.com> wrote:
Ref: Your note of Tue, 17 Jan 2017 10:38:47 -0500

It appears that the Summary of Changes is incorrect. The
floating point RXE instructions did not change to RXY format.

Jonathan Scott
IBM Hursley, UK

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The only response to that so far:

Date: Tue, 17 Jan 2017 16:47:31 -0500
From: Steve Smith <***@GMAIL.COM>
Subject: Re: Did IBM replace all format RXE with RXY ?

How bizarre. I assumed that the RXE->RXY transition was fundamental, and
RXE-format was completely superseded.

The -10 version of PoOp still shows RXE format for BFP instructions. There
are a couple of odd DFP instructions that are documented as RXE, but DFP is
mostly register-only. HFP of course, retains the historic RX-format
op-codes, and evidently never added *Y forms.

If I was interested enough, I think I'd test if the assembler agrees, and
also coerce an RXY-format ADB or something to see what happens.

There are RXY versions of LD (LDY), and STD (STDY), so I suppose this is a
fairly academic issue. It's certainly not going to be a concern with my
limited usage of FP.

sas
--
sas


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - old notes below - - -
- - - In hercules-***@yahoogroups.com, <***@...> wrote:

- - - In hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com,
<***@...> wrote:
- - - all snipped - - -

The biggest concentrations of zArch assembler programmers is probably on
ListServ Assembler-List so I posted the question about possible typos in the
zArch Principles of Operations:

Your message dated Tue, 17 Jan 2017 10:38:47 -0500 with subject "Did IBM
replace all format RXE with RXY ?" has been successfully distributed to the
ASSEMBLER-LIST list (847 recipients).

SA22-7832-02.zArch.Principles.of.Operations.Jun.2003.pdf
claims:

Page xxii to xxiii
"All previously existing format-RSE and
format-RXE instructions are changed to be
of formats RSY and RXY, respectively, by
use of a previously unused byte in the
instructions. These changes are not
marked by a bar in the margin."

The change uses previously unused 8 bits to extend
displacements from 12 bits to the long displacement
positive or negative 20 bit displacement.

All zArch Principle of Operation manuals starting with
June 2003 have the same wording.

But, many of the instruction definition such as BFP Add
instructions AEB and ADB still show RXE ?

Does IBM plan to back-off the change from RXE to RXY and
go in a different direction or are they just sloppy about keeping
the first part of the manual insync with the rest?
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-01-18 14:56:26 UTC
Permalink
FYI to somitcw: I received the below Yahoo group email just fine.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
-----Original Message-----
Sent: Wednesday, January 18, 2017 6:06 AM
Subject: [hercules-390] Re: Hercules status
I posted the answer from IBM yesterday, but yahoo probably
didn't like my complete formatting including the format
information within IBM's post,
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
On Tue, Jan 17, 2017 at 11:09 AM, Jonathan Scott
Ref: Your note of Tue, 17 Jan 2017 10:38:47 -0500
It appears that the Summary of Changes is incorrect. The
floating point RXE instructions did not change to RXY format.
Jonathan Scott
IBM Hursley, UK
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Date: Tue, 17 Jan 2017 16:47:31 -0500
Subject: Re: Did IBM replace all format RXE with RXY ?
How bizarre. I assumed that the RXE->RXY transition was fundamental,
and
RXE-format was completely superseded.
<snip remaining>
somitcw@yahoo.com [hercules-390]
2017-01-18 15:20:39 UTC
Permalink
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
FYI to somitcw: I received the below Yahoo group email just fine.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com http://www.softdevlabs.com
- - - old notes snipped - - -

Yes.
The first attempt never made it.
The second attempt was dog slow.
The third attempt I deleted because the second attempt had finally shown.
somitcw@yahoo.com [hercules-390]
2017-01-19 05:51:59 UTC
Permalink
Another opinion that came from another poster that came
from another person at IBM.

Totally rewritten in the extreme.
The "incorrect" paragraph is not incorrect but must be
read in context.

Within each summery section, They are further split by
chapters. The "incorrect" paragraph for that chapter did
not refer to all RSE or RXE instructions as it said, but
only the RSE and RXE instructions that were described
in one chapter.

Below is the "incorrect" paragraph.

SA22-7832-02.zArch.Principles.of.Operations.Jun.2003.pdf

Page xxii to xxiii
"All previously existing format-RSE and
format-RXE instructions are changed to be
of formats RSY and RXY, respectively, by
use of a previously unused byte in the
instructions. These changes are not
marked by a bar in the margin.".

I hope that the -11 level of the zArch Principle of Operation
manual learns the difference between "all" and instructions
in one chapter.
somitcw@yahoo.com [hercules-390]
2017-01-18 14:05:57 UTC
Permalink
This is my third attempt to post over two days.
I'll strip all I can out to try to keep yahoo happy.
I also added greater-than signs.
I will also split to two posts.
Date: Tue, 17 Jan 2017 16:09:12 +0000
Subject: Re: Did IBM replace all format RXE with RXY ?
Ref: Your note of Tue, 17 Jan 2017 10:38:47 -0500
It appears that the Summary of Changes is incorrect. The
floating point RXE instructions did not change to RXY format.
Jonathan Scott
IBM Hursley, UK
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-01-18 14:57:54 UTC
Permalink
FYI to somitcw: I received your 2nd attempt and the below 3rd attempt just fine, but not your 1st attempt.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
-----Original Message-----
Sent: Wednesday, January 18, 2017 6:06 AM
Subject: [hercules-390] Re: Hercules status
This is my third attempt to post over two days.
I'll strip all I can out to try to keep yahoo happy.
I also added greater-than signs.
I will also split to two posts.
Date: Tue, 17 Jan 2017 16:09:12 +0000
Subject: Re: Did IBM replace all format RXE with RXY ?
Ref: Your note of Tue, 17 Jan 2017 10:38:47 -0500
It appears that the Summary of Changes is incorrect. The
floating point RXE instructions did not change to RXY format.
Jonathan Scott
IBM Hursley, UK
<snip remainder>
Loading...