Multitasking program for VM/CMS? 
Author Message
 Multitasking program for VM/CMS?

Phil,

A multitasking program for VM/CMS? how did you do it? what does it run?
Now you catch me.

But I keep my point.  If you where running it in UNIX, you would use C. But
I'm really upset by your news.  Tell us all about it, ok?

Eduardo Ferreira - System Programmer at Catholic University of Rio de Janeiro.



Wed, 13 Oct 1993 03:21:58 GMT  
 Multitasking program for VM/CMS?

Quote:
>Phil,
>A multitasking program for VM/CMS? how did you do it? what does it run?
>Now you catch me.
>But I keep my point.  If you where running it in UNIX, you would use C. But
>I'm really upset by your news.  Tell us all about it, ok?

What is there to be upset about?  You could just pretend I never wrote it,
and go on living happily ever after.

First of all, this program is NOT finished.  I only just recently finished
writing the code and have not tested it at all yet.  As complex as this kind
of thing is, I'd expect a LOT of "test, trace, dump, re-ipl CMS, edit,
assemble, load, and genmod" cycles.  Also a few untested macros (even though
of general purpose) are used in it.  For the macros, this is their first
time "out of the nest" and they might not fly, either.

This program does NOT provide for the ability to run two or more existing
CMS programs or commands at the same time.  While it provides for the ability
to have tasks, it does NOT attempt to manage any of the resources of CMS as
would be needed by multiple tasks attempting to gain access to them at the
same time.  Only "well behaved" tasks are runnable.  This program only makes
the development cycle for those programs that need to have some background
tasks a little easier to do.

This program is called TIE for lack of a better name.  It is an acronym for
"Tasks, Interrupts, and Events".  I'm still open on the name so if you have
a better idea, do tell me.

TIE runs as a nucleus extension.  The main "TIE" command will return in
register 1 the address of a list of function addresses to call for the
various TIE services.

