[fpc-devel] Re: EBCDIC (was On a port of Free Pascal to the IBM 370)

[Mark Morgan Lloyd]

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]