Conference azur::mcc

  Gee, that is actually a tough question.  The reports package was originally
 designed to be a canned system.  One that would provide an example of what 
 can be done.  So with MCC V1.3 SSB, the current state of reports is that 
 bugs have been fixed and things should be working.

  Since I have heard from many that previous report versions is not useful,
 and not having Datatrieve nor SQL programmers please provide me with some 
 specific feedback as to EXACTLY what you want the reports package to incompass.
 I (only one engineer has been assigned due to budget cuts etc) am working on
 determining what should go into V1.4.  So if you want to see something done
 to meet your needs, talk to me, and talk to me soon.  There are many directions
 that the reports package can go, so to make sure it goes in your desired direction,
 I need to hear what you specifically want from the system.  

  Like I said, there are many ideas floating around, and since reporting is 
 actually very specific to an individual's needs, it is hard to provide every 
 possible type of report out there.  Yes the already implemented canned reports
 will continue to be supported, but maybe we can do something better for the
 next version...

    
    
    O.K., I'll take a crack at some things...
    
    
    1)	Make the reports run in batch.  I had to spend time ripping the
    	command  procedures apart and wrapping them in batch routines to
    	satisfy my customer(s) (and I now know of 3-4 others that wish this)
    	"lights out" reporting requirements. Ie., they wish to walk in Monday
    	morning a pick up all the utilization reports and error reports for
    	their wide area network.
    
    2)	Dump DECgraph... it is not a viable product anymore.  Again, I had
    	to screw around for quite some time to make DECgraph produce output
    	that was translatable to postscript.  Very few customers now have 
    	printers that do other than postscript.
    
    3)	Publish  the RDB data fields for public consumption.  I hate having
    	to go into RDO and dump the information.  At the current time, I am
    	involved in a project to get the reports out using ANY method other
    	than Datatrieve/DECgraph.  (They  have chosen some PC based SQL and
    	SAS) To accomplish this, we have to setup a sample export for each 
    	type of entity we may ever wish to look at, dump the data field 
    	characteristics and give them to a programmer who can use them with 
    	a SQL or whatever.
    
    4) 	Along with #3, make  the report algorithms more available.  I mean 
    	we can rip out the datatrieve code and figure it out, but really
    	Datatrieve is pretty dead and it is hard to find coders.
    
    5)	There should be a method of starting a report from the iconic map
    	using point and grunt technology.  Some of this plays back to how
    	difficult it is to figure out what you're exporting after the fact.
    	Ie., an exporting wildcard directive  that will search and give an
    	abbreviated description of what is being exported, MCC system wide.
    
    I have used DECdecision in the past with good results, however it
    required investigation of data field names to set it up and it is also
    a very expensive product, however something along these lines should be
    integrated.  A canned routine to extract data from the RDB database and
    mung it into a few common spread sheet formats (both VAX and PC based) 
    may be a good way to start some of this.
    
    
    Is this the type of input you are looking for?  I do not have a problem
    with what the reports produce, just the operational aspects and getting
    at the data is somewhat convoluted.
    
    
    Regards,
    
    Dave Comfort

