This is G o o g l e's cache of http://www.lp.se/ftp/mailinglists/FREE-VMS.1997-03.
G o o g l e's cache is the snapshot that we took of the page as we crawled the web.
The page may have changed since that time. Click here for the current page without highlighting.
Google is not affiliated with the authors of this page nor responsible for its content. |
| These search terms have been highlighted: | levitte | programming |
|
|
Archive-Date: Wed, 05 Mar 1997 05:55:24 +0100
Sender: owner-free-vms@lp.se
To: Free-VMS@lp.se
Subject: How to get VMS documentation?
From: "Roland B. Roberts" <roberts@panix.com>
Reply-To: Free-VMS@lp.se
Date: 04 Mar 1997 23:55:11 -0500
Message-ID: <x64ter6iq8.fsf@galileo.rlent.pnet>
Okay, for those of us with limited access to VMS documentation (_very_
limited), how/where do I contact DEC to get it? I'm interested in
tackling the logical name services, but I'd like to understand more
about how they work before I launch into this...
roland
--
Roland B Roberts
roberts@panix.com
================================================================================
Archive-Date: Wed, 05 Mar 1997 09:06:07 +0100
Sender: owner-free-vms@lp.se
From: kkaempf@progis.de (Klaus Kaempf)
Reply-To: Free-VMS@lp.se
Message-ID: <9703050736.AA00552@didymus.progis.de>
Subject: Re: How to get VMS documentation?
To: Free-VMS@lp.se
Date: Wed, 5 Mar 1997 08:36:15 +0100 (MET)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Most of VMS 6.x and 7.x documentation is available as postscript
files:
http://www.partner.digital.com/www-swdev/pages/Home/TECH/documents/doc=
umentation.html
--=20
proGIS Software E-Mail: kkaempf@progis.de
Dipl.-Inform. Klaus K=E4mpf Fax: 0241-47067-29
Jakobstr. 117 Voice: 0241-47067-11
D-52064 Aachen WWW: http://www.progis.de
================================================================================
Archive-Date: Wed, 05 Mar 1997 09:58:12 +0100
Sender: owner-free-vms@lp.se
From: "Thomas,GD,NAIB4,THOMASGD M" <THOMASGD@boat.bt.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS <Free-VMS@lp.se>
Subject: RE: How to get VMS documentation?
Date: Wed, 05 Mar 97 08:58:00 GMT
Message-ID: <331D348E@msmsmtp1.comnet.bt.co.uk>
...
Okay, for those of us with limited access to VMS documentation (_very_
limited), how/where do I contact DEC to get it?
...
Try http://www.openvms.digital.com:81/
It's only a pilot, but it seems to have most of the documentation.
Greg
================================================================================
Archive-Date: Wed, 05 Mar 1997 14:16:42 +0100
Sender: owner-free-vms@lp.se
Date: Wed, 05 Mar 1997 07:18:35 EST
From: DLS Systems Support Team <rozenfeld@dls.net>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
CC: rozenfeld@dls.net
Message-ID: <009B0CBD.E740E3D3.7@dls.net>
Subject: RE: How to get VMS documentation?
I have documentation CD distribution which I could let you use. Not sure if it
is complete but most of it is there.
Let me know if you need it.
>Okay, for those of us with limited access to VMS documentation (_very_
>limited), how/where do I contact DEC to get it? I'm interested in
>tackling the logical name services, but I'd like to understand more
>about how they work before I launch into this...
>
>roland
>--
>Roland B Roberts
>roberts@panix.com
Sam Rozenfeld +----------------------------------------+
PO BOX 7426 | DLS Computer Services, Inc. |
Algonquin, IL 60102 | |
phone: (847) 854-4799 | Full Service Internet Access Provider |
fax: (847) 854-0970 | |
pager: (815) 851-1469 | http://www.dls.net |
+----------------------------------------+
================================================================================
Archive-Date: Wed, 05 Mar 1997 14:55:24 +0100
Sender: owner-free-vms@lp.se
To: Free-VMS@lp.se
Subject: Anyone tried running Mach?
From: Roland Roberts <rroberts@muller.com>
Reply-To: Free-VMS@lp.se
Date: 05 Mar 1997 08:54:34 -0500
Message-ID: <lnrahula05.fsf@bronze.muller.com>
Has anyone tried to install and run Mach yet? I'm especially interested
in any attempts to run Mach on the x86 platform since that's what I'll
have to work with (although I could also try in on a sparc if that seems
easier). I'm trying to decide what hardware I will need to add to my PC
(e.g., disk space).
roland
--
Roland Roberts, PhD Muller Data Corporation
rroberts@muller.com 395 Hudson Avenue
New York, NY
================================================================================
Archive-Date: Thu, 06 Mar 1997 03:02:44 +0100
Sender: owner-free-vms@lp.se
Message-ID: <1.5.4.32.19970306020157.0067cfbc@mail-1.ns.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 05 Mar 1997 18:01:57 -0800
To: Free-VMS@lp.se
From: John Mee <jmee@ns.net>
Reply-To: Free-VMS@lp.se
Subject: Re: How to get VMS documentation?
At 23:55 3/4/97 -0500, you wrote:
>Okay, for those of us with limited access to VMS documentation (_very_
>limited), how/where do I contact DEC to get it? I'm interested in
>tackling the logical name services, but I'd like to understand more
>about how they work before I launch into this...
Nobody has mentioned that you can also call 1-800-digital and order it. I
don't know if you can order individual manuals (you used to be able to), and
the complete doc/media kit is quite expensive (e.g. thousands of dollars)
but it is possible to order.
Another possiblity is if somebody is discarding an older version, there is
still a lot of good information in the older versions of the doc set.
If you get the CD, and do NOT have an X-term (read Dec Windows), then get a
copy of Hunter Goatley's reader for character based-terminals. You won't be
able look at diagrams, but then you won't be spending the bucks on an x-term
package, either. Bear in mind (in case you didn't know) that the CDs are NOT
readable on a PC, since they are not in ISO9660/High Sierra Format.
================================================================================
Archive-Date: Thu, 06 Mar 1997 14:37:35 +0100
Sender: owner-free-vms@lp.se
To: Free-VMS@lp.se
Subject: Re: How to get VMS documentation?
References: <1.5.4.32.19970306020157.0067cfbc@mail-1.ns.net>
Reply-To: Free-VMS@lp.se
From: Roland Roberts <rroberts@muller.com>
Date: 06 Mar 1997 08:36:48 -0500
Message-ID: <lnpvxd87m7.fsf@bronze.muller.com>
>>>>> "John" == John Mee <jmee@ns.net> writes:
John> Nobody has mentioned that you can also call 1-800-digital and
John> order it. [...]
I was wondering about that, especially trying to get a copy of the VMS
internals documentation. I'm hoping that will give me some useful
insight before I tackle logical name services. I'm guess I'm really
looking for the contact for Digital Press....
John> Another possiblity is if somebody is discarding an older
John> version, there is still a lot of good information in the older
John> versions of the doc set.
Hmmm, that makes me think...I may know someone in that position....
John> [...] Bear in mind (in case you didn't know) that the CDs are
John> NOT readable on a PC, since they are not in ISO9660/High
John> Sierra Format.
I suspected this, which is my I've passed on getting the CDs.
Thanks! And thanks also for the tips on where on the web to find some
documentation (which means I now have access much better VMS
documentation than our company has bothered to purchase...).
roland
--
Roland Roberts, PhD Muller Data Corporation
rroberts@muller.com 395 Hudson Avenue
New York, NY
================================================================================
Archive-Date: Thu, 06 Mar 1997 17:20:08 +0100
Sender: owner-free-vms@lp.se
Date: Thu, 06 Mar 1997 11:20:00 -0500 (EST)
From: Keith Parris <PARRIS@Eisner.DECUS.Org>
Reply-To: Free-VMS@lp.se
Subject: Re: How to get VMS documentation?
To: Free-VMS@lp.se
Message-ID: <01IG6H2RBQP6007EJQ@Eisner.DECUS.Org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
>I was wondering about that, especially trying to get a copy of the VMS
>internals documentation. I'm hoping that will give me some useful
>insight before I tackle logical name services. I'm guess I'm really
>looking for the contact for Digital Press....
DEC sold Digital Press to Butterworth-Heinemann. The Digital Press home page
is now at:
http://www.bh.com/dp/
I went directly to the source recently and got autographed copies of all the
current VMS Internals books directly from the author, Ruth Goldenberg. You can
reach her by E-Mail at goldenberg@star.ENET.dec.com or by snail mail at:
Ruth Goldenberg
PO 387
Groton, MA, 01450
The book titles, prices, and ISBN numbers are:
VAX/VMS V5.2 internals book $145.00 ISBN 1-55558-059-9
or under Prentice-Hall
0-13-929886-X
OpenVMS AXP V1.5 74.95 ISBN 1-55558-120-X
OpenVMS Alpha V7.0 (scheduler/process control) 49.95 ISBN 1-55558-156-0
You might also want to consider getting a copy of Roy Davis' book, VAXcluster
Principles, which covers internals of the VMScluster code that Ruth's books
don't get into very deeply. This is also published by Digital Press; ISBN
1-55558-112-9, $59.95.
================================================================================
Archive-Date: Thu, 06 Mar 1997 18:35:41 +0100
Sender: owner-free-vms@lp.se
Message-ID: <v03007805af44b060910b@[140.186.88.14]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 6 Mar 1997 12:33:38 -0500
To: Free-VMS@lp.se
From: Dick Munroe <munroe@acornsw.com>
Reply-To: Free-VMS@lp.se
Subject: Re: How to get VMS documentation?
>At 23:55 3/4/97 -0500, you wrote:
>>Okay, for those of us with limited access to VMS documentation (_very_
>>limited), how/where do I contact DEC to get it? I'm interested in
>>tackling the logical name services, but I'd like to understand more
>>about how they work before I launch into this...
>
>Nobody has mentioned that you can also call 1-800-digital and order it. I
>don't know if you can order individual manuals (you used to be able to), and
>the complete doc/media kit is quite expensive (e.g. thousands of dollars)
>but it is possible to order.
>
>Another possiblity is if somebody is discarding an older version, there is
>still a lot of good information in the older versions of the doc set.
>
>If you get the CD, and do NOT have an X-term (read Dec Windows), then get a
>copy of Hunter Goatley's reader for character based-terminals. You won't be
>able look at diagrams, but then you won't be spending the bucks on an x-term
>package, either. Bear in mind (in case you didn't know) that the CDs are NOT
>readable on a PC, since they are not in ISO9660/High Sierra Format.
It's also available on the net in a number of places...
Dick
--
Dick Munroe Internet: munroe@acornsw.com
Acorn Software, Inc.
267 Cox St. Office: (508) 568-1618 x1
Hudson, Ma. 01749 USA FAX: (508) 562-1133
================================================================================
Archive-Date: Wed, 12 Mar 1997 05:08:00 +0100
Sender: owner-free-vms@lp.se
Date: Wed, 12 Mar 1997 15:12:48 +1100
From: "Scott Hamilton, +61-2-9950 1693, Institute Systems - NSW TAFE ITB" <SHAMILTON1@dev.develop1.tafensw.edu.au>
Reply-To: Free-VMS@lp.se
Subject: $QIO
To: Free-VMS@lp.se
Message-ID: <01IGF42QRNUA00CGLY@hmgwy1.isd1.tafensw.edu.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Hi ya 'all,
I see a quite a bit of activity since I was last on
this list several months ago which is fantastic...
I'm interested in starting to break down EXE$QIO
there are a number of things that need to be looked
at in conjuction with this very important module.
To this end I'd like to start discussion (either here
or in a more restricted forum??) on the specifics of
EXE$QIO and all other related issues... A working
group in essence!! I'm not sure where to take it from
here... any suggestions????
Cheers
Scott, Esq.
================================================================================
Archive-Date: Wed, 12 Mar 1997 19:32:54 +0100
Sender: owner-free-vms@lp.se
Message-ID: <F14AAE60A252CF11B56100805F14DD09022E1745@RED-70-MSG.dns.microsoft.com>
From: Chris Kaler <ckaler@microsoft.com>
Reply-To: Free-VMS@lp.se
To: "'Free-VMS@lp.se'" <Free-VMS@lp.se>
Subject: RE: $QIO
Date: Wed, 12 Mar 1997 10:29:08 -0800
$QIO is a very large area... Are you interested in building a
generalized QIO structure or are you looking at a specific IO
path?
An interesting structure would be to build a basic framework
that does some obvious checking/validation, and then passed
the information to subsystem-specific engines which will most
likely pass the request on to other services on the systems (e.g.,
the file system or mailboxes).
If we take this approach, we need to build a generalized channel
architecture and device naming mechanism so that the QIO
subsystem (and all of the related routines, $ASSIGN,$DASSGN,
$SYNCH, ...) are self-contained. This way you could actually have
a service that provides "pipes" and layer a POSIX pipe interface
and the VMS mailbox interface on the same core service... that
would potentially even allow you to pipe between personalities.
Chris
-----Original Message-----
From: Scott Hamilton, +61-2-9950 1693, Institute Systems - NSW
TAFE ITB [SMTP:SHAMILTON1@dev.develop1.tafensw.edu.au]
Sent: Tuesday, March 11, 1997 8:13 PM
To: Free-VMS@lp.se
Subject: $QIO
Hi ya 'all,
I see a quite a bit of activity since I was last on
this list several months ago which is fantastic...
I'm interested in starting to break down EXE$QIO
there are a number of things that need to be looked
at in conjuction with this very important module.
To this end I'd like to start discussion (either here
or in a more restricted forum??) on the specifics of
EXE$QIO and all other related issues... A working
group in essence!! I'm not sure where to take it from
here... any suggestions????
Cheers
Scott, Esq.
================================================================================
Archive-Date: Thu, 13 Mar 1997 00:07:11 +0100
Sender: owner-free-vms@lp.se
Date: Thu, 13 Mar 1997 10:12:00 +1100
From: "Scott Hamilton, +61-2-9950 1693, Institute Systems - NSW TAFE ITB" <SHAMILTON1@dev.develop1.tafensw.edu.au>
Reply-To: Free-VMS@lp.se
Subject: Re: $QIO
To: Free-VMS@lp.se
Message-ID: <01IGG7U5F9OI00D8NZ@hmgwy1.isd1.tafensw.edu.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Chris!
$QIO is a very large area... Are you interested in building a
generalized QIO structure or are you looking at a specific IO
path?
I think a general front-end, much like VMS $QIO
is a good start, and getting the needed data
structures that have to be passed around
defined (IRP, UCB, CCB, DDB etc in VMS)
once this interface is decided, device drivers
can be attached (from whereever they are coming from)
However it's a pandora's box, before $QIO we need
$ASSIGN, before $ASSIGN we need to have UCB, DDB & PCB's etc
For now, let's assume these lower level structures exist.
We also need some way of checking privilege and quota's
(it's nice to have quota's from a Systems mngt point of view
does anyone think that they can be reduced in number however...)
(for example why limit the number of channels etc...)
An interesting structure would be to build a basic framework
that does some obvious checking/validation, and then passed
the information to subsystem-specific engines which will most
likely pass the request on to other services on the systems (e.g.,
the file system or mailboxes).
what sort of sub-system engines more specifically
are we talking about here??? what sort of functions
could be between the QIO interface and the device driver???
If we take this approach, we need to build a generalized channel
architecture and device naming mechanism so that the QIO
subsystem (and all of the related routines, $ASSIGN,$DASSGN,
$SYNCH, ...) are self-contained.
I suggest device naming obviously remain
the same as VMS (as at V3.0 for example, with
no MSCP...) otherwise people will say it's
not VMS???
I believe we should start with simple locally
attached devices, software devices (NL:, Mailbox etc)
and design but maybe not yet code template devices,
(for LTA, NET, etc later..)
I agree a simple general channel architecture is the most
appropriate, it's also important that any conceivable
device (either real or software) can be attached simply.
This way you could actually have
a service that provides "pipes" and layer a POSIX pipe interface
and the VMS mailbox interface on the same core service... that
would potentially even allow you to pipe between personalities.
Yes I agree, though VMS mailboxes provide the essential
mechanism to provide pipes, it's up to the user CLI
to use that mechanism, for example does the CLI request
the creation of a sub-process to read the output of the
pipe device or does the pipe device request the creation
of the sub-process???? However I think this is up to the
device writer or the CLI writer, not EXE$QIO (just keeping
scope!!)
Scott, Esq.
================================================================================
Archive-Date: Thu, 13 Mar 1997 01:12:47 +0100
Sender: owner-free-vms@lp.se
Message-ID: <F14AAE60A252CF11B56100805F14DD09022E1754@RED-70-MSG.dns.microsoft.com>
From: Chris Kaler <ckaler@microsoft.com>
Reply-To: Free-VMS@lp.se
To: "'Free-VMS@lp.se'" <Free-VMS@lp.se>
Subject: RE: $QIO
Date: Wed, 12 Mar 1997 16:08:58 -0800
I would mimic VMS only to the point of the API - no further.
There is no way that we can make use of existing device
drivers, so I wouldn't propagate the data structures such as
an IRP.
I would code $QIO as a basic function that redirects the request
to a handler for the indicated channel, maybe a little checking,
maybe handle the post-processing of ASTs (probably). We would
define a standard interface that is exported by anyone who fields
a "device".
The $ASSIGN service is pretty simple. It essentially queries a
table of registered devices and creates a connection for a channel.
The $DASSGN service breaks the channel.
Here is basically what I'm talking about presented COM style (which
can be adapted later to the appropriate implementation).
Process Library interfaces:
$ASSIGN (dev-str)
$DASSGN (chan)
$QIO (..., chan, ...)
$QIOW (...,chan,...)
VMS-QIO-Subsystem object exports the following methods:
LookupDevice (name,...)
RegisterDevice (name, interface)
UnRegisterDevice (name, interface)
Each "device" service exports the following methods:
OpenConnection (...)
CloseConnection (...)
ProcessRequest (...)
The VMS-QIO-Subsystem is implemented as a server, but
there is also a client-side library. The server is really nothing
more than a device registration list. The client-side library
initially contacts the server and receives a copy of an interface
to talk to the desired "device". All subsequent discussions are
directly with the device interface. The "logic" of VMS I/O is
inside the client-side libraries which map VMS-style calls to
the published interfaces.
Using this same technique, we could have a ioctl() function which
makes calls to the save "device" interface by mapping UNIX-style
calls to the published interface.
Chris
-----Original Message-----
From: Scott Hamilton, +61-2-9950 1693, Institute Systems - NSW
TAFE ITB [SMTP:SHAMILTON1@dev.develop1.tafensw.edu.au]
Sent: Wednesday, March 12, 1997 3:12 PM
To: Free-VMS@lp.se
Subject: Re: $QIO
Chris!
$QIO is a very large area... Are you interested in building a
generalized QIO structure or are you looking at a specific IO
path?
I think a general front-end, much like VMS $QIO
is a good start, and getting the needed data
structures that have to be passed around
defined (IRP, UCB, CCB, DDB etc in VMS)
once this interface is decided, device drivers
can be attached (from whereever they are coming from)
However it's a pandora's box, before $QIO we need
$ASSIGN, before $ASSIGN we need to have UCB, DDB & PCB's
etc
For now, let's assume these lower level structures
exist.
We also need some way of checking privilege and quota's
(it's nice to have quota's from a Systems mngt point of
view
does anyone think that they can be reduced in number
however...)
(for example why limit the number of channels etc...)
An interesting structure would be to build a basic framework
that does some obvious checking/validation, and then passed
the information to subsystem-specific engines which will most
likely pass the request on to other services on the systems
(e.g.,
the file system or mailboxes).
what sort of sub-system engines more specifically
are we talking about here??? what sort of functions
could be between the QIO interface and the device
driver???
If we take this approach, we need to build a generalized channel
architecture and device naming mechanism so that the QIO
subsystem (and all of the related routines, $ASSIGN,$DASSGN,
$SYNCH, ...) are self-contained.
I suggest device naming obviously remain
the same as VMS (as at V3.0 for example, with
no MSCP...) otherwise people will say it's
not VMS???
I believe we should start with simple locally
attached devices, software devices (NL:, Mailbox etc)
and design but maybe not yet code template devices,
(for LTA, NET, etc later..)
I agree a simple general channel architecture is the
most
appropriate, it's also important that any conceivable
device (either real or software) can be attached simply.
This way you could actually have
a service that provides "pipes" and layer a POSIX pipe interface
and the VMS mailbox interface on the same core service... that
would potentially even allow you to pipe between personalities.
Yes I agree, though VMS mailboxes provide the essential
mechanism to provide pipes, it's up to the user CLI
to use that mechanism, for example does the CLI request
the creation of a sub-process to read the output of the
pipe device or does the pipe device request the creation
of the sub-process???? However I think this is up to the
device writer or the CLI writer, not EXE$QIO (just
keeping
scope!!)
Scott, Esq.
================================================================================
Archive-Date: Thu, 13 Mar 1997 03:02:04 +0100
Sender: owner-free-vms@lp.se
Date: Thu, 13 Mar 1997 13:06:47 +1100
From: "Scott Hamilton, +61-2-9950 1693, Institute Systems - NSW TAFE ITB" <SHAMILTON1@dev.develop1.tafensw.edu.au>
Reply-To: Free-VMS@lp.se
Subject: Re: $QIO
To: Free-VMS@lp.se
Message-ID: <01IGGDXV72TE00CA2T@hmgwy1.isd1.tafensw.edu.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
O.K. a few more ramblings, these are simply idea's
and questions generated on the fly as I read this message
and things become clearer in my thingy...
I would mimic VMS only to the point of the API - no further.
There is no way that we can make use of existing device
drivers, so I wouldn't propagate the data structures such as
an IRP.
Sorry, I didn't really mean to use those data structures
verbatim, however I feel there will be similarity
since they are essentially do the same function...
We will need structures to describe devices, channels,
processes and I/O requests etc...
I would code $QIO as a basic function that redirects the request
to a handler for the indicated channel, maybe a little checking,
maybe handle the post-processing of ASTs (probably). We would
define a standard interface that is exported by anyone who fields
a "device".
Agreed totaly.
so something like:
clear semaphore/event flag/synch mechanism
check channel specified is valid
get device interface/info from channel structure (ie: lookupDevice)
check buffer is writable (may not be a problem on 6502 ;)
check processes quotas, priv's for generic function requested
(ie: we want to write to a channel, is that allowed for this device?)
talk to device via registered interface
(do we need to build any data structures to talk to this device???)
The $ASSIGN service is pretty simple. It essentially queries a
table of registered devices and creates a connection for a channel.
The $DASSGN service breaks the channel.
Here is basically what I'm talking about presented COM style (which
can be adapted later to the appropriate implementation).
Process Library interfaces:
$ASSIGN (dev-str)
$DASSGN (chan)
$QIO (..., chan, ...)
$QIOW (...,chan,...)
VMS-QIO-Subsystem object exports the following methods:
LookupDevice (name,...)
I assume this returns a interface (most probably a simple
pointer to the startIO routine????)
I've just read to end of the message I guess it points to
ProcessRequest()....
RegisterDevice (name, interface)
Should we register what generic functions we support??
perhaps this is a little too complex, kill that last idea!!!
Also expanding on this a little more, how is a device loaded
so that it can register itself.... (a bit of the egg or the
chicken first type of thing...) which also includes image
activation (ooops sliding off the thread..)
UnRegisterDevice (name, interface)
Each "device" service exports the following methods:
OpenConnection (...)
CloseConnection (...)
ProcessRequest (...)
The VMS-QIO-Subsystem is implemented as a server, but
there is also a client-side library. The server is really nothing
more than a device registration list. The client-side library
initially contacts the server and receives a copy of an interface
to talk to the desired "device".
Yes how do you talk to the server to find out it's
interfaces??? interface to unkown interfaces, how do
you find a known interface???
All subsequent discussions are
directly with the device interface. The "logic" of VMS I/O is
inside the client-side libraries which map VMS-style calls to
the published interfaces.
Ohhhh, I see more clearly now... this could potentialy
allow for different driver interfaces.. Getting down
to more details, how will the driver interface work...
I'm not familiar with messy-dos interfaces, but I remember
that Amiga has a very similar style to VMS of putting a
IO request on some queue and calling the START IO routine
(of some sort in the driver) this assumes the IO subsystem
knows intimately the device driver, which returns to the question
are we using someone else device drivers (in which case our hands
are tied to that interface) or will we write our own (I'd prefer
not too...)
Using this same technique, we could have a ioctl() function which
makes calls to the save "device" interface by mapping UNIX-style
calls to the published interface.
Chris
Cheers
Scott, Esq.
================================================================================
Archive-Date: Thu, 13 Mar 1997 18:43:53 +0100
Sender: owner-free-vms@lp.se
Message-ID: <F14AAE60A252CF11B56100805F14DD09022E175C@RED-70-MSG.dns.microsoft.com>
From: Chris Kaler <ckaler@microsoft.com>
Reply-To: Free-VMS@lp.se
To: "'Free-VMS@lp.se'" <Free-VMS@lp.se>
Subject: RE: $QIO
Date: Thu, 13 Mar 1997 09:40:02 -0800
Let me try to explain again using Mach language rather than COM.
The Mach kernel exports a "port" as a trusted system entity. This is
essentially a communication point to which messages can be sent.
There is a "trusted" name server from which applications can lookup
named ports. Each request is granted a port which is unique in
time and space. When the port is destroyed the listener of the port
is notified.
So I would have a server called something like the IO-Manager. This
would export two ports. The first is a read-only lookup up. The other
is a registration port.
We could then implement a "pipe" server. This server would register
itself with the IO-Manager and provide a port that it listens on. This
port accepts a single message which is OpenDevice().
An application makes a call to $ASSIGN. This would be a function that
exists within the process of the caller. It goes to the name server and
requests a port for the specified device. It then sends an OpenDevice()
request to the server. The server decides if the client is authorized
to
open the device, and if so, returns a new port for the connection. The
$ASSIGN services destroys the initial port and caches the new port in
a local table and returns a short int index into the table (the chan
id).
The application then makes a call to $QIOW. The library function makes
an RPC to the server using the port for the channel and all is great in
the world.
Now there are a couple of issues here. The first is the RPC to the
server.
This could be a generalized message that mimics the $QIO arguments.
The advantage to this is that the code is really simple and the burden
is
on the server. The downside is that every server needs to export a
VMS-like interface as well as any other interfaces. This would not be
the approach that I would take.
I would have $ASSIGN parse the device string and determine the type.
Based on the type, $ASSIGN would then lookup a specific server and
would note both the new port and the type. When $QIOW is called,
the function would basically do a select() statement on the type.
This would invoke code that maps the $QIOW syntax onto a general
RPC that is exported by the server. This means that the library has
to do more work. The upside is that the servers export a general
interface that everyone can use. This increases interoperability.
The other issue is that I used $QIOW and not $QIO. VMS functions
are all essentially asynchronous. This causes a real problem when
dealing with multi-process servers. A solution to this is something we
called notices & agendas. The idea was that you passed a token to
the server that represented the post-processing requirements for
a specific RPC call. When the server completed the request, it
would send a notice back to the originating process passing the
token (agenda). A special thread in the process would then process
the agenda. This is a convenient way to implement local event flags
and ASTs. Note that common event flags require a server.
Chris
-----Original Message-----
From: Scott Hamilton, +61-2-9950 1693, Institute Systems - NSW
TAFE ITB [SMTP:SHAMILTON1@dev.develop1.tafensw.edu.au]
Sent: Wednesday, March 12, 1997 6:07 PM
To: Free-VMS@lp.se
Subject: Re: $QIO
O.K. a few more ramblings, these are simply idea's
and questions generated on the fly as I read this
message
and things become clearer in my thingy...
I would mimic VMS only to the point of the API - no further.
There is no way that we can make use of existing device
drivers, so I wouldn't propagate the data structures such as
an IRP.
Sorry, I didn't really mean to use those data structures
verbatim, however I feel there will be similarity
since they are essentially do the same function...
We will need structures to describe devices, channels,
processes and I/O requests etc...
I would code $QIO as a basic function that redirects the request
to a handler for the indicated channel, maybe a little checking,
maybe handle the post-processing of ASTs (probably). We would
define a standard interface that is exported by anyone who
fields
a "device".
Agreed totaly.
so something like:
clear semaphore/event flag/synch mechanism
check channel specified is valid
get device interface/info from channel structure (ie:
lookupDevice)
check buffer is writable (may not be a problem on 6502
;)
check processes quotas, priv's for generic function
requested
(ie: we want to write to a channel, is that allowed
for this device?)
talk to device via registered interface
(do we need to build any data structures to talk to
this device???)
The $ASSIGN service is pretty simple. It essentially queries a
table of registered devices and creates a connection for a
channel.
The $DASSGN service breaks the channel.
Here is basically what I'm talking about presented COM style
(which
can be adapted later to the appropriate implementation).
Process Library interfaces:
$ASSIGN (dev-str)
$DASSGN (chan)
$QIO (..., chan, ...)
$QIOW (...,chan,...)
VMS-QIO-Subsystem object exports the following methods:
LookupDevice (name,...)
I assume this returns a interface (most probably a
simple
pointer to the startIO routine????)
I've just read to end of the message I guess it points
to
ProcessRequest()....
RegisterDevice (name, interface)
Should we register what generic functions we support??
perhaps this is a little too complex, kill that last
idea!!!
Also expanding on this a little more, how is a device
loaded
so that it can register itself.... (a bit of the egg or
the
chicken first type of thing...) which also includes
image
activation (ooops sliding off the thread..)
UnRegisterDevice (name, interface)
Each "device" service exports the following methods:
OpenConnection (...)
CloseConnection (...)
ProcessRequest (...)
The VMS-QIO-Subsystem is implemented as a server, but
there is also a client-side library. The server is really
nothing
more than a device registration list. The client-side library
initially contacts the server and receives a copy of an
interface
to talk to the desired "device".
Yes how do you talk to the server to find out it's
interfaces??? interface to unkown interfaces, how do
you find a known interface???
All subsequent discussions are
directly with the device interface. The "logic" of VMS I/O is
inside the client-side libraries which map VMS-style calls to
the published interfaces.
Ohhhh, I see more clearly now... this could potentialy
allow for different driver interfaces.. Getting down
to more details, how will the driver interface work...
I'm not familiar with messy-dos interfaces, but I
remember
that Amiga has a very similar style to VMS of putting a
IO request on some queue and calling the START IO
routine
(of some sort in the driver) this assumes the IO
subsystem
knows intimately the device driver, which returns to the
question
are we using someone else device drivers (in which case
our hands
are tied to that interface) or will we write our own
(I'd prefer
not too...)
Using this same technique, we could have a ioctl() function
which
makes calls to the save "device" interface by mapping UNIX-style
calls to the published interface.
Chris
Cheers
Scott, Esq.
================================================================================
Archive-Date: Thu, 13 Mar 1997 22:43:32 +0100
Sender: owner-free-vms@lp.se
Message-ID: <1.5.4.32.19970313214742.006bf634@snake.srv.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Mar 1997 14:47:42 -0700
To: Free-VMS@lp.se
From: Kevin Handy <kth@srv.net>
Reply-To: Free-VMS@lp.se
Subject: RE: $QIO
At 09:40 AM 3/13/97 -0800, you wrote:
>Let me try to explain again using Mach language rather than COM.
>
>The Mach kernel exports a "port" as a trusted system entity. This is
>essentially a communication point to which messages can be sent.
>There is a "trusted" name server from which applications can lookup
>named ports. Each request is granted a port which is unique in
>time and space. When the port is destroyed the listener of the port
>is notified.
>
>So I would have a server called something like the IO-Manager. This
>would export two ports. The first is a read-only lookup up. The other
>is a registration port.
>
[SNIP]
I would think that you could also handle Decnet type references
through the server (ie. node::device) in a similiar way to your 'pipe'.
It would just handle half of the process on each system, with a
network link between them.
After getting this to work, clusters may not be too far away.
-------------------------------------------------------------
Kevin Handy kth@srv.net Accounting Software for
Software Solutions. Inc. VAX/VMS Computer Systems
Idaho Falls, Idaho
================================================================================
Archive-Date: Fri, 14 Mar 1997 00:09:37 +0100
Sender: owner-free-vms@lp.se
Message-ID: <F14AAE60A252CF11B56100805F14DD09022E1764@RED-70-MSG.dns.microsoft.com>
From: Chris Kaler <ckaler@microsoft.com>
Reply-To: Free-VMS@lp.se
To: "'Free-VMS@lp.se'" <Free-VMS@lp.se>
Subject: RE: $QIO
Date: Thu, 13 Mar 1997 14:43:35 -0800
Actually, I would take a slightly different approach...
First, let's separate a couple of issues. There is remote servers
and there is clustering. They are very different beasts.
The way you approach this on Mach is to have a server that
accepts RPCs indicating a server and a service. The server
opens a network connection to its counterpart on the indicated
server and passes the service name. The remote server contacts
the local name server and obtains a local port for the service.
This port is cached and an ID is passed back to the local server.
The local server then creates a port to itself and caches that with
the ID. The local port is passed back to the client.
Now the client makes an RPC to the port it received. The message
is received by the local server and packed and sent over the
network to the remote server specifying the saved ID. The remote
server uses the ID to indicate a local port and sends the data to
the port. The response comes back similarly. You now have remote
ports and you can use network error messages and port destruction
messages to clean everything up.
We used this technique and where able to talk to servers running
on remote systems as easily as servers on the local system.
Clustering is much more. Before you can implement "clustering" you
first need to define it. I dare you to try ;-)
Instead, I would suggest you pick the features that you want. For
example,
if all "devices" are implemented as servers that respond to requests on
ports, you can not process them remotely using the technique above.
This gets you access to a file system from multiple hosts. Notice I
didn't
say a shared file system because that implies a certain amount of
functionality to be built into the file system which may, or may not, be
there.
It also gives you shadowing at a very cheap cost because you can just
forward an I/O message to a remote port and boom the shadow is done.
Note that you cannot see my hands waving in the air ;-)
But clustering is more that just shared access to devices, it is also a
shared
security domain and shared services such as batch/print. You can
certainly
employ this approach to build a distributed batch/print.
The security aspect is a conversation for another mail message...
Chris
-----Original Message-----
From: Kevin Handy [SMTP:kth@srv.net]
Sent: Thursday, March 13, 1997 1:48 PM
To: Free-VMS@lp.se
Subject: RE: $QIO
At 09:40 AM 3/13/97 -0800, you wrote:
>Let me try to explain again using Mach language rather than
COM.
>
>The Mach kernel exports a "port" as a trusted system entity.
This is
>essentially a communication point to which messages can be
sent.
>There is a "trusted" name server from which applications can
lookup
>named ports. Each request is granted a port which is unique in
>time and space. When the port is destroyed the listener of the
port
>is notified.
>
>So I would have a server called something like the IO-Manager.
This
>would export two ports. The first is a read-only lookup up.
The other
>is a registration port.
>
[SNIP]
I would think that you could also handle Decnet type references
through the server (ie. node::device) in a similiar way to your
'pipe'.
It would just handle half of the process on each system, with a
network link between them.
After getting this to work, clusters may not be too far away.
-------------------------------------------------------------
Kevin Handy kth@srv.net Accounting Software for
Software Solutions. Inc. VAX/VMS Computer Systems
Idaho Falls, Idaho
================================================================================
Archive-Date: Fri, 14 Mar 1997 00:33:18 +0100
Sender: owner-free-vms@lp.se
Date: Fri, 14 Mar 1997 10:01:02 +1100
From: "Scott Hamilton, +61-2-9950 1693, Institute Systems - NSW TAFE ITB" <SHAMILTON1@dev.develop1.tafensw.edu.au>
Reply-To: Free-VMS@lp.se
Subject: Re: $QIO
To: Free-VMS@lp.se
Message-ID: <01IGHLQWYRXE00DAMX@hmgwy1.isd1.tafensw.edu.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Let me try to explain again using Mach language rather than COM.
The Mach kernel exports a "port" as a trusted system entity. This is
essentially a communication point to which messages can be sent.
There is a "trusted" name server from which applications can lookup
named ports. Each request is granted a port which is unique in
time and space. When the port is destroyed the listener of the port
is notified.
So I would have a server called something like the IO-Manager. This
would export two ports. The first is a read-only lookup up. The other
is a registration port.
Sorry! I forgot this was on the MAch environment,
now I understand much more clearly. I need to read
those MAch doc's again I think...
I think what I my thoughts where leading to,
was implementing what was already there!!!!
This now makes things much simpler.
We could then implement a "pipe" server. This server would register
itself with the IO-Manager and provide a port that it listens on. This
port accepts a single message which is OpenDevice().
An application makes a call to $ASSIGN. This would be a function that
exists within the process of the caller. It goes to the name server and
requests a port for the specified device. It then sends an OpenDevice()
request to the server. The server decides if the client is authorized
to
open the device, and if so, returns a new port for the connection. The
$ASSIGN services destroys the initial port and caches the new port in
a local table and returns a short int index into the table (the chan
id).
The application then makes a call to $QIOW. The library function makes
an RPC to the server using the port for the channel and all is great in
the world.
Now there are a couple of issues here. The first is the RPC to the
server.
This could be a generalized message that mimics the $QIO arguments.
The advantage to this is that the code is really simple and the burden
is
on the server. The downside is that every server needs to export a
VMS-like interface as well as any other interfaces. This would not be
the approach that I would take.
I would have $ASSIGN parse the device string and determine the type.
Based on the type, $ASSIGN would then lookup a specific server and
would note both the new port and the type. When $QIOW is called,
the function would basically do a select() statement on the type.
This would invoke code that maps the $QIOW syntax onto a general
RPC that is exported by the server. This means that the library has
to do more work. The upside is that the servers export a general
interface that everyone can use. This increases interoperability.
I personally don't like maintaining select...case statements
can we get the device when registering itself to tell us
what VMS device naming type it supports, so then we have
structure that contains the port of where to send
messages/requests, what sort of devices (either by name
or type???) that server supports and perhaps what
sort of Inter-server/subsystem protocol it supports.
The other issue is that I used $QIOW and not $QIO. VMS functions
are all essentially asynchronous. This causes a real problem when
dealing with multi-process servers. A solution to this is something we
called notices & agendas. The idea was that you passed a token to
the server that represented the post-processing requirements for
a specific RPC call. When the server completed the request, it
would send a notice back to the originating process passing the
token (agenda). A special thread in the process would then process
the agenda. This is a convenient way to implement local event flags
and ASTs. Note that common event flags require a server.
I've not read the doc's yet... this "special thread"
where does that code come from?? The SYS$QIO code? as
long as the user doesn't have to know they need to
call something else to do this.
I think I'll go and have a good read of the doc's for Mach
and try to install it somewhere???
Cheers
Scott, Esq.
Chris
================================================================================
Archive-Date: Sun, 16 Mar 1997 20:37:05 +0100
Sender: owner-free-vms@lp.se
To: <free-vms@lp.se>
Subject: Mach system somewhere [was: Re: $QIO]
Message-ID: <LEVITTE.97Mar16202814@devil.bofh.se>
From: levitte@lp.se (Richard Levitte - VMS Whacker)
Reply-To: Free-VMS@lp.se
Date: 16 Mar 1997 19:28:14 GMT
References: <01IGHLQWYRXE00DAMX@hmgwy1.isd1.tafensw.edu.au>
MIME-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
In article <01IGHLQWYRXE00DAMX@hmgwy1.isd1.tafensw.edu.au> "Scott Hamilton, +61-2-9950 1693, Institute Systems - NSW TAFE ITB"
<SHAMILTON1@dev.develop1.tafensw.edu.au> writes:
I think I'll go and have a good read of the doc's for Mach
and try to install it somewhere???
If you do, would it be possible, would you make it available?
--
R Levitte, Levitte Programming; Spannv. 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-10-222 64 05; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Mon, 17 Mar 1997 20:38:44 +0100
Sender: owner-free-vms@lp.se
Message-ID: <F14AAE60A252CF11B56100805F14DD09022E1773@RED-70-MSG.dns.microsoft.com>
From: Chris Kaler <ckaler@microsoft.com>
Reply-To: Free-VMS@lp.se
To: "'Free-VMS@lp.se'" <Free-VMS@lp.se>
Subject: Re: $QIO
Date: Mon, 17 Mar 1997 09:48:11 -0800
We had proposed having a background thread in every user process that
handled ASTs and callbacks (notices and agendas). It is a fairly clean
solution in that it can easily freeze user threads and process requests.
Look at the VMS-on-Mach paper.
I agree about not wanting large switch blocks. I would probably
implement it as an array of function pointers within the client code and
then branch based on a flag in the channel.
Chris
================================================================================
Archive-Date: Wed, 19 Mar 1997 05:54:38 +0100
Sender: owner-free-vms@lp.se
Message-ID: <v0300782daf5446ea8091@[140.186.88.221]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Mar 1997 08:24:09 -0500
To: Free-VMS@lp.se
From: Dick Munroe <munroe@acornsw.com>
Reply-To: Free-VMS@lp.se
Subject: Re: $QIO
>We had proposed having a background thread in every user process that
>handled ASTs and callbacks (notices and agendas). It is a fairly clean
>solution in that it can easily freeze user threads and process requests.
>Look at the VMS-on-Mach paper.
>
>I agree about not wanting large switch blocks. I would probably
>implement it as an array of function pointers within the client code and
>then branch based on a flag in the channel.
>
>Chris
You may want to think in terms of a truely object oriented implementation
(c++ or whatever). I've done a couple of decent sized projects and
changing things around with C++ has been a joy compared to C, Bliss, etc.
In such a design, I'ld have the channel index into a table of pointers to
objects whose interfaces actually did the work (assign, whatever).
(I'm not trying to start a religious war here, your choice of language is
as good if not better than mine, I'm just making the suggestion in the
hopes of getting a more object oriented design/implementation which would,
IMHO, be easier to maintain/change than a conventional
design/implementation especially in the face of multiple distributed
implementors).
Dick
--
Dick Munroe munroe@acornsw.com
Acorn Software (508) 568 1618 x1
267 Cox St. FAX: 562 1133
Hudson, Ma. 01749 http://www.acornsw.com/
Need a web site? a web server? other web service? Contact us...
"They told me to get Windows 3.1 or better...so I bought a Macintosh"
"Then they told me to get Windows 95 or better...so I bought another Mac!"
"Now they tell me to get Window NT 4.0 Server or better...my new Mac is on
order!"
================================================================================
Archive-Date: Wed, 19 Mar 1997 05:54:58 +0100
Sender: owner-free-vms@lp.se
Message-ID: <v0300782caf5444fd0cce@[140.186.88.221]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Mar 1997 08:18:43 -0500
To: Free-VMS@lp.se
From: Dick Munroe <munroe@acornsw.com>
Reply-To: Free-VMS@lp.se
Subject: Re: $QIO
> I personally don't like maintaining select...case statements
> can we get the device when registering itself to tell us
> what VMS device naming type it supports, so then we have
> structure that contains the port of where to send
> messages/requests, what sort of devices (either by name
> or type???) that server supports and perhaps what
> sort of Inter-server/subsystem protocol it supports.
Doesn't this depend on how you choose to implement the channel interface?
At the assign/dassgn level, you should be free to plug in an OpenVMS device
name (or logical name). You don't particularly care what it is, but you DO
care that it remain the same forever (or, relatively speaking, forever.
We've all fried disk controllers and had to clean up the resulting logical
new device name problems). But this sort of thing can be handled in a
couple of ways:
1. user maintained "environment" files that effectively define the device
mapping (or, more generally, the logical name translations which can then
be handled any way you want).
2. Server/Service interfaces that define how mapping from "my name" to
"OpenVMS Device Name" is to be managed.
The problem as I see it is on of consistency, so that device A and B from
different servers can be seen in any order and still have the same device
names across invocation of the OpenVMS "environment". In effect a
distributed auto configure.
Dick
--
Dick Munroe munroe@acornsw.com
Acorn Software (508) 568 1618 x1
267 Cox St. FAX: 562 1133
Hudson, Ma. 01749 http://www.acornsw.com/
Need a web site? a web server? other web service? Contact us...
"They told me to get Windows 3.1 or better...so I bought a Macintosh"
"Then they told me to get Windows 95 or better...so I bought another Mac!"
"Now they tell me to get Window NT 4.0 Server or better...my new Mac is on
order!"
================================================================================
Archive-Date: Wed, 19 Mar 1997 20:12:21 +0100
Sender: owner-free-vms@lp.se
Message-ID: <F14AAE60A252CF11B56100805F14DD09022E1789@RED-70-MSG.dns.microsoft.com>
From: Chris Kaler <ckaler@microsoft.com>
Reply-To: Free-VMS@lp.se
To: "'Free-VMS@lp.se'" <Free-VMS@lp.se>
Subject: RE: $QIO
Date: Wed, 19 Mar 1997 11:07:36 -0800
Sorry, I was trying to raise a different point.
My point was that I would have servers/services export
a standard, os-neutral, interface. It would be the job of
the client library to map os-specific interfaces to the
os-neutral interfaces. My point was that this is most
likely device specific. So the $ASSIGN would map
to a device type (however you want) and then $QIO
would branch to a device-specifc handler. I described
this as a big switch statement, but I would probably
implement it as an array of pointers to whatever
(functions, classes, interfaces, ...).
I agree that you want a consistent naming method for
devices. I would think that you would want it to be
system-wide. Users can always customize it using
logical names.
Chris
-----Original Message-----
From: Dick Munroe [SMTP:munroe@acornsw.com]
Sent: Tuesday, March 18, 1997 5:19 AM
To: Free-VMS@lp.se
Subject: Re: $QIO
> I personally don't like maintaining select...case
statements
> can we get the device when registering itself to tell us
> what VMS device naming type it supports, so then we have
> structure that contains the port of where to send
> messages/requests, what sort of devices (either by name
> or type???) that server supports and perhaps what
> sort of Inter-server/subsystem protocol it supports.
Doesn't this depend on how you choose to implement the channel
interface?
At the assign/dassgn level, you should be free to plug in an
OpenVMS device
name (or logical name). You don't particularly care what it is,
but you DO
care that it remain the same forever (or, relatively speaking,
forever.
We've all fried disk controllers and had to clean up the
resulting logical
new device name problems). But this sort of thing can be
handled in a
couple of ways:
1. user maintained "environment" files that effectively define
the device
mapping (or, more generally, the logical name translations which
can then
be handled any way you want).
2. Server/Service interfaces that define how mapping from "my
name" to
"OpenVMS Device Name" is to be managed.
The problem as I see it is on of consistency, so that device A
and B from
different servers can be seen in any order and still have the
same device
names across invocation of the OpenVMS "environment". In effect
a
distributed auto configure.
Dick
--
Dick Munroe munroe@acornsw.com
Acorn Software (508) 568 1618 x1
267 Cox St. FAX: 562 1133
Hudson, Ma. 01749 http://www.acornsw.com/
Need a web site? a web server? other web service? Contact us...
"They told me to get Windows 3.1 or better...so I bought a
Macintosh"
"Then they told me to get Windows 95 or better...so I bought
another Mac!"
"Now they tell me to get Window NT 4.0 Server or better...my new
Mac is on
order!"
================================================================================
Archive-Date: Wed, 19 Mar 1997 20:23:02 +0100
Sender: owner-free-vms@lp.se
Message-ID: <F14AAE60A252CF11B56100805F14DD09022E1788@RED-70-MSG.dns.microsoft.com>
From: Chris Kaler <ckaler@microsoft.com>
Reply-To: Free-VMS@lp.se
To: "'Free-VMS@lp.se'" <Free-VMS@lp.se>
Subject: RE: $QIO
Date: Wed, 19 Mar 1997 11:03:03 -0800
I prefer C++ to C myself... the problem is really one of control.
We were trying to maintain the semantic That only one
user-mode AST can run at a time. So we had a separate
thread that would suspend all other threads, call the AST,
then resume all threads. This is a simple, portable, and
reasonably fast way to implement ASTs. Now if we want
to relax this, I would go with classes as suggested and
hide the implementation in the method. We could also
use derived classes to only implement ASTs once.
-----Original Message-----
From: Dick Munroe [SMTP:munroe@acornsw.com]
Sent: Tuesday, March 18, 1997 5:24 AM
To: Free-VMS@lp.se
Subject: Re: $QIO
>We had proposed having a background thread in every user
process that
>handled ASTs and callbacks (notices and agendas). It is a
fairly clean
>solution in that it can easily freeze user threads and process
requests.
>Look at the VMS-on-Mach paper.
>
>I agree about not wanting large switch blocks. I would
probably
>implement it as an array of function pointers within the client
code and
>then branch based on a flag in the channel.
>
>Chris
You may want to think in terms of a truely object oriented
implementation
(c++ or whatever). I've done a couple of decent sized projects
and
changing things around with C++ has been a joy compared to C,
Bliss, etc.
In such a design, I'ld have the channel index into a table of
pointers to
objects whose interfaces actually did the work (assign,
whatever).
(I'm not trying to start a religious war here, your choice of
language is
as good if not better than mine, I'm just making the suggestion
in the
hopes of getting a more object oriented design/implementation
which would,
IMHO, be easier to maintain/change than a conventional
design/implementation especially in the face of multiple
distributed
implementors).
Dick
--
Dick Munroe munroe@acornsw.com
Acorn Software (508) 568 1618 x1
267 Cox St. FAX: 562 1133
Hudson, Ma. 01749 http://www.acornsw.com/
Need a web site? a web server? other web service? Contact us...
"They told me to get Windows 3.1 or better...so I bought a
Macintosh"
"Then they told me to get Windows 95 or better...so I bought
another Mac!"
"Now they tell me to get Window NT 4.0 Server or better...my new
Mac is on
order!"