[hercules-390] Re: Latest Version of Hercules

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

Hello!
Oh certainly.
It is the oldest continuously active distribution on the planet. It
predates even Red Hat and Debian.

Even a specialist at the lizard shop of SuSe happens to be a user of
Slackware. He maintains the Slack390 port in what remains of his free
time. (I suggested it.)
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."

Slackware ! Now that sure brings back memories. So that is still around ?
-----
I'm sorry Dave, I'm afraid I can't do that
-----

Hello!
And for Slackware its even more complicated. One outfit has taken it
upon itself to laboriously supply build methods for practically every
package one would want. All for the later releases.
For Hercules on a 13.37 system, I simply snagged the build blob and
extracted it, and installed the appropriate release inside it. Running
the build script produced the binary one needed or myself in this
case.
To install it, one simply entered at a root prompt, "#installpkg
-infobox hercules<release number>.txz where that command reads the
package and extracts the compressed tar file inside and tells the
operating system about it.
Obviously the Debian builder who is supposed to package a 3.11 one for
both regular Debian and the one for the Raspberry Pi has not been
keeping up. Or has he? Raspian recently got bumped up to the later
release that Debian has out and theoretically it should be there.
-----
By the way Dave W, what is that thing in your garden that looks like a statue?
-----
"This signature fought the Time Wars, time and again."

Generally the package maintainers of whatever Linux you are using (I.e. Debian, Fedora, Ubuntu, etc) builds the packages for that distribution.
Distrowatch.com shows 762 Linux distributions. While many are variations of other distributions it's too much for one person or small group. People volunteer their time to work on Hercules
Laddie Hanus
Sent from my iPhone
A rose by any other name ...
Hercules Version 3.07
(c)Copyright 1999-2010 by Roger Bowler, Jan Jaeger, and others
Built on Jul 24 2012 at 18:18:24

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

Strictly speaking, no it doesn't matter which "version".


The only things that matter to me are (naturally) that 1, the fix I need is in there, and 2, the particular Hercules version that has it has been deemed stable enough for general use. In the past, that has always meant to go with the "official" releases on Hercules-390.eu, where one can find 3.11 right now.


However, since Hercules developments are evidently not "united" at this time, I have steered clear of the various development versions, because I am not close to that process and don't understand what's going on with them, and there doesn't seem to be any official place to go to determine if a given release is worth using or not. Finally, I have no great interest in building Hercules. I just want to download it and use it. For me, building is just too much trouble, and I can't rely on the results. No offense meant, but that's just how I see it.

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

.c8iii8  1 v


Sent from my Verizon Wireless 4G LTE smartphone-------- Original message --------From: "'John P. Hartmann' ***@gmail.com [hercules-390]" <hercules-***@yahoogroups.com> Date: 11/15/2015 10:49 AM (GMT-06:00) To: hercules-***@yahoogroups.com Subject: Re: [hercules-390] Re: Latest Version of Hercules

 









No, it clearly isn't. I hope Mark will bail me out.

I fixed the mainsize bug. If you don't want to build Hyperion, specify
B, e.g., mainsize 65535b

Umm...it looks like you have changed the meaning of MAINSIZE 65536 from
64GB to 64KB.
I don't think this is going to fix his problem.
Roger

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

It's stated several messages back, but briefly when MAINSIZE is specified greater than 65535 (mb, that is, 64 GB), an IPL fails with a wait state. If just 65535 is used, IPL is normal. I have to conclude there is a bug in the code that processes the MAINSIZE numeric parameter, and that bug somehow causes this crash.

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

It is regrettable that I believed that there was an error from your
misconceptions, where there clearly was none.

Post by ***@yahoo.com [hercules-390]
It's stated several messages back, but briefly when MAINSIZE is
specified greater than 65535 (mb, that is, 64 GB), an IPL fails with a
wait state. If just 65535 is used, IPL is normal. I have to conclude
there is a bug in the code that processes the MAINSIZE numeric
parameter, and that bug somehow causes this crash.

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

