Re: gnu utilities for MVS and CMS

[Paul Edwards]

> That seems reasonable, so it is now up to you to figure out why configure
> is not finding install-sh.  Another thing to consider - why not run
> configure on your MVS machine for a native build, rather than trying to
> run it on Windows for a cross-compile build?  If MVS has a reasonably
> portable sh implementation, then that would be the way to go.

MVS is an IBM mainframe.  It doesn't have sh ported to it.
At least not the version of MVS that is freely available.

> > I guess it's just a case of a different philosophy.  I like and expect
> > C89-compliant code to be provided so that all I need to do is zip
> > up some files,
>
> It sounds like what you are asking is for some pre-configured files for a
> free-standing C89 environment.

No, it's just an alien *hosted* C89 envrionment.  If you go and read
the C89 standard for hosted environments, it complies to everything
there.  That means if your program assumes that the first parameter
to fopen can have a "/" in it - it will not necessarily work (and in this
case, definitely not work - since MVS doesn't use / in filenames and
has no concept of directories).

> But GNU software does not go out of the
> way to target free-standing environments - it is much easier to develop
> code when we can rely on hosted environments, with POSIX and other
> extensions above and beyond what C89 guarantees.  There is a difference
> between limiting yourself to only the functions guaranteed by C89 (m4 does
> not do this, nor do I want to bend over backwards trying to do so), and
> limiting yourself to the features guaranteed by a C89 compiler (m4 does
> this; if you have a C89 compiler that can't compile m4 after a successful
> ./configure run, then that is a bug we need to fix).

MVS is not a Posix environment.  It doesn't have a hierarchical
file system, the ability to fork processes etc.  C89 was designed
to be portable to the wide variety of OSes out there, rather than
be Unix-specific.  In that, it has succeeded.

> > These extra hoops are similar to
> > running an ANSI2K&R translator on an alien system because
> > the compiler you actually have is not C89-compliant, only
> > K&R.
>
> At one point, GNU projects still promised K&R compilation.  But that day
> has come and gone;

Right.  And even when they were doing that, they were still using
all the POSIX extensions which aren't guaranteed even by C89.
I never saw the point in that.

> C89 is 20 years old now

And after 20 years, we are only just getting that completely covered.
In real life, people are having to program in a non-C language because
they can't justify the cost of a C compiler.

Only now do they have one available on MVS.  And CMS.  The only
reasonably important OS that I know of remaining is DOS/VSE.
Which shouldn't be a large change from the MVS version.

> so within the past 5 years, we
> quit trying to support K&R compilers as a waste of valuable volunteer
> time.

Sure.  Time to upgrade to C89.  Not all the way to the alien Posix
system though.

And C99 isn't implemented fully everywhere so not a reasonable
one to use either.

C89 is the way to go.  That is what is portable.

> You may be right with your claims that porting modern software to
> MVS is a lost cause.

Don't know about "modern".  C89-compliant code is not a lost cause,
and a slew of software has been ported after we finally implemented
a C89 compiler.  Depends on whether the author stuck to C89 or
added in a whole lot of unnecessary non-C89 stuff.  It is rarely
necessary to use open instead of fopen, but for whatever reason,
people insist on tying it down to a Posix system instead of making
it portable everywhere.  But that's always been the case.  People
did it on MSDOS too, precluding use on Unix.

Anyway, I'm happy with M4 version 1.4.  Minimal changes required
to take the source and get it up and running on a completely
alien *hosted* C89 environment that happens to have no extensions.
Well, there are some extensions such as __eplist if you wish to
access the raw EPLIST that the CMS operating system provided.
But I don't think that's of much use to you.  And I don't use it myself,
because I know that if I do use it, the code won't port to a hosted
Unix environment.

I've had mainframe people tell me to just write various code using
record I/O and I similarly tell them that that isn't available in Unix.
They think that is strange too.  Unix?!  Who cares about Unix?

C89 covers everything.

BFN.  Paul.