[hercules-390] Possibility of merging in Hercules 380 extensions

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

It would certainly be useful to many users if the Hercules 380 extensions could be folded into the main distribution, perhaps optionally enabled in runtime configuration. These extensions couple with Turnkey MVS MVS/380 extensions which allow 31 bit addressing, a critical feature that allows for a larger variety of programs to be run. This would avoid issues with and headaches for many turnkey users of using the patch to out of date hercules versions. This would be a good idea and of benefit to users.


for more info: MVS/380 - 31-bit MVS - 25 years in the making http://mvs380.sourceforge.net/


http://mvs380.sourceforge.net/

MVS/380 - 31-bit MVS - 25 years in the making http://mvs380.sourceforge.net/ Welcome to OS/380 - the family of freely-available 31-bit mainframe operating systems which currently includes MVS/380, VM/380 and VSE/380 CLIC...



View on mvs380.sourceforge.net http://mvs380.sourceforge.net/
Preview by Yahoo

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

I personally oppose this.

The so called 380 extension breaks each and every S/370 architectural
principles. (It breaks Virtualization, Key protection, Address space
separation, and more S/370 *explicit* mechanism stated in the book of
law (GA22-7000) that I cannot put my finger on at the moment).

If the plan is to run GNU programs - then run them on an Intel processor
running Linux (Or Linux running on hercules in z/Arch mode).

I cannot think of anyone being hercules developers wanting to spend time
maintaining this kludge just to benefit just a few people wanting to run
apache or whatnot under MVS 3.8j

I could be wrong, but it's my view.

--Ivan

On 10/15/2015 7:47 PM, ***@yahoo.com [hercules-390] wrote:
>
>
> It would certainly be useful to many users if the Hercules 380
> extensions could be folded into the main distribution, perhaps
> optionally enabled in runtime configuration. These extensions couple
> with Turnkey MVS MVS/380 extensions which allow 31 bit addressing, a
> critical feature that allows for a larger variety of programs to be
> run. This would avoid issues with and headaches for many turnkey users
> of using the patch to out of date hercules versions. This would be a
> good idea and of benefit to users.
>
>
> for more info: MVS/380 - 31-bit MVS - 25 years in the making
> <http://mvs380.sourceforge.net/>
>
>
>
>
> image <http://mvs380.sourceforge.net/>
>
>
> MVS/380 - 31-bit MVS - 25 years in the making
> <http://mvs380.sourceforge.net/>
> Welcome to OS/380 - the family of freely-available 31-bit mainframe
> operating systems which currently includes MVS/380, VM/380 and VSE/380
> CLIC...
>
> View on mvs380.sourceforge.net <http://mvs380.sourceforge.net/>
>
> Preview by Yahoo
>
>
>
>



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

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

Hence, i mentioned it could be enabled in runtime configuration, rather than by default. Inclusion therefore would not force anything on people. As far as the user base, Turnkey MVS is available to anyone, and so far, MVS/380 is the only way to make it more relevant to modern users, so the potential userbase is far larger. The huge expense of newer commercial only IBM OSs is astronomically higher, so your potential user base is much lower. Do not underestimate the number and potential of hobbyist users for whom Turnkey is the their option and how it might increase interest in the platform for a new generation. As for the 380 design issues, maybe something better will come along or these problems may be fixed but for now its the best we have.

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

The various Principles of Operations manuals are not religious holy
books from which deviations are impossible and punishable by eternal
damnation. IBM's own progression of changes demonstrate that. Why did
IBM do anything different from the S/360? Because of customer needs.

For the same reason, the 380 extensions should be adopted into Hercules
with the appropriate mechanisms making them available only when the user
so elects.

As Hercules frequently goes beyond what is in those manuals, it can do
so in this case. There were all kinds of claims that things would break
when these extensions became available. Experience demonstrates that to
be false. And even if some toleration changes were needed, the versions
of the OS that runs in this environment work just fine.

There are no sound arguments remaining for failure to embrace these
changes short of mere refusal to see they have value and work for
others. Might they need some tweaking to be an option that they don't
have now? Probably. But that should not stop the capability from being
recognized as a desirable feature and worth being embraced.

At a minimum they should be a standard build option eliminating the
whole patch mess when a new release of Hercules is created. And,
Hyperion is the place to start for that.

I personally support the 380 enhancements.

Harold Grovesteen

On Thu, 2015-10-15 at 20:13 +0200, Ivan Warren ***@vmfacility.fr
[hercules-390] wrote:
> I personally oppose this.
>
> The so called 380 extension breaks each and every S/370 architectural
> principles. (It breaks Virtualization, Key protection, Address space
> separation, and more S/370 *explicit* mechanism stated in the book of
> law (GA22-7000) that I cannot put my finger on at the moment).
>
> If the plan is to run GNU programs - then run them on an Intel processor
> running Linux (Or Linux running on hercules in z/Arch mode).
>
> I cannot think of anyone being hercules developers wanting to spend time
> maintaining this kludge just to benefit just a few people wanting to run
> apache or whatnot under MVS 3.8j
>
> I could be wrong, but it's my view.
>
> --Ivan
>
> On 10/15/2015 7:47 PM, ***@yahoo.com [hercules-390] wrote:
> >
> >
> > It would certainly be useful to many users if the Hercules 380
> > extensions could be folded into the main distribution, perhaps
> > optionally enabled in runtime configuration. These extensions couple
> > with Turnkey MVS MVS/380 extensions which allow 31 bit addressing, a
> > critical feature that allows for a larger variety of programs to be
> > run. This would avoid issues with and headaches for many turnkey users
> > of using the patch to out of date hercules versions. This would be a
> > good idea and of benefit to users.
> >
> >
> > for more info: MVS/380 - 31-bit MVS - 25 years in the making
> > <http://mvs380.sourceforge.net/>
> >
> >
> >
> >
> > image <http://mvs380.sourceforge.net/>
> >
> >
> > MVS/380 - 31-bit MVS - 25 years in the making
> > <http://mvs380.sourceforge.net/>
> > Welcome to OS/380 - the family of freely-available 31-bit mainframe
> > operating systems which currently includes MVS/380, VM/380 and VSE/380
> > CLIC...
> >
> > View on mvs380.sourceforge.net <http://mvs380.sourceforge.net/>
> >
> > Preview by Yahoo
> >
> >
> >
> >
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
> Posted by: Ivan Warren <***@vmfacility.fr>
> ------------------------------------
>
> Community email addresses:
> Post message: hercules-***@yahoogroups.com
> Subscribe: hercules-390-***@yahoogroups.com
> Unsubscribe: hercules-390-***@yahoogroups.com
> List owner: hercules-390-***@yahoogroups.com
>
> Files and archives at:
> http://groups.yahoo.com/group/hercules-390
>
> Get the latest version of Hercules from:
> http://www.hercules-390.org
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>

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

In a VM environment 380 is useless in general.

On 10/15/2015 09:28 PM, Harold Grovesteen ***@tx.rr.com
[hercules-390] wrote:
> I personally support the 380 enhancements.

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

Good evening,


do you mean useless or not used?


About 2 years ago, I posted a patch to Hercules as extension to the S/380 architecture as well as to the CP of a VM/370-R6 Sixpack 1.2, allowing several users (virtual machines) to simultaneously use ATL Memory (instead of only one single VM/user).


This extension can be found in the H390-VM files section under the keyword S/381 in Version 1.0.


This thing was widely ignored, which seems to mean it is not used (except myself, although not currently). But it is not useless, as it works.


But may be it is useless in the sense that nobody needs a VM/370 system providing more than one VM having more than 16 MByte of main storage...


Greetings from Berlin
Hans

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

Hello!
Let's make it conditional. Given how the scripts work when the user
runs the configure script, (at least when building the basic Hercules
under Linux) the user can choose to enable or disable them.

I am neither opposed nor for them, but I'm willing to allow someone to
ask questions why a so enabled Hercules is having problems running a
normal VM/370r6 set (Original or Six Pack) or the same person is
struggling with MVS that way,

And yes in those groups. That means I won't insist that the user takes
them to the appropriate group next door.
---
Dave W, what's that strange looking thing doing in your garden?
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."

On Thu, Oct 15, 2015 at 4:45 PM, ***@yahoo.com [hercules-390]
<hercules-***@yahoogroups.com> wrote:
>
>
>
> Good evening,
>
>
> do you mean useless or not used?
>
>
> About 2 years ago, I posted a patch to Hercules as extension to the S/380 architecture as well as to the CP of a VM/370-R6 Sixpack 1.2, allowing several users (virtual machines) to simultaneously use ATL Memory (instead of only one single VM/user).
>
>
> This extension can be found in the H390-VM files section under the keyword S/381 in Version 1.0.
>
>
> This thing was widely ignored, which seems to mean it is not used (except myself, although not currently). But it is not useless, as it works.
>
>
> But may be it is useless in the sense that nobody needs a VM/370 system providing more than one VM having more than 16 MByte of main storage...
>
>
> Greetings from Berlin
>
> Hans
>

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

It needs a vm patch but it allows one VM more store. Isn't this akin to allowing one VM a V+R area...

Dave

> -----Original Message-----
> From: hercules-***@yahoogroups.com [mailto:hercules-
> ***@yahoogroups.com]
> Sent: 15 October 2015 20:33
> To: hercules-***@yahoogroups.com
> Subject: Re: [hercules-390] Possibility of merging in Hercules 380 extensions
>
> In a VM environment 380 is useless in general.
>
> On 10/15/2015 09:28 PM, Harold Grovesteen ***@tx.rr.com
> [hercules-390] wrote:
> > I personally support the 380 enhancements.
>
>
> ------------------------------------
> Posted by: "John P. Hartmann" <***@gmail.com>
> ------------------------------------
>
> 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
>
>
>

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

The first version of MVS/380 only allowed 1 ASID access above 16MB.
The current version allows the partition size to be set and the
2GB-16MB to be split by however many fit.

Also, unless you explicitly request the S/380 mode, you don't have any
of the changes.

On Thu, Oct 15, 2015 at 4:54 PM, 'Dave Wade' ***@gmail.com
[hercules-390] <hercules-***@yahoogroups.com> wrote:
> It needs a vm patch but it allows one VM more store. Isn't this akin to allowing one VM a V+R area...
>
> Dave
>
>> -----Original Message-----
>> From: hercules-***@yahoogroups.com [mailto:hercules-
>> ***@yahoogroups.com]
>> Sent: 15 October 2015 20:33
>> To: hercules-***@yahoogroups.com
>> Subject: Re: [hercules-390] Possibility of merging in Hercules 380 extensions
>>
>> In a VM environment 380 is useless in general.
>>
>> On 10/15/2015 09:28 PM, Harold Grovesteen ***@tx.rr.com
>> [hercules-390] wrote:
>> > I personally support the 380 enhancements.
>>
>>
>> ------------------------------------
>> Posted by: "John P. Hartmann" <***@gmail.com>
>> ------------------------------------
>>
>> 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
>>
>>
>>
>
>
>
> ------------------------------------
> Posted by: "Dave Wade" <***@gmail.com>
> ------------------------------------
>
> 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
>
>
>



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

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

> Also, unless you explicitly request the S/380
> mode, you don't have any of the changes.

That was originally the case, but I believe
I ran into problems with that, so after
some years I just abandoned the S/370
mode and made S/370 do S/380.

BFN. Paul.

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

On 10/15/2015 9:28 PM, Harold Grovesteen ***@tx.rr.com
[hercules-390] wrote:
> As Hercules frequently goes beyond what is in those manuals
Reference please !

--Ivan



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

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

Sorry...

It WILL go beyond (which is not ruled out) but does not go AGAINST what
is in the manual.

the 380 thing DOES break many rules constraints that are explicitly
forbidden.

--Ivan


On 10/15/2015 10:27 PM, Ivan Warren ***@vmfacility.fr [hercules-390] wrote:
>
> On 10/15/2015 9:28 PM, Harold Grovesteen ***@tx.rr.com
> [hercules-390] wrote:
>> As Hercules frequently goes beyond what is in those manuals
> Reference please !
>
> --Ivan
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
> Posted by: Ivan Warren <***@vmfacility.fr>
> ------------------------------------
>
> Community email addresses:
> Post message: hercules-***@yahoogroups.com
> Subscribe: hercules-390-***@yahoogroups.com
> Unsubscribe: hercules-390-***@yahoogroups.com
> List owner: hercules-390-***@yahoogroups.com
>
> Files and archives at:
> http://groups.yahoo.com/group/hercules-390
>
> Get the latest version of Hercules from:
> http://www.hercules-390.org
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>




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

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

On 10/15/2015 4:27 PM, Ivan Warren ***@vmfacility.fr [hercules-390] wrote:
> On 10/15/2015 9:28 PM, Harold Grovesteen ***@tx.rr.com
> [hercules-390] wrote:
>> As Hercules frequently goes beyond what is in those manuals
> Reference please !

Don't know about "frequent", but 370 mode supports BASR and BASR, and
perhaps other things I haven't tried.


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]]

On 10/15/2015 10:39 PM, Gerhard Postpischil ***@charter.net
[hercules-390] wrote:
> As Hercules frequently goes beyond what is in those manuals
>> Reference please !
> Don't know about "frequent", but 370 mode supports BASR and BASR, and
> perhaps other things I haven't tried.
>
>
> Gerhard Postpischil
> Bradford, VT
>
>
S/370 DOES support BASR - It is indicated in GA22-700 (latest version) -
furthermore BASR is NOT prohibited by any other versions of GA22-7000.

Remember :

What is not prohibited is legal. What is strictly forbidden isn't.

The so called "380" architecture is NOT S/370 - It breaks MANY of the
prohibitions set in S/370.

It is a NEW (and convenient architecture). Why not also make hercules an
ARM emulator or POWER emulator. THAT is not the goal of hercules.

--Ivan



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

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

On 10/15/2015 6:55 PM, Ivan Warren ***@vmfacility.fr [hercules-390] wrote:
> S/370 DOES support BASR - It is indicated in GA22-700 (latest version) -
> furthermore BASR is NOT prohibited by any other versions of GA22-7000.

I have a reference card GX20-1850-3, and it does not list BAS or BASR.

> What is not prohibited is legal. What is strictly forbidden isn't.

By that logic I should expect support for SSCH, etc. in S/370, too.
Hercules is insensitive to the processor model specified, which is also
incorrect. E.g., I can specify a processor that didn't have ECPS, but
Hercules will let me use MADS.

> The so called "380" architecture is NOT S/370 - It breaks MANY of the
> prohibitions set in S/370.

That's the whole point. If it didn't, the extensions would be useless.

> It is a NEW (and convenient architecture). Why not also make hercules an
> ARM emulator or POWER emulator. THAT is not the goal of hercules.

The goal of Hercules is to run IBM mainframe software on a PC. The S/380
mods would seem to accomplish that for a specific niche.

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]]