Post by ***@yahoo.com [hercules-390]
It's stated several messages back, but briefly when
MAINSIZE is specified greater than 65535 (mb, that is,
64 GB), an IPL fails with a wait state. If just 65535
is used, IPL is normal. I have to conclude there is
a bug in the code that processes the MAINSIZE numeric
parameter, and that bug somehow causes this crash.

I already have the fix for this (and sent it to Roger too) but have not committed it to Hyperion yet as the initial effort has morphed into a much larger effort than originally anticipated.

Not everyone has such a monster box like you do that they can easily test their changes on.

Patience please!

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

FYI I do hope there will be a fix to this. Eventually
I would like to try a MAINSIZE of 96 GB, and so removing
this artificial 64 GB size barrier is important to me.

I already have the fix for this (and sent it to Roger too) but have not committed it to Hyperion yet as the initial effort has morphed into a much larger effort than originally anticipated.

Not everyone has such a monster box like you do that they can easily test their changes on.

Patience please.

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

OK, I will be patient. I am happy that the issue was found, so eventually the fix will see the light of day.


P.S. It was only recently that the technology was even available to make a (non-server) machine with this much memory. It's a Core I-7 X99 Asus motherboard with 128 GB of G-Skill memory. The bios that allowed this much memory to be installed only was available as of a few months ago, as was getting any memory that was QVL'd for the board. I have been planning this system for a year, and just finished the build a few weeks ago. I am looking forward to exploiting all this technology, so be assured your efforts are appreciated. I am able to run 5 engines, although I have no mainframe work that could utilize all that at the moment. One thing at a time ...


BTW, I see where you can specify the "kind" of engine Hercules emulates, where CP means central processor. I have not seen any Hercules documentation to explain what the other processor types mean or what they are used for. Could you or someone explain this? Is there any need or reason to configure Hercules with any type of engine(s) besides CP?

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

***@yahoo.com asked:

[...]

Post by ***@yahoo.com [hercules-390]
BTW, I see where you can specify the "kind" of engine
Hercules emulates, where CP means central processor.
I have not seen any Hercules documentation to explain
what the other processor types mean or what they are
used for.

And it's likely you never will either as it is not documented on purpose.

Post by ***@yahoo.com [hercules-390]
Could you or someone explain this?

Nope. :)

Post by ***@yahoo.com [hercules-390]
Is there any need or reason to configure Hercules with
any type of engine(s) besides CP?

If you don't know or can't figure out what the engine types are or their purpose then you don't need to be specifying anything other than CP.

Sorry to be that way.

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

zIIPs, zAAPs, and zIFLs. Contact IBM for differences (NDA, $$,$$$
required). No emulator differences.

On Mon, Nov 16, 2015 at 9:36 PM, ''Fish' (David B. Trout)'

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

Post by ***@yahoo.com [hercules-390]
BTW, I see where you can specify the "kind" of engine
Hercules emulates, where CP means central processor.
I have not seen any Hercules documentation to explain
what the other processor types mean or what they are
used for.

And it's likely you never will either as it is not documented on purpose.

Post by ***@yahoo.com [hercules-390]
Could you or someone explain this?

Nope. :)

Post by ***@yahoo.com [hercules-390]
Is there any need or reason to configure Hercules with
any type of engine(s) besides CP?

If you don't know or can't figure out what the engine types are or their purpose then you don't need to be specifying anything other than CP.
Sorry to be that way.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

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

Post by ***@yahoo.com [hercules-390]
BTW, I see where you can specify the "kind" of engine Hercules emulates,
where CP means central processor. I have not seen any Hercules
documentation to explain what the other processor types mean or what they
are used for. Could you or someone explain this? Is there any need or
reason to configure Hercules with any type of engine(s) besides CP?

