[hercules-390] What happened to CP_UPDT / CODEPAGE MAINT commands ?

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

Some years back (2010 timeframe?), the command CP_UPDT / CODEPAGE MAINT were implemented, to allow for dynamic loading of host/guest translation tables. These got implemented and documented if I recall correctly. I believe these were defined as two binary files of 256 bytes each.


But the commands don't appear in the 3.12 release. Does anyone know about this? Were some bugs found that caused someone to remove this?


I had an interest in trying these, and when I saw the commands were not in the doc, I looked at the source for codepage.c and there it's not in there either.

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

I don't think they've ever been in the release version.

They are in an older Hyperion I have (Dec 2014).

Dunno about latest Hyperion.

Post by ***@yahoo.com [hercules-390]
Some years back (2010 timeframe?), the command CP_UPDT / CODEPAGE MAINT
were implemented, to allow for dynamic loading of host/guest translation
tables. These got implemented and documented if I recall correctly. I
believe these were defined as two binary files of 256 bytes each.
But the commands don't appear in the 3.12 release. Does anyone know about
this? Were some bugs found that caused someone to remove this?
I had an interest in trying these, and when I saw the commands were not in
the doc, I looked at the source for codepage.c and there it's not in there
either.

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

Post by Mike Stramba ***@gmail.com [hercules-390]
I don't think they've ever been in the release version.

You're probably right. There's a significant amount of new functionality that was added to Hyperion that has not yet made it into Spinhawk.

Post by Mike Stramba ***@gmail.com [hercules-390]
They are in an older Hyperion I have (Dec 2014).
Dunno about latest Hyperion.

It has it:

HHC01603I help cp*
HHC01603I
HHC01602I Command Description
HHC01602I ------- -----------------------------------------------
HHC01602I cp_updt *Create/Modify user character conversion table
HHC01602I cpu *Define target cpu for panel display and commands
HHC01602I cpuidfmt Set format BASIC/0/1 STIDP generation
HHC01602I cpumodel Set CPU model number
HHC01602I cpuprio Set/Display cpuprio parameter
HHC01602I cpuserial Set CPU serial number
HHC01602I cpuverid Set CPU verion number
HHC01603I
HHC01610I (*) Enter "help <command>" for more info.
HHC01603I
HHC01603I help cp_updt
HHC01603I
HHC01602I Command Description
HHC01602I ------- -------------------------------------------------------
HHC01602I cp_updt *Create/Modify user character conversion table
HHC01603I
HHC01603I Format: 'cp_updt cmd [operands]'
HHC01603I
HHC01603I altER e|g2h|a|h2g (pos, val, pos, val,...)
HHC01603I - alter the user eBCDIC/g2h or aSCII/h2g
HHC01603I table value at hex POSition to hex
HHC01603I VALue 16 pairs of hex digits may be
HHC01603I specified within the parens
HHC01603I
HHC01603I dsp|disPLAY e|g2h|a|h2g - display user eBCDIC|aSCII table
HHC01603I
HHC01603I expORT e|g2h|a|h2g filename - export contents of user table to file
HHC01603I
HHC01603I impORT e|g2h|a|h2g filename - import file contents into user table
HHC01603I
HHC01603I refERENCE [cp] - copy codepage to user tables
HHC01603I if cp is not specified, a list of
HHC01603I valid codepage tables is generated
HHC01603I
HHC01603I reset - reset the internal user tables to
HHC01603I binary zero
HHC01603I
HHC01603I test - verify that user tables are
HHC01603I transparent, i.e. the value at
HHC01603I position n in g2h used as an index
HHC01603I into h2g will return a value equal n
HHC01603I ( g2h<=>h2g, h2g<=>g2h )
HHC01603I
HHC01603I *e|g2h represent ebcdic; a|h2g represent ascii
HHC01603I **lower case part of the cmd name represent the minimum abbreviation
HHC01603I for the command
HHC01603I
HHC01603I To activate the user table, enter the command 'codepage user'
HHC01603I
HHC01603I Note: ebcdic refers to guest to host translation
HHC01603I ascii refers to host to guest translation
HHC01603I These terms are used for historical purposes and do not
HHC01603I represent the literal term.
HHC01603I

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

If these commands work correctly, but just got missed somehow as an oversight, what would it take to get them put back?


Is this something I would have to do my own build for, or would it be incorporated into the 'release' build?

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

There are hyperion binaries on Fish's site with those commands

Post by ***@yahoo.com [hercules-390]
If these commands work correctly, but just got missed somehow as an
oversight, what would it take to get them put back?
Is this something I would have to do my own build for, or would it be
incorporated into the 'release' build?

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

Could someone be persuaded to merge this into 3.12? 3.12.1? Not sure what you'd call it ...

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

Post by ***@yahoo.com [hercules-390]
Could someone be persuaded to merge this into 3.12? 3.12.1?
Not sure what you'd call it ...

Ask Roger. He's the only "someone" that can do it. It's *his* repository.

None of us developers (that I know of!) have commit access to his 3.x Spinhawk repository. Only he does.

By design, we can only make changes to Hyperion. It's then up to *him* to decide which changes we make end up getting merged into his so-called "official" Hercules release.

Which kind of sucks too, since it ultimately means none of us can ever be sure whether or not the work we do, the effort we put into making change, will *ever* make it into the so-called "official" release of Hercules since that decision is now, by design, out of our control.

But then given Roger's (and perhaps others'?) feelings towards some developers however (me in particular I'm sure), I'm certain he feels that is actually a very *good* thing.

To him anyway.

To the rest of us?

Not so much. :(

Although in all fairness the reason he and possibly others in all likelihood believe that doing things that way is an overall Good Thing(tm) is probably because it supposedly ensures a higher quality product given that he (and whoever he has helping him, if anyone) can then be much more careful regarding which changes go into the official release as well as how thoroughly those changes are tested (which we admittedly haven't done a very good job at when the project only had one repository (*)).

At least that's *my* understanding of the situation.

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

As we used to say at my last employer, "That's a GREAT idea. Send me a
change list to review!".

In other words, if you care, do the work yourself and reduce the owner's
load to just final review/acceptance.

That's what I did to get the Web UI autofocus (a trivial change, to be
sure) into spinhawk.

1. I got a github account
2. I branched spinhawk under my own account
3. I made the desired change
4. And yes, I tested it!
5. I committed it locally, carefully documenting it. (A typo still
sneaked in).
6. I pushed it to my repro on github.
7. I sent a pull request to Roger.

This reduced the expense of the merge for Roger and thus made it more
likely he would take it.

Of course, if it's a bad idea in the first place (I have no information
in this case), no amount of care and greasing the skids will help. :-)

