I've made a few more comments below.
On 16 October 2015 at 22:37, ***@yahoo.com.au [hercules-390] <
> > I can see why Paul would want to have done
> > it in the first place maybe as a challenge and
> > an academic exercise,
> It was never an academic exercise. Note
> that GCC work was being done way back
> around 2004. I did not have direct access
> to a z/OS system, so I was unable to
> natively build all of GCC.
> > but I just don't see
> > the need to be able to compile large C
> > programs on a historically non-existent platform/architecture.
> What choice did I have back in 2004?
> How could I develop z/OS software
> without direct access to z/OS?
Not really sure why you would want to develop software for z/OS if you
haven't got z/OS to run it on.
MVS/380 will always be missing lots of z/OS sub-systems and facilities.
> > If it's purely for C programming then I
> > believe Paul (and everyone else) has
> > access to many freely available
> > environments that are much better
> > suited to that purpose.
> Not that exercise MVS functionality such
> as opening members of a PDS
Agreed - that's MVS functionality not z/OS functionality, in fact it goes
back to OS/360.
PDS/Es are a different beast altogether though.
> > The FanDeZhi system is available (as long
> > as you behave) if you want to compile C
> > programs in a z/OS environment.
> When did this become available?
Don't know - been around at least a few years though.
> Also note that I do my GCCMVS builds
> completely automated. At the Windows
> prompt I just type "allmvs" and then
> come back in a couple of hours to see
> what happened.
I don't think you could run your automated GCCMVS build system the same way
as you do now on MVS/380 though as I guess there is no equivalent access to
a card reader.
However, you could probably just submit the jobs from ISPF or automate it
> Also, it is my desire that MVS/380 be
> able to be used as a commercial
> platform. I don't think a company
> would be willing to run their business
> on FanDeZhi with the potential for
> access to be denied at any time.
I'm not sure there would be many takers for running a production workload
> > There is also HLASM, COBOL and PL/I
> > as well as the standard CLIST, REXX and
> > full-blown ISPF Dialog Manager, so it's
> > a far better mainframe programmers
> > playground, with no "bootlegging" required!
> Well, some people may like a playground
> they can IPL themselves etc.
I agree that having your own system is a better playground, as you can do
what you want when you want.
It's nice to be able to play Sysprog!
But the FanDeZhi system is the closest thing to a free z/OS bureau service
that I know of.
> > If itâs for developing and testing GCCMVS
> > and PDPCLIB then I believe the FanDeZhi
> > system could be used for this also,
> Certainly it is great to have access to a
> z/OS system. Normally I need to ask
> someone else to try things for me.
It would definitely be useful for your testing and you may even find it
useful as a development environment.
> > and Iâm guessing you would be able to
> > compile and link for executing on
> > MVS3.8J if you really wanted to.
> I'm not sure you can take z/OS load
> modules and run them on MVS 3.8j.
> However, the reverse is possible. I
> can and do produce modules on
> MVS/380 and they run fine on both
> MVS 3.8j and z/OS.
The question about the load modules is interesting.
If the load library on z/OS is a PDS rather than a PDS/E and the block size
is MVS3.8J "friendly" and the only other routines that are linked in are
from PDPCLIB (no language environment etc) then I wonder if they would load
OK on MVS3.8J?
I guess it would be dependent on the non-text records in the load module
being in a format that MVS3.8J understands.
Anyone know for sure? I don't have MVS3.8J or GCCMVS/PDPCLIB on z/OS to
> BFN. Paul.