Conference azur::mcc

< Thinkin' about playing with launch and the manual has me a bit confused. It
< describes the ability to double-click an icon (ex. NODE4) to directly launch.
< If I define this how do I then 'look-into' the NODE4 if I don't want to
< launch? Is it a different MB or is this an ALL or NOTHING feature.

The documentation is a little bit confusing.  The double-click method is
meant to be used for entity classes that have no AM and would always go
to a launched application for management of that class. 

You are correct that the launch does supercede the look-into.  For 
example, if you define a application to be launched by double-click for 
class NODE4, then you will never be able to look-into the NODE4 class.

I suggest that, for the situation where you want to have look-into and a 
launched application, you use the "applications" or "operations" menu.

...kjn

>I suggest that, for the situation where you want to have look-into and a 
>launched application, you use the "applications" or "operations" menu.

ok thanks. next question, is there any way to define NO WINDOW?? That is, I
simply want to run the application in the background without a window popping
up. The env_type doesn't seem to cover this. Could this be done directly from
the resource file?? As always I'm lookin' to be different (or at least first).

cheers,
brad...

    The problem is that there is not necessarily a window associated 
    with the "background".  For example you could start the impm from the
    session manager directly.  And on Ultrix (and maybe VMS too), you can
    detach the impm from the terminal window you started it from.  We
    would need to figure out how to make all these cases work.
    

>    The problem is that there is not necessarily a window associated 
>    with the "background".  For example you could start the impm from the
>    session manager directly.  And on Ultrix (and maybe VMS too), you can
>    detach the impm from the terminal window you started it from.  We
>    would need to figure out how to make all these cases work.
 
Jim, thanks for your time to answer. Does it really matter how the IMPM is
running? All I want to do is LAUNCH a program/script which uses no window.
It executes, it stops, no window. Is everything that tied up to windows?

Here's my idea (MCC engineers will probably be lookin' to gun me down with this 
one). There are a couple of problems which I have voiced in the past with
using MCC for entity operations. They are:

1. The entity model does not always meet user operations needs. That is, the
   user must issue multiple commands to get the info because the info resides
   within multiple children.

2. MCC is a bit slow and the users don't have the patience. I suspect
   some of the slowness is the creation of the OPS window then the formatting
   of the attributes.

3. Issueing wildcarded commands from IMPM takes too many clicks.

The above issues are comparing MCC to ncp and I suspect the same may be true
(but to a lesser degree) with ncl. My suggestions have been to give the users
a single OPERATIONS DISPLAY WINDOW. This stops all the window create/delete
activity and is much more appealing to the eye. The user can also better scroll
past commands rather than saving windows (which doesn't usually get done). The
next suggestion was to give us buttons to push which the user can customize to
retrieve attribute data which could span the entity model.

The one positive for IMPM was adding the table format (good job) which helps
a bit with wildcarding but selecting the entities still means too many clicks.
Although the voice of the user has been heard these things (if at all) are 
still a ways out.

Sooooo, the heck with it, I'll do it myself. By simply bringing up a window and
assigning a logical or two I get my OPERATIONS WINDOW. This is a done deal and
was simpler than simple. Now I simply set up a LAUNCH to issue those commands 
always used. If it weren't for the window popping up then disappearing
this has been a complete success although I still haven't passed variables yet.

Are there 'any' suggestions out there with this kit to stop the window pop-up
for launch??

thanks,
brad...

    It's not that everything is tied to windows; it's that there is
    probably no such thing as a completely "silent" application.
    
    The issue is that stdin/stdout/stderr (sys$input etc) need to go
    somewhere.  Even an application that does no terminal I/O needs to have
    stderr defined in case it fails.   One possibility is to use the
    console (but I'm not sure that's what you have in mind) - we are
    looking into this for 1.3 because of some related problems. 

    
>    The issue is that stdin/stdout/stderr (sys$input etc) need to go
>    somewhere.  Even an application that does no terminal I/O needs to have
>    stderr defined in case it fails.   One possibility is to use the
>    console (but I'm not sure that's what you have in mind) - we are
>    looking into this for 1.3 because of some related problems. 

No, the console wouldn't work. I'm using stdout now, I don't need stdin, and
maybe stderr could go to a log (only on error??) or to the current STATUS
window? Here is what I have to date. I bring up a DECterm window for 
OPERATIONS OUTPUT and 

ASSIGN <dev> mcc_ops:/group   ! where <dev> is obtained from SHOW TERM

The launched procedure then

assign mcc_ops sys$output     !now everything the launch program outputs goes
                              !to the previous OPERATIONS OUTPUT window above

This eliminates the need to create a decw window. I've done some more testing
to see if there are any real gains. I used three techniques to gain the same
information, NODE4 EXEC STATUS. The first was using normal MCC operations. 
Three attempts = 17 sec, 7 sec, 8 sec. I suspect 8 seconds to be the norm.

Next I used 1.3 launch and it appeared to take about 20 seconds for norm. This
was with the NODE4 name hardcoded and not using arguments and output to 
OPERATIONS window (not very good).

Next I used the OLD 1.2 launch technique and put the procedure in the 
application menu without create/term. The procedure executed with no window
fine. Click, click   ***  3  SECONDS!!!   *** and the output goes to
the OPERATIONS terminal window. But I don't believe the old technique allows
for the passing of map info, right??? As you can see the omission of creating
a DECwindow enhances performance and this is the strongest case yet to develop 
an Operations Output window which stays up. 

Now if you add a user NAVIGATING thru the entities to select a child, then 
issue an operations command, mcc now approaches 30 seconds or more (this can
actually be MUCH higher given look-into may traverse dns and the net). The 
technique I described above yields THREE SECONDS FOR EVERY COMMON OPERATIONS 
COMMAND I DEFINE A BUTTON FOR because I only need the entity name. The script 
executes against any child (and wildcarded) for the entity without navigation.

PLEEEEEASE help get rid of the auto-window in LAUNCH so I can create the 
ULTIMATE operations tool!! Any new ideas now that you see the scenerio and
benefits from this hack attack??

thanks,
brad... 

Greetings,

I can now claim serious success. Using the V1.2 technique and passing the data 
file I have three 'applications' which issue ncp commands at the speed of
light (click,click,click -> 2-3 seconds -> output). I would still however like
to use the new launch facility if I can stop the DECwindow from automatically
coming up. The new version would be much nicer looking and groups better; also
allowing for a single procedure for all commands using arguments. The current
approach forces an individual procedure for each command. Having said this
hopefully something can be done in this version. Any more ideas for no-window??

Also, is there a way to LAUNCH passing NOTIFICATION info??? This would also be
an immense operations time-saver.

Needless to say the features described in this note would prove to GREATLY
improve ease of use and speed of operation. I would like to add that ncp is
still predominantly used for issueing commands instead of mcc by our analysts
because of the steps and time involved.

cheers,
brad...

    how about posting your example ( or a pointer )
    

... or more appropriately, how about putting example or pointer under the
    appropriate TOPIC in MCC-TOOLs.    ( I believe I put a topic in there for
    Launched Application Examples...)

>... or more appropriately, how about putting example or pointer under the
>    appropriate TOPIC in MCC-TOOLs.    ( I believe I put a topic in there for
>    Launched Application Examples...)

Note 20.2 in MCC-TOOLS now contains the procedures for one of the examples
on HOW-TO.

cheers,
brad...