T.R | Title | User | Personal Name | Date | Lines |
---|
801.1 | RDB Prerequisites not clearly spelled out. | NSSG::R_SPENCE | Nets don't fail me now... | Fri Mar 15 1991 15:42 | 16 |
| I did not find in either the installation manual or the BMS Use manual
any indication that RDB was required in order to start the Export
Background Process.
When I submitted the background process, there was no error indication
in the resulting log file that said that RDB was not installed.
I suggest that the error message surpression in the command file be
moved untill after the environmental checks are complete and a specific
warning message be written to the log file in the event that RDB is not
found on the system.
There are indications that RDB is required to use the suppled reporting
package but not to simply do the exporting.
s/rob
|
801.2 | up to date manual? | TOOK::CALLANDER | | Fri Mar 15 1991 16:36 | 11 |
| Rob,
I have a copy of the final version of the BMS use manual and the exporter
chapter mentions the need for rdb all over the place starting right on
the first page of the chapter.
As for the Installation manual, you are right, the only place I could see
where it explained that RDB was required is on page 1-17, and this is specific
to the reports package.
jill
|
801.3 | Need a more clear statement for the field | NETS::R_SPENCE | Nets don't fail me now... | Fri Mar 15 1991 16:58 | 12 |
| I agree that the text "Rdb/VMS file" is used throughout. However,
unless you KNOW that you need to install some software, you will be
faced with at least a delay while your sales person scrambles to get it
for you and since it is likely the system will need at least another
reboot as a result of parameter changes for the RDB install, additional
hassle is involved as well.
What is missing is an explisit statement that you must install one of
the RDB packages (and if more than run-time, the license too) in order
to use either the EXPORT directive or start the background process.
s/rob
|
801.4 | right | TOOK::CALLANDER | | Fri Mar 15 1991 17:04 | 3 |
| I check the installation appendix on required stuff and it isn't there, that
alone isn't good since the reports section of the manual explicitly calls
it out as required.
|
801.5 | Refer note 643 for no more information. | BONNET::MALAISE | All you need is laugh! | Sat Mar 16 1991 03:57 | 3 |
| Rob , I've allready tried to find an answer of this issue in note 643...
Regards ,
MaRc
|
801.6 | Access to entity on Deregister? | NSSG::R_SPENCE | Nets don't fail me now... | Mon Mar 18 1991 14:16 | 27 |
| When attempting to DEREGISTER a NODE4, apparently the AM tries to
contact the node. Why?
In my case I am trying to remove a node that has moved to another
DECnet area. The automatic update proceedures updated my DECnet
database which is now out of sync with the info in DNS. I would like
to remove the old entry and put back a clean one.
For some reason when I attempt to deregister it I get the following
error;
DECmcc (V1.1.0)
MCC> deregister node4 .host.nets
Node4 CLAUDI_NS:.nssg.host.nets
AT 18-MAR-1991 14:06:17
The requested operation cannot be completed
MCC Unhandled Service Reply = Access control information
invalid at
Node
Even though the actual node can be accessed and there does not appear
to be any node at the old address any longer.
|
801.7 | All directives should be case insensitive | NSSG::R_SPENCE | Nets don't fail me now... | Mon Mar 18 1991 17:36 | 14 |
| When specifying a SHOW EXPORT directive, the entity spec must be
identical in case to the way it was registered. This is a pain if you
don't remember how it was done. This only seems to be an issue for the
Historian and Exporter. It should be case insensitive consitantly
accross management modules.
I got burned by an entity of the form ; :.LKG.host.took
where I forgot that I had specified the location as upper case.
In the Iconic Map It seems that even though you may have registered the
entity with some mixed case, when you select it, and then do a
directory, the management window shows the entity in all lower case.
s/rob
|
801.8 | DIRECTORY behaviour in Iconic Map | NSSG::R_SPENCE | Nets don't fail me now... | Mon Mar 18 1991 17:41 | 6 |
| When I pull down the OPERATIONS menue and specify DIRECTORY, the
management window comes up static. That is, it doesn't actually DO
the directory but waits for you to push the button. This is not the
same behaviour as you get with a SHOW.
s/rob
|
801.9 | SHOW EXPORTING bug | NSSG::R_SPENCE | Nets don't fail me now... | Tue Mar 19 1991 15:00 | 9 |
| When requesting SHOW EXPORTING from the iconic map, and leaving the
export target blank, the value of the logical name MCC_EXP_RDB_FILE ,
described in the manual on page 4-12, is not used. Instead, it appears
to use the SYS$LOGIN:MCC_EXPORT.RDB (or perhaps something else?).
Also, it is not clear what the little red button is for next to the
export target line. The manual does not describe it's use.
s/rob
|
801.10 | Cut and Paste doesn't always work. | NSSG::R_SPENCE | Nets don't fail me now... | Tue Mar 19 1991 16:27 | 5 |
| Is ther some reason why I can't select text from management windows
with the mouse and copy it? It only seems to work for "set" windows but
would seem to be usefull for "show" or "directory" windows too.
s/rob
|
801.11 | Directory behavior is like other Action Directives | VERNA::V_GILBERT | | Tue Mar 19 1991 18:05 | 10 |
| Re .8
For all action directives, whether there are arguments or not, the user must
press the start operation before the operation commences. See Zero, Enable,
Test,...
If this is not a desired behavior, it can be changed but it is working as
designed and coded.
Verna
|
801.12 | How come? | NSSG::R_SPENCE | Nets don't fail me now... | Wed Mar 20 1991 10:57 | 14 |
| Two points;
First, for a SHOW operation the user does not have to push a button to
start the operation. I think that is the desired behaviour.
Second, what benefit to the customer did you (meaning engineering, not
you specificly Verna) have in mind when it was designed to require an
additional (but apparently unneeded to my mind) action on the user's
part? The info would be helpful in the event of explaining this
behaviour as a feature to a customer.
Thanks
s/rob
|
801.13 | Here's a little of how come | VERNA::V_GILBERT | | Wed Mar 20 1991 11:44 | 16 |
| Rob,
It is hard to remember exactly why the decision was made BUT part of it was
to ensure that once a entity and action directive are selected, the user can
double check that their selections were correct (ie selected Enable not Disable).
For example, if the user fat-fingered and selected Zero Node4 and it was done
automatically, the results would not be too good. Action directives can do
some damage. This way the user must start the operation - another chance to
cancel out if desired.
Any non-action examine directive (could be others besides Show) starts
automatically, but this does no damage if the selection was incorrect.
Hope this helps a bit
Verna
|
801.14 | Ok, but what about DIRECTORY? | NSSG::R_SPENCE | Nets don't fail me now... | Wed Mar 20 1991 11:48 | 8 |
| For the examples you mentioned, it sure makes sense to get a
confirmation. However, why would DIRECTORY need confirmation? It
doesn't require any arguments in the management window so I would
expect it behave like a SHOW.
Thanks for the explanation.
s/rob
|
801.15 | Case restrictions must be fixed! | NSSG::R_SPENCE | Nets don't fail me now... | Wed Mar 20 1991 12:09 | 18 |
| to expand on .7;
The new requirement as spelled out in the release notes, to not allow
mixed case in NODE4 Synonyms and also to require exact case matching
when requesting only Historian and Exporter functions is a problem.
For the NODE4 synonyms, this restriction places an unreasonable burden
on people who may have populated all or parts of their phase 4 systems
into DNS with the V1.0 product.
As to having to specify exact case for only a subset of permitted
directives is inconsitant and contrary to the message for our customers
that we have an integrated solution.
I believe that these MUST be corrected for the V1.1 product. These
restrictions are too important to let pass.
s/rob
|
801.16 | Export anomaly | NSSG::R_SPENCE | Nets don't fail me now... | Wed Mar 20 1991 13:22 | 45 |
| I am trying out the reports package and wanted to get a report on
the data I had been exporting (thanks to Sam !) so in order to answer
the questions on what date and time to start and finish I used DECmcc
to SHOW EXPORTING to look up the valid times for my data.
However, what I saw surprised me. It showed me that it has not
apparently run the most recent poll even though it claims to be active.
Here is what got displayed;
MCC> show exp node4 nssg line una-0 exp
targ=user$nets:[r_spence.mcc_recording]test_exp.rdb
Node4 nssg Line una-0
AT 20-MAR-1991 13:13:10
Exporting parameters are:
Exporting state = ACTIVE,
State since = 19-MAR-1991 11:44:04.76,
Export period = 0 01:00:00.00,
Begin time = 19-MAR-1991 11:43:42.71,
End time = 25-MAY-2012 00:00:00.00,
Export target =
"USER$NETS:[R_SPENCE.MCC_RECORDING]TEST_EXP.RDB",
Request time = 19-MAR-1991 11:43:42.71,
Requested by = "R_SPENCE",
Time of last successful poll = "20-MAR-1991 11:44:29.35",
Number of successful polls = 25,
Time of last failed poll = "NONE",
Last poll failure reason = "N/A",
Number of failed polls = 0,
Last export time = "20-MAR-1991 11:44:29.35",
Time of last export failure = "NONE",
Last export failure reason = "N/A",
Number of export failures = 0,
Sequence name = "EXPORT",
Initial sequence number = 0,
Current sequence number = 25
MCC>
Note that the time I looked is 13:13:10 and the export period is set
to 1 hour but the last export was at 11:44:29.
What happened to the 12:44 export?
s/rob
|
801.17 | more info on immeidate execution | TOOK::CALLANDER | | Wed Mar 20 1991 15:52 | 32 |
| RE a few of them...
On the management windows taking immediate action instead of requiring the
user to puch a button; I would like to try to restate the problem based upon
the examples that you have give.
What you would like to see is:
If the user selected, from the operations menu, a directive that
is non-destructive, like a DIRECTORY command, and there are no
arguments required...then the action should be taken without the
user having to enter any additional mouse/keyboard commands.
The reason I reworded this, and Rob correct me if this isn't what you were
talking about, is that immediate action on destructive commands like DELETE
will tend to upset the "fat fingered" managers and the users of the net they
manage (especially if you took *THEIR* node off the next work by mistake).
The problem with the current im plementation is that the DIRECTIVE-TYPE field
in the MSL tells us what "type" of directive we have only in terms of what
type of information does it work on (attribute, events, arguments). These
types are defined in the SRM as EVENT, EXAMINE, MODIFY, and ACTION directives.
What we would need would be another field that would tell us if an ACTION
directive is destructive or not. With the other types we know that MODIFY is
destructive (that is the nature of the directive-types definition) and that
the EXAMINE and EVENT are non-destructive (that is the nature of their
definition). If we had this information we could probably have the PMs
expand their implementation (no committments, just passing around ideas
here) to check this field and decide if immediate -- no uadditional user
action required -- can be taken.
jill
|
801.18 | MCC_EXP_RDB_FILE logical problem | NSSG::R_SPENCE | Nets don't fail me now... | Wed Mar 20 1991 16:04 | 7 |
| More on .9, SHOW EXPORT
It turns out that the MCC_EXP_RDB_FILE logical MUST be a Process
Logical for this to work. I had it as a /SYSTEM/EXEC logical and
it didn't work. This seems like a bug.
s/rob
|
801.19 | Thanks Jill. | NSSG::R_SPENCE | Nets don't fail me now... | Wed Mar 20 1991 16:21 | 10 |
| re .-2; Jill's comments.
Yes, Jill, the restatement of my request is correct. From a user view,
the fact that SHOW operates immediately and DIRECTORY requires an
additional action seems inconsistant. Now that you explained the
internals I understand why it works the way it does, not that that
changes my view of how I expect it to work.
Thanks.
|
801.20 | proc logical | TOOK::CALLANDER | | Thu Mar 21 1991 11:43 | 1 |
| Glad to hear that the process logical worked!
|
801.21 | Graph reports don't work. | NSSG::R_SPENCE | Nets don't fail me now... | Thu Mar 21 1991 13:16 | 33 |
| I have not been able to get either of the CIRCUIT Graphs from the
reports package to work. All required software is installed per
instructions. I can get the NODE and LINE reports to work ok.
I get the following error from DECgraph broadcast to all my terminals
Job MCC_RPTS_NODE4_CIRCT_DAILY_GRAPH_DTR (queue SYS$BATCH, entry 186)
terminated with error status
%SYSTEM-F-FILNOTACC, file not accessed on channel
The batch log error looks like
$ datatrieve
VAX DATATRIEVE V5.1
Digital Query and Report System
Type HELP for help
:node4_circt_hourly_graph
exit
$ graph/load/nointeracive/monochrome= CIRCUIT_id00000103211133
CIRCUIT_id0000010
3211133 mcc_reports_files:mcc_rpts_lgraph
%SYSTEM-FILNOTACC, file not accessed on channel
R_SPENCE job terminated at 21-MAR-1991 11:35:32.06
Both graph reports fail in the same way.
s/rob
|
801.22 | Sorry about Directory.... | TOOK::CAREY | | Thu Mar 21 1991 15:29 | 46 |
|
Re: .6
Deregister looks for the node on the network?
Yup, it does. We overgeneralized some of our validation and we
check the node4 on deregister to make sure that it isn't a cluster
alias. Pretty silly, considering you're most likely to Deregister
something after it has been put in a dumpster. This has been QAR'd,
and we'll fix it for V1.2. Sorry about that.
Re: .8 (and others)
Directory. First time I did a Directory of a node4 from the iconic map
I stared at it for a few minutes before I noticed it wanted me to do
something. Since I do all of this from a VS2000 I figured all I had to
do was be patient and it took awhile to notice that it wanted me to
toggle the old "Start Operation" button.
In general, the split behavior between Action and Examine directives
makes sense, but certainly not in this case. I think we should either
special-case the Directory directive, or make it into an Examine
directive (although I think there was a reason we couldn't do that).
Anyway, I wicked agree that that behavior was most unappreciated.
We may want to generalize to "non-desctructive action directives" but
that is a much more complicated discussion.
Let's just fix Directory, don't you think it would be swell?
Re: .15
Node4 synonyms all exact casing? Personal commentary: "Yucky."
FWIW: In the DNA4 AM, we have to up case all that stuff in order to get
it into and out of the DECnet databases. DECnet Phase 4 isn't a
case-sensitive environment. In fact, it sometimes gets upset if you
try to remove lowercase stuff from one of the databases.
I'm sure we got stuck in a bad place on this one, but it sure would be
nice if we could fix it in the future. DECnet Phase 4 is not case
sensitive, it is too bad to make it so in a tool.
-Jim Carey
|
801.23 | about DIRECTORY... | POLE::LEMMON | | Sun Mar 24 1991 14:14 | 25 |
| re: .14 .17 .19 .22
To put it simply, the DIRECTORY directive is screwed up! From the
users point of view it should behave as an EXAMINE directive. This is
where the problem is. An EXAMINE directive works only on attributes.
The DIRECTORY directive does not. If it did, you would see the
following in the pulldown menu:
Directory -> char
counters
status
etc.
Believe it or not it is actually defined in the MS as an
EXAMINE directive! I had to hardcode the directive type to
ACTION because internally it processed as an Action directive.
It was easier to hardcode the Iconic Map than to have everyone
change their MS files. It is supposed to be changed to an
action directive in the v1.2 product.
I will look into what we can do to automatically execute it
so it behaves like the SHOW directive.
/Jim
|
801.24 | EXP Background ^C handleing | NSSG::R_SPENCE | Nets don't fail me now... | Mon Mar 25 1991 15:47 | 11 |
| I have been playing with the EXPORTER background program and have
discovered a problem with it's handeling of ^C. I have been testing it
by running it interactivly. It appears to handle ^C the same as expected
for ^Y. That is, it doesn't run down the image and close things up
cleanly. In fact, it appears that a CONTINUE works after ^C.
If you do a ^C after the EXPORTER has been running for a while, then,
the next image you try and run generates a
%MCC-ALERT_TERMREQ, thread termination requested
message.
|
801.25 | You can't keep help on the screen to use it! | NSSG::R_SPENCE | Nets don't fail me now... | Tue Apr 02 1991 18:40 | 10 |
| When using help from the FCL in line mode and you have succesfully
found the help you needed and then hit return several times to get an
MCC> prompt, the screen is erased so the help information you just
found is lost. WHY?
I reported this as a problem in the V1.0 EFT and it ain't fixed yet.
Please fix for sure in next release!
s/rob
|
801.26 | it is still on the list | TOOK::CALLANDER | | Wed Apr 03 1991 08:56 | 11 |
| Rob,
This item is still qared. Unluckily fixing it is not as easy as
it sounds. In figuring out what to do there we two requirements
we were given. Make long help page between each screenful and
don't clear screen at the end of help. We have found that fixin
both was more work then we felt we had time for. This is still
on the todo list though.
jill
|
801.27 | | NSSG::R_SPENCE | Nets don't fail me now... | Wed Apr 03 1991 12:00 | 13 |
| Thanks Jill. In general, clearing the screen when there is no specific
need to clear it is a bad idea. Another place where it is very
frustrating is when you exit the menue for the reports routines.
In FORMS mode, screen stuff makes sense. In LINE mode, SCREEN stuff
like clearing it, doesn't make sense.
Using help in line mode is tough enough given the upside down way one
has to look things up (yes, I understand why it is that way) but it is
simply maddening to have it erased just when you want to copy the
example as a directive.
s/rob
|
801.28 | Create Domain Inconsistancy in IMPM | NSSG::R_SPENCE | Nets don't fail me now... | Wed Apr 03 1991 18:21 | 26 |
| There are two ways (that I have found) to create a domain from the
iconic map. The first is to OPEN it from the FILE menuebar. The second
is to attempt to place it from the toolbox on to a domain map.
If I create it by attempting to open it from the FILE pulldown OPEN
DOMAIN, I get a very nice (thank you) pop up that says it doesn't exist
and would I like to create it. If I push YES, I get another pop up
that has the domain name, the Owner ID and Directory fields filled in
with what look like reasonable defaults. I like this.
If I create it by attempting to add it as a domain in another domain
from the TOOLBOX I get a LARGE pop up that has the same fields as
previous, DOmain name, Owner ID and DIrectory, but the Owner ID and
Directory fields are blank, no defaults are filled in. This is
inconsistant and anoying. The popups above (in previous methode) are a
much better interface and should be replicated here too.
Also, the initial popup that says "the domain doesn't exist, would you
like to create it" is much more clear than the message in the second
example, "Entity Domain .mydomain is not created. Please fill in
the form below." ^ ^
Besides the ^ funny spacing ^ , the message wording seems like
an attempt to create the domain has failed.
s/rob
|
801.29 | re:28 | BARREL::LEMMON | | Thu Apr 04 1991 10:59 | 22 |
| The difference is because when you open a domain, the code knows about
the domain fm, builds the form specifically for it's create arguments.
(this is true for New Domain also)
When you add it from the toolbox, a generic routine is called that knows
nothing about the domain global entity. It just grabs the create args
for the entity selected and displays them in the form.
Now I know the user doesn't care about these implementation details. S/he
just wants a consistent user interface.
I will check on what can be done to fill in the values for these fields but
can't guarantee it will be done in v1.2.
A future version of DECmcc should allow the MM developer to enroll a
user action routine for each request argument. This routine should
be called to load the field with a specific default and perform a semantic
field validation, in addition to the syntactic check the iconic map does.
Maybe in v2.0?
/Jim
|
801.30 | re:.9 | BARREL::LEMMON | | Thu Apr 04 1991 13:05 | 7 |
| > Also, it is not clear what the little red button is for next to the
> export target line. The manual does not describe it's use.
The red button lets the user decide whether or not to send the argument
across the call interface.
/Jim
|
801.31 | Error on DECmcc Exit-start | NSSG::R_SPENCE | Nets don't fail me now... | Thu Apr 04 1991 17:00 | 92 |
| I started DECmcc from a DECterm and just now I asked DECmcc to QUIT
from the FILE Pulldown and while it was shutting down I went to the
DECterm window and typed an uparrow and return. I just needed to exit
and restart to see if the saved settings I just changed look right to
me after they are loaded. I got the following error that may be of
interest.
$ manage/ent/inter=decw
$ manage/ent/inter=decw
X Toolkit Warning: BadImplementation - server reported implementation
error
XIO: fatal IO error 65535 on X server "NETS::0.0"
after 154 requests (149 known processed) with 0 events remaining.
%XLIB-IOERROR, xlib io error
-DECW-CNXABORT, connection aborted
I typed a ^C after a few minutes where no cpu time was accumulating
and tried it again.
%MCC-CANCEL, cancel
$
Got the error again and this time when I typed ^C I got a major dump
31> manage/ent/inter=decw
X Toolkit Warning: BadImplementation - server reported implementation
error
> %MCC-CANCEL, cancel
XIO: fatal IO error 65535 on X server "NETS::0.0"
after 428 requests (341 known processed) with 0 events remaining.
%XLIB-IOERROR, xlib io error
-DECW-CNXABORT, connection aborted
%SYSTEM-ACCVIO, access violation, reason mask=04, virtual
address=00000000, PC=0
02F67F3, PSL=03C00005
%MCC-LOG_EVENT, logging event type 00000400 reported by thread (name =
Main_Thre
ad, id = 00010000) at 4-APR-1991 15:51:08.54
-MCC-RTN_ENTRY, routine (MCC_ONCE) called at PC = 000FD541
%MCC-LOG_EVENT, logging event type 00000400 reported by thread (name =
Main_Thre
ad, id = 00010000) at 4-APR-1991 15:51:08.58
-MCC-RTN_RETURN, routine (MCC_ONCE) returns with the following status:
-MCC-NORMAL, normal successful completion
The MCC_MAIN image is now using about 28%-35% of my system and
pagefaulting like crazy (and has been for 5 minutes now. I am going to
type a ^Y to see if I can stop it.
Well, I typed ^Y and it has gone into a loop (it seems). Here is some
of the output.
%MCC-LOG_EVENT, logging event type 00000200 reported by thread (name =
Main_Thre
ad, id = 00010000) at 4-APR-1991 15:56:11.89
-MCC-RTN_ENTRY, routine (VMSLOCK_RELEASE) called at PC = 000FE6A2
%MCC-LOG_EVENT, logging event type 00000200 reported by thread (name =
Main_Thre
ad, id = 00010000) at 4-APR-1991 15:56:11.92
-MCC-VMSLOCK_RELEASE, resource=....MCC_EVT_MEMORY ,
VMSLck=0E2400A8,
RefCnt=1, CurMode=5, GrantMode=0, QMode=0, Is_Blk=0
%MCC-LOG_EVENT, logging event type 00000200 reported by thread (name =
Main_Thre
ad, id = 00010000) at 4-APR-1991 15:56:11.95
-MCC-RTN_RETURN, routine (VMSLOCK_RELEASE) returns with the following
status:
-MCC-NORMAL, normal successful completion
%MCC-LOG_EVENT, logging event type 00000200 reported by thread (name =
Main_Thre
ad, id = 00010000) at 4-APR-1991 15:56:12.05
-MCC-RTN_RETURN, routine (MCC_LOCK_RELEASE) returns with the following
status:
-MCC-NORMAL, normal successful completion
%MCC-LOG_EVENT, logging event type 00000040 reported by thread (name =
Main_Thre
ad, id = 00010000) at 4-APR-1991 15:56:12.25
-MCC-RTN_ENTRY, routine (MCC_CONTEXT_GET) called at PC = 000EB759
%MCC-LOG_EVENT, logging event type 00000040 reported by thread (name =
Main_Thre
ad, id = 00010000) at 4-APR-1991 15:56:12.54
-MCC-RTN_RETURN, routine (MCC_CONTEXT_GET) returns with the following
status:
-MCC-NORMAL, normal successful completion
%MCC-LOG_EVENT, logging event type 00000200 reported by thread (name =
Main_Thre
ad, id = 00010000) at 4-APR-1991 15:56:12.59
I don't know how at this time I am going to stop it. Stop process I
guess.
s/rob
|
801.32 | Update to .-1 | NSSG::R_SPENCE | Nets don't fail me now... | Fri Apr 05 1991 11:03 | 8 |
| An update... It appears that somehow the DECwindows Server musta run
out of some resource. We tried new processes for DECmcc to no avail.
The server process was screwed up so bad we had to reboot cause the
server restart wouldn't work.
After the reboot things worked again.
s/rob
|
801.33 | re: .8 | BARREL::LEMMON | | Fri Apr 05 1991 17:36 | 4 |
| I modified the code so that when you do a DIRECTORY the operation
is started automatically. This will be in the V1.2 kit.
/Jim
|
801.34 | Inconsistant window lables | NSSG::R_SPENCE | Nets don't fail me now... | Mon Apr 22 1991 17:08 | 31 |
| There is an inconsistancy in the lable that DECmcc places in the window
for a domain and therefore what the icon in the icon box is labled.
For example I have 3 domains. Lets call them test1, test2 and test3.
The top level is test1. It contains test2. Test2 contains test3.
Ok, I open test1 and get a window with an icon labled
"DECmcc Domain test1"
I double click on the test2 icon and the after we go down a level, the
icon lable changes to
"test2"
I then double click on the test3 icon and we get a lable of
"test3"
Then, using MB2 to "go up", we get
"DECmcc Domain test2"
If one only clicks on domains and goes up and down the tree, going
down makes the lable only be the domain name while going up prepends
the DECmcc Domain text.
If one double clicks on a node4 however, then the DECmcc Domain text is
included for example for a node4 george in domain test3 we get
"DECmcc Domain test3 Node4 .DNA_Node.george"
Personally I suggest that the "DECmcc Domain" text be dropped in all
cases.
s/rob
|
801.35 | QAR for one of the reports files | NSSG::R_SPENCE | Nets don't fail me now... | Mon Apr 29 1991 17:51 | 10 |
| In the MCC_RPTS_NODE4_CIRCT_DAILY_GRAPH_DTR.COM file, the file's name
is documented to be
MCC_RPTS_NODE4_CIRCUIT_DAILY_GRAPH_DTR.COM
Took a while to find it when troubleshooting a reports problem.
Please QAR it.
Thanks
s/rob
|
801.36 | Can't remove 2nd DISPLAY ALARMS window. | NSSG::R_SPENCE | Nets don't fail me now... | Tue May 21 1991 14:35 | 18 |
| I think I found a problem with DISPLAY ALARMS in the IMPM.
I generated an alarm, then pulled down DISPLAY ALARMS and got the
expected window. I then forgot about it and looked at other things
which put the DISPLAY ALARMS window behind so I REALLY forgot about it.
I then CLEARED all Alarms and then I caused another alarm.
After that alarm went off, I DISPLAYed ALARMS again.
The problem is that now that I have two DISPLAY ALARMS windows up, I
can't get rid of both of them. Pushing OK on either window will cause
the newest one to go away but nothing other than exitting MCC will
trar down the other one.
This was repeatable.
s/rob
|
801.37 | | TOOK::F_MESSINGER | | Tue May 21 1991 15:51 | 5 |
|
Rob,
Do you have access to the QAR system?
Fred
|
801.38 | check system status | TOOK::CALLANDER | | Tue May 21 1991 16:17 | 10 |
| Rob,
I am putting this here to update people on our hallway conversation.
Since this isn't the only wierd problem you are seeing, there maybe
somthing more at work here. Your mcc has been up and running, doing
alot from what you told me, for a long time. Check to make sure that
the strange problems you are seeing aren't due to memory limits being
hit or any such thing, and get back to us with the results.
jill
|
801.39 | Here's what it looks like | NSSG::R_SPENCE | Nets don't fail me now... | Wed May 22 1991 15:12 | 76 |
| Well, I looked at the system and I don't see anything that jumps out at
me as an obvious problem. Maybe I missed it so the next page has the
output from SHOW MEMORY.
If you see something that I should fix, please let me know.
$ show mem/pool/full
System Memory Resources on 22-MAY-1991 14:05:19.64
Small Packet (SRP) Lookaside List Packets Bytes Pages
Current Total Size 1066 102336 200
Initial Size (SRPCOUNT) 1024 98304 192
Maximum Size (SRPCOUNTV) 3072 294912 576
Free Space 50 4800
Space in Use 1016 97536
Packet Size/Upper Bound (SRPSIZE) 96
Lower Bound on Allocation 32
I/O Request Packet (IRP) Lookaside List Packets Bytes Pages
Current Total Size 651 114576 224
Initial Size (IRPCOUNT) 441 77616 152
Maximum Size (IRPCOUNTV) 1323 232848 455
Free Space 42 7392
Space in Use 609 107184
Packet Size/Upper Bound (fixed) 176
Lower Bound on Allocation 97
Large Packet (LRP) Lookaside List Packets Bytes Pages
Current Total Size 32 52736 103
Initial Size (LRPCOUNT) 20 32960 65
Maximum Size (LRPCOUNTV) 80 131840 258
Free Space 17 28016
Space in Use 15 24720
Packet Size/Upper Bound (LRPSIZE + 80) 1648
Lower Bound on Allocation 1088
Nonpaged Dynamic Memory
Current Size (bytes) 999936 Current Total Size (pages) 1953
Initial Size (NPAGEDYN) 999936 Initial Size (pages) 1953
Maximum Size (NPAGEVIR) 1999872 Maximum Size (pages) 3906
Free Space (bytes) 263760 Space in Use (bytes) 736176
Size of Largest Block 217440 Size of Smallest Block 16
Number of Free Blocks 124 Free Blocks LEQU 32 Bytes 31
Paged Dynamic Memory
Current Size (PAGEDYN) 1000448 Current Total Size (pages) 1954
Free Space (bytes) 704304 Space in Use (bytes) 296144
Size of Largest Block 701808 Size of Smallest Block 16
Number of Free Blocks 82 Free Blocks LEQU 32 Bytes 76
$ show mem
System Memory Resources on 22-MAY-1991 14:10:16.50
Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (24.00Mb) 49152 491 47951 710
Slot Usage (slots): Total Free Resident Swapped
Process Entry Slots 60 15 45 0
Balance Set Slots 45 2 43 0
Fixed-Size Pool Areas (packets): Total Free In Use Size
Small Packet (SRP) List 1066 44 1022 96
I/O Request Packet (IRP) List 651 38 613 176
Large Packet (LRP) List 32 17 15 1648
Dynamic Memory Usage (bytes): Total Free In Use Largest
Nonpaged Dynamic Memory 999936 262416 737520 217440
Paged Dynamic Memory 1000448 703824 296624 701424
Paging File Usage (pages): Free Reservable Total
DISK$SYS_NETS:[SYS0.SYSEXE]PAGEFILE.SYS 31646 6868 50000
USER$NETS:[SYS0.SYSEXE]PAGEFILE.SYS;3 71079 12661 99992
Of the physical pages in use, 6531 pages are permanently allocated to VMS.
|
801.40 | I don't know | TOOK::CALLANDER | | Wed May 22 1991 16:08 | 6 |
| the sizes all lot reasonable. but maybe it is a virtual memory problem?
How many domains did you have open (including children domains if they
are dynamic under the root where you opened the map),and did you have
notification enabled? also give an average size for the domain memberships.
jill
|
801.41 | Here is the picture... | NSSG::R_SPENCE | Nets don't fail me now... | Wed May 22 1991 16:33 | 27 |
| Ok. The picture looks like this;
LKG
^
lkg1-1 lkg1-2 ... lkg2-a lkg2-1 ... 10 domains, one static
^ ^
^ lkg2-1-c1 lkg2-1-c2 .... 8 domains
^ ^
^ (5 domains, 2 node4, 1 snmp, 1 node)
15 dynamic domains, 1 bridge, and 27 node4s
Notification is enabled. The alarm rule was against one of the node4
entities in the lkg2-1-c2 domain.
Exporting is also going on (and has been for over a month) against
two node4 entities, one line and one circuit on each, every 1 hour
from the lkg2-a domain.
There are only ever 10 or so alarm rules active at any one time.
System is VMS V5.3-2 with 24mb and 100k free blocks on each disk.
Normally I have opened the top level, clicked down to lkg2-a, up again
and down to lkg2-1-c2. All the other upper domains are empty (or mostly
so).
s/rob
|
801.42 | numer of threads... | TOOK::CALLANDER | | Wed May 22 1991 16:48 | 16 |
| If I read your hierarchy tree correctly you are saying it consists
of 39 domains (dynamics only). For each domain the iconic map will
keep a listing (in memory) of the entity information, and a thread
will be generated to do notification on each of these. I believe
our thread stack size on the NOTIFY commands are currently set at 80
pages each. Could you try coming into your hierarchy lower down (some
where, where you have 10 or less domains within the hierarchy), and see
if you still get the strange results. I am wondering if you are hitting
virtual memory limits and if the "strange" behavior is due to the
pms/fms attempting to recover.
just guessing, can you tell. Also you listed a local and cluster page
file, is the 50K the one you are using, and what are the limits
on your account, and do you have any other process logged in (say running
alarms in another job)?
|
801.43 | lack of memory??? | JETSAM::WOODCOCK | | Wed May 22 1991 17:00 | 13 |
| Rob,
Not sure if this is your problem but it is note worthy anyway for those
concerned about MCC performance. I have been often asked lately what I
can manage with my station and my reply is "I'M OUT OF MEMORY (32.0M)
AND I'M ONLY HALFWAY TO PRODUCTION". Rob you also appear out of physical
memory (491 free from 49152 available) and this at the very least will
cause performance degradation. Who knows, it could be causing other
problems. I saw various things happen when I got to this point so it may
be having an effect on your MCC.
something to look into,
brad...
|
801.44 | Still there... | NSSG::R_SPENCE | Nets don't fail me now... | Wed May 22 1991 17:48 | 25 |
| I tried a new instance of MCC and opened the lower level domain
directly (lkg2-1-c2) and the problems with notify for event alarms and
the stuck window problem still exist.
re .-1
I know I am getting tight on physical memory but the pagefault rate on
the system isn't bad and after all, it COULD swap something if it needs
the memory. I agree that we are going to need some realistic system
sizing numbers soon. The minimums are not useful for anything with more
than a few dozen entities.
Jill, here are the stats for my process. I think I followed the
guidelines. BTW, thanks for helping (thanks to all the folks upstairs
who are so helpful).
Maxjobs: 0 Fillm: 100 Bytlm: 40000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 36 JTquota: 4096
Prclm: 2 DIOlm: 18 WSdef: 512
Prio: 4 ASTlm: 48 WSquo: 2048
Queprio: 0 TQElm: 128 WSextent: 20000
CPU: (none) Enqlm: 2048 Pgflquo: 40000
s/rob
|
801.45 | PAGFILQUO is too low | TOOK::GUERTIN | I do this for a living -- really | Thu May 23 1991 10:13 | 16 |
| RE:.44
Rob,
Your PageFileQuota is only 40,000 -- This means that's all the
virtual memory you are going to get. You should definitely bump this
up since you are using the Iconic Map so much -- make it as big as you
can get away with. Also check the SYSGEN parameter VIRTUALPAGECNT (or
something close to that), it should be slightly less than your page file
size (size of PAGEFILE.SYS). Remember that the PageFileQuota MUST be
less than the VIRTUALPAGECNT. While you are at it, I would bump up the
ASTLM to 100.
-Matt.
(Actually, I'm starting to think that quotas/resources are not your
problem, but it couldn't hurt to tune your system for running MCC a
little better.)
|
801.46 | Will up pagefilequo and astlm | NSSG::R_SPENCE | Nets don't fail me now... | Thu May 23 1991 12:56 | 7 |
| Thanks Matt. I will make the mods for my account and try it.
BTW, the Virtualpagecnt is 100,000 (and pagefile is 120,000) so that
seems ok.
s/rob
|
801.47 | Some exporter questions | NSSG::R_SPENCE | Nets don't fail me now... | Wed May 29 1991 15:49 | 52 |
| Some exporter questions/problems...
I have had a set of export directives executing once per hour for
over a month. I have been recording info about the export activity
with pencil and paper about twice a day during this experiment.
Over this past weekend my system, like most other systems around here,
went down for some unknown length of time. When I checked the export
info this morning I saw that the sequence number was now at 741 (it is
now at 746) but as of noon last thursday it was at 706. This would
indicate that lots of polling periods were missed (since there should
have been 144 polls taken during that time, not 40) however, the
output from a SHOW EXPORT doesn't support this conclusion.
Also, the output claims NONE as the time of the last export failure but
has a time for the date of the last failed poll. How can it have a
succesfull export with a failed poll?
The reason for the last failed poll was
Last poll failure reason = "failed to call ETP",
What does this mean?
Here is the output:
MCC> show export node4 islan1
Node4 islan1
AT 29-MAY-1991 14:28:29
Exporting parameters are:
Exporting state = ACTIVE,
State since = 11-APR-1991 18:40:00.22,
Export period = 0 01:00:00.00,
Begin time = 11-APR-1991 19:00:00.00,
End time = 25-MAY-2012 00:00:00.00,
Export target = "USER$NETS:[R_SPENCE.DATA]EXPORT.RDB",
Request time = 11-APR-1991 18:39:56.38,
Requested by = "R_SPENCE",
Time of last successful poll = "29-MAY-1991 13:04:47.33",
Number of successful polls = 731,
Time of last failed poll = "28-MAY-1991 09:04:47.29",
Last poll failure reason = "failed to call ETP",
Number of failed polls = 15,
Last export time = "29-MAY-1991 13:04:47.33",
Time of last export failure = "NONE",
Last export failure reason = "N/A",
Number of export failures = 0,
Sequence name = "bb",
Initial sequence number = 0,
Current sequence number = 746
s/rob
|
801.48 | Problem with SHOW EXPORT | NSSG::R_SPENCE | Nets don't fail me now... | Wed May 29 1991 15:58 | 26 |
| I have this problem with exporting. I tried this morning to start up
some additional exporter background processes which each have their own
RDB databases. This seemed to work fine and the new processes and
sub-processes exist and use compute time every so often, and they have
created the expected 2 files for RDB and the 5 files for MCC.
I then started some exporting with the following command;
MCC> export node4 CLAUDI_NS:.NSSG.host.nssg Export period = 0:05:00, -
MCC>_ Export target = user$nets:[r_spence.data]export_node4.rdb
and got the expected Exporting Started message.
I then tried to check it out with;
MCC> show export NODE4 CLAUDI_NS:.NSSG.host.nssg
Node4 CLAUDI_NS:.NSSG.host.nssg
AT 29-MAY-1991 14:22:19
No exporting for the specified entity
MCC>
I am puzzled as to what I did wrong.
s/rob
|
801.49 | will check out | TOOK::HAO | | Mon Jun 03 1991 12:07 | 16 |
| Rob,
Sorry about the late reply. I've been away on vacation for 2 weeks.
Regarding the Display Alarm window not going away, have you gotten an
answer on that? I'll look into it sometime this week.
Normally, when a Display Alarms window is already displayed, the
Operation/DisplayAlarm menu item is dimmed out. It only becomes active
again when the display box goes away. It could be that you stumbled
on a case where the menu item became active again before the display
box went away, in which case, any box except for the last one cannot
be cancelled.
Christine
|
801.50 | Where is relational operators list in HELP? | NSSG::R_SPENCE | Nets don't fail me now... | Tue Jun 25 1991 12:14 | 11 |
| Well, after 30 minutes of looking, I give up.
Where in HELP is the list of valid relational operators that can be
used for Alarms Rules?
BTW, having subtopics in HELP that have exactly only one sub-subtopic
under them is really frustrating when you are trying to find something
in a hurry (remember, HELP is for quick lookups when you are away from
the manual set...).
s/rob
|
801.51 | Please add the severity levels to HELP | NSSG::R_SPENCE | Nets don't fail me now... | Tue Jun 25 1991 12:24 | 4 |
| In the FCL help for ENTITY - ALARMS - RULE - CREATE - Severity, it
would be good to add the list of Severity levels here.
s/rob
|
801.52 | thanks | TOOK::DITMARS | Pete | Wed Jun 26 1991 09:58 | 20 |
| > Where in HELP is the list of valid relational operators that can be
> used for Alarms Rules?
For mcc 0 alarm rules, you can find the list under:
entity alarms rule create expression syntax
For the comparison format of domain rules, which is the only way users can
create rules from the IMPM you can find the (different) list under:
tutorial creating_rules comparison
I will enter a suggestion QAR that the domain rule help be re-worked to
include this information under the entity topics as well as under the
tutorial topics.
> In the FCL help for ENTITY - ALARMS - RULE - CREATE - Severity, it
> would be good to add the list of Severity levels here.
I will enter a suggestion QAR.
|
801.53 | | NSSG::R_SPENCE | Nets don't fail me now... | Tue Jul 02 1991 15:38 | 2 |
| Thanks to you too Pete.
|
801.54 | Notification Problem, | NSSG::R_SPENCE | Nets don't fail me now... | Tue Jul 02 1991 15:55 | 48 |
| Notification has just about died on my system. I don't know why.
A month ago I was playing with events and at that time discovered
that I didn't get visual notification in the iconic map. A system
crash put a stop to the investigaiton at the time.
Last week I was doing a demo and noticed that normap alarms were not
notifying consistantly on the map. It would work for one domain but
not another.
I tried deleting the domain and creating a new one of the same name
to make sure it was dynamic (how DO you tell on an existing map
anyway?). However, I still don't get notification on the map even
with the new domain.
I have started and exitted (not stopped) DECmcc several times. That
doesn't seem to have an effect.
I tried enabling notification from the FCL but have not seen anything
even though it was enabled at one time where I did get a map color
change (so maybe I didn't do it right?).
Here is my notify command;
MCC> notify domain zko-lkg events=(any events),entity list = (node4 *)
After notify was enabled and the alarm proceedure had broadcast an
alarm to my terminal but notify had not, I looked at the status of
the alarm;
MCC> show mcc 0 alarms rule zko-lkg_incir all status, in domain zko-lkg
MCC 0 ALARMS RULE zko-lkg_incir
AT 2-JUL-1991 14:47:02 Status
Examination of attributes shows:
State = Enabled
Substate = Running
Time of Last Evaluation = 2-JUL-1991 14:46:50.73
Result of Last Evaluation = True
Error Condition = "No counters in the counters
attribute partition for this
entity.
"
Anyway... I don't know where to look. ANy help would be welcome.
s/rob
|
801.55 | More, please -- what's the rule on? | TOOK::ORENSTEIN | | Tue Jul 02 1991 16:56 | 31 |
|
Hi Rob,
I think there were problems with visual notification if the ALARMS
patch was not applied. Did you use the patch?
MCC> show mcc 0 alarms rule zko-lkg_incir all status, in domain zko-lkg
>> MCC 0 ALARMS RULE zko-lkg_incir
>> AT 2-JUL-1991 14:47:02 Status
>> Examination of attributes shows:
>> State = Enabled
>> Substate = Running
>> Time of Last Evaluation = 2-JUL-1991 14:46:50.73
>> Result of Last Evaluation = True
>> Error Condition = "No counters in the counters
>> attribute partition for this
>> entity.
Could you provide the rule expression? Did you use a sub-entity
wildcard? Did you use an EXCEPTION HANDLER procedure -- could
this have been the broadcast you saw? I'm confused by the fact
that the Evaluation = True, but the Error Condition is filled in.
It looks like the rule was evaluated more than once: the former
had an error, and the latter evaluated to true -- what do you think
about this?
aud...
|
801.56 | Here is the rule | NSSG::R_SPENCE | Nets don't fail me now... | Tue Jul 02 1991 18:22 | 48 |
| Ok, here is the rule;
CREATE MCC 0 ALARMS RULE zko-lkg_incir -
EXPRESSION=(NODE4 bblk01 circuit syn-0 Inbound Utilization > 60 , -
AT START=(+00:00:30) EVERY 00:05:00, -
FOR START (-0:00) DURATION 00:04:30 ), -
PROCEDURE=COM$:MCC_UTILIZATION_BROADCAST_ALARM.COM, -
EXCEPTION HANDLER=MCC_COMMON:MCC_ALARMS_BROADCAST_EXCEPTION.COM, -
CATEGORY="Circuit Utilization", -
perceived severity=Critical, -
DESCRIPTION="Inbound Utilization > 60%", -
PARAMETER="USER=SYSTEM", -
IN DOMAIN = zko-lkg
MCC> show mcc 0 alarms rule zko-lkg_incir all char, in domain zko-lkg
MCC 0 ALARMS RULE zko-lkg_incir
AT 2-JUL-1991 17:15:13 Characteristics
Examination of attributes shows:
Procedure =
USER$NETS:[R_SPENCE.COM]MCC_UTILIZATION_BROADCAST_ALARM.COM;2
Exception Handler =
USER$NETS:[MCC]MCC_ALARMS_BROADCAST_EXCEPTION.COM;3
Description = "Inbound Utilization > 60%"
Category = "Circuit Utilization"
Parameter = "USER=SYSTEM"
Expression = (NODE4 bblk01 circuit syn-0 Inbound
Utilization > 60 , AT
START=(+00:00:30) EVERY 00:05:00,
FOR START (-0:00) DURATION 00:04:30 )
Perceived Severity = critical
*** Note, I had to mung the format above a bit to put it here - it
looked ok in MCC
I didn't notice the exception handeler go off although it may have.
Most of the broadcasts were clearly from my alarms proceedure (a
modification of the supplied one that also broadcasts the value).
This proceedure worked great for me for hours at a time over several
weeks. I haven't changed the proceedure. Notification doesn't seem
to see it.
I have the alarms patch installed. I don't have the PA patch installed
but I think it only applies to bridges.
s/rob
|
801.57 | some info | TOOK::HAO | | Wed Jul 03 1991 10:21 | 16 |
| Rob,
When you said you were playing with events, were you talking about
alarm rules using events (occurs function)? The V1.1 IMPM only
supports notification on alarm rules.
When you re-added your domain to double-check that is was a dynamic
member, did you also check that any of it's parents were static? As
long as there is one static member in the hierarchy (where the root is
the domain specified in the Open Domain function), you will not get
notification from the static member on downwards. Also, there isn't
currently a way to find out if the domain member is static or dynamic.
Talk to Jim Lemmon if this is really important to you.
Christine
|
801.58 | Will it be added for V1.2? | NSSG::R_SPENCE | Nets don't fail me now... | Wed Jul 03 1991 11:54 | 11 |
| When I said I was playing with events, yes, I meant using OCCURS in
alarm rules (since that is only use of events in V1.1).
I always take the default when creating domains (except when I really
want a static one). In the past the default has always been dynamic.
If there is no way to check what I have, then how can I proceed?
Perhaps the domain type should be added as a characteristic attribute?
s/rob
|
801.59 | You can check Member Type | SNOC01::MISNETWORK | They call me LAT | Wed Jul 03 1991 21:17 | 17 |
|
You can check the type of the domain via FCL. If the domain zko-lkg
is a member of another domain called ZKO for instance, then use the
following command -
MCC> show domain ZKO member zko-lkg all char
Domain WHO_KNOWS_NS:.ZKO Member WHO_KNOWS_NS:.ZKO_LKG
AT 4-JUL-1991 10:05:45 Characteristics
Examination of attributes shows
Member Type = Dynamic
Member Entity = Domain WHO_KNOWS_NS:.ZKO_LKG
Cheers,
Louis
|
801.60 | Good workaround | NSSG::R_SPENCE | Nets don't fail me now... | Mon Jul 08 1991 10:43 | 9 |
| Thanks lots for the workaround for finding domain type.
I hope that in the future you will be able to do a
MCC> Show domain zko-lkg all char
and see it also.
s/rob
|
801.61 | Modify Export problem | NSSG::R_SPENCE | Nets don't fail me now... | Tue Sep 03 1991 15:29 | 24 |
| I thought I had seen this before but I can't find it. Sorry if it is a
duplicate.
I was setting up EXPORTING the other day and started up export of
a node4 but forgot to specify an end time. The export started up ok.
I then selected Modify Export from the Operations menue and modified
the form to include a stop time and pushed the start button.
We got a no exporting for this entity error even though a SHOW EXPORT
from the iconic map would show it to us. Though we got the error,
it still successfully made the change.
Associated with this, but common to most modify (or SET where there is
allready stuff set) windows, it isn't very clear what the effect of the
pushbuttons (the red ones down the left side) are during these
operations. It seems that it doesn't matter if a button is red or not
for attributes that you have not typed anything into the form.
???
s/rob
|
801.62 | | VERNA::V_GILBERT | | Wed Sep 04 1991 10:10 | 13 |
| Rob,
The purpose of the buttons on the left side of a set form
if they are on (the way they are initially displayed) AND there
is a value in the field the value will be encoded after the user
presses Start Operation
if the button is off, even if there is a value in the field, it
will not be encoded after the user presses Start Operation
Hope that helps.
Verna
|
801.63 | Ok,... but | NSSG::R_SPENCE | Nets don't fail me now... | Wed Sep 04 1991 12:25 | 12 |
| Thanks.
Some feedback...
It has seemed to me when I have used MODIFY activities (a SET where
some attributes are allready set is really a modify also), I always
seemed to expect that the buttons would be by default off and I would
select the few attributes I want to change. I believe this will be
a common operation for selected referance attributes with a wildcard
entity spec in the future (when wildcard entity specs work for this
sort of thing).
s/rob
|
801.64 | | VERNA::V_GILBERT | | Thu Sep 05 1991 16:12 | 8 |
| Rob,
Thanks for the feedback. Others have expressed similar feelings about starting
with all field in the "Do not Send" toggle position. Changes such as that have
been deferred for the time being (V1.2) but hopefully will be re-examined
after.
Verna
|