-ahd-

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

In theory, submitting my own Git updates is a good suggestion. In practice, it doesn't work for me. When the Hercules developers abandoned SVN to use Git, that ended any prospect of me of interacting with the developers again. Call it a mental block, or senility, or whatever you wish, but I cannot understand how Git works; it just makes no sense to me. It's not like the developers made any effort to help the users understand, either - they just assumed that anyone who needed to know already knew, and anyone that didn't fit that category was of no importance to them - like me, for instance.


I don't feel that the developers really want "outsiders" interfering anyway. When they went with Git, they simply announced it without documenting what they did or how it worked. For anyone that didn't understand the process, that's just too damn bad - it's not their problem, and people like me were left behind.


At the moment, my only access to Hercules is as an end user running official binary releases. I am totally dependent on the developers as to what they do or don't choose to make available.


All that is beside the point. I just wanted to know why these commands were designed, developed and documented, and then simply dropped. It doesn't make any sense. But, if what Fish says is true, it seems the real reason is that a kind of "civil war" is going on in the Hercules community, with factions that have run off in a huff, and working independently without regard (or respect) for each other, and without regard to the present and future harm they are bringing to the Hercules "cause".


The irony, and tragedy of this is that most Hercules users are old and getting older. How many more years of this bickering do we all have left in us, collectively, before people start to pass away, and the knowledge possessed by these separate developers becomes lost, due to this foolish animosity and lack of cooperation?


Is this the best we can do?

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

Post by ***@yahoo.com [hercules-390]
In theory, submitting my own Git updates is a good suggestion. In
practice, it doesn't work for me. When the Hercules developers
abandoned SVN to use Git, that ended any prospect of me of interacting
with the developers again. Call it a mental block, or senility, or
whatever you wish, but I cannot understand how Git works; it just
makes no sense to me. It's not like the developers made any effort to
help the users understand, either - they just assumed that anyone who
needed to know already knew, and anyone that didn't fit that category
was of no importance to them - like me, for instance.
I don't feel that the developers really want "outsiders" interfering
anyway. When they went with Git, they simply announced it without
documenting what they did or how it worked. For anyone that didn't
understand the process, that's just too damn bad - it's not their
problem, and people like me were left behind.

You assume there was a collective decision to go to git on the part of
the developers as if we got together without regards to the users and
colluded against them.

If only there had been that much collaboration at the time.
Unfortunately the then maintainer made the unilateral decision to go to
git. The SVN repository was locked, without notice, for months of
silence. In desperation we needed a place to host the repo and github
made sense as long as git was the destination anyways. At the time it
was much more closer to unconsciousness than malicious collusion with
absolutely nothing happening.

None of the rest of the developers had any idea how git worked nor were
we consulted. NONE! All of us were in the same position as you are
now. At the time we were not educated ourselves in how to use git nor
in a position to help others.
I believe there was some desire to be separate from the users in the
past. That is not how the developers working on Hyperion feel. We have
embraced github's facilities providing options for the users to
communicate directly with us. In particular the github issues facility
allows that.

The github site allows you to download the repo as a zip file so you
don't need any local tools to get the latest code. You don't need any
special knowledge. And if you have something to contribute, that can be
worked out some how. Complaining about how we wish things to be that
aren't, is always easier than adapting to existing reality.

Your being left behind is your choice.

Harold Grovesteen

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

1) You can (now) use an SVN client to interact with GITHUB See:-



https://help.github.com/articles/support-for-subversion-clients/



2) Moving to GIT was somewhat un-planned. The original intention was to move to Mercurial on one of the developers private servers but from what I remember there were server and migration problems. Someone created a project on GITHUB which provides reliable free hosting, and after some use it was adopted by default. I am told GIT is better at supporting multiple repositories than SVN which makes it great for multiple Hercules developers. There was little support as it was unplanned so most of the developers were busy learning GIT themselves. In addition, there are numerous web tutorials so why are we going to be better at re-explaining something when we are on a learning curve ourselves. For a tutorials for SVN users see perhaps :-



* http://git.or.cz/course/svn.html



but a google search for “GIT Tutorial” produces innumerable usefull hits, most of which seem readable and usable.



Dave

G4UGM







From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: 25 December 2015 18:01
To: hercules-***@yahoogroups.com
Subject: [hercules-390] Re: What happened to CP_UPDT / CODEPAGE MAINT commands ?








In theory, submitting my own Git updates is a good suggestion. In practice, it doesn't work for me. When the Hercules developers abandoned SVN to use Git, that ended any prospect of me of interacting with the developers again. Call it a mental block, or senility, or whatever you wish, but I cannot understand how Git works; it just makes no sense to me. It's not like the developers made any effort to help the users understand, either - they just assumed that anyone who needed to know already knew, and anyone that didn't fit that category was of no importance to them - like me, for instance.



I don't feel that the developers really want "outsiders" interfering anyway. When they went with Git, they simply announced it without documenting what they did or how it worked. For anyone that didn't understand the process, that's just too damn bad - it's not their problem, and people like me were left behind.



At the moment, my only access to Hercules is as an end user running official binary releases. I am totally dependent on the developers as to what they do or don't choose to make available.



All that is beside the point. I just wanted to know why these commands were designed, developed and documented, and then simply dropped. It doesn't make any sense. But, if what Fish says is true, it seems the real reason is that a kind of "civil war" is going on in the Hercules community, with factions that have run off in a huff, and working independently without regard (or respect) for each other, and without regard to the present and future harm they are bringing to the Hercules "cause".



The irony, and tragedy of this is that most Hercules users are old and getting older. How many more years of this bickering do we all have left in us, collectively, before people start to pass away, and the knowledge possessed by these separate developers becomes lost, due to this foolish animosity and lack of cooperation?



Is this the best we can do?

[Joe Monk [e-mail] [hercules-390]]

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


You would be well advised to read the link...

Joe