IBM doesn't document exactly how the engine types differ, but someone
figured it out and Hercules implements something compatible for some engine
types. On real IBM iron, the engine types are priced differently, there are
limits on how many of which type of engine you can configure on a given
machine, the non-CP engines always run at full speed (CPs may artificially
run slower on the cheaper machines), and of course IBM has licensing
requirements that differ by engine type. To some extent these IBM
requirements are enforced by "technological measures" (for example z/OS
won't IPL on an IFL engine). But on Hercules there is no reasonable case
for specifying anything other than CP.

For e.g. zLinux it makes no difference what kind of Hercules engine you run
on.

Tony H.

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

That's all I was really trying to get at. It would have been helpful if the Hercules documentation just said in plain English, "On Hercules there is no reasonable case for specifying anything other than CP." In addition, because it's not documented, us users have no way of knowing whether an ENGINE of type IP or AP is in any way different from a zIIP or zAAP processor, since they don't tell us what they did to implement an engine of type IP or AP. That is, I may have read the IBM documentation, and I may have concluded that an AP engine in Hercules is supposed to be an emulated zAAP processor, but what did the Hercules developers do to make an AP engine what it is? The Hercules developers won't tell me. What's the big secret?


What I gather from the IBM docs is that the various engine types are basically a marketing ploy, so that if they are used in some restricted roles, IBM charges their customers less money. (The engines dedicated to running Java or maybe Windows - I think there was an x86 or x64 engine type they supported at one time - might be a different case.)


Perhaps a very few people might need the other types, but I believe it would be helpful if the documentation said something like this: "Unless you have very specific technical requirements, most Hercules systems will only need engines of type CP." You know, a simple explanation in plain English to help out us lowly users?

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

RMF can monitor your recent z/OS 1.x+ system and calculate how much of your
workload did run on different processor types, and how much was eligible.

Post by ***@yahoo.com [hercules-390]
That's all I was really trying to get at. It would have been helpful if
the Hercules documentation just said in plain English, "On Hercules there
is no reasonable case for specifying anything other than CP." In
addition, because it's not documented, us users have no way of knowing
whether an ENGINE of type IP or AP is in any way different from a zIIP or
zAAP processor, since they don't tell us what they did to implement an
engine of type IP or AP. That is, I may have read the IBM documentation,
and I may have concluded that an AP engine in Hercules is supposed to be an
emulated zAAP processor, but what did the Hercules developers do to make an
AP engine what it is? The Hercules developers won't tell me. What's the
big secret?
What I gather from the IBM docs is that the various engine types are
basically a marketing ploy, so that if they are used in some restricted
roles, IBM charges their customers less money. (The engines dedicated to
running Java or maybe Windows - I think there was an x86 or x64 engine type
they supported at one time - might be a different case.)
Perhaps a very few people might need the other types, but I believe it
would be helpful if the documentation said something like this: "Unless you
have very specific technical requirements, most Hercules systems will only
need engines of type CP." You know, a simple explanation in plain English
to help out us lowly users?

[Drew Derbyshire [e-mail] [hercules-390]]

The original 360 processors had a wide range of performance, the fastest
was 200 times faster than the low end processor. The high end coast
more to build, too.

Short version of performance numbers:
http://www.jcmit.com/cpu-performance.htm

IBM Comic book version of the models through years:
http://www.vm.ibm.com/devpages/jelliott/pdfs/zhistory.pdf; pages 17, 24,
25, and 30 list the models through the years.

For a more detailed look at central processor levels see "IBM 360 and
Early 370 Systems" by Pugh, Johnson, and Palmer, from 1991. It gives the
historical background to the IBM S/360 environment, and how the systems
met their different price points. For example, all the machines below
(I think) the Model 65 were microcode engine based machined, where as
the 65 and up used faster hard code logic.

And there various hacks they did, for example the late 1970's IBM 3033
was basically a reengineered S/370 168 with a model 158 (or 2) bolted to
it to provide dedicated I/O support.) See
https://groups.google.com/forum/#!msg/alt.folklore.computers/bO0cwjQ2MLU/4643Njhu_P4J

It really comes down to it really /is/ expensive to build a fast system
(processor, memory, I/O subsystems, peripheral), even today. And yes,
some systems are internally governed low to provide a lower entry price
point, either for the hardware or software.

-ahd-

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

You got that one wrong, despite advertising the volume that would have
told you otherwise.

For example, all the machines below (I think) the Model 65 were
microcode engine based machined, where as the 65 and up used faster hard
code logic.

[Drew Derbyshire [e-mail] [hercules-390]]

Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
You got that one wrong, despite advertising the volume that would have
told you otherwise.

