| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 129.1 | The user, not DA, provides the structure | TOOK::SCHLENER | | Fri May 11 1990 17:14 | 15 |
| The user of the DA routines must provide the address of an MCC$R_DA_IOB
structure whether the user defined a structure statically or allocated
one from "heap".
According to the SRM for MCC$DA_CONNECT_INITIATE (or any of the DA
routines) the MCC usage is MCC$R_DA_IOB. If the DA services were
to allocate the iob structure, you would have had to pass in a pointer
to an unsigned long ( which would contain the address to the iob
structure). Hence double indirection.
In that case, the MCC usage would have been defined as an unsigned long
and not the actual structure.
Cindy
|
| 129.2 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Mon May 14 1990 09:25 | 10 |
| Actually, we are probably going to delete these routines from the SRM
before we ship V1. They are blatantly non-portable (iosbs,
mailboxes, ncbs, and the like are all visible) and furthermore don't
provide access to phase V decnet.
You probably noticed they don't do much of anything you couldn't do for
yourself by calling SYS$QIO directly.
A more generic set of decnet interface routines will be developed for
the 1.1/2.0 timeframe.
|
| 129.3 | Extensibility could be a problem... | SMAUG::BELANGER | Quality is not a mistake! | Mon May 14 1990 12:02 | 22 |
|
I realize they are not portable (I have a portable communications
interface definition, if you want an example for your definition).
The problem with the MCC$DA_xxx routines, is that the user is
explicitly told that he/she does not have to know about this DA_IOB
data structure, but they have to allocated (which means they have to
know something about it; the size). Also, when dealing with these
types of structures, if the user allocates them, there is now way to
make additions to the data structure without breaking old code (ie: the
DA_IOB data structure is 8 bytes long (just a guess) and is sufficient
for the needs of a Phase IV environment, but in the Phase V environment
we need a data structure 12 bytes long. There is a problem with the
old code being able to migrate without the need to have another release
to support the new functionality). Therefore, I would suggest that if
DECmcc is to be "somewhat" portable and extensible, those data
structures that are needed be allocated/freed by DECmcc. This way a
new release of DECmcc will allocate the data structures properly
without the need of other products layered on DECmcc also having to
re-release.
~Jon.
|
| 129.4 | There is some value. | TOOK::SCHLENER | | Mon May 14 1990 12:06 | 11 |
| However, you should not do a direct call to the QIO services but use
the MCC QIO services. By doing a call to QIO, you will block the entire
MCC process. If you use the MCC services, they provide a monitor that
will not cause the MCC process to block.
I feel that we should keep the MCC DA routines but perhaps title them
differently so that it is clear they relate to Phase 4 DECnet access.
They do provide some value hence saving people some time if they need
to use Phase 4 DECnet.
Cindy
|
| 129.5 | MCC$QIOW is obsolete, use SYS$QIOW | PETE::BURGESS | | Mon May 14 1990 16:11 | 20 |
| >
> However, you should not do a direct call to the QIO services but use
> the MCC QIO services. By doing a call to QIO, you will block the entire
> MCC process. If you use the MCC services, they provide a monitor that
> will not cause the MCC process to block.
>
No.
This restriction vanished by ift of DECember 89 when blocking
composite system services were intercepted and revectored to thread
synchronous rtns.
I am proposing that documentation for MCC$QIOW, MCC$<rms>
be removed from the SRM. The stop-gap routines may live on, but new
code should use SYS$QIOW, SYS$<rms>, etc!
Kernel developer,
Pete Burgess
|