On 10/16/2015 2:25 AM, Gerhard Postpischil ***@charter.net
[hercules-390] wrote:
> On 10/15/2015 6:55 PM, Ivan Warren ***@vmfacility.fr [hercules-390] wrote:
>> S/370 DOES support BASR - It is indicated in GA22-700 (latest version) -
>> furthermore BASR is NOT prohibited by any other versions of GA22-7000.
> I have a reference card GX20-1850-3, and it does not list BAS or BASR.
Because an instruction isn't listed in the architecture guide doesn't
mean that it isn't allowed (it is a model dependent issue)
>
>> What is not prohibited is legal. What is strictly forbidden isn't.
> By that logic I should expect support for SSCH, etc. in S/370, too.
> Hercules is insensitive to the processor model specified, which is also
> incorrect. E.g., I can specify a processor that didn't have ECPS, but
> Hercules will let me use MADS.
There are no such specifications in the S/370 principle of operation
that disallow that. However SSCH DOES break the I/O chapter of S/370
(but is compliant with S/390 and z/Arch)
>> The so called "380" architecture is NOT S/370 - It breaks MANY of the
>> prohibitions set in S/370.
> That's the whole point. If it didn't, the extensions would be useless.
The fork - make a hercules380 project ... But that is NOT hercules
(which is a S/370, S/390 and z/ARCH implementation).
>
>> It is a NEW (and convenient architecture). Why not also make hercules an
>> ARM emulator or POWER emulator. THAT is not the goal of hercules.
> The goal of Hercules is to run IBM mainframe software on a PC. The S/380
> mods would seem to accomplish that for a specific niche.
I cannot find any IBM software that runs on this so called S/380
architecture. It may actually run... But any non privileged program can
now do about anything it wants - cross memory access and such without
supervisor intervention... (the implications are such that my head
hurts) - no more access control.... Let the kids play - no more
security... Let's just make LRA a non privileged instruction while we
are at it... and make a LOAD REAL instruction where any time you can
load someone else storage... YES ! No more adress space separation !
>
> Gerhard Postpischil
> Bradford, VT
>
>
--Ivan



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

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

On 10/16/2015 2:25 AM, Gerhard Postpischil ***@charter.net
[hercules-390] wrote:
> On 10/15/2015 6:55 PM, Ivan Warren ***@vmfacility.fr [hercules-390] wrote:
>> S/370 DOES support BASR - It is indicated in GA22-700 (latest version) -
>> furthermore BASR is NOT prohibited by any other versions of GA22-7000.
>
Note that your reference card *MAY* be outdated. The Bimodal Feature
(which has been available at least on the 4381, 3090, and 9370) offer
the BAS/BASR in S/370 mode. Otherwise VM/SP5, and VMESA(370 mode) CMS
just wouldn't work (it makes HEAVY use of BAS/BASR - because it was the
entry to bimodal CMS... where it would run in both 24 and 31 bit modes).

I can assure you. BAS/BASR are *DOCUMENTED* S/370 instructions. (your
ref card is just outdated).

But then again.. Look closely....

There ARE no place in the manual that says (until z/Arch version 7 I
think) that says that *ANY* opcode would bring an Operation Exception
(PIC 1).. (the newer versions mandate that opcode 00 does mandate a PIC
1 - but that's fairly new - the manual stated that opcode 00 may occur a
PIC 1 - but that it was not guaranteed).

However the "380" architecture breaks MANY of the S/370 rules (PSW bits,
DAT, key, etc...) That is NOT hercules... It's a brand new
architecture.... (which has NO protection mechanism on which who can see
over looks over who and can not only check the other guy's door but can
also steel, change.... 380 has *ONE* single address space over 16M which
can be addressed and accessed by *ALL* (without supervisor intervention)
- or correct me if I'm wrong about this)

So either -

We make "380" a new architecure
- or - (my opinion)
We leave it to that and we leave those going along this path fork
hercules (but then we'll now *THREE* forks... goldhawk... hyperion...
and the 380 kind)

But I can assure you - I am NOT ready to start maintaining this...

(I am more interested in making sure we have a proper I/O subsystem
working - although I haven't done much yet)

--Ivan



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

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

Ivan Warren wrote:

[...]
> But I can assure you - I am NOT ready to
> start maintaining this...

I'm with you on this Ivan.

If someone wants to fork, fine, let them. THEY can maintain S/380.

But to ask we developers to maintain it for them?!

Not just no, but HELL *FUCKING* NO!! >;-)

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

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

> However the "380" architecture breaks MANY
> of the S/370 rules (PSW bits,
> DAT, key, etc...) That is NOT hercules... It's a brand new
> architecture....

Perhaps so. I don't know much about
Fujitsu's MSP (or whatever it was called),
but if that was a bit different from the
3 currently-supported IBM models, would
you object in principle to having MSP
support in Hercules as a separate
architecture?

> (which has NO protection mechanism
> on which who can see
> over looks over who and can not only
> check the other guy's door but can
> also steel, change....

If you are genuinely worried about that,
then only run 24-bit programs. Problem
solved.

> 380 has *ONE* single address space over
> 16M which can be addressed and accessed
> by *ALL* (without supervisor intervention)
> - or correct me if I'm wrong about this)

S/380 has evolved since then. The latest
version implements CR13 as envisioned
by Laddie:

https://groups.yahoo.com/neo/groups/hercules-380/conversations/messages/133

and supported by Greg Price:

https://groups.yahoo.com/neo/groups/hercules-380/conversations/messages/77

If the CR13 flavour was implemented by
mainstream Hercules, that would be a
great step forward.

Currently PDOS/380 makes use of that
CR13 flavour. There was discussion on
making MVS/380 switch to using CR13,
but that hasn't been done yet.

BFN. Paul.

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

> S/380 has evolved since then. The latest
> version implements CR13

I should also add that Jason Winter
produced a flavour of S/380 which
has memory protection.

If you're not willing to put Laddie's
design into base Hercules, but are
willing to put in Jason's version, I
think that would be a step forward,
even if it's not the exact step I
would like to see.

BFN. Paul.

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

>> (which has NO protection mechanism
>> on which who can see
>> over looks over who and can not only
>> check the other guy's door but can
>> also steel, change....

> If you are genuinely worried about that,
> then only run 24-bit programs. Problem
> solved.

One other possibility. If you DESPERATELY
NEED to run a 31-bit program, you can
switch off your router, restart MVS, run
your 31-bit program (note that this is
totally impossible under MVS 3.8j), then
restart MVS, then restart your router.

This gives you the OPTION to do something
that is otherwise IMPOSSIBLE without a
bootleg z/OS.

Obviously if you're running a bootleg z/OS
you don't need this, but that's no reason to
go out of your way to try to prevent
non-bootleggers from running 31-bit
programs on what is 99% likely to be
a single-user system so there's no
need to even switch off the router
to kick the other users off, even
temporarily.

BFN. Paul.

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

> Obviously if you're running a bootleg z/OS
> you don't need this, but that's no reason to
> go out of your way to try to prevent
> non-bootleggers from running 31-bit
> programs

For completeness ...

Obviously if you're running standard
MVS 3.8j and you don't compile large
C programs or have some other reason
to want to run 31-bit programs, you
don't need this, but that's no reason
to go out of your way to try to prevent
large C program programmers from
running 31-bit programs such as the
GCCMVS C compiler.

BFN. Paul.

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

> We leave it to that and we leave those going along this path fork
> hercules (but then we'll now *THREE* forks... goldhawk... hyperion...
> and the 380 kind)

Note that there are more forks than that.

1. S/381
2. Jason Winter
3. Juergen's TCP/IP

Given that most people do not have a
requirement to run 31-bit programs on
a non-bootleg, number 3 is probably
the most useful for non-bootleggers.

BFN. Paul.

[Mick Graley [e-mail] [hercules-390]]

Hi All,

I really don't want to get into the middle of a holy war, and this is
possibly ignorance on my part, but I just don't get why any "normal" users
would want the S/380 stuff. Then again most of my dabbling with Hercules
has been on OS/360 for historical interest! :-)

I can see why Paul would want to have done it in the first place maybe as a
challenge and an academic exercise, but I just don't see the need to be
able to compile large C programs on a historically non-existent
platform/architecture.

If it's purely for C programming then I believe Paul (and everyone else)
has access to many freely available environments that are much better
suited to that purpose.

The FanDeZhi system is available (as long as you behave) if you want to
compile C programs in a z/OS environment. There is also HLASM, COBOL and
PL/I as well as the standard CLIST, REXX and full-blown ISPF Dialog
Manager, so it's a far better mainframe programmers playground, with no
"bootlegging" required!

If it’s for developing and testing GCCMVS and PDPCLIB then I believe the
FanDeZhi system could be used for this also, and I’m guessing you would be
able to compile and link for executing on MVS3.8J if you really wanted to.

So unless I'm missing something really obvious I don’t understand the need
to emulate something that didn't exist, especially when the developers are
obviously not happy with the idea.

Cheers,

Mick.




On 16 October 2015 at 09:38, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> > We leave it to that and we leave those going along this path fork
> > hercules (but then we'll now *THREE* forks... goldhawk... hyperion...
> > and the 380 kind)
>
> Note that there are more forks than that.
>
> 1. S/381
> 2. Jason Winter
> 3. Juergen's TCP/IP
>
> Given that most people do not have a
> requirement to run 31-bit programs on
> a non-bootleg, number 3 is probably
> the most useful for non-bootleggers.
>
> BFN. Paul.
>
>
>



--
Cheers,

Mick.

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

K&R C AKA the Portable C compiler existed on VM and is lost.

GCCMVS allows REXX to be built on VM

So these things existed and are lost.

Dave

From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: 16 October 2015 17:08
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-390] Possibility of merging in Hercules 380 extensions






Hi All,

I really don't want to get into the middle of a holy war, and this is possibly ignorance on my part, but I just don't get why any "normal" users would want the S/380 stuff. Then again most of my dabbling with Hercules has been on OS/360 for historical interest! :-)

I can see why Paul would want to have done it in the first place maybe as a challenge and an academic exercise, but I just don't see the need to be able to compile large C programs on a historically non-existent platform/architecture.

If it's purely for C programming then I believe Paul (and everyone else) has access to many freely available environments that are much better suited to that purpose.

The FanDeZhi system is available (as long as you behave) if you want to compile C programs in a z/OS environment. There is also HLASM, COBOL and PL/I as well as the standard CLIST, REXX and full-blown ISPF Dialog Manager, so it's a far better mainframe programmers playground, with no "bootlegging" required!

If it’s for developing and testing GCCMVS and PDPCLIB then I believe the FanDeZhi system could be used for this also, and I’m guessing you would be able to compile and link for executing on MVS3.8J if you really wanted to.

So unless I'm missing something really obvious I don’t understand the need to emulate something that didn't exist, especially when the developers are obviously not happy with the idea.

Cheers,

Mick.




On 16 October 2015 at 09:38, ***@yahoo.com.au <mailto:***@yahoo.com.au> [hercules-390] <hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> > wrote:

> We leave it to that and we leave those going along this path fork
> hercules (but then we'll now *THREE* forks... goldhawk... hyperion...
> and the 380 kind)

Note that there are more forks than that.

1. S/381
2. Jason Winter
3. Juergen's TCP/IP

Given that most people do not have a
requirement to run 31-bit programs on
a non-bootleg, number 3 is probably
the most useful for non-bootleggers.

BFN. Paul.




--
Cheers,

Mick.

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

Let me re-iterate my position. Partly, a larger address space relieves memory issues. This makes it more of an interest even to home/hobbyist users who may be interested in developing and working with Turnkey. Secondly, the ability to compile C programs serves many purposes. It allows for a bridge for Unix users to ease into the system by having access to some familiar tools as they learn the native tools, and maybe some bridging of the two. Some people are interested in Turnkey MVS as hobbyist and for learning the development environment. I dont see how it hurts anything to have GCCMVS readily available or how it hurts anything to include the 380 extension in the main tree.

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

> I can see why Paul would want to have done
> it in the first place maybe as a challenge and
> an academic exercise,

It was never an academic exercise. Note
that GCC work was being done way back
around 2004. I did not have direct access
to a z/OS system, so I was unable to
natively build all of GCC.

> but I just don't see
> the need to be able to compile large C
> programs on a historically non-existent platform/architecture.

What choice did I have back in 2004?
How could I develop z/OS software
without direct access to z/OS?

> If it's purely for C programming then I
> believe Paul (and everyone else) has
> access to many freely available
> environments that are much better
> suited to that purpose.

Not that exercise MVS functionality such
as opening members of a PDS
concatenation.

> The FanDeZhi system is available (as long
> as you behave) if you want to compile C
> programs in a z/OS environment.

When did this become available?

Also note that I do my GCCMVS builds
completely automated. At the Windows
prompt I just type "allmvs" and then
come back in a couple of hours to see
what happened.

Also, it is my desire that MVS/380 be
able to be used as a commercial
platform. I don't think a company
would be willing to run their business
on FanDeZhi with the potential for
access to be denied at any time.

> There is also HLASM, COBOL and PL/I
> as well as the standard CLIST, REXX and
> full-blown ISPF Dialog Manager, so it's
> a far better mainframe programmers
> playground, with no "bootlegging" required!

Well, some people may like a playground
they can IPL themselves etc.

> If it’s for developing and testing GCCMVS
> and PDPCLIB then I believe the FanDeZhi
> system could be used for this also,

Certainly it is great to have access to a
z/OS system. Normally I need to ask
someone else to try things for me.

> and I’m guessing you would be able to
> compile and link for executing on
> MVS3.8J if you really wanted to.

I'm not sure you can take z/OS load
modules and run them on MVS 3.8j.
However, the reverse is possible. I
can and do produce modules on
MVS/380 and they run fine on both
MVS 3.8j and z/OS.

BFN. Paul.

[Mick Graley [e-mail] [hercules-390]]

Hi Paul,

I've made a few more comments below.



On 16 October 2015 at 22:37, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> > I can see why Paul would want to have done
> > it in the first place maybe as a challenge and
> > an academic exercise,
>
> It was never an academic exercise. Note
> that GCC work was being done way back
> around 2004. I did not have direct access
> to a z/OS system, so I was unable to
> natively build all of GCC.
>
> > but I just don't see
> > the need to be able to compile large C
> > programs on a historically non-existent platform/architecture.
>
> What choice did I have back in 2004?
> How could I develop z/OS software
> without direct access to z/OS?
>
Not really sure why you would want to develop software for z/OS if you
haven't got z/OS to run it on.
MVS/380 will always be missing lots of z/OS sub-systems and facilities.

>
> > If it's purely for C programming then I
> > believe Paul (and everyone else) has
> > access to many freely available
> > environments that are much better
> > suited to that purpose.
>
> Not that exercise MVS functionality such
> as opening members of a PDS
> concatenation.
>
Agreed - that's MVS functionality not z/OS functionality, in fact it goes
back to OS/360.
PDS/Es are a different beast altogether though.

>
> > The FanDeZhi system is available (as long
> > as you behave) if you want to compile C
> > programs in a z/OS environment.
>
> When did this become available?
>
Don't know - been around at least a few years though.

>
> Also note that I do my GCCMVS builds
> completely automated. At the Windows
> prompt I just type "allmvs" and then
> come back in a couple of hours to see
> what happened.
>
I don't think you could run your automated GCCMVS build system the same way
as you do now on MVS/380 though as I guess there is no equivalent access to
a card reader.
However, you could probably just submit the jobs from ISPF or automate it
using REXX.

>
> Also, it is my desire that MVS/380 be
> able to be used as a commercial
> platform. I don't think a company
> would be willing to run their business
> on FanDeZhi with the potential for
> access to be denied at any time.
>
I'm not sure there would be many takers for running a production workload
on MVS/380.

>
> > There is also HLASM, COBOL and PL/I
> > as well as the standard CLIST, REXX and
> > full-blown ISPF Dialog Manager, so it's
> > a far better mainframe programmers
> > playground, with no "bootlegging" required!
>
> Well, some people may like a playground
> they can IPL themselves etc.
>
I agree that having your own system is a better playground, as you can do
what you want when you want.
It's nice to be able to play Sysprog!
But the FanDeZhi system is the closest thing to a free z/OS bureau service
that I know of.

>
> > If it’s for developing and testing GCCMVS
> > and PDPCLIB then I believe the FanDeZhi
> > system could be used for this also,
>
> Certainly it is great to have access to a
> z/OS system. Normally I need to ask
> someone else to try things for me.
>
It would definitely be useful for your testing and you may even find it
useful as a development environment.

