| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
With the emergence of FDDI support in the VMS and Ultrix device
drivers, will there be a new set of FDDI access routines, similar
to the Ethernet access routines (mcc_ea_...)?
If an MCC application is sending 802 type LLC traffic then I
believe the existing Ethernet access routines will be ok. In
my case, I plan to generate and receive non-LLC traffic (FDDI
Station Management SMT frames), which the existing routines
don't support. I will probably supplement the existing set
with extensions to support SMT traffic. (This is a few months
away, at least.)
Paul C
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1146.1 | Your changes can be the extensions | TOOK::MATTHEWS | Mon Jun 17 1991 20:09 | 7 | |
Paul, I may be speaking out of turn, but I would think that once you
supplement the mcc_ea_... with the fddi extensions, you should submit
them as an extension to the common routines. I would work this through
Chris Brienen because his group has done all the mcc_ea stuff in the
past.
wally
| |||||
| 1146.2 | Oh, ok ... | QUIVER::CIARFELLA | When in doubt, mumble. | Mon Jun 17 1991 20:36 | 3 |
Thanks. This sounds acceptable. I didn't realize that Chris Brienen's
group developed them.
| |||||
| 1146.3 | Definitely integrate with current mcc_ea! | ALLZS::MORRISON | The world is a network | Wed Jun 19 1991 12:59 | 14 |
Yes, we had even done some tracking of the FDDI specs in anticipation
of this, but schedule pressures prevented us from doing much more than
that. You are correct in saying that the mcc_ea_* routines SHOULD
(obviously we'd want to test it extensively first) correctly handle FDDI
adapters when doing non-FDDI specific work such as you mention in .0.
From the way the code is structured, I suspect that adding full support
for FDDI would involve a MUCH smaller effort than what we did for Ethernet,
since much of the code would be common (retries, multiple-port handling,
protocol locking, etc.). When we did the port to ULTRIX, only a half dozen
or so out of 25+ modules needed to be completely rewritten, and I would
expect that a similar ratio would apply for adding FDDI support.
Wayne
| |||||