For example, all the machines below (I think) the Model 65 were
microcode engine based machined, where as the 65 and up used faster hard
code logic.

I bad. I think.

I just had the Pugh book open on the desk in fact. Keep mind, I only
read fully it when it was new. :-)

Basically I miscounted down the largest model. I just peeked, the two
largest were originally supposed to be hardcoded.

I think the 62 (which was the original 65, before it got faster) was
supposed to be hardcoded, but they got microinstructions running faster
in time. But translating from code names to final product models used
this book is a pain in the butt, so I could still have an off-by-one error.

And Penwiper, all 11 pounds of purring fluffy blacknesss of him, says I
need to stop read and start petting. So I guess I can't verify my
correction. (He almost just turned off this monitor. He's gooood.)

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

Perhaps he should.

Post by Drew Derbyshire ***@kew.com [hercules-390]
He almost just turned off this monitor

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

I don’t believe they have any differences, other than the way the report and the way they are charged. You used to be able to run zOS on an IFL for an additional fee. There have been some court cases about software which could offload MVS work to run on an IFL or JAVA CPU. It is really a way for IBM to charge a different amount (i.e. a lot more) for those folks who still need to run an MVS compatible OS 




Dave



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: 17 November 2015 17:37
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-390] Re: Latest Version of Hercules








On 16 November 2015 at 21:32, ***@yahoo.com <mailto:***@yahoo.com> wrote:

BTW, I see where you can specify the "kind" of engine Hercules emulates, where CP means central processor. I have not seen any Hercules documentation to explain what the other processor types mean or what they are used for. Could you or someone explain this? Is there any need or reason to configure Hercules with any type of engine(s) besides CP?



IBM doesn't document exactly how the engine types differ, but someone figured it out and Hercules implements something compatible for some engine types. On real IBM iron, the engine types are priced differently, there are limits on how many of which type of engine you can configure on a given machine, the non-CP engines always run at full speed (CPs may artificially run slower on the cheaper machines), and of course IBM has licensing requirements that differ by engine type. To some extent these IBM requirements are enforced by "technological measures" (for example z/OS won't IPL on an IFL engine). But on Hercules there is no reasonable case for specifying anything other than CP.

For e.g. zLinux it makes no difference what kind of Hercules engine you run on.



Tony H.

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

The plot thickens...

Why do You think so ???


no plot at all

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

Hi,

Post by ***@alice.it [hercules-390]

The plot thickens...

Why do You think so ???
no plot at all

Just kidding.

Post by ***@alice.it [hercules-390]

Ah. That explains why googling for that term doesnt turn up any relevant

hits. I already got the (false ?) impression that Hyperion, in it's
inception, was meant to be the development sandbox for a new Hercules 3.x+
version, but that over time, it turned into a new version all of its own,
turning into a genuine fork, even though that may not have been its
original intent.

Post by ***@alice.it [hercules-390]
I'd say that is quite a good assessment of the situation.
Roger
Nope it was not a fork ...
once upon a time the github repository was f*** up
and the infrastructure was poorly defined ( just one administrator)
since I had a GOOD copy of the repository at that time I defined a better

environment

Post by ***@alice.it [hercules-390]
( more than one administrator )
and since there was a bit of confusion in the naming
at that time there were a sandhawk, a spinhawk, a goldhawk
so after a quick poll we decided about the new codename Hyperion
so no fork just a clear cut from the old names.
cheers
enrico

... But open a second read, I guess these two match up perfectly.



- Maarten.

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

Hi,

Post by ***@alice.it [hercules-390]

The plot thickens...

Why do You think so ???
no plot at all