>
> > and I’m guessing you would be able to
> > compile and link for executing on
> > MVS3.8J if you really wanted to.
>
> I'm not sure you can take z/OS load
> modules and run them on MVS 3.8j.
> However, the reverse is possible. I
> can and do produce modules on
> MVS/380 and they run fine on both
> MVS 3.8j and z/OS.
>
The question about the load modules is interesting.
If the load library on z/OS is a PDS rather than a PDS/E and the block size
is MVS3.8J "friendly" and the only other routines that are linked in are
from PDPCLIB (no language environment etc) then I wonder if they would load
OK on MVS3.8J?
I guess it would be dependent on the non-text records in the load module
being in a format that MVS3.8J understands.
Anyone know for sure? I don't have MVS3.8J or GCCMVS/PDPCLIB on z/OS to
test this.

>
> BFN. Paul.
>
>
Cheers,

Mick.

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

> What choice did I have back in 2004?
> How could I develop z/OS software
> without direct access to z/OS?

> Not really sure why you would want to
> develop software for z/OS if you haven't
> got z/OS to run it on.

Lots of people write software for platforms
they don't personally run. The idea is to
write software for as many platforms as
possible, so that your code is used to
the maximum extent possible.

In particular, it really really irked me that
some MVS shops didn't have a C
compiler at all, and people (especially
me!) were forced to write in alternative
languages. So I did the necessary work
to produce a free C compiler for MVS.

I also provided other great tools like
DIFF3 (three-way diff, one of the great
advances in computer science).

> MVS/380 will always be missing lots of
> z/OS sub-systems and facilities.

Sure. But I never found any need to
use those, instead of sticking to the
MVS 3.8j API, which was used in
production just fine for many years.

>> Also, it is my desire that MVS/380 be
>> able to be used as a commercial
>> platform. I don't think a company
>> would be willing to run their business
>> on FanDeZhi with the potential for
>> access to be denied at any time.

> I'm not sure there would be many takers
> for running a production workload on MVS/380.

That certainly appears to be the case so
far with MVS/380. I bet it is also the
case for FanDeZhi too. Regardless, I
continue my efforts to make MVS/380
a more and more viable platform as
time progresses.

> But the FanDeZhi system is the closest
> thing to a free z/OS bureau service that
> I know of.

Unless they decide to kick you off without
warning when they have no legal
requirement to provide you with the
service!

BFN. Paul.

[Maarten Hoes [e-mail] [hercules-390]]

<random-thought>

1.) Cant we all just get along ?

2.)
Let the s360/s370/z-Architecture developers worry about their bits
Let the s380 developers worry about their bits

3.) ?????

4.) PROFIT !!!

</random-thought>

[Mick Graley [e-mail] [hercules-390]]

On 20 October 2015 at 22:32, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> > What choice did I have back in 2004?
> > How could I develop z/OS software
> > without direct access to z/OS?
>
> > Not really sure why you would want to
> > develop software for z/OS if you haven't
> > got z/OS to run it on.
>
> Lots of people write software for platforms
> they don't personally run. The idea is to
> write software for as many platforms as
> possible, so that your code is used to
> the maximum extent possible.
>
> In particular, it really really irked me that
> some MVS shops didn't have a C
> compiler at all, and people (especially
> me!) were forced to write in alternative
> languages. So I did the necessary work
> to produce a free C compiler for MVS.
>
> And I salute you for that. My workplace is a "COBOL shop" so I've never
had access to PL/I or C on a mainframe system at work. I've been meaning to
have a dabble with the GCCMVS stuff for a while.

I also provided other great tools like
> DIFF3 (three-way diff, one of the great
> advances in computer science).
>
Again, that's a great achievement.
I like the GNU and UNIX tools.
Not sure how well they fit on z/OS but I'm willing to be shown the light :-)


> > MVS/380 will always be missing lots of
> > z/OS sub-systems and facilities.
>
> Sure. But I never found any need to
> use those, instead of sticking to the
> MVS 3.8j API, which was used in
> production just fine for many years.
>
> Fair enough. I suppose that was one of the selling points of the mainframe
in the first place.
Just wonder though whether or not the code produced by GCCMVS will work
against PDS/Es etc.
Think I'm talking myself into some testing here!

>> Also, it is my desire that MVS/380 be
> >> able to be used as a commercial
> >> platform. I don't think a company
> >> would be willing to run their business
> >> on FanDeZhi with the potential for
> >> access to be denied at any time.
>
> > I'm not sure there would be many takers
> > for running a production workload on MVS/380.
>
> That certainly appears to be the case so
> far with MVS/380. I bet it is also the
> case for FanDeZhi too. Regardless, I
> continue my efforts to make MVS/380
> a more and more viable platform as
> time progresses.
>
> > But the FanDeZhi system is the closest
> > thing to a free z/OS bureau service that
> > I know of.
>
> Unless they decide to kick you off without
> warning when they have no legal
> requirement to provide you with the
> service!
>
> Yes I can see that would be a worry for any "real" work.
Also the fact that it could just disappear at any time without warning.
But it could be useful for your GCCMVS testing until that happens.


> BFN. Paul.
>
I can see your need for S/380 now, but I still agree with the developers
from the point of view of the Hercules project. I think you should fork a
new project if that is easy enough to keep in step with the main Hercules
code base. That way the developers don't have to worry about any of the
S/380 mods breaking the other architectures and should hopefully keep
everyone who wants to run in S/380 mode happy also.

Cheers,

Mick.

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

>> In particular, it really really irked me that
>> some MVS shops didn't have a C
>> compiler at all, and people (especially
>> me!) were forced to write in alternative
>> languages. So I did the necessary work
>> to produce a free C compiler for MVS.

> And I salute you for that. My workplace

Thanks.

> is a "COBOL shop" so I've never had
> access to PL/I or C on a mainframe
> system at work. I've been meaning to
> have a dabble with the GCCMVS stuff
> for a while.

That's what decades of effort was
done for!

>> I also provided other great tools like
>> DIFF3 (three-way diff, one of the great
>> advances in computer science).

> Again, that's a great achievement.
> I like the GNU and UNIX tools.
> Not sure how well they fit on z/OS but I'm willing to be shown the light :-)

The concept of a 3-way diff is completely
independent of platform.

Regardless of whether you are on Unix
or z/OS, if two people independently
make changes to a common file, then
3-way diffs will automatically sort out
what is otherwise a mess.

And you can't get diff3 on z/OS without
GCCMVS. :-) Sort of, anyway.

>>> MVS/380 will always be missing lots of
>>> z/OS sub-systems and facilities.

>> Sure. But I never found any need to
>> use those, instead of sticking to the
>> MVS 3.8j API, which was used in
>> production just fine for many years.

> Fair enough. I suppose that was one of the selling points of the mainframe in the first place.

> Just wonder though whether or not the code produced by GCCMVS will work against PDS/Es etc.

> Think I'm talking myself into some testing here!

I am not aware of what new APIs are
involved in PDS/Es. I would guess
that the standard OPEN macro which
works on sequential files and PDS
members will also work on PDS/Es.

But yes, it would be good if you could
test that personally.

> But it could be useful for your GCCMVS
> testing until that happens.

Yes, I will keep it in mind. I rarely ask
for a z/OS test though. If MVS/380
runs my 31-bit program, then it
almost certainly works fine on z/OS
too.

> I can see your need for S/380 now,

Ok, cool.

> but I still agree with the developers from
> the point of view of the Hercules project.
> I think you should fork a new project if

Hercules/380 is *already* a fork, and
stuck at 3.07 because no-one has
volunteered to merge the changes
in either direction.

> that is easy enough to keep in step with
> the main Hercules code base.

It is not easy. Are you volunteering
to do this non-trivial task?

> That way the developers don't have to
> worry about any of the S/380 mods
> breaking the other architectures

They only need to put a #ifdef S380
around any code and that won't be
a problem.

> and should hopefully keep everyone
> who wants to run in S/380 mode happy also.

People are unhappy about Hercules/380
being old. No-one has volunteered to
make it new, which is presumably why
the OP asked the question.

BFN. Paul.

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

> Hercules/380 is *already* a fork, and
> stuck at 3.07 because no-one has
> volunteered to merge the changes
> in either direction.

And I am actually more interested in
having Juergen's changes merged
into Hercules/380 than either of the
3.11 or 4.0 forks.

I don't know what changes there have
been in 3.11 or 4.0, but I do know that
I have no particular need for them.

Whereas I do know what Juergen
(and Jason Winter) have done, and
would like to see MVS/380 supporting
TCP/IP the same way TK4- does.

But no-one has volunteered to do
that work either.

BFN. Paul.

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

> I tried to get a number of people elsewhere
> interested in porting a recent compiler onto
> the IBM architecture, but found it very much
> an uphill struggle: there were too many
> differences in culture and expectations.

Can you elaborate on the different "cultures"
and "expectations" you witnessed?

One thing that really annoyed me was the
GCC maintainers said they were *keen*
to *delete* the i370 target from GCC 4.0.

Unix programmers are a bunch of asshats.
The correct attitude to have with regards
to GCC should have been: we would be
*devastated* at having to remove the i370
target, is there anything we can do to
keep the port alive?

BFN. Paul.

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

> However the most interesting thing was
> that the compiler was written
> with heavy use of OO (Object Oriented)
> techniques, and in a lot of
> places the type of an object hence what
> methods it embeds is not known
> until run-time (e.g. when the nodes of
> a tree are defined as being
> opcode instances, with /which/ opcode
> being unknown until the compiler
> is running). Then somebody "old school"
> came along, and was terminally
> unhappy that he couldn't get a static
> cross-reference of procedure calls.

Ok, that's all above my head.

> I could point you at ML archives etc. if you were interested.

Yes, please provide a link. I'm very
interested in C code migrating from
non-mainframe to mainframe.

> But OTOH if they see it as obsolete and

That's the problem. They are calling
the wonderful MVS environment
"obsolete" without justification.

I wasn't even able to call DOS/VSE
obsolete as there are still people
insisting on running production work
on it, so I had no choice but to port
GCC to VSE to make C a universal
language. I had hoped it would just
die instead. But no, it was me that
needed to adjust.

> are confident that everybody's
> needs can be satisfied by v3,
> which in principle can still be built for

The problem is that there are bugs
in 3.4.6 which I can't fix myself.
These products are not supported,
even by the definition of "support"
is being used by GNU clowns.

> most distreaux... it's really all down
> to how many people from the 370
> community are prepared to engage
> with the GCC developers and find some
> mutually-beneficial modus operandi.

Ok, I guess that's true. I have a limit
of how much (near zero) I am interested
in maintaining a Gnu Virus Licence
product, and they have a limit of how
much (near zero) they are willing to
support an environment they have no
personal use for.

When I completed the GCC port and
had an MVS version of GCC alive, I
had hoped that there would be an
influx of z/OS-only programmers
willing to work on fixing bugs or
making improvements in GCCMVS.

That never eventuated, although
there were a number of hobbyists
who made invaluable contributions,
like Dave Wade and Phil Roberts.

> the only readily-available choice is
> OpenSXCE (a variant of Solaris
> 11), and the maintainer of that has
> made himself extremely unpopular due
> to his outspoken Russian nationalism.

Ah, the internet at its best. Instead of
getting software from a commercial
vendor like IBM that actually cares
about their product, we are instead
faced with negotiating with nutcases
on the internet.

BTW, I'm not claiming to not be an
internet nutcase either. I know I'm
not a professional vendor. Which is
why I write code with an expectation
that a commercial vendor will pick
it up and turn it into a properly
supported product one day when I
get the code near enough for that
to be commercially viable. That has
indeed happened with a couple of
my products.

BFN. Paul.

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

> That never eventuated, although
> there were a number of hobbyists
> who made invaluable contributions,
> like Dave Wade and Phil Roberts.

And in case I get my head bitten
off - Gerhard has made enormous
advances in the MVS assembler
portion of PDPCLIB which is
used/needed by GCC.

And there have been more
contributions than that too.
Not just coding but e.g. testing
on z/OS.

BFN. Paul.

[Maarten Hoes [e-mail] [hercules-390]]

Alright, thats enough name calling and bashing for one thread, right ?
;)
(GNU clowns, Gnu Virus Licence, asshat Unix programmers, etc.)


Anyway, in an attempt to keep things more productive : I havent yet seen
anyone refer to the LLVM/clang compiler, which I hear is a fine replacement
for (and by some even seen as a better product as) GCC ?

http://www.llvm.org/
http://clang.llvm.org/


I mean, once the the point has been reached that a porting effort has to
essentially start over, why not choose an alternative to port ?



Anyway, just my 2$, Im going to crawl back under my rock now.
;)



- Maarten.

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

On 23 October 2015 at 08:26, Maarten Hoes ***@gmail.com
[hercules-390] wrote:

> Anyway, in an attempt to keep things more productive : I havent yet seen
> anyone refer to the LLVM/clang compiler, which I hear is a fine
> replacement for (and by some even seen as a better product as) GCC ?
>
> http://www.llvm.org/
> http://clang.llvm.org/
>

I did, back on 10 July 2015. And the reply was interesting:

===============================
Subject: OT: LLVM back end for zArch?
On 10 July 2015 at 17:08, Dan Horák ***@danny.cz wrote:
>On Fri, 10 Jul 2015 13:39:25 -0400 Tony Harminc ***@gmail.com wrote:

>> Is there one? It's a hard topic to Google, because LLVM supports the
>> GCC parsers, and GCC supports zArch, so there are zillions of false
>>positives.
>>
>> Suggestions on where to look? Also interested in older S/370
>> architectures, of course.

> there is native zArch backend in llvm for some time (since llvm 3.3),
supports z10 or newer HW, see
> http://llvm.org/releases/3.3/docs/ReleaseNotes.html#systemz-s390x-backend

===============================

But note that this is all about zArch, and not the earlier S/370 style
architectures. Also note that IBM contributed the zArch ("s390x") backend.

Tony H.

[Maarten Hoes [e-mail] [hercules-390]]

Hi,


On Fri, Oct 23, 2015 at 10:36 PM, Tony Harminc ***@gmail.com
[hercules-390] <hercules-***@yahoogroups.com> wrote:
>
>
>
> On 23 October 2015 at 08:26, Maarten Hoes ***@gmail.com
[hercules-390] wrote:
>>
>> Anyway, in an attempt to keep things more productive : I havent yet seen
anyone refer to the LLVM/clang compiler, which I hear is a fine replacement
for (and by some even seen as a better product as) GCC ?
>>
>> http://www.llvm.org/
>> http://clang.llvm.org/
>
>
> I did, back on 10 July 2015. And the reply was interesting:
>

< - snip - >

>
> But note that this is all about zArch, and not the earlier S/370 style
architectures. Also note that IBM contributed the zArch ("s390x") backend.
>
> Tony H.
>

Yes, that does indeed look interesting, even if it's 'just' the
z/Architecture. Does still seem to be around though, and maintained:

http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html#changes-to-the-systemz-target

Well then this does indeed seem like a good (? better ?) candidate for
porting than GCC.


Thanks for the info and the links,


- Maarten

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

> Yes, that does indeed look interesting, even
> if it's 'just' the z/Architecture. Does still seem
> to be around though, and maintained:

The S390 port of GCC is also around and
maintained.

> Well then this does indeed seem like a good
> (? better ?) candidate for porting than GCC.

Why would you consider it to be better
than GCC's S370 port, given that you
are using an S370 machine, not S390?

Add to that the fact that GCC is *already*
ported to MVS 3.8j.

BFN. Paul.

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

It seems as though a desirable goal of the whole thing would be to expand the address space for Turnkey MVS to use, whether this is done through MVS/380 or what have you. One desirable benefit of that is to be able to run more native language MVS programs in parallel and to run larger native language programs. In addition to that, GCC is an another benefit. This would increase the versatility for many hobbyist users. Since 31 and 64 bit CPU extensions already exist, what was the rationale for creating Hercules//380 fork rather than just added some backwards compatable extensions to Turnkey MVS to support the existing 31 and 64 bit IBM extensions?

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