Post by ***@yahoo.com [hercules-390]
In theory, submitting my own Git updates is a good suggestion. In
practice, it doesn't work for me. When the Hercules developers abandoned
SVN to use Git, that ended any prospect of me of interacting with the
developers again. Call it a mental block, or senility, or whatever you
wish, but I cannot understand how Git works; it just makes no sense to
me. It's not like the developers made any effort to help the users
understand, either - they just assumed that anyone who needed to know
already knew, and anyone that didn't fit that category was of no importance
to them - like me, for instance.
I don't feel that the developers really want "outsiders" interfering
anyway. When they went with Git, they simply announced it without
documenting what they did or how it worked. For anyone that didn't
understand the process, that's just too damn bad - it's not their problem,
and people like me were left behind.
At the moment, my only access to Hercules is as an end user running
official binary releases. I am totally dependent on the developers as to
what they do or don't choose to make available.
All that is beside the point. I just wanted to know why these commands
were designed, developed and documented, and then simply dropped. It
doesn't make any sense. But, if what Fish says is true, it seems the real
reason is that a kind of "civil war" is going on in the Hercules community,
with factions that have run off in a huff, and working independently
without regard (or respect) for each other, and without regard to the
present and future harm they are bringing to the Hercules "cause".
The irony, and tragedy of this is that most Hercules users are old and
getting older. How many more years of this bickering do we all have left
in us, collectively, before people start to pass away, and the knowledge
possessed by these separate developers becomes lost, due to this foolish
animosity and lack of cooperation?
Is this the best we can do?

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

I read the link ...

