| Newsgroups |
gmane.comp.emulators.hercules390.mvs |
| Message-ID |
<[email protected]> |
---In [email protected], <bumens@...> wrote :
> I think there is a misunderstanding. POSIX is not
> only for Unix systems. It's an API definition.
There is a reason why the C standard doesn't
simply get expanded to include the POSIX
API. It is not a good match for MVS. MVS files
can't be stat'ed to find out the file size or
permissions (don't exist). What exists is what
is covered by the C standards. E.g. you can
do an fopen("dd:in", "r") to read data from the
DDNAME "IN" in your JCL.
> I see no reason why a POSIX API should not
> be possible for MVS.
There's no such thing as fork() in MVS either.
It's not a good match for MVS. *C* is a good
match.
But let's negotiate.
> If you've got implemented a libc then most likely
> you're already close to have POSIX implemented.
I don't think so. Although I am planning on
updating PDPCLIB to handle "/" in filenames
and convert them into MVS dataset names.
> I tried to update my TK4- system to MVS/380.
> Unfortunately, I did not succeed yet. I stopped
> working on it when I started dealing with z/OS.
> If you've got a howto with description how to
> update TK4- to MVS/380 I'd be happy.
There is a readme.txt in this archive:
https://sourceforge.net/projects/mvs380/files/mvs380/MVS_380%202.0/mvs380-2_0-core.zip/download
Let me know if you have any difficulties.
For some reason with TK4- you can't use
TSO while running a 31-bit batch job. I
suspect there is a clash on the ASCBRV44
field. I don't have that problem with TK3UPD
or the MVS/380 that I built against it here:
https://sourceforge.net/projects/mvs380/files/mvs380/MVS_380%202.0/mvs380-2_0.zip/download
which includes the latest GCCMVS which has
a significant advance.
> I saw your GCC in it. It works like a charm, thank you for this!
I'd like to say "no problem", but it was a hell of a
problem to get it to work. :-)
> You have got a point here: at least making some
> intermediate steps it should be possible to use
> your GCC to port a modern version of it onto
> your platform. The porting effort will not be small,
> though. We're in C++ ages. And this is requiring
> to port libstdc++, too, as well as having an
> implementation of C++ exceptions for MVS. This
> is quite some work – while it's possible, of course.
Ok. No-one has volunteered to do C++ yet.
And I'm still working on C90.
> I think you're mistaken: GCC is not only containing
> C90 code any more. At least I'd not bet on it. But
> this does not matter.
Right.
> I can recommend to talk to the GCC guys about
> this topic:
I'd like to chat to you first, about this POSIX
vs ISO C targeting.
> Your platform is deserving support.
Native MVS deserves support. All platforms deserve
support, not just POSIX ones. That's what the C
standard is for. It says what is actually possible
cross-platform. If an application fundamentally
just reads in a bunch of files and writes out
another bunch of files, it should be possible to
do while conforming to the C standard. And I
would like to see freeware providing a standard
C target by default instead of assuming Posix
is available. Note that I did exactly this with
GCC - turning it into a C90-compliant
application first.
BFN. Paul.