IMHO, it is in effect a fork (although the licensing of hercules doesn't
allow it ( but that's not very important)).

you have "hyperion" on one side and "spinhawk" on the other side... So
yes - it IS a fork.

On one hand you have a completely unstable version - but which DOES
implement (or tries to) new features and new functionalities
On the other hand you have a stable - but which isn't moving very much.
But it works (and quite well)...

And it is a fork because it is different people who make changes to the
various versions.

Is it possible to re-unite the 2 versions ? I'm sure it is possible
(after all gcc and egcs did manage to do it - and it was a far more
complex project at the time).

But it will require some coordination.

--Ivan


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

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

IMHO, it would benefit everyone if these two versions were united. Having multiple versions of code never ends up well. The best thing for the development effort, and for the users, and for the developers, would be to have just one development version, and have all developers being united in working on it together. I understand that, for whatever reason, differences have arisen between various people. For the good of everyone, I wish that these differences could be set aside for the common good.

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

Rather than a Fork consider the 3.xx code as "stable" and 4.xx as
development. It really is a major change and critical fixes get merged back
into 3.xx. I hope at some point 4.xx will become release quality...

Post by ***@yahoo.com [hercules-390]
IMHO, it would benefit everyone if these two versions were united. Having
multiple versions of code never ends up well. The best thing for the
development effort, and for the users, and for the developers, would be to
have just one development version, and have all developers being united in
working on it together. I understand that, for whatever reason,
differences have arisen between various people. For the good of everyone,
I wish that these differences could be set aside for the common good.

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

Post by Dave Wade ***@gmail.com [hercules-390]
Rather than a Fork consider the 3.xx code as "stable" and 4.xx as
development.

If there are two separate git repos people are going to consider one a fork
of the other. If one isn't a fork of the other the code should be in a
single git repo with stable and development code in separate branches.

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

If one isn't a fork of the other the code should be in a single git repo
with stable and development code in separate branches.

That might not have been the best wording. What I probably should have said
was that if there is no fork involved most people these days would expect
all the code to be in a single repository with stable and development code
in separate branches. It's so common to fork projects on github these days
that many people seeing two separate Hercules repos will assUme one is a
fork of the other.

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

Hi,

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
IMHO, it is in effect a fork (although the licensing of hercules doesn't

allow it ( but that's not very important)).
Well this certainly got my attention. Although I don't claim to be any kind
of expert when it comes to licenses, I have in personal experience seen a
lot of misunderstandings related to licenses.

Where in the Q Public License does it state or imply that you cannot do so
? As far as I can tell, it even explicitly states that you may make
modifications to the software and distribute those modifications.

http://www.hercules-390.eu/herclic.html



- Maarten

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

It only allows separate patchs, see para 3. This is why the 380 mods are a
patch.

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

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
IMHO, it is in effect a fork (although the licensing of hercules doesn't

allow it ( but that's not very important)).
Well this certainly got my attention. Although I don't claim to be any
kind of expert when it comes to licenses, I have in personal experience
seen a lot of misunderstandings related to licenses.
Where in the Q Public License does it state or imply that you cannot do so
? As far as I can tell, it even explicitly states that you may make
modifications to the software and distribute those modifications.
http://www.hercules-390.eu/herclic.html
- Maarten

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

Hi,


patches only ? initial gut response: now that's just being silly.


re-reading the license again:

4.) states that: you may distribute machine-executable forms of modified
versions of the Software, provided that: all recipients are also able to
receive the complete machine-readable source code to the distributed
Software, including all modifications.


Which I choose to interpret as: once you distribute binaries based on
modified sources, you are required to also distribute the original source
including the modifications, instead of 'just patches'.


This license seems to contradict itself, or even if it doesn't, seems to
leave open much too interpretation.


Lawyers are going to have a field day with this license.
;-)



- Maarten

Post by Dave Wade ***@gmail.com [hercules-390]
It only allows separate patchs, see para 3. This is why the 380 mods are a
patch.

Hi,

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
IMHO, it is in effect a fork (although the licensing of hercules

doesn't allow it ( but that's not very important)).
Well this certainly got my attention. Although I don't claim to be any
kind of expert when it comes to licenses, I have in personal experience
seen a lot of misunderstandings related to licenses.
Where in the Q Public License does it state or imply that you cannot do
so ? As far as I can tell, it even explicitly states that you may make
modifications to the software and distribute those modifications.
http://www.hercules-390.eu/herclic.html
- Maarten

[R P Herrold [e-mail] [hercules-390]]

Post by Maarten Hoes ***@gmail.com [hercules-390]
4.) states that: you may distribute machine-executable forms of modified
versions of the Software, provided that: all recipients are also able to
receive the complete machine-readable source code to the distributed
Software, including all modifications.
Which I choose to interpret as: once you distribute binaries based on
modified sources, you are required to also distribute the original source
including the modifications, instead of 'just patches'.

Nothng beats a good knock-down lawsuit (NOT)

Certainly the practice and text of GPLv2 and GPLv3, is that
patches are insufficient, and that the entire source tree (and
more) need to be made available upon request

This is because a diff / patch set alone based against a third
party 'point in time' sources may have said 'complete sources'
upon which it relies ... disappear, and so end up useless

QPL para 2 seems to require full sources be made available,
anyway, for each subsequent receiver. 3 is just for addons
against a sources set previously required to be made available

No field day there, it would seem

-- Russ herrold

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

Hi,

Post by R P Herrold ***@owlriver.com [hercules-390]
No field day there, it would seem
-- Russ herrold

... just a disagreement of whether a genuine 'for' is allowed or not.


- Maarten

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

Please, children. None of you are lawyers. Don't try to be one.

Post by R P Herrold ***@owlriver.com [hercules-390]

Post by Maarten Hoes ***@gmail.com [hercules-390]
4.) states that: you may distribute machine-executable forms of modified
versions of the Software, provided that: all recipients are also able to
receive the complete machine-readable source code to the distributed
Software, including all modifications.
Which I choose to interpret as: once you distribute binaries based on
modified sources, you are required to also distribute the original source
including the modifications, instead of 'just patches'.

Nothng beats a good knock-down lawsuit (NOT)
Certainly the practice and text of GPLv2 and GPLv3, is that
patches are insufficient, and that the entire source tree (and
more) need to be made available upon request
This is because a diff / patch set alone based against a third
party 'point in time' sources may have said 'complete sources'
upon which it relies ... disappear, and so end up useless
QPL para 2 seems to require full sources be made available,
anyway, for each subsequent receiver. 3 is just for addons
against a sources set previously required to be made available
No field day there, it would seem
-- Russ herrold

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

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

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/

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

Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
Please, children. None of you are lawyers. Don't try to be one.

Hey! I was just making inquires about the statement that a fork of the
Hercules code isnt allowed by the license. And, and ... Oh, well, nevermind
....

[R P Herrold [e-mail] [hercules-390]]

Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
Please, children. None of you are lawyers. Don't try to be one.

ummm

---------------start disclaimer-------------------

I_A_AL, but not your lawyer. I offer legal advice and formal
opinion only within the confines of a previously established
and explicit attorney-client relationship where privilege may
be had; and NEVER on a public list server.

----------------end disclaimers ------------------

-- Russ herrold

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

Yes, but did you remember to do a 'make check' ?
;-)

