[hercules-390] S/380 Integration

[Harold Grovesteen [e-mail] [hercules-390]]

To level set some expectations around this topic. I have a fairly
standard approach to development. Some people like to sit in front of
the computer and just start coding. I tend to take a different
approach. I usually research what needs doing and documenting what
needs to be done. Design or plan or both if you will.

I also feel that with some of the controversy associated with the topic,
I will need to describe the changes that are required in Hercules before
doing them. A degree of "buy in" or approval from others will go along
way.

My first task will be describing in more details what is to be
integrated. There are many things related to S/380 an its supporting
operating systems that needs to be understood by me.

I guess the first thing I need to do is join the hercules-os380 group.
Is that the correct Yahoo group?

Thanks,
Harold Grovesteen

[[e-mail] [hercules-390]]

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
I guess the first thing I need to do is join the hercules-os380 group.
Is that the correct Yahoo group?

I believe so.

Everyone is welcome to join!
hercules-os380 https://groups.yahoo.com/neo/groups/hercules-os380/info




https://groups.yahoo.com/neo/groups/hercules-os380/info

hercules-os380 https://groups.yahoo.com/neo/groups/hercules-os380/info Discussion of everything related to the OS/380 family of operating systems (MVS/380, VM/380, VSE/380), the hardware it runs on (S/380), the softwar...



View on groups.yahoo.com https://groups.yahoo.com/neo/groups/hercules-os380/info
Preview by Yahoo



ScottC

[Harold Grovesteen [e-mail] [hercules-390]]

I have confirmed my request (to Yahoo) that I wish to join
hercules-os380.

Harold

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
I guess the first thing I need to do is join the

hercules-os380 group.

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
Is that the correct Yahoo group?

I believe so.

Everyone is welcome to join!
hercules-os380

[Tony Harminc [e-mail] [hercules-390]]

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
To level set some expectations around this topic. I have a fairly
standard approach to development. Some people like to sit in front of
the computer and just start coding. I tend to take a different
approach. I usually research what needs doing and documenting what
needs to be done. Design or plan or both if you will.

Yay!

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
I also feel that with some of the controversy associated with the topic,
I will need to describe the changes that are required in Hercules before
doing them. A degree of "buy in" or approval from others will go along
way.
My first task will be describing in more details what is to be
integrated. There are many things related to S/380 an its supporting
operating systems that needs to be understood by me.

In my opinion one thing that needs to be done is to produce a small
"Principles of Operation" akin to the very first S/370 one
(GA22-7000-00). This would be an add-on to the last "real" S/370 PofO
(-10, I think), and might plausibly contain careful references to the
XA or even zArch books. While Paul has a document that he calls a
System/380 Principles of Operation, very little of it describes
hardware behaviour. It is mostly a collection of history and polemical
views on this and that, along with a great deal of MVS/380 and related
information that has little or nothing to do with the hardware
definition. A dispassionate review could extract the basic technical
info, while avoiding such terms as "crap byte".

Tony H.

[[e-mail] [hercules-390]]

It would be worth running it past Paul
in case he can identify anything that's
missing to support an e.g. fully ATL-safe VM
(i.e. able to support multiple guests using ATL).

There are 3 dirty things I know of in
Hercules/380:

1. By default, ATL is free-for-all

2. Some crappy code was added
to make VM/380 work - that crappy
code should be put into CP, not
Hercules/380.

3. Some crappy code was put into
Hercules/380 to intercept GETVIS
storage requests in VSE/380. The
code belongs in VSE/380 instead.

I don't have a problem if these
crappy things are not implemented
in the official Hercules.