Yep, this is exactly what I am looking for...more suggestions are 
also welcome!  I am in the process of writing down a proposal for
what should be tackled next and how the package can be improved.
Let me take a moment to briefly describe what some of the areas 
that I think need improvement.

  1)  Current reports might not be valid or at least need to 
 	be better clearified (re: note 4520.*)

  2)  All the reports fall into the category of trends, analysis, 
	justification - all reports to show off to management.
	There needs to be reports in the category of problem management.

  3)  As you mentioned (-.1) the reports package is difficult to use.
	a) exporting the proper data
	b) graphics are clumbsy 
	c) no batch - actually this is a security issue 
	d) useless documentation
	   etc...

  4)  The whole report system is very DEC oriented.  We need to
	be able to handle non Digital hardware/protocal/etc.

  5)  Linkages into spreadsheets like DECDecision and Excel so that
	the user can generate the graphs that are customized for their
	needs.

  6)  There needs to be some sort of GUI; does that mean adding this
	to the iconic map or creating a new system or a combination of
	both?

 The list goes on, but Dave, your comments will help stoke the coals.

 Thanks.

    - Darrell
				

    Some proposals:
    
    1. The content of the DECnet Reports should be at least as good as
       the old NMCC-DECnet Traffic and Error Report
       ( detailed tabular representation ).
    
    2. LAN Reports ( for DECbridges )
    
    3. More detailed SNMP Interface Traffic and Error reports
    
    4. no Datatrieve, but SQL
       no DECgraph, but Postscript
    
    5. possibility for automatic report generation ( weekly, monthly, ...)
    
    6. reachability, availability reports
    
    Regards, Karl 
     

    
    To augment some of the suggestions in .2 - .4, I would like to address
    the concept of exporting RDB data to various spreadsheet formats.  This
    process should operate in two scenarios.  The first is to allow the
    selection of data to export from the windows GUI using a method similar
    to selecting the various counters presented when choosing the real-time
    graphing facility.  One would select individual data fields using check
    boxes, select export style and export to filename.  A second
    implementation would allow the exporting of data on a pre-determined
    schedule, not requiring any user intervention, such as a background
    task, etc.
    
    Dave

These are great suggestions!  Any more?  I will bring them up at the MCC 
users group meeting tomorrow.  Part of the meeting will be focused on
reports so I am glad to see you all putting in your valuable two cents!  
Hopefully management will agree and provide you with what you want.

			- Darrell

    We have just started using InstantSQL.  I got a video from the product
    manager.  This product costs $800 (I believe).  You do not have to sell
    off a subsidary of your corporation just to produce a report.
    
    The interface is object oriented, point and click, and very easy to
    use.  
    
    It also WRITES THE SQL CODE   !!!!!!!!!!!!!!!
    
    This should be included with DECmcc as opposed to Datagrieve.
    
    DECgraph should never have been suggested.  An alternative means of
    graphing is a must. 
    
    InstantSQL will also produce data in ASCII tabular format for inclusion
    in a spreadsheet or other database manager.
    
    
    GET THE VIDEO !!!  It practically teaches you how to use the product.
    
    POLYCENTER should produce a similar video for marketing.
    
    -Dan

re .7

Pardon my ignorance, but is InstantSQL a Digital product?

/doug

   
    To InstantSQL is a fine product, though I must caution you that I have
    only limited experience with it.  I have not really been putting it 
    though its paces, but it seems to work fine for my needs, which is
    quick report generation.
    
    The group has also produced an excellent VIDEO which provides an overview 
    of their Rdb design/development/reporting/tuning products.
    
    This is something POLYCENTER should consider.  (Even better, a PC-based
    multimedia demo.)
    
    The product manager's name is        Gale Toale Taylor (603)-884-5218
    					 NUO (Nashua)
    
    The product would be perfect for a VMS platform if it supported RMS
    files.  It would be even better as a multiplatform product if it
    supported other database management software products (Sybase,
    Oracle,...)
    
    -Dan

    In a sense, it does. Have you heard about Rdb Access for Oracle & Rdb
    Access for RMS?

    It seems that there may be two groups aiming at the same goal: better
    and easier to use reports. 
    
    The poeple writing NSDP  are also very hot on this topic. Have you any
    contact with them? NSDP has an easy to use interface to start and
    control reporting jobs in batch, so that as in .2, one can come in on
    Monday and have the reports ready. But NSDP suffers from the use
    of DECgraph and Datatrieve also.
    
    Perhaps, though, a little bit of combining effort since in Engineering
    the staff is being cut, and the people in Valbonne France are also
    considering how to fund a next version.
    
    A contact would be Thierry Jacquemoux in AEO ( Annecy France ) or
    Tim Hofstee in VBO ( Valbonne France )
    
    just some food for thought,
    
    Julie Ann LUnt
    NIS, Cologne Germany

Julie,

  That definately is good food for thought!  Thanks for the pointer.

				- Darrell

    I used to be product manager for a Service Tool called NSDP (Network
    Service delivery Platform). this has already the reporting stuff being
    discussed here built in... there is a way to add user specific report
    templates etc... also the output is provided in DECgraph, comma
    separated format etc for spread sheets...

    check it out with Timo Hofstee @ VBO

    Amrit