Conference azur::mcc

> How do you pass parameters into a moderately integrated script where the 
> command is set?? I can see how to do this as a loose script but not with
> a moderate. I suppose you could define a seperate instance with its own
> command but that doesn't make the grade. I really would like to pass a variable
> without setting something up with every execution. Does the syntax cover
> this and if so how.

  There are three types of Script Integration:

    o Loose
    o Moderate
    o Tight

  Loose and Moderate are support with the first release of the Script AM.
  The technique required to pass arguments to a script is as you described;
  you need a seperate instance with the exact command .. and yes, I agree
  that it doesn't make the grade.

  It was our intention that we add Tight Integration for the next release
  of the Script AM.  Tight Integration will allow you to use *ANY* entity
  model for your script; so that in theory, you could replace the DECnet AM
  with a series of scripts which call NCP .. also, we would expand the
  verbs supported to include SET.

  As far as I know, there are no plans to work on the Script AM for the 
  release after v1.3.  Would Tighly Integrated Scripts help sell DECmcc ?
  I suggest that you reply here .. and also contact Bill (SKIBUM::)Gassman
  to make you needs known.

  I certainly appreciate your asking about the Script AM .. it means that
  you're using it .. and tools which are useful generally get the $$ to 
  support them.

  /keith

>  As far as I know, there are no plans to work on the Script AM for the 
>  release after v1.3.  Would Tighly Integrated Scripts help sell DECmcc ?
>  I suggest that you reply here .. and also contact Bill (SKIBUM::)Gassman
>  to make you needs known.

>  I certainly appreciate your asking about the Script AM .. it means that
>  you're using it .. and tools which are useful generally get the $$ to 
>  support them.

I'm not sure if it will help sell MCC. But if the script am is to be part of
mcc it must support passing variables more readily. The reason I say I'm not
sure is because the SCRIPT AM is for the very experienced. It is not something
most Joe users are going to unpackage and start scripting. However IT IS AN
EXTREMELY USEFUL UTILITY and should be taken to full development. Your
experienced users familiar with MCC can now build upon the platform themselves
and you could better lock them into the product.

How useful? I just spent maybe four hours doing a proof of concept script which
I believe we have discussed in the past already. Other than my own errors and
causing the dictionary to be out of sync this is what I achieved. Although the
script isn't productionized I proved to myself I COULD BUILD A DISTRIBUTED
RESPONSE MONITOR FOR IP. The concept script can't be more than 30 lines long
and runs from a VMS MCC node w/ucx v2.0. I can now use MCC EXPORT or RECORD to
create a database for monitoring IP response times from remote locations with
a simple .rhosts edit and the use of rsh within the script. Maybe I'd even
alarm the info. Now we've got scripts which do this function already so I don't
know if I'll put it into production but if I were an external customer I sure
would. With this version we'll also use it to monitor other tools running
remotely to ensure their operation. Now this stuff is USEFUL.

best regards,
brad...

    I would also like to see (in the future) a way for the script to know
    what entity and domain they were run from. Same stuff Launch in V1.2
    supplied.
    
    s/rob

RE: .1

>  It was our intention that we add Tight Integration for the next release
>  of the Script AM.  Tight Integration will allow you to use *ANY* entity
>  model for your script; so that in theory, you could replace the DECnet AM
>  with a series of scripts which call NCP .. also, we would expand the
>  verbs supported to include SET.
>
>  As far as I know, there are no plans to work on the Script AM for the 
>  release after v1.3.  Would Tighly Integrated Scripts help sell DECmcc ?
>  I suggest that you reply here .. and also contact Bill (SKIBUM::)Gassman
>  to make you needs known.


Well... I played with the SCRIPT AM yesterday to see if it is useful for my
customer: Belgian Railroads (SABIN project), where we manage a network of 650
systems (VMS). Since the nodename of the system where the script has to run
needs to be in the Command Attribute, you need 650 instances of a moderate
script if you want to see a meaningful name for the attributes returned. 

Unless the target nodename can be supplied from the command line for a moderate
script, the script am is pretty useless in a large network environment since
maintaining 650 instances for each script generates more overhead than other
tools available to execute remote command procedures (example RSM's NETDCL). If
the script am is used for alarms, the data collector is more appealing in a
large network environment because the analysis is done on the local system and
only alarms are transferred across the network.

Conclusion, SCRIPT AM is nice for small management domains, but doesn't
contribute if you have a large management domain. TIGHT scripts is what we need
for large networks and all major customers, where we get the $$, have large
networks.

My 2�,

EricV.

    Actually what you need is the common agent on VMS and a MOM that
    returns the info you need.
    
    What attributes of the VMS systems are you looking to see?
    
    I believe that the VMS common agent is available internally at the
    moment as field test. Perhaps they want/need a real application?
    
    s/rob

>    Actually what you need is the common agent on VMS and a MOM that
>    returns the info you need.

Not really, if it's "HOURS NOT MONTHS" what you're after and if you're a simple
system or network manager.
I have the common agent doc and you need to be an expert C programmer with
thourough knowledge of EMA. I'd position the common agent as "WEEKS NOT
MONTHS".

    I agree, Common Agent is a better choice.
    The VMS version is currently in EFT Update and 
    should be gong to SSB soon.  It uses the CMIP
    protocol and has a development tool kit that 
    generates most of the code needed ... you add
    system specific calls to get or set attributes.
    You can use the MSL you created for the SCRIPT
    AM as seeds for the code generator (Managed Object
    Module generator, MOMGEN).  That same MSL is 
    used again to add the extra capabilities to DECmcc.
    Look in NOTED::COMMON-AGENT for kit pointers and 
    other assistance.
    
    /Claudia Peters