steve smithers wrote:
Mark Morgan Lloyd wrote on Mon, 30 Jan 2012 21:46:28 +0000
Although Linux/390 is closer to what the bulk of us are used to, so
please humour us.
I am a Linux user so I am sympathetic. It's just that I really don't do
development on Linux and am therefore unaware of it's requirements.
One question if I may, and I hope this doesn't sound too stupid. When
Paul Robinson first raised an S/390 port a few days ago, he proposed
using MUSIC/SP as his target operating system. This has the advantages
that it's free and has TCP/IP, but the major disadvantage that the prime
maintainer is... no longer active. I find it difficult keeping track of
things on account of the name changes over the years: what is the
situation as regards OS, is there a free version that can be run locally
under (e.g.) Hercules, or would anybody who wanted to look at what you
were up to have to have a login account on a mainframe somewhere? Or
does MUSIC/SP have any/adequate binary compatibility?
Why should it sound stupid? I've spent 25 years doing this stuff, I can't
reasonably expect everyone else to know how it works.
MUSIC/SP as I understand it (from wikipedia I'm afraid) was a proprietry time
sharing system writtem by McGill university in the states. It's sole use to
us in this discussion was that it had an OS/VS1 emulation mode. OS/VS1 had
no terminal based development environment at all (at least not a standard IBM
one. It did, later, have systems called TONE and ROSCOE). I think Paul chose
this because he either knew it was available or because it was the system
he used to use. OS/VS1 has hideous storage limitations by todays standards.
However, this emulation mode should give us a good binary comatibilty level
storage limitations allowing.
I think in the current context the binary compatibility is the important
thing.
Hercules can run all, or almost all, IBM OS systems. from OS/MFT - OS/MVT
from the 1960's up to the latest z/OS 64 bit systems. The problem is with
licensing. The ones we can run legally are OS/MFT, OS/MVT, OS/VS2, MVS 3.8
along with various others such as early DOS and VM systems and MUSIC/SP. All
of these are free.
These, generally, don't have TCP/IP yet, but Hercules provides us with TCP/IP
connection using TN3270 (telnet in 3270 mode) so we can use Linux or Windows
based terminal emulators such as x3270 to connect to the guests. People are
working on a TCP/IP stack for MVS.
With the major limitation here that MUSIC/SP- and possibly other
operating systems- don't have TCP/IP unless the underlying platform
supports IUCV; Hercules (freely available to everyone) doesn't implement
IUCV unless VM (not freely available) is running on top of it. Linux
appears to get around this restriction by using a simulated SLIP connection.
It's also possible to have a logon to a remote MVS system running inside a
window running in your favourite web browser. I can't find it on the web
at the moment and I don't know what version of MVS it used, but I will keep
an eye out for it.
But as I understand it JCL is distinct from binary programs- different
areas of application, different facilities. On the unix-derived systems
that most of us are more used to there is no such distinction: a shell
script has access to all the facilities that a binary has, you could (in
principle) write a compiler in it.
But we don't need to write a compiler, we just need to feed various source
programs into a compiler and assemble and linkedit the resulting output with
a modicum of "intelligence" to stop on errors. This is what JCL does.
Think of it as using a pipe to link the output of one program into the input
of another, just not as straightforward.
Sorry, you've missed my point. I've come across systems where compilers
have to be "blessed" by the local security administrator before they can
mark code as executable, and there's a progressively stronger chain up
to the point where nobody except that manufacturer can bless a compiler
such that it can generate the operating system kernel. The objective is
to try to avoid the situation described by Ken Thompson in his 1984
"Trusting Trust" paper http://cm.bell-labs.com/who/ken/trust.html
Unix does not have this mechanism: anybody can build a compiler which
can then build a new kernel.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
