Conference azur::mcc

>The question in this sample is why does it return the node number for the 
>DECnetIVName.  A follow on is why does it return an InternetName and OSIName
>at all.

>The questions here are why is the output different between 2 pahse 4 nodes,
>one the mcc station and the other a different node.  The difference I  am
>refering to is one has the correct DECnetIVName and the other is using the 
>node number.  Still why is the InternetName and OSIName returned at all, since 
>they are not valid for this entity.


    I don't believe that "Applies_To" is intended to work the way you're
    trying to use it.   I _think_ that the intent of "Applies_To" is to
    allow you to add operations on specific classes of objects to the
    "Operations" menu.   I _don't_ think the intent was to allow you to do
    'selective branching' like you're trying in your .def file and that's
    why you're getting wacky results.     I.e. the .def file parser logic
    doesn't understand that it's *only* supposed to pass the stuff between
    the various "applies_to's" in your .def file.  Since it can't, it's
    probably passing whatever other attributes it can find lying around
    into the application.
    
>If the "ARGUMENT: <datafile>' is used the docs imply a data file is created
>to be passed to the application.  What or how does one specifiy the name and 
>location of the datafile?

    The Iconic Map is supposed to pass the name of the datafile to the
    application as a parameter.  You should be able to pull it out just
    like you did the other params, then open it.


/doug

    
Well if according to .1 the datafile name is suppose to be passed to the 
application as a parameter it still seems to be a problem.  Not only are
no new files created anywhere on the disk, there is no value passed for the
parameter.

Also, .1 did not touch the fact that results for the DECnetIVName when used
againest the MCC station itself are incorrect, but are correct for other 
phase 4 nodes.

Its too bad the 'APPLIES_TO' is only meant work for the operations menu, if
.1 is correct, and even worse that it is not documented as being so.  

Again attached are the .DEF file, the command procedure called, and sample 
outputs. This time the APPLIES_TO statements are left out, and invalid data
is stll returned.

Steve
--------------------------------
DEL_KEY:*
MENU: Applications
	BUTTON: Name Test
	binary: @dkb100:[woestemeyer]tst_appl.com
	ENV_TYPE: Terminal
		ARGUMENT: <domain>
		ARGUMENT: <decnetivname>
		ARGUMENT: <internetname>
		ARGUMENT: <osiname>
		ARGUMENT: <datafile>
ENDMENU:

$ write sys$output "domain       = ''p1'"
$ write sys$output "DECnetIVName = ''p2'"
$ write sys$output "InternetName = ''p3'"
$ write sys$output "OSIName      = ''p4'"
$ write sys$output "datafile     = ''p5'"
$ inq/nopunc a
$exit

domain       = .DOMAIN.TEST
DECnetIVName = 28.1017
InternetName = KEROON
OSIName      = 28.1017
datafile     =

domain       = .DOMAIN.TEST
DECnetIVName = NSUDC1
InternetName = 40.900
OSIName      = NSUDC1
datafile     =

>
>Again attached are the .DEF file, the command procedure called, and sample 
>outputs. This time the APPLIES_TO statements are left out, and invalid data
>is stll returned.
>

There is a fundamental flaw with the application launch stuff.  Once you
undestand what it is, you can figure out how to work around it.    The
basic problem is this: 
        there is no way to have a single 'button' work for more than one
        object class.   

In other words, the 'Name Test' button can be applied ONLY to one of the
classes you're trying: either NODE4, SNMP or NODE. 

