[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

326.0. "Inconsistency in FCL between Forms and Command Line Modes" by BYBLOS::TAMER () Fri Sep 14 1990 18:13

I noticed the following inconsistency between the Forms mode and the Line mode
in the FCL:


Note: in command below both arguments are required.

In the Line mode,

MCC> register server .server.phil node=byblos
ASSOCIATION = tp$ssc
server TPEDNS_NS:.server.phil
AT 14-SEP-1990 14:04:38


Registration Successful
MCC>

In the Forms mode (Line format)

MCC> register server .server.phil node=byblos

***********************************************************************
                                 DECmcc Output
                                                                               
************************************************************************
%MCC-W-ARGMISSING, The argument is missing


>>>>>It is not PROMPTING for the argument here.


Phil
T.RTitleUserPersonal
Name		DateLines
326.1enhancements in ssb kitGOSTE::CALLANDERTue Sep 18 1990 14:2017
    
    No at this point it doesn't prompt. To get it to prompt in forms
    mode will be a bit of work. To help in this area you will find that
    with your next upgrade forms mode will return a more explicit message
    stating which required argument is missing.
    
    An example would be:
    
    %MCC-W-ARGMISSING,  The required argument ASSOCIATION is missing

    We hope that this will help some. For now we believe (version 1
    and 1.1) that the use of the context sensitive help from forms mode,
    and the enhanced errors (supplying the name of the missing argument)
    should fill the hole left by the lack of prompting.
    
    jill
326.2But there is still a problemBYBLOS::TAMERThu Sep 20 1990 21:5536
Jill,


However, I consider the following still inconsistent given what you said in .1:


We are still in the Forms mode and the two arguments for register are required:

if only one argument is supplied ,

MCC>register server .server.test node =byblos
 
I get < %MCC-W-ARGMISSING, The argument is missing > as stated in the base note.

Now,

MCC> register server .server.test

I get

server TPEDNS_NS:.server.test
AT 20-SEP-1990 17:47:27


The requested operation cannot be completed
                      MCC Service Error = The requested operation cannot be
                                          completed

which means the FCL goes ahead without checking the dictionary, calls the
registration FM, which calls my AM, which in turn rejects it.

Shouldn't the FCL give this same message,
	< %MCC-W-ARGMISSING, The argument is missing >

Thnks,
Phil
326.3could be an old bugTOOK::DITMARSPeteTue Sep 25 1990 17:5932
Hi,

Thanks for reporting your problem.

I can't reproduce what you're reporting, but then again, I'm not running the 
same version of MCC as you, and I don't have whatever AM you're using that 
supports the server entity.

What version of MCC are you running?

How many required arguments does the server entity's register directive have?

Could you post your .MSL file?

Here is a log of a few attempts at register of a STATION entity from within
FORMS mode.  The directive has two required arguments, ADDRESS and FUNCTIONS
SUPPORTED.  This is run on the latest baselevel of MCC (post IFT of V1.1):

register STATION ditmars

%MCC-I-REQARG, ADDRESS is a required argument
%MCC-W-ARGMISSING, argument is missing

register STATION ditmars Address = aa-00-04-00-fb-13

%MCC-I-REQARG, FUNCTIONS SUPPORTED is a required argument
%MCC-W-ARGMISSING, argument is missing

register STATION ditmars Functions Supported = ENETV2_Only

%MCC-I-REQARG, ADDRESS is a required argument
%MCC-W-ARGMISSING, argument is missing
326.4fixed for SSB kitGOSTE::CALLANDERWed Sep 26 1990 12:5111
    
    There was a bug, as reported by .2, where we attempted to make
    the call even if the required arguments were not present. This was
    due to the parser returning the wrong (unexpected) error return
    for the missing arguments.
    
    This has been fixed in the final v1.0 build (as Pete's test show
    in .3).
    
    Thanks for the input.