Conference azur::mcc

Dave,

Notes 704 and 704.4 has an outline of how to use DECdecision if you decide 
try it.  You did not mention what kind of printer the customer did have.

DECmcc V1.2 has at no extra cost real time graphs which can be screen captured.

I am curious what the customer felt was most important to graph.
What is actual data was and for what purpose? 


Al Moore    

    
    Hi, thanks for getting back to me.
    
    Well, the customer (SmithKlone Beecham R&D) runs a world wide network
    with extended lans and Wan connections, X.25 and just about every
    configuration you could dream up with LANs.  My residency here is
    to provide network support as well as implement MCC as a network
    monitoring tool.  They are looking for multiple items from this
    station.  Near real time alarm is very important to them..this is
    pretty much under control.  They are looking for trend analysis
    on their wide area circuits (very important for the higher ups to
    receive line graphs of utilization of the WAN circuits).  They very
    much would like to have graphic reports on such items as:
    
    Area outages - they currently have ~ thirty DECnet areas and are
    charged with providing area reachability statistics.

    X.25 circuit availability - they need to assess the reliability of
    their backup circuits world wide as well as the reliability of the
    service provider.
    
    Major cluster reachability - this one is covered
    
    Translan utilization for extended LAN circuits
    
    The bottom line is that the upper management of the company likes
    the graphical approach.  We have tried to prepare distilled line
    oriented reports, but this approach has been rejected numerous
    times.
    
    
    As far as printers, they mainly use various models of QMS postscript
    printers.  Currently, many of them are driven from a home grown
    symbiont, however, they will shortly be converting to a symbiont
    from Gray Matter.  This symbiont does not support sixel or regis.
    
    I have seen some unsupported hacks to allow our symbiont to converse
    with non-DIGITAL printers, however for a support conscious (sp?)
    customer, this is not a viable solution.
    
    They expect reports to be generated automatically for each week
    and each month and potential on a 6 mo to yearly basis.  Captured
    graphs from the screens is an unacceptable solution because it requires
    human intervention.
    
    Before shutting down the other portions of the EMS station software,
    we had regular weekly and monthly reports generated in line format
    from DECNET/NMCC.  Some of this data was being put into SAS to produce
    the desired results.  I modified an area monitor program from DECUS
    to timestamp area outages, and this is also being worked into a
    SAS whatever-it-is.  I believe everyone feels that this portion
    of report production should be able to be directly obtained from
    the MCC data, rather than exporting from system to system to achieve
    the desired results.
    
    But I ramble on... I hope this gives you some feel for what they
    want (not to mention, they would like graphs depicting the number
    of times alarms fired also, but I am told we can;t record this in
    the MIR).
    
    
    Dave Comfort

    
    Thats - SmithKline Beecham
    
    Arghhh
    
    DAC

	Things like graph generating tool on link utilization and 
	reachability and uptime reports on areas,nodes and links has 
	to be added to MCC in a user friendly interface, that don't 
	need any daily human intervention !

	This is what coustomer demands from us today which in many
	cases has to be sollved by a late midnight hack ! 

	My personal feeling on this is one midnight hack is one midnight
	hack to many.

/Stefan

We are actually working on this at the moment. The idea is to make a
reporting package, that allows the user to setup reporting in an easy way
through a windows interface. The output will be ascii files for DECgraph
and a general spreadsheet format, so that you can import the data into
your favorite spreadsheet/charting package, which might be DECdecision or
any PC package like Excel/Lotus etc.

Timo

re -1,

By the way, around creating reports on lines/circuits, ...
I had a student (Frederic Lucas) who developped a package to provide
graphics on circuits/lines of a DECnet (IV) type of network.

Basically, it uses as input the RDB database created by the Exporter FM.
Thru a menu, you have a set of options to create various reports
(availability, error rate, % utilization, ...)

It uses DECgraph to create/display the result. You can then convert it in SIXEl
to put the result in a document eventually.

If you are interested, you can find a backup kit under 

HERON::UNIT4:[LATOUCHE]LUCAS.BCK;1

Of course, it has to be taken 'as it is' !!!

The documentation is whithin the .BCK



DECgraph is not the ideal tool for the long term, I agree with. Meanwhile, I'm 
not sure yet on what should be the tool to use as output of a 'data reduction'.
I 've read DECdecision, I was thinking of a simple spreadsheet tool.
May be Wandesigner ?

Any ideas ?

Marc.

    RE .5
    	Timo, would it be possible to store the options selected by the
    user in the DNS namespace under a 'profile' name?  That way a
    command line interface to the reporting package could be written at
    a later date. From the command line I would be able to select the
    report 'profile' I want and just pass a few entity or time specific
    parameters at run time.
    
    Eg.
    	Lets assume I've selected the graphing options I want for a
    graph of circuit utilization + error v's time. I would now store
    that profile under a name .graph.decnet_circuit_plot.  Later
    I could use a command line interface to select this profile and
    generate the graph in batch.
    
    MCC> PLOT node4 rtr01 circ syn-0, using profile
    .graph.decnet_circuit_plot, at start xxx, to file rtr01.ps
    
    the same profile could be used over and over for various nodes.
    
    Placing the information in the namespace allows every MCC station in
    the environment to use a common graphing profile.  Most customers
    want to be able to generate their reports in batch at end-of-day. 
    
    Just an idea...
    
    - Mike 

re -1:

Well, without going into too much detail here, the idea is much the same. You
could indeed specify something like :

CREATE EVERY MONTH A LINE UTILIZATION REPORT FOR NODE4 * LINE SYN-*.

However, this will not be possible through an FCL but through a windows
interface.

As far as the output is concerned, we had long discussions if it should be
DECwrite, postscript, ascii, decgraph, decdecision etc. etc.

As stated in my previous note, you can get DECgraph loadfiles or a general
spreadsheet format, that you can import into your favorite graphing package.

What you cannot specify is the 'style' of the graph (line, bar etc.) since
we leave that to the graphing package you prefer to use.

And yes, this will all be running in batch ...

Hope this will be useful :-)

    
Timo

Has anyone looked at the report output mechanisms used in the DECmcc/MSU
product.

MSU seems to be able to produce HPGL, Postscript, ASCII, and/or mail formatted
reports in either table or graph form.  Perhaps some of this could be reused
here.

Regards,

Glen R.

    
    I wanted to let folks know my workaround.  I busted out the CPS
    software and found that there is a program that is called by the
    symbiont that does the translation from regis to postscript.  This
    program plus a little modification of the DECgraph defaults file
    and the DECgraph command line produces excellent results.  This
    is officially unsupported, but it does work.
    
    the file name is TRN$REGIS_PS.EXE
    
    I defined a symbol RTOPS :== $dev:[dir]TRN$REGIS_PS.EXE
    
    and it will prompt for input file, output file and page style info
    ie. landscape, portrait, etc.
    
    The only initial problem is that if one uses a graph output (.GRL)
    file, the image is black with white lines, no matter what you tell
    the DECgraph default file.  With the default file setup correctly
    for my purposes, I had to alter the graph command so it looks like:
    
    graph/mono/out=filename/noint graphics_input.GRI graph_default.file
    
    
    Dave Comfort

    
    I forgot to mention that the regis_to_postscript program only produces
    the postscript language part, not the headers so the % type stuff at
    the beginning of a postscript file has to be added to the result of the
    translation.