开云体育

>
> What's a bit weird is the way IBM layered their hacks on hacks.
>

I'm not sure it's wierd.? Necessary for certain requirements maybe.

>
> And I am not trying to cause controversy because we all know what big
> corporations are like, and what mangers are like ... saving money but
> building up a technical debt. And we all know that (irritatingly) they
> are often right, and certainly I have buried some bodies!
>

Not much argument there.

>
> In this case ... HX should have raised an interrupt which would have
> been manageable with one of the CMS interrupt macros. Instead weird
> polling.
>

This is back to front.? HX is recognised while processing an interrupt
from the console.? What happens next is what happens in most sensible
interrupt service routines, ie a flag is set to note that it happened
and then we go back to doing whatever we were doing in the foreground.
When it is convenient to do so (not in a tight loop while doing nothing
else for example), the foreground task polls the flag and if it is set,
takes action to clean up and exit.

If you add unix signals into this mix, you are just moving part of the
interrupt service routine into the application.? All the called routine
in the application does is set a flag and return.? The foreground part
of the application then polls the flag at a convenient time and if it
is set takes action to clean up and exit.? It is the same thing but only
slighly different.

There is a time and a place for polling and ways to do it right and ways
to do it wrong.? Interrogating the console every n microseconds to see
if a HX has been issued is not a good way to do polling.? Having an
interrupt routine set a flag and acting on it when convenient is the
right way to do it.

>
> And then?REXX came along which (like us today) needed a way for clean
> interrupt for the interpretation. One answer would be to fix HX, and
> allow the interpretor to catch the interrupt.
>

And change the documentation to say that before version x HX did one thing
and since version x it does something else and by the way, it is no longer
possible to halt execution of programs written before version x?? No thanks.

>
> But no - another command HI, another flag to poll!
>

How else is REXX or anything else going to detect at a time convenient to
itself that a HI command has been issued except by looking at some flag?

Why does it seem to make a big difference that the flag being checked has
been set in the console interrupt service routine or in your own routine
that you have registered with the operating system somehow?

>
> The biggest hack was allowing the most significant byte of addresses to
> be used.
>

I wouldn't call it a hack.? I'd call it a bad design decision.

>
> Today, I would fire someone on the spot for doing that (or the equivalent)
> ... and the hardware architects should have made sure CPUs fired a machine
> abend if it ever found anything other than zero in that byte. Just think
> how much easier it would have been to migrate to 32 (yes 32 bit)!
>

What would you do if the hardware already sticks non-address related stuff
into that byte when certain instructions are executed or requires you to
use that byte for something else entirely every time you want to do an I/O?

After you have come back from firing someone or asking the hardare architects
to do something they can't do without breaking existing functionality, you
still have to come up with a way of getting to use more address bits while
maintaining compatibility with large amounts of software that took the
designers at their word that addresses would never exceed 24 bits and used
that extra byte for something else.? How would you do that?? Especially when
you've already fired your best software people and driven your hardware
architects crazy by giving them contraditory design specifications?

>
> And to get a more sympathetic hearing from this forum. In a parallel universe
> IBM launched their PC computer with CMS on metal not DOS.
>

As far as I understand it, CMS was only supplied with VM in order to be able
to maintain it, to rebuild the nucleus, to apply updates etc.? It was never
intended that users would actually use CMS to do real work because it was
totally unsuitable for this.? Does that make it easier to understand some
of the limitations in CMS?

>
> impact on the mainframe business but this was completely offset by new
> customers and use cases. OS emulation was there from day one and later CP
> was introduced as the processors got more powerful. SAA was important
> ... etc.
>

OS emulation was there so that stuff already written for OS (the assembler
for example) could easily be used on CMS without having to rewrite it from
scratch for CMS.

I can't figure out what the rest means.

Regards,
Peter Coghlan.