What you *appear* to want is for the application launch to figure out what
the class *is* and then ONLY return the attributes valid for that class.
It can't do this.  Although it *can* figure out what the class is, the
parser apparently (I have not seen the code, so I'm guessing) gets confused
when you ask it to return attributes that don't make sense for that
particular class (e.g. asking for the OSIname of an SNMP object).   When
you do this, apparently the application launcher just passes back random
data that it has lying around...

Here's an example that will work:

DEL_KEY:*
MENU: Operations
	BUTTON: SNMP Name Test
	binary: /usr/users/doug/tst_appl.csh
	ENV_TYPE: Terminal
	ARGUMENT: <domain>
	APPLIES_TO: SNMP
		ARGUMENT: <internetname>
ENDMENU:
MENU: Operations
	BUTTON: NODE4 Name Test
	binary: /usr/users/doug/tst_appl.csh
	ENV_TYPE: Terminal
	ARGUMENT: <domain>
	APPLIES_TO: Node4
		ARGUMENT: <decnetivname>
ENDMENU:
MENU: Operations
	BUTTON: NODE Name Test
	binary: /usr/users/doug/tst_appl.csh
	ENV_TYPE: Terminal
	ARGUMENT: <domain>
	APPLIES_TO: Node
		ARGUMENT: <osiname>
ENDMENU:

I don't have a quick answer right now for the datafile problem that you're
having, but hopefully, someone else will chime in...  If not, I'll try to
get back in here later.

/doug

OK, I have moved the application from the APPLICATIONS menu to the OPERATIONS
menu. The question that has not been attempted yet is why that when the MCC 
station is selected you get the node number returned when requesting the 
DECnetIVName, yet when the node4 selected is not the mcc station the correct
DECnetIVName is returned.

Re.3
Doug, 

If the APPLIES_TO cannot work for multipule entity types why does the 
documetnation in the Polycenter use manual chapter 8, page 8-11, exhibit
8-5 show an example of it.  I'm not trying to be picky, but I do need to 
understand it.

Steve
---------------------------------------------------------


DEL_KEY:*
MENU: Operations
	BUTTON: Name Test
	binary: @dkb100:[woestemeyer]tst_appl.com
	ENV_TYPE: Terminal
	Applies_to: node4
		ARGUMENT: <domain>
		ARGUMENT: <decnetivname>
		ARGUMENT: <datafile>
ENDMENU:

$ write sys$output "domain       = ''p1'"
$ write sys$output "DECnetIVName = ''p2'"
$ write sys$output "datafile     = ''p3'"
'"
$ inq/nopunc a
$exit

>>>>this is the mcc station
domain       = .DOMAIN.TEST
DECnetIVName = 28.1017
datafile     =

>>>>this is a different node4
domain       = .DOMAIN.TEST
DECnetIVName = NSUDC1
datafile     =

Steve,

>OK, I have moved the application from the APPLICATIONS menu to the OPERATIONS
>menu. The question that has not been attempted yet is why that when the MCC 
>station is selected you get the node number returned when requesting the 
>DECnetIVName, yet when the node4 selected is not the mcc station the correct
>DECnetIVName is returned.

   I cannot duplicate your problem on either VMS or ULTRIX V1.3 systems
   using your .def file and command procedure (and a C-shell translation).  
   - I select a NODE4 *not* the system that MCC is running on and I get back
     the domain name and nodename.
   - I select the NODE4 of the system that MCC is running on and I get back
     the domain name and nodename.
   Bottom line: I have no idea what's wrong with your system.


>If the APPLIES_TO cannot work for multipule entity types why does the 
>documetnation in the Polycenter use manual chapter 8, page 8-11, exhibit
>8-5 show an example of it.  I'm not trying to be picky, but I do need to 
>understand it.

    I did not say that.  What I said (more or less) was that it is
    impossible to have a script behave in a 'class-less' manner, if you
    need it to grab some sort of information as an argument.  [I don't
    think I said that last clause in my previous reply.

    The example you point out in the documentation is (as a fragment)
    perfectly legit.    What *it* is demonstrating is defining an
    application launch via double-click (passing NO arguments, so it should
    work ok, fwiw).

    The "Table of Possible Keywords" (exhibit 8-3, page 8-7) provides a
    fairly concise explanation of what you can expect from the APPLIES_TO
    and other keywords.  

/doug

    P.S.   ARGUMENT: <Datafile> *will* create and pass in the name of a
    file if (and apparently *only* if) you use "MULT_SELECT_POLICY:
    pass_all" in your .def file.   And guess what: you can't do a multiple
    select of *different* classes and have the Operations Menu work right
    -- assuming you have your application defined in the "Operations"
    menu-- if you need to do mult select across classes, you'll have to put
    it in a menu other than "Operations".