On 10/24/2015 3:15 PM, ***@yahoo.com [hercules-390] wrote:
> It seems as though a desirable goal of the whole thing would be to
> expand the address space for Turnkey MVS to use, whether this is done
> through MVS/380 or what have you. One desirable benefit of that is to be
> able to run more native language MVS programs in parallel and to run
> larger native language programs. In addition to that, GCC is an another
> benefit. This would increase the versatility for many hobbyist users.
> Since 31 and 64 bit CPU extensions already exist, what was the rationale
> for creating Hercules//380 fork rather than just added some backwards
> compatable extensions to Turnkey MVS to support the existing 31 and 64
> bit IBM extensions?

I agree that it would be desirable, but the problem is that the 380
extensions are "unclean" - added instructions are trivial, but the
31-bit memory extension is implemented as V=R. Virtual memory in 31-bit
systems is handled differently (compare option bits and control register
use), and would require significant changes to MVS and other systems.

Also the current MVS doesn't support ESPIE, so SPIE exits don't see the
AMODE 31 bit; SVC 51 doesn't dump 31-bit memory; etc. At this time
nobody seems to be interested in doing the non-Hercules changes either.

Gerhard Postpischil
Bradford, VT

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

On 10/25/2015 1:21 AM, Gerhard Postpischil ***@charter.net
[hercules-390] wrote:
> On 10/24/2015 3:15 PM, ***@yahoo.com [hercules-390] wrote:
>> It seems as though a desirable goal of the whole thing would be to
>> expand the address space for Turnkey MVS to use, whether this is done
>> through MVS/380 or what have you. One desirable benefit of that is to be
>> able to run more native language MVS programs in parallel and to run
>> larger native language programs. In addition to that, GCC is an another
>> benefit. This would increase the versatility for many hobbyist users.
>> Since 31 and 64 bit CPU extensions already exist, what was the rationale
>> for creating Hercules//380 fork rather than just added some backwards
>> compatable extensions to Turnkey MVS to support the existing 31 and 64
>> bit IBM extensions?
> I agree that it would be desirable, but the problem is that the 380
> extensions are "unclean" - added instructions are trivial, but the
> 31-bit memory extension is implemented as V=R. Virtual memory in 31-bit
> systems is handled differently (compare option bits and control register
> use), and would require significant changes to MVS and other systems.
>
> Also the current MVS doesn't support ESPIE, so SPIE exits don't see the
> AMODE 31 bit; SVC 51 doesn't dump 31-bit memory; etc. At this time
> nobody seems to be interested in doing the non-Hercules changes either.
>
> Gerhard Postpischil
> Bradford, VT
>
>
To me this S/380 thing is just yet another architecture. Completely
unsafe, a kludge.... (it breaks about every rule set in the S/370
principle of operations).

I see no point in making this part of hercules. If you want to compile
programs using GCC to run on MVS 3.8j, use a cross compiler.

The point of hercules is being an S/370, ESA and z/Arch implementation -
not to implement some new (and flawed) architecture.

I understand the idea - it's just that I *DO NOT* support the principles.

Why don't people with access and knowledge to/of MVS 3.8j source code
turn it into a, XA/ESA system ? THAT would be a true advance.

--Ivan



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

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

Hello!
Now that I'll support. But only if it later becomes possible to turn
VM/370rel6 into VM/ESA.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."


On Sat, Oct 24, 2015 at 7:32 PM, Ivan Warren ***@vmfacility.fr
[hercules-390] <hercules-***@yahoogroups.com> wrote:
>
>
> On 10/25/2015 1:21 AM, Gerhard Postpischil ***@charter.net
> [hercules-390] wrote:
>> On 10/24/2015 3:15 PM, ***@yahoo.com [hercules-390] wrote:
>>> It seems as though a desirable goal of the whole thing would be to
>>> expand the address space for Turnkey MVS to use, whether this is done
>>> through MVS/380 or what have you. One desirable benefit of that is to be
>>> able to run more native language MVS programs in parallel and to run
>>> larger native language programs. In addition to that, GCC is an another
>>> benefit. This would increase the versatility for many hobbyist users.
>>> Since 31 and 64 bit CPU extensions already exist, what was the rationale
>>> for creating Hercules//380 fork rather than just added some backwards
>>> compatable extensions to Turnkey MVS to support the existing 31 and 64
>>> bit IBM extensions?
>> I agree that it would be desirable, but the problem is that the 380
>> extensions are "unclean" - added instructions are trivial, but the
>> 31-bit memory extension is implemented as V=R. Virtual memory in 31-bit
>> systems is handled differently (compare option bits and control register
>> use), and would require significant changes to MVS and other systems.
>>
>> Also the current MVS doesn't support ESPIE, so SPIE exits don't see the
>> AMODE 31 bit; SVC 51 doesn't dump 31-bit memory; etc. At this time
>> nobody seems to be interested in doing the non-Hercules changes either.
>>
>> Gerhard Postpischil
>> Bradford, VT
>>
>>
> To me this S/380 thing is just yet another architecture. Completely
> unsafe, a kludge.... (it breaks about every rule set in the S/370
> principle of operations).
>
> I see no point in making this part of hercules. If you want to compile
> programs using GCC to run on MVS 3.8j, use a cross compiler.
>
> The point of hercules is being an S/370, ESA and z/Arch implementation -
> not to implement some new (and flawed) architecture.
>
> I understand the idea - it's just that I *DO NOT* support the principles.
>
> Why don't people with access and knowledge to/of MVS 3.8j source code
> turn it into a, XA/ESA system ? THAT would be a true advance.
>
> --Ivan
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
> Posted by: Ivan Warren <***@vmfacility.fr>
> ------------------------------------
>
> Community email addresses:
> Post message: hercules-***@yahoogroups.com
> Subscribe: hercules-390-***@yahoogroups.com
> Unsubscribe: hercules-390-***@yahoogroups.com
> List owner: hercules-390-***@yahoogroups.com
>
> Files and archives at:
> http://groups.yahoo.com/group/hercules-390
>
> Get the latest version of Hercules from:
> http://www.hercules-390.org
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>

['Shelby Beach' [e-mail] [hercules-390]]

Well of course both are possible... IBM did it !!! Now then, we've got the
source. Maybe there should be more douin' and less complainin' :-) !

Shelby



________________________________

From: hercules-***@yahoogroups.com
[mailto:hercules-***@yahoogroups.com]
Sent: Saturday, October 24, 2015 4:37 PM
To: hercules-390 hercules
Subject: Re: [hercules-390] Possibility of merging in Hercules 380
extensions




Hello!
Now that I'll support. But only if it later becomes possible to turn
VM/370rel6 into VM/ESA.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."

On Sat, Oct 24, 2015 at 7:32 PM, Ivan Warren ***@vmfacility.fr
[hercules-390] <hercules-***@yahoogroups.com> wrote:
>
>
> On 10/25/2015 1:21 AM, Gerhard Postpischil ***@charter.net
> [hercules-390] wrote:
>> On 10/24/2015 3:15 PM, ***@yahoo.com [hercules-390]
wrote:
>>> It seems as though a desirable goal of the whole thing would be
to
>>> expand the address space for Turnkey MVS to use, whether this is
done
>>> through MVS/380 or what have you. One desirable benefit of that
is to be
>>> able to run more native language MVS programs in parallel and to
run
>>> larger native language programs. In addition to that, GCC is an
another
>>> benefit. This would increase the versatility for many hobbyist
users.
>>> Since 31 and 64 bit CPU extensions already exist, what was the
rationale
>>> for creating Hercules//380 fork rather than just added some
backwards
>>> compatable extensions to Turnkey MVS to support the existing 31
and 64
>>> bit IBM extensions?
>> I agree that it would be desirable, but the problem is that the
380
>> extensions are "unclean" - added instructions are trivial, but
the
>> 31-bit memory extension is implemented as V=R. Virtual memory in
31-bit
>> systems is handled differently (compare option bits and control
register
>> use), and would require significant changes to MVS and other
systems.
>>
>> Also the current MVS doesn't support ESPIE, so SPIE exits don't
see the
>> AMODE 31 bit; SVC 51 doesn't dump 31-bit memory; etc. At this
time
>> nobody seems to be interested in doing the non-Hercules changes
either.
>>
>> Gerhard Postpischil
>> Bradford, VT
>>
>>
> To me this S/380 thing is just yet another architecture.
Completely
> unsafe, a kludge.... (it breaks about every rule set in the S/370
> principle of operations).
>
> I see no point in making this part of hercules. If you want to
compile
> programs using GCC to run on MVS 3.8j, use a cross compiler.
>
> The point of hercules is being an S/370, ESA and z/Arch
implementation -
> not to implement some new (and flawed) architecture.
>
> I understand the idea - it's just that I *DO NOT* support the
principles.
>
> Why don't people with access and knowledge to/of MVS 3.8j source
code
> turn it into a, XA/ESA system ? THAT would be a true advance.
>
> --Ivan
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
> Posted by: Ivan Warren <***@vmfacility.fr>
> ------------------------------------
>
> Community email addresses:
> Post message: hercules-***@yahoogroups.com
> Subscribe: hercules-390-***@yahoogroups.com
> Unsubscribe: hercules-390-***@yahoogroups.com
> List owner: hercules-390-***@yahoogroups.com
>
> Files and archives at:
> http://groups.yahoo.com/group/hercules-390
>
> Get the latest version of Hercules from:
> http://www.hercules-390.org
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>

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

Hi Shelby
>
> Maybe there should be more douin' and less complainin' :-) !
>
Right you are!


That's why I just _did_ a pure fun thing (publishing an executable version of Madnick/Donovan's Sample Operating System), with absolutely no real use case in mind .


Well, I know, quite a few people would rather like to see me publish TK4- Update 08... but I still don't have the time to go after this (it's definitely more work and less fun that getting a "new" operating system to IPL).


Cheers
JÃŒrgen




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

Well of course both are possible... IBM did it !!! Now then, we've got the
source. Maybe there should be more douin' and less complainin' :-) !

Shelby

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

> Since 31 and 64 bit CPU extensions already
> exist, what was the rationale for creating
> Hercules//380 fork rather than just added
> some backwards compatable extensions
> to Turnkey MVS to support the existing
> 31 and 64 bit IBM extensions?

It took me a while to understand what
you meant here. I think I have it now.

The "31 and 64 bit extensions" that
you are referring to are in fact brand
new architectures which MVS 3.8j
cannot run on. Even if MVS 3.8j
could run on the newer architectures,
it would still only run as 24-bit. All
the page tables it defines are 24-bit.
It knows nothing at all about the
31-bit extensions.

Changing MVS 3.8j to support the
new architectures is a major job.
Possibly even an impossible job,
especially when you consider that
we don't have the correct PL/S
source code, in fact, we don't have
the PL/S source code at all, and
even if we did, we don't have the
PL/S compiler anyway.

I guess it's not impossible, because
Fujitsu appears to have somehow
done it. Not sure how many
man-years of effort it took them.

Regardless, whether this mammoth
task is done or not, it is really only
interesting as far as being able to
run 31-bit (or 64-bit) programs.
And so far (and for many years)
there is only one such program
available - GCC.

And that one program - GCC -
works fine on MVS/380 (running
under Hercules/380) and does
not need the mammoth effort
above to be done.

Instead of doing that massive
effort, there are in fact relatively
small things that could be done
to MVS instead. Such as making
IEWL allow more than 16 aliases
and making IEWFETCH honor
the AM31 bit. So far no-one has
come forward to do even minor
changes like that, nevermind
massive changes. Well, Laddie
did indeed come forward to do
the massive changes, but as
he acknowledges, the changes,
as mentioned before, are
massive. So we're looking at
years or decades for the work
to be done.

Meanwhile, 31-bit GCC is running
JUST FINE on my system, as it
has been FOR MANY YEARS.

And that is the bottom line.

BFN. Paul.




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

It seems as though a desirable goal of the whole thing would be to expand the address space for Turnkey MVS to use, whether this is done through MVS/380 or what have you. One desirable benefit of that is to be able to run more native language MVS programs in parallel and to run larger native language programs. In addition to that, GCC is an another benefit. This would increase the versatility for many hobbyist users. Since 31 and 64 bit CPU extensions already exist, what was the rationale for creating Hercules//380 fork rather than just added some backwards compatable extensions to Turnkey MVS to support the existing 31 and 64 bit IBM extensions?

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

On 10/23/2015 11:31 PM, Mark Morgan Lloyd
markmll.hercules-***@telemetry.co.uk [hercules-390] wrote:
> Tony Harminc ***@gmail.com [hercules-390] wrote:
>
>> architectures. Also note that IBM contributed the zArch ("s390x") backend.
> I know that a lot of you guys have been knocking around the industry
> longer than I have, and have lived with whatever preceded punched cards
> and paper tape.
>
> What I've seen over the years is that code generators that target
> multiple architectures are rarely successful, and code generators that
> are good with multiple frontend languages are even less so.
>
> And I've seen suggestion that LLVM might possibly be excessively
> specialised towards C++ and its close relatives, to the detriment of-
> e.g.- languages with more flexible scoping rules.
>
> Now in practical terms, the C/C++ family of languages have pretty much
> swept all before them: they're not my preferred tools, so please don't
> kick me for saying so. But if the industry leans heavily towards LLVM,
> we might find that any non-standard language has first to be translated
> to C++ with a whole lot of name mnagling before it can be compiled to
> machinecode.
>
> So while it's undoubtedly got its good points, I'm a little wary lest
> LLVM turns out to be a retrograde step.
>
I'm a bit surprised here. Both LLVM and GCC use an intermediate language
to enable optimization : They all turn the "compiled" language into
something that is "universal" (in the point of view of the backend) -
that is - something that is not dependent on the higher level language
used - as it tries to disconnect the language from the semantics (how
you say it vs what you mean).

My experience is that - when using the C language - I cannot usually
find any better solution than the generated code (whether it be with GCC
or CLANG/LLVM) - It actually uses architecture tricks I wouldn't have
thought about.

--Ivan



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

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

On 23 October 2015 at 18:14, Ivan Warren ***@vmfacility.fr wrote:
> I'm a bit surprised here. Both LLVM and GCC use an intermediate language
> to enable optimization : They all turn the "compiled" language into
> something that is "universal" (in the point of view of the backend) -
> that is - something that is not dependent on the higher level language
> used - as it tries to disconnect the language from the semantics (how
> you say it vs what you mean).
>
> My experience is that - when using the C language - I cannot usually
> find any better solution than the generated code (whether it be with GCC
> or CLANG/LLVM) - It actually uses architecture tricks I wouldn't have
> thought about.

But that is surely not evidence for or against the suggestion that
both these compilers may be biased toward C/C++ source languages.

How do they perform with, say, FORTRAN or Ada? Of course one would
like to ask a more difficult question: how do they perform with PL/I
or one of its dialects?

Tony H.

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

On 10/24/2015 1:15 AM, Tony Harminc ***@gmail.com [hercules-390] wrote:
> On 23 October 2015 at 18:14, Ivan Warren ***@vmfacility.fr wrote:
>> I'm a bit surprised here. Both LLVM and GCC use an intermediate language
>> to enable optimization : They all turn the "compiled" language into
>> something that is "universal" (in the point of view of the backend) -
>> that is - something that is not dependent on the higher level language
>> used - as it tries to disconnect the language from the semantics (how
>> you say it vs what you mean).
>>
>> My experience is that - when using the C language - I cannot usually
>> find any better solution than the generated code (whether it be with GCC
>> or CLANG/LLVM) - It actually uses architecture tricks I wouldn't have
>> thought about.
> But that is surely not evidence for or against the suggestion that
> both these compilers may be biased toward C/C++ source languages.
>
> How do they perform with, say, FORTRAN or Ada? Of course one would
> like to ask a more difficult question: how do they perform with PL/I
> or one of its dialects?
>
> Tony H.
>
>
This would be more of a question of how the "frontend" is capable of
turning the program into an intermediate language !