Jay however abdicated (resigned from) his position as official project
maintainer when he virtually disappeared from the project, taking the SVN
repository with him. As soon as THAT happened, the project immediately went
into crisis. It became immediately in danger of no longer existing since
none of the developers were able to access the source code repository to
allow development to continue.
Yikes! What to do?!
Well, the logical thing to do was the setup another web site somewhere and
host the repository and web pages (web site) there. The only problem was,
due to SVN's very non-decentralized (i.e. CENTRALized) design, the SVN
repository was nowhere to be found! Jay had it. ALL of it. All any of us
developers had (or so we thought at the time) was the source code and that
was it. All of the repository's commit HISTORY remained with the repository
itself, which disappeared along with Jay and the entire hercules-390 web
site.
Well, luckily, SOMEONE (I don't recall who right now) managed to locate
someone's private/personal copy (mirror?) of the repository, complete with
all of the history, which was then converted to GIT in an effort to try and
prevent from EVER AGAIN HAPPENING what had ALMOST happened: the death of a
project due to the disappearance of the source code repository.
GIT prevents this from occurring by virtue of its DE-centralized nature
wherein each person always receives a complete copy of the ENTIRE
repository.

... and I am surprised to see the claim that
Jay abandoned the project leaving everyone
in the lurch.

I'm not familiar with the timing, but this:

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

makes it look like HE was the one who
made the switch to github on 2012-01-27

ie the github where it is supposedly
no longer possible for one person to
trash the project.

BFN. Paul.





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

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




You would be well advised to read the link...


Joe










On Fri, Dec 25, 2015 at 12:00 PM, ***@... mailto:***@... [hercules-390] <hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com> wrote:

In theory, submitting my own Git updates is a good suggestion. In practice, it doesn't work for me. When the Hercules developers abandoned SVN to use Git, that ended any prospect of me of interacting with the developers again. Call it a mental block, or senility, or whatever you wish, but I cannot understand how Git works; it just makes no sense to me. It's not like the developers made any effort to help the users understand, either - they just assumed that anyone who needed to know already knew, and anyone that didn't fit that category was of no importance to them - like me, for instance.


I don't feel that the developers really want "outsiders" interfering anyway. When they went with Git, they simply announced it without documenting what they did or how it worked. For anyone that didn't understand the process, that's just too damn bad - it's not their problem, and people like me were left behind.


At the moment, my only access to Hercules is as an end user running official binary releases. I am totally dependent on the developers as to what they do or don't choose to make available.


All that is beside the point. I just wanted to know why these commands were designed, developed and documented, and then simply dropped. It doesn't make any sense. But, if what Fish says is true, it seems the real reason is that a kind of "civil war" is going on in the Hercules community, with factions that have run off in a huff, and working independently without regard (or respect) for each other, and without regard to the present and future harm they are bringing to the Hercules "cause".


The irony, and tragedy of this is that most Hercules users are old and getting older. How many more years of this bickering do we all have left in us, collectively, before people start to pass away, and the knowledge possessed by these separate developers becomes lost, due to this foolish animosity and lack of cooperation?


Is this the best we can do?

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

Hello!
All it says Paul in Oz is what happened during the conversion process.
It does not explain the beginnings of the problem that this thread
started off.

It is normal sadly for people to argue. But yes we do need to combine
our efforts and stop all of this bickering. Its pointless.

Which explains my second comment from earlier.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."

Post by ***@yahoo.com.au [hercules-390]
I read the link ...

Jay however abdicated (resigned from) his position as official project
maintainer when he virtually disappeared from the project, taking the SVN
repository with him. As soon as THAT happened, the project immediately went
into crisis. It became immediately in danger of no longer existing since
none of the developers were able to access the source code repository to
allow development to continue.
Yikes! What to do?!
Well, the logical thing to do was the setup another web site somewhere and
host the repository and web pages (web site) there. The only problem was,
due to SVN's very non-decentralized (i.e. CENTRALized) design, the SVN
repository was nowhere to be found! Jay had it. ALL of it. All any of us
developers had (or so we thought at the time) was the source code and that
was it. All of the repository's commit HISTORY remained with the repository
itself, which disappeared along with Jay and the entire hercules-390 web
site.
Well, luckily, SOMEONE (I don't recall who right now) managed to locate
someone's private/personal copy (mirror?) of the repository, complete with
all of the history, which was then converted to GIT in an effort to try and
prevent from EVER AGAIN HAPPENING what had ALMOST happened: the death of a
project due to the disappearance of the source code repository.
GIT prevents this from occurring by virtue of its DE-centralized nature
wherein each person always receives a complete copy of the ENTIRE
repository.

... and I am surprised to see the claim that
Jay abandoned the project leaving everyone
in the lurch.
https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/67275
makes it look like HE was the one who
made the switch to github on 2012-01-27
ie the github where it is supposedly
no longer possible for one person to
trash the project.
BFN. Paul.
https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/73072 https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/73072
You would be well advised to read the link...
Joe

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

Post by ***@yahoo.com [hercules-390]
In theory, submitting my own Git updates is a good
suggestion. In practice, it doesn't work for me.
When the Hercules developers abandoned SVN to use Git,
that ended any prospect of me of interacting with the
developers again. Call it a mental block, or senility,

<snip>

Boy you're grouchy. :)

Two things real quick besides what others have already written:

1. You don't need git.

As Harold mentioned, *anyone* can quickly and easily download the complete source for Hercules at any time via a simple mouse click. For Hercules 4.0 Hyperion there is even a DIRECT DOWNLOAD link on the main Hercules 4.0 Hyperion web site for crying out loud:

http://hercules-390.github.io/html/

"Source code and binaries:"

"Source code::

"Source code repository on Github"
"Source code .ZIP file from Github"


The above "Source code .ZIP file from Github" link is simply the same link that GitHub itself provides for *every* public repository:

https://github.com/hercules-390/hyperion


Just click the "[Download ZIP]" button and voila! You've got the complete source code to Hercules, all *without* having to mess with git.

2. There is more than one "graphical user interface to git" product out there for both Windows and non-Windows alike which are IMO quite user friendly and easy to use (extremely so in the case of TortoiseGit IMHO). I personally use/prefer TortoiseGit on Windows 7, but another developer swears by SmartGit. Other developers that develop mostly on Linux prefer the command-line (which in all honesty isn't really that hard to use since 99% of the time you only ever use two or three commands).

3. There's this thing called "The User Community" out there (you know, the very audience your post was directed towards?) that would be more than willing to help you with whatever it is you need help with, whether it's using git or building Hercules or whatever. All you have to do is ASK.

So with all due respect quatras, I personally find your complaints in all honesty to be rather weak. Sorry!

Maybe you're just having a bad day? (week/month/...)

In any case I wish you all the best and a Merry Christmas besides if that helps any.

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

Post by ***@yahoo.com [hercules-390]
In theory, submitting my own Git updates is a good suggestion. In
practice, it doesn't work for me. When the Hercules developers abandoned
SVN to use Git, that ended any prospect of me of interacting with the
developers again.

Really? You've received replies from a few developers, so by sending the
above message it would appear that you've interacted with some developers.

Post by ***@yahoo.com [hercules-390]
Call it a mental block, or senility, or whatever you wish, but I cannot
understand how Git works; it just makes no sense to me.

I wouldn't be surprised if there were Hercules users in the SVN days that
didn't understand SVN. Does that mean Hercules developers should have
chosen something other than SVN back then?

As others have pointed out one doesn't have to get how git works to get the
latest Hercules source code. There are links to get the latest source code
in a .zip archive without using git.

git basics aren't too tough to figure out. I'm at best a git novice, and I
use it for several personal projects. There are more git tutorial on the
net than one can shake a stick at. There might even be one or two out there
that helps git make sense to those who don't get it.

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

Hello!
I use Git, on both Linux (Intel), and again on Linux (ARM, Raspberry
Pi), and Windows. I freely admit I only grok a portion of what the
thing does. Besides Linus who invented it because of a rift with
another source code control tool, admits he does not like his tool.

Incidentally the one thing GitHub has going for it, happens to be the
entity keeping it up and running. In fact we've bought books and stuff
from them. Amazon.
Can we just agree to just to disagree?

Fish I find your arguments oddly compelling.

And one of you I find your lack of faith disturbing.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."

Post by Kevin Monceaux ***@RawFedDogs.net [hercules-390]

Post by ***@yahoo.com [hercules-390]
In theory, submitting my own Git updates is a good suggestion. In
practice, it doesn't work for me. When the Hercules developers abandoned
SVN to use Git, that ended any prospect of me of interacting with the
developers again.

Really? You've received replies from a few developers, so by sending the
above message it would appear that you've interacted with some developers.

Post by ***@yahoo.com [hercules-390]
Call it a mental block, or senility, or whatever you wish, but I cannot
understand how Git works; it just makes no sense to me.

I wouldn't be surprised if there were Hercules users in the SVN days that
didn't understand SVN. Does that mean Hercules developers should have
chosen something other than SVN back then?
As others have pointed out one doesn't have to get how git works to get the
latest Hercules source code. There are links to get the latest source code
in a .zip archive without using git.
git basics aren't too tough to figure out. I'm at best a git novice, and I
use it for several personal projects. There are more git tutorial on the
net than one can shake a stick at. There might even be one or two out there
that helps git make sense to those who don't get it.
--
Kevin
http://www.RawFedDogs.net
http://www.Lassie.xyz
http://www.WacoAgilityGroup.org
Bruceville, TX
What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

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

Fish wrote:

[...]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
1. You don't need git.

[...]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
2. There is more than one "graphical user interface to git"
product out there for both Windows and non-Windows alike
which are IMO quite user friendly and easy to use (extremely
so in the case of TortoiseGit IMHO). [...]

AND, I'd like to mention again what Dave Wade mention in his reply:

You can access any GitHub repository using SVN as well. That is to say, you do *not* need to install a git client if you don't like or grok git. You can use SVN instead.

So if you prefer SVN and not git (and evidence seems to support that being true in your case(*)), then as I said before you really have no excuse Robert. Your original complaint regarding git itself and not being able to interact with the developers as a result remains incredibly weak.

I'm not trying to pick on you either. I'm not. I'm just using your complaint as a stepping stone to pass along information that others besides yourself may also find useful as well.

Please accept my sincerest wishes for a Happy and Joyous Holiday Season to you and your family and to everyone else on the list and their families as well. :)

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

[...]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
So if you prefer SVN and not git (and evidence
seems to support that being true in your case(*)),

(*) https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/76531

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

Post by ***@yahoo.com [hercules-390]
In theory, submitting my own Git updates is a good suggestion. In
practice, it doesn't work for me. When the Hercules developers
abandoned SVN to use Git, that ended any prospect of me of interacting
with the developers again. Call it a mental block, or senility, or
whatever you wish, but I cannot understand how Git works; it just
makes no sense to me. It's not like the developers made any effort to
help the users understand, either - they just assumed that anyone who
needed to know already knew, and anyone that didn't fit that category
was of no importance to them - like me, for instance.

I feel both your technical and community pain.

I've come to git late in life (dragged in kicking and screaming within
past the 18 months for work), and all I can say is "practice". I didn't
even know how to do a pull request until I submitted my recent change.
git may not worth the effort for hercules by itself ... but git seems to
be winning the global source control war, and so it's worth learning in
general. Look around for a tutorial, or ping me off list.

The community pain is harder to quantify and fix. All I can suggest
either grin and bear it, or seek understanding from the major players
off list (where the rhetoric will be quieter). (There's also lead by
example, but I can't tell if hercules has too many leaders or none at
all -- but if someone who want to step in to organizing things better
they need street cred, and that's hard to come by on an old project like
this. That's not particular to this environment.)

Me? I just take hints like JES2 having a " CATASTROPHIC ERROR" after
midnight that God is telling me is time to go bed. (Yes, that happened
last night). :-)

Drew

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

Roger decides what goes into the official releases. I guess these never made it.

Dave

From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: 23 December 2015 18:32
To: hercules-***@yahoogroups.com
Subject: [hercules-390] What happened to CP_UPDT / CODEPAGE MAINT commands ?





Some years back (2010 timeframe?), the command CP_UPDT / CODEPAGE MAINT were implemented, to allow for dynamic loading of host/guest translation tables. These got implemented and documented if I recall correctly. I believe these were defined as two binary files of 256 bytes each.

But the commands don't appear in the 3.12 release. Does anyone know about this? Were some bugs found that caused someone to remove this?

I had an interest in trying these, and when I saw the commands were not in the doc, I looked at the source for codepage.c and there it's not in there either.

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

Post by ***@yahoo.com [hercules-390]
Some years back (2010 timeframe?), the command CP_UPDT / CODEPAGE MAINT
were implemented, to allow for dynamic loading of host/guest translation
tables. These got implemented and documented if I recall correctly. I
believe these were defined as two binary files of 256 bytes each.

If this is the same printing requirement that you raised in July 2010 then
the your best bet is to use the solution that Rocky offered at that time:

http://permalink.gmane.org/gmane.comp.emulators.hercules390.general/36557

You can use the Hercules "print-to-pipe" facility (see
http://www.hercules-390.eu/hercconf.html#1403) to pipe the printer output
into a program such as the Unix tr utility (there is a Windows version here
http://gnuwin32.sourceforge.net/packages/coreutils.htm).

Thanks
Roger Bowler
Hercules "the people's mainframe"

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

Browsing back through the thread from 2010, it appears that the command
added by Paul Gorlinsky was not exactly what you were looking for anyway:

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

Or at least that's how I read the message.

Roger Bowler
Hercules "the people's mainframe"

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

Sorry for not replying sooner.


My interest in not so much in printing, as it is in actually using the CP_UPDT / CODEPAGE MAINT commands. I did have a chance to test them back in 2010 or so, while they were included in the release version (I believe), but in the mean time, life got in the way and I was not able to pursue this. I have something I am working on that I would like to give to the Hercules community when finished, but it would require these commands to use.


It's possible I could write some 'patch' program to attempt to find the standard code pages in the executable, and replace one of them with a custom version, but, that would be hacking at its worst, and not my first choice.


All I am really looking for is that, if these commands were tested and found to work properly so many years ago, that they be put into "production". Unless someone knows of some reason why they should not be there, that is. I never read of anyone saying they tried them and they didn't work. The commands just quietly got dropped.


If I had more time back then, I could have piped up about it, but my wife and I ended up moving a lot, then she became ill and passed away, so my life has been pulled away from Hercules until recently.

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

[...] I did have a chance to test them back in 2010 or so,
while they were included in the release version (I believe),

[...]

I never read of anyone saying they tried them and they
didn't work. The commands just quietly got dropped.

They weren't quietly dropped. In fact, they weren't dropped at all. AFAIK what actually happened was they never made it into the official release due to the changes that were made in the project's management.

What I believe actually happened was, back then, there was only ONE Hercules repository (instead of the two we have now) and the current production release of Hercules was 3.07. It did not contain the new CP_UPDT codepage management command. It instead only existed in the (at that time, one and only) repository which was *supposed* to eventually be released as 4.0. That's likely where you tested it from.

But then Roger and others (myself included) began questioning some of the changes that were being made, so he (Roger) decided to create the "Spinhawk" repository whose purpose was to be the next "Release" version of Hercules but with only those changes from the development repository he deemed worthy for the official release.

That repository (Spinhawk) was initially populated with (created from) the then current/official 3.07 production version of Hercules. He then began adding selected commits from the our original/only (at that time) version 4.0 repository to his spinhawk repository, eventually releasing it NOT as version 4.0 but as version 3.08 instead. The original development repository containing what was *supposed* to be version 4.0 (and which contained the CP_UPDT codepage management command) was rechristened as "Hyperion".

Over time more and more code from Hyperion was added to Spinhawk and released as subsequent "Official Production" versions of Hercules called 3.09 all the way up to 3.12 which is today's most current official release version.

Thus the CP_UPDT command didn't so much get silently dropped as it did not ever make it into Spinhawk (yet).

So the fact that it's *still* not in the official production version of Hercules (but instead still remains right where it has always been: in the Hyperion repository where it was originally added) is not the fault of any of the Hercules developers but rather that of Roger since, as explained in an earlier post, he's the sole owner of, and the sole person with commit access to, *his* Spinhawk repository. We (the Hercules developers) cannot add it to Spinhawk for you. Only *Roger* can do that. So complain to him, not us.

If I had more time back then, I could have piped up about it,
but my wife and I ended up moving a lot, then she became ill
and passed away, so my life has been pulled away from Hercules
until recently.

(Urk!) I am *very* sorry to hear that Robert. That really sucks. :`(

Losing a spouse takes a long time to get over, if such is even truly possible.

Please forgive me calling you grouchy earlier. Feel free to be as grouchy as you want.

You have every right to be. :(

Again, please accept my sincerest apologies and my deepest sympathies.

I hope what I've written further above helps you and I wish you well my friend.

Take care.

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

David,


Assuming Roger is aware of all this, it seems like I could be of some help. I have done quite a bit of research on the subject of code pages. Not to brag, but I am pretty knowledgeable about it. I believe I could design a better command than the one put together 5 years ago. Since that never got put 'into production' then we don't have to stay with that design.


I would change a few things. First, instead of defining two 256-byte tables, I would have only one, with ASCII to EBCDIC first, then EBCDIC to ASCII. Having just one file simplifies the management of them. I think the two-file approach is a needless complication for users.


Second, I would allow for the tables to be text in addition to binary.


Third, other than the "default" code page, I would delete all code pages from Hercules itself. They take up several thousand bytes, and you can only use one at a time. All the existing translation tables should be make dynamic. It would be more flexible, and not take up all the space in memory doing nothing.


For compatibility, I would take the source code of codepage.c and use the tables within it to generate the external binary files corresponding to the currently defined codepage pairs, to make sure existing configurations continued to work.


Well, if I could wave my magic wand, that's what I'd do.


Robert


p.s. Thanks for the kind words. My "little wifey" has been gone 3 1/2 years, and it never really gets any better. I do things like work on Hercules to try to take my mind off it. Sometimes that works, sometimes not.

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

I wish you would know about code pages and the various efforts rather
that to reinvent something rather complex.

Post by ***@yahoo.com [hercules-390]
David,
Assuming Roger is aware of all this, it seems like I could be of some
help. I have done quite a bit of research on the subject of code
pages. Not to brag, but I am pretty knowledgeable about it. I believe
I could design a better command than the one put together 5 years ago.
Since that never got put 'into production' then we don't have to stay
with that design.
I would change a few things. First, instead of defining two 256-byte
tables, I would have only one, with ASCII to EBCDIC first, then EBCDIC
to ASCII. Having just one file simplifies the management of them. I
think the two-file approach is a needless complication for users.
Second, I would allow for the tables to be text in addition to binary.
Third, other than the "default" code page, I would delete all code pages
from Hercules itself. They take up several thousand bytes, and you can
only use one at a time. All the existing translation tables should be
make dynamic. It would be more flexible, and not take up all the space
in memory doing nothing.
For compatibility, I would take the source code of codepage.c and use
the tables within it to generate the external binary files corresponding
to the currently defined codepage pairs, to make sure existing
configurations continued to work.
Well, if I could wave my magic wand, that's what I'd do.
Robert
p.s. Thanks for the kind words. My "little wifey" has been gone 3 1/2
years, and it never really gets any better. I do things like work on
Hercules to try to take my mind off it. Sometimes that works, sometimes
not.

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

Which part do you believe I don't know about?

[Joe Monk [e-mail] [hercules-390]]

No ... hes saying dont try to reinvent the wheel.


Joe

Post by ***@yahoo.com [hercules-390]
Which part do you believe I don't know about?

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

There are several different codepages for EBCDIC, because different
programs need different special characters.
And they usually translate to different ASCII codepages for the same reason.
Any chance of using UTF-8?

On Fri, Jan 1, 2016 at 7:27 PM, 'John P. Hartmann'

Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
I wish you would know about code pages and the various efforts rather
that to reinvent something rather complex.

Post by ***@yahoo.com [hercules-390]
David,
Assuming Roger is aware of all this, it seems like I could be of some
help. I have done quite a bit of research on the subject of code
pages. Not to brag, but I am pretty knowledgeable about it. I believe
I could design a better command than the one put together 5 years ago.
Since that never got put 'into production' then we don't have to stay
with that design.
I would change a few things. First, instead of defining two 256-byte
tables, I would have only one, with ASCII to EBCDIC first, then EBCDIC
to ASCII. Having just one file simplifies the management of them. I
think the two-file approach is a needless complication for users.
Second, I would allow for the tables to be text in addition to binary.
Third, other than the "default" code page, I would delete all code pages
from Hercules itself. They take up several thousand bytes, and you can
only use one at a time. All the existing translation tables should be
make dynamic. It would be more flexible, and not take up all the space
in memory doing nothing.
For compatibility, I would take the source code of codepage.c and use
the tables within it to generate the external binary files corresponding
to the currently defined codepage pairs, to make sure existing
configurations continued to work.
Well, if I could wave my magic wand, that's what I'd do.
Robert
p.s. Thanks for the kind words. My "little wifey" has been gone 3 1/2
years, and it never really gets any better. I do things like work on
Hercules to try to take my mind off it. Sometimes that works, sometimes
not.

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

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

What I have in mind is not "reinventing the wheel".


I do know about code pages. The ICU Project - International Components for Unicode - define thousands of code pages, notably in the form of UCM files - Unicode Character Mappings. When two UCM files are referenced together, you can create translation tables between two systems, using Unicode as the go-between.


In contrast to the thousands of UCM files that exist from IBM, Apple, HP, The GNU Project and others, Hercules defines just 21 translation tables, including the 7-bit default Ascii version.


If a Hercules user wanted a translation table OTHER than the predefined set of 21 tables that exist now, what choice do they have? There are only these options:


1. Accept what's available and change your data to match; the "do nothing" approach


2. Write a program that will scan the Hercules executable looking for the 256-byte spans containing these translation tables and replacing one or more of them with your own tables.

3. Beg and plead for someone to add the table you want to use into the source code of codepage.c and hope that someday - maybe - it will be adopted. There actually was that kind of hope, once, but now that Hercules development is divided, that hope is mostly gone.


4. Put into production the CODEPAGE MAINT commands, so that any user can create their own tables.


This is not "complex". The work has already been done; the code exists and it works. All I am asking is that it be made available to all users. I have been waiting 5 years for this; it's not like I haven't been patient.


Mike, I know that different code pages are written for different reasons. I could not agree more. That is the very reason I want this. I have a present need for a code page that is NOT one of the predefined 21 translation tables in Hercules.


The shame is, the CODEPAGE MAINT commands and all the work of the ICU project have already be "invented", but Hercules users have up until now been denied the benefits of it. To use the illustration of supposedly "reinventing the wheel", it is like the wheel is well-past being invented, but all the wheel stores are closed and padlocked.


P.S. As for using UTF-8, I don't see that as feasible. The main use of translation tables in Hercules in the first place is for translating unit record I/O. Although the current CODEPAGE command says that UTF-8 is used with "I-Conv" translation, which is a Unix//Linus feature, I have never seen this done myself as a Windows user. For instance, if I run DOS/VS and send a print file to my PC, DOS/VS has created its file in EBCDIC so I need it in ASCII to view or print it locally. So there is a single-byte character set (SBCS) in EBCDIC getting translated to an SBCS in ASCII. When or how would UTF-8 get involved? I don't see how it would.


==================
Mike A Schwab wrote,


There are several different codepages for EBCDIC, because different
programs need different special characters.
And they usually translate to different ASCII codepages for the same reason.
Any chance of using UTF-8?

John P. Hartmann wrote,

I wish you would know about code pages and the various efforts rather
that to reinvent something rather complex.

[Joe Monk [e-mail] [hercules-390]]

I guess I still dont understand your gripe.

You have available to you the Hyperion git repository on github. You can
download the source code, build your own version of hercules and voila ...
codepage commands are ready and waiting for you to use.

If you dont want to do that, you can download pre-built versions of
Hyperion.

So, what you want is already available. Just grab the brass ring, download
it, and use it. If you dont like it as is, modify the source, build it,
test it, and make the case for the changes to the 4.0 development community.

BTW, detailed instructions on how to build hercules from source, as well as
pre-built binaries, can be downloaded from here:

http://www.softdevlabs.com/hyperion.html

Joe

Post by ***@yahoo.com [hercules-390]
What I have in mind is not "reinventing the wheel".
I do know about code pages. The ICU Project - International Components
for Unicode - define thousands of code pages, notably in the form of UCM
files - Unicode Character Mappings. When two UCM files are referenced
together, you can create translation tables between two systems, using
Unicode as the go-between.
In contrast to the thousands of UCM files that exist from IBM, Apple, HP,
The GNU Project and others, Hercules defines just 21 translation tables,
including the 7-bit default Ascii version.
If a Hercules user wanted a translation table OTHER than the predefined
set of 21 tables that exist now, what choice do they have? There are only
1. Accept what's available and change your data to match; the "do nothing" approach
2. Write a program that will scan the Hercules executable looking for the
256-byte spans containing these translation tables and replacing one or
more of them with your own tables.
3. Beg and plead for someone to add the table you want to use into the
source code of codepage.c and hope that someday - maybe - it will be
adopted. There actually was that kind of hope, once, but now that Hercules
development is divided, that hope is mostly gone.
4. Put into production the CODEPAGE MAINT commands, so that any user can
create their own tables.
This is not "complex". The work has already been done; the code exists
and it works. All I am asking is that it be made available to all users.
I have been waiting 5 years for this; it's not like I haven't been patient.
Mike, I know that different code pages are written for different reasons.
I could not agree more. That is the very reason I want this. I have a
present need for a code page that is NOT one of the predefined 21
translation tables in Hercules.
The shame is, the CODEPAGE MAINT commands and all the work of the ICU
project have already be "invented", but Hercules users have up until now
been denied the benefits of it. To use the illustration of supposedly
"reinventing the wheel", it is like the wheel is well-past being invented,
but all the wheel stores are closed and padlocked.
P.S. As for using UTF-8, I don't see that as feasible. The main use of
translation tables in Hercules in the first place is for translating unit
record I/O. Although the current CODEPAGE command says that UTF-8 is used
with "I-Conv" translation, which is a Unix//Linus feature, I have never
seen this done myself as a Windows user. For instance, if I run DOS/VS and
send a print file to my PC, DOS/VS has created its file in EBCDIC so I need
it in ASCII to view or print it locally. So there is a single-byte
character set (SBCS) in EBCDIC getting translated to an SBCS in ASCII.
When or how would UTF-8 get involved? I don't see how it would.
==================
Mike A Schwab wrote,
There are several different codepages for EBCDIC, because different
programs need different special characters.
And they usually translate to different ASCII codepages for the same reason.
Any chance of using UTF-8?
John P. Hartmann wrote,
I wish you would know about code pages and the various efforts rather
that to reinvent something rather complex.

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

I will try to explain my "gripe" as best I can:


1. I don't understand Git. Sorry, I just don't. I was minimally conversant with SVN, but Git doesn't work the same way. I tried reading the Git manual, but ancient Sanscrit would make more sense to me.


2. As I understand it, Hyperion and the "production" version are not compatible, and are essentially forks. Please forgive me, but I couldn't remember the difference between "sandhawk" and "spinhawk" if someone put a gun to my head, and for the life of me, I don't care and don't want to know. I just want the most current production version, and I am sick of these stupid code names.


3. The "pre-built versions of Hyperion" are evidently also the "bleeding edge" versions and thus not necessarily stable. I have enough problems without worrying if this thing is going to crash on me. It's just not my idea of fun. At least with 3.12 I have a modest degree of assurance that it's actually going to work.


4. The minute I were to privately modify the source of Hyperion, I could introduce bugs of my own; it has been a long time since I looked at Hercules source, and not very much even then, so my confidence level in altering source is not good enough.


5. I don't really WANT to "make the case for the changes to the 4.0 development community". With all due respect, (a) those people don't know me from Adam, and will not be impressed with any "case" I might make; and (b) I don't want to contribute to the rift between the "4.0 development community" and the "3.12 development community", the existence of which I disapprove of. IMHO, there should be one, and only one, development community. The current state of divided efforts, divided loyalties and hurt feelings does nothing but harm the long term interests of the larger Hercules community.


6. Finally, all of the above is besides the point anyway. I don't WANT to invent some new piece of code and try to convince someone to adopt it. The code is already written. All I want is for that piece of code to be made part of production Hercules. I don't want to compile my own code, nor would expect anyone else to have to, either, because it shouldn't have to be that hard. It's asking for an enormous commitment of time and effort for every single Hercules user to have to do a build to incorporate logic that was already written by a Hercules developer (NOT by an "outsider" like me). This is a feature everyone should have, right out of the box.


The most reasonable approach is to confirm that this code works (it did before, and should only require a small test to reconfirm it) and then merge it into the code base, so everyone can benefit from it.

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

Perhaps the politics behind this isn’t obvious but:-

1. All the developers are volunteers. They don’t get paid. They have issues they are finding challenging that affect the normal operation of Hercules. I.e. they don’t have time to be distracted with something only one person wants.
2. Whilst you say the code once worked, I know where it came from and I am pretty sure at least some developers don’t trust it, no matter how simple it is.
(Actually I looked at it. On a multi-cpu set up I am pretty sure it will could introduce undefined behaviour because you can change the code page at any point in time, so what happens to i/o’s that are in process on another on another thread is undefined, but it may be console commands and i/o run in the same thread, I am not sure. The abbreviation of “CP” probably would not be acceptable as it is easily confused with the VM/370 “CP” command. It has also under gone several tweaks and revisions. Any way I don’t think putting it back is simple.)
3. Obviously They are not going to put code in from a source they don’t trust without a reason as they then have to support it.

If you want these changes made you will need to make some effort or provide justification. No one else has asked for them. No one complained when they were removed. If you provide some justification then perhaps someone else might say “that’s useful”, but at present that’s not the case and I can’t see this happening.

Dave
G4UGM

P.S. I see some of the changes are visible in an old SVN here:-

https://sourceforge.net/p/hercules-390/

From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: 02 January 2016 23:41
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-390] Re: What happened to CP_UPDT / CODEPAGE MAINT commands ?





I will try to explain my "gripe" as best I can:

1. I don't understand Git. Sorry, I just don't. I was minimally conversant with SVN, but Git doesn't work the same way. I tried reading the Git manual, but ancient Sanscrit would make more sense to me.

2. As I understand it, Hyperion and the "production" version are not compatible, and are essentially forks. Please forgive me, but I couldn't remember the difference between "sandhawk" and "spinhawk" if someone put a gun to my head, and for the life of me, I don't care and don't want to know. I just want the most current production version, and I am sick of these stupid code names.

3. The "pre-built versions of Hyperion" are evidently also the "bleeding edge" versions and thus not necessarily stable. I have enough problems without worrying if this thing is going to crash on me. It's just not my idea of fun. At least with 3.12 I have a modest degree of assurance that it's actually going to work.

4. The minute I were to privately modify the source of Hyperion, I could introduce bugs of my own; it has been a long time since I looked at Hercules source, and not very much even then, so my confidence level in altering source is not good enough.

5. I don't really WANT to "make the case for the changes to the 4.0 development community". With all due respect, (a) those people don't know me from Adam, and will not be impressed with any "case" I might make; and (b) I don't want to contribute to the rift between the "4.0 development community" and the "3.12 development community", the existence of which I disapprove of. IMHO, there should be one, and only one, development community. The current state of divided efforts, divided loyalties and hurt feelings does nothing but harm the long term interests of the larger Hercules community.

6. Finally, all of the above is besides the point anyway. I don't WANT to invent some new piece of code and try to convince someone to adopt it. The code is already written. All I want is for that piece of code to be made part of production Hercules. I don't want to compile my own code, nor would expect anyone else to have to, either, because it shouldn't have to be that hard. It's asking for an enormous commitment of time and effort for every single Hercules user to have to do a build to incorporate logic that was already written by a Hercules developer (NOT by an "outsider" like me). This is a feature everyone should have, right out of the box.

The most reasonable approach is to confirm that this code works (it did before, and should only require a small test to reconfirm it) and then merge it into the code base, so everyone can benefit from it.

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

Folks,
Please excuse (most of) my twaddle below


1) The changes are in the Hyperion build. It might not be “released” but it is “supported” in so far as any Hercules release is supported.
2) FISH has made windows builds available on his web site. www.softdevlabs.com <http://www.softdevlabs.com>

Until a Version 4 is announced, or you can convince Roger its of general utility and widely tested this is the closest you will get.

Dave
G4UGM

From: Dave Wade [mailto:***@gmail.com]
Sent: 03 January 2016 00:56
To: hercules-***@yahoogroups.com
Subject: RE: [hercules-390] Re: What happened to CP_UPDT / CODEPAGE MAINT commands ?

Perhaps the politics behind this isn’t obvious but:-

1. All the developers are volunteers. They don’t get paid. They have issues they are finding challenging that affect the normal operation of Hercules. I.e. they don’t have time to be distracted with something only one person wants.
2. Whilst you say the code once worked, I know where it came from and I am pretty sure at least some developers don’t trust it, no matter how simple it is.
(Actually I looked at it. On a multi-cpu set up I am pretty sure it will could introduce undefined behaviour because you can change the code page at any point in time, so what happens to i/o’s that are in process on another on another thread is undefined, but it may be console commands and i/o run in the same thread, I am not sure. The abbreviation of “CP” probably would not be acceptable as it is easily confused with the VM/370 “CP” command. It has also under gone several tweaks and revisions. Any way I don’t think putting it back is simple.)
3. Obviously They are not going to put code in from a source they don’t trust without a reason as they then have to support it.

If you want these changes made you will need to make some effort or provide justification. No one else has asked for them. No one complained when they were removed. If you provide some justification then perhaps someone else might say “that’s useful”, but at present that’s not the case and I can’t see this happening.

Dave
G4UGM

P.S. I see some of the changes are visible in an old SVN here:-

https://sourceforge.net/p/hercules-390/

From: hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> [mailto:hercules-***@yahoogroups.com]
Sent: 02 January 2016 23:41
To: hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com>
Subject: Re: [hercules-390] Re: What happened to CP_UPDT / CODEPAGE MAINT commands ?





I will try to explain my "gripe" as best I can:

1. I don't understand Git. Sorry, I just don't. I was minimally conversant with SVN, but Git doesn't work the same way. I tried reading the Git manual, but ancient Sanscrit would make more sense to me.

2. As I understand it, Hyperion and the "production" version are not compatible, and are essentially forks. Please forgive me, but I couldn't remember the difference between "sandhawk" and "spinhawk" if someone put a gun to my head, and for the life of me, I don't care and don't want to know. I just want the most current production version, and I am sick of these stupid code names.

3. The "pre-built versions of Hyperion" are evidently also the "bleeding edge" versions and thus not necessarily stable. I have enough problems without worrying if this thing is going to crash on me. It's just not my idea of fun. At least with 3.12 I have a modest degree of assurance that it's actually going to work.

4. The minute I were to privately modify the source of Hyperion, I could introduce bugs of my own; it has been a long time since I looked at Hercules source, and not very much even then, so my confidence level in altering source is not good enough.

5. I don't really WANT to "make the case for the changes to the 4.0 development community". With all due respect, (a) those people don't know me from Adam, and will not be impressed with any "case" I might make; and (b) I don't want to contribute to the rift between the "4.0 development community" and the "3.12 development community", the existence of which I disapprove of. IMHO, there should be one, and only one, development community. The current state of divided efforts, divided loyalties and hurt feelings does nothing but harm the long term interests of the larger Hercules community.

6. Finally, all of the above is besides the point anyway. I don't WANT to invent some new piece of code and try to convince someone to adopt it. The code is already written. All I want is for that piece of code to be made part of production Hercules. I don't want to compile my own code, nor would expect anyone else to have to, either, because it shouldn't have to be that hard. It's asking for an enormous commitment of time and effort for every single Hercules user to have to do a build to incorporate logic that was already written by a Hercules developer (NOT by an "outsider" like me). This is a feature everyone should have, right out of the box.

The most reasonable approach is to confirm that this code works (it did before, and should only require a small test to reconfirm it) and then merge it into the code base, so everyone can benefit from it.

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

I have just been informed that what Roger requires to be convinced of the general utility of this feature is 3,000 euros.


As I cannot afford to be that convincing, I would say that's the end of this topic.