| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2314.1 | More | MAYDAY::ANDRADE | The sentinel (.)(.) | Fri Feb 14 1992 05:22 | 54 |
| On the same note:
The customer's EXPORTER bacground process goes into RWMBX state,
just trying to export fort a few entities. And it happens just a
few minutes after exportation starts. NO data is exported at all.
The VAXstation 3100 and the account running MCC have all the
recomended quotas, but this still seems to happen.
Has anyone an idea, of what needs to increased ?
DECmcc should be able to run on a VAXstation 3100 provided it has
all the required quotas. What are the implicit quotas, normally
set on a big system but not on a standalone VAXstation, and not
mentioned by the DECmcc Installation Guide ?
I guess we could up everything, but then too many resources would
be used, and bring the system to a halt anyway. I guess upping the
Fillm, Enqlm, and Bytlm for the account running DECmcc would help
the polling/exporting, but what about system parameters/quotes ?
Extract from the problem report:
----------------------------------------------------------------
The background process goes in RWMBX state, I tried a minimum
troubleshooting, using the ANALYZE/SYSTEM I found that the
process is waiting for a MailBox and another MailBox is BUSY.
Also, if I tried command like:
MCC>SHOW NODE4 nodename EXPORTING TARGET database, IN DOMAIN
domainname
The command (and the interactive process) hangs. Using the DCL
command $ COPY NL: MBAxxx I was able to de-hangs the SHOW
command,
but after a while the batch's backgound process die,
the error in the log file is QFILE-E-OPENERR.
If I don't try to solve the the Mailbox problem using the
COPY NL: MBAxxx, the background process don't die (at least for
4 hours).
******* I tried also to export only few data (4-5 entities)
and in this case all works.
I checked on the notes files and I found some topics (1182 and
2247) with a problem similar to mine, but no indication if
there's a workaround, if it's a bug and if there's a patch or if
is a HW (memory I think) problem.
I'll try to reproduce the same problem on a internal VAX.
|
| 2314.2 | Understand your frustration, BUT... | MCDOUG::MCPHERSON | Scientific progress goes 'Boink!' | Fri Feb 14 1992 09:06 | 21 |
| re .0
> - Problems are marginally tracked and problems owners left alone
> with their mumblings on the notes-file with no answers (here I'm
> not talking about ft versions for which patience and sense of humour
> are strongly required)
Most VAXnotes conferences (MCC conference in particular) are NOT considered
official support mechanisms. Although the MCC developers _do_ try to help
communicate fixes and other information on SSB-released versions as well as
FT versions in the MCC conference, they are in NO WAY REQUIRED TO DO SO.
They try to turn around answers on most the of notes within 24 hours,
workload permitting.
So please don't slam them if you're having a hard time getting a problem
resolved through the MCC conference. If it's a critical matter, please
also use the supported, established mechanisms such as QARs, SPRs, etc. I
repeat: The MCC conference is NOT an official support mechanism.
regards,
/doug
|
| 2314.3 | No slamming | MLNCSC::MILANA | Patior ut Potiar...NETWORKS: | Fri Feb 14 1992 11:27 | 43 |
| Re:-1
Doug,
thanks for taking the time to answer my question(s). Believe me when I
say I perfectly understand your point (I was on the same boat until few months
ago...).
It's also perfectly clear the scope of this useful vehicle of informations and
the uniqueness and value of this point of contact between the field and the
engineering side, the general "mcc-folklore" NotesFile.
Of course, if it was just a matter of a bug it'd be also clear what to do and
how and where.
Fact is that the problem in .0 is so general and so macroscopic I can hardly
figure out how to put down an SPR.
Infact we are still considering it as a huge lack of directly related informa
tions, system or product-related.
Meanwhile we trust DECmcc so much (because we know the competition and their
products) that we based our Network Management Service offer on it. That means
we are providing consultancies-related services (NMOS and the like) on DECmcc
and its functionalities, the ones written everywhere but hard to demonstrate.
And I'm responsible for the technical aspects of the customization and delivery
of such offer.
I only attended up to the AM-DVL stage of the DECmcc training string, still
can't cope with the overwhelming number of complaints coming from the various
Regions, here in Italy, where it's reported that monitoring of less than 20
entities are enough to kill a VS3100/76 with 32mb of memory.
There must be something we (I) are(am) missing!
If it's just a matter of collecting tips around this precious notesfile ok, I'll
do it, but then again I can't figure a Service based on something not casted in
marble or delivered in the Release Notes of DECmcc.
My initial questions just shouted (sorry) this uncertainity which didn't want to
slam anybody.
Now, back to the point: is anybody carrying any ('hope positive) experience on
the subject? Anybody installed/operated DECmcc on a VS3100/xx with plenty of
memory and storage on (how many) entities? (Credit cards accepted? %^)
Thanks for your patience
Giuseppe.
|
| 2314.4 | QAR it or escalate it. | TOOK::R_SPENCE | Nets don't fail me now... | Fri Feb 14 1992 17:27 | 11 |
| Also, if you don't know if it is a bug and you have a problem customer
situation, use the escalation process to get help.
All field units have a defined process to escalate problems (the US
field people got a new chart last week).
If you think it is a misfeature, QAR it. If it is a performance issue,
QAR it. That is how engineering can track problems and get management
support to spend resources on changes/fixes.
s/rob
|
| 2314.5 | No news, BAD news! | MLNCSC::MILANA | Patior ut Potiar...NETWORKS: | Mon Feb 17 1992 04:42 | 13 |
|
As I said, we are already escalating the problem thru the official
channels and Valbonne is fully involved (see .2 in this entry).
Fact is that Customers living with DECmcc given as the incarnation of a Digital
Service, NMOS, are stuck with it! No panic, no slams, just crude reality.
If we choose not to rely on a product with the (published) features of DECmcc
we're gonna have dire times with direct competitors.
That's why I'm here trying to understand if there's anybody out there using
DECmcc in real life, sampling, alarming, managing, exporting, reporting, etc...
Am I asking too much? I won't think so.
Giuseppe.
|
| 2314.6 | RE:.3 -- Something strange is going on over there | TOOK::GUERTIN | Don't fight fire with flames | Mon Feb 17 1992 07:06 | 25 |
| >>> I only attended up to the AM-DVL stage of the DECmcc training string, still
>>> can't cope with the overwhelming number of complaints coming from the various
>>> Regions, here in Italy, where it's reported that monitoring of less than 20
>>> entities are enough to kill a VS3100/76 with 32mb of memory.
>>> There must be something we (I) are(am) missing!
I can't help feeling that I'm opening a can of worms. But I can't
resist (morbid facination, I guess). ****20**** Entities!!!! are all
that the customer can manage?!?!?! We are off by a factor of 10 from
what engineering have been STRESS TESTING with (where the testing goal
is to KILL MCC by overstressing it). The most inefficient way to use
MCC to monitor a network is by polling. So let's assume for the moment
that the customer is only polling. This takes up a large amount of
CPU, because of the continuous multiple thread processing. This also
takes up a lot of I/O because of all the network requests and
responses. (This is why most people use Events whenever possible.)
Still, I cannot see any reason why the customer cannot monitor/manage
at least 200 entities. What else is running on their system? Is it a
multi-user environment? How is the system tuned? Has any performance
analysis been done on the system? Can you describe the network?
Yes, you're right, something is seriously wrong here. But we need some
real (empirical) data to determine what is happening.
-Matt.
|
| 2314.7 | Let's talk about it... | MLNCSC::MILANA | Patior ut Potiar...NETWORKS: | Mon Feb 17 1992 09:25 | 53 |
| re: -1
Actually there would be well over 20 entities to manage for each of the
involved customer sites. With the problems popping up after less than 20, tho,
I couldn't feel comfortable at all with 200!
With the available docs in one hand a system tuning for DECmcc was attempted,
after the general needs were satisfied (AUDIT_MCC.COM ran successfully), but
things didn't change substiantially.
A couple of suggestions came from this notesfile (thanks) but didn't solve the
main issue.
So, it is my belief that there's something wrong but, to our frustation, nothing
appears to be...
Here are some details:
- Dedicated, standalone VS3100/76, 32Mb memory, 1.2Gb disks (2xRZ56s),
VMS V5.4-3, BMS V1.1
- All activities run from SYSTEM account with these relevant quotas:
FILLM=500,BIOLM=72,DIOLM=60,ASTLM=100,TQELM=128,ENQLM=2300,
BYTLM=200000,JTQUOTA=4096,WSDEF=512,WSQUO=4096,WSEXTENT=20000,
PGFLQUO=120000 (WSMAX=20000 & PAGEFILE.SYS=200000 Blks)
ALL privileges...
and the following SYSGEN parameters:
<the ones suggested by AUDIT_MCC.COM> plus GBLSECTIONS=500,
GBLPAGES=52300,GBLPAGFIL=12200,MAXPROCESSCNT=130,BALSETCNT=117,
SRPCOUNT=2340,IRPCOUNT=1343,LRPCOUNT=128 (also their 4x virtual
values), PQLMASTLM=600,CHANNELCNT=512, etc. (full list on request)
- The customer's network configuration includes a VaxStation 3100, a LPS20 and
a node acting as a local router, a 6420 with 64Mb and VMS V5.4-3, which has a
DEBNA interface and a DMB32 with a total of 6 asynch lines used for DDCMP
point-to-point links. The LAN is a "yellow" thick-wire one.
Add the management station, the abovementioned VS3100/76.
- The total number of involved nodes is 15.
Every EXPORT attempt aborts with "%MCC-E-ALERT_TERMREQ, thread termination
requested"
This is it for the specific customer problem being escalated thru Valbonne.
We then tried to reproduce the problem in-house and we were successfull indeed:
On a VS3100 with the same configuration and less than 15 nodes we had the
very same problem. All nodes were on the same LAN.
(Attempt performed by a third specialist to limit the "human factor").
The experiment is now being attempted on a 6420 with 94Mb and some RA90s with
larger quotas and some first hand results are confirming the above behaviour.
Still working on this... More feedbacks to come...
Ciao, Giuseppe.
|
| 2314.8 | A possible BUG???? | MLNCSC::MILANA | Patior ut Potiar...NETWORKS: | Tue Feb 18 1992 04:43 | 82 |
| Something is moving on:
while playing with the different, possible, combinations, it was discovered
that not all node4 entities are created equal.
This evidence might be of no help if everything is working properly but looks
like a blocking factor to DECmcc/Exporter.
In short, these entities may have circuit layouts that differ each other in
that they have some ADDITIONAL attributes.
Here are some printouts:
$ mana/ent
DECmcc (V1.1.0)
MCC> show node4 saetta circuit sva-0 all counters
Node4 46.282 Circuit sva-0
AT 18-FEB-1992 10:17:09 Counters
Examination of Attributes shows:
Counter Creation Time = 17-FEB-1992 16:04:54.21
Seconds Since Last Zeroed = >65535 Seconds
Terminating Packets Received = 75767 Packets
Originating Packets Sent = 63716 Packets
Terminating Congestion Loss = 0 Packets
Corruption Loss = 0 Packets
Circuit Down = 0
Failure to Initialize = 0
MCC>
MCC> show node4 nebbia circuit bna-0 all counters
Node4 46.364 Circuit bna-0
AT 18-FEB-1992 10:18:17 Counters
Examination of Attributes shows:
Counter Creation Time = 18-FEB-1992 00:55:52.69
Seconds Since Last Zeroed = 33745 Seconds
Terminating Packets Received = 207470 Packets
Originating Packets Sent = 371206 Packets
Terminating Congestion Loss = 0 Packets
Transit Packets Received = 0 Packets
Transit Packets Sent = 0 Packets
Transit Congestion Loss = 0 Packets
Circuit Down = 0
Failure to Initialize = 0
Adjacency Down = 0
Peak Adjacencies = 1
Data Blocks Sent = 373455 Blocks
Bytes Sent = 35466651 Bytes
Data Blocks Received = 209720 Blocks
Bytes Received = 13609441 Bytes
Unrecognized Frame Destination = 0 Errors
User Buffer Unavailable = 0 Errors
MCC>
The first SHOWs an LPS20 circuit's counter while the second SHOWs the Vax 6410
ones.
As you may notice the LPS20 sports one ADDITIONAL attribute not presented by
the 6410, Corruption Loss.
This seems to be more than enough to cause a:
...
$ BTS == "$SYS$SYSTEM:MCC_EXPORTER_FM_BG.EXE"
$ BTS "SYS$COMMON:[SYSMGR]TEST.RDB"
%MCC-E-ALERT_TERMREQ, thread termination requested
SYSTEM job terminated at 18-FEB-1992 09:52:10.53
Accounting information:
Buffered I/O count: 13875 Peak working set size: 4472
Direct I/O count: 18281 Peak page file size: 11768
Page faults: 4077 Mounted volumes: 0
Charged CPU time: 0 00:04:30.19 Elapsed time: 0 16:35:33.44
$
wwhen trying to EXPORT the abovementioned data. Infact this happened to
the background exporter whose logfile it's referred to immediately after issue
ing the EXPORT command from DECmcc interactive.
Further research is goin' on with the same evidences popping up for VT1XXXs and
VS2000s used as XTERMs, yet to be confirmed.
Thanks alot to Barbara, a contractor working here in DEC Milan, who helped a
great deal in tracking the problem down to the single entity level.
Giuseppe.
|
| 2314.9 | re: .8 | TOOK::SHMUYLOVICH | | Tue Feb 18 1992 11:11 | 29 |
|
Re: .8
"%MCC-E-ALERT_TERMREQ, thread_termination requested" error has been
discussed several times in this conference.
In V1.1 Exporter is very sensitive to the information in the data
dictionary. If, for example, Show command returns an attribute which has
a data type different from what is defined in the data dictionary the
background dies with the above error. I think that this is your case.
Another known problem in V1.1 Exporter is the case when Show command returns
an argument twice.
In V1.2 Exporter can handle situations described above.
Please, do the following:
1. define logical: def MCC_FCL_PM_LOG 8
2. from MCC:
a. Show <entity_which_kills_exporter> all attribute
b. Show <entity_which_kills_exporter> all statistics
c. Show <entity_which_DOES_NOT_kill_exporter> all attribute
d. Show <entity_which_DOES_NOT_kill_exporter> all statistics
If you send me (TOOK::SHMUYLOVICH) or post here the result we'll try to
identify your problem.
Regards, Sam
|
| 2314.10 | We are getting better all the time | TOOK::GUERTIN | Don't fight fire with flames | Tue Feb 18 1992 14:59 | 7 |
| RE:.7
No one feels comfortable with 200 entities. I was only trying to
describe the stress-test environment that we commonly run with. The
design center is 2000 entities. We are making a lot of progress,
stay tuned for more performance improvements with upcoming releases.
-Matt.
|
| 2314.11 | You may be in luck | TOOK::GUERTIN | Don't fight fire with flames | Wed Feb 19 1992 06:02 | 9 |
| RE:.8 & 9
If what Sam says is true, and the dictionary is out of synch with the
application which is returning the data to the Exporter, then you may
be in luck. I've seen such situations often corrected simply by
"zapping" the dictionary with the right data by using the DAP program
(VERY carefully).
-Matt.
|
| 2314.12 | Sound interesting... | MLNCSC::MILANA | Patior ut Potiar...NETWORKS: | Wed Feb 19 1992 08:51 | 9 |
| re: -1
Can you give more details on that? An interim solution would be great
to allow DECmcc to work as advertised (the other workaround being EXCLUDING the
abovementioned entities from the EXPORT sequence %^(
I'm taking the time to send some outputs from DECmcc, as requested in .9. I'll
mail them directly to Sam and post the final thoughts here.
Giuseppe.
|
| 2314.13 | Couldn't wait... | MLNCSC::MILANA | Patior ut Potiar...NETWORKS: | Wed Feb 19 1992 11:28 | 307 |
| Further analysis using the DAP utility did show that the suspected
subclass attribute is indeed presented by DECmcc (see appended output log).
It could be argued that the EXPORTER isn't creating the corresponding field in
the adequate relation in the target RDB file. Just a thought, needs to be demon
strated...
...more to come,
Giuseppe.
-------------------------------- Output LOG ------------------------------------
(command used: SHOW CLASS NODE4 SUBCLASS CIRCUIT)
DECmcc Dictionary Administrator Program Version V1.1.0
Class (1) : NODE4
---> Subclass (2) : CIRCUIT
Definition (3) : PRESENTATION_NAME
Definition (3) : INSTANCE_REQUIRED
Definition (3) : DYNAMIC
Definition (3) : INSTANCE_DATATYPE
Definition (3) : VARIANT_SELECTOR
Subclass (2) : ADJACENTNODE 40
Attribute (5) : ACTIVEBASE 101
Attribute (5) : ACTIVEINCREMENT 102
Attribute (5) : ADJACENCYDOWN 146
Attribute (5) : ADJACENTLISTENTIMER 170
Attribute (5) : ADJACENTNODEADDRESS 169
Attribute (5) : ADJACENTNODENAME 168
Attribute (5) : ADJSTATLISTENTIMER 173
Attribute (5) : ADJSTATNODEADDRESS 172
Attribute (5) : ADJSTATNODENAME 171
Attribute (5) : AVERAGEINBOUNDBLOCKSIZE 1304
Attribute (5) : AVERAGEOUTBOUNDBLOCKSIZE 1303
Attribute (5) : BABBLETIMER 97
Attribute (5) : BLOCKING 67
Attribute (5) : BLOCKSIZE 130
Attribute (5) : BYTESRECEIVED 151
Attribute (5) : BYTESSENT 152
Attribute (5) : CALLSFAILED 150
Attribute (5) : CALLSPLACED 149
Attribute (5) : CHANNEL 93
Attribute (5) : CIRCUITDOWN 144
Attribute (5) : CONNECTEDNODE 117
Attribute (5) : CONNECTEDNODEADDRESS 118
Attribute (5) : CONNECTEDNODENAME 119
Attribute (5) : CONNECTEDOBJECT 120
Attribute (5) : CONNECTEDOBJECTNAME 122
Attribute (5) : CONNECTEDOBJECTNUMBER 121
Attribute (5) : CORRUPTIONLOSS 148 <<<<<<<<<<<<<<<<<<<<<<<<<
Attribute (5) : COST 61
Attribute (5) : COUNTERCREATIONTIME 174
Attribute (5) : COUNTERTIMER 59
Attribute (5) : COUNTOFCIRCUITINBOUNDDATAERRORS 1318
Attribute (5) : COUNTOFCIRCUITINITIALIZATIONFAILURES 1316
Attribute (5) : COUNTOFCIRCUITOUTBOUNDDATAERRORS 1317
Attribute (5) : COUNTOFCIRCUITSDOWN 1315
Attribute (5) : COUNTOFFORWARDINGCONGESTIONLOSS 1330
Attribute (5) : COUNTOFLOCALBUFFERERRORS 1319
Attribute (5) : COUNTOFLOCALLYINITIATEDRESETS 1326
Attribute (5) : COUNTOFLOCALREPLYTIMEOUTS 1323
Attribute (5) : COUNTOFLOCALSTATIONERRORS 1321
Attribute (5) : COUNTOFNETWORKINITIATEDRESETS 1328
Attribute (5) : COUNTOFREMOTEBUFFERERRORS 1320
Attribute (5) : COUNTOFREMOTELYINITIATEDRESETS 1327
Attribute (5) : COUNTOFREMOTEREPLYTIMEOUTS 1324
Attribute (5) : COUNTOFREMOTESTATIONERRORS 1322
Attribute (5) : COUNTOFSELECTIONTIMEOUTS 1325
Attribute (5) : COUNTOFTOTALRESETS 1329
Attribute (5) : COUNTOFUSERBUFFERSUNAVAILABLE 1313
Attribute (5) : CURRENTDTE 129
Attribute (5) : DATABLOCKSRECEIVED 153
Attribute (5) : DATABLOCKSSENT 154
Attribute (5) : DATAERRORSINBOUND 155
Attribute (5) : DATAERRORSOUTBOUND 156
Attribute (5) : DEADTHRESHOLD 109
Attribute (5) : DESIGNATEDROUTER 175
Attribute (5) : DESIGNATEDROUTERADDRESS 176
Attribute (5) : DESIGNATEDROUTERNAME 177
Attribute (5) : DIALINGCOST 71
Attribute (5) : DTE 92
Attribute (5) : DURATION 1300
Attribute (5) : DYINGBASE 106
Attribute (5) : DYINGINCREMENT 107
Attribute (5) : DYINGTHRESHOLD 108
Attribute (5) : ERRORPERCENT 1333
Attribute (5) : FAILURETOINITIALIZE 145
Attribute (5) : HANDSHAKEREQUIRED 77
Attribute (5) : HELLOTIMER 66
Attribute (5) : IDLETIMER 74
Attribute (5) : IMPLEMENTATIONDESC 301
Attribute (5) : INACTIVEBASE 103
Attribute (5) : INACTIVEINCREMENT 104
Attribute (5) : INACTIVETHRESHOLD 105
Attribute (5) : INBOUNDBLOCKRATE 1306
Attribute (5) : INBOUNDCONGESTIONLOSSPERCENT 1331
Attribute (5) : INBOUNDOVERHEAD 1310
Attribute (5) : INBOUNDPACKETRATE 1308
Attribute (5) : INBOUNDUTILIZATION 1302
Attribute (5) : INITIALACTIVEBASE 46
Attribute (5) : INITIALACTIVEINCREMENT 47
Attribute (5) : INITIALBABBLETIMER 42
Attribute (5) : INITIALBLOCKING 12
Attribute (5) : INITIALCHANNEL 38
Attribute (5) : INITIALCOST 6
Attribute (5) : INITIALCOUNTERTIMER 4
Attribute (5) : INITIALDEADTHRESHOLD 54
Attribute (5) : INITIALDIALINGCOST 16
Attribute (5) : INITIALDTE 37
Attribute (5) : INITIALDYINGBASE 51
Attribute (5) : INITIALDYINGINCREMENT 52
Attribute (5) : INITIALDYINGTHRESHOLD 53
Attribute (5) : INITIALHANDSHAKEREQUIRED 22
Attribute (5) : INITIALHELLOTIMER 11
Attribute (5) : INITIALIDLETIMER 19
Attribute (5) : INITIALINACTIVEBASE 48
Attribute (5) : INITIALINACTIVEINCREMENT 49
Attribute (5) : INITIALINACTIVETHRESHOLD 50
Attribute (5) : INITIALL1DTEADDRESSES 26
Attribute (5) : INITIALL2DTEADDRESSES 28
Attribute (5) : INITIALLEVEL1ROUTERDTES 25
Attribute (5) : INITIALLEVEL2COST 10
Attribute (5) : INITIALLEVEL2ROUTERDTES 27
Attribute (5) : INITIALLINE 33
Attribute (5) : INITIALLOOPBACKNODE 55
Attribute (5) : INITIALMAXIMUMADJACENCIES 23
Attribute (5) : INITIALMAXIMUMBUFFERS 44
Attribute (5) : INITIALMAXIMUMDATA 39
Attribute (5) : INITIALMAXIMUMRECALLS 17
Attribute (5) : INITIALMAXIMUMROUTERS 7
Attribute (5) : INITIALMAXIMUMTRANSMITS 45
Attribute (5) : INITIALMAXIMUMWINDOW 40
Attribute (5) : INITIALMINIMUMTIMER 20
Attribute (5) : INITIALNAME 2
Attribute (5) : INITIALNETWORK 36
Attribute (5) : INITIALNUMBER 29
Attribute (5) : INITIALORIGINATINGQUEUELIMIT 5
Attribute (5) : INITIALOWNER 32
Attribute (5) : INITIALOWNERCM 31
Attribute (5) : INITIALPOLLINGSTATE 57
Attribute (5) : INITIALPROTOCOL 35
Attribute (5) : INITIALRECALLTIMER 18
Attribute (5) : INITIALRESERVEADJACENCIES 24
Attribute (5) : INITIALRESERVETIMER 21
Attribute (5) : INITIALROUTERPRIORITY 8
Attribute (5) : INITIALROUTINGQUEUETHRESHOLD 9
Attribute (5) : INITIALSERVICE 3
Attribute (5) : INITIALSTATE 56
Attribute (5) : INITIALSUBADDRESSES 13
Attribute (5) : INITIALSUBADDRESSRANGEBEGIN 14
Attribute (5) : INITIALSUBADDRESSRANGEEND 15
Attribute (5) : INITIALTRANSMITTIMER 43
Attribute (5) : INITIALTRIBUTARY 41
Attribute (5) : INITIALUSAGE 34
Attribute (5) : INITIALVERIFICATION 30
Attribute (5) : L1DTEADDRESSES 81
Attribute (5) : L2DTEADDRESSES 83
Attribute (5) : LEVEL1ROUTERDTES 80
Attribute (5) : LEVEL2COST 65
Attribute (5) : LEVEL2ROUTERDTES 82
Attribute (5) : LINE 88
Attribute (5) : LOCALBUFFERERRORS 160
Attribute (5) : LOCALLYINITIATEDRESETS 163
Attribute (5) : LOCALREPLYTIMEOUTS 158
Attribute (5) : LOCATION 300
Attribute (5) : LOOPBACKNODE 110
Attribute (5) : MAILACCOUNT 304
Attribute (5) : MAXIMUMADJACENCIES 78
Attribute (5) : MAXIMUMBUFFERS 99
Attribute (5) : MAXIMUMDATA 94
Attribute (5) : MAXIMUMRECALLS 72
Attribute (5) : MAXIMUMROUTERS 62
Attribute (5) : MAXIMUMTRANSMITS 100
Attribute (5) : MAXIMUMWINDOW 95
Attribute (5) : MINIMUMTIMER 75
Attribute (5) : NAME 1
Attribute (5) : NEGOTIATEDBLOCKING 127
Attribute (5) : NEGOTIATEDHANDSHAKE 128
Attribute (5) : NETWORK 91
Attribute (5) : NETWORKINITIATEDRESETS 165
Attribute (5) : NUMBER 84
Attribute (5) : ORIGINATINGPACKETSSENT 139
Attribute (5) : ORIGINATINGPACKETSSENTPERCENT 1311
Attribute (5) : ORIGINATINGQUEUELIMIT 60
Attribute (5) : OUTBOUNDBLOCKRATE 1305
Attribute (5) : OUTBOUNDCONGESTIONLOSSPERCENT 1332
Attribute (5) : OUTBOUNDOVERHEAD 1309
Attribute (5) : OUTBOUNDPACKETRATE 1307
Attribute (5) : OUTBOUNDUTILIZATION 1301
Attribute (5) : OWNER 87
Attribute (5) : OWNERCM 86
Attribute (5) : PEAKADJACENCIES 147
Attribute (5) : PHONENUMBER 303
Attribute (5) : POLLINGSTATE 113
Attribute (5) : POLLINGSUBSTATE 136
Attribute (5) : PROTOCOL 90
Attribute (5) : RECALLTIMER 73
Attribute (5) : REMARKS 305
Attribute (5) : REMOTEBUFFERERRORS 159
Attribute (5) : REMOTELYINITIATEDRESETS 164
Attribute (5) : REMOTEREPLYTIMEOUTS 157
Attribute (5) : RESERVEADJACENCIES 79
Attribute (5) : RESERVETIMER 76
Attribute (5) : RESPONSIBLEPERSON 302
Attribute (5) : ROUTERPRIORITY 63
Attribute (5) : ROUTINGQUEUETHRESHOLD 64
Attribute (5) : SECONDSSINCELASTZEROED 137
Attribute (5) : SELECTIONINTERVALSELAPSED 161
Attribute (5) : SELECTIONTIMEOUTS 162
Attribute (5) : SERVICE 58
Attribute (5) : SERVICEPHYSICALADDRESS 115
Attribute (5) : SERVICESUBSTATE 116
Attribute (5) : STATE 112
Attribute (5) : STATUSDESIGNATEDROUTER 123
Attribute (5) : STATUSDESIGNATEDROUTERADDR 124
Attribute (5) : STATUSDESIGNATEDROUTERNAME 125
Attribute (5) : SUBADDRESSES 68
Attribute (5) : SUBADDRESSRANGEBEGIN 69
Attribute (5) : SUBADDRESSRANGEEND 70
Attribute (5) : SUBSTATE 114
Attribute (5) : SWITCHEDSTATE 126
Attribute (5) : TERMINATINGCONGESTIONLOSS 140
Attribute (5) : TERMINATINGPACKETSRECEIVED 138
Attribute (5) : TERMINATINGPACKETSRECEIVEDPERCENT 1312
Attribute (5) : TEXTFILE 306
Attribute (5) : TRANSITCONGESTIONLOSS 143
Attribute (5) : TRANSITPACKETSRECEIVED 141
Attribute (5) : TRANSITPACKETSSENT 142
Attribute (5) : TRANSMITTIMER 98
Attribute (5) : TRIBUTARY 96
Attribute (5) : UNRECOGNIZEDFRAMEDESTINATION 167
Attribute (5) : USAGE 89
Attribute (5) : USER 131
Attribute (5) : USERBUFFERUNAVAILABLE 166
Attribute (5) : USERENTITYNAME 133
Attribute (5) : USERENTITYTYPE 132
Attribute (5) : USERNODEADDRESS 135
Attribute (5) : USERNODENAME 134
Attribute (5) : VERIFICATION 85
Directive (6) : CREATE 12
Directive (6) : DELETE 13
Directive (6) : DELETEEXPORTING 118
Directive (6) : DELETERECORDING 111
Directive (6) : DEREGISTER 30
Directive (6) : DIRECTORY 26
Directive (6) : DISABLE 15
Directive (6) : ENABLE 14
Directive (6) : ERASE 33
Directive (6) : EXPORT 113
Directive (6) : GETEVENT 65
Directive (6) : GETVARSELECTOR 124
Directive (6) : INITIALIZE 35
Directive (6) : MODIFYEXPORTING 115
Directive (6) : MODIFYRECORDING 108
Directive (6) : PURGE 38
Directive (6) : RECORD 106
Directive (6) : REGISTER 29
Directive (6) : RESUMEEXPORTING 117
Directive (6) : RESUMERECORDING 110
Directive (6) : SET 2
Directive (6) : SHOW 1
Directive (6) : SHOWEXPORTING 114
Directive (6) : SHOWRECORDING 107
Directive (6) : SUSPENDEXPORTING 116
Directive (6) : SUSPENDRECORDING 109
Directive (6) : TEST 3
Directive (6) : ZERO 4
Event (10) : ABORTEDSERVICEREQUEST 7
Event (10) : AUTOMATICCOUNTERS 8
Event (10) : AUTOMATICSERVICE 3
Event (10) : BLOCKHEADERFORMATERROR 506
Event (10) : CIRCUITDOWN 408
Event (10) : CIRCUITDOWNCIRCUITFAULT 407
Event (10) : CIRCUITDOWNOPERATORINITIATED 409
Event (10) : CIRCUITUP 410
Event (10) : COUNTERSZEROED 9
Event (10) : INITIALIZATIONFAILURECIRCUITFAULT 411
Event (10) : INITIALIZATIONFAILUREOPERATORINITIATED 413
Event (10) : INITIALIZATIONFAILURESOFTWARE 412
Event (10) : LOCALBUFFERTOOSMALL 509
Event (10) : LOCALLYINITIATEDSTATECHANGE 500
Event (10) : NODEOUTOFRANGEPACKETLOSS 402
Event (10) : NODEUNREACHABLEPACKETLOSS 401
Event (10) : OVERSIZEDPACKETLOSS 403
Event (10) : PACKETFORMATERROR 404
Event (10) : PARTIALROUTINGUPDATELOSS 405
Event (10) : PASSIVELOOPBACK 6
Event (10) : PROTOCOLRESTARTRECEIVEDINMAINTENANCEMODE 502
Event (10) : RECEIVEERRORTHRESHOLD 504
Event (10) : RECEIVEFAILED 515
Event (10) : REMOTELYINITIATEDSTATECHANGE 501
Event (10) : SELECTERRORTHRESHOLD 505
Event (10) : SELECTIONADDRESSERROR 507
Event (10) : SENDERRORTHRESHOLD 503
Event (10) : STREAMINGTRIBUTARY 508
Event (10) : VERIFICATIONREJECT 406
Attribute_Partition (11) : CHARACTERISTICS 4
Attribute_Partition (11) : COUNTERS 3
Attribute_Partition (11) : IDENTIFIERS 1
Attribute_Partition (11) : INITIALATTRIBUTES 12
Attribute_Partition (11) : REFERENCES 5
Attribute_Partition (11) : STATISTICS 13
Attribute_Partition (11) : STATUS 2
Event_Partition (13) : CONFIGURATION 15
|
| 2314.14 | | TOOK::GUERTIN | Don't fight fire with flames | Thu Feb 20 1992 07:26 | 46 |
| The attribute is available to MCC, but may not be defined correctly
in the Dictionary. In fact, FCL, and IconicMapPM are both
capable of displaying attributes which are not correctly defined in
the Dictionary.
The data that comes back from examine-like requests (e.g., SHOW
commands) have the datatype in the response, so most PMs do not
validate it with the Dictionary (the performance cost would make that
prohibitive anyway). However, the Exporter is driven off the
Dictionary. Putting the wrong value in the dictionary WILL break the
V1.1 Exporter.
As an example, an application can return a value as an Unsigned8 value,
which is defined in the dictionary as a 16 bit counter. It will be
displayed as a 16 bit counter, no complaints from FCL. But Exporting
will fail. In these cases, from DAP it is possible to simply SET the
DEFINITION DATA_TYPE to be the correct numeric value. We do not want
customers modifing dictionaries because it could result in a corrupted
dictionary. But certainly service organizations should know how to do
this.
Note that I'm not saying that this is the problem you are seeing. I'm
hoping that your problem is this simple. We won't know until Sam has
analysed your FCL dumps.
To go off the subject a little: The biggest difference between MCC
and other "directors" is that MCC is both heavily object-based AND
data-driven. Data-driving improves performance, and allows for generic
applications to be more easily developed. But, on the down side, it
requires that management modules correctly define _exactly_ what
information they are returning. Which is a very difficult and time
consuming task.
-Matt.
P.S. To any toolkit developers listening: In the long term a
Certification_PM would be a nice idea. It would be driven off the
dictionary and closely scrutinize the response to see if it is EXACTLY
the way it is defined in the dictionary. This "PM" would have to be
run on different platforms/configurations/etc., in order to test all
the possible results, but it would "certify" that the MM is responding
correctly, with the correct data. The output would show what
directives were tested, and what attributes/arguments/etc were
verified, and more importantly, which ones were NOT verified. Any
errors detected would generate a FAILED result. The output would
have to be DTM-able (ie, no hex memory dumps).
|
| 2314.15 | perhaps extend the FCL ... | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Thu Feb 20 1992 08:40 | 23 |
| re .-1
> P.S. To any toolkit developers listening: In the long term a
> Certification_PM would be a nice idea. It would be driven off the
> dictionary and closely scrutinize the response to see if it is EXACTLY
> the way it is defined in the dictionary. This "PM" would have to be
> run on different platforms/configurations/etc., in order to test all
> the possible results, but it would "certify" that the MM is responding
> correctly, with the correct data. The output would show what
> directives were tested, and what attributes/arguments/etc were
> verified, and more importantly, which ones were NOT verified. Any
> errors detected would generate a FAILED result. The output would
> have to be DTM-able (ie, no hex memory dumps).
Perhaps add an option to the FCL to do the extended checking (via log
bit [boo] or 'use' command [yea]).
In addition, the FCL could be a bit friendlier when Dictionary problems
(information not found) cause it to print NOENTITY type error messages.
I am NOT suggesting any changes for v1.2
/keith
|
| 2314.16 | Data dictionary problem | TOOK::SHMUYLOVICH | | Thu Feb 20 1992 09:03 | 14 |
| Yes, the problem exists in the data dictionary.
The data type for the following following attributes:
1. "Management Version" (code 72);
2. "NSP Version" (code 89);
3. "Routing Version" (code 108)
is defined in the data dictionary as MCC_K_DT_VERSION (datatype code 9)
but the Show command returns these attributes as MCC_K_DT_UNSIGNED8 (datatype
code 33).
Regards,Sam
|