I tried with jcc - (the Java GCC frontend) - and the results seemed
quite convincing - But I'd have to make more tests

It pretty much depends on how much effort is put into the other languages...

Using a 3 step compilation seems like a sane way of compiling... High
level -> Intermediate (then optimize) -> Native

But that's me just thinking out loud - I am no compiler expert.

--Ivan



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

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

On 23 October 2015 at 19:42, Ivan Warren ***@vmfacility.fr wrote:
>> How do they perform with, say, FORTRAN or Ada? Of course one would
>> like to ask a more difficult question: how do they perform with PL/I
>> or one of its dialects?

> This would be more of a question of how the "frontend" is capable of
> turning the program into an intermediate language !

Well I'm not so sure. If the intermediate representation is itself
optimized, or even designed, for one language, then a language with
very different semantics may not survive the process too well.

Tony H.

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

On 10/24/2015 2:22 AM, Tony Harminc ***@gmail.com [hercules-390] wrote:
> On 23 October 2015 at 19:42, Ivan Warren ***@vmfacility.fr wrote:
>>> How do they perform with, say, FORTRAN or Ada? Of course one would
>>> like to ask a more difficult question: how do they perform with PL/I
>>> or one of its dialects?
>> This would be more of a question of how the "frontend" is capable of
>> turning the program into an intermediate language !
> Well I'm not so sure. If the intermediate representation is itself
> optimized, or even designed, for one language, then a language with
> very different semantics may not survive the process too well.
>
>
I beg to differ !

I don't think that a strictly defined computer language cannot be
reduced to an intermediate form which can then be optimized.

To me a strictly defined language is a language where all your intents
as a programmer can be expressed. (But I haven't looked at all the
languages in 99 bottles of beer http://www.99-bottles-of-beer.net)

--Ivan



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

[Maarten Hoes [e-mail] [hercules-390]]

Hi,


On Fri, Oct 23, 2015 at 11:31 PM, Mark Morgan Lloyd
markmll.hercules-***@telemetry.co.uk [hercules-390] <
hercules-***@yahoogroups.com> wrote:
>
> And I've seen suggestion that LLVM might possibly be excessively
> specialised towards C++ and its close relatives, to the detriment of-
> e.g.- languages with more flexible scoping rules.
>
Memory might (will) fail me here. Or I might (will) have misunderstood your
previous post. But in my recollection, C was implemented in LLVM before C++
and Objective-C.

Anyway, werent we talking about 'C' here ? I might have missed some
(important) posts.


- Maarten

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

On Fri, 2015-10-23 at 12:12 +0000, Mark Morgan Lloyd
markmll.hercules-***@telemetry.co.uk [hercules-390] wrote:

>
> So what exactly happened to Solaris for System z?

In a word, Oracle happened to Solaris for System z. I was making some
enhancements to Hercules that would allow Solaris for System z to run.
Solaris for System z was targeted for use in a z/VM virtual machine and
needed some DIAGNOSE function emulation to run.

Sine Nomine Associates (SNA) was behind the openSolaris port to System
z. When Oracle decided to kill openSolaris, SNA's efforts became a
victim. From participation on the System z openSolaris mailing list a
number of consequences resulted from Oracle's decision that ended SNA's
efforts.

As was pointed out the resuscitated openSolaris effort after Oracle's
actions were not interested in the System z port. This also contributed
to its failure to return as a port.

BTW, I did get openSolaris to run on Hercules. Probably the only one on
the planet to do so. I was working with SNA to package a version for
use with Hercules when Oracle happened. Once SNA's port died, it made
no sense to continue the changes to Hercules to support it.

Harold Grovesteen

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

On 10/24/2015 5:38 PM, Harold Grovesteen ***@tx.rr.com
[hercules-390] wrote:
> On Fri, 2015-10-23 at 12:12 +0000, Mark Morgan Lloyd
> markmll.hercules-***@telemetry.co.uk [hercules-390] wrote:
>
>> So what exactly happened to Solaris for System z?
> In a word, Oracle happened to Solaris for System z. I was making some
> enhancements to Hercules that would allow Solaris for System z to run.
> Solaris for System z was targeted for use in a z/VM virtual machine and
> needed some DIAGNOSE function emulation to run.
>
> Sine Nomine Associates (SNA) was behind the openSolaris port to System
> z. When Oracle decided to kill openSolaris, SNA's efforts became a
> victim. From participation on the System z openSolaris mailing list a
> number of consequences resulted from Oracle's decision that ended SNA's
> efforts.
>
> As was pointed out the resuscitated openSolaris effort after Oracle's
> actions were not interested in the System z port. This also contributed
> to its failure to return as a port.
>
> BTW, I did get openSolaris to run on Hercules. Probably the only one on
> the planet to do so. I was working with SNA to package a version for
> use with Hercules when Oracle happened. Once SNA's port died, it made
> no sense to continue the changes to Hercules to support it.
>
> Harold Grovesteen
>
>
>
Is there still a "legal" repository of Open Solaris for z lying around -
Or does the SUN (now Oracle) license prohibit it ?

(Not that I'm willing to work on it... Just a simple question)

--Ivan



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

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

On Sat, 2015-10-24 at 17:43 +0200, Ivan Warren ***@vmfacility.fr
[hercules-390] wrote:
>
> On 10/24/2015 5:38 PM, Harold Grovesteen ***@tx.rr.com
> [hercules-390] wrote:
> > On Fri, 2015-10-23 at 12:12 +0000, Mark Morgan Lloyd
> > markmll.hercules-***@telemetry.co.uk [hercules-390] wrote:
> >
> >> So what exactly happened to Solaris for System z?
> > In a word, Oracle happened to Solaris for System z. I was making some
> > enhancements to Hercules that would allow Solaris for System z to run.
> > Solaris for System z was targeted for use in a z/VM virtual machine and
> > needed some DIAGNOSE function emulation to run.
> >
> > Sine Nomine Associates (SNA) was behind the openSolaris port to System
> > z. When Oracle decided to kill openSolaris, SNA's efforts became a
> > victim. From participation on the System z openSolaris mailing list a
> > number of consequences resulted from Oracle's decision that ended SNA's
> > efforts.
> >
> > As was pointed out the resuscitated openSolaris effort after Oracle's
> > actions were not interested in the System z port. This also contributed
> > to its failure to return as a port.
> >
> > BTW, I did get openSolaris to run on Hercules. Probably the only one on
> > the planet to do so. I was working with SNA to package a version for
> > use with Hercules when Oracle happened. Once SNA's port died, it made
> > no sense to continue the changes to Hercules to support it.
> >
> > Harold Grovesteen
> >
> >
> >
> Is there still a "legal" repository of Open Solaris for z lying around -
> Or does the SUN (now Oracle) license prohibit it ?
>
> (Not that I'm willing to work on it... Just a simple question)
>
> --Ivan
>
>
Once SUN had made versions available as open source, those could not go
away. Oracle could not go back in time and change that. This is why
the resuscitated x86-64 effort could continue. Those sources certainly
are available and legal.

Somewhere the changes made to support z/Architecture were in a
repository or branch. If they exist somewhere, they are certainly
legal. I looked at SNA's web site and what they did have available
seems to have gone away. I honestly don't know if they exist anywhere.

One of the major challenges was the build tool chain. The port included
a gcc option for Open Solaris to build on s390 architecture. A lot of
the difficulties revolved around the tool chain and the ability to
continue to build Open Solaris on z. The x68-64 effort had some of
those same issues. They overcame those problems, but it was too late
for the z port to take advantage of them.

Harold Grovesteen

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

On Sat, 2015-10-24 at 17:43 +0200, Ivan Warren ***@vmfacility.fr
[hercules-390] wrote:

> Is there still a "legal" repository of Open Solaris for z lying around -
> Or does the SUN (now Oracle) license prohibit it ?
>
> (Not that I'm willing to work on it... Just a simple question)
>
> --Ivan
>

Did some hunting and found

http://distribution.sinenomine.net/opensolaris/

https://en.wikipedia.org/wiki/OpenSolaris_for_System_z

The binary information is still available, if you know the link.
The source seems to have been available at www.opensolaris.org. But
that site no longer seems to exist. Maybe SNA or someone else has held
onto the source.

Harold Grovesteen

[Robert Prins [e-mail] [hercules-390]]

http://web.archive.org/web/20080101000000*/http://www.opensolaris.org

On 24 October 2015 at 16:58, Harold Grovesteen ***@tx.rr.com
[hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
> On Sat, 2015-10-24 at 17:43 +0200, Ivan Warren ***@vmfacility.fr
> [hercules-390] wrote:
>
> > Is there still a "legal" repository of Open Solaris for z lying around -
> > Or does the SUN (now Oracle) license prohibit it ?
> >
> > (Not that I'm willing to work on it... Just a simple question)
> >
> > --Ivan
> >
>
> Did some hunting and found
>
> http://distribution.sinenomine.net/opensolaris/
>
> https://en.wikipedia.org/wiki/OpenSolaris_for_System_z
>
> The binary information is still available, if you know the link.
> The source seems to have been available at www.opensolaris.org. But
> that site no longer seems to exist. Maybe SNA or someone else has held
> onto the source.
>
> Harold Grovesteen
>
>
>



--
Robert AH Prins
***@gmail.com

[Josef 'Jeff' Sipek [e-mail] [hercules-390]]

On Sat, Oct 24, 2015 at 05:43:48PM +0200, Ivan Warren ***@vmfacility.fr [hercules-390] wrote:
> On 10/24/2015 5:38 PM, Harold Grovesteen ***@tx.rr.com
> [hercules-390] wrote:
> > On Fri, 2015-10-23 at 12:12 +0000, Mark Morgan Lloyd
> > markmll.hercules-***@telemetry.co.uk [hercules-390] wrote:
> >
> >> So what exactly happened to Solaris for System z?
> > In a word, Oracle happened to Solaris for System z. I was making some
> > enhancements to Hercules that would allow Solaris for System z to run.
> > Solaris for System z was targeted for use in a z/VM virtual machine and
> > needed some DIAGNOSE function emulation to run.
> >
> > Sine Nomine Associates (SNA) was behind the openSolaris port to System
> > z. When Oracle decided to kill openSolaris, SNA's efforts became a
> > victim. From participation on the System z openSolaris mailing list a
> > number of consequences resulted from Oracle's decision that ended SNA's
> > efforts.
> >
> > As was pointed out the resuscitated openSolaris effort after Oracle's
> > actions were not interested in the System z port. This also contributed
> > to its failure to return as a port.
> >
> > BTW, I did get openSolaris to run on Hercules. Probably the only one on
> > the planet to do so. I was working with SNA to package a version for
> > use with Hercules when Oracle happened. Once SNA's port died, it made
> > no sense to continue the changes to Hercules to support it.
> >
> > Harold Grovesteen
>
> Is there still a "legal" repository of Open Solaris for z lying around -
> Or does the SUN (now Oracle) license prohibit it ?

Absolutely! The OpenSolaris code was licensed under CDDL - a MPL
derivative. The "upstream" OpenSolaris code got forked back in 2011 as
illumos (http://illumos.org). It supports x86 & sparc.

The code Sine Nomine published was also licensed under the CDDL so anyone
who has a copy can share it without worrying about Oracle. I currently
don't have a good way to host the Mercurial repository, but I can make it
available to anyone who wants it.

Jeff.

> (Not that I'm willing to work on it... Just a simple question)
>
> --Ivan
>
>
>
> [Non-text portions of this message have been removed]
>

--
C is quirky, flawed, and an enormous success.
- Dennis M. Ritchie.

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

On Sat, 2015-10-24 at 13:49 -0400, Josef 'Jeff' Sipek
***@josefsipek.net [hercules-390] wrote:


> The code Sine Nomine published was also licensed under the CDDL so anyone
> who has a copy can share it without worrying about Oracle. I currently
> don't have a good way to host the Mercurial repository, but I can make it
> available to anyone who wants it.
>
> Jeff.
>
Jeff, would it not be easiest, even if the repo technology needed to be
changed, to host it on something like github?

That is what I was thinking about doing if we could get a copy, which I
guess you have. Wonder how it might compare to the one SNA may have.

Harold

[Mick Graley [e-mail] [hercules-390]]

On 21 October 2015 at 10:27, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

> >> I also provided other great tools like
>
> >> DIFF3 (three-way diff, one of the great
> >> advances in computer science).
>
> > Again, that's a great achievement.
> > I like the GNU and UNIX tools.
> > Not sure how well they fit on z/OS but I'm willing to be shown the light
> :-)
>
> The concept of a 3-way diff is completely
> independent of platform.
>
> Regardless of whether you are on Unix
> or z/OS, if two people independently
> make changes to a common file, then
> 3-way diffs will automatically sort out
> what is otherwise a mess.
>
> And you can't get diff3 on z/OS without
> GCCMVS. :-) Sort of, anyway.
>
Where are these ported tools Paul?
Are they just on the MVS/380 system?
I couldn't find a link or docs for them on the GCCMVS sourceforge site.


> I am not aware of what new APIs are
> involved in PDS/Es. I would guess
> that the standard OPEN macro which
> works on sequential files and PDS
> members will also work on PDS/Es.
>
> But yes, it would be good if you could
> test that personally.
>
I got GCCMVS up and running on z/OS 1.13 yesterday.
I tested some simple programs and reading and writing PDS/E members works
fine.
Now I need to resume learning C programming!

>
> Hercules/380 is *already* a fork, and
> stuck at 3.07 because no-one has
> volunteered to merge the changes
> in either direction.
>
> > that is easy enough to keep in step with
> > the main Hercules code base.
>
> It is not easy. Are you volunteering
> to do this non-trivial task?
>
No way! :-)
My limited knowledge of C and Git etc preclude me from this task.

BFN. Paul.
>
I've probably taken this discussion way off topic now. Sorry everyone!
If you want me to test anything on z/OS (especially the ported tools) then
contact me off-list.

Cheers,

Mick.

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

>> And you can't get diff3 on z/OS without
>> GCCMVS. :-) Sort of, anyway.

> Where are these ported tools Paul?

> Are they just on the MVS/380 system?

> I couldn't find a link or docs for them on
> the GCCMVS sourceforge site.

The source code is on the GCCMVS
sourceforge site:

Source code is here:

https://sourceforge.net/projects/gccmvs/files/diffmvs/

Precompiled binaries (lots more things
that DIFF3) are distributed as part of SEASIK:

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

I believe the binaries are also provided
as part of TK4-, and thus MVS/380
also.

Let me know if that isn't enough.


> I got GCCMVS up and running on z/OS 1.13 yesterday.

Fantastic!

> I tested some simple programs and reading
> and writing PDS/E members works fine.

Excellent!

> Now I need to resume learning C programming!

Good move!

BFN. Paul.

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

> Precompiled binaries (lots more things
> that DIFF3) are distributed as part of SEASIK:

> https://sourceforge.net/projects/gccmvs/files/SEASIK/

Be aware that SEASIK contains an older
version of GCCMVS, so keep your current
version of GCCMVS, which is presumably
8.5.

BFN. Paul.

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

> current version of GCCMVS, which is
> presumably 8.5.

That's assuming you downloaded
GCC 3.2.3 rather than 3.4.6.

I recommend using 3.2.3 v 8.5,
not 3.4.6 v 1.0. The latter has
more bugs in it.

BFN. Paul.

[Mick Graley [e-mail] [hercules-390]]

On 22 October 2015 at 10:00, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> > current version of GCCMVS, which is
> > presumably 8.5.
>
> That's assuming you downloaded
> GCC 3.2.3 rather than 3.4.6.
>
> I recommend using 3.2.3 v 8.5,
> not 3.4.6 v 1.0. The latter has
> more bugs in it.
>

Oops! I downloaded the current/latest version thinking that was a better
option as it had a later version of GCC. Point noted, also the previous one
about the older version in SEASIK.


> BFN. Paul.
>
> Cheers,

Mick.

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

> Oops! I downloaded the current/latest
> version thinking that was a better option
> as it had a later version of GCC.

Well, 3.4.6 is indeed good enough to
recompile itself without hitting any bugs.

It also produces better code (ie smaller
executables) than 3.2.3. When it is
working, anyway. And most of the time
it does indeed work. There's a good
chance you'll never hit any bugs when
doing your work.

BFN. Paul.

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

On 10/15/2015 9:15 PM, Ivan Warren ***@vmfacility.fr [hercules-390] wrote:
> I can assure you. BAS/BASR are *DOCUMENTED* S/370 instructions. (your
> ref card is just outdated).

Actually, every S/370 card is outdated, since IBM is using z/OS and its
documentation. I suspect that my P/390 may be the last one running
OS/390? My S/370 card applied to the machine I used it with. If you want
to start nitpicking, then BAS and BASR were documented on the S/360
reference, qualified as applying to the model 67.

> However the "380" architecture breaks MANY of the S/370 rules (PSW bits,
> DAT, key, etc...) That is NOT hercules... It's a brand new
> architecture.... (which has NO protection mechanism on which who can see
> over looks over who and can not only check the other guy's door but can
> also steel, change.... 380 has *ONE* single address space over 16M which
> can be addressed and accessed by *ALL* (without supervisor intervention)
> - or correct me if I'm wrong about this)

You're making the case for having it working as you expect, which is
most easily done if its integrated into the base.

> But I can assure you - I am NOT ready to start maintaining this...

Isn't the entire project a group effort?

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/

[Dave McGuire [e-mail] [hercules-390]]

On 10/16/2015 02:52 PM, Gerhard Postpischil ***@charter.net
[hercules-390] wrote:
>> I can assure you. BAS/BASR are *DOCUMENTED* S/370 instructions. (your
>> ref card is just outdated).
>
> Actually, every S/370 card is outdated, since IBM is using z/OS and its
> documentation. I suspect that my P/390 may be the last one running
> OS/390?

[raises hand]

Nope. I have two P/390s, the second is also about to be running OS/390.

Also, not to be disagreeable, but I dispute the notion that every
S/370 card is outdated simply because the manufacturer released
subsequent iterations of the architecture. The S/370 cards still apply
perfectly well to S/370s.

-Dave

--
Dave McGuire, AK4HZ
New Kensington, PA


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

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

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

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

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


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

Yahoo Groups Links

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

<*> Your email settings:
Individual Email | Traditional

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

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

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

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

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

On 10/16/2015 3:02 PM, Dave McGuire ***@neurotica.com [hercules-390]
wrote:
> Also, not to be disagreeable, but I dispute the notion that every
> S/370 card is outdated simply because the manufacturer released
> subsequent iterations of the architecture. The S/370 cards still apply
> perfectly well to S/370s.

Apparently you jumped into the middle of the thread, and are repeating
my point. I said that my -3 S/370 card didn't show BAS/BASR, and got two
replies that it was obsolete. I then made the conditional statement that
based on that "logic" all S/370 cards are obsolete. Obviously each card
applies to a specific machine or a group, and in that sense is never
obsolete.

And I would never get upset about an opinion; I might get disagreeable
by a misstatement of fact, especially one repeated after correction.

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/

[Dave McGuire [e-mail] [hercules-390]]

On 10/18/2015 10:57 AM, Gerhard Postpischil ***@charter.net
[hercules-390] wrote:
>> Also, not to be disagreeable, but I dispute the notion that every
>> S/370 card is outdated simply because the manufacturer released
>> subsequent iterations of the architecture. The S/370 cards still apply
>> perfectly well to S/370s.
>
> Apparently you jumped into the middle of the thread, and are repeating
> my point. I said that my -3 S/370 card didn't show BAS/BASR, and got two
> replies that it was obsolete. I then made the conditional statement that
> based on that "logic" all S/370 cards are obsolete. Obviously each card
> applies to a specific machine or a group, and in that sense is never
> obsolete.
>
> And I would never get upset about an opinion; I might get disagreeable
> by a misstatement of fact, especially one repeated after correction.

I'm sorry Gerhard, you are absolutely right. Apparently I was
undercaffeinated that day; I wasn't paying quite as much attention as I
thought I was!

-Dave

--
Dave McGuire, AK4HZ
New Kensington, PA


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

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

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

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

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


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

Yahoo Groups Links

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

<*> Your email settings:
Individual Email | Traditional

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

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

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

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

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

On 10/18/2015 4:57 PM, Gerhard Postpischil ***@charter.net
[hercules-390] wrote:
> On 10/16/2015 3:02 PM, Dave McGuire ***@neurotica.com [hercules-390]
> wrote:
>> Also, not to be disagreeable, but I dispute the notion that every
>> S/370 card is outdated simply because the manufacturer released
>> subsequent iterations of the architecture. The S/370 cards still apply
>> perfectly well to S/370s.
>
> And I would never get upset about an opinion; I might get disagreeable
> by a misstatement of fact, especially one repeated after correction.
>
>
I disagree !

(Just kidding)

--Ivan



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

[Dave McGuire [e-mail] [hercules-390]]

On 10/18/2015 02:59 PM, Ivan Warren ***@vmfacility.fr [hercules-390] wrote:
>>> Also, not to be disagreeable, but I dispute the notion that every
>>> S/370 card is outdated simply because the manufacturer released
>>> subsequent iterations of the architecture. The S/370 cards still apply
>>> perfectly well to S/370s.
>>
>> And I would never get upset about an opinion; I might get disagreeable
>> by a misstatement of fact, especially one repeated after correction.
>>
> I disagree !
>
> (Just kidding)

;)

--
Dave McGuire, AK4HZ
New Kensington, PA


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

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

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

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

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


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

Yahoo Groups Links

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

<*> Your email settings:
Individual Email | Traditional

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

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

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

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

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

Hello!
I'll say. Too much work. And of course the facts that those Yetis were
trying to corrupt a gaggle of machines to do their dirty work didn't
help any as they were also.

Besides its the fault of Vanya for wanting to start trouble. And this
is not the fault of the other two ones named Dave here. Including the
one with gills who we need to hear from second.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."


On Sun, Oct 18, 2015 at 4:04 PM, Dave McGuire ***@neurotica.com
[hercules-390] <hercules-***@yahoogroups.com> wrote:
> On 10/18/2015 02:59 PM, Ivan Warren ***@vmfacility.fr [hercules-390] wrote:
>>>> Also, not to be disagreeable, but I dispute the notion that every
>>>> S/370 card is outdated simply because the manufacturer released
>>>> subsequent iterations of the architecture. The S/370 cards still apply
>>>> perfectly well to S/370s.
>>>
>>> And I would never get upset about an opinion; I might get disagreeable
>>> by a misstatement of fact, especially one repeated after correction.
>>>
>> I disagree !
>>
>> (Just kidding)
>
> ;)
>
> --
> Dave McGuire, AK4HZ
> New Kensington, PA
>
>
> ------------------------------------
>
> ------------------------------------
>
> Community email addresses:
> Post message: hercules-***@yahoogroups.com
> Subscribe: hercules-390-***@yahoogroups.com
> Unsubscribe: hercules-390-***@yahoogroups.com
> List owner: hercules-390-***@yahoogroups.com
>
> Files and archives at:
> http://groups.yahoo.com/group/hercules-390
>
> Get the latest version of Hercules from:
> http://www.hercules-390.org
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>

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

On 10/18/2015 11:03 PM, Gregg Levine ***@gmail.com
[hercules-390] wrote:
> Besides its the fault of Vanya for wanting to start trouble. And this
> is not the fault of the other two ones named Dave here. Including the
> one with gills who we need to hear from second.
>
You know I wouldn't start trouble if I hadn't a good reason to do so ;)

--Ivan



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

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

Gerhard Postpischil wrote:
> Ivan Warren wrote:
>
> > S/370 DOES support BASR - It is indicated in GA22-700
> > (latest version) - furthermore BASR is NOT prohibited
> > by any other versions of GA22-7000.
>
> I have a reference card GX20-1850-3, and it does not list BAS or BASR.

Your reference card is out of date. The last version of S/370 PrincOps most definitely *does* document BAS and BASR, just as Ivan said.

GA22-7000-10 can be downloaded from either bitsavers.org or from the Internet Archive:

http://www.bitsavers.org/pdf/ibm/370/

At the very bottom of that page (lowercase comes *after* uppercase in their directory listing) there's a link to the "princOps/" directory. Clicking that takes you to:

http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/ibm/370/princOps/

You can also view and/or download it from the Internet Archive:

https://archive.org/details/bitsavers_ibm370prininciplesofOperationSep87_37959168

Just click the "PDF" download link in the box on the right hand side of the page, taking you to:

https://ia902703.us.archive.org/23/items/bitsavers_ibm370prininciplesofOperationSep87_37959168/GA22-7000-10_370_Principles_of_Operation_Sep87.pdf

As you will see, BAS and BASR, etc, most definitely *are* an official part of the System/370 architecture.


And I too, like Ivan, object to the 380 extension. Instead, whoever wants to support is should fork Hyperion or 3.11 and start maintaining it. That way people can always download the latest source for 380 whenever they want without having to mess with any patches.

And if they want to periodically merge the changes we make to Hyperion into their 380 repository, then fine, that's easy to do too.

But the point is *I* don't want to have to maintain 380 code nor have its side effects interfere with our supporting the officially recognized IBM architectures, and from the sound of it neither do most of the other developers. It's hard enough supporting Herc as it is without adding yet further complications.

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

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

On 10/15/2015 9:46 PM, ''Fish' (David B. Trout)' ***@gmail.com
[hercules-390] wrote:
> Your reference card is out of date. The last version of S/370
> PrincOps most definitely *does* document BAS and BASR, just as Ivan
> said.

It seems to me that the "last" S/370 reference card applied to XA, which
is definitely not what we are running. It applied exactly to the machine
I used it with.

> GA22-7000-10 can be downloaded from either bitsavers.org or from the
> Internet Archive:

I have a drawer full of reference "cards", all the way up to the white z
booklet. The instruction set on each corresponds to specific models,
which (unfortunately?) Hercules does not implement (e.g., ECPS should
fail on early 370s).

> And if they want to periodically merge the changes we make to
> Hyperion into their 380 repository, then fine, that's easy to do
> too.

I don't like applying changes to software I'm not competent to make. I
did get the MS assembler when the PC first came out, but I am not a fan
of either the hardware or software. And I'm certain that authors of
other forks should not need to make change after change, when the same
effort could be expended only once. You could always have them provide a
test suite to run after modifications.

> But the point is *I* don't want to have to maintain 380 code nor have
> its side effects interfere with our supporting the officially
> recognized IBM architectures, and from the sound of it neither do
> most of the other developers. It's hard enough supporting Herc as it
> is without adding yet further complications.

I find it more interesting to have received no comments about getting an
HL compatible assembler to run on a legal platform.

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]]

