| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3233.1 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Tue Jun 23 1992 12:14 | 13 |
| Yes, in fact its the whole idea behind all the work that went into
MCC.
You may add partitions and then support access to them by writing
an AM that is dispatched to only for class NODE4 <new_partition>. In
fact a single AM may do this on behalf of an added partition for
any number or all classes.
The existing REFERENCE partition is an example of such a partition.
It is supported for the REGISTRATION FM (acting as a reference AM).
Thus all classes get references attributes and no code is written
in their existing AMs.
|
| 3233.2 | I don't think so. | TOOK::MCPHERSON | Life is hard. Play short. | Tue Jun 23 1992 13:31 | 15 |
| Jim, I don't think what you explained is possible with MCC right now. Attribute
partitions are bounded.
You *can* specify an EVENT partition (e.g. Configuration Events, Notification
Events, etc), but not any other partitions. The SRM was ECO'd to include
support for event partitions, but there is no capability (yet) to arbitrarily
add any other new partitions for dispatching. I'm pretty sure that the MSL
translator will barf.
In other words, "There is nothing inherent in the architecture that would
preclude this, but the actual product capabilities do not allow this."
Prove that I'm wrong and large 3-letter DECmcc OEM will be ecstatic...
/doug
|
| 3233.3 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Tue Jun 23 1992 14:00 | 11 |
| There's actually nothing inherent in the implementation either that
stops this with the exception of MSL.
I just went into the dictionary with DAP and added attribute partition
FOOBAR to class SNMP. FCL parses it and it comes up under the SHOW
submenu on the iconic map, (it gets an unsupported V,E,P combination
trying to dispatch to it, as I would expect since I didn't enroll an MM
to field it).
I'll look into expediting what should be a trivial ECO.
|
| 3233.4 | I'd be interested to *see* this one... ;^) | TOOK::MCPHERSON | Life is hard. Play short. | Tue Jun 23 1992 14:23 | 17 |
| <conversation w/Jim deleted>
If you gotta, here's a gameplan:
You can hack a new partition into the dictionary with DAP, no prob.
Write up the new partition into your existing MSL but USE A PRE-DEFINED
ATTRIBUTE PARTITION. MSL xlator will BARF if it sees any ATTRIBUTE partitions
other than the pre-defined ones it knows about (Ident, status, char etc).
Once the DAP .COM file is produced, go into it and replace any occurrences of
the PRE-DEFINED partition you used with the NEW partition you zapped into the
dictionary via DAP.
It's not pretty; it's not supported, but it should work.
Good luck.
/doug
|
| 3233.5 | It should be supported ! | CCIIS1::ROGGEBAND | _ �hili��e _ | Wed Jun 24 1992 05:23 | 25 |
| Re: .-1
I presume you also have to assign a code to the partition so that the
PM can match the partition name with a numeric code for the partition
parameter ?
�It's not pretty; it's not supported, but it should work.
I have always believed that when you developped an FM, there were two
basic ways to provided value-added features to DECmcc :
1) Provide new value-added verbs (eg: RECORD, Diagnose etc...)
2) Provide new attribute partitions (Statistics, Reference, whatever)
I'm *very* surprised to find out that (2) is not supported...
especially as the only "blocking factor" seems to be the MSL
translator....
Any hopes of a patch to solve this ? I have several customers who
*need* to add new partitions...
Regards,
Philippe.
|
| 3233.6 | Known bug in MSL Translator | TOOK::GUERTIN | It fall down, go boom | Wed Jun 24 1992 07:34 | 5 |
| The inability of the MSL translator to allow the developer/architect to
define new attribute partitions is a known bug. I thought it was to be
supported (via a different syntax) in V1.2, I guess it didn't make it in.
-Matt.
|
| 3233.7 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Wed Jun 24 1992 10:06 | 3 |
| Yes, this is taking on more of the aspects of a bug rather than
a restriction.
|
| 3233.8 | | CCIIS1::ROGGEBAND | _ �hili��e _ | Wed Jun 24 1992 11:05 | 7 |
| Thanks for the prompt answer, now the subsidiary question is (of
course) when can we expect a fix ? Has this been QAR'ed ?
I expect my customers will agree to using the workaround if I tell them
that this will be resolved within a reasonable timeframe.
�hR.
|
| 3233.9 | new partition ? | ANNECY::ROUX | Denis @AEO (887-4059) | Thu Jul 02 1992 03:58 | 7 |
| Thanks to all of you Jim/Doug/Matt/Phil
We are going to use this proposed workaround and create a new partition.
Anyway, I'm now more confident in the fact that It's seen more as a bug
as a restriction. I have an another customer who wants to use this
feature.
Denis
|
| 3233.10 | Ok. Let us know how it works. | TOOK::MCPHERSON | Life is hard. Play short. | Thu Jul 02 1992 09:13 | 20 |
| > We are going to use this proposed workaround and create a new partition.
> Anyway, I'm now more confident in the fact that It's seen more as a bug
> as a restriction. I have an another customer who wants to use this
> feature.
Ok, but please remember to proceed with caution.... Remember that
attribute partitions must use UNIQUE codes and are supposed to be
registerd through the DECmcc Registrar, same as Global Entity codes.
If you mess up and choose one that's already in use by some other
application, then you may run into some probably 'non-obvious'
problems.
Unless you really need to change dispatching behavior, then the easiest
way for you to proceed may be by defining a new ATTRIBUTE GROUP
(something that's been supported for a while and is used by several
AMs.)
/doug
|