| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3246.1 | SHOW TO FILE | CCIIS1::ROGGEBAND | _ �hili��e _ | Thu Jun 25 1992 06:27 | 7 |
| Dan
The simplest way that comes to mind is to run a batch job which issues
a "SHOW <obj whatever> ALL ATTRIBUTES TO FILE <whatever> [AT EVERY
<timeframe>]"
�hR
|
| 3246.2 | "last captured data" | SKIBUM::GASSMAN | | Thu Jun 25 1992 08:57 | 7 |
| Going to a file is fine - but how is the data recalled then? When doing
trouble shooting of a downed router - knowing what interfaces it had, and
what was the data on all partitions at the last snapshot - is valuable to
the person looking into the problem. A new feature that kept that
"last captured" data would go a long way towards adding value to MCC.
bill
|
| 3246.3 | Storing of last captured data = excellent idea | CUJO::HILL | Dan Hill-Net.Mgt.-Customer Resident | Thu Jun 25 1992 14:00 | 4 |
| Bill's idea is exactly what we need. It would be nice to have the
option to turn it on or off by default.
-dh
|
| 3246.4 | You can do it now. It just needs some lipstick... | MCDOUG::MCPHERSON | Life is hard. Play short. | Thu Jun 25 1992 14:27 | 9 |
| Recording of atribute data and subsequent playback is already handled by the
Historian FM and DECmcc's dispatcher handling of requests for *past* data.
E.g. If you've recorded "all attributes" for a router using the RECORD
directive, then you can 'play back' the old data by simply issuing a SHOW ALL
ATTRIBUTES for the router specifying a timespec that matches the window of
recorded data.
|
| 3246.5 | Entity cloner FM, Set debug FM | TOOK::FONSECA | I heard it through the Grapevine... | Fri Jun 26 1992 16:29 | 20 |
| I'm not sure you are really talking about this, but I would like to
see a way to do this SHOW ALL, and store the information in a way that
would allow you to then do a subsequent SET ALL using the information
gleaned from the SHOW. TSAM currently has a utility that allows you
to grab all of the info, and then it scans through it and creates
a com file that does this. Folks like to set up a terminal server,
and then clone other servers the same way.
I'm sure that terminal servers are not the only management entity
that users would like to do this with.
Secondly, a similar feature which would be useful for testing AMs
would allow you to do a SET, and would do a subsequent SHOW, which would
verify that the SET actually 'took'. This would either triggerable
by setting a logical, or would be another AM that would somehow intercept
the commands. I've thought of impletmenting it inside TSAM, but to
be truely general and more useful to all AM developers, it would be
outside the AM.
-Dave
|
| 3246.6 | copy obj X to Obj Y -- would be nice | CLARID::PATEL | We'll get it right on the night | Mon Jun 29 1992 05:39 | 6 |
| While we are in a good ideas mode, ;-)
a copy object x attributes to object y, with data entry for mandatory
"different" data in a form would be really whoopee
Amrit
|
| 3246.7 | SHOW TO SPREADSHEET | ZPOVC::ANDREWWAITES | Do what it takes, take what it does | Tue Jun 30 1992 00:32 | 19 |
| Hi,
Seems there is room for ideas here. I am busily building all sorts
of nasty interfaces to provide some "finish" to MCC. The architecture
is GREAT but one suggestion..
I find the output from the SHOW directive to be pretty long winded
(especially when doing things like SHOW BRIDGE blah FORW DATA STAT
ENTRY *). I could export lots of data then use the Rdb database
but setting this up is a pain and the export seems more for repetitious
exercises than for one-off things. I'd love to see some way of
exporting to a spreadsheet compatible file (flat with delimiters would
do) so happy users could use LOTUS or EXCEL (insert approp trademarks)
to provide the finish (we shouldn't spend time re-inventing their
wheels). I have used SHOW TO FILE plus lots of TPU but that is messy.
thanks,
Andrew
|
| 3246.8 | will be on NSDP CDROM | CLARID::HOFSTEE | Take a RISC, buy a VAX | Tue Jun 30 1992 05:49 | 23 |
|
Since we had the same problem, we developed a windows based reporting package
that creates directly 'spreadsheet readable files' out of the RDB file. The
process is releatively simple:
1. Select through the interface which reports you want, for what entities
2. Start the report production. From this moment on everything is automated.
3. The package generates the proper EXPORT commands and starts collecting
the data. This can be automatically repeated every week,month.
4. At the end of every period, some data analysis routines will munch the
RDB file and produce 'spreadsheet ' files, that can be imported directly
into DECcalc, LOTUS, Excel or you own favorite spreadsheet/graph
package.
Of course, to create your own ,customized, reports , you still have to
write your own data analysis munching routine.
Notice that this package will only be available on the NSDP CDROM , which
is meant to be used for customers with a Network Management Service Contract.
Timo Hofstee
ESE/TT
|