🚀 go-pugleaf

> From:         803 James Loser 654-1284 <JAL2@CLEMSON.BITNET>
>
> Use a scheduler to manage your task.  When the interupt occurs, your FLIH
> should save the state of who is getting stepped on and then service the
> interrupt.  When the interrupt is finished, control is given to the
> scheduler (or dispatcher as some people prefer) which decides who still
> needs to run and passes control to that process.  When a process finishes,
> control is again returned to the dispatcher which again decides who
> who needs to run .....

This is the theoretically correct way to do it.  But in the absense of a
dispatcher, such as the case is with CMS, things get messy.  In addition,
just adding one is not that easy, since you need to make CMS jump to the
dispatcher instead of just load a wait state PSW.

If the application I mentioned has the constraint of running under CMS,
the problems become very difficult.

> From:         Jim McIntosh <JIM@AUVM.AUVM.EDU>
>
> This is  what operating systems do  all the time. The  solution is fairly
> simple. The  First Level Interupt  Handler (FLIH) should  receive control
> disabled  for interupts,  that is  the first  byte of  PSW NEW  should be
> zeros. Interupts which  arrive while the PSW is masked  off for interupts
> are  stacked until  a PSW  is loaded  with indicate  that it  will accept
> interupts. The  FLIH can  either restart  the application  (which accepts
> interupts) which would  be immediately interupted with  your interupt, or
> it  can save  PSW OLD  and call  a higher  level interupt  handler (which
> generally run with interupts enabled).

Good operating systems designed for multiple concurrent activity, of course,
do just this kind of thing.  CMS imposes different constraints.  You can
easily get into a "hang" situation where some CMS routine just loaded a
wait state PSW instead of jumping to a dispatcher, which it knows nothing
about.  To make CMS fully multi-tasking requires redesigning CMS.

I am interesting in finding the highest workable degree of overlap and
concurrency that can be gotten into CMS without modifying CMS.

But for other things, other systems do work better.  RSCS and VTAM run under
GCS, for instance, because they need the multitasking capabilities, among
other things (such as near MVS-like compatibility).  I've been designing a
smaller multi-tasking OS for lesser needs, but with full multitasking and
intertask communications using a server-client model for rendevous and
symmetrical message channels.  I'm developing this for the gap between
CMS and GCS.

------------------------------------------------------------------------

I am presently working on a program that does overlapped tape I/O.
Of course if there is nothing else going on inside the virtual machine,
the problems are quite simple.  But I have also written other sorts of
background processes for CMS.  For instance the first one I did was one
to print files in a queue to a dialed in ascii terminal printer (the
DECwriter was just becoming a popular printer then).  While I no longer
have need for that kind of thing, I certainly am envisioning others, such
as NETWORKING application stuff.

If we restrict interrupt processing to mask off all interrupts during
such processing, then we always have completed contexts to deal with,
and there is no ambiguity to knowing where to go to after interrupt
completion.  But unfortunately this rules out some kinds of background
activity, such as spare-cycle number crunching.  Under VM such things
probably should be in a separate virtual machine anyway.