$ make check
<-snip->
Test Prefix register and real/absolute storage set/display. 9 OK
compares. One failure.
<-snip->
Done 136 tests. 1 failed; 135 OK.
Makefile:2621: recipe for target 'check' failed
make: *** [check] Error 1

Me? I simply fixed a bug in whoever has been hacking at mainsize's
magnum opus. You could no longer specify the mainsize in bytes. But
all other hi'felutin' stuff like exabytes.

Have you introduced yet another change that isn't with previous behavior

?

--Ivan

I fixed the mainsize bug. If you don't want to build Hyperion, specify
B, e.g., mainsize 65535b
On 11/15/2015 09:08 AM, ''Fish' (David B. Trout)'

Which developments am I interested in? Well, all of them.
But to keep it simple, the correction to the MAINSIZE bug
is the one I need right now.

I'm working on it for Hyperion.
You can help some by creating the github issue for it so I don't have
to. I'll post my findings there.
Thanks.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com

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

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

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

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

*compatible*... Sorry missed a word

Have you introduced yet another change that isn't with previous behavior ?
--Ivan

I fixed the mainsize bug. If you don't want to build Hyperion, specify
B, e.g., mainsize 65535b
On 11/15/2015 09:08 AM, ''Fish' (David B. Trout)'

Which developments am I interested in? Well, all of them.
But to keep it simple, the correction to the MAINSIZE bug
is the one I need right now.

I'm working on it for Hyperion.
You can help some by creating the github issue for it so I don't have
to. I'll post my findings there.
Thanks.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com

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