> Don't know about "frequent", but 370 mode
> supports BASR and BASR, and
> perhaps other things I haven't tried.

I think a better example would be this code
in standard Hercules:

feat370.h:

/* The following ESA/390 features can be retrofitted to S/370 and
may be activated if desired by uncommenting the appropriate
define statements below and performing a complete rebuild */
#define FEATURE_BASIC_FP_EXTENSIONS
#define FEATURE_BINARY_FLOATING_POINT
#define FEATURE_CHECKSUM_INSTRUCTION
#define FEATURE_COMPARE_AND_MOVE_EXTENDED
#define FEATURE_COMPRESSION
#define FEATURE_EXTENDED_TRANSLATION
#define FEATURE_EXTENDED_TRANSLATION_FACILITY_2
#define FEATURE_HFP_EXTENSIONS
#define FEATURE_HFP_MULTIPLY_ADD_SUBTRACT
#define FEATURE_HFP_UNNORMALIZED_EXTENSION
#define FEATURE_IMMEDIATE_AND_RELATIVE
#define FEATURE_SQUARE_ROOT
#define FEATURE_STRING_INSTRUCTION

/* The following ESAME features can be retrofitted to S/370 and
may be activated if desired by uncommenting the appropriate
define statements below and performing a complete rebuild */
#define FEATURE_ESAME_N3_ESA390
#define FEATURE_ETF2_ENHANCEMENT
#define FEATURE_ETF3_ENHANCEMENT
#define FEATURE_EXECUTE_EXTENSIONS_FACILITY
#define FEATURE_EXTENDED_IMMEDIATE
#define FEATURE_EXTENDED_TRANSLATION_FACILITY_3
#define FEATURE_GENERAL_INSTRUCTIONS_EXTENSION_FACILITY
#define FEATURE_LONG_DISPLACEMENT
#define FEATURE_MESSAGE_SECURITY_ASSIST
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_1
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_2
#define FEATURE_PARSING_ENHANCEMENT_FACILITY



BFN. Paul.

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

Implementing vm functions, extensions to access tcpip and file store...

> -----Original Message-----
> From: hercules-***@yahoogroups.com [mailto:hercules-
> ***@yahoogroups.com]
> Sent: 15 October 2015 21:27
> To: hercules-***@yahoogroups.com
> Subject: Re: [hercules-390] Possibility of merging in Hercules 380
extensions
>
>
>
> On 10/15/2015 9:28 PM, Harold Grovesteen ***@tx.rr.com
> [hercules-390] wrote:
> > As Hercules frequently goes beyond what is in those manuals
> Reference please !
>
> --Ivan
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
> Posted by: Ivan Warren <***@vmfacility.fr>
> ------------------------------------
>
> Community email addresses:
> Post message: hercules-***@yahoogroups.com
> Subscribe: hercules-390-***@yahoogroups.com
> Unsubscribe: hercules-390-***@yahoogroups.com
> List owner: hercules-390-***@yahoogroups.com
>
> Files and archives at:
> http://groups.yahoo.com/group/hercules-390
>
> Get the latest version of Hercules from:
> http://www.hercules-390.org
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>

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

> I personally support the 380 enhancements.
> Harold Grovesteen

Thanks for your support Harold! I agree
with everything you said.

BTW, while looking back at old messages,
I can see that I was not very clear in one
of my messages:

https://groups.yahoo.com/neo/groups/hercules-380/conversations/messages/408

You asked this question:

> Unless all
> of the GENx___x390x900's get turned into GENx370x390x900,

And I just dumped this code:

> > ! #ifdef FEATURE_S380
> > ! #define GENx___x390x900 GENx370x390x900
> > ! #else

without specifically saying that this
code clearly converts all 390+900
(common) instructions into 370.

BFN. Paul.

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

> If the plan is to run GNU programs - then run
> them on an Intel processor running Linux
> (Or Linux running on hercules in z/Arch mode).

The plan is to run z/OS programs, like
GCCMVS. The fact that the vendor
is GNU instead of IBM is totally
irrelevant.

The z/OS programs do things like open
a member of concatenated PDSes,
something which has zero chance of
working on either Intel or even Linux
in z/Arch.

The z/OS programs also use DD
statements etc.

There is no more reason to switch
these programs from z/OS to a PC
than there is to move any other
z/OS application off z/OS. While
ever z/OS remains an important
platform, then having a free C
compiler for it is very useful (to
some, at least).

MVS/380 allows a z/OS program like
GCCMVS to run in certain situations
that MVS 3.8j can't handle. To fulfil
this need, it works fine, according to
anyone who has actually bothered
to use it, and who actually cares
about running such z/OS programs
because they're not running a
bootlegged z/OS.

BFN. Paul.

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

Another thing I should note is that the majority
of the Hercules/380 changes are actually
extensions to tape-handling, not 31-bit
processing.

Even if Laddie's CR13 is implemented in
standard Hercules, I personally won't be
moving. I'm probably the only person
using the tape extensions though, so
maybe that's not relevant.