One of these services is an interrupt dispatcher that handles I/O and
external interrupts, except clock comparator (which TIE uses itself in
3 different ways).  TIE traps interrupts at the NEW PSW level.  Interrupts
not requested to be handled are passed on to the handlers pointed to by the
NEW PSWs that were previously in place (usually in CMS).  The function that
accepts requests for interrupts to be handled can also cancel those requests.
Interrupts are requested in terms of a code value to be matched and a code
mask that is ANDed with the actual interrupt code (prefixed by 01 for I/O
and 02 for external).  With mask=0 and value=0 you effectively always match
every interrupt (except you won't get clock comparator).

When TIE initializes, it creates a ROOT TASK and makes it the current task.
CMS then effectively runs as the ROOT TASK as well as any program run by
command.  A program can create a new task any time (except during the handling
of an interrupt).  The function to do this is called FORK, but unlike its
UNIX namesake, it does not copy any address spaces.  The FORK function will
return twice, once to the parent, and once to the child.  The child will have
a new savearea.  When the child does its own return, the task is terminated.
The parent's savearea chain context is unchanged.  Most of the general
registers and all of the floating registers are copied to the child.

A task will typically invoke some service package, for instance a message
trapper, TCP/IP, asyncronous I/O, etc.  That package will contact TIE and
request interrupt handling.  The program will make requests of the package
at a higher level (e.g. listen on TCP port 119).  The package will field
the actual interrupts, and when appropriate, post an event to the calling
task.  A TIE function can be called when a task is current to identify
what the current task is.

To receive an event, the WAIT function is called.  The one parameter to
the wait function is the wakeup time in TOD format.  If an event is present
now, or arrives before the wakeup time, WAIT will return with a code saying
that the status of an event is being returned.  Some registers are filled
in with event data.  If no events arrive by the timeout, a timeout code
is returned instead.  The termination of a child is a special case of an
event identified by a code different from a posted event.

I don't want to give too many specifics at this time since I am not that
sure all will stay as I have initially designed it.  While I am still open
to ideas to be added, I am also trying to keep this thing basically simple.
It is mostly to avoid writing programs that are interrupt driven, and to
allow "plug and play" between interrupt driven service packages and more
generic programs that use them.

In the plans are:
    A C language interface to TIE
    A TCP/IP package using TIE
    An RSCS message handler using TIE
--
 /***************************************************************************\

\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/



Fri, 15 Oct 1993 12:55:35 GMT  
 Multitasking program for VM/CMS?

Quote:
>Phil,
>A multitasking program for VM/CMS? how did you do it? what does it run?
>Now you catch me.
>But I keep my point.  If you where running it in UNIX, you would use C. But
>I'm really upset by your news.  Tell us all about it, ok?

What is there to be upset about?  You could just pretend I never wrote it,
and go on living happily ever after.

First of all, this program is NOT finished.  I only just recently finished
writing the code and have not tested it at all yet.  As complex as this kind
of thing is, I'd expect a LOT of "test, trace, dump, re-ipl CMS, edit,
assemble, load, and genmod" cycles.  Also a few untested macros (even though
of general purpose) are used in it.  For the macros, this is their first
time "out of the nest" and they might not fly, either.

This program does NOT provide for the ability to run two or more existing
CMS programs or commands at the same time.  While it provides for the ability
to have tasks, it does NOT attempt to manage any of the resources of CMS as
would be needed by multiple tasks attempting to gain access to them at the
same time.  Only "well behaved" tasks are runnable.  This program only makes
the development cycle for those programs that need to have some background
tasks a little easier to do.

This program is called TIE for lack of a better name.  It is an acronym for
"Tasks, Interrupts, and Events".  I'm still open on the name so if you have
a better idea, do tell me.

TIE runs as a nucleus extension.  The main "TIE" command will return in
register 1 the address of a list of function addresses to call for the
various TIE services.

One of these services is an interrupt dispatcher that handles I/O and
external interrupts, except clock comparator (which TIE uses itself in
3 different ways).  TIE traps interrupts at the NEW PSW level.  Interrupts
not requested to be handled are passed on to the handlers pointed to by the
NEW PSWs that were previously in place (usually in CMS).  The function that
accepts requests for interrupts to be handled can also cancel those requests.
Interrupts are requested in terms of a code value to be matched and a code
mask that is ANDed with the actual interrupt code (prefixed by 01 for I/O
and 02 for external).  With mask=0 and value=0 you effectively always match
every interrupt (except you won't get clock comparator).

When TIE initializes, it creates a ROOT TASK and makes it the current task.
CMS then effectively runs as the ROOT TASK as well as any program run by
command.  A program can create a new task any time (except during the handling
of an interrupt).  The function to do this is called FORK, but unlike its
UNIX namesake, it does not copy any address spaces.  The FORK function will
return twice, once to the parent, and once to the child.  The child will have
a new savearea.  When the child does its own return, the task is terminated.
The parent's savearea chain context is unchanged.  Most of the general
registers and all of the floating registers are copied to the child.

A task will typically invoke some service package, for instance a message
trapper, TCP/IP, asyncronous I/O, etc.  That package will contact TIE and
request interrupt handling.  The program will make requests of the package
at a higher level (e.g. listen on TCP port 119).  The package will field
the actual interrupts, and when appropriate, post an event to the calling
task.  A TIE function can be called when a task is current to identify
what the current task is.

To receive an event, the WAIT function is called.  The one parameter to
the wait function is the wakeup time in TOD format.  If an event is present
now, or arrives before the wakeup time, WAIT will return with a code saying
that the status of an event is being returned.  Some registers are filled
in with event data.  If no events arrive by the timeout, a timeout code
is returned instead.  The termination of a child is a special case of an
event identified by a code different from a posted event.

I don't want to give too many specifics at this time since I am not that
sure all will stay as I have initially designed it.  While I am still open
to ideas to be added, I am also trying to keep this thing basically simple.
It is mostly to avoid writing programs that are interrupt driven, and to
allow "plug and play" between interrupt driven service packages and more
generic programs that use them.

In the plans are:
    A C language interface to TIE
    A TCP/IP package using TIE
    An RSCS message handler using TIE
--
 /***************************************************************************\

\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/



Fri, 15 Oct 1993 12:55:35 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. VM/CMS Release 5 Assembler Program To Read Huge Files

2. Stopping a program in CMS (was: Return to CMS after PER breakpoint)

3. Porting REXX CMS MultiTasking Application

4. NUCLPLIST and releated fileds in VM/CMS

5. MAKE on VM/CMS

6. INFO Request: Compression Software for VM/CMS

7. Multi-player adventure for VM/CMS

8. VM/CMS Compile, load, and go

9. VSAM VM/CMS problem

10. REXX and VM/CMS

11. automated IND$FILE transfer OS/2 Rexx VM/CMS

 

 
Powered by phpBB® Forum Software