[Non-text portions of this message have been removed]
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

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

[Roger Bowler [e-mail] [hercules-390]]

I fixed the mainsize bug. If you don't want to build Hyperion, specify
B, e.g., mainsize 65535b

Umm...it looks like you have changed the meaning of MAINSIZE 65536 from
64GB to 64KB.
I don't think this is going to fix his problem.

Roger

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

No, it clearly isn't. I hope Mark will bail me out.

I fixed the mainsize bug. If you don't want to build Hyperion, specify
B, e.g., mainsize 65535b

Umm...it looks like you have changed the meaning of MAINSIZE 65536 from
64GB to 64KB.
I don't think this is going to fix his problem.
Roger

[Roger Bowler [e-mail] [hercules-390]]

So, to answer your question, if someone could see if the MAINSIZE bug fix
is included in 3.12, it would be greatly appreciated. Thanks.

According to my tests, spinhawk is correctly calculating the size of
mainstor for both MAINSIZE 65535 and MAINSIZE 65536. A bit more research is
needed to determine the origin of the problem. My recommendation is that
you next run the same test with hyperion and see if it exhibits the same
problem.

Roger

[Roger Bowler [e-mail] [hercules-390]]

Ah. That explains why googling for that term doesnt turn up any relevant
hits. I already got the (false ?) impression that Hyperion, in it's
inception, was meant to be the development sandbox for a new Hercules
3.x+ version, but that over time, it turned into a new version all of its
own, turning into a genuine fork, even though that may not have been its
original intent.

I'd say that is quite a good assessment of the situation.

Roger

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

On Sun, 2015-11-15 at 00:08 -0800, ''Fish' (David B. Trout)'

Which developments am I interested in? Well, all of them.
But to keep it simple, the correction to the MAINSIZE bug
is the one I need right now.

I'm working on it for Hyperion.
You can help some by creating the github issue for it so I don't have
to. I'll post my findings there.
Thanks.

Hello,