BFN. Paul.

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

> The so called 380 extension breaks each and every S/370 architectural
> principles. (It breaks Virtualization, Key protection, Address space
> separation, and more S/370 *explicit* mechanism stated in the book of
> law (GA22-7000) that I cannot put my finger on at the moment).

I'd also like to point out that it is the S/380
POO, not the S/370 POO, that is relevant
to this discussion.

Hercules/380 perfectly conforms to the
S/380 POO.

The same way that Fujitsu MSP conforms
to the Fujitsu POO.

And the same way that IBM's S/390
conforms to the S/390 POO, not the
S/370 POO.

BFN. Paul.

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

> I'd also like to point out that it is the S/380
> POO, not the S/370 POO, that is relevant
> to this discussion.

> Hercules/380 perfectly conforms to the
> S/380 POO.

For those interested, the S/380 POO can
be found here:

http://mvs380.sourceforge.net/System380.txt

Search for "CR13".

It's not up to IBM's standard of documentation,
but unless you're being deliberately obnoxious,
it's perfectly understandable.

If anyone is genuinely having trouble
understanding it, let me know and I'll
try to explain, and possibly update
the document.

Like I said, it's not up to IBM's or
presumably Fujitsu's level of
professionalism, but it is after all
an architecture produced by
hobbyists (Laddie etc), not an
international company.

BFN. Paul.

[Jay Moseley [e-mail] [hercules-390]]

On 10/15/2015 12:47 PM, ***@yahoo.com [hercules-390] wrote:
> It would certainly be useful to many users if the Hercules 380
> extensions could be folded into the main distribution, perhaps
> optionally enabled in runtime configuration. These extensions couple
> with Turnkey MVS MVS/380 extensions which allow 31 bit addressing, a
> critical feature that allows for a larger variety of programs to be run.
> This would avoid issues with and headaches for many turnkey users of
> using the patch to out of date hercules versions. This would be a good
> idea and of benefit to users.

It might be useful to many users of Hercules 380, but not to those of us
using Hercules to run unmodified legacy operating systems. Although I am
not a Hercules developer, I would be opposed to merging these extensions
into Hercules.

Regards,
Jay Moseley

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

As interesting an idea as this might be, I would have to be opposed to it also, but for different reasons.


We have to face facts; Hercules is in trouble.


Correct me if I have any of these facts wrong, but as I understand it, there has not been a new release of Hercules in a year, since 3.11. The task list for 3.12 only contains two declared features, yet the developers are silent on when (if ever?) 3.12 will appear. There is dissention in the ranks between developers, and developers are being lost.


I the face of all this, this is not the time to be trying to show-horn an experimental offshoot of Hercules into the main fold. The highest priority ought to be to reconcile any issues faced by the developers, to resolve any differences (personal or otherwise) and put Hercules on a strong footing again. I see the idea of merging Hercules 380 as a distraction to what is more important, at a time when we can least afford it.


I truly wish we had unlimited resources to do everything, but we don't. I would help myself if I could, but I don't understand Hercules internals enough to make a difference, and I am not in the best of health either, so my efforts wouldn't amount to much.


The truth is, we can't do everything. We have to make choices as to what is possible, and what is in the best interests of the most people. I don't believe this Hercules 380 idea is in fact in the best interests of Hercules users.

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

On 10/15/2015 3:30 PM, ***@yahoo.com [hercules-390] wrote:
> The truth is, we can't do everything. We have to make choices as to
> what is possible, and what is in the best interests of the most people.
> I don't believe this Hercules 380 idea is in fact in the best interests
> of Hercules users.

Perhaps a case can be made that this is useful to a larger portion of
the users than perceived. David Bond's Tachyon Assembler is basically
compatible with HLASM, but does not use utility files, and is severely
constrained by the 8-10MiB private region available in MVS. With the 380
mods to Hercules, and some tweaks to storage management, MVS users could
get a fully functional assembler than will tackle large programs, not
just trivial ones. One of my long term objectives is to get Wylbur
running, but the SLAC version requires HLASM (or compatible) and fails
to complete assemblies in my 9 MiB region.

Gerhard Postpischil
Bradford, VT

[Robert Prins [e-mail] [hercules-390]]

This may not be a well-received comment, but I find the suggestion a that a
380-enhanced Hercules that allows "newbies" to run bigger (GCC) programs,
thus allowing them to get better acquainted with a mainframe system,
eminently laughable. For me it's the same as giving a newbie a Windows 3.11
system to let them get acquainted with a PC, because it can do more than
MS-DOS.

The fact is that, whether we in this group like to admit to using it or
not, and whether IBM likes it or not, there is a z/OS 1.10 ADCD
distribution out in the wild, that runs perfectly well, even on very modest
hardware. It has up-to-date tools (HLASM, Enterprise PL/I, Enterprise
COBOL, C/C++) and the interface (ISPF) newbies will use if they ever move
to a real z/OS system. If you want to introduce a newbie to IBM, that would
be the place to start!

My € 0.02...

Robert

On 16 October 2015 at 19:20, Mark Morgan Lloyd
markmll.hercules-***@telemetry.co.uk [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> And the VM/370 "Sixpack" is a comparatively easy environment to
> introduce to programmers brought up on Linux or Windows, and now that
> most of them can't remember anything smaller than 32-bit being able to
> offer /380 has to be a Good Thing- even if it's not "authentic".
>
> I'm definitely not thinking of anybody in this particular forum (or
> whatever one chooses to call it), but my unfortunate experience is that
> a lot of people who still consider mainframes to to be a worthwhile
> platform are excessively- I'm tempted to say aggressively- defensive
> when they engage with people who don't have significant exposure to
> them. That sort of attitude is really no substitute for providing a
> half-decent toolchain that people considering porting software from e.g.
> z/Linux to z/OS can play with, and while I'm not suggesting that serious
> developers would use VM/370 etc., making sure that they can get a bit of
> hands on experience before raising their heads above the parapet has to
> be to everybody's advantage.
>
> 'Dave Wade' ***@gmail.com [hercules-390] wrote:
> >
> > K&R C AKA the Portable C compiler existed on VM and is lost.
> >
> > GCCMVS allows REXX to be built on VM
> >
> > So these things existed and are lost.
> >
> > Dave
> >
> > *From:* hercules-***@yahoogroups.com [mailto:
> hercules-***@yahoogroups.com]
> > *Sent:* 16 October 2015 17:08
> > *To:* hercules-***@yahoogroups.com
> > *Subject:* Re: [hercules-390] Possibility of merging in Hercules 380
> > extensions
> >
> >
> > Hi All,
> >
> > I really don't want to get into the middle of a holy war, and this is
> > possibly ignorance on my part, but I just don't get why any "normal"
> > users would want the S/380 stuff. Then again most of my dabbling with
> > Hercules has been on OS/360 for historical interest! :-)
> >
> > I can see why Paul would want to have done it in the first place maybe
> > as a challenge and an academic exercise, but I just don't see the need
> > to be able to compile large C programs on a historically non-existent
> > platform/architecture.
>
> --
> Mark Morgan Lloyd
> markMLl .AT. telemetry.co .DOT. uk
>
> [Opinions above are the author's, not those of his employers or colleagues]
>
>



--
Robert AH Prins
***@gmail.com

[Gonzalo Martin Barrio [e-mail] [hercules-390]]

I can't talk from experience with the software, but I'd say: if the current
developers/maintainers of the existing "branches" don't want to include
this, I don't see any harm in a separate fork with the S380 functionality.

On Fri, Oct 16, 2015 at 5:12 PM, Robert Prins ***@gmail.com
[hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
> This may not be a well-received comment, but I find the suggestion a that
> a 380-enhanced Hercules that allows "newbies" to run bigger (GCC) programs,
> thus allowing them to get better acquainted with a mainframe system,
> eminently laughable. For me it's the same as giving a newbie a Windows 3.11
> system to let them get acquainted with a PC, because it can do more than
> MS-DOS.
>
> The fact is that, whether we in this group like to admit to using it or
> not, and whether IBM likes it or not, there is a z/OS 1.10 ADCD
> distribution out in the wild, that runs perfectly well, even on very modest
> hardware. It has up-to-date tools (HLASM, Enterprise PL/I, Enterprise
> COBOL, C/C++) and the interface (ISPF) newbies will use if they ever move
> to a real z/OS system. If you want to introduce a newbie to IBM, that would
> be the place to start!
>
> My € 0.02...
>
> Robert
>
> On 16 October 2015 at 19:20, Mark Morgan Lloyd
> markmll.hercules-***@telemetry.co.uk [hercules-390] <
> hercules-***@yahoogroups.com> wrote:
>
>>
>>
>> And the VM/370 "Sixpack" is a comparatively easy environment to
>> introduce to programmers brought up on Linux or Windows, and now that
>> most of them can't remember anything smaller than 32-bit being able to
>> offer /380 has to be a Good Thing- even if it's not "authentic".
>>
>> I'm definitely not thinking of anybody in this particular forum (or
>> whatever one chooses to call it), but my unfortunate experience is that
>> a lot of people who still consider mainframes to to be a worthwhile
>> platform are excessively- I'm tempted to say aggressively- defensive
>> when they engage with people who don't have significant exposure to
>> them. That sort of attitude is really no substitute for providing a
>> half-decent toolchain that people considering porting software from e.g.
>> z/Linux to z/OS can play with, and while I'm not suggesting that serious
>> developers would use VM/370 etc., making sure that they can get a bit of
>> hands on experience before raising their heads above the parapet has to
>> be to everybody's advantage.
>>
>> 'Dave Wade' ***@gmail.com [hercules-390] wrote:
>> >
>> > K&R C AKA the Portable C compiler existed on VM and is lost.
>> >
>> > GCCMVS allows REXX to be built on VM
>> >
>> > So these things existed and are lost.
>> >
>> > Dave
>> >
>> > *From:* hercules-***@yahoogroups.com [mailto:
>> hercules-***@yahoogroups.com]
>> > *Sent:* 16 October 2015 17:08
>> > *To:* hercules-***@yahoogroups.com
>> > *Subject:* Re: [hercules-390] Possibility of merging in Hercules 380
>> > extensions
>> >
>> >
>> > Hi All,
>> >
>> > I really don't want to get into the middle of a holy war, and this is
>> > possibly ignorance on my part, but I just don't get why any "normal"
>> > users would want the S/380 stuff. Then again most of my dabbling with
>> > Hercules has been on OS/360 for historical interest! :-)
>> >
>> > I can see why Paul would want to have done it in the first place maybe
>> > as a challenge and an academic exercise, but I just don't see the need
>> > to be able to compile large C programs on a historically non-existent
>> > platform/architecture.
>>
>> --
>> Mark Morgan Lloyd
>> markMLl .AT. telemetry.co .DOT. uk
>>
>> [Opinions above are the author's, not those of his employers or
>> colleagues]
>>
>
>
>
> --
> Robert AH Prins
> ***@gmail.com
>
>
>

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

> I can't talk from experience with the software,
> but I'd say: if the current developers/maintainers
> of the existing "branches" don't want to include
> this, I don't see any harm in a separate fork
> with the S380 functionality.

It means that people who want S380
functionality have to use an old version
of base Hercules, because no-one has
volunteered to merge the changes from
base Hercules since 3.07 into Hercules/380.

That's the only "harm" I see. I personally
am perfectly happy with 3.07, but others
are not. Not sure what others are doing
that I'm not.

BFN. Paul.

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

S/380 has advances in memory availability.
Allows GCC to recompile itself.
Wasn't Review being updated to use more memory for large files?

Turnkey 4- has bug fixes and enhancements.
Would be nice to have both in one download, instead of having to run
one or the other.

On Fri, Oct 16, 2015 at 4:18 PM, ***@yahoo.com.au
[hercules-390] <hercules-***@yahoogroups.com> wrote:
>> I can't talk from experience with the software,
>> but I'd say: if the current developers/maintainers
>> of the existing "branches" don't want to include
>> this, I don't see any harm in a separate fork
>> with the S380 functionality.
>
> It means that people who want S380
> functionality have to use an old version
> of base Hercules, because no-one has
> volunteered to merge the changes from
> base Hercules since 3.07 into Hercules/380.
>
> That's the only "harm" I see. I personally
> am perfectly happy with 3.07, but others
> are not. Not sure what others are doing
> that I'm not.
>
> BFN. Paul.
>
>
>
>
> ------------------------------------
> Posted by: ***@yahoo.com.au
> ------------------------------------
>
> 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
>
>
>



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

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

I think that it is ideal to have Tk4-, GCCMVS and MVS/380 integrated into a single release. This would attract more interest from many many newbies, and allowing Tk4- to be much more flexible and many interesting new applications to be made available. People ask why. Well, the address space extension by itself would appear to be useful for running more instances of MVS native software, and native MVS software that wont fit in a small address space. i dont think its just about running GCCMVS. The GCCMVS is an added benefit. The immense value of this is obvious, in synergy and improving ease of use and versatility. A synergy comes with Tk4- both being a retrocomputing experience but also practical for modern C programs at the same time . Yes of course there are other C development environments, but it really does introduce something new, the environment is a coupling of languages and the OS, and a coupling of C and Tk4- would be unique and novel. To ask why is like asking why you want tomato sauce on pizza when you can have it on spaghetti already. I dont see why we have anything to lose if it were integrated into Tk4- and is interested to us who would like to experiment with running C code on Tk4- . The software to do all of this is mostly already written anyway so its just putting the parts together. So yes its a great idea in my opinion.

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

> I think that it is ideal to have Tk4-, GCCMVS
> and MVS/380 integrated into a single release.

Well that's exactly what MVS/380 was,
until relatively recently. MVS/380 was
an extension of the TK3 line. In fact,
there might even be a version based
on an early version of TK4-.

The other thing that TK4- has is mods
to Hercules to get TCP/IP. Those mods
will probably be ported to Hercules/380
one day.

BFN. Paul.

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

There was an overlay for MVS/380 on Tk4- version 5 but it was not updated for Tk4- version 7.

[Neale Ferguson [e-mail] [hercules-390]]

I believe I have it somewhere. I'll take a look. 

-------- Original message --------
From: "Harold Grovesteen ***@tx.rr.com [hercules-390]" <hercules-***@yahoogroups.com>
Date: 2015/10/24 12:58 (GMT-05:00)
To: hercules-***@yahoogroups.com
Subject: [hercules-390] Open Solaris WAS: Possibility of merging in Hercules 380 extensions


 









On Sat, 2015-10-24 at 17:43 +0200, Ivan Warren ***@vmfacility.fr

[hercules-390] wrote:



> Is there still a "legal" repository of Open Solaris for z lying around -

> Or does the SUN (now Oracle) license prohibit it ?

>

