| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 18.1 | SOLUTION: check the following | GOSTE::CALLANDER | | Fri Oct 06 1989 09:45 | 56 |
|
Okay, there could be a number of things. If you check out the release
notes you should find a set of worksheets. These can be used to
help you walk through the problem and some of the more common possible
solutions.
I don't have the worksheets in front of me, but I would suggest
that you start with the one about verifying codes.
In documenting your problem you used the names of the fields, like
"SET". The names are only used in parsing. These are then translated
into the internal codes for passing across the interface. If the
codes don't match everywhere, this includes matching other dictionary
entries for the same class of data, then what goes across the interface
may not match anything.
Some examples, example 1:
MS 1 defines SET as code 1
MS 2 defines SET as code 2
PTB will print a warning about this, but the parse tables will
make ALL SETs code 1 (so if you were MS 2 and code 2 is what
you used in generating your vector tables, you won't dispatch)
example 2:
MS defines CLASS as code 1
VECTOR.MAR defines CLASS as code 2
This could happen for a number of reasons (like changing your
MS and not recompiling with the new header file generated by
the translator), but no matter what the reason it will not
dispatch
example 3:
MS 1 defines CLASS 1 as code 1
MS 2 defines CLASS 2 as code 1
As you know certain codes spaces are flat, if you or some one
else infringes on some one elses code space, you will get a
warning from PTB and both entries in with the same code. It
will then be up to the dispatcher to decide which entry point
gets the call.
Finally there is one thing to note. One of the known bugs documented
in the release notes is the inability for the system to handled
codes greater than 255. This will be rectified, but not until the
field test update.
|
| 18.2 | | SCRPIO::LIZBICKI | | Fri Oct 06 1989 12:57 | 18 |
| >> mcc$dispatch_entry -
>> SET,-
>> <MCC$ENTITY <TIMER,*>>, -
>> NULL,-
>> MCC$TIMER_AM_SERV_SET
I believe the problem is that in the dispatch table entry, you specified
NULL for the attribute group. I assume SECONDS and EXPIRATION are
characteristic attributes, and therefore, instead of "NULL" you should
have "CHAR".
mcc$dispatch_entry -
SET,-
<MCC$ENTITY <TIMER,*>>, -
CHAR,-
MCC$TIMER_AM_SERV_SET
|
| 18.3 | MCC$CONTROL_FM? | CHRISB::BRIENEN | Christopher J. Brienen | Fri Oct 06 1989 18:50 | 1 |
| Also verify that MCC$CONTROL_FM is enrolled!
|
| 18.4 | PROBLEM - solved, I fear the next one. | KETJE::PACCO | | Wed Oct 11 1989 15:58 | 17 |
| In this case note 18.2 solved my problem.
I would once more stress the fact that writing a management module is
not an easy task, at this time at least, because it requires very
strict developement rules in order to avoid mysterious problems like
this one which in fact could have been eliminated if cross checking
between code, management specifications, enrolment information was more
integrated.
I don't blame at all that such a tool does not exist, but because the
rules are quite complex we will have to take care of this in making
e.g. a booklet giving a list of the rules to follow, step by step, to
produce immediately a well structured access module. This cookbook
will become even more useful once functional modules start to be
written by non engineering people.
Dominique.
|
| 18.5 | INFO - cross reference documentation | GOSTE::CALLANDER | | Thu Oct 12 1989 09:35 | 8 |
|
Work in this area has already been started. The project lead of
the DECmcc SRM has taken on the effort of documenting just what
information needs to be cross checked. At this time where this will
be documented (in what manual) is still under discussion. When
something does come available a pointer to it will be placed in
this notes file.
|