Conference azur::mcc

    The Script AM Specialized Exception # 6 is the 'Time out'.  It took
    longer for the script to return data than the Default Timeout.
    
    If you have not specified a Timeout value when you created your script,
    check the Default Timeout value:
    
    	show mcc 0 script all char
    
    /keith

    I come back on note #5327.
    
    I made a script file with moderately integrated script, which
    executes in average in 10 seconds time.
    
    When I try to RECORD the information provided by the script, VERY
    often, meaning almost always results in
    "Specialized exception 6 ==> Time-out."
    
    I increased the time-ou value from 0:2:0 to 0:5:0, without any visible
    improvement.
    
    I am starting to think about a side-effect which could potentially
    be the cause of this behaviour.
    
    When "GRAPH" was used to display multiple arguments of the same script
    entity, GRAPH will always run into problems and threads will very often
    time-out.  If on the other hand GRAPH is started several times, where
    in each GRAPH thread only 1 argument is graphed, everyting runs
    smoothly.  This is a (well known) bug for the combination GRAPHS and
    SCRIPTS.
    
    Would it be possible that that the same kind of problem is hidden in
    the historian FM?
    
    I started now recording with a 60 second interval between recordings to
    see if the recording behaviour will be better.  I'll post the results
    here.
    
    Has anybody encountered the same problems ?
    Dominique.

    Since I increased the time between two pollinig[Bs to 60 seconds, I surely
    do not get any parallel recordings on my domain, and in this case the
    recording of the STATUS partition of my scripts seems to run smoothly
    now.
    
    I do not like however to set the bakground polling delay to 60 seconds,
    which will limit very hard the way data recording will work.
    
    Is there any news here ?
    
    dominique.

I didn't think to ask if this was on Ultrix... 8(

Yes - the same problem with Graphing Script Attributes on Ultrix
will cause problems for the Historian.

But I now remember something about the way Historian works and how
the Script AM handles overloading of entity instances.  It might be
that the Historian cannot record script attributes 8(

I'll try testing this /keith

I just tested recording script attributes on VMS...

First, I tried starting the MCC_HISTORIAN_BACKGROUND.COM in batch...I got
weird data recorded from the Script AM .. I understand this to be because
the historian running in batch, causes the script am to not spawn correctly.

So .. I made another terminal window and ran the historain in that .. recording
script attributes then worked fine .. 8)

I'll try on Ultrix next /keith

    Yes, I encounter the problems on ULTRIX. I once saw also the
    "MCC specialized exception code : 2"  but the code 6 is on few
    exceptions the only one I see always.
    
    The funny thing is that another recording (for a NODE child entity)
    works fine, and that EACH time (without exception) I am trying to get
    the status attributes of the script, I ALWAYS get these attributes in
    about 15 seconds.  The time-out on the script is actually 5 minutes!
    
    After all the "60" second delay as specified in the historian
    background process did not help a lot. You better forget the comments
    around this.
    
    What is sure is that my management station is a DECsystem 5000/240,
    that station has no special load as I am only setting-up management
    procedures.
    
    I have two different scripts on several different objects.  These
    all behave in the same way.
    
    Dominique.

    Is the following problem related to the previous one ?
    Since this week the scripts I have does not like to run.
    
    The show SCRIPT ... all status results in
    	"The script has produced no output" about immediately, although
    explicit execution of the script works:
    
    MCC> sho script .mcc.gkk_statistics ns_statistics ngkk02 all attr
    
    Script bc:.mcc.gkk_statistics ns_statistics ngkk02
    AT 1993-07-19-16:24:11.254 All Attributes
    
                                   Hostname = ngkk02
    The script has produced no output.
                                    Command = "/usr/mcc/mcc_scripts/ns_statistics
                                              ngkk02"
                                    Timeout = +0-00:05:00.000I-----
    MCC> sho script .mcc.gkk_statistics ns_statistics ngkk02 all attr
    
    Script bc:.mcc.gkk_statistics ns_statistics ngkk02
    AT 1993-07-19-16:24:12.961 All Attributes
    
                                   Hostname = ngkk02
    The script has produced no output.
                                    Command = "/usr/mcc/mcc_scripts/ns_statistics
                                              ngkk02"
                                    Timeout = +0-00:05:00.000I-----
    MCC> Exit
    mgkk01> /usr/mcc/mcc_scripts/ns_statistics ngkk02
    ngkk02 0 0 43 57 73  0.01 212 21 21 32 1
    
    

    Now the problem described in note 5361 has disappeared,  I can
    concentrate back on this problem.
    
    I monitored the recording and it shows
    "MCC specialized exception code : 6" in about ALL SCRIPT (and only
    script) recordings, and as said earlier, interactively it NEVER fails,
    at any time !
    
    	What part of the code is responsible for this ?
    
    	Dominique.

MORE ACCURATE PROBLEM STATEMENT.

	It is reproductible that, when two or more scripts are being
executed, but the first one does not terminate quickly, the following
scripts does time-out EVEN IF DATA WAS returned normally.
Also the longer the timeouts, the more critical the problem.

e.g.	SCRIPT1	tmo = 5 minutes.
	SCRIPT2 tmo = 1 minute.

Now SCRIPT1 is issued, then SCRIPT2
Lets assume SCRIPT1 takes very long ....
SCRIPT2 executes normally and should finish about immediately.

In this case SCRIPT2 will TIMEOUT, although it got its data.



ANOTHER WAY TO EXPRESS THE PROBLEM

As long as there is a script thread which is not terminated,
meaning did not returned the requested data back to DECmcc, all
other scripts issued afterwards will never terminate normally
as long as the first one did not timeout !


    	Can anyone confirm this,  this seems a serious bug.
    
    	Regards,
    	Dominique.