[Info-vax] The (now lost) future of Alpha.

[Tim Sneddon]

invalid <address at is.invalid> wrote:
> On 2018-08-02, Arne Vajh??j <arne at vajhoej.dk> wrote:
>> On 8/1/2018 3:16 PM, invalid wrote:
>>> To answer your point elsewhere that you're hearing from other sources
>>> DB/2 is written in C: if you can't build a compiler framework due to
>>> differences in *versions* of Linux, imagine how dumb it is to suggest it
>>> would be easy or even reasonable to port DB/2 written in C on a mainframe
>>> (which it is not, to the best of my knowledge) to other completely
>>> dissimilar platforms.
>>
>> Well - that strategy is used successfully by thousands and thousands
>> of applications to support very dissimilar platforms.
>>
>>> I don't work with DB/2 so I don't know. But I listened in on a meeting
>>> recently with a guy who does work with DB/2 every day and has for a few
>>> decades. He works in a vendor software DB/2 utilities team. The question of
>>> whether DB/2 is written in C came up. This guy told us, from the dumps he
>>> has seen he has no evidence DB/2 has any significant amount of code in C. He
>>> said he has not seen any evidence at all, but of course he realizes he may
>>> have missed something and does not see everything. So he doesn't rule out
>>> there might be some C, but as far as he has seen there is not any. This
>>> discussion is entirely about DB/2 running on z/OS. I don't know and I don't
>>> care about DB/2 for spintel, DB/2 for Linux on Z etc. I'm talking about the
>>> real, core DB/2 that started on mainframes.
>>
>> An anonymous person quoting another anonymous person.
> 
> You can judge from my other posts on IBM whether I know what I'm talking
> about or not. Or maybe *you* can't, but I suspect other people can.
> 
> If I call myself Arne does it help?
> 
> The IBM world is full of trade secrets, NDAs, and proprietary info.
> 
>>
>>> You guys need to understand z/Arch and z/OS are built entirely around
>>> assembler. There is *no* direct system interface except in assembler and
>>> PL/X. And it is only from around z/OS 1.10 (2.3 just came out and 1.13 was
>>> the last of the 1. series) where there was a C compiler capable of running
>>> with no runtime and being able to support inline assembler to call systems
>>> services since C cannot do it directly. And it is only in the very recent
>>> past IBM has started to try to create header files for all the systems
>>> services (nothing has been released yet) and we only know it by
>>> accident. But it's a huge job and far from complete. When it is done, then
>>> it will be physically possible and feasible to write compilers in C. But no
>>> reasonable person would suggest they would be willing to take a chance on
>>> breaking their enterprise clients applications just so they can say their
>>> compilers were written in C.
>>
>> Well - a compiler can be written in pure C with no system calls at all
>> beyond the C RTL.
> 
> No, a compiler in the IBM world needs storage and other systems services so
> it is OS specific. z/OS is not a POSIX OS although it has POSIX component;
> POSIX is not in the picture for normal mainframe languages, not at
> compilation time and not at runtime.
> 

A compiler in any environment needs storage.  So, coupled with your other
statements, what you're saying is that a compiler needs to be written at
operating system level because it needs storage?

Tell me, how do other applications work?  Are they all written at assembler
level too?  They would need storage.  Seems like IBM have wasted a lot of
time writing compilers...given your arguments I can't actually see a
purpose for them.

Regards, Tim.