Note that without these crappy things,
PDOS/380 is the only thing that will
actually run. However, I believe at
least with MVS/380, someone will
be willing to write the small amount
of code required to activate the
non-crappy CR13 (Laddie's design).

BFN. Paul.

In my opinion one thing that needs to be done is to produce a small
"Principles of Operation" akin to the very first S/370 one
(GA22-7000-00). This would be an add-on to the last "real" S/370 PofO
(-10, I think), and might plausibly contain careful references to the
XA or even zArch books.

Seconded. A clear statement of what's been added on top of S/370 to get
to Notional/380. It would be worth running it past Paul in case he can
identify anything that's missing to support an e.g. fully ATL-safe VM
(i.e. able to support multiple guests using ATL).

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

[Ivan Warren [e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]

It would be worth running it past Paul
in case he can identify anything that's
missing to support an e.g. fully ATL-safe VM
(i.e. able to support multiple guests using ATL).

There are 3 dirty things I know of in
1. By default, ATL is free-for-all

S/380 breaks every virtualization principle.

Post by ***@yahoo.com.au [hercules-390]
2. Some crappy code was added
to make VM/380 work - that crappy
code should be put into CP, not
Hercules/380.

S/380 break every virtualization principle

Post by ***@yahoo.com.au [hercules-390]
3. Some crappy code was put into
Hercules/380 to intercept GETVIS
storage requests in VSE/380. The
code belongs in VSE/380 instead.

S/380 break every virtualization principle

Post by ***@yahoo.com.au [hercules-390]
I don't have a problem if these
crappy things are not implemented
in the official Hercules.

Me neither !

Post by ***@yahoo.com.au [hercules-390]
Note that without these crappy things,
PDOS/380 is the only thing that will
actually run. However, I believe at
least with MVS/380, someone will
be willing to write the small amount
of code required to activate the
non-crappy CR13 (Laddie's design).
BFN. Paul.

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
I don't have a problem if these
crappy things are not implemented
in the official Hercules.

Me neither !

But I don't consider Laddie's CR13
design to be crappy, and I believe it
should exist in the official Hercules
at least as a non-default option
that people can switch on at
compile time (at least).

In addition, I don't consider somitcw's
request for CR0.10 to enable a full
XA DAT in S/370 mode to be crappy.
Even though it's non-crappy, I can
understand if people say "already
covered by Harold's S/370 I/O
forward port", but I'm not 100%
sure that argument is correct. And
again - at least able to be enabled
at compile time.

BFN. Paul.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
It would be worth running it past Paul
in case he can identify anything that's
missing to support an e.g. fully ATL-safe VM
(i.e. able to support multiple guests using ATL).

There are 3 dirty things I know of in
1. By default, ATL is free-for-all

S/380 breaks every virtualization principle.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
2. Some crappy code was added
to make VM/380 work - that crappy
code should be put into CP, not
Hercules/380.

S/380 break every virtualization principle

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
3. Some crappy code was put into
Hercules/380 to intercept GETVIS
storage requests in VSE/380. The
code belongs in VSE/380 instead.

S/380 break every virtualization principle

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
I don't have a problem if these
crappy things are not implemented
in the official Hercules.

Me neither !

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Note that without these crappy things,
PDOS/380 is the only thing that will
actually run. However, I believe at
least with MVS/380, someone will
be willing to write the small amount
of code required to activate the
non-crappy CR13 (Laddie's design).
BFN. Paul.

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]
However, I believe at
least with MVS/380, someone will
be willing to write the small amount
of code required to activate the
non-crappy CR13 (Laddie's design).

Note that the "small amount" of
code I envision would, at least
for now, restore the free-for-all.
ie at startup, CR13 is set to map
all ATL memory, and that's it.

The crappiness is moved out of
Hercules/380 and into MVS/380.

MVS/380 can be improved in due
course, where it will require more
than a "small amount" of code.

BFN. Paul.

Post by ***@yahoo.com.au [hercules-390]
It would be worth running it past Paul
in case he can identify anything that's
missing to support an e.g. fully ATL-safe VM
(i.e. able to support multiple guests using ATL).

There are 3 dirty things I know of in
Hercules/380:

1. By default, ATL is free-for-all

2. Some crappy code was added
to make VM/380 work - that crappy
code should be put into CP, not
Hercules/380.

3. Some crappy code was put into
Hercules/380 to intercept GETVIS
storage requests in VSE/380. The
code belongs in VSE/380 instead.

I don't have a problem if these
crappy things are not implemented
in the official Hercules.

Note that without these crappy things,
PDOS/380 is the only thing that will
actually run. However, I believe at
least with MVS/380, someone will
be willing to write the small amount
of code required to activate the
non-crappy CR13 (Laddie's design).

BFN. Paul.

Post by ***@yahoo.com.au [hercules-390]
In my opinion one thing that needs to be done is to produce a small
"Principles of Operation" akin to the very first S/370 one
(GA22-7000-00). This would be an add-on to the last "real" S/370 PofO
(-10, I think), and might plausibly contain careful references to the
XA or even zArch books.

Seconded. A clear statement of what's been added on top of S/370 to get
to Notional/380. It would be worth running it past Paul in case he can
identify anything that's missing to support an e.g. fully ATL-safe VM
(i.e. able to support multiple guests using ATL).

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

[[e-mail] [hercules-390]]

Good evening,


just for the records: an implementation of multi-user capable ATL-Support for VM/380 is already there and can be found in the "s381-for-vm380" folder of the files section of the H390-VM group.


In short: S/381 is an extension of S/380 allowing to run VMs each with an own ATL memory space. The largest part of the implementation is in Hercules, whereas CP requires only 2 small changes.


S/3xx architecture purists will find it indiscutable, as the Load/Store Control Register instructions are misused to support the ATL isolation between VMs.


But on the other hand: it works...


Greetings
Hans

Post by Tony Harminc ***@gmail.com [hercules-390]
In my opinion one thing that needs to be done is to produce a small
"Principles of Operation" akin to the very first S/370 one
(GA22-7000-00). This would be an add-on to the last "real" S/370 PofO
(-10, I think), and might plausibly contain careful references to the
XA or even zArch books.

Seconded. A clear statement of what's been added on top of S/370 to get
to Notional/380. It would be worth running it past Paul in case he can
identify anything that's missing to support an e.g. fully ATL-safe VM
(i.e. able to support multiple guests using ATL).

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

[[e-mail] [hercules-390]]

Post by ***@yahoo.com [hercules-390]
In short: S/381 is an extension of S/380
allowing to run VMs each with an own
ATL memory space. The largest part
of the implementation is in Hercules,
whereas CP requires only 2 small changes.

Hi Hanz.

Wouldn't it be more logical to put the
major code changes in CP and just have
a relatively simple split DAT in Hercules?

BFN. Paul.





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

Good evening,


just for the records: an implementation of multi-user capable ATL-Support for VM/380 is already there and can be found in the "s381-for-vm380" folder of the files section of the H390-VM group.


In short: S/381 is an extension of S/380 allowing to run VMs each with an own ATL memory space. The largest part of the implementation is in Hercules, whereas CP requires only 2 small changes.


S/3xx architecture purists will find it indiscutable, as the Load/Store Control Register instructions are misused to support the ATL isolation between VMs.


But on the other hand: it works...


Greetings
Hans

Post by ***@yahoo.com [hercules-390]
In my opinion one thing that needs to be done is to produce a small
"Principles of Operation" akin to the very first S/370 one
(GA22-7000-00). This would be an add-on to the last "real" S/370 PofO
(-10, I think), and might plausibly contain careful references to the
XA or even zArch books.

Seconded. A clear statement of what's been added on top of S/370 to get
to Notional/380. It would be worth running it past Paul in case he can
identify anything that's missing to support an e.g. fully ATL-safe VM
(i.e. able to support multiple guests using ATL).

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

[Ivan Warren [e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]

Post by ***@yahoo.com [hercules-390]
In short: S/381 is an extension of S/380
allowing to run VMs each with an own
ATL memory space. The largest part
of the implementation is in Hercules,
whereas CP requires only 2 small changes.

Hi Hanz.
Wouldn't it be more logical to put the
major code changes in CP and just have
a relatively simple split DAT in Hercules?
BFN. Paul.

Wouldn't it be more simple to leave things as they are ?

--Ivan



[Non-text portions of this message have been removed]

[Gerhard Postpischil [e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Wouldn't it be more simple to leave things as they are ?

With that mindset we'd still be living in trees <g>

Gerhard Postpischil
Bradford, VT


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

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

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/

[Ivan Warren [e-mail] [hercules-390]]

Post by Gerhard Postpischil ***@charter.net [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Wouldn't it be more simple to leave things as they are ?

With that mindset we'd still be living in trees <g>

It depends on the mindset behind the project.

Otherwise we could also go to a full fledged Intel emulator.

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Otherwise we could also go to a full fledged Intel emulator.

It is ludicrous to suggest that the small
changes required to Hercules to enable
new platforms, such as S/380 or
Fujitsu MSP, are the equivalent of
emulating Intel instructions.

There are actually ZERO new instructions
in S/380, compared to numerous Intel
instructions. If you can't tell the difference
between 0 and numerous, I won't be able
to explain it any better.

BFN. Paul.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Wouldn't it be more simple to leave things as they are ?

With that mindset we'd still be living in trees <g>

It depends on the mindset behind the project.

Otherwise we could also go to a full fledged Intel emulator.

--Ivan



[Non-text portions of this message have been removed]

[Ivan Warren [e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Otherwise we could also go to a full fledged Intel emulator.

It is ludicrous to suggest that the small
changes required to Hercules to enable
new platforms, such as S/380 or
Fujitsu MSP, are the equivalent of
emulating Intel instructions.
There are actually ZERO new instructions
in S/380, compared to numerous Intel
instructions. If you can't tell the difference
between 0 and numerous, I won't be able
to explain it any better.
BFN. Paul.

Complete different architecture.

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
There are actually ZERO new instructions
in S/380, compared to numerous Intel

Complete different architecture.

It IS a different architecture, which is
why it is named S/380 instead of
either S/370 or S/390.

However, the changes to Hercules
required to support this new
architecture are miniscule. Like
less than 1% of the Hercules
code base.

Supporting intel architecture would
likely double the Hercules code
base.

If you can't tell the difference, others
can.

BFN. Paul.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
Otherwise we could also go to a full fledged Intel emulator.

It is ludicrous to suggest that the small
changes required to Hercules to enable
new platforms, such as S/380 or
Fujitsu MSP, are the equivalent of
emulating Intel instructions.
There are actually ZERO new instructions
in S/380, compared to numerous Intel
instructions. If you can't tell the difference
between 0 and numerous, I won't be able
to explain it any better.
BFN. Paul.

Complete different architecture.

--Ivan



[Non-text portions of this message have been removed]

[Gregg Levine [e-mail] [hercules-390]]

Hello!
Has it occurred to you folks that all of this has become an early duck
hunt with snipers? And no one is winning. Please stop. All of you have
good ideas and that extension idea should be available via a configure
selection.

Besides this is the fault of two people for it going on this long.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."

Post by ***@yahoo.com.au [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
There are actually ZERO new instructions
in S/380, compared to numerous Intel

Complete different architecture.

It IS a different architecture, which is
why it is named S/380 instead of
either S/370 or S/390.
However, the changes to Hercules
required to support this new
architecture are miniscule. Like
less than 1% of the Hercules
code base.
Supporting intel architecture would
likely double the Hercules code
base.
If you can't tell the difference, others
can.
BFN. Paul.

[Ivan Warren [e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
There are actually ZERO new instructions
in S/380, compared to numerous Intel

Complete different architecture.

It IS a different architecture, which is
why it is named S/380 instead of
either S/370 or S/390.
However, the changes to Hercules
required to support this new
architecture are miniscule. Like
less than 1% of the Hercules
code base.
Supporting intel architecture would
likely double the Hercules code
base.
If you can't tell the difference, others
can.
BFN. Paul.

What is the purpose ?

S/370 is to support legacy OS (which CAN be improved - VM/370 ? MVS ? DOS ?)
XA-ESA is to support legacy OS (Which can possibly also be improved
including Linux/390)
z/Arch is to support current OSes (especially z/Linux - and possibly
others).

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
If you can't tell the difference, others
can.

What is the purpose ?
S/370 is to support legacy OS (which CAN be improved - VM/370 ? MVS ? DOS ?)
XA-ESA is to support legacy OS (Which can possibly also be improved
including Linux/390)
z/Arch is to support current OSes (especially z/Linux - and possibly
others).

The purpose of S/380 is to be able to
manipulate ATL storage for legacy
operating systems where we don't
have the source code or even the
compiler in order to change the BTL
manipulations, but we can safely add
code to manipulate ATL storage
because the legacy OS has no
knowledge about the ATL storage.

This has been shown to work in
practice, and a program such as
GCCMVS which uses a lot of
storage (ie more than 16 MiB)
is able to run perfectly fine for
almost a decade without issue.

Let me know if that is not clear.

BFN. Paul.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
There are actually ZERO new instructions
in S/380, compared to numerous Intel

Complete different architecture.

It IS a different architecture, which is
why it is named S/380 instead of
either S/370 or S/390.
However, the changes to Hercules
required to support this new
architecture are miniscule. Like
less than 1% of the Hercules
code base.
Supporting intel architecture would
likely double the Hercules code
base.
If you can't tell the difference, others
can.
BFN. Paul.

What is the purpose ?

S/370 is to support legacy OS (which CAN be improved - VM/370 ? MVS ? DOS ?)
XA-ESA is to support legacy OS (Which can possibly also be improved
including Linux/390)
z/Arch is to support current OSes (especially z/Linux - and possibly
others).

--Ivan



[Non-text portions of this message have been removed]

[Ivan Warren [e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
If you can't tell the difference, others
can.

What is the purpose ?
S/370 is to support legacy OS (which CAN be improved - VM/370 ? MVS ? DOS ?)
XA-ESA is to support legacy OS (Which can possibly also be improved
including Linux/390)
z/Arch is to support current OSes (especially z/Linux - and possibly
others).

The purpose of S/380 is to be able to
manipulate ATL storage for legacy
operating systems where we don't
have the source code or even the
compiler in order to change the BTL
manipulations, but we can safely add
code to manipulate ATL storage
because the legacy OS has no
knowledge about the ATL storage.
This has been shown to work in
practice, and a program such as
GCCMVS which uses a lot of
storage (ie more than 16 MiB)
is able to run perfectly fine for
almost a decade without issue.
Let me know if that is not clear.
BFN. Paul.

It is perfectly unclear to me.

The Idea of hercules is to provide the mainframe experience... not a
specific requirement from a specific person.

If you intend to drive hercules into YOUR architecure - but it's no
longer the S/370, S/390 and z/Arch architecture hercules is intended to
be.. Call it : Paul's Architecture (or whatever you wish).

Your stuff, your project... not mine.

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
The Idea of hercules is to provide the
mainframe experience...

S/380 *is* a mainframe experience,
in the same way that Fujitsu MSP is,
even if it was (theoretically) slightly
different from IBM's offerings.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
not a specific requirement from a specific person.

It is a general requirement for anyone
who has a large program they wish
to run on a free MVS-style operating
system, e.g. Free Pascal or RPF380.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
If you intend to drive hercules into
YOUR architecure - but it's no
longer the S/370, S/390 and z/Arch

True, it's none of those. It's S/380.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
architecture hercules is intended to be..

Intended to be according to who? Where
does it say that if Fujitsu hardware is
found to be slightly different to IBM,
then it is ABSOLUTELY NOT allowed
to add small changes to Hercules to
support Fujitsu hardware?

Where is that strange attitude set in stone?

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Call it : Paul's Architecture (or whatever you wish).
Your stuff, your project... not mine.

Yes, that's the "my way or the highway"
attitude I encountered a decade ago,
and why I have been travelling on the
highway, with Hercules/380, ever since.

BFN. Paul.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
If you can't tell the difference, others
can.

What is the purpose ?
S/370 is to support legacy OS (which CAN be improved - VM/370 ? MVS ? DOS ?)
XA-ESA is to support legacy OS (Which can possibly also be improved
including Linux/390)
z/Arch is to support current OSes (especially z/Linux - and possibly
others).

The purpose of S/380 is to be able to
manipulate ATL storage for legacy
operating systems where we don't
have the source code or even the
compiler in order to change the BTL
manipulations, but we can safely add
code to manipulate ATL storage
because the legacy OS has no
knowledge about the ATL storage.
This has been shown to work in
practice, and a program such as
GCCMVS which uses a lot of
storage (ie more than 16 MiB)
is able to run perfectly fine for
almost a decade without issue.
Let me know if that is not clear.
BFN. Paul.

It is perfectly unclear to me.

The Idea of hercules is to provide the mainframe experience... not a
specific requirement from a specific person.

If you intend to drive hercules into YOUR architecure - but it's no
longer the S/370, S/390 and z/Arch architecture hercules is intended to
be.. Call it : Paul's Architecture (or whatever you wish).

Your stuff, your project... not mine.

--Ivan



[Non-text portions of this message have been removed]

[Ivan Warren [e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
The Idea of hercules is to provide the
mainframe experience...

S/380 *is* a mainframe experience,
in the same way that Fujitsu MSP is,
even if it was (theoretically) slightly
different from IBM's offerings.

You're requirement....

Post by ***@yahoo.com.au [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
not a specific requirement from a specific person.

It is a general requirement for anyone
who has a large program they wish
to run on a free MVS-style operating
system, e.g. Free Pascal or RPF380.

You're requirement

Post by ***@yahoo.com.au [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
If you intend to drive hercules into
YOUR architecure - but it's no
longer the S/370, S/390 and z/Arch

True, it's none of those. It's S/380.

Not Hercules... Which is a S/370, Esa 390 and z/Arch emulator

Post by ***@yahoo.com.au [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
architecture hercules is intended to be..

Intended to be according to who? Where
does it say that if Fujitsu hardware is
found to be slightly different to IBM,
then it is ABSOLUTELY NOT allowed
to add small changes to Hercules to
support Fujitsu hardware?
Where is that strange attitude set in stone?

The principles of the project - a S/370, ESA/390 and z/Arch emulator

Post by ***@yahoo.com.au [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Call it : Paul's Architecture (or whatever you wish).
Your stuff, your project... not mine.

Yes, that's the "my way or the highway"
attitude I encountered a decade ago,
and why I have been travelling on the
highway, with Hercules/380, ever since.
BFN. Paul.

Your way... Call it Paul's Highway... Call it Paul's Herc... whatever...

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
If you intend to drive hercules into
YOUR architecure - but it's no
longer the S/370, S/390 and z/Arch

True, it's none of those. It's S/380.

Not Hercules... Which is a S/370, Esa 390 and z/Arch emulator

Currently. But that may change in the future.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
architecture hercules is intended to be..

Intended to be according to who? Where
does it say that if Fujitsu hardware is
found to be slightly different to IBM,
then it is ABSOLUTELY NOT allowed
to add small changes to Hercules to
support Fujitsu hardware?
Where is that strange attitude set in stone?

The principles of the project - a S/370,
ESA/390 and z/Arch emulator

So if Hercules had been developed in
increments, starting with S/370, you
would have been vocal at the S/390
stage saying "no no we can't add
S/390, this is strictly a S/370 project"?

Or are you an IBM stooge who
only allows official IBM hardware to
be supported, because you don't
want competition from Fujitsu or
any other manufacture's equipment?

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Your way... Call it Paul's Highway...
Call it Paul's Herc... whatever...

I have called it Hercules/380
because the most noticeable
thing it supports is the S/380
architecture.

I might consider renaming it if
it starts supporting slightly
different Fujitsu hardware (not
allowed in to mainstream
Hercules by a possible IBM
stooge) too. Maybe Hercules/F380.

BFN. Paul.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
The Idea of hercules is to provide the
mainframe experience...

S/380 *is* a mainframe experience,
in the same way that Fujitsu MSP is,
even if it was (theoretically) slightly
different from IBM's offerings.

You're requirement....

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
not a specific requirement from a specific person.

It is a general requirement for anyone
who has a large program they wish
to run on a free MVS-style operating
system, e.g. Free Pascal or RPF380.

You're requirement

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
If you intend to drive hercules into
YOUR architecure - but it's no
longer the S/370, S/390 and z/Arch

True, it's none of those. It's S/380.

Not Hercules... Which is a S/370, Esa 390 and z/Arch emulator

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
architecture hercules is intended to be..

Intended to be according to who? Where
does it say that if Fujitsu hardware is
found to be slightly different to IBM,
then it is ABSOLUTELY NOT allowed
to add small changes to Hercules to
support Fujitsu hardware?
Where is that strange attitude set in stone?

The principles of the project - a S/370, ESA/390 and z/Arch emulator

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
Call it : Paul's Architecture (or whatever you wish).
Your stuff, your project... not mine.

Yes, that's the "my way or the highway"
attitude I encountered a decade ago,
and why I have been travelling on the
highway, with Hercules/380, ever since.
BFN. Paul.

Your way... Call it Paul's Highway... Call it Paul's Herc... whatever...

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

In hercules-***@yahoogroups.com, <***@...> wrote:
- - - most of beginning snipped - - -
The principles of the project - a S/370, ESA/390 and z/Arch emulator
- - - ending removed - - -

Wow, I'm impressed.

<tongue-in-cheek>
A zArch emulator before the first zArch Prin.of.Op came out.
</tongue-in-cheek>

[Mike Schwab [e-mail] [hercules-390]]

<deleted>
Not Hercules... Which is a S/370, Esa 390 and z/Arch emulator

<deleted>

The principles of the project - a S/370, ESA/390 and z/Arch emulator

<deleted>

Your way... Call it Paul's Highway... Call it Paul's Herc... whatever...
--Ivan

Without touching S/370, ESA/390, or ESAME, Paul is calling his mode
S/380. All new architeture mode that pulls in all of S/370, A few
features of ESA/390 or ESAME, and a few custom features to let Free
S/370 access more than 16MB of memory.

If you ask for S/370, ESA/390, or ESAME, you won't see any changes.

[[e-mail] [hercules-390]]

Post by Mike Schwab ***@gmail.com [hercules-390]
If you ask for S/370, ESA/390, or ESAME,
you won't see any changes.

Exactly. A non-default compile option that
harms no-one at all other than potentially
IBM, as they are starting to get a 31-bit
rival.

BFN. Paul.

Post by Mike Schwab ***@gmail.com [hercules-390]
<deleted>
Not Hercules... Which is a S/370, Esa 390 and z/Arch emulator

<deleted>

Post by Mike Schwab ***@gmail.com [hercules-390]
The principles of the project - a S/370, ESA/390 and z/Arch emulator

<deleted>

Post by Mike Schwab ***@gmail.com [hercules-390]
Your way... Call it Paul's Highway... Call it Paul's Herc... whatever...
--Ivan

Without touching S/370, ESA/390, or ESAME, Paul is calling his mode
S/380. All new architeture mode that pulls in all of S/370, A few
features of ESA/390 or ESAME, and a few custom features to let Free
S/370 access more than 16MB of memory.

If you ask for S/370, ESA/390, or ESAME, you won't see any changes.


--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

[[e-mail] [hercules-390]]

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

Post by ***@yahoo.com.au [hercules-390]
BFN. Paul.

"BFN. Paul"...we wish.

<Tongue-in-cheek>
Turnkey-MVS Founded: Oct 1, 2002 already has 9243 messages.
hercules-os380 Founded: Sep 4, 2008 only has 9213 messages.
Why is there 30 messages less interest in MVS 3.8j with
31-bit addressing than in MVS 3.8j with 24 bit addressing?
</Tongue-in-cheek>

[Kevin Monceaux [e-mail] [hercules-390]]

Post by ***@yahoo.com [hercules-390]
<Tongue-in-cheek>
Turnkey-MVS Founded: Oct 1, 2002 already has 9243 messages.
hercules-os380 Founded: Sep 4, 2008 only has 9213 messages.
Why is there 30 messages less interest in MVS 3.8j with
31-bit addressing than in MVS 3.8j with 24 bit addressing?
</Tongue-in-cheek>

The word only above should probably be replaced with already. The
Hercules-OS380 mailing list is six years younger than the Turnkey-MVS
mailing list and already has almost as many messages as the older list. The
Turnkey-MVS mailing list has had an average of 994 messages a year, while
the Hercules-OS380 mailing list has had an average of 1,247 messages a year.

[[e-mail] [hercules-390]]

Post by ***@yahoo.com [hercules-390]
<Tongue-in-cheek>
Turnkey-MVS Founded: Oct 1, 2002 already has 9243 messages.
hercules-os380 Founded: Sep 4, 2008 only has 9213 messages.
Why is there 30 messages less interest in MVS 3.8j with
31-bit addressing than in MVS 3.8j with 24 bit addressing?
</Tongue-in-cheek>

The word only above should probably be replaced with already. The
Hercules-OS380 mailing list is six years younger than the Turnkey-MVS
mailing list and already has almost as many messages as the older list. The
Turnkey-MVS mailing list has had an average of 994 messages a year, while
the Hercules-OS380 mailing list has had an average of 1,247 messages a year."

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

According to the Yahoo interface with latest message number in URL:

Turnkey-MVS has 9244 messages. hercules-s380 has 632 ( 568 in 1st 3 months of existence )

See https://groups.yahoo.com/neo/groups/hercules-380/info https://groups.yahoo.com/neo/groups/hercules-380/info

If the founding dates are correct ( which it appears they are not Hercules-OS380 Nov 27, 2007 ) this would make 695 per year for Turnkey-MVS (13.3 years) vs 77 per year for Hercules-OS380 ( 8.16 years).

[Mike Schwab [e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
It is perfectly unclear to me.
The Idea of hercules is to provide the mainframe experience... not a
specific requirement from a specific person.
If you intend to drive hercules into YOUR architecure - but it's no
longer the S/370, S/390 and z/Arch architecture hercules is intended to
be.. Call it : Paul's Architecture (or whatever you wish).
Your stuff, your project... not mine.
--Ivan

We don't have a free 31 bit operating system.
We do have the last pure 24 bit operating systems.
There are memory size limits that applications (GCC, RPF) are running into.
The S/38x architetures are to allow MVS 3.8 to run in 31 bit mode.
Only applications specifically coded for MVS 380 (requesting over 16MB
of memory in one call) will get their request satisfied with memory
over the 16MB line. They will also run on MVS/XA, ESA, 390, z/OS.
That memory is only accessible to one ASID in S/38x.
Normal 24 bit applications won't see the memory.
Normal 31 bit applications with lots of small memory requests will run
out of space in 24 bit memory. (unless they change the loader and get
main routine)

The goal is to allow a few applications to run with more than 16MB of
memory as a substitute for a more modern Operating System that we
can't get. The design guidelines should result in object modules that
can run on z/OS without recompiling. Albeit with slightly different
memory management calls than usual.

[[e-mail] [hercules-390]]

Post by Mike Schwab ***@gmail.com [hercules-390]
We don't have a free 31 bit operating system.

Well I don't know that that is strictly true.
I think there is a 31-bit Linux. Also
MUSIC/SP allows 31-bit programming
to some extent. MTS 1996 is expected
to be available in due course. And then
there is the primitive PDOS/390.

Perhaps you meant "IBM operating system".

Post by Mike Schwab ***@gmail.com [hercules-390]
Normal 31 bit applications with lots of
small memory requests will run
out of space in 24 bit memory. (unless
they change the loader and get
main routine)

This is currently true, but I expect that
Gerhard will fix that problem in due
course and MVS/380 will support
fantastic memory capabilities with
regard to ANY/ANY modules.

BFN. Paul.

Post by Mike Schwab ***@gmail.com [hercules-390]
It is perfectly unclear to me.
The Idea of hercules is to provide the mainframe experience... not a
specific requirement from a specific person.
If you intend to drive hercules into YOUR architecure - but it's no
longer the S/370, S/390 and z/Arch architecture hercules is intended to
be.. Call it : Paul's Architecture (or whatever you wish).
Your stuff, your project... not mine.
--Ivan

We don't have a free 31 bit operating system.
We do have the last pure 24 bit operating systems.
There are memory size limits that applications (GCC, RPF) are running into.
The S/38x architetures are to allow MVS 3.8 to run in 31 bit mode.
Only applications specifically coded for MVS 380 (requesting over 16MB
of memory in one call) will get their request satisfied with memory
over the 16MB line. They will also run on MVS/XA, ESA, 390, z/OS.
That memory is only accessible to one ASID in S/38x.
Normal 24 bit applications won't see the memory.
Normal 31 bit applications with lots of small memory requests will run
out of space in 24 bit memory. (unless they change the loader and get
main routine)

The goal is to allow a few applications to run with more than 16MB of
memory as a substitute for a more modern Operating System that we
can't get. The design guidelines should result in object modules that
can run on z/OS without recompiling. Albeit with slightly different
memory management calls than usual.



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

[[e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
It is perfectly unclear to me.

BTW Ivan, even if it is unclear to
you, do you admit that it is clear
to lots of other people (ie not
just me)?

What do you think of those other
people who think it is clear?

And what do you think of those
people who think it is both clear
and desirable?

Are they all insane or stupid or
being devious pretending to
understand or what?

BFN. Paul.

[[e-mail] [hercules-390]]

Good morning,


it would be logical if the goal was to create a true 31-bit capable VM/xxx OS starting from VM/370. Extending CP with ATL-DAT management (and CMS: program loader, memory management etc.) would be an enormous task.


But what for? There seems to be only a very low call for 31-bit with VM/370, most been the C-compiler. The focus for 31-bit seems to be on MVS.


Personnaly, I find the possibility to use the "old" OS VM/370 with 31-bit programs very interresting, although I did'nt find time to develop real 31-bit programs.


My focus was to lift the restriction "only one ATL-user/VM at a time" for VM380. To minimize changes to (or avoid a major reconstruction of) the CP code (which I could'nt have done, I'm not an assembler or system programmer), implementing the major support software outside the legacy OS in the hardware emulator seemed the way to go for me, also allowing to easily implement value-added functionality in S/381 (ATL-heap seen inside the VM, API to query ATL configuration info). My simple approach was: give each VM needing ATL an own memory chunk, not managed by a DAT subsystem but exchanged in the real Memory space presented by Hercules to the OS each time CP dispatches to another VM.


BTW:
Would you ALL please stop the religion war about the orthodoxy of the hardware architectures supported by Hercules?
Hercules is a great software to run the class of OSes using the S/360 and onwards architecture, and the more people can and want to use it the better it is. And if these OSes can do more, then the better it is. Even if the S/360 descendance used by the OS is not strictly the lineage written down by a single company.
Adding useful features to the architecture is possible as Hercules is software instead of hardware.
And adding new useful features that allow some users to have a better OS but do not prevent other users to continue using their unmodified OS could be called "support your customers".
And these customers are not the Principle-of-Operation documents, but the people working Hercules.


Greetings from Berlin
Hans

Post by ***@yahoo.com [hercules-390]
In short: S/381 is an extension of S/380
allowing to run VMs each with an own
ATL memory space. The largest part
of the implementation is in Hercules,
whereas CP requires only 2 small changes.

Hi Hanz.

Wouldn't it be more logical to put the
major code changes in CP and just have
a relatively simple split DAT in Hercules?

BFN. Paul.





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

Good evening,


just for the records: an implementation of multi-user capable ATL-Support for VM/380 is already there and can be found in the "s381-for-vm380" folder of the files section of the H390-VM group.


In short: S/381 is an extension of S/380 allowing to run VMs each with an own ATL memory space. The largest part of the implementation is in Hercules, whereas CP requires only 2 small changes.


S/3xx architecture purists will find it indiscutable, as the Load/Store Control Register instructions are misused to support the ATL isolation between VMs.


But on the other hand: it works...


Greetings
Hans

Post by ***@yahoo.com [hercules-390]
In my opinion one thing that needs to be done is to produce a small
"Principles of Operation" akin to the very first S/370 one
(GA22-7000-00). This would be an add-on to the last "real" S/370 PofO
(-10, I think), and might plausibly contain careful references to the
XA or even zArch books.

Seconded. A clear statement of what's been added on top of S/370 to get
to Notional/380. It would be worth running it past Paul in case he can
identify anything that's missing to support an e.g. fully ATL-safe VM
(i.e. able to support multiple guests using ATL).

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Hans wrote:

[...]

Post by ***@yahoo.com [hercules-390]
And adding new useful features that allow some users
to have a better OS but do not prevent other users to
continue using their unmodified OS could be called
"support your customers".
And these customers are not the Principle-of-Operation
documents, but the people working Hercules.

Precisely. Which is why I for one support the spirit and intent of the S/380 and S/381 effort.

Providing OPTIONAL features is in general a Good Thing. Users wishing to take advantage of said option can do so while those who do not don't have to. Both sets of users are happy and the product itself becomes better overall because of it. It increases the number of satisfied users and the product is better because of it.

Leaving a large segment/subset of users out in the cold for mostly political/personal reasons is almost always *not* a very wise thing to do.

Creating a separate fork of Hyperion as Ivan suggested that contains Hyperion + S/38X *seems* on the face of it to be a proper resolution as it provides those users wanting a S/38X version of Hyperion a place to get it while keeping current Hyperion pure/clean/unpolluted, but in reality it is not a realistic solution.

First, the current maintainers of S/38X are admittedly not as skilled at maintaining/modifying the Hercules codebase as are the maintainers of the Hyperion code base, and their changes (I have not seen them myself) are likely more akin to "hacks" or "kludges" in order to accomplish their goal.

Officially and *properly* integrating their changes into the official Hyperion codebase however would ensure their changes were not only done *correctly* (in such a way as to not impact any of the existing non-S38X architectures) but also in such a manner as to make it easier to maintain overall while at the same time providing them with all the features and benefits that Hyperion has to offer that the current S38X codebase is currently lacking.

Second, doing so (integrating S38X into Hyperion) provides significant benefit for our users as well as it provides "One Stop Shopping" for a version of Hercules with or without S/38X support. There are already two different forks of Hercules (three if you count my own Hercules-ECPS-VSE fork(*)) -- Roger's Spinhawk (3.X series) and Hyperion (4.X series) -- and creating yet another will only confuse and alienate our users even further than they are already.

Having a separate fork also introduces the risk of that fork, not being the "official" version of the product, from not being properly maintained and thus "getting behind" over time, missing certain key fixes and/or enhancements that were made to the official version but not to the forked version. This alone is enough for users to shy away from said fork causing it to die of starvation if you will (from lack of proper "feeding" (maintenance)).

The bottom line is forking a popular, well established and mature product is rarely a Good Thing.

The only sensible thing to do is to provide for our users what they have for many years now quite clearly been patiently pleading us for: a version of Hercules/Hyperion with a USER SELECTABLE S/38X option (either via build option or config file option).

I for one say let's give them what they clearly want.

I vote yes.

[[e-mail] [hercules-390]]

Fish wrote:

"The only sensible thing to do is to provide for our users what they have for many years now quite clearly been patiently pleading us for: a version of Hercules/Hyperion with a USER SELECTABLE S/38X option (either via build option or config file option).

I for one say let's give them what they clearly want.

I vote yes."

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

I had refrained from getting into this as I thought it was resolved long ago. It seems to crop up again and again however. I may drift a bit as well.

The sole creator and maintainer of the 380 fork of hercules wants his changes to be adopted by the development fork of hercules because despite his capabilities in C coding the effort to bring forward his changes is too much for him to accomplish.

As one poster wrote, if they want specific 'features' they are free to create their own fork.

AFAIK there are currently 5 forks in use ( some by only a few people ):

3.12 Official release.
Juergen's TK4 has HAO features 3.12 doesn't have
380 fork based on 3.07
hyperion development snapshots
fish's something of other which I never heard of before

Among the above there are probably compile time options which can include 370 I/O in 390 mode ?

And many run time options/configurations which change behavior of the underlying architecture.

The available 370 OSes which are available have not substantially changed, yet Official Hercules has changed to correct bugs and add thing like HAO features. Most Linux distros still have 3.07 as the default install from their repositories yet we are at version 3.12. Can't help but think it's because of the fork between Official and development which has contributed to this.

Now there is another effort to embrace a design which does not comply with standard OSes, only exists for a very few end users ( 86 in Hercules-OS380 group ( like most groups many more join than utilize ) and further cements the divergence of Official and development releases. IIRC Roger didn't even like the idea it was called Hercules-380.

Someone recently posted as to whether their effort would be wasted, I think anything which pushes Official and development forks of Hercules further apart is counter-productive to Hercules as a whole.

Am tired and eye is hurting so I'm gone for now

Phil

[Harold Grovesteen [e-mail] [hercules-390]]

Post by ***@hotmail.com [hercules-390]
The sole creator and maintainer of the 380 fork of hercules wants his
changes to be adopted by the development fork of hercules because
despite his capabilities in C coding the effort to bring forward his
changes is too much for him to accomplish.
As one poster wrote, if they want specific 'features' they are free to
create their own fork.

We should cease thinking separate repositories constitute forks. The
development processes especially those with github embrace multiple
repositories.

Post by ***@hotmail.com [hercules-390]
Most Linux distros still have 3.07 as the default install from their
repositories yet we are at version 3.12. Can't help but think it's
because of the fork between Official and development which has
contributed to this.

There is no evidence I have seen to support that position. I have seen
evidence the QPL is not sufficiently open source for a distro to include
Hercules, or to feel they can maintain it themselves. It has also been
suggested that there is an absence of maintainers for some distros, so
Hercules is not being updated and distributed because the distro has
nobody maintaining it. When the two issues are combined it may be that
the Hercules project will have to maintain the package, per the disto's
requirements, for some distros to accept the package.

Post by ***@hotmail.com [hercules-390]
I think anything which pushes Official and development forks of
Hercules further apart is counter-productive to Hercules as a whole.

Philosophically I would agree. I am not in control of that or much
anything else.

Post by ***@hotmail.com [hercules-390]
Phil

Harold Grovesteen

[[e-mail] [hercules-390]]

Harold wrote:

"We should cease thinking separate repositories constitute forks. The
development processes especially those with github embrace multiple
repositories."

and

"There is no evidence I have seen to support that position. I have seen
evidence the QPL is not sufficiently open source for a distro to include
Hercules, or to feel they can maintain it themselves. ,,,"

Maybe I misunderstand the term FORK.

Official and development are separate not because of different github repositories but because 4.0 will never have it's changes incorporated into Official just as changes which have gone into Official may never work their way into development. Isn't that a FORK ?

Juergen's TK4 hercules has TCP/IP incorporated into it so it won't be merged back into Official or development ( you wanted to implement via diagnose but OS side software isn't written for that even if it is/were available ). Isn't that a FORK from both Official and development ?

Paul's 380 changes to base 3.07 have been sufficient for his and others purposes and yet there is much ado about incorporating them into a development version. When someone wants to get rid of the backlevel stigma ( not necessarily a bad thing if it works for them ) and maintenance of their mods onto other personnel, Isn't that a FORK from everything else ?

Distro hercules packages are:

Linux Mint 3.07
DEBIAN 3.07
UBUNTU 3.07
SUSE 3.11
Fedora 3.12
Arch 3.12

Speaking of the QPL, these distributions don't seem to have a problem including Hercules-390 even though DEBIAN seems to take exception to some of the QPL stipulations. The one that caught my eye was :

"Forced blanket license to the original developer"

So what does Roger want in any Hercules distribution/version/release ?

Phil

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Phil wrote:

[...]

Post by ***@hotmail.com [hercules-390]
Now there is another effort to embrace a design which
does not comply with standard OSes, only exists for a
very few end users ( 86 in Hercules-OS380 group ...

Um, wrong. The hercules-os380 group currently has 459 members, not 86.

I believe the confusion reigns from the fact that two completely different S/380 Yahoo Groups were created: one called "hercules-380" and another called "hercules-os380":


(NOT the official S/380 group):
https://groups.yahoo.com/neo/groups/hercules-380/info


(THE official S/380 group):
https://groups.yahoo.com/neo/groups/hercules-os380/info


The "380" group has only 86 members, but the *OFFICIAL* S/380 Yahoo Group ("OS380") and has *459* members.

Over 6% of the number of members subscribed to the main hercules-390 group is hardly "very few".

I would like to encourage those objecting to the S/380 effort (are you listening Ivan?) to read Jay's original SHARE presentation on the subject to refresh your memory that S/380 *was* at one point in time long ago, destined to become an *officially sanctioned* part of Hercules:

http://mvs380.sourceforge.net/share_mvs380.pdf

Why the code never made it into the official repository is unknown, but my guess would be the shrill objections of one or more members of the original Hercules development team at the time.

Jay Maynard saw the utility/importance of providing users what they wanted YEARS ago.

Why can't those *still* objecting to that concept today, years later, see that??

[Harold Grovesteen [e-mail] [hercules-390]]

On Sat, 2016-01-23 at 10:55 -0800, ''Fish' (David B. Trout)'

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Um, wrong. The hercules-os380 group currently has 459 members, not 86.
https://groups.yahoo.com/neo/groups/hercules-380/info

This was a group that I formed to discuss the forward-porting of channel
I/O to ESA/390 and/or z/Architecture. Yes, it is not the official
group.

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
https://groups.yahoo.com/neo/groups/hercules-os380/info
The "380" group has only 86 members, but the *OFFICIAL* S/380 Yahoo Group ("OS380") and has *459* members.

Harold Grovesteen

[[e-mail] [hercules-390]]

Post by ***@hotmail.com [hercules-390]
https://groups.yahoo.com/neo/groups/hercules-380/info https://groups.yahoo.com/neo/groups/hercules-380/info

This was a group that I formed to discuss the forward-porting of channel I/O to ESA/390 and/or z/Architecture. Yes, it is not the official group."
Ok, so Harold creates a group to discuss incorporating 380 'stuff' into hercules in 2007. In the last 7 years it has 70 messages total. There doesn't seem to be much demand in the unofficial created by a hercules developer forum for 380 'stuff'.

Phil

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Fish wrote:

[...]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
my guess would be the shrill objections of one or more members
of the original Hercules development team at the time.

Of which I was one of them I believe.

At that time.

SINCE then however, I have seen the light of day and no longer object to the idea. Rather, I simply want to ensure that when it is done, that it is done *correctly* (i.e. without impacting existing architectural support).

[[e-mail] [hercules-390]]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
SINCE then however, I have seen the
light of day and no longer object to the
idea.

I know it's a long-shot, but could you
perhaps explain how you were able
to be converted? Maybe if you can
set out the logic to conversion, Ivan
will follow it.

Note that I asked an anti-western
Russian to explain his conversion
(by me) to pro-western here:

http://sabodog.livejournal.com/2291.html

It took months/years to convert him.
Also, he is almost unique. I can only
name one other person (a Pakistani)
who I managed to convert, and his
English is too poor to do anything
much useful.

BFN. Paul.




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

Fish wrote:

[...]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
my guess would be the shrill objections of one or more members
of the original Hercules development team at the time.

Of which I was one of them I believe.

At that time.

SINCE then however, I have seen the light of day and no longer object to the idea. Rather, I simply want to ensure that when it is done, that it is done *correctly* (i.e. without impacting existing architectural support).

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com http://www.softdevlabs.com
mail: ***@... mailto:***@...

[[e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]
Note that I asked an anti-western
Russian

Whose name is also "Ivan" BTW. :-)

BFN. Paul.

[Ivan Warren [e-mail] [hercules-390]]

On 1/23/2016 3:44 PM, Mark Morgan Lloyd

[Remainder read carefully.]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
I vote yes.

I of course I vote no - This abomination has no place in hercules

It breaks EVERY principle the mainframe world gives.

--Ivan



[Non-text portions of this message have been removed]

['John P. Hartmann' [e-mail] [hercules-390]]

I downloaded http://mvs380.sourceforge.net/System380.txt, but found very
little information of the type one would put in a principles of
operation manual.

I'm sure Fish will agree that we need a formal specification of the
where the /380 diverges from (enhances, if you like) /370 before we can
even consider whether to implement it or not.

Since Ivan calls it an abomination (which is rather a strong word), it
is clear that we are speaking a new design and that the /380 operating
systems will need change. So the question is also whether anyone will
sign up to make such changes; otherwise this is just another exercise in
futility.

From my perspective, it would be the best strategy to make /380 as
close to the two systems that were built as part of IBM's XA effort (XA
cpu, /370 I/O), but chances of finding their PoO is slim to nil.

And please, cut out the swearing and mudslinging. It does not help to
be infantile if you want to be taken seriously.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
On 1/23/2016 3:44 PM, Mark Morgan Lloyd

[Remainder read carefully.]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
I vote yes.

I of course I vote no - This abomination has no place in hercules
It breaks EVERY principle the mainframe world gives.
--Ivan

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

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

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/

[Harold Grovesteen [e-mail] [hercules-390]]

On Sat, 2016-01-23 at 18:01 +0100, 'John P. Hartmann'

Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
I downloaded http://mvs380.sourceforge.net/System380.txt, but found very
little information of the type one would put in a principles of
operation manual.
I'm sure Fish will agree that we need a formal specification of the
where the /380 diverges from (enhances, if you like) /370 before we can
even consider whether to implement it or not.
Since Ivan calls it an abomination (which is rather a strong word), it
is clear that we are speaking a new design and that the /380 operating
systems will need change. So the question is also whether anyone will
sign up to make such changes; otherwise this is just another exercise in
futility.
From my perspective, it would be the best strategy to make /380 as
close to the two systems that were built as part of IBM's XA effort (XA
cpu, /370 I/O), but chances of finding their PoO is slim to nil.

I agree with all you have said here. A specification and design before
coding.

So far, individuals have adjusted the legacy operating systems to
accommodate the changes introduced by the 380 changes. Obviously they
can't "sign up" without knowing what those future changes might be. A
little bit of the old chicken and egg problem.

Now that I have successfully joined the hercules-os380 group, I can work
with them through the process, from research to specs to OS changes.

Further discussions will be on that group, for anyone interested.

Harold Grovesteen

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Harold Grovesteen wrote:

[...]

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
Now that I have successfully joined the hercules-os380
group, I can work with them through the process, from
research to specs to OS changes.

And for the record, that group is the FOLLOWING one (and not the other one someone else erroneously mentioned):


The OFFICIAL S/380 Yahoo group:

https://groups.yahoo.com/neo/groups/hercules-os380/info

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
Further discussions will be on that group, for anyone
interested.

Also a very good idea. We've wasted too much bandwidth on this subject already in this group. Further discussion should take place in the OS380 group (of which I too am now a member).

[[e-mail] [hercules-390]]

Fish wrote:

"Also a very good idea. We've wasted too much bandwidth on this subject already in this group. Further discussion should take place in the OS380 group (of which I too am now a member)."

What is this ? Discussion of changes to hercules-390 should not take place in the hercules-390 forum ?

It would be much more productive if someone could convince IBM to let XA go into the Public Domain or hobby license.

Phil

[Ivan Warren [e-mail] [hercules-390]]

Post by ***@hotmail.com [hercules-390]
"Also a very good idea. We've wasted too much bandwidth on this
subject already in this group. Further discussion should take place in
the OS380 group (of which I too am now a member)."
What is this ? Discussion of changes to hercules-390 should not take
place in the hercules-390 forum ?
It would be much more productive if someone could convince IBM to let
XA go into the Public Domain or hobby license.
Phil

Phil,

I do not think IBM or any other organization is putting any patent claim
on S/370 XA in itself.

--Ivan


[Non-text portions of this message have been removed]

[Ivan Warren [e-mail] [hercules-390]]

What is this ? Discussion of changes to hercules-390 should not take
place in the hercules-390 forum ?

It would be much more productive if someone could convince IBM to let
XA go into the Public Domain or hobby license.

Phil

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Phil,
I do not think IBM or any other organization is putting any patent claim
on S/370 XA in itself.
--Ivan

Please do not confuse patent and copyright.

--Ivan



[Non-text portions of this message have been removed]

[Tony Harminc [e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
I do not think IBM or any other organization is putting any patent claim
on S/370 XA in itself.

I'll bet they did patent aspects of the XA architecture, as they have
with everything up to zArch, where they have been patenting individual
machine instructions. The whole point of these (mostly bogus) patents
is to have something (many thousands of things in IBM's case) to
threaten competitors with. Look at the list IBM trotted out when
TurboHercules posed a tiny threat to them.

Now whether all the putative XA patents have expired is another matter entirely.

Tony H.

[Ivan Warren [e-mail] [hercules-390]]

Post by Tony Harminc ***@gmail.com [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
I do not think IBM or any other organization is putting any patent claim
on S/370 XA in itself.

I'll bet they did patent aspects of the XA architecture, as they have
with everything up to zArch, where they have been patenting individual
machine instructions. The whole point of these (mostly bogus) patents
is to have something (many thousands of things in IBM's case) to
threaten competitors with. Look at the list IBM trotted out when
TurboHercules posed a tiny threat to them.
Now whether all the putative XA patents have expired is another matter entirely.
Tony H.

The XA patents, pretty much sure they expired... Any XA capable OS
(except Linux which has a licence that make it usable), pretty sure they
are still copyrighted for another 50 years or so.

--Ivan




[Non-text portions of this message have been removed]

[Tony Harminc [e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
The XA patents, pretty much sure they expired... Any XA capable OS
(except Linux which has a licence that make it usable), pretty sure they
are still copyrighted for another 50 years or so.

As you just said, "Please do not confuse patent and copyright." I
really don't know why you brought patents into the discussion.

Tony H.

[Ivan Warren [e-mail] [hercules-390]]

Post by Tony Harminc ***@gmail.com [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
The XA patents, pretty much sure they expired... Any XA capable OS
(except Linux which has a licence that make it usable), pretty sure they
are still copyrighted for another 50 years or so.

As you just said, "Please do not confuse patent and copyright." I
really don't know why you brought patents into the discussion.
Tony H.

Because the original responder required that "XA" be made public domain.

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by Tony Harminc ***@gmail.com [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
The XA patents, pretty much sure they expired... Any XA capable OS
(except Linux which has a licence that make it usable), pretty sure they
are still copyrighted for another 50 years or so.

As you just said, "Please do not confuse patent and copyright." I
really don't know why you brought patents into the discussion.

Because the original responder required that "XA" be made public domain.

That doesn't answer the question. The
original poster asked for the copyright
of the XA software to change from
being copyrighted by IBM and into
public domain.

That has nothing to do with patents.

BFN. Paul.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by Tony Harminc ***@gmail.com [hercules-390]
The XA patents, pretty much sure they expired... Any XA capable OS
(except Linux which has a licence that make it usable), pretty sure they
are still copyrighted for another 50 years or so.

As you just said, "Please do not confuse patent and copyright." I
really don't know why you brought patents into the discussion.
Tony H.

Because the original responder required that "XA" be made public domain.

--Ivan



[Non-text portions of this message have been removed]

[Ivan Warren [e-mail] [hercules-390]]

That doesn't answer the question. The
original poster asked for the copyright
of the XA software to change from
being copyrighted by IBM and into
public domain.

That has nothing to do with patents.

BFN. Paul.



You are confusing Patent with copyright.

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Ivan wrote:

"Phil,

I do not think IBM or any other organization is putting any patent claim
on S/370 XA in itself."

Need more than that before XA is made available.

Phil

[[e-mail] [hercules-390]]

I wrote while Yahoo interface continues to play with my head:

"Need more than that before XA is made available."

Some years back a kind soul entrusted me with a bunch of boxes of tapes. Among them was a backup of a operational XA system. It includes many things which will never be released because it was a backup of a running installation with data in the databases.

On the other hand there were also the install tapes ( I think for XA ) along with several reels of Symbolics ( Source for the OS ). Some of these tapes I converted to AWS format and restored using Hercules to get the XA system running ( the SP1 system also backed up fails to run due to the previously mentioned E502 (Fix Page instruction not implemented in Hercules ) ).

Having several family medical and personal situations over the last 10 years I have not converted all of them to AWS format. My 9-track drive is one of the deck variety and occasionally a tape will seize to the head and some have stretched, not good for one of a kind tapes. Since I am still dealing with family situations and now my own health, I am looking for someone with a vacuum column drive to convert the remaining tapes with permission of the original owner. Please reply off list to opplr hotmail you should know the rest.

Phil

[[e-mail] [hercules-390]]

Post by ***@hotmail.com [hercules-390]
It would be much more productive if
someone could convince IBM to let
XA go into the Public Domain or
hobby license.

Every time someone suggests asking
IBM to open-source their valuable trade
secrets, it would be good if that person
would ring IBM and record the
conversation, so that we can all listen
to IBM's laughter.

BFN. Paul.






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

Fish wrote:

"Also a very good idea. We've wasted too much bandwidth on this subject already in this group. Further discussion should take place in the OS380 group (of which I too am now a member)."

What is this ? Discussion of changes to hercules-390 should not take place in the hercules-390 forum ?

It would be much more productive if someone could convince IBM to let XA go into the Public Domain or hobby license.

Phil

[[e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]
Every time someone suggests asking
IBM to open-source their valuable trade
secrets, it would be good if that person
would ring IBM and record the
conversation, so that we can all listen
to IBM's laughter.

Or even just allow the release of the
valuable object code. The laughter
level should be the same, and I'd
love to hear it. I can't ring them
myself, because I wouldn't be able
to keep a straight face while asking
them to do this.

BFN. Paul.

Post by ***@yahoo.com.au [hercules-390]
It would be much more productive if
someone could convince IBM to let
XA go into the Public Domain or
hobby license.

Every time someone suggests asking
IBM to open-source their valuable trade
secrets, it would be good if that person
would ring IBM and record the
conversation, so that we can all listen
to IBM's laughter.

BFN. Paul.






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

Fish wrote:

"Also a very good idea. We've wasted too much bandwidth on this subject already in this group. Further discussion should take place in the OS380 group (of which I too am now a member)."

What is this ? Discussion of changes to hercules-390 should not take place in the hercules-390 forum ?

It would be much more productive if someone could convince IBM to let XA go into the Public Domain or hobby license.

Phil

[[e-mail] [hercules-390]]

Post by ***@hotmail.com [hercules-390]
hobby license.

Note that even if they did release it
with a hobby license, it wouldn't
change a thing from my perspective
anyway.

I wish to create a public domain
alternative to z/OS so that it can
be freely used commercially.

BFN. Paul.






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

Fish wrote:

"Also a very good idea. We've wasted too much bandwidth on this subject already in this group. Further discussion should take place in the OS380 group (of which I too am now a member)."

What is this ? Discussion of changes to hercules-390 should not take place in the hercules-390 forum ?

It would be much more productive if someone could convince IBM to let XA go into the Public Domain or hobby license.

Phil

[Ivan Warren [e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]

Post by ***@hotmail.com [hercules-390]
hobby license.

Note that even if they did release it
with a hobby license, it wouldn't
change a thing from my perspective
anyway.
I wish to create a public domain
alternative to z/OS so that it can
be freely used commercially.
BFN. Paul.

Good luck with that.

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Paul wrote :

Note that even if they did release it
with a hobby license, it wouldn't
change a thing from my perspective
anyway.

I wish to create a public domain
alternative to z/OS so that it can
be freely used commercially.

So how many people do you think you need to recruit to support such an effort ?

How many commercial sites do you think would adopt such a thing ?

I am a hobbyist. My working days are behind me. I IPLed 3.8j only 1 time in the last 6 months or so. I have no desire to see the basic 370 architecture polluted with items which are seemingly a stepping stone to your targeted desire.

I don't mind run time additions like the TCP/IP module or 37X although I can't remember currently if I purposely even left out Greg Prices's FLIH for some additional instructions for 3.8j.

If I have a vote, I vote no for Paul's 380 kludge ( what it used to be called ).

Phil

[[e-mail] [hercules-390]]

Post by ***@hotmail.com [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
I wish to create a public domain
alternative to z/OS so that it can
be freely used commercially.

So how many people do you think
you need to recruit to support such
an effort ?

None. It already exists. The alternative
that already exists is certainly not as
good as z/OS, but it continues to grow.

Post by ***@hotmail.com [hercules-390]
How many commercial sites do you
think would adopt such a thing ?

I don't know. That is of secondary
interest to me. My primary interest is
to continue to expand the two
rivals to z/OS, namely MVS/380
and PDOS/390. Marketing is
someone else's problem.

Post by ***@hotmail.com [hercules-390]
I have no desire to see the basic 370
architecture polluted with items which
are seemingly a stepping stone to
your targeted desire.

S/370 is not being polluted. A new
S/380 is being created, which is
absolutely no skin off your back.

Post by ***@hotmail.com [hercules-390]
If I have a vote, I vote no for Paul's
380 kludge ( what it used to be called ).

It's not my kludge that is being discussed.
It is Laddie's CR13 properly architected
design that is being discussed. Are you
saying there is something wrong with
Laddie's design? If so, please elaborate.
Inquiring minds would like to know.

BFN. Paul.




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



Paul wrote :

Note that even if they did release it
with a hobby license, it wouldn't
change a thing from my perspective
anyway.

I wish to create a public domain
alternative to z/OS so that it can
be freely used commercially.

So how many people do you think you need to recruit to support such an effort ?

How many commercial sites do you think would adopt such a thing ?

I am a hobbyist. My working days are behind me. I IPLed 3.8j only 1 time in the last 6 months or so. I have no desire to see the basic 370 architecture polluted with items which are seemingly a stepping stone to your targeted desire.

I don't mind run time additions like the TCP/IP module or 37X although I can't remember currently if I purposely even left out Greg Prices's FLIH for some additional instructions for 3.8j.

If I have a vote, I vote no for Paul's 380 kludge ( what it used to be called ).

Phil

[Gerhard Postpischil [e-mail] [hercules-390]]

Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
Since Ivan calls it an abomination (which is rather a strong word), it
is clear that we are speaking a new design and that the /380 operating
systems will need change. So the question is also whether anyone will
sign up to make such changes; otherwise this is just another exercise in
futility.

I wouldn't consider it "strong", but misguided. According to Leviticus,
an abomination is something that requires ritual cleansing before
attending services. No idea how it got so abominably redefined <g>

Gerhard Postpischil
Bradford, VT


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

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

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/

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
I downloaded http://mvs380.sourceforge.net/System380.txt,
but found very little information of the type one would
put in a principles of operation manual.

I was going to mention that myself but forgot to, so thank you for pointing that out, John. The so-called S/380 "Principles of Operation" is a joke. (Or at the very least leaves a *lot* to be desired.)

Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
I'm sure Fish will agree that we need a formal specification
of the where the /380 diverges from (enhances, if you like)
/370 before we can even consider whether to implement it or not.

Agree 100%. This issue is key. Without a clear, well defined design document detailing what departures need to be made, S/380 just ain't gonna happen.


[...]

Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
From my perspective, it would be the best strategy
to make /380 as close to the two systems that were built
as part of IBM's XA effort (XA cpu, /370 I/O), but
chances of finding their PoO is slim to nil.

Again, I agree.

Regardless of the availability of such a manual however, the S/380 effort should proceed as you suggested IMHO.

If Paul or Harold or other(s) can manage to convert the existing "System380.txt" document into something more akin to a *real* Principles of Operation manual, that might do in lieu of any such existing but currently unavailable manual you previously mentioned.

[Tony Harminc [e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
I of course I vote no - This abomination has no place in hercules
It breaks EVERY principle the mainframe world gives.

So Ivan, I would've voted NO back when we were all talking about the
right way to architect this sort of hybrid in 2006 or whenever it was.
In fact I believe I *did* vote no... Paul went ahead and, as I've said
a number of times, used his "bias for action" to get a lot of things
running, despite the objections of the architectural purists (a group
of which I still consider myself a member).

Now we have a chance, it seems, to get some sort of extensions
*architected* in the product, to produce a PofO for them, and ensure
that existing architectures are not broken by the extensions. I am
convinced that this is now the right way to go. What Paul did may look
like any number of movies where the macho hero blasts ahead against
all advice from the experts, and makes it work, wins the war, etc.
etc. (Of course in the Hollywood version he also gets the girl and
saves the world from destruction and so on, but I think we can pass on
some of that.) But he *has* made great progress in getting things to
work, and we now (*if* Paul will control his blasting ahead for a
while, or at least keep it to himself) have the opportunity to do it
right.

So please tell me, where does your personal line lie? That is, is it a
matter of "no new architectural elements can be under any
circumstances added to Hercules beyond what IBM provides", or is it
more a matter of the ugliness of their implementation(s)? If the
former, then we probably have little to talk about in this context. If
the latter, then we have the basis for a discussion.

Tony H.

[Ivan Warren [e-mail] [hercules-390]]

Post by Tony Harminc ***@gmail.com [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
I of course I vote no - This abomination has no place in hercules
It breaks EVERY principle the mainframe world gives.

So please tell me, where does your personal line lie? That is, is it a
matter of "no new architectural elements can be under any
circumstances added to Hercules beyond what IBM provides", or is it
more a matter of the ugliness of their implementation(s)? If the
former, then we probably have little to talk about in this context. If
the latter, then we have the basis for a discussion.
Tony H.

My line is : NO...

You go that way - and I won't participate in this party I see as nowhere
near the goal of the project.

I have no issues turning hercules into S/380, Intel or Power
architecture whatsoever. I just will not participate in it.

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Note: I already sent an earlier version
of this message, but it hasn't shown up
yet, so I'm sending an updated version of it

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
I of course I vote no - This abomination has no place in hercules
It breaks EVERY principle the mainframe world gives.

Please explain why Laddie's CR13 design
is an abomination that breaks every
principle the mainframe world gives.

Name the principle, and say exactly
how Laddie violated it. I can't see it,
so please enlighten me.

BFN. Paul.


P.S. I see you have just said "NO" to
Tony's question. My question is not a
simple YES/NO. I want to you to state
something technically wrong with
Laddie's design, that it breaks some
principle. Basically put up or shut up.
Laddie is a very smart cookie and I
stand by his superb design.




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

On 1/23/2016 3:44 PM, Mark Morgan Lloyd

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
[Remainder read carefully.]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
I vote yes.

I of course I vote no - This abomination has no place in hercules

It breaks EVERY principle the mainframe world gives.

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
I of course I vote no - This abomination has no place in hercules
It breaks EVERY principle the mainframe world gives.

Please explain why Laddie's CR13 design
is an abomination that breaks every
principle the mainframe world gives.

Name the principle, and say exactly
how Laddie violated it. I can't see it,
so please enlighten me.

BFN. Paul.





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

On 1/23/2016 3:44 PM, Mark Morgan Lloyd

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
[Remainder read carefully.]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
I vote yes.

I of course I vote no - This abomination has no place in hercules

It breaks EVERY principle the mainframe world gives.

--Ivan



[Non-text portions of this message have been removed]

[Gerhard Postpischil [e-mail] [hercules-390]]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Providing OPTIONAL features is in general a Good Thing. Users
wishing to take advantage of said option can do so while those who do
not don't have to. Both sets of users are happy and the product
itself becomes better overall because of it. It increases the number
of satisfied users and the product is better because of it.

I agree with you, except on the use of optional features. Even though
you qualified it, I know of several installations that used IBM
extensions to CoBOL, and then had a difficult time switching to a
non-IBM platform. Purportedly there is one installation that after ten
years of effort is still not converted.

Gerhard Postpischil
Bradford, VT

[[e-mail] [hercules-390]]

On Sat, 23 Jan 2016 12:47:08 -0500

Post by Gerhard Postpischil ***@charter.net [hercules-390]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Providing OPTIONAL features is in general a Good Thing. Users
wishing to take advantage of said option can do so while those who do
not don't have to. Both sets of users are happy and the product
itself becomes better overall because of it. It increases the number
of satisfied users and the product is better because of it.

I agree with you, except on the use of optional features. Even though
you qualified it, I know of several installations that used IBM
extensions to CoBOL, and then had a difficult time switching to a
non-IBM platform. Purportedly there is one installation that after ten
years of effort is still not converted.

Are you talking about Prudential? I have a friend who worked at McAuto who
had a friend who wrote PruCOBOL at Prudential. From his description it
sounds like it would be something they would have a hard time getting away
from.

[Gerhard Postpischil [e-mail] [hercules-390]]

Post by ***@openmailbox.org [hercules-390]
Are you talking about Prudential? I have a friend who worked at McAuto who
had a friend who wrote PruCOBOL at Prudential. From his description it
sounds like it would be something they would have a hard time getting away
from.

No, but I don't remember who it was. I was considering installations
that used IBM language extension, rather than homebrew modifications
(although I've made some of those myself - our pre-RACF security was
based on account numbers rather job names).

Gerhard Postpischil
Bradford, VT


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

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

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/

[[e-mail] [hercules-390]]

On Sat, 23 Jan 2016 12:59:27 -0500

Post by Gerhard Postpischil ***@charter.net [hercules-390]

Post by ***@openmailbox.org [hercules-390]
Are you talking about Prudential? I have a friend who worked at McAuto
who had a friend who wrote PruCOBOL at Prudential. From his description
it sounds like it would be something they would have a hard time
getting away from.

No, but I don't remember who it was. I was considering installations
that used IBM language extension, rather than homebrew modifications
(although I've made some of those myself - our pre-RACF security was
based on account numbers rather job names).

I can't think of any shop I ever worked at that didn't use IBM language
extensions. I don't think they were necessarily aware of it but I also
don't think anybody was ever concerned that their code would run on any
other platform.

['Dave Wade' [e-mail] [hercules-390]]

-----Original Message-----
Sent: 23 January 2016 17:47
Subject: Re: [hercules-390] Re: S/380 Integration

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Providing OPTIONAL features is in general a Good Thing. Users wishing
to take advantage of said option can do so while those who do not
don't have to. Both sets of users are happy and the product itself
becomes better overall because of it. It increases the number of
satisfied users and the product is better because of it.

I agree with you, except on the use of optional features. Even though you
qualified it, I know of several installations that used IBM extensions to
CoBOL, and then had a difficult time switching to a non-IBM platform.
Purportedly there is one installation that after ten years of effort is still not
converted.

It depends on how the optional features work. In the S/380 case they allow a user
to perform some limited tested of 31-bit code problem state code on an OS that is normally 24-bit only.

The idea is that the code IS forward compatible, It is not meant to be a dead end.

Updating VM/370 to run on a machine with 31-bit DAT is a major project as it would, I believe, require the use of SIE and so I guess require re-writing most of CP.

On the other hand, I know what you mean about extensions. The Honeywell Series 200 COBOL had a masked move, implemented as "Move Thru" in Cobol which we used in two ways.
One to store multiple flags in a character, and one to allow months 10, 11 and 12 to be stored as a single "digit"...

When we moved from the H3200 to a L66/10 which had different encodings the conversion team could understand why they couldn't automate the handling of this code,
But as you could tell which sort of "Move Thru" you were doing at any point in the code...

Gerhard Postpischil
Bradford, VT

Dave
G4UGM

------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

[[e-mail] [hercules-390]]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
The only sensible thing to do is to provide
for our users what they have for many years

Yes! Very patient, but still here. :-)

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
a version of Hercules/Hyperion with a USER
SELECTABLE S/38X option (either via build
option or config file option).

Yes, I'm flexible in how the problem
is solved.

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
I for one say let's give them what they clearly want.

Thankyou sir!

BFN. Paul.




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

Hans wrote:

[...]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
And adding new useful features that allow some users
to have a better OS but do not prevent other users to
continue using their unmodified OS could be called
"support your customers".
And these customers are not the Principle-of-Operation
documents, but the people working Hercules.

Precisely. Which is why I for one support the spirit and intent of the S/380 and S/381 effort.

Providing OPTIONAL features is in general a Good Thing. Users wishing to take advantage of said option can do so while those who do not don't have to. Both sets of users are happy and the product itself becomes better overall because of it. It increases the number of satisfied users and the product is better because of it.

Leaving a large segment/subset of users out in the cold for mostly political/personal reasons is almost always *not* a very wise thing to do.

Creating a separate fork of Hyperion as Ivan suggested that contains Hyperion + S/38X *seems* on the face of it to be a proper resolution as it provides those users wanting a S/38X version of Hyperion a place to get it while keeping current Hyperion pure/clean/unpolluted, but in reality it is not a realistic solution.

First, the current maintainers of S/38X are admittedly not as skilled at maintaining/modifying the Hercules codebase as are the maintainers of the Hyperion code base, and their changes (I have not seen them myself) are likely more akin to "hacks" or "kludges" in order to accomplish their goal.

Officially and *properly* integrating their changes into the official Hyperion codebase however would ensure their changes were not only done *correctly* (in such a way as to not impact any of the existing non-S38X architectures) but also in such a manner as to make it easier to maintain overall while at the same time providing them with all the features and benefits that Hyperion has to offer that the current S38X codebase is currently lacking.

Second, doing so (integrating S38X into Hyperion) provides significant benefit for our users as well as it provides "One Stop Shopping" for a version of Hercules with or without S/38X support. There are already two different forks of Hercules (three if you count my own Hercules-ECPS-VSE fork(*)) -- Roger's Spinhawk (3.X series) and Hyperion (4.X series) -- and creating yet another will only confuse and alienate our users even further than they are already.

Having a separate fork also introduces the risk of that fork, not being the "official" version of the product, from not being properly maintained and thus "getting behind" over time, missing certain key fixes and/or enhancements that were made to the official version but not to the forked version. This alone is enough for users to shy away from said fork causing it to die of starvation if you will (from lack of proper "feeding" (maintenance)).

The bottom line is forking a popular, well established and mature product is rarely a Good Thing.

The only sensible thing to do is to provide for our users what they have for many years now quite clearly been patiently pleading us for: a version of Hercules/Hyperion with a USER SELECTABLE S/38X option (either via build option or config file option).

I for one say let's give them what they clearly want.

I vote yes.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com http://www.softdevlabs.com
mail: ***@... mailto:***@...

(*) https://github.com/Fish-Git/Hercules-ECPS-VSE https://github.com/Fish-Git/Hercules-ECPS-VSE