I have been unable to reproduce the problem for Hyperion (4.0 compiled
on CENTOS 7 with gcc 4.8.3 with no optimization (-O0)
It seems that it is booting fine with whatever MAINSIZE
I tried:

64G
65G
75G
75536M
all worked and booted fine

version.c(755) HHC01413I Hercules version 4.00
version.c(765) HHC01414I (c) Copyright 1999-2015 by Roger Bowler, Jan
Jaeger, and others
version.c(775) HHC01415I Build date: Nov 16 2015 at 00:05:33
version.c(807) HHC01417I Built with: GCC 4.8.3 20140911 (Red Hat
4.8.3-9)
version.c(807) HHC01417I Build type: GNU/Linux x86_64 ** DEBUG **
host architecture build
version.c(807) HHC01417I Modes: S/370 ESA/390 z/Arch
version.c(807) HHC01417I Max CPU Engines: 8
version.c(807) HHC01417I Using setresuid() for setting privileges
version.c(807) HHC01417I Using POSIX threads Threading Model
version.c(807) HHC01417I Using Error-Checking Mutex Locking Model
version.c(807) HHC01417I With Syncio support
version.c(807) HHC01417I With Shared Devices support
version.c(807) HHC01417I With Dynamic loading support
version.c(807) HHC01417I Using shared libraries
version.c(807) HHC01417I Without External GUI support
version.c(807) HHC01417I With IPV6 support
version.c(807) HHC01417I With HTTP Server support
version.c(807) HHC01417I With sqrtl support
version.c(807) HHC01417I With SIGABEND handler
version.c(807) HHC01417I With CCKD BZIP2 support
version.c(807) HHC01417I With HET BZIP2 support
version.c(807) HHC01417I With ZLIB support
version.c(807) HHC01417I With Regular Expressions support
version.c(807) HHC01417I Without Object REXX support
version.c(807) HHC01417I Without Regina REXX support
version.c(807) HHC01417I Without Automatic Operator support
version.c(807) HHC01417I Without National Language Support
version.c(807) HHC01417I Machine dependent assists: cmpxchg1 cmpxchg4
cmpxchg8 hatomics=gccIntrinsics
hostinfo.c(324) HHC01417I Running on: llgc2
(Linux-3.10.0-229.el7.x86_64 x86_64) MP=2
hdl.c(194) HHC01508I HDL: loadable module directory
is /usr/local/lib/hercules
dyncrypt.c(4943) HHC00150I Crypto module loaded (c) Copyright 2003-2015
by Bernard van der Helm
dyncrypt.c(4944) HHC00151I Activated facility: Message Security Assist
dyncrypt.c(4946) HHC00151I Activated facility: Message Security Assist
Extension 1, 2, 3 and 4
cpu.c(1256) HHC00100I Thread id 00007f20cd81c700, prio 2147483647,
name Processor CP00 started
timer.c(203) HHC00100I Thread id 00007f20cd71b700, prio 2147483647,
name Timer started
cpu.c(1776) HHC00811I Processor CP00: architecture mode z/Arch
archlvl.c(742) HHC02204I archmode set to z/Arch
hscpufun.c(1056) HHC02256W Command ALRF is deprecated, use archlvl
ENABLE asn_lx_reuse instead
archlvl.c(502) HHC00898I Facility(ASN_LX_REUSE) enabled for archmode
ESA/390
archlvl.c(526) HHC00898I Facility(ASN_LX_REUSE) enabled for archmode
z/Arch
cmdtab.c(433) HHC90000D DBG: RC = 0
cckddasd.c(5468) HHC00346I cckd opts:
comp=-1,compparm=-1,ra=2,raq=4,rat=2,wr=2,gcint=5
cckddasd.c(5473) HHC00346I
gcparm=0,nostress=0,freepend=-1,fsync=0,linuxnull=0,trace=0
hsccmd.c(8044) HHC02204I conkpalv set to (3,1,10)
hsccmd.c(5288) HHC02204I cpumodel set to 3090
hsccmd.c(5344) HHC02204I cpuserial set to 012345
hsccmd.c(7815) HHC02204I ecpsvm set to enabled
hsccmd.c(5518) HHC02204I loadparm set to 0A95DB..
hsccmd.c(5063) HHC02204I lparname set to HERCULES
hsccmd.c(8523) HHC17003I MAIN storage is 64G (mainsize); storage
is not locked

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

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

Which developments am I interested in? Well, all of them.
But to keep it simple, the correction to the MAINSIZE bug
is the one I need right now.

I'm working on it for Hyperion.
You can help some by creating the github issue for it so I
don't have to. I'll post my findings there.
Thanks.

Hello,
I have been unable to reproduce the problem for Hyperion (4.0
compiled on CENTOS 7 with gcc 4.8.3 with no optimization (-O0)
It seems that it is booting fine with whatever MAINSIZE
64G
65G
75G
75536M
all worked and booted fine
version.c(755) HHC01413I Hercules version 4.00

[...]

Post by Truda ***@yahoo.com [hercules-390]
hsccmd.c(8523) HHC17003I MAIN storage is 64G (mainsize);
storage is not locked

"Booted" WHAT? Which operating system did you try "booting"?

What you have listed is simply the messages that Hercules issues upon startup, but I do not see any actual guest operating system being IPLed (booted).

I can state categorically with absolute 100% certainty that Hyperion most definitely *does* have the bug (as does Roger's 3.x too), and it's NOT what everyone has been talking about (MAINSIZE statement).

If you try IPLing z/OS for example with a mainsize set to 64G, it crashes and burns.

I have the fix for it (found it *days* ago) but it's not ready to be committed yet. They are many other odds and ends that I am also addressing in my upcoming patch.

If I could simply have another day or three of uninterrupted development time I could finish it, but it seems each time I go away to concentrate on Hercules I get flooded with a jillion zillion messages when I come back.

And it doesn't help any that my external backup array broke again for the THIRD F**KING TIME either (and is going to cost me $$$$ that I simply don't have).

Nor does the fact that it's difficult to thoroughly test such a fix on a box that only has 16GB and limited disk space for a swap (pagefile.sys) file either (thanks to the previously mentioned hardware issues).

If you could all cut me some slack and show a little patience I'll have the fix for you shortly.

Thanks.