Hercules on Mac OSX
Paul A. Scott
Nov 19, 2001
The screenprint I uploaded to Yahoo! Groups does indeed show Hercules
running natively on Mac OSX. The machine is a dual-800 Mhz powerpc G4
processor. I had a heck of a time getting it to run, and I completely
ripped out the SCSI tape support because a) I don't need it, and b) it
used linux-only code that would take too much of my time to
rewrite.
Now that it's running, in retrospect it was pretty easy to do, but the
process was tedious. However, I learned a lot and can now find my way
around the code pretty well.
The only pthread support missing from OSX (that Hercules uses,
anyway - since there's really a whole bunch of missing pthread
stuff that Apple is working on to implement) is
pthread_kill(). However, pthread_kill() isn't strictly
required by Hercules. The only other pthread issue I ran into was that
the pthread implementation in OSX and FreeBSD does not automatically
increase the thread's stack when it overflows, like for
processes. This produced some strange effects when using gdb to shoot
the problem. In any case, I added code to set the thread's stack size
and voila! no more pthread issues.
The select() call didn't seem to work on the console fd, and the
console would hang. However, rather than spend the time figuring out
why, I simply inverted the #ifdef for WIN32 support so the
select() times out.
Rather than go through all the changes one by one, I'll upload a set
of diffs to Yahoo! Groups. All in all, the changes are rather small,
but remember I've ripped out the (real) SCSI tape handling. Emulated
tapes work, though.
One strange thing I found was with a CKD volume. When the volume was
un-compressed, IPL was not possible as lseek errors occured. However,
when I used ckd2cckd to compress the volume and re-IPL, i got no more
errors and the IPL succeded. I suspect there's a bug in the
non-compressed CKD handling. However, it must be rather obscure,
because it only affects one of the 6 CKD volumes on OS/390. If no one
else looks into this problem, perhaps I will, but I'm in no hurry
because of the workaround. VM runs without a hitch but I'm using only
FBA devices there.
I don't have any benchmarks available, but I've seen the MIPS rate go
over 12 MIPS, although that's probably not a very useful indicator. On
a more subjective level, it FEELS like it runs as fast, maybe a little
faster than my P/390 box. The P/330 box might out pace hercules,
though. I'll have to run side-by-side comparisons, or get a benchmark
program to be certain.
Look for a set of diffs on Yahoo! Groups shortly.
Paul A. Scott
mailto:pscott@...
http://www.the-frontier.org/pscott/
4:58 pm
Re: Hercules on Mac OSX
zenith89@...
Nov 19, 2001
Thanks very much for getting Herc to run on OS X. I have a dumb
question for you... I actually am not running OS X yet (I'm still on
OS 8 and 9), so I'm curious as to what you used for a 3270 client. Is
there one built into OS X?
...CPV
--- In hercules-390@y..., "Paul A. Scott" <pscott@t...> wrote:
> The screenprint I uploaded to Yahoo! Groups does indeed show
Hercules
> running natively on Mac OSX. (snip)
8:21 pm
Re: Hercules on Mac OSX
Paul A. Scott
Nov 19, 2001
Since so many have asked offline, I'm posting this to the list.
Basic steps to compile hercules on MacOSX.
1. First, get the latest CVS sources (no password when you login)
setenv CVSROOT :pserver:anonymous@...:/usr/cvs/hercules
cvs login
cvs co hercules
cvs logout
2. You'll first need to get and install the latest "autoconf" and
"automake" software per the hercules INSTALL instructions.
3. Then cd to hercules and run "sh autogen.sh".
4. Then, apply all the patches, including the one to the configure
script. You can't do this until you've run step 3 successfully. If you
ever run step 3 again, you'll need to re-apply the configure patch.
5. Then run "./configure CPPFLAGS=-traditional-cpp LIBS=-pthread"
6. Finally, do a "make hercules". Note that I haven't patched any of
the stand-alone tape programs, so you can't simply do a
"make". However, you can do things like "make ckd2cckd", and probably
will want to (see my other posts on the list).
7 Fire up hercules, and IPL your favorite OS or SA utility.
Enjoy,
Paul
Paul A. Scott
mailto:pscott@...
http://www.the-frontier.org/pscott/
10:44 pm
Re: Hercules on Mac OSX
pscott@...
Nov 19, 2001
--- In hercules-390@y..., zenith89@h... wrote:
> I'm curious as to what you used for a 3270 client. Is
> there one built into OS X?
>
> ...CPV
You can get a rootless X server running on MacOSX very easily. Visit
http://www.xfree86.org for a MacOSX download.
Then you can simply build and compile the sources for x3270, which is
available just about anywhere. Try this link for one:
ftp://crl.dec.com/pub/X11/contrib/applications/x3270-3.1.1.6.tar.gz
11:02 pm
Re: Hercules on Mac OSX
Matt Zimmerman
Nov 19, 2001
On Mon, Nov 19, 2001 at 02:44:43PM -0800, Paul A. Scott wrote:
> Since so many have asked offline, I'm posting this to the list.
>
> Basic steps to compile hercules on MacOSX.
> [...]
> 2. You'll first need to get and install the latest "autoconf" and
> "automake" software per the hercules INSTALL instructions.
This shouldn't be necessary with current CVS, since the auto-generated files
are pre-generated and checked in. Of course, it's still a good idea.
> 3. Then cd to hercules and run "sh autogen.sh".
>
> 4. Then, apply all the patches, including the one to the configure
> script. You can't do this until you've run step 3 successfully. If you
> ever run step 3 again, you'll need to re-apply the configure patch.
This sounds suspicious. If configure needs to be modified, your patch
should be against configure.ac, which will then generate configure (in which
case you should do it before running autogen.sh, to avoid running autoconf
twice). Since configure will be generated differently by different versions
of autoconf (and possibly with different local macros) your patch won't
necessarily work if it changes configure directly.
Can you make your patches available somewhere besides Yahoo? If you like,
you can send them to me via private email and I will put them up. I would
like to see what changes you have made, and integrate them into Hercules
proper.
--
- mdz
11:52 pm
Re: Hercules on Mac OSX
pscott@...
Nov 20, 2001
--- In hercules-390@y..., Matt Zimmerman <mdz@c...> wrote:
> This sounds suspicious. If configure needs to be modified,
your patch
> should be against configure.ac, which will then generate
configure (in which
> case you should do it before running autogen.sh, to avoid
running autoconf
> twice). Since configure will be generated differently by different
versions
> of autoconf (and possibly with different local macros) your
patch won't
> necessarily work if it changes configure directly.
Well, at this moment in time, what I said should work since we're
talking about specific versions of autoconf and MacOSX and
hercules. You are correct, though, it's not a good long-term
solution.
The problem originates with Apples implementation of sh and
the handling of CDPATH and cd. All other implementations of sh
that I've tested (and apparently by the autoconf people) don't
echo the path when CDPATH exists and cd is processed (except
under clearly defined conditions), which is why autoconf does
(cd;pwd). However, Apple's sh echoes the path on cd when used
with CDPATH.
Now, do we get Apple to fix this, or get the autoconf maintainers
to support Apple. My preference is the former, but either way my
fix is only a temporary solution for those who want to build
hercules "pronto".
Paul A. Scott
mailto:pscott@...
http://www.the-frontier.org/pscott/
5:08 am
Re: Hercules on Mac OSX
Matt Zimmerman
Nov 20, 2001
On Tue, Nov 20, 2001 at 05:08:37AM -0000, pscott@... wrote:
> Well, at this moment in time, what I said should work since we're talking
> about specific versions of autoconf and MacOSX and hercules. You are
> correct, though, it's not a good long-term solution.
>
> The problem originates with Apples implementation of sh and the handling
> of CDPATH and cd. All other implementations of sh that I've tested (and
> apparently by the autoconf people) don't echo the path when CDPATH exists
> and cd is processed (except under clearly defined conditions), which is
> why autoconf does (cd;pwd). However, Apple's sh echoes the path on cd when
> used with CDPATH.
>
> Now, do we get Apple to fix this, or get the autoconf maintainers to
> support Apple. My preference is the former, but either way my fix is only
> a temporary solution for those who want to build hercules "pronto".
Does Apple claim to support POSIX, SUS or some other standard? If so, they
are probably violating something somewhere by doing this. Since that could
take forever, the short-term options are to port a POSIX shell (such as ash)
to OS X and use that, or to hack up autoconf. Have you tried building ash
there? ftp.netbsd.org should have the source; if not, you can grab it from
Debian:
http://http.us.debian.org/debian/pool/main/a/ash/ash_0.3.8.orig.tar.gz
--
- mdz
5:22 am
Re: Hercules on Mac OSX
pscott@...
Nov 20, 2001
--- In hercules-390@y..., Matt Zimmerman <mdz@c...> wrote:
> This sounds suspicious. If configure needs to be modified,
> your patch should be against configure.ac, which will then
> generate configure (in which case you should do it before
> running autogen.sh, to avoid running autoconf
> twice). Since configure will be generated differently by different
> versions of autoconf (and possibly with different local macros)
> your patch won't necessarily work if it changes configure
> directly.
I forgot to mention that if I recall correctly, this was not something
that could be fixed with a local configuration. I think the code is
within autoconf itself, so that I could either patch autoconf or the
resulting configure script. I chose the latter because a) it's a
quick fix anyway, b) the real problem can be traced to Apple's sh
rather than autoconf per se, and c) finding the right place in
autoconf to patch was a lot harder than the path I took.
Of course, if the autoconf folks patched their stuff to generate
what I did, it would be a universal solution. However, I'd rather
shake Apple's tree (hmmm) than the autoconf tree, because
Apple did it wrong.
Paul A. Scott
mailto:pscott@...
http://www.the-frontier.org/pscott/
5:28 am
Re: Hercules on Mac OSX
Matt Zimmerman
Nov 20, 2001
On Tue, Nov 20, 2001 at 05:28:22AM -0000, pscott@... wrote:
> I forgot to mention that if I recall correctly, this was not something
> that could be fixed with a local configuration. I think the code is within
> autoconf itself, so that I could either patch autoconf or the resulting
> configure script. I chose the latter because a) it's a quick fix anyway,
> b) the real problem can be traced to Apple's sh rather than autoconf per
> se, and c) finding the right place in autoconf to patch was a lot harder
> than the path I took.
>
> Of course, if the autoconf folks patched their stuff to generate what I
> did, it would be a universal solution. However, I'd rather shake Apple's
> tree (hmmm) than the autoconf tree, because Apple did it wrong.
I agree. Not having been able to view your diff yet, I misunderstood your
purpose in patching configure.
--
- mdz
5:41 am
Re: Hercules on Mac OSX
pscott@...
Nov 20, 2001
--- In hercules-390@y..., Matt Zimmerman <mdz@c...> wrote:
> Does Apple claim to support POSIX, SUS or some other
> standard? If so, they are probably violating something
> somewhere by doing this.
This is from OSX sh man page:
The sh utility is the standard command interpreter for the
system. The current version of sh is in the process of being
changed to conform with the IEEE Std1003.2 (``POSIX.2'')
specification for the shell. This version has many features which
make it appear similar in some respects to the Korn shell, but it
is not a Korn shell clone like pdksh(1). Only features designated
by POSIX, plus a few Berkeley extensions, are being
incorporated into this shell.
> Since that could take forever,
Gosh, I hope not! I'm going to report this as a bug on their
developer bug report data base.
> the short-term options are to port a POSIX shell (such as ash)
> to OS X and use that, or to hack up autoconf.
Yup. Or if you're *really* in a hurry, apply my patch to configure. :)
Paul A. Scott
mailto:pscott@...
http://www.the-frontier.org.pscott/
5:41 am
Re: Hercules on Mac OSX
rvjansen@...
Nov 22, 2001
On Monday, November 19, 2001, at 11:44 , Paul A. Scott wrote:
>
> 2. You'll first need to get and install the latest "autoconf" and
> "automake" software per the hercules INSTALL instructions.
>
>
>
Paul,
this is where I got stuck; both autoconf and automake give sed errors
when running ./configure. Do we need to have other stuff installed to
make this work?
I have macosx 10.1.1 & the 10.1 dev kit. Why this bleeding edge stuff?
Do you have gnu sed? m4?
thanks in advance
Rene Jansen
Amsterdam
11:12 pm
Re: Hercules on Mac OSX
pscott@...
Nov 23, 2001
> this is where I got stuck; both autoconf and automake give
> sed errors when running ./configure. [...] I have macosx 10.1.1
> & the 10.1 dev kit.
If you have installed autoconf 2.52 and automake 1.5 along with
MaxOSX10.1, then all you need to do is apply the patch I provided
to the configure script *after* you run "sh autogen.sh". If you ever
regenerate the configure script, then you'll need to re-apply my
patch to configure. I have not attempted a more elegant solution
because the problem will disappear when Apple fixes their sh.
Paul
mailto:pscott@...
http://www.the-frontier.org/pscott/
6:35 am
Re: Hercules on Mac OSX
rvjansen@...
Nov 23, 2001
On Friday, November 23, 2001, at 07:35 , pscott@... wrote:
> > this is where I got stuck; both autoconf and automake give
> > sed errors when running ./configure. [...] I have macosx 10.1.1
> > & the 10.1 dev kit.
>
> If you have installed autoconf 2.52 and automake 1.5 along with
Sorry if I was not clear; but I got stuck installing automake &
autoconf; it is their install that gives trouble; you did this on
10.0.4? Do you have GNU m4 like the docs of autoconf say, or do you use
apple's? It is terrible that I'm nearly there and cannot proceed.
Obviously I share some of the criticism on using too new stuff.
bye
7:57 am
Re: Hercules on Mac OSX
Matt Zimmerman
Nov 23, 2001
On Fri, Nov 23, 2001 at 08:57:41AM +0100, rvjansen@... wrote:
> Obviously I share some of the criticism on using too new stuff.
As Paul pointed out, this is a bug in Apple's shell. Please don't make a
scapegoat of autoconf, automake or the Hercules build system derived from
them, for other programs' bugs.
--
- mdz
8:53 am
Re: Hercules on Mac OSX
Roger Bowler
Nov 23, 2001
--- In hercules-390@y..., Matt Zimmerman <mdz@c...> wrote:
> Please don't make a scapegoat of autoconf, automake or
> the Hercules build system derived from them, for other
> programs' bugs.
Well now hold on a sec. Autoconf was touted as being worth the pain
because it allows Hercules to be ported to any flavour of Unix
whatever its quirks (or bugs if you like). Now you are saying that
the quirks need to be acceptable to autoconf.
Let's face it, Unix is a mess, which is the reason why autoconf
exists. During the 1990's I watched opensource projects (Samba
springs to mind) bogging themselves down in spaghetti as they
attempted to support every possible variant of Unix. Don't get me
wrong, Samba is a terrific feat of engineering. But supporting
multiple Unix platforms soaks up the valuable time of skilled
engineers, time which in my judgement is better spent developing the
functionality of the core product.
That's why I took a design decision right at the beginning that
Hercules would run on just one platform, and I chose Linux as the
most suitable one for the job. As I have stated previously, Hercules
is designed to run standalone on its own dedicated machine. You
dedicate a machine, you install Linux, and you run Hercules.
Multiplatform support is only necessary if you want Hercules to
coexist on a machine with other users or applications. This isn't
how it was intended to be.
Opponents of autoconf have been characterized as being old-fashioned
and resistant to new ideas, but sometimes there are good reasons for
rejecting new methods. I am not against autoconf because it is new
(it isn't), or because I don't know what it is. I looked at it
before starting the project, predicted the consequences, and decided
against it.
Roger Bowler
2:06 pm
Re: Hercules on Mac OSX
Matt Zimmerman
Nov 23, 2001
On Fri, Nov 23, 2001 at 02:06:38PM -0000, Roger Bowler wrote:
> --- In hercules-390@y..., Matt Zimmerman <mdz@c...> wrote:
> > Please don't make a scapegoat of autoconf, automake or the Hercules
> > build system derived from them, for other programs' bugs.
>
> Well now hold on a sec. Autoconf was touted as being worth the pain
> because it allows Hercules to be ported to any flavour of Unix whatever
> its quirks (or bugs if you like). Now you are saying that the quirks need
> to be acceptable to autoconf.
No, that is not what I am saying, and I would appreciate if you would allow
me to decide what it is that I am saying. The phrase "straw man" springs to
mind.
MacOS X is just about the newest UNIX-like platform out there, and it turns
out (unsurprisingly) that it has bugs that nobody had anticipated before.
Nobody ever said that autoconf was magical or precognitive, though it does
know how to deal with the same bugs on many platforms.
Also, even though autoconf is able to deal with some pretty severe bugs in
the underlying OS, that doesn't mean that these bugs are OK. If autoconf
isn't able to deal with a certain bug (yet), that is still a bug in the OS,
and only a missing feature in autoconf.
Do you consider it a bug in Hercules that it doesn't build uchanged on MacOS
X?
> Let's face it, Unix is a mess, which is the reason why autoconf exists.
> During the 1990's I watched opensource projects (Samba springs to mind)
> bogging themselves down in spaghetti as they attempted to support every
> possible variant of Unix. Don't get me wrong, Samba is a terrific feat of
> engineering. But supporting multiple Unix platforms soaks up the valuable
> time of skilled engineers, time which in my judgement is better spent
> developing the functionality of the core product.
Folks who are now running Samba on Linux/390 right now would very much
disagree with your opinion. They are able to do what they are doing because
a couple of large Free Software projects put some effort into portability.
The Linux/390 port itself might never have happened if some porting
infrastructure hadn't been introduced into Linux for, e.g. the Alpha.
> That's why I took a design decision right at the beginning that Hercules
> would run on just one platform, and I chose Linux as the most suitable one
> for the job. As I have stated previously, Hercules is designed to run
> standalone on its own dedicated machine. You dedicate a machine, you
> install Linux, and you run Hercules. Multiplatform support is only
> necessary if you want Hercules to coexist on a machine with other users or
> applications. This isn't how it was intended to be.
First of all, Hercules has run on multiple platforms for quite a while now,
I understand. You can't blame me OR autoconf for that one. Arguing against
porting is pointless, because Hercules is already being ported.
I would be willing to wager that most of the people working on Hercules
don't have an entire system dedicated to it, so claiming that that is the
only recommended configuration is just a little bit ridiculous.
Furthermore, multiplatform support has nothing to do with multiuser systems.
Dedicating an Intel/Linux system is no different from dedicating an
Intel/Solaris system or an ia64/Linux system.
> Opponents of autoconf have been characterized as being old-fashioned and
> resistant to new ideas, but sometimes there are good reasons for rejecting
> new methods. I am not against autoconf because it is new (it isn't), or
> because I don't know what it is. I looked at it before starting the
> project, predicted the consequences, and decided against it.
You are against autoconf because you are against porting, that much is
clear. Others have their own reasons.
--
- mdz
9:23 pm
Re: Hercules on Mac OSX
Roger Bowler
Nov 25, 2001
--- In hercules-390@y..., Matt Zimmerman <mdz@c...> wrote:
> I would be willing to wager that most of the people working
> on Hercules don't have an entire system dedicated to it, so
> claiming that that is the only recommended configuration is
> just a little bit ridiculous.
Well, excuuuse me.
Roger Bowler
1:35 am
Copyright 2001