> (Not that I'm willing to work on it... Just a simple question)

>

> --Ivan

>



Did some hunting and found



http://distribution.sinenomine.net/opensolaris/



https://en.wikipedia.org/wiki/OpenSolaris_for_System_z



The binary information is still available, if you know the link.

The source seems to have been available at www.opensolaris.org. But

that site no longer seems to exist. Maybe SNA or someone else has held

onto the source.



Harold Grovesteen

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

After putting forth the effort awhile back, I would certainly be
interested in a copy. It needs to be preserved someplace.

Harold


On Sat, 2015-10-24 at 13:02 -0400, Neale Ferguson
***@verizon.net [hercules-390] wrote:
>
>
> I believe I have it somewhere. I'll take a look.
>
> -------- Original message --------
> From: "Harold Grovesteen ***@tx.rr.com [hercules-390]"
> <hercules-***@yahoogroups.com>
> Date: 2015/10/24 12:58 (GMT-05:00)
> To: hercules-***@yahoogroups.com
> Subject: [hercules-390] Open Solaris WAS: Possibility of merging in
> Hercules 380 extensions
>
>
> On Sat, 2015-10-24 at 17:43 +0200, Ivan Warren ***@vmfacility.fr
> [hercules-390] wrote:
>
> > Is there still a "legal" repository of Open Solaris for z lying
> around -
> > Or does the SUN (now Oracle) license prohibit it ?
> >
> > (Not that I'm willing to work on it... Just a simple question)
> >
> > --Ivan
> >
>
> Did some hunting and found
>
> http://distribution.sinenomine.net/opensolaris/
>
> https://en.wikipedia.org/wiki/OpenSolaris_for_System_z
>
> The binary information is still available, if you know the link.
> The source seems to have been available at www.opensolaris.org. But
> that site no longer seems to exist. Maybe SNA or someone else has held
> onto the source.
>
> Harold Grovesteen
>
>
>
>
>
>
>

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

For those who are not aware, Neale Ferguson is with Sine Nomine
Associates. If anyone is likely to have a copy they are.

Harold


On Sat, 2015-10-24 at 18:24 +0000, Mark Morgan Lloyd
markmll.hercules-***@telemetry.co.uk [hercules-390] wrote:
> Harold Grovesteen ***@tx.rr.com [hercules-390] wrote:
> > After putting forth the effort awhile back, I would certainly be
> > interested in a copy. It needs to be preserved someplace.
> >
> > Harold
> >
> >
> > On Sat, 2015-10-24 at 13:02 -0400, Neale Ferguson
> > ***@verizon.net [hercules-390] wrote:
> >>
> >> I believe I have it somewhere. I'll take a look.
> >>
> >> -------- Original message --------
> >> From: "Harold Grovesteen ***@tx.rr.com [hercules-390]"
> >> <hercules-***@yahoogroups.com>
> >> Date: 2015/10/24 12:58 (GMT-05:00)
> >> To: hercules-***@yahoogroups.com
> >> Subject: [hercules-390] Open Solaris WAS: Possibility of merging in
> >> Hercules 380 extensions
> >>
> >>
> >> On Sat, 2015-10-24 at 17:43 +0200, Ivan Warren ***@vmfacility.fr
> >> [hercules-390] wrote:
> >>
> >>> Is there still a "legal" repository of Open Solaris for z lying
> >> around -
> >>> Or does the SUN (now Oracle) license prohibit it ?
> >>>
> >>> (Not that I'm willing to work on it... Just a simple question)
> >>>
> >>> --Ivan
>
> I noticed some stuff relating to the SPARC port at archive.org earlier
> in the day, and am currently DLing it since it's disappeared from the
> original site (opensxce.org). I'm not hopeful that it will contain
> anything other than SPARC, it's only 4Gb.
>
> >> Did some hunting and found
> >>
> >> http://distribution.sinenomine.net/opensolaris/
> >>
> >> https://en.wikipedia.org/wiki/OpenSolaris_for_System_z
> >>
> >> The binary information is still available, if you know the link.
> >> The source seems to have been available at www.opensolaris.org. But
>
> Archive.org appear to have a list of mailing list archives, but I can't
> see any content. If you knew directory names etc. you might have more luck.
>
> >> that site no longer seems to exist. Maybe SNA or someone else has held
> >> onto the source.
>
> By the looks of it SNA had used a robots.txt file so there's either
> nothing at archive.org, or they're not making it available per SOP. I
> don't know whether there would be any mileage in approaching archive.org
> and asking whether they have [identifiable files] which were at one
> point available under an open source license, "not so much because you
> wanted to lean on them but to make sure that somebody has them in safe
> keeping".
>

[Laddie Hanus [e-mail] [hercules-390]]

--------------------------------------------
On Sat, 10/24/15, 'Shelby Beach' ***@comcast.net [hercules-390] <hercules-***@yahoogroups.com> wrote:

Subject: RE: [hercules-390] Possibility of merging in Hercules 380 extensions
To: hercules-***@yahoogroups.com
Date: Saturday, October 24, 2015, 5:48 PM



Well of course both are possible... IBM did it !!!
Now then, we've got the

source. Maybe there should be more douin' and less
complainin' :-) !



Shelby



<snipped a lot>

________________________________


We do not have MVS source. We have the output of the PL/S compiler which is generated assembler for the most part. Also most of the comments are stripped out especially the prologs at the start of the module. If you have access to the old microfiche you will see what I mean. There are some logic manuals but no System initialization logic or IOS logic.

When this whole 380 business started I started looking at the source that came with TK3 majority of it was PL/S output which was (is) a PL/1 like language that puts out assembler statements. The main issue is that PL/S expanded all the macros and the offsets are hard coded in the generated assembler code. So lets say I want to change the page table macro (IHAPGTE) I change the 2 byte table entry to 4. Only problem is when you assemble the 20+ modules that actually update the table none of them will see your macro change. Also the source is way down level from the running system. Its basicallly a 3.7 system. So unless you reassemble everything (and there are a few missing pieces) change 1 module and you run into issues with other modules that dont match. And then the problem of SYS1.Maclilb/amodgen/agenlib at a newer level than the source..

Updating the source to TK3 level is doable with disassemblers and such but just IEAVNIP0 took about 2 months of spare time. Then there's the time to change all those hardcoded offsets in using statements and adding the field names into the instructions. Eventually I got it to load 31 bit segment table and page tables but it program checked first time it took a pagefault as now VSM/RSM and ASM needed to be upated. Go to bitsavers and get volume 5 of the os/vs2 system logic library and size that mess.

It took IBM from the mid 70's to about 1982 to produce MVS/XA (source Melinda Varian's VM and the VM Community: Past, Present, and Future) and they had the original source and the compiler and all the logic manuals. Ms Varian has a website with the paper and it is a very interesting read for this interested in the history.

VM would be easier as the source matches the running system but it would take a lot of work to change it to use the SIE instruction. I actually at one time thought about running MVS under a hypervisor using SIE and intercepting all the paging but decided it was too much work.


Theres a lot of people that want this but very few who are willing to contribute. Even I have grown tired of it as StorageTek/Sun/Oracle have laid off almost everyone I have worked with and not cut the projects back.Last thing I feel like doing when I get home is working on an old MVS. When I retire in a few years I plan on getting back to it.It seems that the thing to do is steal a copy of z/OS so whats the point of investing so much time in updating MVS?

In reference to

>milnser43200
>Today at 2:15 PM
>It seems as though a desirable goal of the whole thing would be to expand the address space for Turnkey MVS to use, whether this is done through MVS/380 or what have you. >One desirable benefit of that is to be able to run more native language MVS programs in parallel and to run larger native language programs. In addition to that, GCC is an another >benefit. This would increase the versatility for many hobbyist users. Since 31 and 64 bit CPU extensions already exist, what was the rationale for creating Hercules//380 fork rather > than just added some backwards compatable extensions to Turnkey MVS to support the existing 31 and 64 bit IBM extensions?

The original desire for all this was to be able to build the GCC compiler under MVS The 8-9 MB private space was insufficient. Addling the ability to TK3 as he did was the quickest and simplest. Paul has not shown any interest in to fitting it to anything newer than 3.07 and I don't blame him It works for him. Some of his newer ideas seem strange but then there is a lot more to z/OS than just getting large chunks of storage

Laddie Hanus

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

On 24 October 2015 at 21:22, Laddie Hanus ***@yahoo.com wrote:
> It took IBM from the mid 70's to about 1982 to produce MVS/XA (source Melinda Varian's VM and the VM Community: Past, Present, and Future) and they had the original source and the compiler and all the logic manuals. Ms Varian has a website with the paper and it is a very interesting read for this interested in the history.

Well to be fair, IBM also had to produce the hardware. And (as Melinda
and Lynn Wheeler have mentioned), the hardware engineers tend to live
in a different world from the software guys.

I've thought for a long long time (and said so here) that getting a
working PL/S compiler is the real key to all this. And that compiler
needs to generate a different kind of assembler source; one that
relies on the assembler to resolve names rather than, as you point
out, converting PL/S constants into generated absolute numbers and
offsets.

In about 1979 I started to write a PL/S compiler using the macro
facilities of ASMH. It got to the point where I could parse the source
and dump out a syntax tree, and generate macro invocations.

Well this is a pretty stupid approach; I was more just playing with
the ASMH facilities than doing anything real. But it remains true that
PL/S language is fairly well defined, and is really quite small
compared to, say, PL/I. I am not the only person to try to write a
PL/S compiler. Notoriously around 1976 or 77 the Rand Corporation
actually produced and announced a product called RL/S, and were only
stopped when IBM's lawyers got involved. I had tried to order their
compiler, and got a letter saying things were on hold until the
situation was resolved, and that's the last I heard from them.

I know another person who started his own PL/S project, and he
concluded that although there was (still is) lots and lots of example
MVS code in PL/S, the difficult part was the missing maclibs and the
actual definition of the macro language.

And of course IBM did make PLX/370 (the 1990s version of PL/S)
available to ISVs. I tried to order it, and it turns out I had missed
the boat by about a month. :-( However there are still ISVs with a
legitimate copy, and I think this is important because there could be
help there when difficult questions of the language definition arise.
There is also a fair bit of sample (non-IBM) code written for the
PLX/370 compiler out there, notably on IBM's VM Downloads page.

Not surprisingly Melinda had some things to say about PL/S in the
paper you mention; most of them not very positive, but that was in the
context of the OCO wars where PL/S was seen as an inherent part of the
problem.

Anyway - I suppose I'm another person without the time to work on this
until retirement, and that's still a few years off.

Tony H.

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

Hi Laddie.

> Paul has not shown any interest in to fitting
> it to anything newer than 3.07 and I don't
> blame him It works for him. Some of his
> newer ideas seem strange but then
> there is a lot more to z/OS than just
> getting large chunks of storage

I'm not trying to be annoying, but can
you tell me what "newer ideas" you
are talking about? And do they merely
"sound" strange or are they genuinely
strange? Maybe I can either elaborate
or adjust?

Thanks. Paul.





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

--------------------------------------------
On Sat, 10/24/15, 'Shelby Beach' ***@... mailto:***@... [hercules-390] <hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com> wrote:

Subject: RE: [hercules-390] Possibility of merging in Hercules 380 extensions
To: hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com
Date: Saturday, October 24, 2015, 5:48 PM



Well of course both are possible... IBM did it !!!
Now then, we've got the

source. Maybe there should be more douin' and less
complainin' :-) !



Shelby



<snipped a lot>

________________________________


We do not have MVS source. We have the output of the PL/S compiler which is generated assembler for the most part. Also most of the comments are stripped out especially the prologs at the start of the module. If you have access to the old microfiche you will see what I mean. There are some logic manuals but no System initialization logic or IOS logic.

When this whole 380 business started I started looking at the source that came with TK3 majority of it was PL/S output which was (is) a PL/1 like language that puts out assembler statements. The main issue is that PL/S expanded all the macros and the offsets are hard coded in the generated assembler code. So lets say I want to change the page table macro (IHAPGTE) I change the 2 byte table entry to 4. Only problem is when you assemble the 20+ modules that actually update the table none of them will see your macro change. Also the source is way down level from the running system. Its basicallly a 3.7 system. So unless you reassemble everything (and there are a few missing pieces) change 1 module and you run into issues with other modules that dont match. And then the problem of SYS1.Maclilb/amodgen/agenlib at a newer level than the source..

Updating the source to TK3 level is doable with disassemblers and such but just IEAVNIP0 took about 2 months of spare time. Then there's the time to change all those hardcoded offsets in using statements and adding the field names into the instructions. Eventually I got it to load 31 bit segment table and page tables but it program checked first time it took a pagefault as now VSM/RSM and ASM needed to be upated. Go to bitsavers and get volume 5 of the os/vs2 system logic library and size that mess.

It took IBM from the mid 70's to about 1982 to produce MVS/XA (source Melinda Varian's VM and the VM Community: Past, Present, and Future) and they had the original source and the compiler and all the logic manuals. Ms Varian has a website with the paper and it is a very interesting read for this interested in the history.

VM would be easier as the source matches the running system but it would take a lot of work to change it to use the SIE instruction. I actually at one time thought about running MVS under a hypervisor using SIE and intercepting all the paging but decided it was too much work.


Theres a lot of people that want this but very few who are willing to contribute. Even I have grown tired of it as StorageTek/Sun/Oracle have laid off almost everyone I have worked with and not cut the projects back.Last thing I feel like doing when I get home is working on an old MVS. When I retire in a few years I plan on getting back to it.It seems that the thing to do is steal a copy of z/OS so whats the point of investing so much time in updating MVS?

In reference to

>milnser43200
>Today at 2:15 PM
>It seems as though a desirable goal of the whole thing would be to expand the address space for Turnkey MVS to use, whether this is done through MVS/380 or what have you. >One desirable benefit of that is to be able to run more native language MVS programs in parallel and to run larger native language programs. In addition to that, GCC is an another >benefit. This would increase the versatility for many hobbyist users. Since 31 and 64 bit CPU extensions already exist, what was the rationale for creating Hercules//380 fork rather > than just added some backwards compatable extensions to Turnkey MVS to support the existing 31 and 64 bit IBM extensions?

The original desire for all this was to be able to build the GCC compiler under MVS The 8-9 MB private space was insufficient. Addling the ability to TK3 as he did was the quickest and simplest. Paul has not shown any interest in to fitting it to anything newer than 3.07 and I don't blame him It works for him. Some of his newer ideas seem strange but then there is a lot more to z/OS than just getting large chunks of storage

Laddie Hanus

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

>>milnser43200
>>"It seems as though a desirable goal of the whole thing would be to expand the address space for Turnkey MVS to use, whether this is done through MVS/380 or what have you. >One desirable benefit of that is to be able to run more native language MVS programs in parallel and to run larger native language programs. In addition to that, GCC is an another >benefit. This would increase the versatility for many hobbyist users. Since 31 and 64 bit CPU extensions already exist, what was the rationale for creating Hercules//380 fork rather > than just added some backwards compatable extensions to Turnkey MVS to support the existing 31 and 64 bit IBM extensions?"

> Laaddie wrote:
> "The original desire for all this was to be able to build the GCC compiler under MVS The 8-9 MB private space was insufficient. Addling the ability to TK3 as he did was the quickest and simplest. Paul has not shown any interest in to fitting it to anything newer than 3.07 and I don't blame him It works for him. Some of his newer ideas seem strange but then there is a lot more to z/OS than just getting large chunks of storage"

Almost all of GCC 3.2.3 compiles under MVS 3.8j with increased private area ( 11MB or so ). It does, IIRC, compile compeletly under VM/370 as more 'private' memory is available. If he has modified the build procedure from when I was creating the load modules it may take more now. For all the hooplah about compiling large C programs, I personally have not encountered any other than about 4 in the GCC compiler which wouldn't compile under 3.8j. This might have been a design consideration when Paul and I were working on the port as IIRC everything is stored in memory instead of having a disk work area for expansion of the C source and whatever else it might need work space for.

Paul created patches to Hercules 3.07 but hasn't shown any interest in keeping them current to applicable Hercules release levels since then ( other than his recently stated desire for Juergen's TCP/IP inclusion).

Perhaps 'strange' is the noise about help/usage messages out of batch utilities like IEBCOPY or IEBGENER .

Running more native language MVS programs on MVS 3.8j in parallel is more limited by number of initiators, not necessarily amount of memory as each program gets it's own Virtual Storage. Started task and initiators themselves do take up physical memory but that is what might limit a single 'larger native' programs to run.

Gerhard mentioned Tachyon assembler IIRC not having enough memory under 3.8j and I wondered if z390 executable environment would permit it to run.

And if you really want to compile large C programs without any memory constraints, use the cross compilers available for windows or linux to create the large assembly language program GCC would create on the mainframe anyway without as much time lapse in the compile. How do you think GCC got ported to MVS in the 1st place !

Phil

ps - I don't have much time for this these days either